Chapter 17 - Implementation

Class Diagram, Entity Relationship Diagram and Database can be used to generate the persistent code while the EJB Diagram can be used to generate the Enterprise JavaBeans. This chapter shows you how to generate the persistent code and Enterprise JavaBeans, and describes how the Object Model maps to ORM-Persistent Class.

In this chapter:

• Introduction
• Generating ORM-Persistable Class from Data, Object Models and Database
• Mapping Object Model to ORM-Persistable Java Class
• Mapping Object Model to ORM-Persistable .NET class
• Generating Enterprise JavaBeans (EJB) from Enterprise JavaBeans Model
• Mapping Enterprise JavaBeans Model to Enterprise JavaBeans
• Deploying Enterprise JavaBeans on Application Server
• Developing a Client Program

Introduction

Persistent code is the object that exposes the ability to store and retrieve data in relational databases permanently. An instance of the persistence class represents a row of a database table. As the persistent code is generated based on the object models, a mapping between object models and relational models is automatically built, which in turn supports your software development in database applications in an easier way.

ORM-Persistable Class

You are provided with three ways to generate persistent code.

1. Generating Persistent Code from ERD
2. Generating Persistent Code from Class Diagram
3. Generating Persistent Code from Database

Generating ORM-Persistable Class from Data Model

You can generate the persistent code from data model in one of the two ways:

1. Using Database Code Generation Dialog Box
2. Using ORM Wizard

Using Database Code Generation Dialog Box

As persistent code is generated based on the object model, and it will be used to manipulate the relational database which is the data model, if the object and data models were not synchronized, the generated persistent code may become malfunction.

Hence, there is a prerequisite of using Database Code Generation dialog box to generate persistent code, which is the synchronization between object and data models. The persistent code will be generated successfully as if the object and data models are synchronized in advance. For information on synchronization from data model to object model, refer to Synchronizing from a Data Model to an Object Model in the Object Model chapter.

To generate the persistent code from data model, synchronize the data model to object model before performing the following steps.

1. On the menu, click Modeling > ORM > Generate Code....

Figure 17.1 - To generate code

For other SDE:

SDE	Method
SDE for JBuilder	On the menu, click Tools > Modeling > ORM > Generate Code....
SDE for NetBeans	On the menu, click Modeling > ORM > Generate Code....
SDE for IntelliJ IDEA	On the menu, click Modeling > ORM > Generate Code....
SDE for JDeveloper	On the menu, click Model > ORM > Generate Code....
SDE for WebLogic Workshop	On the menu, click Modeling > ORM > Generate Code....

Table 17.1

The Database Code Generation dialog box is displayed.

Figure 17.2 - Database code generation dialog

2. Select the language of code to be generated from the drop-down menu of Language, either Java or C#.

Figure 17.3 - The language options

3. Configure the code generation setting with respect to the selected language of code. Refer to the descriptions of Configuring Code Generation Setting for Java and Configuring Code Generation Setting for C# for information on how to configure the code generation setting for Java and C# respectively.
4. Click OK, you will be prompted by the Generate ORM Code/Database dialog box showing the progress of database generation. Click Close when the generation is complete; whereas if generation is failed, you will be prompted by a Message dialog box informing you to find the error/warning message on the Message Pane.

Figure 17.4 - Message dialog

The persistent code is generated.

Configuring Code Generation Setting for Java

By specifying the settings of code generation for Java, the Java persistence class will be generated accordingly.

Figure 17.5 - Configuring Code Generation Setting for Java

• Default Order Collection Type

Select the type of ordered collection to be used in handling the multiple cardinality relationship, either List or Map.

• Default Un-Order Collection Type

Select the type of un-ordered collection to be used in handling the multiple cardinality relationship, either Set or Bag.

• Override toString Method

Select the way that you want to override the toString method of the object. There are three options provided to override the toString method as follows:

• ID Only - the toString method returns the value of the primary key of the object as string.
• All Properties - the toString method returns a string with the pattern "Entity[<column1_name>=<column1_value><column2_name>=(column2_value>...]"
• No - the toString method will not be overridden.
• Error Handling

Select the way to handle errors when they occur.

• Return false/null - It returns false/null in the method to terminate its execution.
• Throw PersistentException - It throws a PersistentException which will be handled by the caller.
• Throw RuntimeException - It throws a RuntimeException which will be handled by the caller.

Figure 17.6 - Error Handle options

• Lazy Collection Initialization

Check the option to avoid the associated objects from being loaded when the main object is loaded. Uncheck the option will result in loading the associated objects when the main object is loaded.

• Association Handling

Select the type of association handling to be used, either Smart, or Standard.

• Smart

With smart association handling, when you update one end of a bi-directional association, the generated persistent code is able to update the other end automatically. Besides, you do not need to cast the retrieved object(s) into its corresponding persistence class when retrieving object(s) from the collection.

• Standard

With standard association handling, you must update both ends of a bi-directional association manually to maintain the consistency of association. Besides, casting of object(s) to its corresponding persistence class is required when retrieving object(s) from the collection.

Figure 17.7 - Association Handling options

• Persistent API

Select the type of persistent code to be generated, either Static Methods, Factory Class, DAO or POJO.

Figure 17.8 - Persistent API options

• Generate Criteria

You can check the option for Generate Criteria to generate the criteria class for each ORM Persistable class. The criteria class supports querying the database by specifying the searching criteria. For information on using the criteria, refer to the description of Using Criteria Class in the Manipulating Persistent Data with Java chapter.

• Select Optional Jar

You are allowed to select the libraries and JDBC driver to be included in the generation of the orm.jar file. Click on the Select Optional Jar button, the Select Optional Jar dialog box is displayed. Check the desired libraries to be included in the orm.jar which will be built at runtime.

Figure 17.9 - Select Optional Jar

• Samples

Sample files, including Java application sample, servlet sample and Java Server Page (JSP) sample are available for generation. The generated sample files guide you through the usage of the Java persistence class. You can check the options to generate the sample files for reference.

Figure 17.10 - General samples options

• Scripts

Scripts, including Ant File, Batch and Shell Script are available for generation. You can execute the generated scripts directly.

Figure 17.11 - Generate scripts options

Configuring Code Generation Setting for C#

By specifying the settings of code generation for C#, the C# persistence class will be generated accordingly.

Figure 17.12 - Configuring Code Generation Setting for C#

• Default Order Collection Type

Select the type of ordered collection to be used in handling the multiple cardinality relationship, either List or Map.

• Default Un-Order Collection Type

Select the type of un-ordered collection to be used in handling the multiple cardinality relationship, either Set or Bag.

• Override toString Method

Select the way that you want to override the toString method of the object. There are three options provided to override the toString method as follows:

• ID Only - the toString method returns the value of the primary key of the object as string.
• All Properties - the toString method returns a string with the pattern

  "Entity[<column1_name>=<column1_value><column2_name>=(column2_value>...]"

• No - the toString method will not be overridden.
• Error Handling

Select the way to handle errors when they occur

.
• Return false/null - It returns false/null in the method to terminate its execution.
• Throw PersistentException - It throws a PersistentException which will be handled by the caller.

Figure 17.13 - Error Handling checkbox

• Lazy Collection Initialization

Check the option to avoid the associated objects from being loaded when the main object is loaded. Uncheck the option will result in loading the associated objects when the main object is loaded.

• Association Handling

Select the type of association handling to be used, either Smart, or Standard.

• Smart

With smart association handling, updating one end of a bi-directional association will update the other end automatically. Besides, casting of object(s) is not needed when retrieving object(s) from the collection.

• Standard

With standard association handling, both ends of a bi-directional association must be updated manually to maintain the consistency of association. Besides, casting of object(s) is required when retrieving object(s) from the collection.

Figure 17.14 - Association Handling options

• Persistent API

Select the type of persistent code to be generated, either Static Methods, Factory Class, DAO or POJO.

Figure 17.15 - Persistent API options

• Generate Criteria

You can check the option for Generate Criteria to generate the criteria class for each ORM Persistable class. The criteria class supports querying the database by specifying the searching criteria. For information on using the criteria, refer to the description of Using Criteria Class in the Manipulating Persistent Data with .NET chapter.

• C# Assembly Name

Specify the name of the assembly for the .NET application which holds the assembly metadata.

• Compile to DLL

By checking the option of Compile to DLL, the DLL files will be generated, which can be referenced by .NET projects of language other than C# source.

Figure 17.16 - Compile to DLL setting

• Sample

Sample files, C# project file are available for generation for reference. The generated sample files guide you through the usage of the .NET persistence class. You can check the options to generate the sample files.

Figure 17.17 - generate sample options

Using ORM Wizard

For information on generating persistent code from data model by using wizard, refer to the descriptions of Generating Code and Database from ERD in the Using ORM Wizard chapter.

Generating ORM-Persistable Class from Object Model

You can generate the persistent code from object model in one of the two ways:

1. Using Database Code Generation Dialog Box
2. Using ORM Wizard

Using Database Code Generation Dialog Box

Persistent code is designed to manipulate the relational database. The persistent code maps to object model; and meanwhile, data model maps to relational database. Thus, synchronization between object model and data model is important such that the object-relational mapping environment can be built successfully.

Hence, synchronizing the object model to data model is the prerequisite of using Database Code Generation dialog box. For more information, refer to Synchronizing from an Object Model to a Data Model in the Data Model chapter.

For information about using Database Code Generation dialog box, refer to Using Database Code Generation Dialog Box section.

Using ORM Wizard

For information on generating persistent code from object model by using wizard, refer to the descriptions of Generating Code and Database from Class Diagram in the Using ORM Wizard chapter.

Generating ORM-Persistable Class from Database

You can generate the persistent code from database by using Wizard. For more information, refer to the descriptions of Generating Code from Database in the Using ORM Wizard chapter.

Mapping Object Model to ORM-Persistable Java Class

The persistent code can be generated with the support on mapping from Object Model to Persistent Code. In this section, examples will be given to show the mapping between object model and Java persistence class.

Mapping Classes, Attributes and Data Type

For each class element which may have attributes and methods in the object model, a corresponding Java class will be generated. The generated ORM persistable Java class will have the name as same as the name of the class element for identification. As if the class element has attributes with specified data types, all the attributes and data types will map to the Java class as well.

Example:

Figure 17.18 - Mapping Classes, Attributes and Data Type

In the above example, an ORM-Persistable Java class, Product was generated according to the class Product in the object model. There are three types of mapping shown above:

1. Mapping Class Name

The name of the class, Product maps to the name of the Java class, Product. (It is illustrated by the red line in the diagram.)

2. Mapping Attribute

The attributes of the class map to the attributes of the Java class. (It is illustrated by the green line in the diagram.) Besides, a pair of getter and setter methods for the corresponding attribute is generated to the Java class.

3. Mapping Data Type

The data type of the class maps to the data type of the Java Class. (It is illustrated by the blue line in the diagram.)

Mapping Data Type

The following table shows the data type mapping between object model and Java persistent code.

Mapping Primary Key

As object model maps to data model bridging the environment between object model and relational database, primary key is mapped. As the object model maps to persistent code, primary key is in turn mapped.

Example:

Figure 17.19 - Mapping Primary Key

In the above example, the primary key of Product entity, ProductID maps to an attribute, ProductID of class element, Product, which in turn becomes an attribute of the Java class.

In the ORM-Persistable class, a pair of getter and setter methods for the attribute is generated for accessing its value. Besides, the ORM-Persistable class has a method named as getORMID which returns the primary key value of the class.

In the above example, the getORMID() method returns the value by calling the method getProductID() which returns the value of ProductID. It thus signifies ProductID is the primary key of the class.

Mapping Generalization

Generalization distributes the commonalities from the superclass among a group of subclasses. The subclass is consistent with the superclass and it may contain additional attributes and methods to make it specific.

Mapping generalization hierarchy to persistent code, the superclass and its subclasses are generated to individual Java class while the subclasses inherit all the superclass attributes and methods.

Example:

Figure 17.20 - Mapping generalization

In the above example, the generalization hierarchy of BankAccount, CheckingAccount and SavingAccount maps to three ORM-Persistable Java classes where the subclasses, CheckingAccount and SavingAccount extend their superclass, BankAccoount so as to inherit the BankAccount's attributes and methods.

Mapping Association and Multiplicity

The role name of the association maps to an attribute which specifies how the class associates with its associated supplier class with respect to multiplicity. If a class has a multiplicity of many in an association, the class maps not only to an ORM persistent Java class, but also to a collection class which supports manipulating the objects within a collection.

You are allowed to define the type of collection class for code generation. Meanwhile, List and Set are the default types for ordered and un-ordered collection respectively.

Example:

Figure 17.21 - Entity Relation Diagram

In the above object model, there is a one-to-many association between Customer class and PurchaseOrder class; defining that a customer can place many purchase order meanwhile a purchase order is placed by one customer. As object model maps to persistent code, three ORM-Persistable classes will be generated, including Customer, PurchaseOrder and PurchaseOrderSetCollection classes.

Figure 17.22 - Mapping Association and Multiplicity

From the above diagram, PurchaseOrder class has the role of "PlacedBy" in the association and it is associated with the Customer class with multiplicity of one. The role, "PlacedBy" maps as an attribute to the PurchaseOrder class which is defined as the data type of Customer class; it implies that the attribute "PlacedBy" stores a customer object which places the particular purchase order.

Figure 17.23 - Mapping an association

From the above diagram, Customer has the role of "Places" in the association which associates with many PurchaseOrder instances. As the PurchaseOrder class has the multiplicity of many in the association, a collection class is generated so as to manipulate the multiple instances of PurchaseOrder. The role, "Places" maps as an attribute to the Customer class with the data type of PurchaseOrderSetCollection class; it implies that the attribute "Places" represents a collection of PurchaseOrder objects which was placed by a particular customer.

Mapping Navigable Association

An association, which specifies a semantic relationship occurring between typed instances, has at least two ends represented by properties. When a property at an end of the association is owned by an end class, it represents the association is navigable from the opposite ends. On the contrary, when a property does not appear in the namespace of any associated class, it represents a non-navigable end of the association.

An open arrowhead on the end of an association indicates the end is navigable. Meanwhile, a small cross (x) on the end of an association indicates the end is not navigable. If an association has two navigable ends, it is considered as bi-directional associations.

As the role name of the association maps to an attribute which specifies how the class associates with its associated class, however if the association has a non-navigable end, the corresponding role name will not map to an attribute, suppressing the ownership of the class.

Example:

Figure 17.24 - Class Diagram with navigable

In the above object model, it shows a binary association with one end navigable and the other non-navigable. It indicates that Product is owned by OrderLine while Product cannot own OrderLine. As the object model maps to persistent code, the ownership of OrderLine instance in Product class will not be generated in the persistent code.

Figure 17.25 - Mapping with navigable

From the above diagram, OrderLine class has the role of "Orders" in the association and associated with the one Product instance. The role, "Orders" maps as an attribute to OrderLine class which defines as the data type of Product; it implies that the attribute "Orders" stores a product instance.

On the other hand, Product class has the role of "OrderedBy" associated with many OrderLine instances in a non-navigable association; that is, Product class does not have the ownership of OrderLine. Even though the OrderLine class has the multiplicity of many in the association, the corresponding collection class of OrderLine for the Product class is not generated to manipulate it.

Mapping Object Model to ORM-Persistable .NET Class

As the .NET persistence class can be generated with the support on mapping from Object Model to Persistent Code. In this section, examples will be given to show the mapping between object model and .Net persistence class.

Mapping Classes, Attributes and Data Type

For each class element which may have attributes and methods in the object model, a corresponding persistence class of C# will be generated. The generated ORM persistable .NET class will have the name as same as the name of the class element for identification. As if the class element has attributes with specified data types, all the attributes and data types will map to the .NET persistence class as well.

Example:

Figure 17.26 - Mapping Classes, Attributes and Data type

In the above example, an ORM-Persistable .NET class, Product was generated according to the class Product in the object model. There are three types of mapping shown above:

1. Mapping Class Name

The name of the class, Product maps to the name of the .NET persistence class, Product. (It is illustrated by the red line in the diagram.)

2. Mapping Attribute

The attributes of the class map to the attributes of the .NET persistence class. (It is illustrated by the green line in the diagram.) Besides, a pair of getter and setter methods for the corresponding attribute is generated to the persistence class.

3. Mapping Data Type

The data type of the class maps to the data type of the .NET persistence class. (It is illustrated by the blue line in the diagram.)

Mapping Data Type

The following table shows the data type mapping between object model and .NET persistent code.

Mapping Primary Key

As object model maps to data model bridging the environment between object model and relational database, primary key is mapped. As the object model maps to persistent code, primary key is in turn mapped.

Example:

Figure 17.27 - Mapping Primary Key

In the above example, the primary key of Product entity, ProductID maps to an attribute, ProductID of class element, Product, which in turn becomes an attribute of the .NET persistence class.

In the ORM-Persistable .NET class, a pair of getter and setter methods for the attribute is generated for accessing its value. Besides, the ORM-Persistable .NET class has a method of getting the ORMID which returns the primary key value of the class.

In the above example, the getter method of ORMID returns the value by calling the getter method of ProductID which returns the value of __ProductID. It thus signifies ProductID is the primary key of the class.

Mapping Generalization

Generalization distributes the commonalities from the superclass among a group of subclasses. The subclass is consistent with the superclass and it may contain additional attributes and methods to make it specific.

Mapping generalization hierarchy to persistent code, the superclass and its subclasses are generated to individual .NET persistence class while the subclasses inherit all the superclass attributes and methods.

Example:

Figure 17.28 - Mapping generalization

In the above example, the generalization hierarchy of BankAccount, CheckingAccount and SavingAccount maps to three ORM-Persistable .NET classes where the subclasses, CheckingAccount and SavingAccount extend their superclass, BankAccoount so as to inherit the BankAccount's attributes and methods.

Mapping Association and Multiplicity

An association specifies the semantic relationship between two classes in the object model with a role attached at one end. The role specifies the detailed behavior of a class associated in the association, including its role name, which indicates how the class acts in the association; and multiplicity, which specifies the number of links between each instance of the associated classes.

The role name of the association maps to an attribute which specifies how the class associates with its associated supplier class with respect to multiplicity. If a class has a multiplicity of many in an association, the class maps not only to an ORM persistent .NET class, but also to a collection class which supports manipulating the objects within a collection.

You are allowed to define the type of collection class for code generation. Meanwhile, List and Set are the default types for ordered and un-ordered collection respectively.

Example:

Figure 17.29 - Class Diagram with association and multiplicity

In the above object model, there is a one-to-many association between Customer class and PurchaseOrder class; defining that a customer can place many purchase order meanwhile a purchase order is placed by one customer. As object model maps to persistent code, three ORM-Persistable .NET classes will be generated, including Customer, PurchaseOrder and PurchaseOrderSetCollection classes.

Figure 17.30 - Mapping Association

From the above diagram, PurchaseOrder class has the role of "PlacedBy" in the association and it is associated with the Customer class with multiplicity of one. The role, "PlacedBy" maps as an attribute to the PurchaseOrder class which is defined as the data type of Customer class; it implies that the attribute "PlacedBy" stores a customer object which places the particular purchase order.

Figure 17.31 - Mapping Multiplicity

From the above diagram, Customer has the role of "Places" in the association which associates with many PurchaseOrder instances. As the PurchaseOrder class has the multiplicity of many in the association, a collection class is generated so as to manipulate the multiple instances of PurchaseOrder. The role, "Places" maps as an attribute to the Customer class with the data type of PurchaseOrderSetCollection class; it implies that the attribute "Places" represents a collection of PurchaseOrder objects which was placed by a particular customer.

Mapping Navigable Association

An association, which specifies a semantic relationship occurring between typed instances, has at least two ends represented by properties. When a property at an end of the association is owned by an end class, it represents the association is navigable from the opposite ends. On the contrary, when a property does not appear in the namespace of any associated class, it represents a non-navigable end of the association.

An open arrowhead on the end of an association indicates the end is navigable. Meanwhile, a small cross (x) on the end of an association indicates the end is not navigable. If an association has two navigable ends, it is considered as bi-directional associations.

As the role name of the association maps to an attribute which specifies how the class associates with its associated class, however if the association has a non-navigable end, the corresponding role name will not map to an attribute, suppressing the ownership of the class.

Example:

Figure 17.32 - Class Diagram with Navigable

In the above object model, it shows a binary association with one end navigable and the other non-navigable. It indicates that Product is owned by OrderLine while Product cannot own OrderLine. As the object model maps to persistent code, the ownership of OrderLine instance in Product class will not be generated in the persistent code.

Figure 17.33 - Mapping with Navigable

From the above diagram, OrderLine class has the role of "Orders" in the association and associated with the one Product instance. The role, "Orders" maps as an attribute to OrderLine class which defines as the data type of Product; it implies that the attribute "Orders" stores a product instance.

On the other hand, Product class has the role of "OrderedBy" associated with many OrderLine instances in a non-navigable association; that is, Product class does not have the ownership of OrderLine. Even though the OrderLine class has the multiplicity of many in the association, the corresponding collection class of OrderLine for the Product class is not generated to manipulate it.

Enterprise JavaBeans (EJB)

Enterprise JavaBeans can be generated based on the Enterprise JavaBeans model, the generated code ensures that all developers produce consistent java persistence. Application development cycles are shortened using a code generation approach. As common database and application servers are supported, you are allowed to use the same Enterprise JavaBeans model to develop application with several supported application and database servers.

Generating Enterprise JavaBeans from Enterprise JavaBeans Model

You can generate EJB code from EJB Diagram.

You can obtain the EJB Diagram by drawing or from ERD. For more information, refer to the descriptions of Creating an EJB Diagram in Object Model chapter.

In order to generate Enterprise JavaBeans from the Enterprise JavaBeans model, you have to specify the class code detail for the models.

Specifying Entity Bean Code Detail

1. Right-click on Entity Bean, select Open Specification....

Figure 17.34 - To open specification

2. Click EJB Class Code Details Tab on the Class Specification dialog box.
3. Enter the code detail for the Entity Bean and click OK to confirm.

Figure 17.35 - Class Specification dialog (EJB Class Code Details)

Field	Description
Has remote	Generate the remote interface of the entity bean if the option is selected.
Has local	Generate the local interface of the entity bean if the option is selected.
Has home	Generate the home interface of the entity bean if the option is selected.
Has local home	Generate the local home interface of the entity bean if the option is selected.
Simple primary key	Disable the generation of primary key class if the option is selected; that is, the selected field will be used as a primary key of the entity bean.
Abstract schema name	The abstract schema name of the entity bean. The name must be a valid java identifier and unique. It is used by EJB-QL in CMP entity bean for retrieving data from the database.
JNDI name	The JNDI name of the entity bean which is used for the lookup process of the home interface.
JNDI local name	The local JNDI name of the entity bean which is used for the lookup process of the local home interface.
Display name	The short name of this entity bean.

Table 17.4

Specifying Message-Driven Bean Code Detail

1. Right-click on Message Driven Bean, select Open Specification....

Figure 17.36 - To open specification for Message Driven Bean

2. Click EJB Class Code Details Tab on the Class Specification dialog box.
3. Enter the code detail for the Message Driven Bean and click OK to confirm.

Figure 17.37 - Class Specification dialog (EJB Class Code Details tab)

Field	Description
JNDI name	The JNDI name of the entity bean which is used for the lookup process of the home interface.
JNDI local name	The local JNDI name of the entity bean which is used for the lookup process of the local home interface.
Transaction type	The transaction type of the message-driven bean.
Acknowledge mode	The acknowledge mode of the message-driven bean.
Display name	The short name of this message-driven bean.

Table 17.5

Specifying Session Bean Code Detail

1. Right-click on Session Bean and select Open Specification....

Figure 17.38 - Open specification for Session Bean

2. Click EJB Class Code Details Tab on the Class Specification dialog box.
3. Enter the code detail for the Session Bean and click OK to confirm.

Figure 17.39 - Class Specification Dialog (EJB Class Code Details tab)

Field	Description
Has remote	Generate the remote interface of the session bean if the option is selected.
Has local	Generate the local interface of the session bean if the option is selected.
Has home	Generate the home interface of the session bean if the option is selected.
Has local home	Generate the local home interface of the session bean if the option is selected.
JNDI name	The JNDI name of the entity bean which is used for the lookup process of the home interface.
JNDI local name	The local JNDI name of the entity bean which is used for the lookup process of the local home interface.
Session type	The type of the session bean, either Stateless or Stateful.
Transaction type	The transaction type of the session bean.
Display name	The short name of this session bean.

Table 17.6

Using Update Code

After specifying the code details for the Enterprise JavaBeans model, you can generate the beans and deployment descriptor.

1. Click the Update Code on toolbar.

Figure 17.40 - Update the code

The Java class for beans and the deployment descriptor are generated. The Java class can be found under the package of your project and the deployment descriptor, ejb-jar.xml can be found inside the META-INF folder of your project.

Figure 17.41 - The generated files

Mapping Enterprise JavaBeans Model to Enterprise JavaBeans

The Enterprise JavaBeans is generated and supports mapping from Enterprise JavaBeans Model to Enterprise JavaBeans code. In this section, examples will be given to show the mapping between Enterprise JavaBeans model and Enterprise JavaBeans code.

Mapping Entity Bean

For each Entity Bean element which may have attributes and methods in the Enterprise JavaBeans model, a corresponding Java class will be generated. By configuring the EJB Class Code Details of Entity Bean, remote, local, home and local home interface can be generated. By default, the name of the interface will be generated as appending the type of interface to the name of the entity bean. You are allowed to assign the name for the interface.

Example:

Figure 17.42 - The Class Configuration for Home/Local interface

In the above example, the Product Entity Bean model maps to a class ProductBean and four interface including Product, ProductLocal, ProductHome and ProductLocalHome.

Figure 17.43 - Mapping the creator method

• Mapping Create Method

In the above example, the create method of the Product entity bean model maps to the create method of ProductHome and ProductLocalHome interface which has the same signature of the model with the same parameters in order. (It is illustrated by the red line in the above diagram.)

The ProductHome interface contains create and finder methods. The create method takes the Product value and primary key as parameters. When entity bean instantiates the home interface and calls its create method, the container create a ProductBean instance and calls its ejbCreate method. The ProductHome.create() and ProductHomeBean.ejbCreate() methods must have the same signatures, such that the product and primary key values can be passed from the home interface to the entity bean by the entity bean's container.

Figure 17.44 - The generated Class

From the above example, the attributes of Product map to the attributes of the Product Bean. A pair of getter and setter methods will be generated in the Product interface, ProductLocal interface and ProduceBean. This pair of getter and setter methods of attributes allows the access to the Entity Bean attributes' value.

Mapping Primary Key

The primary key of the entity bean can be mapped to either an attribute of the generated entity bean, or a Primary Key class.

Example:

Figure 17.45 - Mapping Primary Key

In the above example, the primary key of Product entity, ProductID maps to an attribute, ProductID of the entity bean, Product, which in turn becomes an attribute of the ProductBean class.

Mapping Association and Multiplicity

An association specifies the relationship between two entity bean classes in the EJB model with a role attached at one end. The role specifies the detailed behavior of an entity bean associated in the association, including its role name, which indicates how the entity bean class acts in the association; and multiplicity, which specifies the number of links between each instance of the associated classes.

Figure 17.46 - Mapping Association and Multiplicity

In the above Enterprise JavaBeans model, there is a one-to-many association between Customer and PurchaseOrder entity beans, defining that a customer can place many purchase order meanwhile a purchase order is placed by one customer.

Figure 17.47 - Mapping the association

From the above diagram, Customer entity bean has the role of "Places" in the association which associates with many PurchaseOrder instances. As the PurchaseOrder entity has the multiplicity of many in the association, a collection type is generated so as to manipulate the multiple instances of PurchaseOrder. The role, "Places" maps as an attribute to the Customer class with the data type Collection class.

Mapping Navigable Association

An association, which specifies a semantic relationship occurring between typed instances, has at least two ends represented by properties. When a property at an end of the association is owned by an end class, it represents the association is navigable from the opposite ends. On the contrary, when a property does not appear in the namespace of any associated class, it represents a non-navigable end of the association.

An open arrowhead on the end of an association indicates the end is navigable. Meanwhile, a small cross (x) on the end of an association indicates the end is not navigable. If an association has two navigable ends, it is considered as bi-directional associations.

As the role name of the association maps to an attribute which specifies how the entity bean associates with its associated entity bean, however if the association has a non-navigable end, the corresponding role name will not map to an attribute, suppressing the ownership of the entity bean.

Example:

Figure 17.48 - The Class Diagram with Navigable

In the above object model, it shows a binary association with one end navigable and the other non-navigable. It indicates that Product is owned by OrderLine while Product cannot own OrderLine. As the Enterprise JavaBeans model maps to Enterprise JavaBeans, the ownership of OrderLine instance in Product entity bean will not be generated in the bean code.

Figure 17.49 - Mapping with Navigable Association

From the above diagram, OrderLineLocal interface has the role of "Orders" in the association and associated with the pair of getter and setter for ProductLocal instance. The role, "Orders" maps as an attribute to OrderLineLocal class which defines as the data type of ProductLocal; it implies that the attribute "Orders" stores a product local instance.

On the other hand, Product class has the role of "OrderedBy" associated with many OrderLine instances in a non-navigable association; that is, ProductLocal class does not have the ownership of OrderLine. Even though the OrderLine class has the multiplicity of many in the association, the corresponding collection class of OrderLine for the ProductLocal class is not generated to manipulate it.

Mapping Message-Driven Bean

The message-driven bean allows you to process the JMS message asynchronously. The message may be sent by a client application, another enterprise java bean, a web component, any other J2EE component or a JMS application. The main difference between the message-driven beans and entity beans and session beans is the client can access the message-driven bean directly.

Example:

Figure 17.50 - Mapping Message Driven Bean

Mapping Session Bean

For each Session Bean element which may have attributes and methods in the Enterprise JavaBeans model, a corresponding Java class will be generated. By configuring the EJB Class Code Details of Session Bean, remote, local, home and local home interface can be generated. By default, the name of the interface will be generated as appending the type of interface to the name of session bean. You are allowed to assign the name of the interface.

Figure 17.51 - Class Specification (EJB Class Code Details)

Example:

The Session Bean, Transaction is selected to generate remote, local, home and local home.

Figure 17.52 - Mapping Session Bean

Deploying Enterprise JavaBeans on Application Servers

The deployment of Enterprise JavaBeans is supported on different application servers. A simple Application Server function provided to user to configure different kind of application server easily.

Configuring Application Servers

1. On the menu, click Modeling > EJB > Application Server Configuration....

Figure 17.53 - Application Server Configuration


For other SDE:

SDE	Method
SDE for JBuilder	On the menu, click Tools > Modeling > EJB > Application Server Configuration....
SDE for NetBeans	On the menu, click Modeling > EJB > Application Server Configuration....
SDE for IntelliJ IDEA	On the menu, click Modeling > EJB > Application Server Configuration....
SDE for JDeveloper	On the menu, click Model > EJB > Application Server Configuration....
SDE for WebLogic Workshop	On the menu, click Modeling > EJB > Application Server Configuration....

Table 17.7

The Application Server Configuration dialog box is displayed.

2. Place a check mark beside the desired application servers for configuration.
3. Enter the general application server setting.

For the Deploy Path, click to specify the location to deploy the EJB application JAR file which will be run on the application server.

For the Client JAR Path, click to specify the location for the user to get the client JAR file to develop their client application which will be deployed to the application server.

For the JDK Home, click to specify the location of JDK Home which can be configured instead of using the default JDK Home in the system. By default, the value of the JDK Home is "default".

Figure 17.54 - The general deploy setting

4. Right-click on the desired server, select Set as Default Application Server if more than one application server is configured.

Figure 17.55 - Set the database as default

JBoss Application Server

Example:

Figure 17.56 - JBoss application server configuration

For the JBoss Application Server configuration, you are asked to configure the Data Source settings including Driver Class, Connection URL, UserName and Password which can be configured with the Database Option button. The Database Configuration dialog box is displayed if the Database Option button is clicked. Refer to the descriptions in the Database Configuration chapter for information on how to configure database.

You are allowed to synchronize the setting between the JBoss Application Server and Database Configuration by using the Restore Database Values button.

IBM WebSphere Application Server

Example:

Figure 17.57 - WebSphere application server configuration

The IBM WebSphere Application Server requires you to specify the DataSource and Database Type for configuring the application server. You can select one of the database types supported.

BEA WebLogic Application Server

Example:

Figure 17.58 - WebLogic Application Server configuration

The BEA WebLogic application server requires you to provide the DataSource for setting up the application server.

Oracle Application Server

Example:

Figure 17.59 - Oracle AS configuration

The Oracle application server requires you to provide the DataSource and Version for setting up the application server.

JOnAS Application Server

Example:

Figure 17.60 - JOnAS configuration

The JOnAS application server requires you to specify the installed location for the JOnAS application server and provide the DataSource for setting the application server.

After configure the application server, you can deploy the EJB code to your selected application server.

Deploying Beans on the Application Server

1. On the menu, click Modeling > EJB > Deploy, select one of the application servers which have been configured from the sub-menu.

Figure 17.61 - Deploy to Application Server

For other SDE:

SDE	Method
SDE for JBuilder	On the menu, click Tools > Modeling > EJB > Deploy.
SDE for NetBeans	On the menu, click Modeling > EJB > Deploy.
SDE for IntelliJ IDEA	On the menu, click Modeling > EJB > Deploy.
SDE for JDeveloper	On the menu, click Model > EJB > Deploy.
SDE for WebLogic Workshop	On the menu, click Modeling > EJB > Deploy.

17.13

After deploying the EJB application, a message will be displayed on the message pane showing the result of deployment.

Figure 17.62 - Message Pane show the deploy message

Deploying Beans on WebSphere Application Sever

A backend database can be generated for deploying beans to WebSphere Application Server. The backend database helps you to perform Entity Bean to Database mapping for specified database type. In order to generate the backend database, you must ensure the EJB Diagram is synchronized with the ERD Diagram.

Example:

1. Synchronize the EJB Diagram to ERD Diagram.

Figure 17.63 - Synchronize EJB Diagram to ERD

2. Deploy the project to WebSphere Application server.

Figure 17.64 - Deploy EJB to Application Server

3. The backend database is generated and included in the deployment JAR file.

Figure 17.65 - The generated Server configuration files

Developing a Client Program

After deploying the EJB application to application server, you can write a client program with Client JAR file to test the application. A sample code for the client program is provided. The following example demonstrates how to get the deployed session bean from the application and instance to call the session bean information.

Example 1:

Example 2:

The following example shows a client program developed without specifying the environment parameter of the context. When executing the program, the following statement should be used:

As the client program may connect to different application server, the parameter values for the context's environment are different. The following tables show the values to be used in different application server.

Parameter Value for Context Environment in JBoss Client Program

Parameter Value for Context Environment in WebLogic Client Program

Parameter Value for Context Environment in WebSphere Client Program

Parameter Value for Context Environment in Oracle Client Program

Parameter Value for Context Environment in JOnAS Client Program

Visual Paradigm International Limited Website: www.visual-paradigm.com E-mail: support@visual-paradigm.com