XML Application Servers

Steven Livingstone, ITS, SENM steven.livingstone at scotent.co.uk
Fri Nov 26 15:52:37 GMT 1999

An ISAPI extension is probably best if your server/application is devoted to
XML, as your clearly is (yes?).

Can you perform business validation etc in this way? As in a typical n-teir
So you want to write XML pages back for an application, after validating
business rules and getting the resultsd from the database.

If so, does the extension or your COM objects dynamically create the XML
document from the result set?
Do you have a URL for the extension?

Sounds good !


PS. You can get round the XML problem in ASP, if you map the .xml extension
to the asp.dll. I have done this (for .xsl) to dynamically create .xsl
stylesheets based on Site Server personalization attributes !

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

Professional Site Server 3, Wrox Press
Professional Site Server 3.0 Commerce Edition, Wrox Press

> -----Original Message-----
> From:	Didier PH Martin [SMTP:martind at netfolder.com]
> Sent:	26 November 1999 14:19
> To:	Steven Livingstone, ITS, SENM; xml-dev at ic.ac.uk
> Subject:	RE: XML Application Servers
> 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)

More information about the Xml-dev mailing list