Selecting an Architecture With TopLink

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:

Tiers
Service Layer
Data Access
Caching
Locking

Tiers

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:

Three Tier
- J2EE or Non-J2EE
- Client
  - Web client
  - XML/Web service client
  - Java (fat) client
Two Tier

Three Tier

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 Chapter 97, "Understanding TopLink Transactions").

For more information, see "Understanding the Three-Tier Architecture".

J2EE or Non-J2EE

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 and/or entity beans.

With a non-J2EE application, you should use internal connection pools (see "Internal Connection Pools").

Client

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 (see "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.

Two Tier

With a two-tier application architecture, Oracle recommends using TopLink database sessions (see "Database Sessions") and the TopLink unit of work (see Chapter 97, "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".

Service Layer

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:

EJB Session Beans
- Stateful
- Stateless
EJB Entity Beans
- Container-Managed Persistence (CMP)
- Bean-Managed Persistence (BMP)
EJB 3.0 JPA Entities
Plain Old Java Objects (POJO)

EJB Session Beans

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 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".

Stateful

If you are using stateful session beans, then note that a reference to a client session cannot be passivated. In this case, you must reacquire a client session (see "Acquiring a Session at Run Time With the Session Manager") on activate or per request.

Stateless

If you are using stateless session beans, you must acquire new client session (see "Acquiring a Session at Run Time With the Session Manager") for each request.

EJB Entity Beans

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.

Container-Managed Persistence (CMP)

Oracle recommends using entity beans with container-managed persistence. 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".

Bean-Managed Persistence (BMP)

If you are using entity beans with bean-managed persistence, you should use the TopLink BMP integration. The disadvantages of this architecture are that the BMP architecture is restrictive and may not provide good performance.

For more information, see "Understanding the EJB Entity Beans With BMP Architecture".

EJB 3.0 JPA Entities

EJB 3.0 Java Persistence API (JPA) is a specification for persistence in Java EE and SE applications. In JPA, a persistent class is referred to as an entity. An entity is a plain old Java object (POJO) class (see "Plain Old Java Objects (POJO)") that is mapped to the database and configured for usage through JPA using annotations and/or XML.

With JPA, when your application is running inside a container, all of the benefits of the container support and ease of use apply. Note that you can configure the same application to run outside the container.

You can use session beans (see "EJB Session Beans") as the means for your application to interact with JPA.

If you choose to use JPA for your application development, consider the following options:

TopLink Essentials–the open-source community edition of TopLink. TopLink Essentials is derived from TopLink providing core object-relational mapping functionality necessary for the reference implementation of JPA in EJB 3.0. TopLink Essentials is available in source and binary distributions as the entity-persistence module of GlassFish Open Source Java EE 5 Application Server.
TopLink–a commercial implementation that provides the preview functionality of JPA.

Both options provide excellent support for this new standard, as well as additional functionality and performance benefits.

For more information, see "Understanding the EJB 3.0 JPA Entity Architecture" and "TopLink Application Architectures".

Plain Old Java Objects (POJO)

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").

Data Access

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:

Data Type
Multiple Data Sources
Isolating Data Access
Historical Data Access

Data Type

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")

Multiple Data Sources

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 two-phase commit.

Alternatively, you may use multiple sessions.

Isolating Data Access

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)").

Historical Data Access

If your data source maintains past or historical versions of objects, Oracle recommends that you use a TopLink historical session (see "Historical Sessions") to access this historical data so that you can express read queries conditional on how your objects are changing over time.

Caching

This section describes choices you need to make when deciding on how to use the TopLink cache (see Chapter 87, "Understanding the Cache") in your application architecture.

These choices can be summarized as follows:

Cache Type
Refreshing
Cache Coordination
- Protocol
- Synchronization

Cache Type

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").

Refreshing

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.

Cache Coordination

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").

Protocol

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").

Synchronization

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 as follows:

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).

Locking

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:

Optimistic Locking
Pessimistic Locking

If you are building a three-tier application, be aware of how that architecture affects the way you use locking (see "Locking in a Three-Tier Application").

For more information, see "Understanding Descriptors and Locking".

Optimistic 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.

Pessimistic Locking

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 "Configuring Named Query Options").