[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Design Issues in XSLT


Subject: RE: [xsl] Design Issues in XSLT
From: "Emmanuel Oviosa" <Emmanuel.Oviosa@xxxxxxxxx>
Date: Wed, 10 Jul 2002 17:08:44 +0100

I am forever gratefull Kirk. Cheers for the clarification and sensible
hints, I doubt if anyone is a master in anything because you just cant know
it all especially in this IT business.

-----Original Message-----
From: Kirk Allen Evans [mailto:kaevans@xxxxxxxxxxxxx]
Sent: 10 July 2002 16:36
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Design Issues in XSLT


> > Is XSLT matured enough for the development of a multi-tier
> > web application that will be used in many regions across the
> > country by 100s of users?. Developing in XML, XSL, COM+, VB,
> > SQL 2000, JavaScript, ASP.

The easy answer would be, "yes, it is mature... XSLT is more maintainable...
application state is fine for single-server architectures...don't use MTS,
use COM+, and you shouldn't call COM components from XSLT without a bonafide
reason, necessitating ASP...DOMDocument40 does not marshall, necessitating
the serialized string representation for performance."

An even shorter answer is that Mike's answer was spot-on:  it depends on
your experience.

The longer answer will not answer your questions at all, just lead you to
more resources that are much more applicable to your questions.
Unfortunately, this is not the proper forum for 90% of your questions.

There are LOTS of real-world sites that support thousands of concurrent
users using the techologies you listed, Microsoft.com and NASDAQ.com,
notably.  Microsoft offers their IBuySpy portal example as well as the Fitch
And Mather stocks example for free download from Microsoft.com, both
incorporate these technologies as well.

There is no out-of-the-box solution for developing scalable solutions, it
depends on the experience level of your developers.  It takes a lot of
forethought and understanding to design a large scale system.  Simply
dropping a component in COM+ does not make it scalable, just like
introducing XSLT into your solution does not necessarily improve your
solution.  XSLT may or may not improve your solution, it depends on what you
are trying to do with it.

Questioning the maturity of XSL is a red herring, because it sounds like you
really want less information on the MSXML parser and its support for XSLT,
but you want more on COM+ and designing scalable architectures.  ASP is a
mature technology and is used on many large-scale sites (NASDAQ.com and
Microsoft.com, notably).  But it depends on what you are doing with the
technology and how well you understand it.  If you really want to know more
about MSXML, its support for XSLT, and performance of different approaches,
then see TopXML.com.

> > Does anyone know for sure that XML/XSLT approach would be
> > faster, scalable and more maintainable than the ASP/ADO
> > approach, is there any bench mark statistics?.

There is no comparable benchmark because the technologies are not
comparable.  XSLT provides no means of accessing databases, just like ADO
doesn't provide a transformation syntax.  If your question involves the
performance of using looping logic to display data versus using XSLT to
transform XML, then you have to also involve ADO best practices as well as
MSXML-specific best practices.  Both of these topics are well documented on
MSDN, and both require experience and a lot of research.  There are
discussions in MSDN regarding looping logic versus using XSLT, more notably
there are discussions on using looping logic with MSXML COM objects versus
using XSLT.  Search MSDN for Chris Lovett's MSXML performance articles.
Kurt Cagle did some benchmarking on specific techniques using MSXML 3.0 and
compared them to MSXML 4.0 in XML Magazine (http://www.xml-mag.com), but I
don't know of any ADO versus XSLT benchmarks because the technologies are
radically different.

> > Caching xsl templates into application variable seems to
> > improve performance but is there any serious issues on the
> > use of application variables like we have in sessions and cookies?.

Depends on your architecture.  Again, experience would immediately invoke
the term "web farm" into your mind when application variables are
questioned.  TopXML hosts a vbxml mailing list (vbxml@xxxxxxxxxxxxxxx) that
would be a much better candidate for this type of discussion  Another
resource is the microsoft.public.xml and microsoft.public.xsl mailing lists
(which are monitored by Microsoft developers and support engineers).

> > Should I be calling my MTS VB components in the XSLT, do I
> > even need ASP?.

There are a lot of discussions on the web regarding using ASP over compiled
components and understanding the COM context switches required that can
impact this decision.  But this is not appropriate for an XSL list.  A great
resource for understanding the tradeoffs is VB2TheMax.com.

> > Is there any overhead in passing MSXML DOM object accross com
> > boundaries, should I be passing xmldom.xml instead?

A whole can of worms here... marshalling across COM boundaries is a long
subject that is not appropriate for an XSLT list.  May I suggest:

	TopXML's vbxml mailing list (vbxml@xxxxxxxxxxxxxxx)
	VB2TheMax.com's article bank
	a microsoft.public.* newsgroup that focuses on COM development
	VBCOM list at http://discuss.develop.com

There are also a LOT of books on COM+ development using VB... notably Ted
Pattison's VB6 Distributed book.

Kirk Allen Evans
http://www.xmlandasp.net
"XML and ASP.NET", New Riders Publishing
http://www.amazon.com/exec/obidos/ASIN/073571200X



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


The contents of this email and any attachments may be privileged or confidential, for the exclusive use of the intended recipient(s) only and may not be disclosed or used in any way other than by the addressee(s). If you have  received this email in error please advise the sender and delete from your system.

Integrated Solutions Consultants Ltd are unable to guarantee the security of email content outside of our own systems where all emails and content are treated in accordance with the Regulation of Investigatory Powers Act 2000.

Further information about Integrated Solutions Consultants Ltd is available at http://www.isc.co.uk or mailto:info@xxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords