Activity: Enterprise JavaBean (EJB) Design
| Purpose
The purpose of EJB Design is to identify and specify the Design Classes that make up Enterprise JavaBeans (EJBs). As with activity: Class Design, the purpose is:
| |
| Role: Designer | |
| Frequency: Occurs repeatedly during all iterations after Inception. May also occur in Inception if there are prototyping activities. | |
| Steps
| |
Input Artifacts:
| Resulting Artifacts:
|
| Tool Mentors: | |
More Information:
| |
| Workflow Details:
|
Identify EJBs
Identify EJBs from the Analysis Classes and/or initial Design Model elements. EJBs may also be identified as part of a design pattern. Incorporating a pattern is effectively performing many of the steps in this activity (adding new classes, operations, attributes, and relationships), but in accordance with the rules defined by the pattern. For examples of J2EE patterns, see Core J2EE Patterns ([ALU01].
There are a few key decisions to make.
- How to map the "business logic" to EJB's and non-EJB classes - how many classes are needed, and of which kinds. For example, classes that represents objects with "state" information that needs to persist should be mapped to entity EJB's. Classes that perform services and don't have their own persistent data should be mapped to session or message EJB's.
- For session beans, whether or not to use a stateful or stateless session bean (the decision to use a stateful vs. stateless session bean is a critical part of identifying the responsibility of the session bean vs. other identified classes). Stateless session beans are more efficient, because an instance can be shared among discontiguous requests, rather than "tied" up with a particular session of activity.Moreover if the EJB will be used as a web service endpoint it must necessarily be stateless.
- What design patterns
and mechanisms the bean should use or participate in. The use of specific
patterns and mechanisms affects the number and type of EJBs that are identified.
Note: The Software Architect usually decides which patterns and mechanisms should be used by the project, and the Designer follows the guidelines.
For more information on identifying EJBs, see Guidelines: Identifying EJBs.
Define Attributes
Identify any attributes for the EJB.
In particular, for each entity bean, identify its persistent attributes, and primary key.
For more information on defining entity EJB attributes, see Guidelines: Designing Entity Beans.
Define Operations
This step is applicable to session and entity beans. It is not applicable to message-driven beans.
The design of operations is covered by Activity: Class Design, in particular the step Define Operations.
Some key decisions for EJBs are:
- Whether or not a particular operation needs to be available to local or remote clients. Typically, an EJB has only local or remote component interfaces. If you are working with a version of J2EE higher than 1.3 , a standard practice is to handle all remote client access through session EJBs, which manipulate entity EJBs in the same JVM through local component interfaces.
- How to group attributes into value objects for get/set operations. If you provide remote interfaces for entity EJBs, it is best to define a "value object" class that is used to pass a snapshot of the bean's data at once, in both directions. This minimizes network overhead compared to repeated get/set calls for individual bean fields. See the Core J2EE Patterns ([ALU01] for more information.
For more information on defining EJB operations, see Guidelines: Designing EJBs.
Define Behavior
The design of class behavior is covered by Activity: Class Design.
A key step in designing an EJB is identifying which EJB mechanisms to use, if not already specified when the EJB was first identified. Decisions include:
- Whether or not to use transactions, and if so, whether to use bean-managed or container-managed transactions.
- Whether security policies need to be provided, and if so, what these policies are, how they relate to each method provided by the bean, and which user "roles" are associated with each policy. The designer must also decide whether to use programmatic or declarative authorization.
- For entity beans, whether or not to use container-managed, or bean-managed persistence. Bean managed persistence provides more flexibility, but also more work on the part of the developer. Container managed persistence automates much of the work, but is less flexible.
Many of these mechanism decisions will have been made by the Software Architect at a project level, in which case, the Designer follows project guidelines.
While part of the EJB behavior is provided by the methods, additional behavior is provided through EJB collaborations. You can create references between EJB's, and for CMP 2.0 entity EJBs, you can create container-managed relationships (CMR's) between them.
Detailed guidance on designing EJB behavior is provided by Guidelines: Designing EJBs.
Design Supporting Classes
This step is applicable to all EJBs.
This is where additional Design Classes that support the EJB design are identified. Common support classes include Primary Key classes (PK classes), Data Accessor Objects (DAO's), and Value Objects (VO's). DAO's are used in implementing BMP entity EJBs to hide the database manipulation details. This makes it easier to port an application from one database server to another. VO's are used for accessing data transparently and passing data values between components in efficient ways.
You can create references between EJBs and container-managed relationships (CMR's) between EJBs.
Additional supporting classes may be defined through the application of patterns. For more information on J2EE patterns, see Core J2EE Patterns ([ALU01].
See Activity: Class Design for general guidance on designing classes.
