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:
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.
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:
The following rules are used to generate the EJB Class model PSM for the from EJB Data Classes:
In Appendix B, you can find some fragments of the generated code.