RE: [Embedlets-dev] [Arch] JMX Management

[Christopher S. <cs...@oo...>]

 Topic tags:[Arch][Wiring][Doc][HW][PM]
 _______________________________________________

Sounds like we are very much in sync (see following excerpt).

Not to get hung up on the syntax, but I would like to point out that passing
around the XML serialized object itself as the response has one or two
advantages:

1. Multiple attributes can be returned in one request, as opposed to
multiple requests required for an RPC/SOAP based scheme.
2. The object packet is self documenting. The requester needs to know only
the id of the object and not every attribute. This decouples the
requester/responder very effectively.
3. The ability to 'turn-around' the packet with modifications forms the
basis for Embedlet update.
4. The 'object packet' scheme supports persistence in any form (flash, file,
database etc.) based on the provider, without additional code or XML
vocabulary.

Item 2 leads to a very nice bonus capability where a generic property editor
without prior knowledge can:

1. Query the container for its list of Embedlet names/ids
2. Select an Embedlet and send a 'getProperties' request. (Note the plural
form).
3. Display/edit the returned object properties in a name/value grid.
4. Modify and update via a 'setProperties' request that returns the modified
object packet.

The responder has control over the properties that are exposed/read/written
unlike native Java serialization.

The disadvantage of course is that getting the whole object packet is likely
to be more expensive than a single RPC query, but probably not more
expensive than 2. If this were an issue the container could filter the
response down to the requested property.


>
> > For example a request:
> >
> > <Request command="getProperties" identity="CB_OUTPUT_1"/>
> >
> > The response:
> >
> > <Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../>
> >
> > This can easily be handled by one of the small-footprint parsers or a
> > hand-rolled byte level parser. It is in stripped XML form so
> that an upper
> > level transport can simply enclose it into a full envelope or
> transform it
> > to established protocols. Collections, compound objects and
> reference links
> > are possible using this technique as well.
>
> Exactly right.  That is what I've been thinking all along,
> however, I think your example
> is too application specific.
>
> The name of the feature/embedlet /device (Lights) would probably
> never be an
> element or attribute.  Doing this ties your vocabulary to the
> specific domain
> application (light control in the this example). XML management
> syntax would have
> be more generic than that to provide a universal management
> capability across
> any/all embedlets.  For instance, the request to get a property
> from a managed
> object (embedlet) would look more like:
>
> <request target="embedlet"
> 	type="light"
> 	id="30212"
> 	operation="getProperty"
> 	property="CB_OUTPUT_1" />
>
> and the response would be more like:
>
> <response target="embedlet"
> 	type="light"
> 	id="30212"
> 	property="CB_OUTPUT_1"
>     	value="On" />
>
> Very similar to your example, but extensible to ALL management
> functions, since the
> element tags and attributes are defined by the Embedlet Management XML
> Schema....and only the values are unique to the specific
> embedlet/application. (Don't
> get hyper about the example syntax...it's just an example to get
> the concept across,
> not a "proposal" for how the Management XML Schema should
> actually look. In fact,
> there would be value in using a SOAP-based RPC approach to the
> XML managment
> schema since it maps nicely to the remote RPC-like JMX API's
> cleanly and there are
> a lot of back end tools that let you create/consume such Web Services RPC
> requests without having to bother with the SOAP/XML "plumbing").
>
> For example, to control a GPS device the request might look like:
>
> <request target="embedlet"
> 	type="GPS"
> 	id="myGPS"
> 	operation="setProperty"
> 	property="GPSProtocol"
> 	value="NMEA"/>
>
> Same syntax, different application altogether!  But this allows
> us to implement a
> generic Management Service that all Embedlets can utilize.  The
> user wouldn't even
> have to know anything about the underlying XML syntax, since this
> would be
> automatically assembled and then parsed at both ends (JMX API's
> used by the
> remote GUI control app to issue the request through the JMX
> Adapter, then across
> the comm link and the to the Outpost Managment Service API used
> by the Embedlet
> to respond to the request).
>
> I know I'm splitting hairs here...but such genericity has to be
> implicit in the design of
> our protocols and XML vocabularies/schemas for the container to
> be able to provide
> useful, generic, reuseable services, so I thought it worth noting.
>
> > This becomes the foundation for building complex systems out of
> very simple
> > rules, as Andrzej has proposed.
>
> Yuppers! ;-)
>