Welcome!

Victor Rasputnis

Subscribe to Victor Rasputnis: eMailAlertsEmail Alerts
Get Victor Rasputnis via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, XML Magazine, Java Developer Magazine

J2EE Journal: Article

Converting Your Client/Server Applications to the Internet

Converting Your Client/Server Applications to the Internet

IT projects closely follow the path of technology. .For example, the number of Java/XML/HTML projects is increasing, replacing PowerBuilder or VisualBasic systems developed just a few years ago. And developers are asking themselves the question: Do I have to write the same app from scratch? Again?

Integrating existing systems developed in previous millennium environments with the Internet is a costly and difficult task. The other approach would be to "convert" existing applications to native Internet technologies.

Sound complex? It's not. Legacy systems contain rich metadata, although in a proprietary format such as PowerBuilder's PBL or VisualBasic's FRM files. All graphic controls - list boxes, buttons, labels, and so on - show up in the metadata with all their positions, sizes, colors, and other attributes. Database queries allow reconstruction of the original SQL select statements or stored procedure calls. Code scripting of the events is also available.

Suppose we learn how to read the metadata and put it into XML format. What can we do with it? We can generate systems for the Internet by automatically converting existing legacy code.

Magic Wand
In this article we outline the design of the "magic wand" that converts client/server programs into a Java/XML/XSL solution. In particular, we'll demonstrate how you can leverage investments in all your PowerBuilder DataWindows, migrating them to sites residing on J2EE application servers.

Figure 1 presents the logical flow of the conversion process, which starts with the extraction of the XML metadata. This step includes the translation of PowerScript formulas into corresponding Java and JavaScript code. Listing 1 provides a fragment of XML metadata for a simple report listing data from a "Customer" table.

Extracted XML metadata undergoes several independent XSL transformations in order to generate Java servlets, XSL stylesheets, XML Schema, JSP framework objects, and so on. Finally, appropriate generated objects get deployed into a J2EE server as components of the Web application.

Code Generation via Metadata: The Basic Idea
Powered with XSLT, XML metadata lends itself to code generation. For instance, we can write a generic XSL stylesheet to convert metadata into a Java code that executes a query and provides data in XML. We wouldn't have to write and debug servlets anymore, just generate them! A fragment of a servlet generation stylesheet that produces query and data output portions of the code is provided in Listing 2. In our sample case, it results in the Java code in Listing 3.

Similarly, XML metadata precisely prescribes how to lay out all fields and records on the page with position, size, color, font, and so on. It means we have the information to build the XSL stylesheet, transforming the output of the generated servlet into HTML. Better yet, we can generate such a stylesheet withŠa stylesheet!

The basic idea is code generation via metadata. By automatically converting existing reports and forms into Java/XML code that supports the data model, with the XSL stylesheet controlling the view and JavaScript functioning as controller, we make them applicable for any J2EE server.

Sample in Point: Migrating Reports to the Web
The Java servlet for the "Customer List" report, partially illustrated in Listing 1, will produce data in XML with the layout presented in Listing 4. This XML data is transformed into HTML with the XSL stylesheet in Listing 5. (We'll show how this has been generated later in the article.)

And finally, merging XML and XSL results in an HTML page rendered in a browser (see Figure 2).

Looking into Details
The following paragraphs contain selected topics of the magic wand design, such as XSL (with XSL) generation, lookups, and reusing code between JavaScript and XSLT. We'll show how XML metadata comes into play once again - at runtime - supporting built-in end-user dialogs. We'll also introduce XMLControl as a manifestation of Model/ View/Controller architecture. First, however, we'll explain our design considerations. Generated Code vs Generic Runtime

The classic alternative approach to the proposed solution is to interpret metadata during runtime. Several major advantages of code generation made us decide in its favor, however.

  • Performance: Generated servlet code doesn't contain any logic related to metadata processing, since it was used for the code generation itself. Also, generated servlets produce reduced XML output optimized for the data layout. For instance, an XML document corresponding to the population report grouped by country and city shouldn't contain repeating country and city nodes within the appropriate sublevels.
  • Flexibility: Template-based generation lends itself to end-user modifications and integration with client frameworks (as well as porting to other platforms). Users can freely incorporate their business rules, standard actions, and validations. With templates it's easy to switch to produce servlets with a custom data layout. The same SQL query can produce a different XML data layout. In fact, automatic conversion uses different templates to generate different layouts for relational data, a hierarchical collapsible tree view, and an OLAP crosstab. The same is true for the presentation stylesheets.
  • Maintenance and versioning: Both are much simpler. With an interpretive approach any change to the common runtime potentially affects your entire site, while in a code generation case, damage is always limited to the object being regenerated.

Server-Side Transformation vs Client-Side Transformation: Where's My DOM?
Dynamic generation of HTML via XML/XSL always presents the question: Should "XML transformation" be performed on the server or the client?

In the first case, XML and XSL stay at the server. The entire HTML page - the result of XML transformation - is sent to the browser. In the second case, XML and the stylesheet are sent to the browser for the client-side transformation.

We can use either approach. Our generated XSL stylesheet stays the same whether applied on the server or within a browser. For the server-side solution, row-level and aggregation formulas within the metadata result in server-side Java code. For client-side XML transformation we generate the calculation and validation in JavaScript. That said, there's a certain cost associated with either approach for users and developers.

Server-side transformation usually leads to extra round-trips. Recalculating, sorting, or filtering data within the same document results in a new HTML page being generated by the server. Client-side transformation eliminates this. It becomes crucial for advanced data entry systems: imagine Microsoft Excel or Lotus 1-2-3 reloading an entire spreadsheet every time you changed the cell value. (If your users settle for a refresh button, we want them as our clients.)

For programmers, persisting XML and XSL on the server(s) presents additional file, DOM, and session management. Loading them into a browser eliminates these problems. Besides, XML tends to be three to four times smaller than HTML, which means a faster download. Also, XML on the client side allows front-end scripting with strictly defined, strongly typed document models totally independent of the presentation. (To keep things simple, in this article we assume XML is processed on the client.)

Creating XSL with XSL
Creating the presentation stylesheet is a pretty straightforward task since all positioning is kept in the metadata. The trick is in mapping the original presentation objects into HTML objects.

Let's take "radiobutton" as an example. If we have a "gender" column in the DataWindow styled as "radiobutton," it amounts to two HTML <INPUT> controls of type "radiobutton," two associated <LABEL>s indicating option name, two JavaScript actions that modify document values "onclick," and surrounding <SPAN> to define the CSS style of the whole set.

Listing 6 is a fragment of the template for the "radiobutton" control.
Given the following XML metadata:

<DocumentRoot application="sample">...<DATAFIELD> <NAME>gender</NAME> <TABORDER>10</TABORDER> <X>33px</X> <Y>1px</Y> <<WIDTH>144px</WIDTH> <HEIGHT>19px</HEIGHT> <OPTIONS> <OPTION value="M">Male:</OPTION> <OPTION value="F">Female:</OPTION> </OPTIONS> <CONTROLTYPE>radiobuttons</CONTROLTYPE> </DATAFIELD>...</DocumentRoot>
the template in Listing 6 results in the generated presentation XSL, which can be used to generate exactly two input fields, two labels, and two JavaScripts for "onclick" actions (see Listing 7).

During the runtime for the following XML produced by our servlet:

<Root>...<Detail id="1"><fname>Tim</fname><gender>M</gender>...</Detail>... </Root>,
the presentation XSL will, in turn, result in the HTML in Listing 8.

Handling Lookups
The data we use often requires translation table functionality, or "lookups." For instance, state codes - CA, MA, IN - have to be displayed as corresponding state names - California, Massachusetts, Indiana. We'll demonstrate how XML DOM objects facilitate the effective implementation of lookups. Let's assume that we declare a JavaScript array for all different lookup tables within a page.

var allLookups = new Array();
Suppose the state information is in an XML file with the following layout:
<LookupRoot>
<key id="AK"> <selection name="description">Alaska</selection ></key>
<key id="AL"><selection name=" description">Alabama</selection></key>...
</LookupRoot>
We can write a function to load a particular element of array, allLookups, with a reference to lookup data retrieved from a given URL (see Listing 9).

Next we write a showLookup() function, which returns a translation of the value containing the XML node, if it's found (see Listing 10).

As a result, assuming we add these functions under the namespace "lookup," we can write the following XSL statement:

<xsl:value-of select="lookup:showLookup( state, '/cache/states.xml', 'description')"/>
This statement performs a conditional load of the "states" lookup data and results in the description of the code values contained in the "state" column. It's worth mentioning that with browser caching turned on we may not need to reload data from "/cache/states.xml".

Sharing Objects Between JavaScript and XSLT
Besides serving as translation tables, lookups are often used to validate user input. While translation table functionality is part of an XSLT generation of HTML, JavaScript-based input validation is invoked interactively - later and in a different context. To avoid a duplicate load of data and allow reuse of the same code in XSLT and JavaScript, do the following:

  1. Encapsulate allLookups array in a Lookup object and make show-Lookup() and loadLookup() into object methods (see Listing 11).
  2. To use lookup functions (and data) in JavaScript, create an instance of Lookup object:
    var lookupInstance = new Lookup();
  3. To use the same object in XSLT, register this instance with the XLST processor via AddObject function. Below we associate it with the "lookup" namespace:
    xslProcessor.AddObject( "lookup", lookupInstance); xslProcessor.transform();
    As a result, this XSL statement:
    <xsl:value-of select="lookup:showLookup( state, '/cache/states.xml', 'description')"/>
uses data and functions with the browser's JavaScript-hosted instance of the lookup at transformation time.

Is Metadata for Design Time Only?
So far, we've seen how metadata is used to generate J2EE objects. However, XML metadata can be just as valuable at runtime.

For example, it's possible to build a generic ad hoc dialog to accompany any Web report supported by XML metadata. Of course, we need to access the business names of the columns to present them to the end user. And we need to know the data types of the columns to add appropriate <xsl:sort> tags to the presentation XSL. We can also build dynamic ad hoc filter and query-by-example dialogs once we know the appropriate presentation, such as whether a particular column is a checkbox, edit field, or selection list. All this information is contained in the metadata, so its URL is an essential component for the runtime. Figure 3 is an example of the sort dialog running against "Customer List" metadata, with the records sorted by "Last Name, First Name."

XMLControl: More than the Sum of Its Parts
By now we've mentioned four runtime components: data XML, presentation XSL stylesheet, client-side JavaScript, and metadata XML. The first three are essential for rendering the original document in HTML, while metadata is required primarily for ad hoc dialogs such as generic sort and filter.

It's now time to introduce XMLControl:

object:myControl= new XMLControl(dataXML, presentationXSL, placeholderHTML, metaURL, "myControl")
where placeholderHTML is a
that's filled with the results of XML transformation.

XMLControl puts the Model/View/Controller paradigm to work. It "glues" the presentation and underlying XML data by providing transparent synchronization of the presentation HTML and XML data.

Front-end programmers can work with data models instead of pulling data out of HTML debris. For data-entry subsystems, in particular, there's no guessing which data element has been updated since XMLControl maintains state information inside the DOM.

XMLControl provides for adding handlers, such as onItemChanged(), onRadioButtonClicked(), and onAcceptChanges(), emulating a rich set of event notifications for data-bound controls in PowerBuilder and VisualBasic. By the same token, XMLControl lends itself to the implementation of high-level methods such as paint(), update(), setItem(), scrollToRow(), and selectRow(). All these event handlers and methods correspond to the document model, not the view. For example, the task of updating the presentation upon each setItem() called by a programmer is handled by XMLControl as a part of the setItem() implementation. As a result, 90% of legacy client/server code becomes portable with just minor cosmetic changes.

Conclusion
We demonstrated the working approach to migrating client/server applications into the J2EE environment. It enables the automatic magic-wand conversion of databound legacy control to cutting-edge Internet technologies. The cornerstone of the solution - code generation from XML metadata - extends it far beyond the conversion process. Indeed, where the metadata is coming from is irrelevant. Combined with a proper graphic design tool, this solution may become a full-scale IDE for creating Internet applications.

This proposed approach puts to work the Model/View/Controller paradigm, enforcing strict separation of the data model (XML) from presentation (XSL). In our opinion that alone should bring developers' productivity back to the level of RAD tools. In addition, the XSL-based approach to code generation provides limitless possibilities for end-user customization.

The authors maintain a free online implementation of the conversion software at www.xmlsp.com.

More Stories By Victor Rasputnis

Dr. Victor Rasputnis is a Managing Principal of Farata Systems. He's responsible for providing architectural design, implementation management and mentoring to companies migrating to XML Internet technologies. He holds a PhD in computer science from the Moscow Institute of Robotics. You can reach him at vrasputnis@faratasystems.com

More Stories By Anatole Tartakovsky

Anatole Tartakovsky is a Managing Principal of Farata Systems. He's responsible for creation of frameworks and reusable components. Anatole authored number of books and articles on AJAX, XML, Internet and client-server technologies. He holds an MS in mathematics. You can reach him at atartakovsky@faratasystems.com

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.