Currently Enhydra is receiving lots of attention for its capabilities as a server for wireless applications, but application service providers (ASPs) can use it to improve their ability to provide custom branding while at the same time reducing development costs. This article outlines some of the design patterns we used with Enhydra to create a set of applications that support thousands of very different looks from a single code base.

Even more impressive is the potential for evolution. Instead of using file-based development, as we did back in the days of C programming, we can begin to apply object-oriented concepts, like classification and abstraction, to HTML development. In C programming we divided up our code into files that corresponded to the coarse-grained concepts in the software we created. That's pretty much how Web developers divide up their HTML. With object orientation we can divide our program into classifications (classes), and classes are wonderful things because, unlike files, they can have complex relationships to other classes (association, inheritance, aggregations, etc...). Using XMLC and some well-known design patterns, you can apply OO principles to Web development, including inheritance.

The Requirement
Our client is an ASP for a group of about 30 commercial financial institutions. Each of which uses the products internally and resells them to thousands of retail financial institutions. The unique look each of these institutions has is a valuable commodity, and having a look and feel that consistently matches their branding is an absolute requirement.

Developing server applications that can support thousands of different looks based on a user's login is difficult. Before Enhydra, we were limited to the items available in Cascading Style Sheets (i.e., colors and fonts) and perhaps a different logo in the corner. Or we would end up with tons of JSP pages that required lots of maintenance and made making wholesale application changes very expensive.

The Bridge Pattern
The first pattern we used is the Bridge pattern (see Figure 1) from the "Gang of Four" book (Design Patterns, Gamma et al., Addison-Wesley,1995). This pattern allows the interface of an object to bridge to several different implementations.

Enhydra's XMLC compiler has built-in support for the Bridge pattern. Using it requires both the "-generate both" and "-implements" options on the XMLC compiler. To use this pattern effectively requires a little up-front analysis. What we need to look for is classifications or classes of pages. For example, we may find that our application has several HTML forms. Yes, each instance of the HTML form is different. It may have different input elements appearing in a unique order and position, but closer examination reveals that all the HTML forms are built from the same finite set of elements. This is a sure sign of a correct classification. I think you'll find only a small number of classes (form, detail display, summary display, etc.) in your applications.

When a classification is discovered, the next step is to create some code that defines the class (the HTML Form class). This definition is used as a template to create all instances of the class required by the application. Here the class is defined in HTML. The class HTML file must contain one example of each of the elements needed to create the instances. For example, our form class will require sample submit and reset buttons and several input element samples. Each sample element should have a unique ID attribute so the XMLC compiler will generate methods that make it easy to get hold of these elements when we start programming.

With the class defined, we're ready to generate the abstract interface and reference implementation Java classes. Your XMLC command will need to use the "-generate both" option (see Listing 1). This will cause XMLC to generate an abstract interface class (see Listing 2) that we'll use in our servlets. The implementation generated at this stage can be used as a reference implementation (see Listing 3) so you can start coding your servlets right away. This is great because developers can start building the application while the art department is still working their magic on the look and feel. Note: Files are generated by compiling the source code (on the Web at www.sys-con.com/xml/source.cfm), which requires ANT (see http://jakarta.apache.org.ant).

After this, you can add new looks to your application by creating a new class definition HTML file that has the same elements as the original. The elements themselves can be different, but every ID attribute in the original class must be in the subsequent classes. For example, the reference implementation HTML file might have a plain button element for a submit button and later implementations can define fancy rollover buttons. As long as the ID attribute matches the original class, it'll work just fine.

The question that always comes up is, "What if I miss one of the attributes?" XMLC's Bridge pattern support can help. Subsequent implementations are processed with the "-implements <interface>" option. If the abstract interface is used with this option, the generated Java implementation will implement the abstract interface; if any of the ID attributes don't match or are missing, you'll get a compile error. Because you have compile time checking, you can safely let other developers produce HTML class definitions.

Abstract Factory Pattern
This pattern also comes from Design Patterns. The Abstract Factory creates instances of an object without the client actually knowing what the implementation class is (see Figure 2). We use the pattern because we don't want our servlets to know which implementation from the Bridge pattern we're using. That way the servlet is dependent only on the interface, not on any actual implementation.

To use this pattern we need to have our HTML classes defined because we'll need a create method for each of our interface classes on the Abstract Factory interface. Then we'll need to create a concrete factory implementation for each related group of classes. In our case each look and feel needs its own factory implementation. Coding all these factories was tedious, to say the least, but Java's introspection capabilities and XML can help. We created a factory implementation that reads in an XML configuration file (see Listing 4). The XML file defines which HTML class the factory implementation should instantiate. This means that we need only one concrete factory implementation that changes its behavior based on the XML file that it loads. How do we make sure we load the right XML file, and aren't there scalability limits to this approach? The answer to both questions is yes, of course, or I wouldn't have brought them up.

Factory Finder Pattern
This pattern deviates from the Abstract Factory pattern. In this case the objects created by the Abstract Factory are more Abstract Factories. A good example of this pattern is the CORBA Life Cycle Service. For our purposes we'll use a Factory Finder (see Listing 5) to get the correct factory that will create the HTML instances. The Factory Finder has a single method that returns the correct factory object based on supplying a string name. The name we used was the name of the user's financial institution-supplied parameter in the HTTP request.

We started out with an XML file-configured Factory Finder (see Listing 6) that used introspection to create instances of all the factories that were required. We found that when several thousand factories were loaded, the Factory Finder became difficult to maintain. The XML file got really big and the Factory Finder consumed a lot of memory, so we switched to an implementation of the Factory Finder that used a relational database for lookup and created an instance of factories on the fly. This too had scalability limits so we finally settled on an implementation that loaded data from our LDAP directory. This directory offers a much better read performance than a relational database and you can get some pretty cool administration tools to help with care and feeding.

Putting It All Together
Okay, we've got a Factory Finder that returns a Factory class that can create objects that are the correct HTML class for the branding we need. The HTML classes have examples of all the elements required to make the screens our application requires and an empty workspace identified by a "div" tag.

To build an application you need to take all of the above, add a servlet or two, and stir. Each servlet is passed the name of the look and feel to use. The servlet then uses the name to look up the correct Factory in the Factory Finder. The Factory Finder will find the Factory either in its own cache or the LDAP directory. The servlet now uses the Factory to get an instance of the HTML class. It then copies the example elements and puts them in the work space marked by the "div" tag.

Since all of the look and feel is encapsulated in the HTML class, the servlet has no idea what the page looks like - it's just putting the dynamic elements into the page wherever it finds the workspace. Finally, the example elements are removed from the HTML class and the class returns HTML to the browser. The servlet only knows the class interface and has no direct dependencies on anything to do with the look and feel.

In about 20 or 30 minutes, using these techniques, we can deploy a new look and feel that is consistent across all our applications. An added benefit is that we can give the template HTML file to a customer's Web designers and they can quickly create a new look and feel for the whole application. Since the template is validated by XMLC and the Java compiler as containing all the correct elements (e.g., it has to match the defined interface exactly), it's safer than handing out JSP pages for modification by third-party developers. Also, since XMLC supports HTML and XML, we can have the same code base serve up HTML as well as almost any flavor of XML. All we need is a different template.

SIDE BAR
Open Source Enhydra XMLC
Enhydra XMLC is a tool for creating Web and wireless presentations. As an open-source technology hosted at http://xmlc.enhydra.org, it's commonly used as an alternative to JavaServer Pages development because of its appeal to IT architects concerned about the long-term maintenance issues presented by JSP development.

XMLC's emphasis on precompiling HTML or any XML pages into "template objects" completely avoids the need to insert scripting or Java code into the markup page. Instead, Java logic manipulates the page by operating on the template object. By representing markup pages as a W3C standard DOM template class, XMLC enforces good programming practices since developers can never "break the rules" and resort to embedding Java in the markup.

This appeals to IT architects concerned about developers who are using JSP to intermingle markup and Java code, setting the stage for future maintenance nightmares. It also gives architects a Java path to XML development without requiring development (and support) of yet another language, such as XSLT.

During development of the presentation page, designers and/or developers can identify areas of dynamic content by inserted ID attributes inside markup elements. These attributes are later used by the XMLC compiler to create access methods that can be used by the developer to manipulate the page with new information.

Additional benefits of XMLC programming give designers the ability to leave mocked-up content in the page, creating a true WYSIWYG presentation of the page before the presentation is rendered during execution. This is impossible with JSP. XMLC also supports the ability to detect changes made to the original document page. When a change is detected, the XMLC environment can be configured to auto-recompile and reload the page, thus making it possible for designers to make presentation changes without the required involvement of the Java developer.

XMLC has evolved since its introduction by Lutris in early 1999 to embrace WML, XHTML, cHTML (i-mode), and VoiceXML, thanks in large part to the contributions made by Enhydra.org members from around the world. Barracuda, another open-source effort, is a presentation framework that takes advantage of XMLC to add component-based GUI development modeled after the Swing libraries of the Java Foundation Class.

XMLC is part of the larger Enhydra open-source project, founded and stewarded by application server vendor Lutris Technologies. Enhydra has gained notoriety by virtue of its focus on open-source application server technologies, including, most recently, EnhydraME. EnhydraME was launched last summer to extend Web service technologies such as SOAP (kSOAP), XML parsing (kXML), and UDDI (kUDDI) to devices turning. The result is that J2ME devices from Motorola, RIM, and NTT DoCoMo can use EnhydraME technologies to become microapplication servers.
END SIDE BAR

• Figure 1
• Figure 2
• Figure 3