RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

Michael Brennan wrote :

<snip/>

>Developers still need to write business logic, and they need to get the
>information from the XML document into data structures better suited to
>supporting that business logic. All of the APIs in the XML world are
>unsuited for this. They force the developer to mold their 
>logic to fit an
>API that is only suited for modeling a document structure, rather than
>letting the developer mold their data structures and APIs to align with
>business concepts and processes.

This is maybe a somewhat bizarre question, but what exactly prevents
somebody from writing business logic that operates on a document structure ?
If the answer is "a document model isn't usable as a business data model"
then the whole XML industry in trouble ; if the answer is "XML APIs just
don't help us doing this", this is a problem that can be solved.

I have been developing for my company a kind of compiler that enables us to
embed XPath expression in Java code. We can now access any random piece of
data within a document as easily as we would have done with an object model,
e.g. we can write things like invoice/line[5]/quantity in our Java code
instead of invoice.getLine(5).getQuantity().

We then developed a model in which business processes where expressed in XML
documents, possibly containing Java code fragments, that are compiled into
Java code, then into bytecode by a standard Java compiler. The compilation
is dynamic, and is done for performance purpose. If a scripting language
seamlessly integrating XPath expressions existed, we could have used it.

At the end, we get a dynamic processing language that can easily manipulate
dynamic XML data in a business-oriented way (we could not do the same thing
using XSLT, for example). The "dynamic" part here is important : it means
that if the data changes, we are able to promptly adapt the processes. 

Investigations on this approach lead us to the following reflexions / issues
/ questions :

1) We have been using this framework for one year and a half to implement
and consume web services. In fact, we first implemented some in january
2000, using a proprietary SOAP-like protocol (XML over HTTP), implemented
both in Java and Microsoft technologies. As an example of benefits of this
approach, we managed to integrate our 100% Java server running on Solaris
with 100% Microsoft code accessing to an Exchange server running on Windows
NT. This is something that would have been very difficult and expensive to
implement using CORBA, DCOM or RPCs.

2) The use of an intermediate compiler enables us to insulate our developers
from underlying XML APIs. We can therefore change of DOM implementation,
selecting for example JDOM, or dom4j, or a custom one. Likewise, we can
choose the XPath API we want, etc. This allows us to always select the most
effective library. This is very important because most XML technologies
implementations have yet to mature, both on the compliance level and on the
performance level.

3) We don't have to worry about object model mappings to/from databases or
XML ; all data is represented as XML documents. This is good, because it
saves a lot of code writing, and increases our flexibility. The bad side is
that non-textual data (e.g. numeric values) are not handled easily. But
that's something we plan to solve by implementing our own DOM.

4) This separation between data and processes is totally against most
object-oriented practices. This is somewhat considered as "bad", especially
in France where people are very strict about it :). But in fact if you take
a close look at most EJB architecture, you'll discover that processes (in
Session EJBs) are usually separated from data (in Entity EJBs), and that
implementing business methods in data object is not an easy task (not even
speaking about evolution of the model).

5) Our greatest current problem is about schemas. As I've wrote previously
on this list, our approach raises a dire need of a simple schema language,
simple enough so that developers can write and use schemas without having to
read thousands of pages of specifications. We are currently investigating
languages such as RELAX NG, Schematron, Examplotron or a custom language we
named RESCALE to solve this problem.

Regards,

Nicolas Lehuen
Responsable R&D / Head of R&D
UBICCO, the Multi-Access Software Vendor
http://www.ubicco.com/
mailto:nicolas.lehuen@ubicco.com
Phone : +33 1 53 24 99 79
Fax   : +33 1 53 24 17 23
Mobile: +33 6 61 90 76 40