Hi Matt,
Based on what you've presented below, and not a small portion of sheer
instinct, I'd recommend the first option (Persistent COM Objects). It seems
cleaner to me (as much as I understand it), and IMHO, the Cons of the first are
less significant than the Cons of the second. There's not a lot in it, and I
reserve the right to run like a coward if challenged as to why I think that
way, but I hope it helps a little in making your decision.
Craig
So just when I thought the WMI code was complete Jeff asked me a question which
forced me to seriously consider whether it was releasable in its current state.
The short version is that I think it's useful in its current state but I'm not
positive I'd release it and here's why:
I presently use the WbemServices method "InstanceOf" which only allows me to
get the objects of a single-instance class or a list of classes - which I
presently do not support. I need to reimplement using "Get" or "ExecQuery" (if
I wanted to move to WQL.) Ultimately I decided that what would be better would
be to better mimmick the WBEM classes provided in the scripting interface I'm
querying. So WmiClient would become something similar to WbemServices, which
would return WbemObjectSets which would return WbemObjects and so on.
To the point - I'm doing this very thing. The question though becomes do I
maintain persistent COM objects or do I dutifully extract the information
necessary and pre-build the resulting objects? They both have merits and
detractions.
Persistent COM Objects:
For each method call that generates an object from the remote host I would
generate a local native object (e.g. OnmsWbemObject) and include a reference to
the original COM object. Any method or property calls would simply be wrapping
and abstracting the J-Interop calls to the COM object.
Pros:
* Simplest method to implement.
* Provides a familiar interface for future feature developers within the
project wanting to harness WMI for a new module (e.g. inventory collection.)
* The J-Interop COM model better matches the OpenNMS Wbem model.
Cons:
* J-Interop code is spread throughout the WMI protocol code rather than limited
to existing within a single class (WmiClient, as was my hope.)
* Difficulty in managing lifetime of resulting COM objects. Maintaining an
instance of an object beyond the scope of the connection to the host will
produce exceptions.
* Each call will generate connectivity to the remote host, causing each call to
be dependent upon the efficiency of the network.
* Difficult to upgrade in an effort to accomodate the shifting J-Interop APIs.
Pre-Built WBEM Objects
For each method the WmiClient would recursively crawl through each resulting
object and generate a native class independent of the WMI/J-Interop structure.
Pros:
* All connectivity lifetime issues are eliminated as the data is no longer
associated with an active COM object.
* The model objects (e.g. OnmsWbemObject) require no business logic and become
simple data containers.
* All logic can be aggregated into WmiClient and, at worse, a few utilitity
classes.
* More simplified upgrade process for API changes in the J-Interop library due
to the consolidation of J-Interop-facing logic.
Cons:
* The process of parsing all of the data into native objects will be time
consuming, especially if the developer needs only one property and an object
contains hundreds.
* The WmiClient class and any potential utility classes become cumbersome and
complicated due to the mess of logic being shoved into a limited space.
* The a large query result will result in a large allocation of system
resources. This is loosely related to the first con. This is a challenge if
very little data is actually needed.
* This could be more prone to bugs due to the need for forward-thinking
conversion, missed types, mis-casting, etc. As these may not be converted on an
individual basis.
* Limitation in the inability to execute WMI methods efficiently. A model
object would not have the ability to make method calls and an alternative API
would have to be develped.
I'm torn because both ways to attack the problem have upsides and downsides. I
was kind of hoping to get some feedback from you guys as to what your thoughts
and opinions were on this.
--
Matt Raykowski
/s
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
