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

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

>Most PICs running uVM won't have enough RAM to hold the parsing stack.

If well designed ie XML JAXP style and the XML dictionary is lean enough to
handle 'on the fly' then I could probably handle XML. Its a bit like the way
I handle TCP/IP - I do the whole thing on the fly - in fact most of the
packet has been sent even before it is completely received.

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

Ted's original vision was to have the Embedlet container be able to accept a
serialised stream representing the instantiated application embedlet
heirachy all in one go. I quite like it, the container only needs to be able
deserialise, the task of serialisation is done by the management tool and
all you need is some communications link to 'upload' the serialised embedlet
application. It is certainly quite an elegant approach.


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: Sunday, February 09, 2003 5:57 AM
> To: emb...@li...
> Subject: [Embedlets-dev] [Arch] Persistence vs. Management
>
>
> 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.
>
> 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		=
Service( 
> 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 Ser
vice)
>    }
> }
>
> 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
>
>