Chapter 1: J2EE architectures

One should apply J2EE to realize OO design, not let J2EE technologies dictate object design.

Goals of an Enterprise Architecture

• Be robust
• Be performant and scalable
• Take advantage of OO design principles
• Avoid unnecessary complexity
• Be maintainable and extensible
• Be delivered on time
• Be easy to test
• Promote reuse

We may also need:

• Support for multiple client types
• Portability

The importance of the last two goals is a matter of business requirements, not a J2EE article of faith. We can draw a dividend of simplicity that will boost quality and reduce cost throughout a project lifestyle if we strive to achieve only goals that are relevant.

Distributed applications or not

This is a crucial point [the misconception that J2EE is necessarily a distributed model, ZWH], as distributed applications are complex, incur significant runtime overhead, and demand design workarounds to ensure satisfactory performance.

In my experience [Rod Johnson’s, ZWH], the deployment flexibility benefits of distributed applications are exaggerated. Distribution is not the only way to achieve scalable, robust applications. Most J2EE architectures using remote interfaces tend to be deployed with all components on the same servers, to avoid the performance overhead of true remote calling. This means that the complexity of a distributed application is unneccessary, since it results in no real benifit.

With EJB local interfaces and web services, we can now use EJB without RMI, and support remote clients without EJB. This gives us much greater freedom in designing J2EE applications.

When to use EJB

Implications of using EJB

• Using EJB makes applications harder to test
• Using EJB makes applications harder to deploy
• Using EJB with remote interfaces may hamper practcing OO design
• Using EJB may make simple things hard
• Reduced choice of application servers

Unconvincing arguments for using EJB

• To ensure clean architecture by exposing business objects as EJBs
• To permit the use of entity beans for data access
• To develop scalable robust applications

Compelling arguments for using EJB

• To allow remote access to application components
• To allow application components to be spread across multiple physical servers
• To support multiple Java or CORBA client types
• To implement message consumers when an asynchronous model is appropriate

Arguments for using EJB to consider on a case-by-case basis

EJB’s simplification of multi-threaded code is a strong, but not decisive, argument for using EJBs.

The availability of declarative transaction management via CMT is the most compelling reason for using EJB.

When you want to have declarative (as opposed to programmatic) role-based security, EJB is a valid choice.

EJBs are a good solution to problems of distributed applications and complex transaction management. However, many applications don’t encounter these problems. EJBs add unnecessary complexity in such applications. An EJB solution can be likened to a truck and a web application to a car. When we need to perform certain tasks, such as moving large objects, a truck will be far more effective than a car, but when a truck and a car can do the same job, the car will be faster, cheaper to run, more maneuverable and more fun to drive.

Accessing data

Whatever the data access strategy we use, it is desirable to decouple business logic from the details of data access, through an abstraction layer.

State management

Applications that do not maintain server-side state are more scalable than applications that do, and simpler to deploy in a clustered environment.

J2EE architectures

Architectural Tiers in J2EE applications

• Enterprise Information System tier (EIS)
• Middle tier
• UI tier

Importance of business interfaces

EJB is not the only technology for implementing the middle tier in J2EE applications.

Design to Java interfaces, not concrete classes, and not technologies.

Architectures for web applications (may be distributed)

Following are four J2EE architectures, each with their own strengths and weaknesses.

I. Web Application with business component interfaces

A layer of business component interfaces exposes all the application’s business logic to web-tier components:

• EIS may consist of any DBMS/Legacy System
• Business tier consists of POJOs
• Web tier hosted by web container of J2EE server

For strength and weaknesses, see book.

II. Web Application that accesses local EJBs

An extension of the previous architecture, allowing to use EJB container services to provide thread and transaction management:

• EIS may consist of any DBMS/Legacy System
• EJBs with local interfaces only, hence avoiding the (programming and run-time overhead induced by remote interfaces
• Web tier hosted by web container of J2EE server

For strengths and weaknesses, see book.

III. Web Application with remote EJBs

This is the “classic” full-blown J2EE architecture, fulfilling the needs of remote J2EE-technology clients, optimally scalable and robust, at the cost of complexity and performance:

• EIS may consist of any DBMS/Legacy System
• EJBs with remote interfaces
• Web tier hosted by web container of J2EE server
• Possibility of executing components on physically different layers

For strengths and weaknesses, see book.

Do not let the use of EJBs with remote interfaces cause an application to be distributed unless business requirements dictate a distributed architecture.

IV. Web Application with Web Services Interface

Adds support for non J2EE-technology clients by adding a web services layer:

• Adds an object layer exposing the web services, and a transport layer implementing the necessary protocols
• Any of the above presented architectures can be extended to include a Web Services interface
• (It is possible that web services protocols such as SOAP will eventually supplant platform-specific protocols such as RMI.)

For strengths and weaknesses, see book.

Web Tier Design

It’s important that hte web tier is a distinct layer that sits on the middle-tier business interfaces. This ensures that the web tier can be modified without altering business objects and that business objects can be tested without refrence to the web tier.

The Model View Controller (MVC) Architectural Pattern

• A model is a JavaBean that exposes data
• A view is a component that is used to display the data in a model
• A controller is a Java class that handles incoming requests, interacts with business objects, builds models, and forwards each request to the appropriate view

Use the MVC architectural pattern in the web tier. use a web application framework such as Struts to provide a standard implementation of the MVC pattern, minimizing the amount of application code you will need to write.

Connectivity between the web tier and business object

In a well-designed J2EE web application, the web tier will be very thin. It will only contain code that’s necessary to invoke middle-tier business interfaces on user actions and to display the results.

Designing applications for portability

We must distinguish between implementation portability (“this code runs without change on any application server”) and design portability (“this application will work correctly and efficiently on any application server, if a small number of clearly identified interfaces are re-implemented”). Total implementation portability can be achieved in J2EE, but may not be a realistic or even a very worthwhile outcome. Design portability is achievable, and delivers most of the business value of portability. Even when portability is not a business requirement, design portability should flow from good OO design practice.

Some valid arguments for reverting to vendor-specific extensions:

• The limitations of EJB QL
• Access to proprietary features of EIS-tier components

Don’t reject vendor-specific enhancements or EIS resource-specific functionality, which may produce significant benefits. Instead, ensure that these can be accessed without compromising design portability.
Application portability results from good design. If we localize vendor-specific functionality and ensure that it is accessed through vendor-independent interfaces, we can take full advantage of valuable features of each taret platform without compromising the portability of our overall design.

Good OO design practice is fundamental to a sound architecture. J2EE technologies should be applied in pursuit of a sound object model, and should not dictate the object model itself.