[Embedlets-dev] [Arch] JMX Management

[Andrzej J. T. <an...@ch...>]

Chris said (re GUIs for Control functions):

>  am assuming that they have none. The devices that provide the UI need to
> be able to communicate directly and simply with the Embedlets. Envision a
> plant operator walking up to a device with his wireless or wired hand-held
> to make adjustments to the system. 

Makes sense.  I think it is well beyond our scope to try and create a UI library to 
support devices that have display capability, and it would likely be best to just adopt 
and implement the MIDP LCDUI API if such was needed on the platform itself, but 
that should be a separate project from Embedlets probably.

> Requiring JMX as the sole management
> interface would, I think, put a very large infrastructure demand on that
> simple interaction. 

I think you'll be pleasantly surprised.  If you compare the JMX standard with the 
Embedlets Architecture (as outlined in the discussion document), you'll find there is a 
lot of conceptual similarity (deliberate on my part ;-)  between Embedlets and JMX).  
At a conceptual level there are a lot of parallels between the two architectures, with 
the mapping (conceptual, not intended to imply inheritance or implementation 
dependency) looking something like:

Outpost/Embedlets			JMX
--------------------------			--------------------
Outpost Container			MBean Server (and managed resource 
itself)
Outpost Services			JMX Agents/Services
Embedlet				MBean (managed resource/properties)
Event Manager Service		JMX Notifications
Timer Service				JMX Timer Agent/Service
Monitoring Service			JMX Monitoring Agent/Service
Protocol/Transport Adapter		JMX Connector/Adapter

Now if you look at the JMX spec, external management is done through a 
protocol/transport adapter, which exposes the JMX interfaces/API's at the 
management end.  This means we can implement some hooks in the Outpost 
Container and Services, along with a custom Protocol/Transport Adapter (probably 
using Web Services, eg. SOAP/XML/HTTP) that exposes the Embedlet 
management functions outside the device.  Note that we do NOT need to implement 
the actual JMX interfaces in the embedded container!  On the management side 
(management console, server side JMX-aware management tool like Tivoli for 
instance) all we need to do is provide an adapter that can translate our Management 
Protocol (XML vocabulary) into the real JMX interfaces, classes and methods.  This 
can be done because the preliminary architecture I documented deliberately maps 
nicely onto JMX concepts as well.

So we get the best of both worlds, optional, but very lightweight Management Service 
on the embedded device, with an external JMX-compatible (but decoupled) adapter 
and tools (like your Process Control UI remote app) layer that translates from the 
Outpost Management protocol to JMX standard APIs (and vice versa).

One of the benefits of this is anyone writing external control or management 
applications can use a standard API to do this, namely JMX, which is gaining ground 
very rapidly.  If there is a standard way of doing something there is a lot of value to 
adopting that approach, since it widens the market and gives more 
credibility/acceptance value. Using this approach, the glass-house server operations 
boys could actually use Tivoli, OpenView or such to manage the distributed 
Embedlets!  In fact, this approach would let operations staff (which could be the shop 
floor operator, foreman, plant manager, etc.) receive real time alerts if things start to 
go amiss...and get those through the corporations normal management 
infrastructure. Wow...now that's a sales/adoption feature big time!  Management 
is/will be a big issue with thousands of Embedlets flung around a corporation and 
integrated to the back ends.

Just like Ted, you can have your cake and eat it too, Chris! <grins>

> It would also lock out other socket/XML capable
> interfaces such as ActiveX (yes it still lives), .NET, Perl etc.

With the solution that I envision (see above) with the Management capability 
exposed as a Web Service (SOAP/XML), it would be trivial to integrate into any other 
back end technology that was not JMX enabled, such as the ones you mention, yet 
still provide tight integration with JMX-based management solutions where desired, 
with minimal performance or footprint penalty.

> I agree
> that a JMX/Embedlet Adapter would defintely be a huge boost to the
> acceptablility at the Enterprise management level.

Absolutely!  Even if they don't use it right away (or ever) it's a very, VERY big selling 
feature.  Remote management of Embedlets, to the point of enabling integration with 
the large, common back end management systems (eg, Tivoli) would be a HUGE 
benefit for Embedlets.  I would even say it would be more important than many other 
features of Outpost.  Manageability is a key issue for corporate systems when they 
become integrated together (which is one of our key goals).

> It is my assertion, however that we need and can have a simple dynamic
> configuration, persistence and management interface without significant
> footprint bloat, possibly relieving the requirement for a tool-heavy
> static build process.

I agree that we need these capabilities, but there are very good architectural reasons 
to make them decoupled, independent (of each other) and optional Outpost 
Container services.  Take Persistence for instance.  It should be generic enough to 
store/retrieve any arbitrary data...not just config files.  There may be good reason for 
an application to use persistance, but it may not need dynamic reconfig.  Think 
"service-oriented" rather than "interface-oriented" (though it can be very convenient 
to have a Persistable interface implemented by objects that are candidates for 
storage).

Dynamic config has already been added as an optional service to the 1.2 
Architecture Discussion Doc.  So has Persistence.  Management I talked about 
earlier.  I expect to add more detail to all three of these service "definitions" in the 
document (to preserve our thinking) per my comments in this email, in the next 
release of the document (1.3).

I think that when more of the details of my (admittedly warped at times) thinking 
come to light, you'll see that you'll be able to handle the kind of applications you have 
described, without compromising the lightweight design goals of an Embedlet server, 
and also be able to leverage more modularity, flexibility and standards (eg. JMX).

> A bold statement I know, but I am prepared to back it up with some coded
> examples.

I've read some of your stuff already.....will be reviewing the JavaDocs in the next day 
or two regarding your implementation of some of these concepts.

Gregg then clarifies:

> The MBean would not necessarily have to be on the device.  If we spec
> a very simple text based admin protocol that provides 'events',
> 'properties' and 'actions', then we can write a single MBean that can
> run on the managers device, and talk via a serial network to the
> device.  This would facilitate remote management in places where
> device have a network to somewhere else....  But a serial port could
> be used for management of individual devices. 

Bingo! Exactly my thinking, Gregg!  Larger platforms (maybe JStik's or PC's) might 
want to actually implement MBeans on the controller (there are some benefits to that 
approach, and it could be implemented as a decorator layer without touching the 
core embedlet container code)....but for the most part, a decent XML-based 
management vocabulary, exposed as a web service over HTTP would give us way 
more flexibility, even to the point of providing management across serial cable 
connections (or wireless equivalents like Bluetooth).  The possbilities are very 
exciting and would make a very compelling "pitch".

Chris then provides an example:

> 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! ;-)

BTW....I'm typing this in a coffee shop while waiting to give a presentation on Web 
Services (the MGDP project) and ebXML to the Toronto Java Users Group in about 
an hour.  I'll be mentioning the Outpost/Embedlets initiative at the presentation. It 
might engender some more victims....ooops.....I mean interest and volunteers. ;-)



...Andrzej

Chaeron Corporation
http://www.chaeron.com