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

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
>
> >> 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.
>
> In our container, we originally used Java serialization for
> persistance.  But
> soon found out that it was difficult to make sure that
> SerialVersionUIDs were
> managed correctly.  We had create a properties based management
> system, and
> that worked well (via introspection, so adding a new property was
> just the
> business of adding a setter and getter).  When we started hating
> serialization, it was trivial to just write and read properties via the
> Properties.load() and Properties.save() methods, and we have never looked
> back.  Now, we also include in our container definition the ability of a
> module to include a GUI.  So, there is a method that returns a
> factory for
> getting the GUI.  This factory falls in line with the Jini
> ServiceUI, and this
> allows our status monitoring and management app to swallow the containers
> management objects and provide them inside of its GUI too.  So,
> if you just
> have our broker, you can use its management tool.  But, if you have the
> monitoring app, you can use it for management, and the broker is not the
> wiser...
>
> Property set/get based management is a fine starting point.  Adding a GUI
> factory mechanism via the JMX client interface or remoting specs
> would be the
> next step...
>
> -----
> gr...@cy...  (Cyte Technologies Inc)
>
>

I agree completely. The issue with J2ME and other constrained VM's is that
they do not all support introspection or the invoke() method so there is a
need to use a streamlined substitute based on the Properties concept. The
other issue is that you do not always want to expose every public method to
the outside-outside world.

The solution that OopScope provides is a 'Properties' interface that is
implemented by specific media services (XML, database, binary etc). The
component (Embedlet) reconstructs itself after instantiation by the same
general method, coincidentally, that you use: getProperty calls to a
Properties 'bag'. The sequence of events are:

1. The Properties service reads the input media (eg. XML) and encounters an
object.
2. The Properties service instantiates the object based on the 'class'
attribute on the stream. The objects' Class is assumed to be preloaded in
the installation, thus avoiding byte code streaming.
3. The object implements the PropertyAccess interface (orginally called
Persistent), which defines the readProperties(Properties p) method.
4. The component reads its properties using getProperty(String Name) methods
of the Properties object. Components can access other objects by reference
using getObjectProperty(objectName).
5. The container manages the life cycle processes by informing each
component of its current state: create (implied in constructor), initialize,
start, stop, terminate.

The 'serialization' process uses the reverse writeProperties method.

I have used this technique sucessfully in a number of Enterprise (Financial
Data Warehouse) and embedded projects, both for long term persistence,
configuration, temporal storage (JMS message based), data transform services
and even tranforms between languages (Java<->VB6).

As I have stated before EJB Entity bean persistence to a DataSource is an
example of a 'sucessful' container service that uses a coded variation of
object serialization. It does not use binary serialization but rather a
mapping of object properties to RDBMS (JDBC) attributes.

I have used the above media 'Properties' technique to map an Entity bean to
an RDBMS persistent store,  an XML stream to a front-end JSP and a mirrored
VB6 object for a client GUI application, all with the same 'PropertyAccess'
interface code.

I understand that you, Gregg, have had the same success.

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