[Embedlets-dev] Re: Serialization

[Andrzej J. T. <an...@ch...>]

Ted said:

> Well, you know, I thought it was an elegant approach.  A serialized object
> graph only contains each object's state information (just instance
> variable settings are included, no code is sent with serialization).  What
> can be simpler than having a target system read what the state of each
> object's instance variables are and then reconstituting it based on this
> information?

How do you handle hardware intialization at startup?  What about other 
initializations (Container level....like opening communications 
connections/streams, ensuring that the component lifecycles are properly 
managed)?  

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).  If it's just a bunch of very simple components that get serialized, it 
can work(as with GUI components where JavaBeans evolved from), but in a 
container-based system, this becomes nigh impossible.  Trying to handle the 
complexity of mixing and matching config/initialization/lifecycle AND 
serialization state usually makes the serialization approach much less 
attractive.

> The new XML based Long Term Persistence API has completely
> fixed this problem and now Sun strongly recommends using the LTP API for
> saving object graphs of any kind for any purpose for any length of time. 

That only makes sense for object graphs that are inherently static in nature, 
and that have temporal dependencies (eg. initialization, lifecycle, etc.).

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.

> Perhaps James and I are missing something here but since the Long Term
> Persistence API has fixed the versioning problem I do not see the downside
> of using object serialization as a lightweight method for getting an
> application into an Embedlet Container?

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?  There are 
none that I am aware of (at least not successful ones).  Sure, some of these 
containers use serialization as a short term persistence strategy (typically for 
caching/paging activities, which can be a good use for this technique), but 
every one uses an XML config approach to the packaging/config runtime 
config/startup process due to the issues I have mentioned earlier.

Actually...there is one implementation that relied on such a serialized object 
graph approach to saving/packaging an application, and that was Smalltalk.  
Most Smalltalk implementations saved a complete "image" of the application 
(effectively the same thing as serialization under the covers).  This approach 
was fraught with issues in the real world (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).  It failed as a practical application packaging technology.

It was tried.  It did not work (or at least it caused many serious problems that 
caused the approach to go out of favour).  It's against all current Container 
design best practices.

My vote: serialization as a component packaging technology for Embedlets: 

    -666 (forget this wimpy +1/0/-1 stuff <grins>).

The devil is in the details....and he's gonna getcha if you go down this road. ;-)




Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com