A little over a year ago, I created my first Web application to publish AS/400 data. The application was based on a three-tier architecture. In the first tier, a Web browser presented the data to the user. In the middle tier, Active Server Pages (ASPs), coupled with ASNA Visual RPG (AVR) components, implemented the business rules. In the third tier, an AS/400 was serving the data. The technologies involved were pretty easy to grasp. Besides learning the basic mechanics of Web serving, I had to learn a little HTML and how to create ActiveX components to interact with the ASP machinery.
Even though I could have created an ActiveX component or Java applet to deliver logic to the user, I opted against it for three reasons. First, users can be impatient and might not have waited for the component to download to their machines. Second, the application would have become dependent on the end user’s platform, especially in the case of an ActiveX program, and some users might have been marginalized. The third reason for avoiding this model was scalability. When a component is running on a browser and accessing data directly on the AS/400, the architecture being used is the traditional client/server, which, apart from increasing the security concerns, imposes huge demands on the AS/400. Each user navigating through the Web application would start at least one AS/400 job. Imagine the number of active jobs the machine would have to support at Web rush hour! For these reasons, I chose the three-tier model, which nicely addressed all of these issues.
Why Use XML?
Under the three-tier architecture, the middle tier accesses data from DB2/400, processes it, and produces HTML. The HTML is then sent to the browser which presents the data in its window. HTML is a format used to direct the browser on how to present the data.
However, developers producing HTML directly from within their applications end up “contaminating” the applications by inserting code for HTML alongside that of the applications’ business rules. They also end up with applications that are useful only when accessed from a Web browser. Modern Web applications should produce Extensible Markup Language (XML). (For an introduction to XML, please see my article “
To get an idea of how problematic it is to generate HTML from an application, imagine that, within your RPG or COBOL program, you had to deal with the details of the 5250 data stream used with dumb terminals. Your program would end up being very hard to maintain, and any changes to the appearance of the screen would imply code changes and program recompiles. In the case of Web applications, this problem is compounded because Web masters, usually hired by the marketing department, have strong opinions on how information should be presented to the user.
Separating Presentation from Data
On traditional AS/400 applications, you separate the data itself from the way the data is to be presented to the user. A display file serves as a template, which is merged with the data calculated by a program to form what the user sees on the screen. This merging happens when the program issues a write or an execute-format to the display file. The need to separate the presentation from the data becomes more demanding as the dynamism of the Web site grows. The trick to this separation is to output the data produced by the application in XML and then apply a transformation to it using some form of externally described format.
Extensible Stylesheet Language (XSL) is a language used to define style sheets; a style sheet contains templates indicating how to transform data from XML into HTML. XSL is a declarative language, not a procedural one. Conceptually, it is more like O-specs than C-specs. With XSL, a set of templates is built to process specific types of XML documents and transform them into HTML or even to create a new XML document with a different structure or format. When the HTML is needed, a processor (which I’ll describe in a moment) takes the templates in the style sheet and applies them to the document. This process is similar to doing a “mail merge” using a word processing program.
Like a Tree
A well-formed XML document can be described as a tree, with a single element as its root and multiple elements and subelements as the branches and leafs. The elements in the tree are known as nodes of the tree. At runtime, templates in the style sheet are matched with the nodes of the tree. When a match is made, the corresponding template is applied. This results in a transformation of the XML document into, for example, another XML document of a different type or into an HTML document. This transformation is done by an XSL processor, and it can occur either on the client side (if the user has a newer Web browser) or on the Web server itself.
When the process is done on the server, the programmer needs to call processor methods. XSL processors are also bundled with other Web products. Microsoft provides its processor as an ActiveX component, which is included with Internet Explorer 5.0; it is
accessible from languages such as Visual Basic (VB) and AVR. IBM makes the Lotus XSL processor, a set of Java classes that is available as part of WebSphere Application Server Version 3.
Formally, XSL is divided into two areas. One area deals with the selection of nodes, and the other area deals with the actual transformations. The World Wide Web Consortium (www.w3c.org) released the two standards defining these areas last November: XSL Transformations (XSLT) and XML Path Language (XPath).
A Closer Look at XSL
XSL uses XML as its syntax, which has several advantages. The main advantage is that, in general, the tools and technologies created for XML can be used for XSL immediately. Currently, programmers and Web masters have to create the style sheets by hand with text editors. However, the wave of WYSIWYG editors for style sheets is approaching the shore quickly. For now, though, having XSL use the XML syntax frees XML authors from having to learn another markup language.
Take a look at an example. Figure 1 (on page 57) shows an article listing in XML format. In the example, the element
The template matches the root node by indicating a slash (/) as the pattern to find. The content of the template is basically an HTML file with "holes" in it that are to be filled with data coming from the XML document. These holes are marked by the element
To work with a list of similar nodes, such as the actual list of articles, use
XSL transforms the XML tree into a new tree, allowing extensive reordering, generated text, and calculations. This is in contrast to Cascading Style Sheets (CSS), which only "decorate" an XML tree with formatting properties. (See "XML and CSS: Displaying Information on the Web" in this issue by Teresa Pelkie.)
The XML source generation can be maintained by the programmer from the perspective of "pure content" and can be delivered simultaneously to different users by providing different style sheets. In my example, I could deliver basic catalog information, article ID, and quantity available to a palmtop device just by switching the style sheet!
And It's Just Getting Started
You can use style sheets to convert an XML document from one schema to another without having to write a program. This capability will become extremely useful as XML technology starts to encroach into the electronic data interchange (EDI) domain. And even though the current implementations of XSL-supporting products may differ from vendor to vendor, it is worthwhile getting a head start with the technology that will change the landscape of data processing by starting some pilot projects within your organization.
Editor's note: The XML and XSL files shown in Figures 1 and 2 are available for download from www.midrangecomputing.com/mc. Please realize, however, that the XML was dynamically generated by a server-side application program. That program can be written in any language, but this "nuts and bolts" application, in particular, generated its XML with AVR. The AVR application senses whether or not the browser is Internet Explorer 5.0. If the browser is Internet Explorer 5.0 or higher, the AVR application simply sends the XML and XSL files. But, if the browser is other than Internet Explorer 5.0, the AVR application transforms the XML into HTML (via the XSL rules) on the server with the following three lines of code:
TheData.LoadXml(XmlString)
TheStyleSheet.Load(“C:StylesheetsArticles.xsl”)
Response.Write(TheData.TransformNode(TheStyleSheet))
Eduardo C. Ross has been vice president and director of research and development at ASNA since 1987. He is responsible for the design of the companys new technology and jointly holds patents included in Acceler8DB. You can reach Eduardo via email at
.
Headed Bolts
Articles for Category
ID Description Available Unit
Category Description:
Figure 1: This XML article listing will be transformed into HTML.
Figure 2: A single template in this XSL style sheet is used to transform the list of articles into a displayable HTML table.
Figure 3: The transformation from XSL into HTML gives this browser display.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online