Deployment Layer - How to be a Successful Technical Architect for J2EE Applications

Deployment Layer

Objects in the deployment layer—called deployment wrappers—are the heart of J2EE architecture. Deployment wrappers publish business object functionality to Java classes that could be on separate machines (including anything in the presentation tier). Examples of deployment wrappers include enterprise beans (e.g., session beans, message-driven beans), RMI services, and Web services. CORBA services are also deployment wrappers but are not considered a traditional part of J2EE architecture.

I consider entity beans to be DAOs, not deployment wrappers. Although technically you can call entity beans from remote clients, doing so slows performance and is therefore not recommended. Calls to entity beans are usually consolidated in session beans. This practice is known as a session bean fa鏰de.

Use enterprise beans to publish business logic. Some developers consider enterprise beans to represent business logic. Although it is technically possible to consolidate what I call business objects and enterprise beans into the same class, I don't recommend it. Keeping the business logic separate gives you complete deployment flexibility. You can deploy the same business object as an enterprise bean, message-driven bean, a CORBA service, a Web service, or even a client application with no changes to the underlying business object. Separating the business logic into deployment-independent classes does create additional classes, but the classes are less complex.

Document a deployment wrapper as one class in your object model, even though it's composed of several classes. Take a stateless session bean example. A session bean has a client proxy, an interface, a bean, and a home object implementation. With the exception of the home implementation, all these classes will contain the same method signatures. There's no value in tediously documenting every piece of the deployment layer.

Choosing Deployment Wrappers

You can have multiple deployment wrappers for the same business object. For example, it is not uncommon to create a message-driven bean and a Web service deployment for a customer object.

Each type of deployment wrapper has its advantages and disadvantages. Choosing which type of deployment wrapper to use is difficult if you haven't substantially completed use-case analysis and prototyping (chapter 3) or defining application interfaces (chapter 4). Table 5.3 summarizes the differences between the types of deployment wrappers.

Table 5.3: Features of Deployment Wrapper Types
Feature	EJB	Web Services	Messaging/JMS	RMI	HTTP	CORBA
Caller platform requirements	Java-compliant only	Any	Any	Java-compliantonly	Any	Any
Communication method supported	Synch. only	Both	Both	Synch. only	Synch. only	Synch. only
Coupling	Tight	Loose	Loose	Tight	Loose	Loose
Transaction support	Local and JTA	Local and JTA	Local	Local	Local	Local
Requires J2EE container?	Yes	No	No	No	No	No
Supports clustering for scalability and availability?	Yes	Yes	Yes	No	Yes	Yes

Faced with deciding which deployment wrappers to use and which business objects to publish, ask yourself the following questions; your answers will help you navigate through the decision-making process.

Q:�	Is your business object called from applications that aren't Java?
Q:�	Is your business object likely to be used by dynamic HTML page constructs, such as servlets and JSPs?
Q:�	Does your business object receive and process messages via JMS?
Q:�	Does your business object require two-phase commit functionality?

Answers

A:�	This functionality is commonly deployed as a Web service. Web services completely eliminate any language-to-language restrictions by using a common message protocol, UDDI. Because Web services don't represent a programmatic coupling, they need little deployment coordination. Drawbacks to using Web services are that the standards are still being refined. It's a newer, and thus less mature, technology. Additionally, if the external application is written in a language that supports CORBA and your organization has purchased an ORB supporting that language, you can deploy this functionality as a CORBA service. The CORBA interface is the lowest common denominator so that a wider array of languages can be supported. Supported CORBA languages include C/C++, COBOL, Java, Lisp, PL/I, Python, and Smalltalk. If your messaging vendor supports JMS and also has a native API for the foreign application platform, you should be able to deploy this functionality as a message-driven enterprise bean.
A:�	These business objects should be published with a deployment wrapper instead of being used directly by the presentation layer. This allows you to keep the presentation layer, which is typically hard to debug, less complicated. It also allows you to keep the business logic layer deployment generic. Functionality supporting JSPs and servlets is commonly implemented as a session bean. For best performance, use stateless rather than stateful session beans if the business rules of your application allow it. Avoid using entity beans directly because doing so greatly increases the number of network transmissions and gravely impacts performance.
A:�	Functionality supporting JMS message receipt and processing is commonly implemented via a message-driven enterprise bean. Although the JMS standard was created and refined in the last few years, messaging technology has existed for more than a decade. Most messaging technology vendors have implemented the JMS interface. Messaging is good for transmitting information. This technology is designed more to guarantee delivery than to issue a subsecond response time.
A:�	If it does, deploy the business object as a session bean. Two-phase commit functionality requires JTA and is provided by J2EE containers. Web services or servlets running from within a J2EE container will have access to JTA, but these deployments may be used in environments that don't support JTA.

Common Patterns

The pattern commonly used for deployment wrappers is a combination of the session fa鏰de pattern and the proxy pattern. This combination (or slight variations thereof) works for all the deployment wrappers that I can think of. The session fa鏰de pattern has been especially popular with EJB deployments, but the concept is valid for most types of distributed objects.

One of the primary objectives of the session fa鏰de pattern is to minimize network traffic. Figure 5.8 illustrates how you can effectively combine the session fa鏰de and proxy patterns.

Figure 5.8: Session Fa鏰de Pattern with Proxy Pattern

Although not required by the session fa鏰de pattern, I like to provide client proxies for my distributed services, such as enterprise beans, RMI services, and CORBA services. This makes objects in the deployment layer easier to use because it eliminates the need for a caller in the presentation layer to care about wrapper-specific deployment details. Figure 5.9 depicts enterprise beans deployed in a session fa鏰de pattern.

Figure 5.9: Session Bean Deployment Example