XML has become the de facto standard data representation format for the Internet. A new article on TheServerSide presents an overview of XML, then it shows how to: Present XML documents, Generate XML using JSP, Parse XML documents using Simple Access API for XML (SAX) and Document Object Model (DOM), Use SAX and DOM in JSP, Transform XML into other markup languages.
Read Web Application Development with JSP and XML
Part II: JSP with XML in mind
Also read Part I: Fast Track JSP
Feel free to discuss this article here.
IMHO, generating XML from JSP is a waste of time and CPU cycles. The Maverick MVC framework (http://mav.sourceforge.net
) provies a JavaBeans->DOM adapter called "domify" which eliminates the need to generate and parse textual XML. The XSLT processor can work directly from the DOM facade, so in most cases JSP is wholly unnecessary.
I had experience with creating XML both using DOM vs. textual XML for public entertainment website. Using DOM was 3-4 times slower. DOM performance was also 2-3 times worse, especially on pages with heavy (20-50 Kbytes) text nodes. To meet a deadline and performance requirements in our project, we discarded DOM in favor of textual XML.
On the other side, if some design efforts were spent on elaborating classes for each of page component type for producing chunks of DOM XML, the application appearance will be far more pleasant. But performance issues are still there.
"Using DOM was 3-4 times slower."
Slower to produce Java code, I meant.
It seems strange that there was no mention of XML Schema (XSD) in the article. One of the benefits of well-formed and well-defined XML is in its ability to be transformed and manipulated thru a standard set of tools and APIs.
Maybe Part III can address these issues.
I noticed in part II that there was an error in your Stock.xsl sample code. I made an update to your code below
with just minor changes, but I still think you guys did
a great job and got your point across clearly.
<xsl:stylesheet version="1.0" xmlns:xsl=
<body bgcolor="#ffffcc" text="#0000ff">
<table border="2" width="50%">
It's curious that the author mentioned using tag libs in separating logic from presentation, I thought this was purpose of using XSL.
Great concept until implementation time.
We strongly believe that XML and XSL is a good way to go but performances are not there yet to make a fully dynamic web site. We did some performance testing using different approaches (XML + XSLT, XML + XSLTC, XML + SAXON, JSP producing XML to be treated by XSLT, or even JDOM ....) and in every case the performances are very poor compared to a full blown JSP solution using taglibs (like struts). The most inefficient part comes from the persing of the DOM Tree. Using Jmeter and 10 simultaneous users, it took 3 seconds to present a complex (but realistic page: list of products,...) versus 0.025 seconds for a pure JSP + taglib approach. 100% of the CPU was also used when using any combination of XSLT (with 10 users).
I guess that if the web site is pretty much static, a cache taglib can be used to avoid generating the page, but in the case of a dynamic site, performances are too slow.
I would be curious to see if Maverick is fast (faster than XSLTC ?).
I believe that a MVC approach and a framework like struts fits perfectly into many J2EE designs such as EJB + ValueObjects.
Somebody mentionned XML Schema for validation. This is actually something we have been using to validate our ValueObjects, but for now we are not using the marshalling framework with XSLTC. Using this kind of framework is valuable when dealing with protocols like SOAP, where you can transform any ValueObjects to valid XML using XML Schemas defined in WSDL documents, but this is another story... I highly recommend the use of Castor from Exolab (Open Source).
That's true. In my case, its a XML +XSLTC. And we have cases like complexed and big XML documents. The transformation process is taking lot CPU cycles and MIPS on OS390 JVM with a Websphere App Server environment. I think JSP Custom Tag is a good idea
I haven't ever really understood why I would like to use JSP for generating XML. Few points:
1) Why do I need XML? If I'm using it only in presentation layer, should I consider exploiting it further. Using XML-enabled databases for example. Of course this depends greatly on what you are doing. If data is updated often, this can be bad choice. On the other hand if XML is used only at the presentation layer and there are no special scenarios, just producing plain HTML, why bother. Of course PDA/WAP scenarios are real, but then again I see some proplems with JSP-XML-XHTML/WML/etc. scenario. Overhead is one of them.
2) Generating XML with JSP becomes tricky when your pipeline is bit longer. Say that you have application server producing XML for web-server which acts as a portal server. Or pretty much anything else than just feeding client directly.
Jaxb seems promising.. It can definately prove performance, DOM is quite overkill for producing XML for presentation layer and making some updates on the data.
I was also wondering what I could do with XML until my Manager asked me to do a poll form to sample staff's opinions regarding some HR issues. I spent two nights creating the web form (it had 14 questions in all), writing the Servlets and Beans for the JSPs. It was plenty of work! Enter XML!
I've written a web-based wizard that builds a web form for people like my Manager who don't know HTML and Java. In reality, the user of the application just creates an XML file with DOM and saves this file. For display purposes, XSLT is used to transform the file into HTML. I only used JSP for presentation; all the logic was handled with Servlets and helper classes.
I can't say much about it's performance as I haven't checked that out yet but one thing is for sure, my Manager is happy and I have found out that XML can be quite useful for some purposes.
I agree to the first part about JSPs sending out XML but not to the second part that talks about JSPs consuming XML.
JSPs sending out XML
1. If the browser can do the transformation to HTML, why not let it do it? This frees up some processing time at the server and also reduces the size of the page sent across.
2. However I object to the code in Sample#6 that shows a method in a JSP generating xml inline. I would suggest the use of a method called 'toXMLString' in every data bean (javabean) that spews out the complete xml text for that bean. This scales neatly if you have composite beans. It also conforms to the objective of minimizing Java code within a JSP.
JSPs consuming XML
I really don't see a need for this. JSPs shouldn't need to tinker around with javabeans to get useful information. Those parser beans( sample 8 and 11) are real bad. If at all you have a middle tier that only speaks 'xml' with the front tier, it should be the job of the 'controller components' to consume this xml and provide some simple java beans to the JSP.
What happens when you have clients i.e most web browsers which can't do client side transformations like IE 5. Does anyone know of any good strategies which continue to use JSP to produce the XML and are able to transform the XML for these type of clients using XSL ?
How come i can't complie the PortfolioBean.java ?? please help!
I was just running the examples from article two and I noticed that the SAX one doesn't work here. The DOM model shows a nicely filled table. The SAX model doesn't however.
I cut and pasted the code to make sure I wasn't making any typos. It compiles fine but when I run the SAX model the rows are empty .... the dom model does fill the rows.
Any clues as to what might be causing this?
I'm in a Oracle9i environment with JDeveloper.