I wanted to ask about the fact that a locator is not a requirement when accessing WMI. For us, this is the biggest differentiating factor between j-Interop and Jintegra.
Having a windows machine to act as a locator when accessing WMI via Jintegra is an absolute requirement and specified in all documentation from Jintegra (see http://j-integra.intrinsyc.com/support/com/doc/other_examples/WMI_Scripting_from_Java.htm for example). Do you have any idea how it is that j-Interop manages to get around this requirement? Do you know of any limitations about this ability regarding j-Interop?
I recommend that you mention this fact in your presentation when a comparison between the 2 libraries is made, because this is a huge advantage for j-Interop.
-David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The difference is that when using Jintegra the locator used is not the host being accessed; instead it is either the host running Jintegra (when running on Windows) or a 3rd "management" host when running on a Unix host.
With j-Interop, there is no need for a "management" host when running from a Unix host. A Unix host accesses WMI directly on a remote host without any need for a 3rd host. And that's a big advantage...
-David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi David,
WMI is part of the infrastructure services of all Windows OSs (with a hotfix, it is even available for 95)...so a locator exists on all OSs...I wonder why they (JIntegra) did not go for direct access. All the customers I have who are using WMI, have been following the direct route (as you mentioned also) and no one complained so far ...may be you can try the same code with JIntegra and see if it works ... I hope they do provide basic APIs instead of wrappers.
Thanks,
best regards,
Vikram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried the strategy used in j-Interop samples to access WMI, with J-Integra (using their wrappers). There are some Windows hosts it succeeds with, but for others it hangs or otherwise fails during connect.
So j-Interop does have a great advantage (one which I would love to understand!).
-David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well David, in that case, here is the secret...nothing :)...I really don't do anything extra. It is plain COM. Maybe they do some magic inside which unfortunately doesn't but I really do nothing special. To me , WMI is just another example.
take care,
best regards from a cold,windy and wet Munich,
Vikram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I understand, J-Interop modifies registry on remote machine to make SWbemLocator object available via DCOM (changes its registration). But sometimes this is not a good solution...
But there is another interface what can be used to access WMI remotely: IWbemLevel1Login (MS recently has published documentation for it) I can create instance of this interface on remote machine, but when I try to call method “NTLMLogin” via J-Interop, I'm getting error (procedure number is out of range). Looks like a bug… I'm getting this error for any operation number, including 0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is an old thread, but it came up in searches for how to do this. So I figured I'll share the information below that I managed to figure out and patch together from various snippets in obscure corners of the great Google oracle. The below is cobbled together from various abstractions but hopefully should give the idea:
public IJIComObject doLevel1Login( IJIComObject o_IWbemLevel1Login, String wmiNamespace, String wmiLocaleCode )
{
final int OPNUM_NTLM_LOGIN = 3;
Note that the caveat here is the objects returned from this WMI entry point aren't Automation friendly and can require parsing the WMI object encoding protocol: http://msdn.microsoft.com/en-us/library/cc250837\(PROT.10).aspx
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I wanted to ask about the fact that a locator is not a requirement when accessing WMI. For us, this is the biggest differentiating factor between j-Interop and Jintegra.
Having a windows machine to act as a locator when accessing WMI via Jintegra is an absolute requirement and specified in all documentation from Jintegra (see http://j-integra.intrinsyc.com/support/com/doc/other_examples/WMI_Scripting_from_Java.htm for example). Do you have any idea how it is that j-Interop manages to get around this requirement? Do you know of any limitations about this ability regarding j-Interop?
I recommend that you mention this fact in your presentation when a comparison between the 2 libraries is made, because this is a huge advantage for j-Interop.
-David
Hi David,
In the MSWMI examples, the locator is reached via these calls...
comStub = new JIComServer(JIProgId.valueOf(session,"WbemScripting.SWbemLocator"),address,session);
IJIComObject unknown = comStub.createInstance();
comObject = (IJIComObject)unknown.queryInterface("76A6415B-CB41-11d1-8B02-00600806D9B6");//ISWbemLocator
so we do need a locator... Unfortunately I am uncertain if I even understood your question,
beg your pardon,
best regards,
Vikram
Hi Vikram,
The difference is that when using Jintegra the locator used is not the host being accessed; instead it is either the host running Jintegra (when running on Windows) or a 3rd "management" host when running on a Unix host.
With j-Interop, there is no need for a "management" host when running from a Unix host. A Unix host accesses WMI directly on a remote host without any need for a 3rd host. And that's a big advantage...
-David
Hi David,
WMI is part of the infrastructure services of all Windows OSs (with a hotfix, it is even available for 95)...so a locator exists on all OSs...I wonder why they (JIntegra) did not go for direct access. All the customers I have who are using WMI, have been following the direct route (as you mentioned also) and no one complained so far ...may be you can try the same code with JIntegra and see if it works ... I hope they do provide basic APIs instead of wrappers.
Thanks,
best regards,
Vikram
Hi Vikram,
I have tried the strategy used in j-Interop samples to access WMI, with J-Integra (using their wrappers). There are some Windows hosts it succeeds with, but for others it hangs or otherwise fails during connect.
So j-Interop does have a great advantage (one which I would love to understand!).
-David
Well David, in that case, here is the secret...nothing :)...I really don't do anything extra. It is plain COM. Maybe they do some magic inside which unfortunately doesn't but I really do nothing special. To me , WMI is just another example.
take care,
best regards from a cold,windy and wet Munich,
Vikram
As I understand, J-Interop modifies registry on remote machine to make SWbemLocator object available via DCOM (changes its registration). But sometimes this is not a good solution...
But there is another interface what can be used to access WMI remotely: IWbemLevel1Login (MS recently has published documentation for it) I can create instance of this interface on remote machine, but when I try to call method “NTLMLogin” via J-Interop, I'm getting error (procedure number is out of range). Looks like a bug… I'm getting this error for any operation number, including 0.
This is an old thread, but it came up in searches for how to do this. So I figured I'll share the information below that I managed to figure out and patch together from various snippets in obscure corners of the great Google oracle. The below is cobbled together from various abstractions but hopefully should give the idea:
public IJIComObject doLevel1Login( IJIComObject o_IWbemLevel1Login, String wmiNamespace, String wmiLocaleCode )
{
final int OPNUM_NTLM_LOGIN = 3;
JICallBuilder cb = new JICallBuilder(true);
cb.reInit();
cb.setOpnum(OPNUM_NTLM_LOGIN); // IWbemLevel1Login.NTLMLogin()
cb.addInParamAsPointer(new JIPointer(new JIString(wmiNamespace, JIFlags.FLAG_REPRESENTATION_STRING_LPWSTR)), JIFlags.FLAG_NULL);
cb.addInParamAsPointer(new JIPointer(new JIString(wmiLocaleCode, JIFlags.FLAG_REPRESENTATION_STRING_LPWSTR)), JIFlags.FLAG_NULL);
cb.addInParamAsInt(0, JIFlags.FLAG_NULL);
cb.addInParamAsPointer(new JIPointer(null, true), JIFlags.FLAG_NULL);
cb.addOutParamAsType(IJIComObject.class, JIFlags.FLAG_NULL);
final String IID_IWbemServices = "9556DC99-828C-11CF-A37E-00AA003240C7";
Object[] callResult;
callResult = o_IWbemLevel1Login.call(cb);
return ((IJIComObject) callResult[0]).queryInterface(IID_IWbemServices);
}
Note that the caveat here is the objects returned from this WMI entry point aren't Automation friendly and can require parsing the WMI object encoding protocol: http://msdn.microsoft.com/en-us/library/cc250837\(PROT.10).aspx
why these interface names are hard coded 00020400-0000-0000-c000-000000000046 and how we can get all these interface names ?