|
|
Now that we've discussed some of the high-level issues in J2EE design, let's look at some alternative architecture for J2EE apps.
First, let's consider some concepts shared by all J2EE architectures.
Each of the architectures discussed below involves three major tiers, although some introduce an additional division within the middle tier. Experience has shown the value of cleanly dividing enterprise systems into multiple tiers. This ensures a clean division of responsibility. The three-tier architecture of J2EE reflects experience in a wide range of enterprise systems. Systems with three or more tiers have proven more scalable and flexible than client server systems, in which there is no middle tier. In a well-designed multi-tier system, each tier should depend only on the tier beneath it. For example, changes to the database should not demand changes to the web interface. Concerns that are unique to each tier should be hidden from other tiers. For example, only the web tier in a web app should depend on the servlet API, while only the middle tier should depend on enterprise resource APIs such as JDBC. These two principles ensure that apps are easy to modify without changes cascading into other tiers. Let's look at each tier of a typical J2EE architecture in turn.
Sometimes called the Integration Tier, this tier consists of the enterprise resources that the J2EE app must access to do its work. These include Database Management Systems (DBMSs) and legacy mainframe apps. EIS tier resources are usually transactional. The EIS tier is outside the control of the J2EE server, although the server does manage transactions and connection pooling in a standard way. The J2EE architect's control over the design and deployment of the EIS tier will vary depending on the nature of the project (green field or integration of existing services). If the project involves the integration of existing services, the EIS tier resources may impact on the implementation of the middle tier.
J2EE provides powerful capabilities for interfacing with EIS-tier resources, such as the JDBC API for accessing relational databases, JNDI for accessing directory servers, and the Java Connector Architecture (JCA) allowing connectivity to other EIS systems. A J2EE server is responsible for the pooling of connections to EIS resources, transaction management across resources, and ensuring that the J2EE app doesn't compromise the security of the EIS system.
This tier contains the app's business objects, and mediates access to EIS tier resources. Middle tier components benefit most from J2EE container services such as transaction management and connection pooling. Middle-tier components are independent of the chosen user interface. If we use EJB, we split the middle tier into two: EJBs, and objects that use the EJBs to support the interface. However, this split isn't necessary to ensure a clean middle tier.
This tier exposes the middle-tier business objects to users. In web apps, the UI tier consists of servlets, helper classes used by servlets, and view components such as JSP pages. For clarity, we'll refer to the UI tier as the "web tier" when discussing web apps.
Many regard EJBs as the core of a J2EE app. In an EJB-centric view of J2EE, session EJBs will expose the app's business logic, while other objects (such as "business delegate" objects in the web tier in the Business Delegate J2EE design pattern) will be defined by their relationship to the EJBs. This assumption, however, elevates a technology (EJB) above OO design considerations.
| Important |
EJB is not the only technology for implementing the middle tier in J2EE apps. |
The concept of a formal layer of business interfaces reflects good practice, and we should use it regardless of whether we use EJB. In all the architectures we discuss below, the business interface layer consists of the middle-tier interfaces that clients (such as the UI tier) use directly. The business interface layer defines the contract for the middle tier in ordinary Java interfaces; EJB is thus one implementation strategy. If we don't use EJB, the implementation of the business interfaces will be ordinary Java objects, running in a J2EE web container. When we do use EJBs, the implementations of the business interfaces will conceal interaction with the EJB tier.
| Important |
Design to Java interfaces, not concrete classes, and not technologies. |
Let's now look at four J2EE architectures that satisfy different requirements.
The following architectures are suitable for web apps. They can run all app components in a single JVM. This makes them simple and efficient but limits the flexibility of deployment.
In most cases, J2EE is used to build web apps. Thus, a J2EE web container can provide the entire infrastructure required by many apps. J2EE web apps enjoy virtually the same access to enterprise APIs as EJBs. They benefit from the J2EE server's transaction management and connection pooling capabilities and can use enterprise services such as JMS, JDBC, JavaMail, and the Java Connector API. All data access technologies are available with the exception of entity beans. The web tier and middle tier of a web app run in the same JVM. However, it is vital that they are kept logically distinct. The main design risk in web apps is that of blurred responsibilities between UI components and business logic components. The business interface layer will consist of Java interfaces implemented by ordinary Java classes. This is a simple yet scalable architecture that meets the needs of most apps. The following diagram illustrates this design. The dashed horizontal lines indicate the divisions between the app's three tiers:
This architecture has the following strengths:
Simplicity. This is usually the simplest architecture for web apps. However, if transaction management or threading issues require the development of unduly complex code, it will probably prove simpler to use EJB.
The following drawbacks should be kept in mind:
This architecture supports only a web interface. For example, it cannot support standalone GUI clients. (The middle tier is in the same JVM as the web interface.) However, a layer of web services can be added, as we shall see later.
The Servlet 2.3 specification (SRV.9.11), which can be downloaded from http://java.oracle.com/products/servlet/download.html, guarantees web-tier objects access to EJBs via local interfaces if an app is deployed in an integrated J2EE app server running in a single JVM. This enables us to benefit from the services offered by an EJB container, without incurring excessive complexity or making our app distributed. In this architecture, the web tier is identical to that of the web app architecture we've just considered. The business interfaces are also identical; the difference begins with their implementation, which faces the EJB tier. Thus the middle tier is divided into two (business interfaces running in the web container and EJBs), but both parts run within the same JVM. Two approaches can be used to implement the business interfaces:
A proxy approach, in which a local EJB implements the business interface directly and web container code is given a reference to the EJB's local interface, without needing to handle the necessary JNDI lookup.
We don't need to worry about catching java.rmi.RemoteException in either case. Transport errors cannot occur. In this architecture, unlike an architecture exposing a remote interface via EJB, the use of EJB is simply an implementation choice, not a fundamental characteristic of the architecture. Any of the business interfaces can be implemented without using EJB without changing the overall design. This is an effective compromise architecture, made possible by the enhancements in the EJB 2.0 specification:
This architecture has the following strengths:
It's less complex than a distributed EJB app.
Its drawbacks are as follows:
It's more complex than a pure web app. For example, it encounters EJB deployment and class loading complexity.
| Note |
Sometimes we may decide to introduce EJB into an architecture that does not use it. This may result from the XP approach of "doing the simplest thing that could possibly work". For example, the initial requirements might not justify the complexity introduced by EJB, but the addition of further requirements might suggest its use. If we adopt the business component interface approach described above, introducing EJBs with local interfaces will not pose a problem. We can simply choose the business component interfaces that should be implemented to proxy EJBs with local interfaces. Introducing EJBs with remote interfaces may be more problematic, as this is not merely a question of introducing EJB, but of fundamentally changing the nature of the app. For example, business interface granularity may need to be made more coarse-grained to avoid "chatty" calling and achieve adequate performance. We will probably also want to move all business logic implementation inside the EJB container. |
The following two architectures support remote clients as well as web apps.
This is widely regarded as the "classic" J2EE architecture. It offers the ability to split the middle tier physically and logically by using different JVMs for EJBs and the components (such as web components) that use them. This is a complex architecture, with significant performance overhead:
Although the diagram shows a web app, this architecture can support any J2EE client type. It is particularly suited to the needs of standalone client apps. This architecture uses RMI between the UI tier (or other remote clients) and the business objects, which are exposed as EJBs (the details of RMI communication are concealed by the EJB container, but we still need to deal with the implications of its use). This makes remote invocation a major determinant of performance and a central design consideration. We must strive to minimize the number of remote calls (avoiding "chatty" calling). All objects passed between the EJB and EJB client tiers must be serializable, and we must deal with more complex error handling requirements. The web tier in this architecture is the same as in the ones we've discussed above. However, the implementations of the business interface will handle remote access to EJBs in the (possibly remote) EJB container. Of the two connectivity approaches we discussed for local EJBs (proxy and business delegate), only the business delegate is useful here, as all methods on EJB remote interfaces throw javax.rmi.RemoteException. This is a checked exception. Unless we use a business delegate to contact EJBs and wrap RMI exceptions as fatal runtime exceptions or app exceptions, RemoteExceptions will need to be caught in UI-tier code. This ties it inappropriately to an EJB implementation. The EJB tier will take sole charge of communication with EIS-tier resources, and should contain the app's business logic.
This architecture has the following unique strengths:
It can support all J2EE client types by providing a shared middle tier.
The weaknesses of this architecture are:
This is the most complex approach we've considered. If this complexity isn't warranted by the business requirements, it's likely to result in wasted resources throughout the project lifecycle and provide a breeding ground for bugs.
When using this architecture, don't subvert it. For example, Sun Java Center's "Fast Lane Reader" J2EE pattern (http://java.oracle.com/blueprints/patterns/j2ee_patterns/fast_lane_reader/) advocates performing read-only JDBC access from the web tier so as to minimize the overhead of calling through the EJB tier. This violates the principle that each tier should only communicate with those immediately above on beneath it. It also reduces the deployment flexibility that is a key virtue of the distributed architecture. Now servers running the web tier must be able to access the database, which may necessitate special firewall rules.
| Note |
Even if we use remote interfaces, most J2EE servers can optimize out remote invocations and substitute call by reference if EJBs and components that use them are collocated. This may greatly reduce the performance impact of using EJBs with remote interfaces but cannot undo the harmful effects that remote semantics introduce. This configuration changes the semantics of the app. For this configuration to be used, it's vital to ensure that the EJBs support local invocation (by reference) and remote invocation (by value). Otherwise, callers by reference may modify objects to be passed to other callers with serious consequences. |
| Important |
Do not let the use of EJBs with remote interfaces cause an app to be distributed unless business requirements dictate a distributed architecture. |
The emergence of web services standards such as SOAP means that J2EE apps are no longer tied to using RMI and EJB to support remote clients. The following architecture can support non-J2EE clients such as Microsoft apps:
This architecture adds an object layer exposing the web services, and a transport layer implementing the necessary protocols, to any J2EE app. Web services components may either run in the same web container as a traditional web interface, or the web service interface may be the only one exposed by the app. The object layer may be simply the app's business interfaces. The details of the transport layer will vary (J2EE does not presently standardize support for web services), but J2EE servers such as WebLogic make it easy to implement. Third-party products such as Apache Axis provide easy SOAP web services support on any J2EE server. For example, Axis provides a servlet that can be added to any web app and can publish any app class, including generating WSDL, as a web service. This is a very simple operation. This architecture differs from the distributed EJB architecture we've just described not only in remoting protocol, but in that remote interfaces are typically added onto an existing app, rather than built into the structure of the app. The diagram opposite shows web services being exposed by a web app without EJB. We can use this approach to add web services to any of the three architectures we've described (especially the first or second. The use of web services remoting removes one major reason to use EJBs with remote interfaces).
| Note |
It's possible that web services protocols such as SOAP will eventually supplant platform-specific protocols such as RMI. This seems to be Microsoft's belief as it moves away from its proprietary DCOM remoting technology. |
These are the strengths of this architecture:
SOAP is more open than RMI/IIOP. This architecture can support clients other than J2EE-technology clients, such as VB apps.
The weaknesses of this architecture are:
Performance. The overhead of passing objects over an XML-based protocol such as SOAP is likely to be higher than that of RMI.
| Note |
EJB apps can also expose web services. WebLogic and some other servers allow direct exposure of EJBs as web services. |
|
|