OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML Application Servers

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven Livingstone, ITS, SENM" <steven.livingstone@scotent.co.uk>
  • To: martind@netfolder.com, xml-dev@ic.ac.uk
  • Date: Fri, 26 Nov 1999 15:48:26 -0000

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
application.
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 !

cheers,
steven

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
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
Professional Site Server 3.0 Commerce Edition, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505


> -----Original Message-----
> From:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	26 November 1999 14:19
> To:	Steven Livingstone, ITS, SENM; xml-dev@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@netfolder.com
> http://www.netfolder.com
> 
> Cheers

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS