The UML-to-EJB transformation transforms Unified Modeling Language (UML) model elements into enterprise beans and Java code. The UML-to-EJB transformation is the same as the UML-to-Java transformation, but it can also generate enterprise beans from UML elements that are marked with stereotypes from the EJB transformation profile.
You should be familiar with the UML-to-Java transformation before you use the UML-to-EJB transformation.
UML-to-EJB transformation configuration tabs
Interpretation of source objects
Support for common transformation technologies
Integration with team functionality
Source-to-target relationships
You can select one or several items from the Model Explorer view as the source for the UML-to-EJB transformation. The following table lists the items that the transformation accepts as a valid source:
Source |
Result |
UML model |
Transforms all packages, classes, and interfaces in the model |
UML package |
Transforms the package and all classes and interfaces in that package |
UML class |
Transforms the class and all the attributes, operations, classes, and interfaces in that class Note: The parent of the class must be a UML package |
UML interface |
Transforms the interface and all the attributes, operations, classes, and interfaces in that interface Note: The parent of the interface must be a UML package |
UML enumeration |
Transforms the enumeration and all the enumeration literals Note: The parent of the enumeration must be a UML package |
To generate enterprise beans from a source model, the source model must have the EJB transformation profile applied to it, and the model elements must be marked with stereotypes from the EJB transformation profile.
The UML-to-EJB transformation accepts a single EJB project as its target. You can create the EJB project with or without a client project. The transformation generates code in the first source folder that it detects in the EJB project (typically ejbModule) and in the first source folder that it detects in the client project (typically src), if a client project exists.
The version of the EJB container that is associated with the EJB project affects the UML-to-EJB transformation. Each version of EJB container has different rules that must be followed for the UML-to-EJB transformation to function and process properly. The following table lists the rules that are associated with the different versions of EJB containers:
EJB container version |
Rules that affect the transformation |
2.1 |
Container-managed persistence (CMP) 1.1 beans must be generated with remote interfaces only |
2.0 |
CMP 1.1 beans must be generated with remote interfaces only |
1.1 |
|
If the above rules are not followed before you run the transformation, the EJB transformation does not process the source model and transforms nothing.
The EJB transformation profile defines stereotypes that the UML-to-EJB transformation interprets to generate enterprise beans. The following table lists the stereotypes that the EJB transformation profile defines:
Stereotype |
Target element |
UML-to-EJB transformation interpretation |
<<entity>> |
UML class |
Represents an entity bean |
<<service>> |
UML class |
Represents a session bean with a stereotype property, hasState, that is initially set to false, which signifies that the session bean is stateless. |
<<messageprocessor>> |
UML class |
Represents a message-driven bean |
<<id>> |
UML attribute |
Represents a CMP or BMP field to be used as part of the primary key of an entity bean |
<<query>> |
UML operation |
Represents a query method on an entity bean |
The EJB transformation profile also defines the following constraints:
When you validate a model with the EJB transformation profile, these constraints generate warnings. Before you run the UML-to-EJB transformation, you should correct the issues that generate the warnings. However, the warnings do not prevent you from running the transformation.
The EJB transformation configuration window contains six tabs: Target, Entity, Session, Advanced, Mapping, and Common. This section describes how the first three tabs affect the EJB transformation.
You can use the Target tab to select the target EJB project in which the EJB transformation generates the output files. You can create a new target container even if an EJB project is available. Each project is associated with a single EJB container. The EJB transformation supports all the available EJB container versions that the EJB project wizard provides.
The version of the target EJB project container might restrict the options that are available on the Entity and Session tabs. For more information about the restrictions for each type of EJB container, see the Target EJB container section.
You can use the Entity tab to customize newly generated entity beans. You can configure two different options on the Entity tab: Entity bean type and Entity bean interface. The following figure shows the Entity tab in the EJB transformation configuration window:
Depending on the version of the EJB container in the project, you can only select certain combinations of properties before you can run the EJB transformation. The following table lists the entity bean types that the transformation supports, the interfaces that the entity beans support, and the default interface selection:
EJB container version |
Entity bean type |
Supported interfaces for entity beans |
Default selection |
2.x |
CMP 2.x |
Local and remote |
Local interfaces only |
2.x |
CMP 1.1 |
Remote |
Remote interfaces only |
2.x |
BMP |
Local and remote |
Local interfaces only |
1.1 |
CMP 2.x |
None |
N/A |
1.1 |
CMP 1.1 |
Remote |
Remote interfaces only |
1.1 |
BMP |
Remote |
Remote interfaces only |
The default selections in the table reflect the default behavior of the entity bean creation wizard.
If you select an invalid combination of options, an error message is displayed at the top of the EJB transformation configuration window and the Run button that runs the transformation is unavailable. When you select a valid combination of options, the Run button becomes available and the error message disappears.
You can use the Session tab to customize the generation of interfaces for newly generated session beans. The following figure shows the Session tab in the EJB transformation configuration window:
Depending on the version of the EJB container in the project, you can only select certain combinations of properties before you can run the EJB transformation. The following table lists the interfaces that the transformation supports for session beans, according to the version of the EJB container, and the default interface selection:
EJB container version |
Supported interfaces for session beans |
Default selection |
1.1 |
Remote |
Remote interfaces only |
2.0 |
Local and remote |
Remote interfaces only |
2.1 |
Local and remote |
Remote interfaces only |
If you select an invalid combination of options, an error message is displayed at the top of the EJB transformation configuration window and the Run button that runs the transformation is unavailable. When you select a valid combination of options, the Run button becomes available and the error message disappears.
For information about the Advanced tab, see the UML-to-Java transformation documentation.
This section describes how the UML-to-EJB transformation interprets the elements in a UML model and what the transformation generates as output.
The UML-to-EJB transformation interprets primitive types the same way that the UML-to-Java transformation interprets them. For more information, see the UML-to-Java transformation documentation.
The UML-to-EJB transformation interprets packages the same way that the UML-to-Java transformation interprets them: it transforms them into Java packages. For more information, see the UML-to-Java transformation documentation.
The UML-to-EJB transformation interprets unmarked classes the same way that the UML-to-Java transformation interprets them: it transforms them into Java classes. For more information, see the UML-to-Java transformation documentation.
If an unmarked class contains attributes whose type are of a class with an <<entity>>, <<service>>, or <<messageprocessor>> stereotype, the transformation does not generate the attributes. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
The UML-to-EJB transformation interprets unmarked interfaces the same way that the UML-to-Java transformation interprets them: it transforms them into Java interfaces. For more information, see the UML-to-Java transformation documentation.
If an unmarked interface contains attributes whose type are of a class with an <<entity>>, <<service>>, or <<messageprocessor>> stereotype, the transformation does not generate the attributes. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
The UML-to-EJB transformation interprets unmarked enumeration the same way that the UML-to-Java transformation interprets them: it transforms them into Java interfaces. For more information, see the UML-to-Java transformation documentation.
The UML-to-EJB transformation transforms a class that is marked with the <<entity>> stereotype into a CMP 2.x, CMP 1.1, or BMP entity bean with a bean name that is equal to the name of the source UML class. The type of generated entity bean corresponds to the option that you select in the EJB transformation configuration window, on the Entity tab.
The transformation always generates the following Java classes for entity beans:
The transformation generates the following Java classes when, on the Entity tab, you click Remote interfaces only:
The transformation generates the following Java classes when, on the Entity tab, you click Local interfaces only:
The transformation generates the following Java classes when, on the Entity tab, you click Local and remote interfaces:
The transformation generates all classes in the package folder that is generated for the parent package of the source UML class. If you create a UML model without packages, the transformation generates a default package named ejbs.
The transformation generates the bean class and key class files in the source tree of the target EJB project.
The transformation generates the four interface files in the source tree of the client project of the target EJB project. If no client project exists, the transformation generates the interface files in the target EJB project.
The transformation adds data that defines the entity bean to the deployment descriptor (ejb-jar.xml).
Generalization relationships
If the source UML class for the entity bean has a generalization relationship (such as an extends relationship) with another UML class with the <<entity>> stereotype, the entity bean that the class represents becomes the EJB superclass for the entity bean to be generated.
Both entity beans must be of the same type. Therefore, both entity beans must be CMP 2.x, CMP 1.1, or BMP. For example, if the super bean is a CMP 2.x entity bean, all child beans must be CMP 2.x entity beans. If the super bean is not the same type as the expected child bean, the transformation generates the child bean without a generalization relationship.
Realization relationships
If the source UML class for the entity bean has realization relationships (such as implements relationships) with interface elements, the interfaces that the source interfaces represent are implemented by the four interfaces (remote, home, local, local home).
Unmarked attributes - CMP 2.x
The transformation transforms attributes on the source UML class into CMP fields on the entity bean with the properties listed in the following table:
CMP 2.x field property |
CMP field value |
Name |
UML attribute name, with the first character of the field name changed to lowercase |
Type |
Type determined from the attribute type (See the Type map table.) |
Key field |
False |
Generate field in bean implementation class |
False |
Generate getter and setter |
True |
Promote getter and setter to local interfaces |
True (if local interfaces exist) |
Promote getter and setter to remote interfaces |
True (if remote interfaces exist) |
IsArray |
True if the UML attribute has a finite upper value |
If the attribute type is that of another CMP 2.x entity bean, the transformation does not transform the attribute into a CMP field, but assumes that the attribute is part of an association that should be transformed into an EJB relationship. However, if the attribute type is that of another enterprise bean that is not a CMP 2.x entity bean, the transformation does not transform the attribute into a CMP field or an association. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
Unmarked attributes - CMP 1.1
The transformation transforms attributes on the source UML class into CMP fields on the entity bean with the properties listed in the following table:
CMP 1.1 field property |
CMP field value |
Name |
UML attribute name, with the first character of the field name changed to lowercase |
Type |
Type determined from the attribute type (See the Type map table.) |
Key field |
False |
Generate field in bean implementation class |
False |
Generate getter and setter |
True |
Promote getter and setter to local interfaces |
False |
Promote getter and setter to remote interfaces |
True (always) |
IsArray |
True if the UML attribute has a finite upper value |
If the attribute type is that of another entity bean or enterprise bean, the transformation does not transform the attribute into a CMP field or an association. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
Unmarked attributes - BMP
The transformation transforms attributes on the source UML class into BMP fields on the entity bean with the properties listed in the following table:
BMP field property |
BMP field value |
Name |
UML attribute name, with the first character of the field name changed to lowercase |
Type |
Type determined from the attribute type (See the Type map table.) |
Key field |
False |
Generate field in bean implementation class |
True |
Generate getter and setter |
True |
Promote getter and setter to local interfaces |
True (if local interfaces exist) |
Promote getter and setter to remote interfaces |
True (if remote interfaces exist) |
IsArray |
True if the UML attribute has a finite upper value |
If the attribute type is that of another entity bean or EJB, the transformation does not transform the attribute into a BMP field or an association. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
<<id>> attributes - CMP 2.x and CMP 1.1
The transformation also transforms attributes on the source UML class that are marked with the <<id>> attribute into CMP fields, but with different property values, as listed in the following table. These CMP fields help form the primary key.
CMP 2.x and CMP 1.1 field property |
CMP field value |
Name |
UML attribute name, with the first character of the field name changed to lowercase |
Type |
Type determined from the attribute type (See the Type map table.) |
Key field |
True |
Generate field in bean implementation class |
False |
Generate getter and setter |
True |
Promote getter and setter to local interfaces |
False |
Promote getter and setter to remote interfaces |
False |
IsArray |
True if the UML attribute has a finite upper value |
If the attribute type is that of another entity bean or enterprise bean, the transformation does not transform the attribute into a CMP key field or an association. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
<<id>> attributes - BMP
The transformation also transforms attributes on the source UML class that are marked with the <<id>> into BMP fields, but with different property values, as listed in the following table. These BMP fields help form the primary key.
BMP field property |
BMP field value |
Name |
UML attribute name, with the first character of the field name changed to lowercase |
Type |
Type determined from the attribute type (See the Type map table.) |
Key field |
True |
Generate field in bean implementation class |
True |
Generate getter and setter |
True |
Promote getter and setter to local interfaces |
False |
Promote getter and setter to remote interfaces |
False |
IsArray |
True if the UML attribute has a finite upper value |
If the attribute type is that of another entity bean or enterprise bean, the transformation does not transform the attribute into a BMP key field or an association. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
As the following table illustrates, the transformation generates the CMP and BMP fields with types based on the source attribute type:
UML attribute type |
CMP/BMP field type |
boolean |
boolean |
byte |
byte |
char |
char |
float |
float |
int |
int |
long |
long |
short |
short |
Boolean |
java.lang.Boolean |
Byte |
java.lang.Byte |
Char |
java.lang.Char |
Float |
java.lang.Float |
Integer |
java.lang.Integer |
Long |
java.lang.Long |
Short |
java.lang.Short |
String |
java.lang.String |
other |
Fully qualified name |
Unmarked operations
The transformation transforms unmarked operations on the source UML class into business methods on the entity bean. Initially, the operation is transformed in the same manner as an operation on an unmarked UML class. The transformation enforces lowercase naming by making the first character of the method name lowercase if it is a valid uppercase character. The transformed operation is added to the classes listed in the following table, with some modifications.
Class |
Method modifications |
Bean class |
No change |
Local interface |
Interface method |
Remote interface |
Interface method, throws java.rmi.RemoteException |
<<query>> operations - CMP 2.x
The transformation transforms <<query>> operations on the source UML class into one of two types of query methods: finder methods and select methods. Select methods exist only in CMP 2.x entity beans.
The transformation generates finder methods in the classes listed in the following table, with some modifications:
Class |
Method modifications |
Local home interface (if local interfaces exist) |
|
Remote home interface (if remote interfaces exist) |
|
UML operation name |
Finder method name |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Java transform parsed return type |
Finder method return type |
Mapped collection (such as Collection, List, Set, and so on) |
java.util.Collection |
<source class name>[] |
java.util.Collection |
<source class name> OR void |
|
<user defined type name>[] |
java.util.Collection |
<non source class name (for example, String, Integer, and so on)>[] |
java.util.Collection |
<user-defined type name> |
Generate a select method instead of a finder method |
<non-source class name (for example, String, Integer, and so on)> |
Generate a select method instead of a finder method |
The EJB transformation creates a task that indicates that you need to manually add a query to the deployment descriptor for each generated finder method.
The transformation transforms a query operation into a select method if the visibility on the operation is private, or if the return type is different from the name of the source UML class and the entity bean type is CMP 2.x.
Operation visibility |
Return type |
Method type |
Private |
Equal to the source class name |
Select method |
Not private |
Equal to the source class name |
Finder method |
Private |
Not the source class name |
Select method |
Not private |
Not the source class name |
Select method |
The transformation generates select methods in the bean class, with the following modifications:
UML operation name |
Select method name |
xxx |
ejbSelectXxx |
selectXxx |
ejbSelectXxx |
SelectXxx |
ejbSelectXxx |
ejbSelectXxx |
ejbSelectXxx |
Java transform parsed return type |
Select method return type |
Mapped collection( such as Collection, List, Set, and so on) |
Fully qualified name of the collection type (for example, java.util.Collection) |
<source class name>[] |
java.util.Collection |
<source class name> OR void |
Local Interface name |
<user defined type name>[] |
java.util.Collection |
<non source class name (for example, String, Integer, and so on)>[] |
java.util.Collection |
<user-defined type name> |
User-defined type name |
<non-source class name (for example, String, Integer, and so on)> |
Non-source class name |
The EJB transformation creates a task that indicates that you need to manually add a query to the deployment descriptor for each generated select method.
<<query>> operations - CMP 1.1
The transformation transforms <<query>> operations on the source UML class into one type of query method: finder methods. CMP 1.1 entity beans do not support select methods, as they are only available for CMP 2.x entity beans. Therefore, regardless of the return type and visibility of the <<query>> operation, the transformation always generates a finder method in the remote home interface of the entity bean.
As the following table illustrates, the transformation always generates finder methods in the remote home interface, with some modifications:
Class |
Method modifications |
Remote home interface |
|
UML operation name |
Finder method name |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Java transform parsed return type |
Finder method return type |
Mapped collection (such as Collection, List, Set, and so on) |
java.util.Collection |
<source class name>[] |
java.util.Collection |
<source class name> OR void |
Remote interface name |
<user defined type name>[] |
java.util.Collection |
<non source class name (for example String, Integer, and so on)>[] |
java.util.Collection |
<user-defined type name> |
Remote interface name |
<non-source class name (for example, String, Integer, and so on)> |
Remote interface name |
The EJB transformation creates a task that indicates that you need to manually add a query to the deployment descriptor for each generated finder method.
<<query>> operations - BMP
The transformation transforms <<query>> operations on the source UML class into one type of query method: finder methods. BMP entity beans of any version do not support select methods, as they are only available for CMP 2.x entity beans. Therefore, regardless of the return type and visibility of the <<query>> operation, the transformation always generates a finder method in the bean implementation class. The transformation then generates finder methods in the existing interfaces of the entity bean.
As the following table illustrates, the transformation generates finder methods in the following classes, with some modifications:
Class |
Method modifications |
Local home interface |
|
Remote home interface (if remote interfaces exist) |
|
Bean implementation class |
|
UML Operation name |
Finder method name |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
ejbFindXxx |
findEjbFindXxx |
EjbFindXxx |
findEjbFindXxx |
UML Operation name |
Finder method name |
xxx |
ejbFindXxx |
findXxx |
ejbFindXxx |
FindXxx |
ejbFindXxx |
ejbFindXxx |
ejbFindEjbFindXxx |
EjbFindXxx |
ejbFindEjbFindXxx |
Java transform parsed return type |
Finder method return type |
Mapped collection (such as Collection, List, Set, and so on) |
java.util.Collection |
<source class name>[] |
java.util.Collection |
<source class name> OR void |
|
<user defined type name>[] |
java.util.Collection |
<non source class name (for example, String, Integer, and so on)>[] |
java.util.Collection |
<user-defined type name> |
|
<non-source class name (for example, String, Integer, and so on)> |
|
Java transform parsed return type |
Finder method return type |
Mapped collection (such as Collection, List, Set, and so on) |
java.util.Collection |
<class name>[] |
java.util.Collection |
<class name> OR void |
Key class name |
Inner classes
Ignored.
Inner interfaces
Ignored.
The UML-to-EJB transformation transforms a class with the <<service>> stereotype into a container-managed, stateless, or stateful session bean with a bean name that is equal to the name of the source UML class. The transformation always generates the following Java classes for session beans:
The transformation generates the following Java classes when, on the Session tab, you click Remote interfaces only:
The transformation generates the following Java classes when, on the Session tab, you click Local interfaces only:
The transformation generates the following Java classes when, on the Session tab, you click Local and remote interfaces:
The transformation generates all classes in the package folder that is generated for the parent package of the source UML class. If you create a UML model without packages, the transformation creates a default package named ejbs.
The transformation generates the bean class file in the source tree of the target EJB project.
The transformation generates the four interface files in the source tree of the client project of the target EJB project. If no client project exists, the transformation generates the interface files in the target EJB project.
The transformation adds data that defines the session bean to the deployment descriptor (ejb-jar.xml).
Stereotype property - hasState
Each UML class with a <<service>> stereotype has a stereotype property named hasState. When the value of hasState is false, the transformation generates that UML class as a stateless session bean. Conversely, when the value of hasState is true, the transformation generates the UML class as a stateful session bean.
Note: The stereotype property affects only those UML classes that the transformation generates as new session beans.
By default, the hasState property has a value of false, which is consistent with the default settings in the session bean creation wizard.
Generalization relationships
If the source UML class for the session bean has a generalization relationship (such as an extends relationship) with another UML class with the <<service>> stereotype, and that stereotype has the same hasState property value, the session bean that the class represents becomes the EJB superclass for the session bean to be generated.
Realization relationships
If the source UML class for the session bean has realization relationships (such as implements relationships) with interface elements, the interfaces that the source interfaces represent are implemented by the four interfaces (remote, home, local, local home).
Attributes
The transformation transforms attributes on the source UML class into Java properties in the bean class. For more information about how the attributes are transformed, see the UML-to-Java transformation documentation. The transformation enforces lowercase naming by making the first character of the property name lowercase if it is a valid uppercase character.
If the type of the attribute is of another enterprise bean, the EJB transformation does not generate a field and association for the session bean. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
Operations
The transformation transforms operations on the source UML class into business methods on the session bean. Initially, the operation is transformed in the same manner as an operation on an unmarked UML class. Thetransformation enforces lowercase naming by making the first character of the method name lowercase if it is a valid uppercase character. The transformed operation is added to the classes listed in the following table, with some modifications.
Class |
Method modifications |
Bean class |
No change |
Local interface |
Interface method |
Remote interface |
Interface method, throws java.rmi.RemoteException |
The transformation applies the following rules to determine the operation return type based on the operation parameters:
o The operation has return and output parameters
o The operation has more than one output parameter
Inner classes
Ignored.
Inner interfaces
Ignored.
The UML-to-EJB transformation transforms a class with the <<messageprocessor>> stereotype into a message-driven bean with a bean name that is equal to the name of the source UML class and with default data. The transformation generates the following Java class:
The transformation generates the class in the package folder that is generated for the parent package of the source UML class. If you create a UML model without packages, the transformation creates a default package named ejbs.
The transformation generates the bean class file in the source tree of the target EJB project.
The transformation adds data that defines the message-driven bean to the deployment descriptor (ejb-jar.xml).
Generalization relationships
If the source UML class for the message-driven bean has a generalization relationship (such as an extends relationship) with another UML class with the <<messageprocessor>> stereotype, the message-driven bean that the class represents becomes the EJB superclass for the entity bean to be generated.
Realization relationships
Ignored.
Attributes
The transformation transforms attributes on the source UML class into Java properties in the bean class. For more information about how the attributes are transformed, see the UML-to-Java transformation documentation. If the type of the attribute is of another enterprise bean, the EJB transformation does not generate a field and association for the session bean. Instead, the transformation writes a message to the log file that states that the source attribute will not be transformed.
Operations
The transformation transforms operations on the source UML class into typical Java methods, just as though the message-driven bean were a Java class.
Inner classes
Ignored.
Inner interfaces
Ignored.
Typically, the transformation transforms associations the same way as the UML-to-Java transformation: it transforms the endpoint attributes into Java properties.
If an endpoint of the association is a class with an <<entity>>, <<service>>, or <<messageprocessor>> stereotype, the transformation does not transform that endpoint. Instead, the transformation writes a message to the log file in the metadata directory that states that the endpoint property was not transformed. The exception to this occurrence is when the association is between two classes with <<entity>> stereotypes and both classes are generated as CMP 2.x beans. Then, the transformation transforms the UML association into an EJB 2.0 relationship, which is also known as a container-managed relationship (CMR). The following table illustrates the mappings between association properties and EJB relationship properties:
Association property |
EJB relationship property |
End1 |
BeanA |
End2 |
BeanB |
End1 name |
BeanB CMR name |
End2 name |
BeanA CMR name |
End1 navigability |
BeanB navigability |
End2 navigability |
BeanA navigability |
|
|
|
|
The following figure illustrates two UML classes with <<entity>> stereotypes. The association between the classes is generated into a CMR if the transformation generates both entity classes as CMP 2.x entity beans.
After the transformation occurs, the deployment descriptor has an entry to describe the CMR between AEntity and BEntity. As the following figure illustrates, the project's deployment descriptor can display the association between the two CMP 2.x entity beans:
The following table lists how the transformation transforms dependencies and generates EJB references for classes with an <<entity>>, <<service>>, or <<messageprocessor>> stereotype.
UML dependency source |
UML dependency target |
EJB target |
<<entity>> class |
<<entity>> class |
EJB reference |
<<entity>> class |
<<service>> class |
EJB reference |
<<messageprocessor>> class |
<<entity>> class |
EJB reference |
<<messageprocessor>> class |
<<service>> class |
EJB reference |
<<service>> class |
<<entity>> class |
EJB reference |
<<service>> class |
<<service>> class |
EJB reference |
When a target Java 2 Platform, Enterprise Edition (J2EE) project includes at least one bean with the same name and namespace as a UML class in the transformation, a reapplication scenario can occur. A reapplication scenario refers to when the type of the existing enterprise bean matches the type of the enterprise bean to be generated for the corresponding class in the UML model.
When the type of the enterprise bean to be generated is incompatible with the type of the existing enterprise bean, a collision scenario occurs. In a collision scenario, the UML-to-EJB transformation does not update the existing bean and does not generate a new enterprise bean.
The following table lists the expected response of the transformation to possible reapplication scenarios for CMP 2.x entity beans:
Enterprise bean to be generated |
Existing enterprise bean |
Expected scenario |
Transformation response |
CMP 2.x |
CMP 2.x |
Reapplication |
Update CMP fields and methods |
CMP 2.x |
CMP 1.1 |
Reapplication |
Update CMP fields and methods as though it were a regular CMP 1.1-to-CMP 1.1 reapplication scenario |
CMP 2.x |
BMP |
Reapplication |
Update BMP fields and methods as though it were a regular BMP-to-BMP reapplication scenario |
CMP 2.x |
Session (stateful or stateless) |
Collision |
Leave the session bean untouched |
CMP 2.x |
Message-driven |
Collision |
Leave the message-driven bean untouched |
The following table lists the expected response of the transformation to possible reapplication scenarios for CMP 1.1 entity beans:
Enterprise bean to be generated |
Existing enterprise bean |
Expected scenario |
Transformation response |
CMP 1.1 |
CMP 2.x |
Reapplication |
Update CMP fields and methods as though it were a regular CMP 2.x-to-CMP 2.x reapplication scenario |
CMP 1.1 |
CMP 1.1 |
Reapplication |
Update CMP fields and methods |
CMP 1.1 |
BMP |
Reapplication |
Update BMP fields, methods, and associations as though it were a regular BMP-to-BMP reapplication scenario |
CMP 1.1 |
Session (stateful or stateless) |
Collision |
Leave the session bean untouched |
CMP 1.1 |
Message-driven |
Collision |
Leave the message-driven bean untouched |
The following table lists the expected response of the transformation to possible reapplication scenarios for BMP entity beans:
Enterprise bean to be generated |
Existing enterprise bean |
Expected scenario |
Transformation response |
BMP |
CMP 2.x |
Reapplication |
Update CMP fields and methods as though it were a regular CMP 2.x-to-CMP 2.x reapplication scenario |
BMP |
CMP 1.1 |
Reapplication |
Update CMP fields and methods as though it were a regular CMP 1.1-to-CMP 1.1 reapplication scenario |
BMP |
BMP |
Reapplication |
Update BMP fields and methods |
BMP |
Session (stateful or stateless) |
Collision |
Leave the session bean untouched |
BMP |
Message-driven |
Collision |
Leave the message-driven bean untouched |
The following table lists the expected response of the transformation to possible reapplication scenarios for session beans:
Enterprise bean to be generated |
Existing enterprise bean |
Expected scenario |
Transformation response |
Session (stateful or stateless) |
CMP 2.x |
Collision |
Leave the CMP 2.x bean untouched |
Session (stateful or stateless) |
CMP 1.1 |
Collision |
Leave the CMP 1.1 bean untouched |
Session (stateful or stateless) |
BMP |
|
Leave the BMP bean untouched |
Session (stateful) |
Session (stateful only) |
Reapplication |
Update the fields and methods of the session bean |
Session (stateful) |
Session (stateless only) |
Collision |
Leave the stateless session bean untouched |
Session (stateless) |
Session (stateful only) |
Collision |
Leave the stateful session bean untouched |
Session (stateless) |
Session (stateless only) |
Reapplication |
Update the fields and methods of the session bean |
Session (stateful or stateless) |
Message-driven |
Collision |
Leave the message-driven bean untouched |
The following table lists the expected response of the transformation to possible reapplication scenarios for message-driven beans:
Enterprise bean to be generated |
Existing enterprise bean |
Expected scenario |
Transformation response |
Message-driven |
CMP 2.x |
Collision |
Leave the message-driven bean untouched |
Message-driven |
CMP 1.1 |
Collision |
Leave the message-driven bean untouched |
Message-driven |
BMP |
Collision |
Leave the message-driven bean untouched |
Message-driven |
Session (stateful or stateless) |
Collision |
Leave the message-driven bean untouched |
Message-driven |
Message-driven |
Reapplication |
Update the fields and methods of the message-driven bean |
The following table lists the expected response of the transformation to possible reapplication scenarios for unmarked UML classes:
Stereotype on UML class |
Existing enterprise bean |
Expected scenario |
Transformation response |
Unmarked |
CMP 2.x |
Reapplication |
Update the fields and methods of the CMP 2.x entity bean in its existing remote interface |
Unmarked |
CMP 1.1 |
Reapplication |
Update the fields and methods of the CMP 1.1 entity bean in its existing remote interface |
Unmarked |
BMP |
Reapplication |
Update the fields and methods of the BMP entity bean in its existing remote interface |
Unmarked |
Session (stateful or stateless) |
Reapplication |
Update the fields and methods of the Session in its existing remote interface |
Unmarked |
Message-driven |
Reapplication |
Generate a typical Java class |
In the reapplication scenarios for unmarked UML classes, the code updates to the remote interface of the existing enterprise bean cause build errors in the EJB project. These build errors occur because the updated code in the remote interface does not conform to EJB specifications for remote interfaces. If you intend to overwrite the entire enterprise bean, you must remove the existing enterprise bean before you run the EJB transformation.
This section discusses in more detail how the transformation responds to a reapplication scenario and provides more information about what to expect from the transformation after a reapplication.
If a reapplication scenario occurs for a CMP 2.x entity bean, the following modifications might occur:
The following modifications should not occur:
If a reapplication scenario occurs for a CMP 1.1 entity bean, the following modifications might occur:
The following modifications should not occur:
If a reapplication scenario occurs for a BMP entity bean, the following modifications might occur:
The following modifications should not occur:
If a reapplication scenario occurs for a session bean, the following modifications might occur:
The following modifications should not occur:
If a reapplication scenario occurs for a message-driven bean, the following modifications might occur:
The following modifications should not occur:
The following table lists how the UML-to-EJB transformation processes relationships:
UML source element |
Visualized target element |
Relationship type |
Transformation result |
Class with <<entity>> or <<service>> stereotype |
Java interface (UML interface) |
Implementation |
Generated enterprise bean implements the visualized interface |
Class with <<entity>> or <<service>> stereotype |
Java interface (UML interface) |
Realization |
Generated enterprise bean implements the visualized interface |
Class with <<entity>> stereotype |
Visualized entity bean (UML component) |
Association |
CMR relationship |
Class with <<entity>>, <<service>>, or <<messageprocessor>> stereotype |
Visualized entity bean or session bean (UML component) |
Dependency |
EJB reference |
The UML-to-EJB transformation supports integration with team functionality. When you run a transformation with a target project in a source-controlled environment, the system prompts you to add new files to source control and to check out existing files.
The UML-to-EJB transformation provides mapping support similar to the mapping support that the UML-to-Java transformation provides. For information about how to set up and use a mapping model to run a transformation, see the UML-to-Java transformation documentation.
When source classes are marked to be transformed into enterprise beans, the transformation uses the mapped name of the source class as the bean name for the generated enterprise bean.
If the Generate Source to Target Relationships feature is enabled, the transformation adds tags to the API documentation of the generated Java classes and interfaces. The tags contain information that enables tools to trace the generated files to the original UML source element.
For generated enterprise beans, all the Java files that the transformation generates for an enterprise bean have the source-to-target API documentation tags point to the single UML source class.
Terms of use | Feedback
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.