XML Application Servers

[Didier PH Martin]

Hi Steven,

Steven said:
Anyone building this kind of thing on a IIS/ASP/COM  based technology?

I am interested in the different ways people doing this have managed to
integrated this technology with the XML technologies.

Also, anyone using Tamino XML Server? What experiences have you had?

Didier reply:
We are currently building this XML server as an IIS extension (later on as
an extension to Apache). We obviously do not use the ASP technology which is
reducing the performance. The goal of the IIS extension is:
a) check the client's browser version, if it is IE 5 then send the XML
document as is. Otherwise do the transformation server with either a XSL or
DSSSL engine.
b) the XML document may not be associated to a style sheet, in this case,
the server look for the document type in a table and associate a style sheet
to the document.

Actually, it works for outgoing process only.

If you use ASP technology instead of an XML IIS extension, then you are
facing:
a) the overhead of the ASP interpretation
b) the overhead of the script language interpretation (ex: javaScipt or
VBScript used a script engines by ASP)

In fact, by using ASP technologies you have two interpretation level that
are superfluous to the process of
a) sending an XML document to a XML browser
b) associating a style sheet to an XML document before sending it to the
browser
c) doing style sheet processing on the server is there is a need to do so.

We came to that conclusion after having created, for our needs, an XML
server with ASP, the MSXML XML/XSL engine and VBScript as the script
language instantiating the MSXML engine to perform the transformation job.

So, at first we used IIS, ASP and COM technologies but came to the
conclusion that ASP was causing superfluous processing. So we moved to IIS,
Talva XML IIS extension and COM to improve the performance and remove the
unnecessary bottlenecks. Also, the secondary advantage is that now, the
server respond with this kind of URL http://www.mydomain.com/mydocument.xml
(of course, MyDomain and Mydocument are imaginary names). This is an
improvement on our previous URLS which where
http://www.mydomain.com/xml.asp?file="mydir/myfile.xml".

The Talva XML IIS extension is written in C++ and compiled with optimisation
for Pentium to reach a maximum performance. We are now, integrating the
capability to use Java processors for XSL processing. Some Java XSL
processor are more up to date and conform to the latest W3C recommendations
that is MSXML. This provides more freedom of choice for the XSLT processor.
Among the actual Java XSLT providers, you have: IBM, oracle, Indev and James
Clark. The VM is mounted at the same time as the IIS server is mounted and
then the overhead of loading the VM for each processing is removed. This is
not a servlet though. It is a XML engine aware of the XSLT processor
packaged as COM objects or as Java classes and knowing how to interface with
each one.

A note about the Java processor:
As soon as an XML document has been processed, the Java classes are compiled
into native machine code by the Just in time compiler. Thus, after the first
usage of the Java XSLT engine, this latter is compiled and more efficient.
We used the Microsoft VM for its exeptional JIT processing and overall
performance. Also, because it is, in fact a COM component.

Cheers
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com

Cheers


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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)