Satya Komatenini

Subscribe to Satya Komatenini: eMailAlertsEmail Alerts
Get Satya Komatenini: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: XML Magazine, Java Developer Magazine

XML: Article

Applying Java/XML/XSL Technology

Applying Java/XML/XSL Technology

XML/XSL are widely used for publishing and EDI. This article shows how XML/XSL can be used effectively for IT Web development by overcoming the disparities between relational data and XML.

What's the best way to develop Web applications driven by relational databases (the backbone of current IT)? Would the answer lead us down the road to XML/XSL? If so, how can we convert relational data to XML?

In Part 1, I describe the appeal of XSLT as a presentation engine, why we should retrieve relational data as XML, and briefly review how XSQL, a promising tool from Oracle, converts relational data to XML. I'll show how an HTML page's data requirements can be displayed as an XML structure and a set of Java interfaces at the same time.

In Part 2, I'll present a design that lets you obtain these page-level data interfaces from a series of data sources including SQL, Stored Procedures, Java objects, and session beans in a declarative manner, outline why XSLT is not suited for large data sets, and why you should choose JSP in those circumstances.

The Role of XML/XSL/Relational Data in IT Development
Since XML is structured data, its uses are quite extensive. EDI, B2B, and the publishing industry are using XML as part of a central development strategy. But XML hasn't found widespread use yet for IT applications that depend on relational data for the back end and HTML for the browser side. This is contrary to the initial enthusiasm generated by the widespread availability of XSLT. XSLT allows for the true separation of presentation from data so why isn't it used much? In my view, there are two reasons.

First, XSLT as a general purpose transformation language for XML has features and complexity that exceed the needs of simple HTML conversion. XSL transformation source files appear daunting to the first-time developer, thereby hindering their adoption. There's also a latent fear that you might need to access something other than data on the Web page, so you want to be able to use Java on the page as well.

The second reason pertains to the fact that for an IT developer, XML data isn't obvious, so using XSLT isn't encouraged. All an IT developer sees is relational data. Until an efficient mechanism is available to convert this data to XML, the IT developer is not apt to receive the benefits of XSLT.

The first problem is addressed in this article by presenting a template substitution subset of XSLT for HTML transformation, and the second is addressed by a detailed Java-based design that allows conversion of relational data to XML. To allay fears that this is brand-new territory, let me start by reviewing a tool from Oracle called XSQL.

Introduction to XSQL
Using XSQL from Oracle, it's possible to retrieve the output of a set of SQL and Stored Procedures as an XML document. The resulting document can be passed through XSLT for browser consumption. XSQL accomplishes this by embedding SQL and Stored Procedures in an XML document as XML tags to be processed. When processed, this document will have the original XML plus the output of the executed SQL embedded in it. Oracle provides the necessary servlet support for the immediate use of this facility for Web development via XSL and XSLT. The following example demonstrates the central concept of XSQL conversion:

<?xml version="1.0">
<xsql:query xmlns:xsql="urn:oracle-xsql" connection="demo_database">
select 'hello' as Greeting from dual
</xsql:query>

When passed through the XSQL processor, this becomes:

<?xml version="1.0">
<rowset>
<row id="1">
<GREETING>hello</GREETING>
</row>
</rowset>

This means you can construct your XML skeleton and fill it up with rows and columns from Oracle. Note that the conversion from relational to XML in this example took place declaratively. The database and connection details are hidden under the symbolic name "demo_database." XSQL is responsible for managing the connections and all the JDBC-related issues you'd have to worry about if you were writing this in Java.

From the design of tags, it can be easily extrapolated that you can introduce data sources other than relational databases into this framework by providing custom tags and custom tag handlers. It's also possible to carry database inserts, deletes, and updates through XSQL. XSQL is expected to support applications that are Web browser-based, database export/import-based, and XML messaging-related.

XSQL seems to be a good fit if you're using XSLT as your primary presentation engine and you have custom tags for all your data sources, for example, your favorite database environment and your favorite EJB server if you're using EJBs. I'm not too confident this will scale for HTML pages that have to display hundreds of rows and have hundreds of users. This is because the XML has to be fully formed for XSLT. This means you have to retrieve all the rows from the database, and you won't be able to use cursors effectively. I don't see a way to work around this problem as long as XSLT is used. Nevertheless, with a prudent page design, you should be able to develop a good number of form-based, e-commerce applications.

With that said, let me show you a similar design that's more Java-centric and allows for JSP as a transformation engine, in addition to XSLT.

HTML Page Data as an XML Stream
Let's talk about the data needs of an HTML page, irrespective of what business object is being displayed on that page. An HTML page has a series of key/value pairs that define both entry and text fields. It'll also have a series of loop-related data representing the multiple tables, list boxes, and other replicated structures. It's also possible to have loops inside loops, such as list boxes inside tables. This structure can be expressed as XML.

The rationale is that even if you have thousands of pages on your Web site, all their data needs can be satisfied by this same XML structure. This is a powerful abstraction that opens up for Java-based horizontal interfaces (a term borrowed from CORBA architectures). Without further ado, let's see the corresponding XML structure followed by the Java interfaces needed to support the same structure in Java (see Listing 1).

XSLT can retrieve key/value pairs at the root level and also at the row level of every named loop and substitute them into an appropriate XSLT template. Let's see a pair of Java interfaces that a JSP page can use to get access to the same data (see Listing 2).

Page Data Java Interfaces
Page-level data is accessed from the IPageData interface. Loop data is accessed through ILoopData. All URL, session, application-level, and relational data are channeled through these interfaces. This simple model allows for rapid JSP page development.

Using these interfaces has another not so subtle benefit. Loop data can be loaded on a demand basis. As long as the JSP pages walk through this data sequentially, it's possible to use cursors that greatly aid in memory requirements. In a multiuser situation these savings could be significant.

Converting XML to HTML (Sample XSL Page)
To demonstrate the conversion of the resulting XML data to HTML, let me introduce some book-related XML data (see Listing 3).

Listing 4 is a sample of XSLT that converts this data into an HTML file using the XSLT template substitution approach. (More on this approach later.)

Sample JSP Page
Listing 5 shows how the same transformation is accomplished using JSP.

The JSP page starts by obtaining a reference to the IPageData interface. This object reference is passed to the JSP page by a controller servlet. Typically, the same controller servlet passes these IPageData references to all the JSP pages based on their URL name.

The similarities of the XSL and JSP approaches provide an easy migration from one to the other while maintaining the same back-end abstraction. This migration becomes important as you need to move a few of your pages to meet the high volume of your users.

Summary
In Part 1, I discussed why we should adapt XSL and JSP transformations to transform the pervasive relational data to HTML. To support that vision, I proposed a way to convert relational data to XML in such a way that it can be used by both XSL and JSP. I utilized XSQL as one of the approaches for dealing with a set of the same issues and provided an example of how JSP and XSL are applied to the same data stream.

In Part 2 I'll cover a Java-centric design approach for converting the relational data to an XML DOM for access by Xalan, which in turn will be transformed into HTML.

More Stories By Satya Komatenini

Satya Komatineni is Chief Technology Officer of INDENT, Inc and the author of a Java based RAD framework for developing J2EE based HTML applications. The product has the distinction of supporting multiple html transformations (XSL,JSP, proprietary templates) while utilizing the same data abstraction to interact with EJBs, relational databases and ERP systems. After earning an M.S. in Electrical Engineering from Indian Institute of Technology, New Delhi, worked with LAN based collaboration technologies, C++ patterns and frameworks, Java and Web based frameworks in a distributed environment.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.