XML as an alternative to Object Serialization?
dima at paragraph.com
Fri Jan 16 00:17:11 GMT 1998
At 17:59 13.01.98 -0500, Tyler Baker wrote:
>Now my idea rests upon the power of Reflection in JDK 1.1+. I have had
>experience in using Reflection to auto-map Java class files and
>interfaces to a relational database by auto-generating SQL create
>scripts, and I had the idea that XML could be used as an alternative to
>Object Serialization for small to medium sized content. XML of course
>is much fatter as a persistence framework than something like Object
>Serialization but for web browsers and the web in general, embedding
>this info via XML in a page may make more sense in some circumstances,
>especially since you would get the added boon of your Java Object being
>cached on the users computer.
It may be interesting for you to check the JSXML work that Bill laForge at
OpenGroup is doing (being able to serialize a Bean to XML) at :
As for myself, after a lot of thinking about Java/XML serialization I found
that I don't see *real* application for it. It seems evident that
(de-)serialization of state in the "native-Java" way is much more efficient
then in Java-->XML-->Java way. So effectiveness is certainly not an issue
here. On the other hand I don't see a single case where Java/XML
serialization may be required in *homogeneous* Java systems. I want to
stress that when saying that Java/XML serialization seems useless, I mean
exactly the case of *homogeneous* Java systems.
To my mind, the whole problem of Java/XML serialization seems to be wrongly
formulated. The idea of component state specification through meta
information has *much wider scope* and *implications* then just Java/XML
serialization. Component serialization in general (not JavaBean only) can be
specified in XML. This makes a lot of sense to me. Having *general* XML
specification for component state will allow different OO languages/tools
interoperate on different platforms and network nodes.
Java->XML->Java serialization will make sense only when *general meta
component state specification* will be defined universally. In other words
general serialization scheme will look something like :
Y-Object ---<Meta-Object (XML)>---X-Object
Where X,Y, and Z are different OO systems with common notion of class/object
as defined by OOP model.
Another interesting issue here is that having component (file, object,
etc..) specification on meta level (XML) will provide for more uniform
run-time service discovery. Here comes component introspecion.
Though component introspection can certainly be done in the "native-Java"
way (java.beans.BeanInfo), the obvious for me advantage of *XML BeanInfo* is
the ability to introspect components described in BeanInfo _markup_ *without
the need to pre-load these components (classes) first*. This means that one
can make decision of component suitability for some task from its markup
only. To make this possible I am working now on BeanInfo markup and
framework for bean introspection from its XML spec.
So my bottom line is :
- Java/XML combination will help a lot for run time service discovery in
dynamic, context-based, component frameworks. (Introspection with XML BeanInfo).
- General markup (based on XML) for the *component state specification* may
be a real break-through for D-O frameworks running across different
platforms (including different OO tools) on network.
All the best,
dima at paragraph.com
102401.2457 at compuserve.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev