As it relates to J2EE, there already exists a set of well-defined design patterns geared toward the technology. They can be found in the recently published book, Core J2EE Patterns. Sun's J2EE Blueprints provide best practice guidelines and architectural recommendations for real-world application scenarios. These enable developers to build portable, scalable, and robust applications. But remember, a framework must provide an implementation of the guidelines and design patterns across all tiers. Before listing what to look for in the implementation, it's important to look at existing framework references.

Struts
This framework implements the Model-View-Controller (MVC) pattern to aid JSP and servlet development efforts. Regardless how appropriate its implementation, without components and services for the other J2EE aspects (EJB, JMS, etc.), and because it supports the presentation tier only, Struts is not qualified to be considered a J2EE application framework.

realMethods Framework
This framework attempts to provide support for all the major J2EE technologies, on all tiers. realMethods contends that its framework is completely design pattern-based and has been developed from the ground up for the past 18 months. There is more on this framework later in the article.

J2EE Blueprints and the Pet Store Demo
Sun's J2EE Blueprints seeks to provide a set of best practice guidelines for J2EE application development. The Pet Store demo represents an application built using these guidelines. It also includes potentially reusable vertical components, such as a shopping cart. Our definition also rules out the Blueprints Pet Store demo since it's an application with an implementation based on design patterns, instead of a core set of reusable classes and services.

What To Look For
There are roughly a half-dozen key features and characteristics to look for in a J2EE application framework. But first, let's define three things a framework is not:

1. A library of independent Java components: Too often, an enterprise considers itself to have a framework when what it has is a set of reusable components, each not necessarily having any relationship with the set. This isn't to undermine their importance, but such components are often not required for the J2EE application being considered. A framework should provide reusability for all applications across the enterprise using the targeted technology. A calendar component, while reusable, isn't required of every J2EE application.
2. An application: Even the best designed and written J2EE application is not a framework. Sifting through such an application will hopefully provide some best practices toward proper idioms and techniques of implementation. However, the level of reusability required of a framework would be nearly impossible to extract from the application.
3. Any other framework: This simply means that you should expect the framework to be constructed "with intention" from the ground up. As software vendors attempt to capitalize on the need for J2EE frameworks, understand the origin of the resulting framework. Be cautious of vendors porting existing frameworks from one technology to J2EE. Ultimately, the best J2EE frameworks will be based on the best design patterns and guidelines related and specific to J2EE.

The Shopping List
Design Patterns Implemented
A framework must have at its core a set of design patterns. Patterns provide solutions for problems typically encountered in the design and development of J2EE applications. It's important to remember that these patterns should be implemented in such a way as to provide full coverage on all J2EE tiers.

By building your application on top of such a framework, it should immediately inherit the important characteristics intended by the design patterns.

Multiple Tier Support
Any substantial J2EE implementation will require support on the presentation, business, and data/service tiers.

1. Presentation tier: Encompasses JavaServer Pages, servlets, presentation logic, minimal security, and an object cache
2. Business tier: Encompasses application business objects, session/entity beans, and JMS technologies
3. Data/service tier: Encompasses data access considerations as well as asynchronous service definitions and provisions

Application Server Neutral
A framework should not make a commitment to any one J2EE application server. None of its core capabilities should have a dependency on a single app server. A feature with a dependency should be peripheral to the essential offerings of the framework, or encapsulated and implemented in such a way that the dependency is transparent to the application.

Configurable
A considerable number of features and services of a framework should be modifiable without making changes to its code. This should happen by means of property and/or XML files. One way in which a framework can maintain application-server neutrality is by allowing property-based configuration. This should simplify migration from one app server to another, or allow a heterogeneous mix of app servers in a single application deployment.

Useful But Not Intrusive There is a fine line between each. A framework takes a stand with its implementation, but is it forcing your design and development to take place in an unnatural or unacceptable fashion? A framework is of no use if it causes you to retrain in ways that are not transferable to other J2EE efforts (that do not use the same framework). Again, this is where design patterns play a part. By having patterns as the foundation of the framework, you can be assured that the role you will play in consuming the framework will be consistent and predictable.

Code Generation
Since a framework should be based on design patterns and provide multi-tier support, generating much of the code as it relates to the application and its integration with the framework should be expected. In fact, if this code is not generated, the application runs the risk of incorrectly interpreting the intent of the design patterns already implemented by the framework. This would defeat the purpose of using a framework in the first place.

Dependent (Yet Independent) Services
Just because a framework should be a cohesive implementation of design patterns doesn't mean the application needs to be dependent on all available services. A framework is of the greatest use when an application is able to pick and choose those features that are most important. Loose component coupling by the framework assists in accomplishing this.

Application Server Vendor Positioning
Vendors are busy keeping in step with an ever-changing J2EE specification and JDK. Many have provided vertical components and applications that are mainly tied to their server offering. Most either include, or offer at an additional cost, tools to assist in bean deployment, O/R mapping, and more. Some include Struts or the Blueprints Pet Store demo as part of their download.

But what good are any of these if, fundamentally, the first hurdle is understanding J2EE itself? And the second hurdle, an even higher priority, is to effectively design and implement in J2EE. Fast-moving technology with an increasing level of complexity needs to provide relief in many areas. Frameworks address this need. To date, no application server vendor provides a complete J2EE application framework.

There exists a natural relationship between app server and framework vendors. Considering the neutrality requirement of a J2EE application framework, it should seamlessly complement and enhance any app server vendor offering. A simple comarketing relationship shows that each vendor endorses and supports the other's product. A more "collaborative" relationship is an indicator of a committed, embedded correlation between the two. This type of relationship should serve notice of both vendors' commitment to simplifying and enhancing your J2EE experience.

realMethods Framework
All of the necessary design patterns required of any well-structured J2EE application are already implemented by the realMethods Framework. As such, the framework provides support on all tiers (Web, business, and data access). Its main purpose is to provide a cohesive implementation of the best J2EE design patterns. This framework also provides a set of solutions to reoccurring complexities and issues found in most, if not all, J2EE application development.

Observe the realMethods Framework implementation of a dozen design patterns as defined by the book, Core J2EE Patterns, Best Practices and Design Strategies.

Unlike single-purpose Java components, the realMethods Framework fulfills the need for application-level reusability across the enterprise (see Figure 1). By furnishing design time, development time, and runtime support, it appropriately allows design and development efforts to be focused on business-related issues, and not necessarily on application infrastructure. Much like the Microsoft Foundation Classes is to the Windows API, the realMethods Framework is to the J2EE Application Server: it applies structure, order, predictability, and simplification toward building J2EE applications.

Utilization Is an Issue
Acceptance of J2EE is becoming more widespread, but its utilization remains an issue. Today it is a known fact that many J2EE-based applications remain on the peripherals of the technology, using EJB and JMS technologies sparingly, preferring to focus on the JSP/servlet and JDBC aspects. A framework encourages more thorough consumption of an application server's offerings, and ultimately a deeper commitment by the enterprise to J2EE. As competing technologies attempt to get the attention of software architects and developers, J2EE application frameworks will be an important part of gaining deeper loyalty and dedication to J2EE.

Resources

1. Struts: http://jakarta.apache.org/struts/
2. J2EE Blueprints: http://java.sun.com/j2ee/blueprints/
3. Core J2EE Design Patterns: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0130648841&vm=
4. realMethods Framework: www.realmethods.com; www.j2eeframework.com
5. Alur, D., Crupi, J., and Malks, D. (2001). Core J2EE Patterns, Best Practices and Design Strategies. Prentice Hall.