A Java-centric view on XML as RPC wire format

Late-breaking news (2001-04-07) - Koala Object Markup Language (KOML) appears to do what this page advocates except for supporting custom filters based on a schema.

XML can be used as a data storage format or data transmission format (a.k.a. "wire format"), whether or not encapsulated in a formal RPC mechanism.

So far, all XML use I'm aware of could be summarized thus:

An XML format is specified without any strong bias toward ease of use with Java. Java code, like code in any language, has to work with this externally-imposed XML format using a parser.

The proposal here is:

Rather than forcing all languages to suffer equally with an externally-imposed XML format that must be parsed by hand, use an XML format that is automatically generated and parsed in at least one modern language (Java). Other languages can parse by hand or can implement a similar automatic mechanism.

(This proposal is quite different from XML-RPC.)

A rough spec

There are 3 standard, nonXML wire formats of interest to Java
XML is a class of languages.  Each of the above wire formats can be faithfully represented in a new XML subclass language: Each of these XML subclass languages is in turn a class of languages, each of whose subclass languages is determined by the specific Java classes used in an application.

The XJSF format encodes Java class names as XML tags and provides for all Java primitive types à la XML-RPC. Java FilterInputStream and FilterOutputStream subclasses are provided so that these new XML languages are nearly as easy to use in Java as are the wire formats they represent.  These 6 filters are provided:

XJSFOutputStream example:
Instead of this:
FileOutputStream out = new FileOutputStream("theTime");
ObjectOutputStream s = new ObjectOutputStream(out);
s.writeObject(new Date());

You do this:

FileOutputStream out = new FileOutputStream("theTime");
XJSFOutputFilter xjos = new XJSFOutputFilter(out);
ObjectOutputStream s = new ObjectOutputStream(xjos);
s.writeObject(new Date());

Custom filters for externally-imposed XML formats

You can write a pair of custom filters to make an externally-imposed XML format as painless as possible in Java. In the second example above, you would replace XJSFOutputFilter with OurCustomOutputFilter. Presumably such a filter would use something like the emerging XML Schema standard.

The point of the proposal here is that although that solution would be nice, the ultimate in transparency in Java is to be able to use a single, off-the-shelf pair of filters. Still, the custom filter approach has the attraction that it leverages the work that is already done for you by Java's serialization mechansm: the transient keyword, the built-in methods for serialization, the marker interfaces, the version tagging of serialized data to prevent mismatches with incompatible code, etc.

JSF as a binary XML

The above approach suggests another tack. What if we treated JSF as a kind of binary XML? Instead of filtering it into XML so other languages like C++ can parse it, what if we implemented a DOM parser for JSF?  A C++ programmer comfortable with XML can use this parser and not care whether the actual communication format is XJSF or JSF.  The application can be easily changed to use the XML representation if needed.  This approach saves the performance cost at both ends of filtering to-from human-readable form (XML).  And if a programmer ever needs to look at the JSF data, they can simply use a tool that filters between XJSF and JSF to look at the data in XML format.

http://Yost.com/Computers/java/xjsf.html - this page
2001-01-23 Created
2001-03-16 Published here
2001-04-07 Modified