|
Oracle TopLink Developer's Guide
10g Release 3 (10.1.3) B13593-01 |
|
 Previous |
 Next |
|
Oracle TopLink Developer's Guide
10g Release 3 (10.1.3) B13593-01 |
|
|
Previous |
Next |
This section describes some of the key aspects of application architecture that apply to TopLink and discusses the various options available for each, including the following:
This section describes choices you need to make when deciding on how to separate client and server functionality in your application architecture.
These choices can be summarized as follows:
Web client
XML/Web service client
Java (fat) client
Oracle recommends a three-tier application architecture. With a three-tier architecture, Oracle recommends using TopLink server sessions and client sessions (see "Server and Client Sessions") and the TopLink unit of work (see "Understanding TopLink Transactions").
For more information, see "Understanding the Three-Tier Architecture".
You can use TopLink in a J2EE or non-J2EE application architecture. Oracle recommends that you use a J2EE application architecture.
With a J2EE application, you should use external connection pools (see "External Connection Pools"). You may consider using Java Transaction API (JTA) integration (see "JTA Controlled Transactions"), EJB session beans, and EJB entity beans.
With a non-J2EE application, you should use internal connection pools (see "Internal Connection Pools").
In a three-tier application architecture, you can implement any of the following types of client:
Web client–Oracle recommends that you implement a Web client.
XML/Web service client–With this client type, you can use TopLink XML (see "XML Usage").
Java (fat) client–With this client type, you can choose the means of communicating with the server:
EJB session beans–Oracle recommends this approach. You may consider using the UnitOfWork method mergeClone to handle merging deserialized objects (see "Merging Changes in Working Copy Clones"). The disadvantage of this approach is that your application must handle serialization. Avoid serializing deep object graphs. You should use indirection ("Configuring Indirection"). Consider using the data-transfer-object pattern.
XML/Web service–Use TopLink XML (see "XML Usage").
EJB entity bean–Use TopLink CMP integration or BMP support. The disadvantage of this approach is that remote entity beans may not perform or scale well.
RMI–You may consider using a TopLink remote session (see "Remote Sessions"). The disadvantage of this approach is that a remote session is stateful and may not scale well.
See also "Service Layer".
With a two-tier application architecture, Oracle recommends using TopLink database sessions (see "Database Sessions") and the TopLink unit of work (see "Understanding TopLink Transactions"). The disadvantages of this architecture are that it is not Web-enabled and does not scale well to large deployments.
For more information, see "Understanding the Two-Tier Architecture".
This section describes choices you need to make when deciding on how to encapsulate your application's business logic (or service).
These choices can be summarized as follows:
See also:
Oracle recommends using EJB session beans.
With EJB session beans, you should use JTA integration (see "JTA Controlled Transactions") and external connection pools (see "External Connection Pools"). You should acquire a unit of work using Server method getActiveUnitOfWork (see "Acquiring a Unit of Work with an External Transaction Service"). If your EJB session bean and data source are not in the same JVM, you may consider using UnitOfWork method mergeClone to handle merging deserialized objects (see "Merging Changes in Working Copy Clones").
For more information, see "Understanding the EJB Session Bean Facade Architecture".
If you are using stateful EJB session beans, then note that a reference to a client Session cannot be passivated. In this case, you must re-acquire a client Session ("Acquiring a Session at Run Time With the Session Manager") on activate or per request.
If you are using stateless EJB session beans, you must acquire new client Session ("Acquiring a Session at Run Time With the Session Manager") for each request.
EJB entity bean architectures are slightly different from other TopLink architectures, because the EJB entity bean interfaces hide TopLink functionality completely from the client application developer.
You can use entity beans in almost any J2EE application. For TopLink, how the application uses the entity beans is not important; how entity beans are mapped and implemented is important to TopLink.
Oracle recommends using CMP entity beans. In this case, you should use the TopLink CMP integration for your application server. You must ensure that you are using a J2EE server that TopLink supports (see "Integrating TopLink With an Application Server ").
For more information, see "Understanding the EJB Entity Beans with CMP Architecture".
If you are using BMP entity beans, you should use the TopLink BMP integration. The disadvantages of this architecture are that the BMP architecture is restrictive and may not be provide good performance.
For more information, see "Understanding the EJB Entity Beans With BMP Architecture".
If you choose to build your service layer with non-EJB Java objects with a J2EE application server, you should use external connection pools (see "External Connection Pools"). If you use a non-J2EE Web server, you should use internal connection pools (see "Internal Connection Pools"). In either case, you may consider using JTA integration (see "JTA Controlled Transactions").
This section describes choices you need to make when deciding on what type of data your application architecture must support.
These choices can be summarized as follows:
See also "Locking".
You can use TopLink to manage any of the following types of data:
relational (see "Relational Database Usage")
object-relational (see "Object-Relational Database Usage")
Oracle XDB (see "Oracle XML Database (XDB) Usage")
EIS, nonrelational, legacy data (see "Enterprise Information System (EIS) Usage")
XML and Web service data (see "XML Usage")
If your application architecture must access more than one data source, Oracle recommends that you use a session broker (see "Session Broker and Client Sessions") and JTA integration (see "JTA Controlled Transactions") for 2-phase commit.
Alternatively, you may use multiple sessions.
If your application architecture requires that some data be restricted to a private cache and isolated from the TopLink shared session cache, Oracle recommends that you use an isolated session (see "Isolated Client Sessions"). You can also use an isolated session with the Oracle Virtual Private Database (VPD) feature (see "Isolated Client Sessions and Oracle Virtual Private Database (VPD)".
If your data source maintains past or historical versions of objects, Oracle recommends that you use a TopLink historical session (see "Historical Client Sessions") to access this historical data so that you can express read queries conditional on how your objects are changing over time.
This section describes choices you need to make when deciding on how to use the TopLink cache (see "Understanding the Cache") in your application architecture.
These choices can be summarized as follows:
See also "Locking".
Choose a cache type (see "Cache Type and Object Identity") appropriate for the type of data your application processes. For example, consider a weak identity map for volatile data (see "Guidelines for Configuring the Cache and Identity Maps").
Consider how your application architecture may be affected by stale data (see "Handling Stale Data"): for example, consider using query or descriptor refresh options (see "Refreshing") or cache invalidation (see "Cache Invalidation"). Consider using an isolated session's cache (see "Isolated Client Sessions") for volatile data.
Avoid using no identity map (see "No Identity Map") for objects that are involved in relationships or that require object identity.
TopLink provides a distributed cache coordination feature that allows multiple, possibly distributed, instances of a session to broadcast object changes among each other so that each session's cache is kept up to date (see "Understanding Cache Coordination". Before using cache coordination, ensure that it is appropriate for your application (see "When to use Cache Coordination").
You can configure a coordinated cache to broadcast changes using any of the following communication protocols:
Java Message Service (JMS)–Oracle recommends using a JMS coordinated cache (see "JMS Coordinated Cache").
Remote Method Invocation (RMI)–Oracle recommends that you use RMI cache coordination only if you require synchronous change propagation (see "Configuring the Synchronous Change Propagation Mode"). For more information, see "RMI Coordinated Cache".
Common Object Request Broker Architecture (CORBA)–Currently, TopLink provides support for the Sun ORB (see "CORBA Coordinated Cache").
You can configure synchronization strategy that a coordinated cache uses to determine what it broadcasts when an object changes. You can configure this at the project (see "Configuring Cache Coordination Change Propagation at the Project Level") or descriptor ("Configuring Cache Coordination Change Propagation at the Descriptor Level") level:
invalidate changed objects–Propagate an object invalidation that marks the object as invalid in all other sessions. This tells other sessions that they must update their cache from the data source the next time this object is read. Oracle recommends using this synchronization strategy.
synchronize changes–Propagate a change notification that contains each changed attribute.
synchronize changes and new objects–Propagate a change notification that contains each changed attribute. For new objects, propagate an object creation (along with all the new instance's attributes).
This section describes choices you need to make when deciding on how to use TopLink locking options in your application architecture. Oracle strongly recommends always using a locking policy in a concurrent system (see "Configuring Locking Policy").
These choices can be summarized as follows:
If you are building a three-tier application, be aware of how that architecture affects how you use locking (see "Locking in a Three-Tier Application").
For more information, see "Understanding Descriptors and Locking".
Oracle recommends using TopLink optimistic locking. With optimistic locking, all users have read access to the data. When a user attempts to write a change, the application checks to ensure the data has not changed since the user read the data.
You can use version (see "Optimistic Version Locking Policies") or field (see "Optimistic Field Locking Policies") locking policies. Oracle recommends using version locking policies.
With pessimistic locking, the first user who accesses the data with the purpose of updating it locks the data until completing the update. The disadvantage of this approach is that it may lead to reduced concurrency and deadlocks.
Consider using pessimistic locking support at the query level (see "Configuring Named Query Options").
If are using CMP, you may consider using bean-level pessimistic locking support (see "Pessimistic Locking Policy").
