I've been using j-Interop for the past 3 weeks to learn how to execute WMI queries against Windows event logs. It's pretty cool stuff, but I'm now at a point where I need to ask if anyone knows how to perform early binding for the Win32_NTLogEvent objects that return in the SWbemObjectSet as a result of my SWbemServices.ExecQuery method call.
I've used Wireshark to observe the IDispatch network traffic between my host machine (running the JVM and j-Interop framework) and the remote machine where the Windows event logs are located and the Wireshark captures confirm that no matter whether I'm using synchronous or semisynchronous mode to retrieve all the attributes of each Win32_NTLogEvent object, a network call is necessarily made to get that data from the remote machine.
My research has lead me to believe this is because j-Interop is based on the IDispatch object, which is a late binding technology designed by Microsoft. To avoid the extra network traffic, which slows down the performance of getting all my log data back into the JVM, I would prefer if I could use j-Interop in some way to perform an early binding of the attributes on the Win32_NTLogEvent objects that return to me in the SWbemObjectSet enumeration.
Is early binding possible for the returning log event objects or am I pretty much restricted only to late bound objects via the j-Interop API?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologize but I don't follow you entirely. Is it about data latency (you
not getting full data in one go) or is it about late binding as the term
holds ? The thing is IDispatch is early binding however the way WMI
scripting has been designed by MS is that you have to query per object and
limited information is returned back from the server. You can get the
Enumeration as well but only pointers are returned again and a round-trip
call will be required to get data back. If you implement the WMI
Specifications directly (via j-interop) then you can get data in one go
(full object).
I've been using j-Interop for the past 3 weeks to learn how to execute WMI
queries against Windows event logs. It's pretty cool stuff, but I'm now at
a point where I need to ask if anyone knows how to perform early binding
for the Win32_NTLogEvent objects that return in the SWbemObjectSet as a
result of my SWbemServices.ExecQuery method call.
I've used Wireshark to observe the IDispatch network traffic between my
host machine (running the JVM and j-Interop framework) and the remote
machine where the Windows event logs are located and the Wireshark captures
confirm that no matter whether I'm using synchronous or semisynchronous
mode to retrieve all the attributes of each Win32_NTLogEvent object, a
network call is necessarily made to get that data from the remote machine.
My research has lead me to believe this is because j-Interop is based on
the IDispatch object, which is a late binding technology designed by
Microsoft. To avoid the extra network traffic, which slows down the
performance of getting all my log data back into the JVM, I would prefer if
I could use j-Interop in some way to perform an early binding of the
attributes on the Win32_NTLogEvent objects that return to me in the
SWbemObjectSet enumeration.
Is early binding possible for the returning log event objects or am I
pretty much restricted only to late bound objects via the j-Interop API?
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
Yes, my performance question is regarding (as you put it) the data latency - not getting full data in one go.
Perhaps if you see my prototype code, you get a better idea for structure of what I'm doing. This could easily just be a j-Interop noob problem and that I'm somehow not using the j-Interop framework properly.
final JIVariant variant = wbemObjectSet.get("_NewEnum");
final IJIComObject comObject = variant.getObjectAsComObject();
final IJIEnumVariant wbemEnum = (IJIEnumVariant) JIObjectFactory
.narrowObject(comObject.queryInterface(IJIEnumVariant.IID));
// An array to put all my returning Java objects
// Win32_NTLogEvent is my Java representation of the
// WMI Win32_NTLogEvent class.
final Win32_NTLogEvent[] logEvents = new Win32_NTLogEvent[recordCount];
for (int outerLoopIndex = 0; outerLoopIndex < recordCount;
outerLoopIndex++) {
final Object[] values = wbemEnum.next(1);
final JIArray array = (JIArray) values[0];
final Object[] objectArray = (Object[]) array.getArrayInstance();
// Process each element of the array to get all the attributes of the
// underlying object from each element of the SWbemObjectSet
// enumeration
for (int innerLoopIndex = 0; innerLoopIndex < objectArray.length;
innerLoopIndex++) {
// Each wbemObject is expected to be a WMI Win32_NTLogEvent object
final IJIDispatch wbemObject = (IJIDispatch) JIObjectFactory
.narrowObject(((JIVariant) objectArray[innerLoopIndex])
.getObjectAsComObject());
// The convertToWin32_NTLogEvent static method is just a long
// method that converts the IJIDispatch object (a WMI
// Win32_NTLogEvent object) into a Java object.
//
// It is in the static convertToWin32_NTLogEvent method when I get
// each attribute that Wireshark shows a DCE/RPC request back to
// the remote machine to get the parameter value via IDipatch (as
// many as 16 potentially separate attributes for each event log
// record.)
logEvents[outerLoopIndex] = Win32ToJavaObjectConverter
.convertToWin32_NTLogEvent(wbemObject);
}
}
Like I said, the above code works, but the problem is that my Wireshark capture shows me that getting each attribute of the underlying enumeration back (e.g., for the Win32_NTLogEvent class these are attribute names such as Category, EventCode, EventType, Logfile, Message, RecordNumber, SourceName, TimeGenerated, etc.) invokes a DCE/RPC call back to the remote machine to get that value from the IDispatch object.
So many DCE/RPC calls (up to 16 attributes per object) seems to be killing my j-Interop performance to get those event log records back from the remote machine. I'd love it if the simple answer is that I'm a noob and just don't yet understand how to more efficiently use j-Interop to get all the parameter data back in "one go" of the ExecQuery execution, but I have not yet found information on this subject anywhere online.
So what observations/insights do you have to share with me, Vikram?
Thanks,
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your code is correct. And, unfortunately for you, you do understand the
problem :D ... (which means we have no solution to look for) ... To get
information in one go , you need to implement the WMI Service interface
yourself, using j-interop. There are several posts about this, if you would
please search the forum.
We have implemented it for a few APIs. It gets the full object back and
then these are local calls on the object.
Yes, my performance question is regarding (as you put it) the data latency
- not getting full data in one go.
Perhaps if you see my prototype code, you get a better idea for structure
of what I'm doing. This could easily just be a j-Interop noob problem and
that I'm somehow not using the j-Interop framework properly.
final JIVariant variant = wbemObjectSet.get("_NewEnum");final IJIComObject comObject = variant.getObjectAsComObject();
final IJIEnumVariant wbemEnum = (IJIEnumVariant) JIObjectFactory
.narrowObject(comObject.queryInterface(IJIEnumVariant.IID));
// An array to put all my returning Java objects// Win32_NTLogEvent is my Java representation of the// WMI Win32_NTLogEvent class.final Win32_NTLogEvent[] logEvents = new Win32_NTLogEvent[recordCount];
for (int outerLoopIndex = 0; outerLoopIndex < recordCount;
outerLoopIndex++) {
final Object[] values = wbemEnum.next(1);
final JIArray array = (JIArray) values[0];
final Object[] objectArray = (Object[]) array.getArrayInstance();
// Process each element of the array to get all the attributes of the
// underlying object from each element of the SWbemObjectSet
// enumeration
for (int innerLoopIndex = 0; innerLoopIndex < objectArray.length;
innerLoopIndex++) {
// Each wbemObject is expected to be a WMI Win32_NTLogEvent object
final IJIDispatch wbemObject = (IJIDispatch) JIObjectFactory
.narrowObject(((JIVariant) objectArray[innerLoopIndex])
.getObjectAsComObject());
// The convertToWin32_NTLogEvent static method is just a long
// method that converts the IJIDispatch object (a WMI
// Win32_NTLogEvent object) into a Java object.
//
// It is in the static convertToWin32_NTLogEvent method when I get
// each attribute that Wireshark shows a DCE/RPC request back to
// the remote machine to get the parameter value via IDipatch (as
// many as 16 potentially separate attributes for each event log
// record.)
logEvents[outerLoopIndex] = Win32ToJavaObjectConverter
.convertToWin32_NTLogEvent(wbemObject);
}}
Like I said, the above code works, but the problem is that my Wireshark
capture shows me that getting each attribute of the underlying enumeration
back (e.g., for the Win32_NTLogEvent class these are attribute names such
as Category, EventCode, EventType, Logfile, Message, RecordNumber,
SourceName, TimeGenerated, etc.) invokes a DCE/RPC call back to the remote
machine to get that value from the IDispatch object.
So many DCE/RPC calls (up to 16 attributes per object) seems to be killing
my j-Interop performance to get those event log records back from the
remote machine. I'd love it if the simple answer is that I'm a noob and
just don't yet understand how to more efficiently use j-Interop to get all
the parameter data back in "one go" of the ExecQuery execution, but I have
not yet found information on this subject anywhere online.
So what observations/insights do you have to share with me, Vikram?
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While that is obviously not the answer I was hoping to receive, it is definitely helpful to know that I haven't missed anything in the j-Interop API or framework. Thanks for your time and guidance regarding the WMI service interface.
All my best,
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using j-Interop for the past 3 weeks to learn how to execute WMI queries against Windows event logs. It's pretty cool stuff, but I'm now at a point where I need to ask if anyone knows how to perform early binding for the Win32_NTLogEvent objects that return in the SWbemObjectSet as a result of my SWbemServices.ExecQuery method call.
I've used Wireshark to observe the IDispatch network traffic between my host machine (running the JVM and j-Interop framework) and the remote machine where the Windows event logs are located and the Wireshark captures confirm that no matter whether I'm using synchronous or semisynchronous mode to retrieve all the attributes of each Win32_NTLogEvent object, a network call is necessarily made to get that data from the remote machine.
My research has lead me to believe this is because j-Interop is based on the IDispatch object, which is a late binding technology designed by Microsoft. To avoid the extra network traffic, which slows down the performance of getting all my log data back into the JVM, I would prefer if I could use j-Interop in some way to perform an early binding of the attributes on the Win32_NTLogEvent objects that return to me in the SWbemObjectSet enumeration.
Is early binding possible for the returning log event objects or am I pretty much restricted only to late bound objects via the j-Interop API?
Hi,
I apologize but I don't follow you entirely. Is it about data latency (you
not getting full data in one go) or is it about late binding as the term
holds ? The thing is IDispatch is early binding however the way WMI
scripting has been designed by MS is that you have to query per object and
limited information is returned back from the server. You can get the
Enumeration as well but only pointers are returned again and a round-trip
call will be required to get data back. If you implement the WMI
Specifications directly (via j-interop) then you can get data in one go
(full object).
best regards,
Vikram
On Tue, Sep 23, 2014 at 6:13 AM, Java Steve safrin@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Hi Vikram,
Yes, my performance question is regarding (as you put it) the data latency - not getting full data in one go.
Perhaps if you see my prototype code, you get a better idea for structure of what I'm doing. This could easily just be a j-Interop noob problem and that I'm somehow not using the j-Interop framework properly.
final JIVariant variant = wbemObjectSet.get("_NewEnum"); final IJIComObject comObject = variant.getObjectAsComObject(); final IJIEnumVariant wbemEnum = (IJIEnumVariant) JIObjectFactory .narrowObject(comObject.queryInterface(IJIEnumVariant.IID)); // An array to put all my returning Java objects // Win32_NTLogEvent is my Java representation of the // WMI Win32_NTLogEvent class. final Win32_NTLogEvent[] logEvents = new Win32_NTLogEvent[recordCount]; for (int outerLoopIndex = 0; outerLoopIndex < recordCount; outerLoopIndex++) { final Object[] values = wbemEnum.next(1); final JIArray array = (JIArray) values[0]; final Object[] objectArray = (Object[]) array.getArrayInstance(); // Process each element of the array to get all the attributes of the // underlying object from each element of the SWbemObjectSet // enumeration for (int innerLoopIndex = 0; innerLoopIndex < objectArray.length; innerLoopIndex++) { // Each wbemObject is expected to be a WMI Win32_NTLogEvent object final IJIDispatch wbemObject = (IJIDispatch) JIObjectFactory .narrowObject(((JIVariant) objectArray[innerLoopIndex]) .getObjectAsComObject()); // The convertToWin32_NTLogEvent static method is just a long // method that converts the IJIDispatch object (a WMI // Win32_NTLogEvent object) into a Java object. // // It is in the static convertToWin32_NTLogEvent method when I get // each attribute that Wireshark shows a DCE/RPC request back to // the remote machine to get the parameter value via IDipatch (as // many as 16 potentially separate attributes for each event log // record.) logEvents[outerLoopIndex] = Win32ToJavaObjectConverter .convertToWin32_NTLogEvent(wbemObject); } }Like I said, the above code works, but the problem is that my Wireshark capture shows me that getting each attribute of the underlying enumeration back (e.g., for the Win32_NTLogEvent class these are attribute names such as Category, EventCode, EventType, Logfile, Message, RecordNumber, SourceName, TimeGenerated, etc.) invokes a DCE/RPC call back to the remote machine to get that value from the IDispatch object.
So many DCE/RPC calls (up to 16 attributes per object) seems to be killing my j-Interop performance to get those event log records back from the remote machine. I'd love it if the simple answer is that I'm a noob and just don't yet understand how to more efficiently use j-Interop to get all the parameter data back in "one go" of the ExecQuery execution, but I have not yet found information on this subject anywhere online.
So what observations/insights do you have to share with me, Vikram?
Thanks,
Steve
Dear Steve,
Your code is correct. And, unfortunately for you, you do understand the
problem :D ... (which means we have no solution to look for) ... To get
information in one go , you need to implement the WMI Service interface
yourself, using j-interop. There are several posts about this, if you would
please search the forum.
We have implemented it for a few APIs. It gets the full object back and
then these are local calls on the object.
best regards,
Vikram
On Wed, Sep 24, 2014 at 11:38 AM, Java Steve safrin@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Dear Vikram,
While that is obviously not the answer I was hoping to receive, it is definitely helpful to know that I haven't missed anything in the j-Interop API or framework. Thanks for your time and guidance regarding the WMI service interface.
All my best,
Steve