[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML Application Servers

• From: "Steven Livingstone, ITS, SENM" <steven.livingstone@s...>
• To: Didier PH Martin <martind@n...>, xml-dev@i...
• Date: Fri, 26 Nov 1999 15:35:48 -0000

Sure,it is http://www.softwareag.com/tamino

Supposed to be one of the best !?

cheers
steven

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@n...]
> Sent:	26 November 1999 14:19
> To:	Steven Livingstone, ITS, SENM; xml-dev@i...
> 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@n...
> http://www.netfolder.com
> 
> Cheers
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@i... the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo@i... the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@i...)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: [UseableServerSML+i18n] Preliminary EBNF for UseableServerSML+i18n
• Next by Date: RE: XML Application Servers
• Previous by thread: Re: XML Application Servers
• Next by thread: RE: XML Application Servers
• Index(es):
  • Date
  • Thread