WebSphere Studio Application Developer Version 5 Programming Guide part 42 doc

Finally, our business entities Customer, Account, and TransRecord are implemented as CMP entity beans with local interfaces, as opposed to regular JavaBeans.. TransRecord Customer Accoun

Sample Application: RedBank

In this chapter, we are going to reuse the design of the RedBank application, described in “Developing Web applications” on page 179 This time, though, we will use EJBs to implement the business model, instead of regular JavaBeans The rest of the application’s layers (control and view) still apply exactly as designed, even though we will have to make some small changes to the facade

to make it work with EJBs instead of JavaBeans

In Figure 12-3 you can see the model layer’s updated design

Figure 12-3 EJB module design

If you compare this model to the Web application model shown in Figure 5-21 on page 111, you can see that the coordinator (Bank) has been replaced with a session EJB (BankEJB) This EJB has a remote interface and uses container demarcated transactions Without any extra code, we are able to count on transaction management for our operations

Finally, our business entities (Customer, Account, and TransRecord) are implemented as CMP entity beans with local interfaces, as opposed to regular JavaBeans By doing so, we automatically gain persistence, security, and transaction management services

On the other hand, this also implies that the control and view layers will not be able to reference these entities directly, because they may be placed in a different JVM This time around, only the session bean (BankEJB) will be able to access the business entities through their local home interfaces

TransRecord

Customer

Account

Facade

Business Model

Session bean - Entity beans

EJB Project Web Project

JavaBean

m:m

1:m

You may be asking yourself, then why we do not expose a remote interface for our entity beans as well? The problem with doing that is twofold First, in such a design, clients would probably make many remote calls to the model in order to resolve each client request This is not a recommended practice because remote calls are much more expensive than local ones Finally, allowing clients to see into the model breaks the layer’s encapsulation, promoting unwanted

dependencies and coupling

Fortunately, this problem has a well-known documented solution: the data transfer object (DTO) design pattern (refer to EJB Design Patterns, by FLoyd Marinescu), also known as value object and transfer object) The idea is to limit inter-layer data sharing to serializable JavaBeans, thus avoiding remote

references This DTO can be created by the session facade or by a builder object (according to the builder design pattern) on its behalf, in case the building process is too complicated or needs validation steps

Figure 12-4 shows the application component model and the flow of events, so that you can see the big picture

Figure 12-4 Application component model and workflow

Note: In general, the session bean is called the facade In our design we use

a JavaBean and a session bean to function as the facade This isolates the Web application completely from the model implementation Only the

JavaBean part of the facade must be changed to interact with the session bean facade instead of another model implementation

Application Server

Web Client

Web Container

EJB Container

EJB Module Web Module

View

Control

Entity Model

1

5

DTO

4

6

HTTP

7

RMI/IIOP

3

1 The first event that occurs is the HTTP request issued by the Web client to the server This request is answered by a servlet in the control layer, also known

as the front controller, which extracts the parameters from the request The servlet sends the request to the appropriate control JavaBean This bean verifies if the request is valid in the current user and application states

2 If so, the control layer sends the request through the JavaBean facade to the session EJB facade This involves using JNDI to locate the session bean’s home interface and creating a new instance of the bean

3 The session EJB executes the appropriate business logic related to the request This includes having to access entity beans in the model layer

4 The facade creates a new DTO and populates it with the response data

5 The front controller servlet sets the response DTO as a request attribute and forwards the request to the appropriate JSP in the view layer, responsible for rendering the response back to the client

6 The view JSP accesses the response DTO to build the user response

7 The result view, possibly in HTML, is returned to the client

Please note that the intent of this chapter is to introduce you to the Application Developer’s tools that make the development of EJBs and enterprise applications possible Together we will work only on a single session bean and three entity beans The rest of the application has already been developed and will be made available to you, so that you can dig into it if you would like to

Creating an EJB project

In Application Developer, you create and maintain Enterprise JavaBeans and associated Java resources in EJB projects The environment has facilities that help you deal with all three types of EJBs, define relationships (association and inheritance), and create resources such as access beans, converters and composers Within an EJB project, these resources can be treated as a portable, cohesive unit

An EJB module typically contains components that work together to perform some business logic This logic may be self-contained, or access external data and functions as needed It should be comprised of a facade and the model The

Note: Converters and composers are used for non-standard relational

mapping A converter allows you to transform a user-defined Java type to an SQL type back and forth Composers are used when entity attributes have multi-column relational representations

facade is usually implemented using one or more remote session beans The model is commonly implemented with related local entity beans and

message-driven beans

In this chapter we develop three entity beans, two relationships, and a session bean We require a J2EE EJB project to support our tasks To create an EJB project, select File -> New -> EJB Project The dialog in Figure 12-5 is displayed

Figure 12-5 Create an EJB project wizard (page 1)

The wizard’s first page asks you to supply the version of the EJB specification you want to use in your project Since this is a brand new project, we want the latest version available Select the Create 2.0 EJB Project option and click Next

to continue to the second page (Figure 12-6)

Figure 12-6 Create an EJB project wizard (page 2)

The second page lets you specify the project’s name, directory and associated enterprise application project Type ItsoProGuideEJB in the Project name field and leave the directory to the default value

We use the existing ItsoProGuide project as enterprise application Alternatively

we could create a new one Select Existing and click Browse to find the project Select it and click OK

Click Next On the Module Dependencies page, select the

ItsoProGuideJava.jar utility JAR file as a dependency (Figure 12-7)

Figure 12-7 Module dependency of EJB project Click Finish to complete the creation of the EJB project

If you already had the enterprise application project added to a server configuration, Application Developer displays the Repair Server Configuration dialog Simply click OK to continue

Data transfer objects and helper classes

We will use the Customer, Account, and TransRecord objects of the utility project

as our data transfer objects (DTOs) In addition we use the exception and the

AmountConverter classes

Implementing the model with entity beans

Our first step towards implementing the RedBank’s model with EJBs is creating the entity beans: Customer, Account, and TransRecord (Figure 12-8)

Figure 12-8 Business entities

Creating the entity beans

We implement the three entity beans in sequence

Define the Customer bean

Switch to the J2EE perspective and select the EJB project you have just created

in the J2EE Hierarchy view Select File -> New -> Enterprise Bean (Figure 12-9)

Figure 12-9 Enterprise Bean Creation Select the ItsoProGuideEJB project from the list

Note: If you select the ItsoProGuideEJB project and New -> Enterprise Bean (context), the project is prefilled

m:m

1:m

TransRecord

Customer

Account Facade

Business Model

BankEJB

Click Next to continue (Figure 12-10).

Figure 12-10 Creating an entity bean (page 1) The three entity beans that we are creating have container-managed persistence fields and comply with the EJB 2.0 specification Select the Entity bean with container-managed persistence (CMP) fields and CMP 2.0 Bean options Type the bean name (Customer), leave the source folder to the default value (ejbModule), and enter the default package (itso.ejb.model.entity) Click Next

to continue (Figure 12-11):

򐂰 This page lets you select the supertype (allowing you to define the inheritance structures, not covered any further in this book), type names, binding name (the name through which the bean is going to be referenced by its clients), which views you would like to create, and finally the key class and CMP attributes

򐂰 Most of the time the suggested values for the binding name and the type names (derived from the bean name) are good, so you do not have to worry about them

򐂰 According to our design, entity beans should have only local interfaces, so make sure not to select the Remote client view check box Application Developer knows about this good practice, so it will only select Local client view by default

Figure 12-11 Creating an entity bean (page 2)

Add the CMP attributes by clicking Add (Figure 12-12)

Figure 12-12 Create a CMP attribute

This dialog lets you specify the characteristics of the new CMP attribute you would like to add to the entity bean Enter the attribute’s name and type

Alternatively, you can browse the type by clicking Browse

If the attribute is an array, select the Array check box and specify the number of the dimensions for it

By selecting the Key field check box, you indicate that the new field should be part of the entity’s unique identifier You may declare as many attributes as you want to perform this role Application Developer is very smart here If you specify just one key attribute of an object type, it will declare that type as the key class in Figure 12-11) If you select an attribute of a non-object type (like int or double),

or if you select more than one key attribute, the environment will automatically create a new key class for you, implement all its methods (including equals and

hashCode), and declare it as the key class

The two last check boxes let you indicate if you want to promote the new attribute (through its getter and setter) to either the remote or the local interfaces, or to both The availability of these options depends on which client views you selected

For the Customer bean, add the fields stated in Table 12-1 If you click Apply, the attribute will be added and the dialog will stay open

Table 12-1 Customer bean’s CMP attributes

Click Close only after adding the last attribute and clicking Apply You are brought back to the wizard, which should look like Figure 12-13

Note: If you do not define at least one key CMP attribute, errors will exist for

the new enterprise bean You can correct them later by adding CMP key attributes

Figure 12-13 Creating an entity bean (page 2) after adding CMP attributes

Note the check box Use the single key attribute type for the key class If you have one key attribute and it is a normal Java type, such as String, Integer, Float,

BigDecimal, and so forth, then a separate key class is not required

Key wrapper classes are required for the simple data types (int, float, char), for JavaBeans, and if there is more than one key attribute

Click Next to continue to the wizard’s last page (Figure 12-14)