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

[James C. <ca...@vi...>]

>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".

This was the way I very early on proposed uVM devices could interact in this
framework and still make sense. I also think that this is something that
makes sense for the User Interface thing also, why not just use dynamicall
generated HTML as our user interface to anything rather than try to create
some other GUI standard.

James Caska
http://www.muvium.com
'Java Bred for Embedded'



> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Thursday, February 06, 2003 1:33 AM
> To: emb...@li...
> Subject: [Embedlets-dev] [Arch] JMX Management
>
>
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> 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
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>