Lists Home |
Date Index |
- From: "Didier PH Martin" <email@example.com>
- To: "Steven Livingstone, ITS, SENM" <firstname.lastname@example.org>,<email@example.com>
- Date: Fri, 26 Nov 1999 09:19:27 -0500
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?
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
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
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
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
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
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.
Didier PH Martin
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)