Flowlets - Bringing RAD to the Web

Whitewolf [HREF1], Whitewolf Online Ultimo, NSW

Abstract

This paper sets out the techniques for improved time to market Web Application Development using Whitewolf's Flowlets technology.

Introduction

A Brief History of the Web Application

Since the early days of the web, the user interface features offered by web browsers have not really met the needs of serious application developers. Innovations like Java and JavaScript, and later the fuller DHTML and XML standards, promised to dramatically improve the client application experience in their different ways. The problems with the Java and JavaScript technologies was that they were developed in a somewhat ad hoc manner especially in their early incarnations, and implementations were inconsistent. DHTML deployment on the world-wide scale is low and good implementations of XML are only now beginning to appear on desktops.

This has limited serious web-developers to a structured set of components with which to develop on-line applications. What is provided to developers is a basic request-response mechanism that allows requesting of pages (some of which can be generated on-the-fly) and a means of submitting form data to similar ends.

The Traditional Web Application - Shortcomings of CGI

CGI was the technology that allowed the Web to become a dynamic entity. It was possible to create pages of almost unlimited complexity as long as you were willing to put in a similar amount of effort! CGI was certainly better than nothing, but alas it had many shortcomings:

1. CGI is relatively inefficient
2. CGI is somewhat platform-dependent
3. CGI makes development of complex applications difficult

Java from the Ashes - Servlets

Java, a powerful Object Oriented language with Write-Once, Run-Anywhere capabilities improved the lot of application developers, particularly as it's APIs evolved, notably, JDBC and later, the excellent Servlet specification.

Servlets provide a superficially similar mechanism to CGI - they both allow the processing of requests from clients and the generation of customised responses. Servlets provide more functionality while providing a better abstraction from the HTTP protocol.

1. Servlets are efficient with better resource-sharing and threads
2. Servlets are platform and database independent by virtue of running in a virtual machine (JVM)
3. Servlets ease complex application development, somewhat, with basic session handling and the power of OO programming

The Shortcomings of Servlets. i.e. Why use Flowlets

The standard Servlet model provides, at the most basic level, a simple request/response HTTP mechanism. It is a better abstraction than that given by CGI but when developers require more sophisticated functionality, an extension of this model is necessary. This is particularly the case when developers need to develop applications with complex user-interactions, and potentially complex flow of control. In addition, a quality abstraction is needed for the sending and checking of parameters, for example when processing forms or tracking sessions. Servlets merely allow the developer to access those parameters. The Whitewolf Flowlet Framework was designed to provide this functionality as a means of simplifying application implementation, improving reusability and reducing software maintenance costs.

Nature of the Discourse

Flowlets

The Flowlet architecture was originally designed to allow more complex sites to be easily developed and maintained. During an application's lifetime, requirements almost always change. It is usual for these changes to necessitate user-interface modifications. One of the problems that Servlets does not address is the flow of control between different pages. It provides low-level mechanisms such as a session-key, URL encoding and access to cookies. It is the users responsibility to use these mechanisms to create an interactive application.

The Flowlet architecture addresses these issues by automating their use and providing an extra level of abstraction. The primary construct of the Flowlet architecture is the Flow-Model which defines the ordering of pages within a site. The Flow-Model consists of:

• Actions: An Action Flowlet performs a step of business logic and/or communicates with the database. Actions produce no output to the browser, but allow logical segmentation of functional steps to enhance reusability and flexibility.

• Pages: A Page Flowlet generates the UI representation (usually HTML but can be XML or Graphics or a file for download) and/or performs a determination on an action chosen from a particular page (where a form might have more than one submit button or action choice). Even though the page generates UI presentation, it is separate from the internal page delivery mechanism. For example, a page could produce a data bean and JSP page name and have another class (OutputHandler) carry out the function of working out where the JSP page is, passing it the bean and activating the Servlet engine to render the result.

• Transitions: A HTTP-like standard Request-Processing-Response sequence, with added functionality allowing a number of peer objects to be executed in sequence instead of a single object handling the full sequence. This also facilitates sequence routing between objects stored in an external entity (Flow-Model Registry). Any particular sequence must start and end with a Page Flowlet, with any number of Action Flowlets performing steps of business logic in between.

• Chains: Chains serve as containers for other Flowlets. The purpose of the chain is to provide easy representation of application logic sequences, to allow sequence reuse, and to simplify modeling of interactions between elements of the overall model. Indeed any Flowlet (including chains) can be reused in several places in an application, allowing extremely complex flow of control to be built up in a hierarchical manner. There is no nesting limit for chains.

The flow of a site is generally represented by a Flow-Model Diagram. These are used to describe a site succinctly while allowing easy modification later. The Flow-Model Diagram can be used to automatically generate a Registry Model which is the in-memory model of the full application flow.

Figure 1: A Flow-Model Diagram showing a chain containing one action and one Page

Figure 2: A Flow-Model Diagram showing a Chain within a Chain

Advanced Features of the Flowlets Architecture

The Whitewolf Flowlet Framework is, however, not just a Servlet enhancing technology. It also provides a complete supporting environment for the construction of cross-platform, complex applications that are web-server and database independent. This allows developers to take advantage of advanced programming features with ease, intuitively, and in a repeatable fashion. Modules available as part of the Whitewolf Flowlet Framework include:

• Reporting Module - to generate attractive reports from an arbitrary source - often a database.

• Forms Module - to tackle the problem of easily generating common forms while keeping them maintainable, and allowing easy validation of results on the back-end. Currently, classes exist within the Flowlets Framework that allow easy creation of forms. The Forms module also streamlines the common case where a database row is to be populated or modified on an individual basis by the user and generates the vast majority of HTML, SQL and validation automatically.

• Database Helper Classes - to help the developer to generate clean, correct, compliant SQL code and to streamline access to the database. These classes are called by the Forms and Reporting modules in common cases.

• HTML Generation Helper Classes - to assist in the creation of quality, readable HTML that is fully compliant with standards and free of typos and other errors. These classes are used extensively by the Forms and Reporting modules. They generate all common mark-up and allow for customisation where necessary.

• Logging Mechanism - to allow detailed tracing of the application to be viewed at a configurable level of detail. It is expected that this will soon be improved to allow remote tracing/debugging.

Integration with Emerging Technologies

From its inception, the Flowlets architecture was designed to be future-friendly. It was clear that a number of technologies were being developed which would replicate or complement our work. As is often discovered, there are many ways to solve most problems in the world of IT and the choice is really one of appropriateness to the task. With this in mind, we will discuss some of the technologies with which we feel the Flowlets technology will be valuable.

Java 2 Enterprise Edition (J2EE)

This is a key technology which endeavours to specify clear sets of functionality to allow 'best-of-breed' technology implementations to work together by defining minimum APIs for key enterprise software layers to implement. J2EE subsumed the Servlet specification so that the Servlet engine is now a J2EE Container. J2EE also includes the Enterprise Java Beans (EJB) specification, a technology which is strongly in line with Whitewolf's architectural preferences.

If EJBs are used, the Flowlets framework will help complete the development infrastructure by allowing the front-end to be rapidly developed in line with the business layers. Thus the technology occupies a niche in the front of the middle tier.

Figure 3: How the Flowlets Architecture fits in

XML/XSL

As already discussed, one of the emphases of the Flowlets design is to allow it to operate at multiple levels of abstraction. Thus it allows the developer to use its features in various ways while allowing them to maintain maximum control when detailed customisation in a particular application is necessary. As a result, there is a strong separation between the modules of the system. That said, there is a strong emphasis within the Flowlets technology towards the generation and processing of HTML/HTTP. One of the main goals of our design in the near-term future is to allow pages to be specified as XML/XSL for direct display on the client machine, or to be post-processed into HTML for rendering on older browsers.

Conclusion

While the market is gratifyingly moving towards better implementation of standards, and newer standards (J2EE, XML, XSL), there are still many market niches where common repetitive developer work can be automated. One of the largest costs in the development of Internet and Intranet web-applications is maintenance. Thus, tools that assist in this process should be most welcome to the market.

Whitewolf online has proved that Servlets can compete with and improve upon software solutions developed using tools which are dependant on proprietary technologies. Whitewolf's flow-model technique and its associated generic functional modules greatly simplify the process of Servlet-based application development. Planned enhancements to these products will further extend the ease of use and shorten the implementation cycle of Servlet technology-based applications.

Hypertext References

HREF1

http://www.whitewolf.com.au

Copyright

WhiteWolf, © 2000. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.

[ Proceedings ]