RE: [Embedlets-dev] [Arch] Persistence vs. Management

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris responds.
>
> > I think that it could be simplified to two distinct requests
> 'getProperty'
> > singular  and 'getProperties' plural.
> >
> > This make request parsing single level.
> >
> > I am not sure why the response attributes need their own ids as they are
> > encapsulated within the response and associated with the object
> id?? This
> > would make for simple XML encoding of multiple attributes in the
> > name=value form.
>
> Doesn't really matter....it was just a quick example off the top
> of my head....not a proposal for an
> on-the-wire encoding.  As I had mentioned, I think using a
> SOAP/RPC encoding that is based on
> WSDL and standard Web Services encodings will be the initial way
> to go (though with pluggable
> adapters for communications protocols and transports, it should
> be fairly easy to change to some
> other encoding if there is need/desire to do so).
>
> > They are not actually orthagonal to each other, but rather very much
> > parallel. They are both variations on property set/get
> functionality. From
> > the Embedlet's point of view there is no difference between a
> persistence
> > property assignment and a Management property assignment.
>
> Actually I think there is a lot of difference, despite the rather
> superficial similarties.

If you apply your 'inversion of control' pattern the Embedlet should not see
a difference. The container would determine the services that are available
and determine whether the Embedlet could be persisted and what persistent
service is required. Otherwise the simplest Embedlet would have to 'know'
how to interact with all of the expected (and unexpected services) in order
to operate in all containers from constrained to powerful.

This means that an Embedlet provider would have to offer multiple versions
of Embedlets (simple/static, exposed/dynamic, persistent, managed ...??).

If the Embedlet interface is simple and sets & gets its properties via
name/value pairs (alla Properties) it can accomodate the expected
interactions with the same interface. So that a simple embedlet would be
able to run in a complex enviroment and be dynamically loaded, persisted and
managed. In an enviroment that does not require these (it is hard to imagine
not needing at least one) the overhead is small.

Keep in mind, contrary to your statements below, the interface does not
specify that XML or any media is used just that properties are exposed as
name/value pairs. This is the commonality that should be defined at the
Embedlet interface or a separate 'PropertyExposer' interface (I named it
Persistent originally which may have caused some of the confusion). The
differences between persistence, management and configuration should be
controlled by the container and its services.

To address your concern about JMX support, I am familiar with the spec
(probably not in the detail you are) and the one area that would not be
handled by a PropertyExposer at the Embedlet level would be a notifier. This
would be handled by a generic notifier Embedlet that gets 'wired' to the
output of any Embedlet's event and relays the notification to the JMX
service.


>
> Of course, Property setting/getting looks similar....that's a
> pretty basic requirement.  And a
> SOAP/RCP based XML encoding (based on Web Services standards and
> code generators like
> Apache Axis) would look virtually identical.
>
> But keep in mind that Persistence should not be tied to a
> particular encoding format (like XML).
> The interface should be generic enough to support pluggable
> storage/retrieval handlers for any
> object.  XML would typically be most useful if the storage was
> going to be streamed over a network
> connection.  Internal storage (flash) should probably be in some
> other native object format (for
> efficiency of processing and memory utilization).
>
> > Both require an Object to Property(ies) interface.
>
> Some forms of persistence (saving an actual object instance to
> Flash) many not require this.
>
> > Both require an XML vocabulary that maps objects (or parts of
> objects) to
> > XML.
>
> Not always.  We're trying to avoid as much internal use and
> parsing of XML as possible since the
> overheads can get way too high for constrained devices.  Most
> PICs running uVM won't have
> enough RAM to hold the parsing stack.
>
> > In the case of Management the media is XML over TCP/IP (HTTP).
> In the case
> > of persistence the media is varied and will require separate services to
> > provide the 'EmbedletProperties' implementation. The interfaces ensure
> > that:
>
> Have you read the JMX spec?  It provides for much more than just
> property getter/setters.  It
> supports arbitrary method invocation, notifications (events),
> timers, monitors and such.
> Persistence does not need all of those features, which is why I
> say they should be distinct services
> with their own API designs.  If there is some overlap and we can
> make the API's look similar for
> that overlap (or even identical) then that would be useful from a
> user learning curve perspective,
> but it's not strictly necessary.
>
> >  The Embedlet does'nt care where its properties are sent to or
> come from.
>
> No it doesn't and shouldn't.  That is basic interface
> encapsulation, and you're preaching to the
> converted! ;-)
>
> However, things like dynamic reconfig need to be handled through
> the lifecycle process....some
> values in a config will not be changeable without re-initializing
> the Embedlet.
>
> >  The 'EmbedletProperties' implementation does'nt care which
> Embedlet it is
> > populating.
>
> But the EmbedletProperties approach does not address the other
> Management features (arbitrary
> method invocation, notifications (events), timers, monitors and
> such).  It also does not address the
> need for a more generic persistence service, which can save
> objects other than Embedlets.  In
> fact, in most cases, I think that applications will not have a
> need to save an Embedlet in persistent
> storage,  but rather some object that the Embedlet may use.  For
> instance, a Config Object (or
> multiple versions from your scenario on dynamic reconfig) could
> be Persistable, even if the
> Embedlet that uses it is not. Persistence can be implemented
> through a JavaBeans properties-
> based approach, but that is not the only way to do it (and may
> turn out not to be the best way in all
> circumstances...eg. storage to flash).
>
> > That is the hallmark of a good de-coupled design.
>
> Persistence deals with the storage and retrieval of data
> (probably objects that implement a
> Persistable interface).  Management primarily deals with
> configuration and monitoring of
> "Manageable" objects (which could be Embedlets, JAPL device
> drivers, Communications Adapters,
> the Container itself and the Services the container provides).
>
> They are radically different in their purpose and usage, and thus
> I believe should be independent of
> each other (for the most part).
>
> Granted that in some circumstances (specifically the dynamic
> config scenario you outlined) the
> Management Service may need to be used to reconfig a running
> Embedlet using a stored config.
> Here's a potential scenario:
>
> You need to the reconfig the Embedlet where the new config that
> is one that is typically put
> together using the Wiring tool, that is, part of the normal
> Container initialization config info that is
> passed to an Embedlet during the startup phase of the lifecycle.
> In this scenario the Embedlet
> might externally expose a reconfig method (through the Management
> Service) something like this
> (only an example):
>
> boolean reconfig( String pconfigID ) {
>
>    try {
>       PersistenceService	ps		= getService(
> EMBEDLET_PERSISTENCE_SERVICE );
>       LifecycleService     	ls		= getService(
> EMBEDLET_LIFECYCLE_SERVICE );
>       EmbedletConfig      	newConfig	= ps.retrieve(
> configID, ConfigObject.class() );
>
>       ls.reInitialize( this, newConfig );
>    }
>    catch( EmbedletServiceNotImplementedException e ) {
>       // Oh Shit...no Optional Persistence Service (note:
> Lifecycle is a Core/Mandatory Service)
>    }
> }
>
> To get the Embedlet to dynamically reconfigure itself, you would
> use a Managment tool (possibly
> JMX-based) that would let you remotely invoke the reconfig()
> method call with a string that denotes
> what saved config should be used when restarting the Embedlet.
> Not all Embedlets will need this
> capability, and those that don't would simply not implement nor
> expose such a method.  The value
> of this approach is that it keeps Management, Persistence and
> Lifecycle services distinct from
> each other, and allows for a lot of flexibility in how to handle
> the reconfig issue. Note how the
> neither the Embedlet nor the Managment service knows where or how
> the new config is stored...it
> might actually end up being downloaded over a network connection
> by the Persistence Service.
>
> If all you need to do is to change a specific value in the
> Embedlet and it doesn't need to go through
> the lifecycle re-initialization process, then you could just use
> the JMX Management facilities to
> change a property that was externally exposed.  Persistence
> doesn't even come into it, since
> nothing needed storing or retrieval. Lifecycle is not involved
> since you don't need to re-initialize and
> restart the Embedlet.
>
> Hopefully this helps to illustrate where my warped mind is heading....
>
>
>
>
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> 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
>