Designing for Enterprise Java Beans

Becoming familiar with the capabilities of J2EE technology is important so that you can begin visualizing a J2EE solution early in your design. For example, by having a firm understanding of EJBs, you can design class diagrams with this technology component in mind. Hence, the overall software development process will be more rapid, and round-trip engineering can be achieved because the design and code are more tightly coupled . Though several excellent software development tools are on the market, the authors of this book have had a great deal of real-life success with the Together ControlCenter product. This tool has very strong built-in support for EJB software development, object-oriented analysis, and seamless WebLogic interoperability.

Note

For more information on the Together ControlCenter product, please visit the Borland Web site, www.borland.com, which recently acquired TogetherSoft.

Enterprise applications provide many improvements on the traditional client/server model. Whereas a client/server application has two logical tiers, the client and the server, a J2EE application has four logical tiers. It is vital that you understand that these tiers are logical and, hence, location transparent. It is possible to have a simple architecture in which all four tiers are physically located on one machine, in which all four tiers are physically separated, or in any other combination. This architecture provides you an unprecedented level of control over the proximity of components to one another, allowing for optimization of system resources for performance or business requirements. Table 6.2 lists the four logical tiers.

Table 6.2. The Four Logical Tiers of an Enterprise Application

Tier Level	Type of Tier	J2EE Service and Components at Tier level
Tier 1	Client tier	Web browser, HTML,
Tier 2	Web server tier	Web server, JSP, Servlet, JNDI
Tier 3	Application server tier	Application server, Enterprise Java Beans, JMS
Tier 4	Database tier	Database server, JDBC

The tiers identify the components that must be designed, the interfaces between the components, and the overall deployment model of the J2EE application. As the Model-View-Controller design pattern dictates, the JSP is the View because it renders the data into the format that will be viewed by the client tier, the entity EJBs are the Model, and the servlets or Session beans are the control. In general, there is a JSP that interfaces with a servlet, which, in turn, is a client to a Session bean. Session beans delegate the persistence requirements to the entity beans, which, in turn , delegate the database calls through JDBC to a database server. The business logic is performed by the Session bean.

Because J2EE provides most of the enterprise framework, the major portion of the original design work therefore is focused on the EJBs themselves . The three major classes of Enterprise Java Beans are the entity bean , session bean , and message-driven beans . Each bean type has unique a characteristic and behavior, which allows them to solve a whole host of distributed application scenarios, as shown in Table 6.3.

Table 6.3. The Three Major Classes of EJBs

Type of Bean	Task Performed
Entity bean	Represents persistent data. Shared by multiple clients .
Session bean	Represents a workflow. Not shared, single client only.
Message-driven bean	Consumes JMS messages. Has no client interface; rather, is a server-side “only technology.

Throughout the analysis and design, you should attempt to identify design patterns. EJBs provide the solution for a number of design patterns, for example:

Note

For more information on design patterns, we strongly recommend the book Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al). Published by Addison Wesley Longman, Inc. ISBN 0-201-63361-1.

• Proxy pattern ” Both entity and session beans use remote interfaces as a proxy to the business logic object that is more expensive to create.

• Factory pattern ” The factory interface that is used to create an instance of the remote interface follows the factory pattern.

• Mediator pattern ” A session bean is often used to centralize control over a group of entity beans.

• Fa §ade pattern ” When a single session bean is used as a simple front-end to a group of entity beans, the session bean is a fa §ade. This layering approach provides a single unified interface to the client to the more complex subsystem.

Stateful and Stateless Session Beans

When your analysis identifies the need for EJB functionality, you will create class diagrams using EJB classes. The Together ControlCenter provides a Class By Pattern tool; when this tool is used to add classes to the class diagram, a Choose Pattern dialog is automatically opened. The EJB Pattern includes the subtypes : Entity EJB, MessageDriven EJB, and Session EJB, as shown in Figure 6.4.

Figure 6.4. The Together ControlCenter provides tools to add classes by pattern to the class diagram including EJB patterns.

Each of the patterns has properties that you can access by right-clicking on the class after it has been added to the diagram. As shown in Figure 6.5, the Session EJB includes a property to choose stateful versus stateless. This affects the code that is automatically generated by Together.

Figure 6.5. The Session EJB Class by Pattern has a full feature list of properties.

A stateless session bean is the simplest type of EJB. The bean does not maintain any state information between method calls. Each method call is like talking to a new instance of the object. The benefit of implementing this type of bean is that memory use is not nearly as impactful as with stateful EJBs because no state is maintained between invocations on behalf of the caller.

In a WebLogic cluster, stateless beans generally scale better because invocations can be routed to any instance, whereas stateful invocations must maintain primary server affinity and state information is replicated to a secondary server for high availability. There is some overhead to this affinity and replication; however, in some cases the high availability and scalable solution can often outweigh the resource cost.

A stateful session bean maintains state for the client between invocations of methods . This ties the client to a specific instance of the session EJB. Stateful session beans are therefore not reusable as stateless session beans. The caching and pooling of a stateful session bean is performed by the EJB container using the ejbActivate() and ejbPassivate() methods, respectively.

Container Managed Persistence (CMP) and Bean Managed Persistence (BMP) Entity Beans

Entity EJBs are added to the class diagram in Together ControlCenter using the Class by Pattern tool. The properties for the entity EJB include a selection for Bean Managed or Container Managed Persistence, as shown in Figure 6.6.

Figure 6.6. Selecting the property type of an Entity EJB using the Together ControlCenter ”Bean or Container Managed persistence.

In Container Managed Persistence (CMP), the attributes of the entity bean are persisted , usually to a relational database, by the EJB container. Attributes in the deployment descriptor provide the mapping between the bean and the relational database. The deployment descriptor is an XML document that describes the location, persistence, and security of the bean. The advantage of CMP is that it makes the bean much easier to implement and also more portable because it uses declarative mapping instead of hard-coded JDBC database access.

In Bean Managed Persistence (BMP), the persistence is implemented by the Enterprise Bean provider. As such, the developer writes the code to interact with the database or other persistent storage to create, update, and delete the data referenced by the entity bean. The advantage of BMP is that it gives you complete flexibility and control of the persistence; however, you should use it only if CMP lacks the capability that you require because you are, in essence, hard-wiring the access, which can limit the bean's portability and reusability.

Every entity bean has a corresponding home interface that controls its life cycle. It provides the methods to create, locate, and remove the entity bean. The usage of the home interface will be evident in the sequence diagram, which shows when the client creates and destroys the bean.

This interface also exposes the remotely accessible methods. When Together ControlCenter is used to design the Java Enterprise Application, the home and remote interfaces are encapsulated by the class that provides the client-link to the Enterprise Java Bean. The client-link is selected from the EJB Clients pattern from the Class By Pattern tool.

Note

Home Interface is applicable for all EJBs except message-driven beans.

J2EE Deployment to WebLogic Server 7.0

An enterprise J2EE application is deployed as an Enterprise Archive (EAR) file, which can contain one or more of each of the two other archive file types: the Web Archive (WAR) and the Java Archive (JAR) files. The WAR contains the servlet classes, images, JSPs, HTML, and other resources. The JAR contains the EJBs and other supporting compiled Java classes. The Together ControlCenter provides the complete platform to Model-Build-Deploy J2EE applications. The J2EE Deployment Expert menu item fully supports deployment for the WebLogic 7.0 application server platform, as shown in Figure 6.7.

Figure 6.7. Targeting a J2EE application deployment to the WebLogic Server 7.0 using the Together ControlCenter's J2EE Deployment Expert.