[Embedlets-dev] Re: Serialization
Status: Alpha
Brought to you by:
tkosan
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:39:28
|
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
|