Developing CMP 2.0 Entity Beans
- Advantages of CMP Entity Beans over BMP Entity Beans
- CMP 2.0 Entity Bean Sample Application
- Step 1: Implementing the CMP 2.0 Address Entity Bean
- Step 2: Implementing the CMP 2.0 Roster Entity Bean
- Step 3: Implementing the CMP 2.0 Student Entity Bean
- Step 4: Implementing JSP Clients to Test CMP 2.0 Entity Beans
- Step 5: Packaging the CMP 2.0 Entity Beans as an ejb-jar File
- Step 6: Packaging the JSP As a Web Component
- Step 7: Deploying the CMP 2.0 Entity Bean Sample Application
- Step 8: Testing the Sample Application
- A Discussion of the Deployment Descriptor
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Characteristics of CMP 2.0 Entity Beans
CMP 2.0 entity beans have the following significant characteristics:
CMP 2.0 entity beans support rich relationships between CMP 2.0 entity bean instances. Inter-entity bean relationship is characterized by its cardinality. CMP 2.0 entity beans support three types of cardinality: one-to-one, one-to-many, and many-to-many. This extensive cardinality enables developers to model complex business relationships in applications.
CMP 2.0 supports an abstract persistence schema that separates the client view of persistence from the implementation. The consequence is that developers can implement business logic based on an object model, without having to deal with the intricacies of the relational database model. During deployment, the abstract persistence schema model is mapped to the existing operational model. CMP 2.0 entity beans support EJB QL, a language for querying entity attributes and relationships between objects. At deployment time, the deployment tool converts EJB QL query statements to the query language of the underlying data source. CMP 2.0 entity beans use abstract methods to access container-managed fields and container-managed relationship fields.
CMP 2.0 entity beans provide two new optional ejbHome and ejbSelect methods to perform global operations, thus providing developers with added flexibility to implement complex business logic.
Bean developers don't have to implement finder and ejbSelect methods; the deployment tool is responsible for generating the implementation classes during deployment.
The container is responsible for automatically providing the inter-entity relationship referential integrity checks as well as implementing cascade delete. In CMP 2.0 relationships, cascade delete enables the container to delete dependent entity objects automatically when a primary entity object is deleted, all the while ensuring referential integrity in the relationship.
CMP 2.0 beans must be declared an abstract class. During deployment, the vendor-provided deployment tool is responsible for subclassing the abstract bean class and generating concrete classes to support the container-managed persistence.
Advantages of CMP Entity Beans over BMP Entity Beans
Factors that influence a developer's decision to use CMP entity beans as opposed to BMP entity beans include the availability of in-house expertise and the extent of a developer's experience. There are several additional reasons to consider CMP over BMP:
Time to market—With CMP entity beans, the developers write only the business logic and defer the persistence and relationship management logic to the deployment tool and the container, with the result that their applications contain fewer lines of code and take less time to develop. With BMP entity beans, on the other hand, the developer is responsible for writing the persistence and relationship management logic in addition to the business logic.
Portability—With BMP entity beans, the developer may write optimized SQL query statements and logic to manage persistence for a specific relational database. The hard-coded optimized SQL query statements and the logic may not be portable to other relational databases. With CMP entity beans, the developer uses the abstract persistence schema to specify the CMP and CMR fields in the deployment descriptor. The vendor-provided deployment tool then generates the appropriate classes at deployment time, thus ensuring a high degree of portability regardless of the type of data source.
Flexibility—With BMP entity beans, the developer must write the appropriate query statements to manage persistence based on the target data source. For example, the developer must write SQL statements for the relational database and OQL statements for the object database. As a result, third-party EJB providers must code and provide two sets of data access objects. The end users then must use the right combination of data access logic and query language for the query statements according to the target database. This adds unnecessary code management tasks for the user and the seller of BMP entity bean components. With CMP entity beans, on the other hand, the developer uses the abstract persistent schema to declare the CMP and CMR fields and then specifies the query using the EJB QL in the deployment descriptor. The deployment tool provides the flexibility to generate the SQL query for a relational database or the OQL query for an object database.
Improved performance—To enable high performance with BMP entity beans, bean developers (the business domain experts) must also become database experts, as they must write optimized code for a particular vendor's database. Obviously, database expertise is usually the domain of database administrators, not of bean developers. A higher level of data access code optimization also leads to reduced portability of the bean class. With CMP entity beans, the vendor-provided tool can read the deployment descriptor and potentially generate highly optimized code for the target data source. The degree of code optimization (and, therefore, of real-world CMP entity bean performance) will vary among the container providers. Optimization is a matter of simply converting EJB QL into native API calls of the particular target data source during deployment. Bean developers don't have to learn any vendor-specific APIs to improve performance in CMP entity beans.
Referential integrity—CMP entity beans inherit the rich relationship semantics, referential integrity, cardinality, relationship management, and cascading delete that the EJB 2.0 container provides automatically. With BMP entity beans, on the other hand, the bean developer must provide referential integrity checks and relationship management when implementing inter-entity relationships—and that's no trivial task.
Ease of maintenance—With BMP entity beans, there's more code to maintain—data access code in addition to business logic code results in software code maintenance challenges. CMP entity beans have only business logic code, as the deployment tools generate complicated data access and management code automatically during deployment.
Clearly, CMP entity beans have overwhelming advantages over BMP entity beans. They do have some drawbacks, however:
Debug difficulty—Because the data access and management classes are generated by the vendor's tool (meaning that the bean developers don't have access to the source code), some bugs are harder to debug in CMP entity beans. Also, CMP entity bean implementation automatically inherits any bugs inherent in the persistence class generated by the deployment tool.
Reduced developer control—The developer has complete control of the data access logic when using BMP entity beans and, consequently, more control over the entity bean's persistence management. In some instances—such as when there's a requirement to use vendor-specific, optimized query features like automatic primary key generators—the benefit of better data access control may be critical.
Higher learning curve—Because most developers are already familiar with writing SQL queries, it's easier to learn how to implement BMP entity beans. The CMP 2.0 abstract programming model is relatively more complex, and there's a sharp learning curve initially. To implement CMP 2.0 entity beans, the bean developer must understand the abstract persistence schema model and abstract CMP and CMR methods.