[Embedlets-dev] Re: [Arch] Serialization

[Ted K. <tk...@ya...>]

Andrzej,

>How do you handle hardware intialization at startup?

The same way that serialized objects that have references to non-serializeable
objects like Threads are properly de-serialized, by using custom serialization.
 With custom serialization the developer gets to define whatever code is
necessary to properly reconstitute the object when it is deserialized.  If it
is a JAPL object that is getting deserialized then the hardware is called with
the proper initialization parameters in the custom deserialization code.



> What about other initializations (Container level....like opening 
> communications connections/streams, ensuring that the component 
> lifecycles are properly managed)?  

Again, custom serialization can make sure that all of the things that are not
serializeable during 'freeze' time, like live communications connections and
Threads, can all be reconnected at 'thaw' time.


> Your approach would almost certainly force the Container itself to be 
> serialized, which is going to be problematic, since the object graph will
> likely 
> have references to all sorts of objects like Container Services, Adapters,
> JAPL 
> device drivers (all of which have initialization/lifecycle requirements and
> likely 
> would not be serializable without a lot of extra, unecessary work, if it even
> was 
> possible).

Custom serialization should fix all of these things with or without serializing
the container. 



> Trying to handle the 
> complexity of mixing and matching config/initialization/lifecycle AND 
> serialization state usually makes the serialization approach much less 
> attractive.

With a serialized application, the components, JAPL peripherals, services, etc.
 have already all been put into the 'running' lifecycle state (or other desired
states) and all of their configurations have already been set using an
inspector or perhaps an easier to use customizer.  Most of the complexity has
already been handled by the application assembler in a PnP instant feedback
environment.  So all of the config, initialization and lifecycle state
information is then serialized, transfered to the target device and then
deserialized.  I guess I am just going to have to see all of this stuff fail
like you say it will with my own eyes in order to believe it.

It is just so difficult for me to take on faith that serialization does not
make sense when the new BeanBuilder application:

http://java.sun.com/products/javabeans/beanbuilder/index.html

leverages the new Long Term Persistence API to do all of the things that you
say can't be done.

You must understand that I agree that serialization might not work for our
application, but I would be much more comfortable reaching this conclusion only
after actually trying it and seeing exactly how and why it failed.  At least
this should be good for an article or two. ;-)



> There is still the issue of keeping class files and serialized objects 
> synchronized, which always ends up being a real PITA in a real world 
> implementation.

The Long Term Persistence API, in combination with a serialized object's SUID
class version identifier, fixes this problem.  Here is a section from one of
the early LTP papers that talks about this:

<paper>
http://java.sun.com/products/jfc/tsc/articles/persistence/index.html

A Note on Marshaling vs. Archiving
There are two common approaches to the problem of persisting graphs of objects:

    * Recording all state in an object graph, including non-public state.
    * Recording all state that can be reconstituted using the public APIs of
the objects in the graph.

The simplest scheme taking the first approach requires the inclusion of all the
classes that define the objects -- which is too expensive. The practical
alternative, which is to refrain from serializing the byte codes that define
the classes themselves, is workable between identical implementations of the
same libraries. The serialization framework in 1.1 implements this and is
therefore the method of choice for sending faithful copies of an object graph
between two similarly configured VMs.

The second approach cannot produce as faithful a copy of the original objects
as the first but can store the state of the graph in such a way that any
API-compatible implementation of the classes involved will be sufficient to
reconstitute it. Since APIs are so much more stable than their private
implementations, this single step virtually solves the versioning issues for
most practical purposes. As importantly, from an applet perspective, the
behavior of the constructors residing on the client machine can be leveraged,
often dramatically reducing the size of the files that need to be transferred.

Luckily, although the serialization APIs in JDK 1.1 provided direct support for
only the first task, they used a series of interfaces to ensure that support
for the second operation could easily be accommodated by the same framework. We
use this framework to implement the ObjectOutput and ObjectInput interfaces and
house a complimentary scheme which is designed to solve the long term
persistence problem for user interfaces of JavaBeans. 

</paper>



> Please name one accepted/widely deployed Container (eg. Tomcat, Jetty, 
> JBoss, Weblogic, Websphere, Avalon, etc...) implementation that uses 
> serialization for it's component "packaging/deployment" strategy? 

Embedlets have some attributes that are much closer to JavaBeans than any of
these other technologies have so I do not know how one can use them to show
that serialization for packaging and deployment purposes is a defective
technique.  First off Servlets are not a component technology so I do not think
that they can be used for comparison here.  As for EJBs and Avalon components,
point me to where I can see object graphs of 10 to 100 EJBs or Avalon
components wired together in a JavaBeans-like configuration and I will
certainly take a look at it.




> Actually...there is one implementation that relied on such a serialized
> object 
> graph approach to saving/packaging an application, and that was Smalltalk.  
> (I'll let you research the massive 
> amount of literature and links that deal with this problem in the Smalltalk
> world 
> if you are interested).

I will definitely research SmallTalk further because I was not aware that they
tried such a strategy.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com