|
|
|
|
|
|
Deploying Your Application
This chapter explains how to deploy your application. The following topics are presented:
Defining the Persistence Type for your Deployment
Before you start the WebLogic application server, you must do the following:
The WLCS EJB source code is independent of the persistence method, whether it is container-managed or any implementation of Bean-Managed Persistence.
The source code that uses JDBC instructions to persist Entity Beans is generated according to one of the BEA reference implementations of Bean-Managed Persistence. If you use the reference data model, the source code may be used as generated. The more likely case is that the JDBC source code may be used as templates to persist EJBs to a legacy data model.
One of the advantages of the WLCS approach is that business logic and other core EJB source code is independent of the persistence implementation. This isolates business application development from database development and schema changes.
Using Bean-Managed Persistence
You can deploy the WebLogic Commerce Server examples using Bean-Managed Persistence.
This section discusses the following topics:
You can map WLCS to any database available through JDBC. BEA provides a reference implementation (deployment set) for Bean-Managed Persistence. This is available as a deployment options in the WebLogic Commerce Server release.
Here, we describe how to deploy the WebLogic Commerce Server software in the following environments:
The example Oracle deployment set allows you to map the MyBuyBeans.com components to Oracle 8.0.5 and Oracle 8.1.5.
The WLCS Smart Generator has basic object/relational mapping features that generate up to 100% of the mapping from beans to a relational model using serialization. For complex databases the generated code serves as a starting point for reliable and scalable Bean-Managed Persistence that you can modify and fine-tune.
Note: For specific directions on deploying the MyBuyBeans.com example portal on Oracle, see the Installation Guide.
The Oracle Reference Implementations
The Oracle reference implementation uses Oracle's object-relational features including database object types and nested tables. WebLogic Commerce Server are stored with a maximum transparency. You can query on every field in the example BuyBeans object model. This reference implementation is made available to help gauge the effort and complexity of more-detailed object-relational persistence.
If you have any comments, questions, or need help with a WebLogic-Oracle 805 deployment, please contact support@theorycenter.com.
Oracle OCI Driver. The WebLogic-Oracle 805 deployment uses the Oracle Thin JDBC driver. If you want to use the Oracle OCI driver instead, you do not have to re-run the EJB compiler. You need to modify the weblogic.properties file to use the OCI Driver instead of the Thin driver, then re-start the server. All our beans use TRANSACTION_READ_COMMITED as the isolation-level, but if you change the isolation level then you need to re-run the EJB compiler and redeploy all the beans.
Additional Requirements
Deployment Sets Overview
Deployment Sets give you the freedom to develop your business application independently from the application server or database vendors.
This separates business logic from the development environment and gives you the freedom to choose to develop in one environment and deploy in another. Each Deployment Set pertains to a particular combination of an application server and database.
There is a deployment set available for each of BEA's certified implementations on an application server and database. Deployment sets are available for:
The following table illustrates the matrix of servers and databases.
|
Databases |
Application Servers |
|
|---|---|---|
|
Databases |
WebLogic |
NAS |
|
Cloudscape |
CMP |
n/a |
|
Oracle 8.0.5 |
BMP |
under development |
Deploying on Windows NT
This reference example assumes you have installed the WebLogic Commerce Server software under c:\WebLogicCommerce.
Deploying on Solaris
This example assumes you have installed the WebLogic Commerce Server software in /WebLogicCommerce.
Considerations in Bean-Managed Persistence
The section discusses the design and implementation of Bean-Managed Persistence.
Container-Managed Persistence Versus Bean-Managed Persistence
In Container-Managed Persistence (CMP), you use the deployment descriptor to tell the container which attributes of the entity bean to persist. Flexibility is therefore governed by the vendors of the container and database.
BMP gives you explicit control of the management of a bean instance's state.
The advantages of using Bean-Managed persistence may include:
Some disadvantages for developers when you use BMP:
Considerations when Persisting an EJB
The data model and access mechanisms have a strong impact on persistence logic. In particular, an entity bean's primary key, attributes, and contained classes must be considered. Particular attention should be given to other entity beans that are contained by value or reference.
The principles discussed in this section use a framework of mapping EJB Objects to a relational data model using JDBC. These principles may be generalized by the reader and applied to other mechanisms for modeling and accessing enterprise data.
Complexity of the Mapping Implementation
Consider the factors driving the map between EJB Objects and data storage.
A fixed database schema and a fixed object model may increase the complexity of the mapping implementation. Flexibility in either the database schema or the object model may correspondingly decrease this complexity.
Serializing objects or parts of objects may help decrease complexity of data mapping. The tradeoff is that the serialized data is "opaque" and is not easily accessed through third party tools such as report writers.
Dissecting and Persisting an Enterprise Java Bean
Primary Key
The Enterprise JavaBeans Specification requires that each Entity Bean has a class that represent attributes that uniquely identify an instance of that bean. The implication is that these attributes are used in primary key columns or foreign key columns in a relational database. These attributes cannot be serialized because they must be queried against.
Singleton Attributes
Attributes that have a 1:1 relationship with their class are easily mapped to columns or sets of columns in a relation that characterizes the bean.
Primitive Data Types
Attributes that correspond to JDBC primitive types, (for example: java.sql.Types.LONGVARCHAR, java.sql.types.INTEGER) easily map to columns in a relational table. If these attributes are serialized they cannot be easily be used in SQL reports or queries. Serialization of these attributes may impact the complexity or performance of the object-relational map. References to primitive data types are possible but discouraged.
Compound Data Types
Attributes that are java objects (not EJB's) are easily decomposed into columns that correspond to the JDBC primitive types. When these attributes are contained by value they can go in the table (or relation) where the EJB object is persisted. Care must be taken to ensure they are deleted from the database when the containing EJB object is deleted.
A reference to an attribute can be established with a foreign key to a relation that stores the actual attribute.
It is up to the application designers to determine application specific standards for creating and maintaining these keys. Application logic must ensure dangling references do not occur when the contained object is removed.
Designers should also consider if the referenced data should have a foreign key back to the containing EJB.
The complexity of this issue increases if many EJBs can reference the data.
Entity Beans
Entity Beans can contain other Entity Beans by value or reference. The fields in an entity bean's primary key class comprise a foreign key in the containing bean's relation. In addition, the containing bean needs access to the contained bean's primary key class and home class. This allows the containing bean to call findByPrimaryKey() to locate the contained bean.
Entity beans should be stored in their own relation, regardless of their containment by value or reference.
Application logic must be developed so beans contained by value are not orphaned, and to avoid dangling references to beans contained by reference. Designers should also consider if the target entity bean should have a foreign key back to the containing EJB. The complexity of this issue increases if many EJB's can reference the data.
Collections: Attributes Contained in a Many-to-One Relationship
Entity beans can contain other Java objects in many-to-one relationship. These collections can be stored in a separate table or a nested table if the DBMS supports this. The separate table needs a foreign key to join with the containing entity bean.
Application logic needs to address issues raised by Java's different collection classes. Many of these classes do not have a key to access the data. Some of these classes support ordering which must the persistence logic must manage.
Performance issues arise when persisting collections that have no primary key. When one member of the collection changes, the entire collection must be deleted and updated into persistent storage.
The CRUD operations (create, refresh, update, delete) must be done atomically on all the changing attributes of an Entity bean. This raises issues of transactional integrity and increased resources to support large transactions; for example: transaction logs, open cursors.
Collections can be serialized into a single column if the Java collection class implements the java.io.Serializable interface and the DBMS supports binary data types. This may simplify the persistence logic. In this case, whenever any member of the collection changes, the entire collection must be deleted and updated in the database.
Application logic needs to address orphan and dangling reference issues for objects contained by value and reference. Serialization of collections contained by reference will increase application logic complexity.
Primitive Data Types
Collections of primitive data types raise few issues that have not been previously discussed. Collections of primitive data types by reference are an absurdity, because the only key can be the value of each element in the collection.
Compound Data Types
Collections of compound data types that are contained by value can be serialized or stored in a separate table from the Entity Bean. If they are stored in a separate table, they need a foreign key to join with the containing entity bean.
Collections of compound data types by reference are possible if there is some unique key that identifies each element in the collection. The collection of keys would be serialized or stored in a separate table from the containing Entity Bean. If the keys are stored in a separate table, this table also needs a foreign key to the containing Entity Bean(s). This makes it possible to avoid dangling references when the object is deleted.
The complexity of the object-relational mapping increases when the objects in a collection have collections themselves. Many joins may be required to update and refresh the data. Serialization may reduce this complexity.
Entity Beans
Collections of Entity Beans are simplified because of requirement that each Entity Bean have a primary key class. The collection of primary keys needs to be persisted in serialized or table form.
As previously stated, Entity Beans should be stored in their own relation. The containing class needs to have access to the contained bean's home class and primary key class to invoke findByPrimaryKey() to locate the contained bean.
When entity beans are contained by value, and persisted in a table, this table may not need a foreign key to the containing bean. When they are contained by reference, the table should have a foreign key to the containing Entity Bean(s). This makes it possible to avoid dangling references when the contained entity bean.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|