6.2 EJB Model to Code Transformation

To explain the EJB model to code transformation in detail, we must zoom in on the overall picture of the relations between all models used in the MDA process. Figure 6-1 shows a refinement of Figure 4-1. In it a distinction is made between the EJB PSM that represents the coarse grained component model, as described in section 5.2, and an EJB PSM that is much closer to the generated code. This PSM contains class definitions, and is called the EJB Class PSM. The EJB Class PSM consists of class diagrams where the classes relate one-to-one to the actual classes in the Java code. You could say that this model is on the same abstraction level as the EJB source code, but in a diagrammatic presentation.

Figure 6-1. The models in the MDA process in detail

In this section, we describe the transformation from the EJB Component PSM to the EJB Class PSM. The EJB Class PSM is written in the language defined by another UML variant, the standardized EJB Profile (Java Community Process document JSR26, 2001). Because the generation of code from the EJB Class PSM is very simple, we do not describe it. Fragments of the generated code can be found in Appendix B.

Before explaining the transformation rules, a small introduction to the specific aspects of entity beans in EJB is given.

6.2.1 Some Remarks on EJB Code

According to the EJB specification (Sun Microsystems, Enterprise JavaBeans Specification, Version 2.1, 2002), a person (or persons) who develops entity beans must provide the following:

• Entity bean class and all classes it depends on.

• Key class.

• Entity bean's remote interface and entity bean's remote home interface, if the entity bean provides a remote client view.

• Entity bean's local interface and local home interface, if the entity bean provides a local client view.

• A deployment descriptor written in XML defining some properties of the EJB components . The deployment descriptor describes the transactional behavior of the business methods , and also the persistence strategy for a component.

If an entity bean is managing its own persistence, then in its own implementation it has to call methods of a persistency API like Java Database Connectivity (JDBC). If the entity bean has container managed persistency, it does not have to call these methods but only has to set its own attributes. These attributes are copied from and to the database by the EJB container. Note that EJB containers are not developed by the EJB component developer but are completely generic, and work for all EJB compliant components.

For Rosa's Breakfast Service, we generate entity beans with container managed persistency. Besides that, we have to generate remote interfaces, remote home interfaces, the key classes, and the deployment descriptors, which are written in XML.

In addition to the code required by the EJB standard, we have chosen to generate coarse grained components and components that do not need any manually added code to work. This implies that the code model consists of Java packages with classes that implement the data classes in the EJB components. Each data class in Java has set- and get-methods and private attributes for maintaining the fine-grain data locally. The EJB component and remote interface need to have methods for getting and setting the data objects remotely. The bodies of the Java methods in the bean implementations consist of procedural code to construct the data objects and process all the changes made in the data objects. Although it helps that we have chosen container-managed persistency, we still have to generate a lot of code.

To make the code of the remote EJB clients simpler, a so-called data object manager is created. The data object manager is a normal local java class that creates an instance of the remote interface and is able to retrieve and store sets of data objects.

Figure 6-2 shows the RemoteInterface, the HomeInterface, and the EJB implementation class for the StandardBreakfast component. Note that the class derived from the PIM class Part does not have its own remote or home interface. It is accessible through the StandardBreakfast .

Figure 6-2. EJB Home, Remote Interface, and EJB Implementation classes

In Figure 6-3 the EJB key classes are shown. In EJB 2.0, the key classes are renamed to Handle classes; therefore, they implement the javax.ejb.Handle class.

Figure 6-3. EJB code for key classes

Finally, Figure 6-4 shows the EJB data classes, which are communicated to clients of the component. As we can see, all access to Part objects can be done through the StandardBreakfastDataObject class.

Figure 6-4. EJB code for data classes

6.2.2 The Transformation Rules

It is clear from the above description that generating the code for the EJB Component PSM is far more complex than for the relational model. The EJB coarse grained model abstracts away many details. These details include all the procedural behavior of the EJB components. Because of the complexity of the details, we will not define all the transformation rules in detail, but give a global picture of the transformation rules needed for generating the EJB Class PSM. Because our target is still a visual model, there is no need to explicitly refer to the Java syntax. For example, we will write "generate a Java class" instead of "first generate 'public class' followed by the name of the class."

The following set of rules is used to generate the classes in the EJB Class PSM for the EJB Entity Components in the EJB Component PSM.

• For each EJB Entity Component, one EJB Entity Home Interface, one EJB Remote Interface, and one EJB Implementation is generated.

• For each business method in an EJB Entity Component, one method in the Remote Interface and one method in the EJB Implementation is generated.

• One "get" method and one "set" method is generated in each EJB Remote Interface and in each EJB Implementation with the corresponding EJB Data Object implementation as result and parameter type.

• All the standard methods (according to the EJB specification) for entity beans are implemented in the EJB Implementation.

• In each EJB Home Interface, three methods are generated: one EJB Create method, one EJB Finder method based on the EJB Key implementation, and one EJB finder method called findall.

The result of the method in the EJB Home Interface called findall is a Collection that contains a set of instances of Remote Interface that give access to all instances of the corresponding EJB Entity Component.

The following rules are used to generate the classes in the EJB Class PSM for the EJB key classes:

• Each EJB key class is transformed into one Java class that implements javax.ejb.Handle .

• For each attribute in an EJB key class, one constructor parameter, and one "get" method is generated in the corresponding implementation.

The following rules are used to generate the EJB Class model PSM for the from EJB Data Classes:

• Each EJB Data Class is transformed into a Java class that implements java.io.Serializable .

• For each attribute in an EJB Data Object, one "get" method and one "set" method is generated in the corresponding serializable Java class.

• For each association end navigable from an EJB Data Object with a multiplicity not higher than 1, one "get" method and one "set" method is generated in the corresponding serializable Java class.

• For each association end navigable from an EJB Data Object with a multiplicity higher than 1, one "get" method with return type Collection, one "add" and one "remove" method is generated in the corresponding serializable Java class.

• The types of the Java parameters and method result types in the EJB Data Object implementation for "get" methods and "set" methods correspond with the Java class that is generated for the type in the source model.

• One constructor per EJB Data Object implementation is generated with one parameter with the corresponding Key Class implementation as its type.

• For each EJB data schema, one data object manager is generated with methods to initialize the EJB remote interface and to retrieve and store sets of data objects.

In Appendix B, you can find some fragments of the generated code.