Modern software applications are data-centric and event-driven; and Object Oriented programming techniques and languages are a good fit for this type of applications. Web applications pose additional challenges, but Open Source Software and tailored development techniques can help developing even industrial-grade applications.

1. Introduction

For Java Web applications (also known as J2EE applications) a lot has been done in terms of tools, frameworks, best practices, and methodologies, nevertheless J2EE development is still complex. Steps are being taken to simplify things and minimize effort even further (think, for instance, in the new EJB specification), but the need for quality and speed in delivering software artifacts still persists.

In this article I’ll present some ideas that might help starting up J2EE development projects by combining Open Source tools and frameworks and some requirements elicitation techniques, focusing on quality, testability, and short delivery times of functional and evolutionary software artifacts.

2. Background

As pointed in [1], many J2EE patterns are not patterns but merely workarounds for technology limitations or complex APIs.  Within the Web applications scope, regardless of programming language and technology, the Model View Controller (MVC) pattern has driven the development of most of the tools and frameworks although it may not always be the best approach or even provide a close approach to OO programming. In the framework (Click) discussed in this article, a combination of simpler enterprise applications patterns provide not only a closer OO approach but also help in constructing evolutionary prototypes that prove project feasibility while at the same time target the speed of product delivery by having working software components from the beginning; this is also consistent with the OO approach to systems development: follow an incremental and iterative process.

Prototyping has, of course, its downsides, particularly in large applications, but it is still a very good choice when there’s a lot interaction between users and systems –generally the case in Web applications, and there is a base set of well-understood requirements to start from.

3. Technical aspects

3.1  MVC in perspective

The MVC pattern aims to decouple data access (Model), business logic (Controller), and data presentation (View) in a visual application. A typical MVC flow involves a user taking some action (i.e. clicking links, submitting forms) and a controller component responding to the action by updating the model (data) and its view. Typically, the model pushes changes to the view, but new paradigms such as Ajax [2] also enable the view to (asynchronously) pull data from the model.

The separation of concerns enforced by the MVC pattern –even for desktop applications– do not necessarily provide the best practical solution; as described in the Swing Architecture Overview article [3], “the view and controller parts of a component required a tight coupling (for example, it was very difficult to write a generic controller that didn’t know specifics about the view)”, in other words, it is not rare to find that “the control and the view are usually the same thing” [4]; take, for instance, a visual Web component (combo box, text field, checkbox, etc.): it is both responsible for controlling itself, its views and also holds, or knows how to interact with, the model.

In Swing, the approach was to collapse the view and the controller into a single UI object, and so was for the Click framework. This decision reduces design complexity because there is no need to have and manage different software artifacts for each of the MVC parts.

3.2 One alternative to MVC

“Click provides a Page oriented design, featuring Control components and an event based programming model” [4], all of this possible because the framework is built around the Composite and Decorator[1] patterns.

The Composite pattern is one fundamental pattern that makes possible to organize objects into tree structures to represent part-whole hierarchies (a.k.a. has-a relationships) all exhibiting the same functionality; this is, composite and individual objects are treated uniformly by its clients. Web pages and its components are based on standards (e.g. XHTML, CSS, ECMA, etc.) that define their attributes, structure (hierarchies and relationships), and behavior, and this makes them good candidates to be abstracted as software components.

Click goes one step further by making this components not only fully compliant with the standards from which there are derived, but also makes the components responsible for rendering themselves in their original form: full fledged (X)HTML pages with controls.

The Decorator pattern allows attaching additional responsibilities or behavior to an object dynamically, at runtime, not at compile time, which would be the case when subclassing. Page and control behavior can be modified on-the-fly if required; think, for instance, that a particular cell in a table (both components of a Web page) can either have a red or green background depending on whether the cell value is negative or positive, respectively, at rendering time.

On an implementation level, other relevant patterns come into play; the

• Front Controller is the single entry point to all requests made to the application. “This object can carry out common behavior, which can be modified at runtime with decorators[2]” [5].
• Template View allows composing “the content of the page by looking at the page structure” [5] and replacing embedded markers with the result of some operation.
• Transform View renders data into a Web page having “the model’s data as input and its HTML as output” [5]

3.2.1. Tech details

Click abstracts web pages into a Page base class which has to be extended by every page in the application; Click pages, in turn, are composed of (renderable HTML) controls abstracted in a Control interface which all controls (default and custom) must implement. Click also provides a decorator interface for delegating object/control rendering in the form of a Decorator interface.

There is a ClickServlet which acts as a front controller intercepting all HTTP requests to the application. It is this Servlet’s responsibility to load application configuration, set start up and caching strategies, and map requests to Click pages based on configuration settings and URL information received.

The front controller decides what Page is to be created and served once all its dependencies are satisfied; here both the template and transform views come into picture; for the latter this holds true due to the use of the Java-based template engine Velocity^[3], for the former, the Click Control API relies on the HtmlStringBuffer helper class for HTML rendering of controls.

As a summary, the core framework implementation mapping to the discussed patterns can be thought as follows:

Table 1 – Framework/Pattern mapping

Arguably, the Two Step View pattern could be mapped to the templating implementation in Click due to the driving forces behind it (enabling a consistent look and feel for a Web application), but because of the way this pattern is implemented in the framework, a combination of subclassing techniques and the other patterns might also provide the conceptual/technical foundation.

In the two step view pattern, the view module for every Web page has two stages: the first pertains to the page itself and the second to the entire application. Ultimately, the pattern will be responsible for turning domain data into HTML but with a standardized look and feel.

3.3 A note on tools

Currently, Java Web application development has very good tool support; if using the Eclipse IDE, there are several plugins available to work with the framework[4].

3.4 Acknowledging drawbacks

A quick evaluation of the solution proposed by Click could point out some disadvantages of this approach, like the difficulty to test the template view pattern because it requires a server, or the fact that it also could lead to page cluttering with complicated display logic; yet this issues –as others, are compensated in the design (e.g. the Velocity Template Language is small and focuses on simplicity, the transform view pattern is easier to test).

4. From the Business Perspective

Due to its nature, evolutionary prototypes can also be regarded as business patterns since through them it is also possible to “highlight the most commonly observed interactions between Users, Businesses, and Data” [7].

Out of the four identified business patterns in [7], a Java Web application developed using Click is a good fit for Self-Service (User-to-Business) solutions, Collaboration (User-to-User), and maybe in some Extended Enterprise application (Business-to-Business).

Particularly in Self-Service applications, “where users interact with a business via the Internet and intranet” [7], the iterative development process could very well begin with prototyping of the solution after the requirements elicitation phase has produced a core business model were expected services (including business functions, dependencies, data structures) and constraints are clearly defined and prioritized, typically in the form of Use Cases, UML artifacts and/or other RUP[5]-related documents.

4.1 A word on patterns

Patterns “helps companies understand the true scope of their development project and provide the necessary tools to facilitate the application development process, thereby allowing companies to shorten time to market, reduce risk, and more importantly, realize a more significant return on investment” [7].

Choosing the right business patterns is critical as patterns will allow the business to lay a solid and extendable foundation which will be independent of the chosen development method for the solution. If when mapping those patterns to an implementation technology the technology itself is also built around repeatable solutions to commonly occurring problems –patterns, not only there will be a documented, proven solution but also pitfalls that should be avoided will be readily identifiable.

5. Prototyping

As defined in [9], “a prototype is a demonstration system”, a “working model of the solution that presents a graphical user interface (GUI) and simulates the system behavior for various user events”. As such, prototypes can, and are frequently, used for eliciting requirements. Not surprisingly, prototypes can also be thought of as patterns, archetypes.

A prototype helps in different ways, it

• Helps communicating and refining requirements,
• Gives a head start towards a product release, and, very important,
• Give users, stakeholders, and developers a common ground to negotiate.

They can broadly be classified into throw-away and evolutionary when considering their purpose, but can also be differentiated by their fidelity (low-medium-high), which is the “level of detail that content is rendered in the interface” [8] and by many other factors like audience, longevity, style, and medium.

5.1 From an idea to a system

Regardless of the chosen prototyping method during the requirements elicitation phase (cards, storyboards, use cases narratives or diagrams, etc.), the first working model of the solution should come from a coded prototype since it would be created in the target language when building a technical proof of concept and will be “meant to directly evolve into a final coded product”. “A coded prototype is especially good for capturing both qualitative and quantitative data via usability validation testing”.

5.1.1. The role of the GUI

As stated, modern software applications are data-centric and event-driven, this means users are in control of the GUI and when interacting with it they will always expect consistency (in the way of getting things done), forgiveness (e.g. undo functionality), feedback (i.e. know what is going on at any time), good aesthetics and usability (i.e. visual appeal, ease of use, productivity).

Prototypes will often begin as a skeleton GUI and will be the seed of a final product, hence the special attention that needs to be placed in their design.

5.1.2  Where open source software fits

Frameworks like Click concentrate on simplicity and productivity while providing enough extension points to preserve flexibility. It has a moderate learning curve as is based in component hierarchies, pages and an event based programming model, like when developing desktop GUI applications; also provides out-of-the-box and ready-to-use facilities and controls that shorten development time and is built around simple design patterns.

Click encourages refactoring of complex business logic out of its display components (e.g. into Service Layer [5] classes) so it can be reused and easily tested but still allows component/page testing; logging, persistence, and other utility frameworks can be plugged in and complex components can be either built from basic ones or created from scratch.

Being Open Source software, developers are free to change or extend built in functionality to suit business requirements without significantly affecting the project’s budget (but do relying primarily on non-commercial support).

6. Conclusions

Management of J2EE development projects is still complex, but as more and more the technical side of that complexity is addressed by new technologies, standards, and specifications, still the development process for such applications needs to deal with the business requirements modeling hassles and the intricacies involved in constructing a sound system architecture capable of evolving as business requirements change (and they continuously do).

To cope with such venture, patterns are a good starting point as they provide solid foundations, but choosing the right ones for a specific business scenario would certainly benefit from having tailored made requirements elicitation techniques and open tools and frameworks that make the production of quality-driven, functional, evolutionary software artifacts possible.

Tailored made requirements elicitation techniques facilitates capturing and describing business complexity whereas open tools and frameworks enable dealing with that complexity trough extensible software artifacts.

From a medium-fidelity, coded prototype to the actual finished product the only driving force of change should be the business needs and the user feedback; ideally, everything else should serve this purpose. The proposed ideas in this article aim show one possible path to achieve that goal.

7. Acknowledgements

Our thanks to Mr. Rajeev Gupta, Site Manager of the TCS GDC in Guadalajara, Mexico, for his continuous support and encouragement and to Mr. Malcom Edgar, creator of the Click framework, for his enthusiastic help and invaluable technical feedback.

8. References

[1]     Johnson, Rod, ET. Al, Professional Java development with the Spring framework. Wiley Publishing, Inc., (2005).

[2]     Garret, Jesse J. Ajax: A New Approach to Web Applications. http://www.adaptivepath.com/publications/essays/archives/000385.php.

[3]     Fowler, Amy. A Swing architecture overview. http://java.sun.com/products/jfc/tsc/articles/architecture/.

[4]     Edgar, Malcom. Why Click? http://click.sourceforge.net/.

[5]     Fowler, Martin, ET. Al, Patterns of Enterprise Application Architecture. Addison-Wesley, (2003).

[6]     Gamma, Erich, ET. Al, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

[7]     Galic, Michele, ET. Al, Patterns: Applying Pattern Approaches, Patterns for e-business Series. IBM RedBooks, (2003), 107.

[8]     Arnowitz, Jonathan, ET. Al, Effective Prototyping for Software Makers, Morgan Kaufmann, 2007.

[9]     Maciaszek, Leszek A., Requirements analysis and system design, Addison-Wesley, 2001.