XML as an alternative to Object Serialization?

[Dmitri Kondratiev]

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 :

http://www.camb.opengroup.org/cgi-bin/mailbox.pl

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 :

           X-Object\   /Z-Object
                    \ /
Y-Object ---<Meta-Object (XML)>---X-Object 
                    / \
           Z-Object/   \Y-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



-----------------
Dmitri Kondratiev
dima at paragraph.com
102401.2457 at compuserve.com
http://www.geocities.com/SiliconValley/Lakes/3767/
tel: 07-095-464-9241


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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)