Regulating the XML Marketplace

[N. y M. Zito]

1. XML and appls interconection

The point mentioned by Gerard Berthet is, in my opinion, the biggest
inmediate achievable  benefit of XML. That is: interoperation between
appls. As an appls. developer I have usually faced the problems he mentioned. 

I work in Laboratory Info. Systems, where we usually have to parse ASCII
reports generated by lab. instruments to transfer the extracted data to the
lab system. There are hundreds of instrument providers (and instruments),
each with their own formats. This is an area where using XML may be of
incredible benefit. It would be very simple for the instrument providers to
just generate one additional XML report.

One remaining problem is that, if you need to connect two appls from
different providers, you still have to deal with the different data models
in each appl. This requires the transformation of one XML doc (generated
with appl #1) to other XML doc (readable by appl #2). I don't clearly see
how this can be solved in a standard way: Can this be done using XSL ? Is
there some other way of doing it ? 

2. XML Migration paths

I think the point we should raise is:

How can be begin using XML and obtaining benefits from it's use in appls
development, while XML and it's associated technologies are still evolving
and there are still a lot of open questions (namespaces, XML Data, Xlink,
compounding documents, etc...) ? 

What can be use NOW, and what will have to wait till it's mature ?

I here briefly describe the lines we have taken in this direction (maybe
this experience is of some help for anyone else). This may or may not be a
solution, as this is an open question (even for myself):
 
Aside from Web development, we have found XML to be of help in developing
client-server appls (not Web appls). Request messages are XML docs, as well
as the response messages, and so XML is used as a way of implementing a RPC
or distributed objects mechanism. I have seen a Note to the W3C where this
has been already proposed.

Although some can say that CORBA has already solved this problem,
developing in CORBA (or DCOM) is much more difficult and error prone (using
the C++ mappings). Previously we were using CORBA, and I can testify this.
We have been using XML (and our own little parsers) in our appls to support
this type of client-server interaction with success. We have observed
little performance penalties compared to using CORBA.

Some benefits we observed: Client and server can run in different
platforms, no CORBA runtimes or fees (just a little TCP/IP library for
managing the client-server connections), much easier installation and
deployment, VERY lightweight, much easier development (and less training
for new developers), very simple to change the server interface definitions.

Although CORBA should have solved this problem, developing in CORBA (or
DCOM) is much more difficult and error prone (using the C++ mappings).
previously we were using CORBA, and I can testify this. We have been using
XML (and our own little parsers) in our appls to support this type of
client-server interaction with success. 

This can be viewed as a specialized browser, one that implements the user
interface our appls require, without the performance penalty of supporting
complex user interface development in a browser with the current tools
(Java and JavaScript). I can say that developing such a client application
that interacts with a XML server in this way is really not difficult.

When the Web browsers (in some future time) are ready for true XML-XSL
support and higher degrees of interaction, it will be very easy to migrate
our current appls to them (only the client side needs to be migrated, the
appl. servers should remain nearly untouched: they already generate XML
responses). 

The big point here is that we can begin using XML and getting it's benefits
NOW, while we let XML and it's associated technologies mature and define
clear ways to arquitecture our appls. 

Hope this can help.








Mario A. Zito

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)