WebSphere Studio Application Developer Version 5 Programming Guide part 42 doc

384 WebSphere Studio Application Developer Version 5 Programming Guide 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 Banking BankEJB EJB ProjectWeb Project JavaBean m:m 1:m Chapter 12. Developing EJB applications 385 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 Facade 2 Facade 3 386 WebSphere Studio Application Developer Version 5 Programming Guide 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. Chapter 12. Developing EJB applications 387 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) 388 WebSphere Studio Application Developer Version 5 Programming Guide 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. Chapter 12. Developing EJB applications 389 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 390 WebSphere Studio Application Developer Version 5 Programming Guide 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. Chapter 12. Developing EJB applications 391 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 392 WebSphere Studio Application Developer Version 5 Programming Guide 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. Name Type Key Local Interface id int Yes N / A title String No Yes firstName String No Yes lastName String No Yes Chapter 12. Developing EJB applications 393 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). . 384 WebSphere Studio Application Developer Version 5 Programming Guide Sample Application: RedBank In this chapter, we are going to reuse the design of the RedBank application, described. WebSphere Studio Application Developer Version 5 Programming Guide The second page lets you specify the project’s name, directory and associated enterprise application project. Type ItsoProGuideEJB. m:m 1:m TransRecord Customer Account Facade Business Model BankEJB 390 WebSphere Studio Application Developer Version 5 Programming Guide Click Next to continue (Figure 12-10). Figure 12-10 Creating