|
Oracle® Application Server TopLink Application Developer's Guide
10g Release 2 (10.1.2) Part No. B15901-01 |
|
 Previous |
 Next |
|
Oracle® Application Server TopLink Application Developer's Guide
10g Release 2 (10.1.2) Part No. B15901-01 |
|
|
Previous |
Next |
This section offers a more in-depth look at the five architectures and provides information to help you choose the right design for your application. It includes sections that describe:
Table 2-1 lists common application feature requirements and indicates which architectures support each feature. Use this information to choose the most appropriate architecture for your application.
Table 2-1 Feature Support in the Five OracleAS TopLink Architectures
| Feature | Three-Tier Web Application | EJB Session Bean Facade | EJB Entity Bean with CMP | EJB Entity Bean with BMP | Client-Server Two-Tier |
|---|---|---|---|---|---|
| Persistent Entity: Java Objects | X | X | X | X | X |
| Persistent Entity: EJB Entity Beans |
|
X | X | X |
|
| JSP/Servlet Presentation Layer | X | X | X | X |
|
| J2EE Compliance | X | X | X | X |
|
| JTA/JTS Transaction Management | X | X | X | X |
|
| Scaling to Multiple J2EE Application Server (Clustering) | X | X | X | X |
|
| Hosting Web Server and Application Server on Separate JVMs | X | X | X | X | X |
| Java 2 Standard Edition (J2SE) Application | X |
|
|
|
X |
|
Note: Application requires access to multiple datasources and, therefore, requires the JTA/JTS capabilities of the host application server to support two-phase commit. |
The examples and discussions in this guide focus primarily on managing persistent entities on relational databases; however, OracleAS TopLink also offers access to nonrelational data through the OracleAS TopLink Software Development Kit (SDK). For example, the OracleAS TopLink installation includes the ability to persist objects to and from XML data stream or file representation.
For more information about OracleAS TopLink with nonrelational information, see "OracleAS TopLink XML Support".
The three-tier Web application architecture usually includes the connection of a server-side Java application to the database through a JDBC connection. In this common pattern, OracleAS TopLink resides within a Java server (a J2EE server or a custom server), with several possible server integration points. The application can support Web clients such as servlets, Java clients, and generic clients, using XML or CORBA.
A Model View Controller (MVC) Model 2 architectural design pattern that runs in a J2EE container with servlets and JSPs that uses OracleAS TopLink to access data, without EJBs
A Swing or AWT client that connects to a server-side Java application through RMI, without an application server or container
The three-tier Web application architecture offers the following advantages:
High performance, lightweight persistent objects
High degree of flexibility in deployment platform and configuration
The disadvantage of this architecture is that it is a less standard approach than EJBs.
OracleAS TopLink includes a session type called RemoteSession. The remote session offers the full session API and contains a cache of its own, but exists on the client system rather than the OracleAS TopLink server. Communications can be configured to use RMI or RMI-IIOP.
Remote session operations require a corresponding client session on the server.
Although this is an excellent option for developers who wish to simplify their access from the client tier to the server tier, it is less scalable than using a client session and does not easily allow changes to server-side behavior.
If you build the three-tier application with a stateless client, this architecture presents several technical challenges, that the following sections discuss.
A common design practice is to delimit client requests within a single Unit of Work. In a stateless environment, this may affect how you design the presentation layer. For example, if a client requires multiple pages to collect information for a transaction, then the presentation layer must retain the information from page to page until the application accumulates the full set of changes or requests. At that point, the presentation layer invokes the Unit of Work to modify the database.
In a stateless environment, take extra care to avoid processing out-of-date (stale) data. A common strategy for avoiding stale data is to implement optimistic locking, and store the optimistic lock values in the object.
This solution requires careful implementation if the stateless application serializes the objects, or sends the contents of the object to the client in an alternative format. If this is the case, transport the optimistic lock values to the client in the HTTP contents of an edit page. You must then use the returned values in any Write transaction to ensure that the data did not change while the client was performing its work.
For more information about locking, see "Locking Policy".
A common extension to the three-tier architecture is to combine session beans and OracleAS TopLink-managed persistent Java objects. The resulting application includes session beans and Java objects on an OracleAS TopLink three-tier architecture.
The three-tier architecture creates a server session and shares it between the session beans in the application. When a session bean needs to access an OracleAS TopLink session, the bean obtains a client session from the shared server session.
Here are the key features in this solution:
Session beans delimit transactions; you must configure OracleAS TopLink to work with a JTA system and its associated connection pool.
Accessing the persistent objects on the client side causes them to be serialized; ensure that when they re-emerge on the server-side, they properly merge into the cache to maintain identity.
An example of the EJB session bean facade architecture implementation is a Model View Controller (MVC) Model 2 architectural design pattern that runs in a J2EE container with servlets and JSPs that uses the OracleAS TopLink-enabled session bean to access data, without EJBs.
The EJB session bean facade architecture is a popular and effective compromise between the performance of persistent Java objects and the benefits of EJBs for standardized client development and server scalability. It offers several advantages:
Less overhead than an EJB entity bean application: OracleAS TopLink shares access to the project, descriptor, and login information across the beans in the application.
Future compatibility with other servers: This design isolates login and EJB server-specific information from the beans, which enables you to migrate the application from one application server to another without major recoding or rebuilding.
Shared read cache: This design offers increased efficiency by providing a shared cache for reading objects.
The key disadvantage of this model is the need to transport the persistent model to the client. If the model involves complex object graphs in conjunction with indirection, this can present many challenges with inheritance, indirection, and relationships.
For more information about managing inheritance, indirection, and relationships, see Chapter 3, "Mapping".
Session beans model a process, operation, or service and, as such, are not persistent entities. However, session beans can use persistence mechanisms to perform the services they model.
Under the session bean model, a client application invokes methods on a session bean that, in turn, performs operations on Java objects enabled by OracleAS TopLink. Session beans execute all operations related to OracleAS TopLink on behalf of the client.
The EJB specification describes session beans as either stateless or stateful.
Stateful beans maintain a conversational state with a client; that is, they retain information between method calls issued by a particular client. This enables the client to use multiple method calls to manipulate persistent objects.
Stateless beans do not retain data between method calls. When the client interacts with stateless session beans, it must complete any object manipulations within a single method-call.
An application can use both stateful and stateless session beans with an OracleAS TopLink client session or database session. When you use session beans with an OracleAS TopLink session, the type of bean used affects how it interacts with the session.
Stateless beans store no information between method calls from the client. As a result, re-establish the connection of the bean to the session for each client method call. Each method call through OracleAS TopLink obtains a session, makes the appropriate calls, and releases the reference to the session.
Your EJB Server configuration includes settings that affect the way it manages beans—settings designed to increase performance, limit memory footprint, or set a maximum number of beans. When you use stateful beans, the server may deactivate a stateful session bean enabled by OracleAS TopLink out of the JVM memory space between calls to satisfy one of these settings. The server then reactivates the bean when required and brings it back into memory.
This behavior is important, because an OracleAS TopLink session instance does not survive passivation. To maintain the session between method calls, release it during the passivation process and re-obtain it when you reactivate the bean.
You can use a Unit of Work to enable your client application to modify objects on the database. The Unit of Work merge functions employ mappings to copy the values from the serialized object into the Unit of Work, and to calculate changes.
For more information, see "Merging Changes in Working Copy Clones".
OracleAS TopLink CMP support enables you to leverage a J2EE container to automate mapping, querying, and other OracleAS TopLink calls. In doing so, you combine the standard interfaces and power of CMP and a container, with OracleAS TopLink flexibility, performance, and productivity. OracleAS TopLink integrates with the EJB container in this architecture, to become the persistence manager of teh container.
OracleAS TopLink components are transparent to the developer in CMP architectures. The developer interacts with CMP entity beans, and the container uses OracleAS TopLink internally.
An example of the EJB entity beans with CMP implementation is a Model View Controller (MVC) Model 2 architectural design pattern that runs in a J2EE container, with servlets and JSPs that access either session beans or EJB 2.0-compliant CMP entity beans enhanced by OracleAS TopLink.
This three-tier application offers the following advantages:
It allows for CMP beans with OracleAS TopLink features such as caching and mapping support. This enables the bean designer to leverage the OracleAS TopLink complex mapping functionality, such as storing bean data across more than one table, composite primary keys, and data conversion.
The CMP Architecture presents a standard method to access data, which enables you to create standardized reusable business objects.
CMP is well-suited to create coarse-grained objects, which OracleAS TopLink relates to dependent, lightweight, regular Java objects.
OracleAS TopLink provides for lazy initialization of referenced objects and beans.
OracleAS TopLink provides functionality for transactional copies of beans, allowing concurrent access by several clients, rather than relying on individual serialization.
OracleAS TopLink provides advanced query capabilities, as well as dynamic querying.
OracleAS TopLink maintains bean and object identity.
The disadvantage of this architecture is that pure CMP entity bean architectures can impose a high overhead cost. This is especially true when a data model has a large number of fine-grained classes with complex relationships.
The key technical challenge in this architecture lies in integrating components into a cohesive system. For example, this architecture requires a specific OracleAS TopLink integration with the application server or J2EE container. Other issues include:
External JDBC Pools: By default, OracleAS TopLink manages its own connection pools. You can also configure OracleAS TopLink to use connection pooling offered by the host application server. This feature is useful for shared connection pools and is required for JTA/JTS integration.
JTA/JTS Integration: JTA and JTS are standard Java components that enable sessions to participate in distributed transactions. You must configure OracleAS TopLink to use JTA/JTS to leverage session beans in the architecture.
Cache Synchronization: If you choose to use multiple servers to scale your application, you may require OracleAS TopLink cache synchronization.
OracleAS TopLink BMP support enables you to combine the standard interfaces of BMP entity beans with OracleAS TopLink flexibility, performance, and productivity. OracleAS TopLink provides a base class for BMP entity beans, and the base class implements the required methods for the EJB specification. This greatly simplifies the work of the developer when implementing BMP entity beans.
An example of the EJB entity beans with BMP implementation is a Model View Controller (MVC) Model 2 architectural design pattern that runs in a J2EE container, with servlets and JSPs that access session beans and EJB 2.0-compliant BMP entity beans enhanced by OracleAS TopLink.
Using BMP with an OracleAS TopLink three-tier architecture offers the following advantages:
It simplifies the BMP method calls. These can be inherited from an abstract bean class, rather than being generated.
OracleAS TopLink makes BMP easier to implement.
It enables you to implement database-independent code in the bean methods.
The architecture supports features such as complex relationships, caching, object level and dynamic queries, and the Unit of Work.
The key technical challenge in this architecture lies in integrating components into a cohesive system. For example, this architecture requires a specific OracleAS TopLink integration with the application server or J2EE container. Other issues include:
External JDBC Pools: By default, OracleAS TopLink manages its own connection pools. You can also configure OracleAS TopLink to use connection pooling offered by the host application server. This feature is useful for shared connection pools and is required for JTA/JTS integration.
JTA/JTS Integration: JTA and JTS are standard Java components that enable sessions to participate in distributed transactions. You must configure OracleAS TopLink to use JTA/JTS to leverage session beans in the architecture.
Cache Synchronization: If you choose to use multiple servers to scale your application, you may require OracleAS TopLink cache synchronization.
Two-tier applications are often implemented as user interfaces that directly access the database. They can also be noninterface processing engines. In either case, the two-tier model is not as common as the three-tier model.
These are key elements of an efficient two-tier (client-server) architecture with OracleAS TopLink:
Minimal dedicated connections from the client to the database
An isolated object cache
An example of a two-tier architecture implementation is a Java User Interface (Swing/AWT) and batch data processing.
The advantage of the two-tier design is its simplicity. The OracleAS TopLink database session that builds the two-tiered architecture provides all the OracleAS TopLink features in a single session type, thereby making the two-tier architecture simple to build and use.
The most important limitation of the two-tired architecture is that it is not scalable, because each client requires its own database session.
The current trend toward multi-tiered Web applications makes the two-tier architecture less common inproduction systems, but no less viable. However, because there is no shared cache in a two-tier system, you risk encountering stale data if you run multiple instances of the application. This risk increases as the number of individual database sessions increase.
To minimize this problem, OracleAS TopLink offers support for several data locking strategies. These include pessimistic locking and several variations of optimistic locking.
For more information, see"Locking Policy".
