5.2 The PIM to EJB Transformation

To complete the system for Rosa's Breakfast Service we need to generate an EJB PSM. We will make a number of architectural choices in the way that we use the EJB framework. These choices are specific for Rosa's Breakfast Service. Depending on the project requirements and the possibilities offered by the available tools, you will need to make your own choices in your own situation. We start out by explaining some aspects of the choices we have made regarding the EJB PSM.

5.2.1 A Coarse Grained EJB Model

The EJB model for Rosa's Breakfast Service is structured in a rather different manner than the PIM. We could have built a component model for Rosa's Breakfast Service by simply generating a component for each class. However, it is crucial for the performance of EJB components in a distributed environment with remote access that the communication between components remains minimal.

The attributes of an object could be exchanged one by one, where each get- or set-operation on an attribute value causes a remote method invocation. This is a straightforward, but rather naive approach. To minimize the frequency of interaction between components, wherever possible, it is better to exchange all attributes of an object in one remote call. This results in messages that are more complex, and include a relatively high amount of data, and in component interfaces that have a relatively low number of operations, relieving the burden on the communication network.

Furthermore, it is better to keep the number of components relatively small, because intercomponent communication will not burden the network, whereas intracomponent communication will. To minimize the number of components, we can combine closely related classes into one component, instead of having a component for each of them separately. We call a component model that adheres to these principles a coarse grained component model.

A coarse grained component model is a model of components where the components are large and have infrequent interaction with a relatively high amount of data in each interaction.

In contrast to the coarse grained component model there is the fine grained component model.

A fine grained component model is a model of components where the components are small and have frequent communication with a low amount of data in each interaction.

For Rosa's Breakfast Service we have chosen to use a coarse grained EJB component model. There are a number of books where you can find out more about component models (for example, Cheeseman 2001, Szyperski 1998, and Allen 1998). This book does not address that subject.

The interfaces of the coarse grained components have methods to exchange complete sets of associated objects, and they do not have methods for accessing the individual attributes and associations between these objects. Therefore, a number of classes in the source model must be clustered into so-called EJB data schemas.

An EJB data schema is a set of classes, attributes, and associations that is served by an EJB component as a whole.

An EJB data class is a class that is part of an EJB data schema.

To find out which EJB data classes should be part of a data schema, we use the composite aggregation property of the associations in the PIM. Every class that is part of a whole is clustered into the data schema that is generated from the whole. For example, the class Breakfast is defined to be part of the class BreakfastOrder , therefore Breakfast will be clustered in the data schema for BreakfastOrder and there will be no separate data schema or component for Breakfast .

Likewise, association classes are clustered in the data schema that is generated from the associated class that is able to navigate to the other associated class. For example, the class Change would be clustered into the data schema for Breakfast , but because the class Breakfast itself is clustered into the data schema for BreakfastOrder , the class Change becomes part of the data schema for BreakfastOrder as well.

A client of the EJB component can access the details of these clustered classes by getting a so-called EJB data object .

An EJB data object is an instance of an EJB data class.

Each data class has its own local get- and set-operations for its attributes and associations to other data classes. When the client of the EJB component has finished, all changes that need to be made on the data objects are sent back to the EJB component with the request to process all changes.

Besides data classes that are holding the state of the exchanged objects, we need so-called key classes.

An EJB key class is a class that holds the data that is needed to identify EJB data objects.

If a data class has an association to a class that does not reside in the same data schema, it will refer to a key class instead of a data class. In this manner, the amount of exchanged data in one data object is limited to the instances of the classes within one data schema.

5.2.2 The Transformation Rules

Now that we have established that we are going to generate a coarse grained EJB model, we are able to define the rules for the transformation from the PIM to the EJB PSM. Figure 5-2 shows the four EJB components that result from this transformation.

Figure 5-2. Top-level EJB component model for Rosa's system

As explained in the previous section, the granularity of the EJB components is based on the composition of the classes in the domain model. In the transformation rules, we will use the term outermost composition of x to refer to the class that is not a part (via a composite association) of another class and is equal to or the (direct or indirect) container of the class x . To make the following transformation rules readable, we will leave out the words UML and EJB whenever the source and target model are clear.

1. For each PIM class, an EJB key class is generated.

2. Each PIM class that is not a composite part of another PIM class is transformed into an EJB component and an EJB data schema.

3. Each PIM class is transformed into an EJB data class residing in an EJB data schema that is generated from the PIM class that is the outermost composition of the transformed PIM class.

4. Each PIM association is transformed into an EJB association within an EJB data schema that is generated from the PIM class that is the outer-most composition of the transformed PIM association.

5. Each PIM association class is transformed into two EJB associations and an EJB data class. The EJB associations and the EJB data class are generated within the EJB data schema that is generated from the PIM class that is the outer-most composition of the PIM class that can navigate across the transformed PIM association class.

6. Each PIM attribute of a class is transformed into an EJB attribute of the mapped EJB data class.

7. Each PIM operation is transformed into an EJB operation of the generated EJB component that is generated from the PIM class that is the outer-most composition of the PIM class that owns the transformed PIM operation.

Figure 5-3 depicts the EJB data schemas of the Comestible and StandardBreakfast components. As indicated by the composition relations between the classes in the PIM, the Comestible data schema includes only the Comestible EJB data class, while the StandardBreakfast data schema includes the EJB data classes StandardBreakfast and Part .

Figure 5-3. EJB component model including the data schemas