[opennms-devel] WMI Architecture Dilemma

[Matt R. <mat...@gm...>]

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