10g (9.0.4)
Part Number B10313-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Application Server TopLink Application Developer's Guide 10g (9.0.4) Part Number B10313-01 |
|
This chapter presents an overview of five common enterprise architectures. Each architecture leverages Oracle Application Server TopLink to manage object persistence. The descriptions in this chapter include common usages for each of the architectures, as well as discussions about the technical challenges each architecture presents. Where appropriate, the sections refer to related technical information later in this document.
OracleAS TopLink supports any enterprise architecture that makes use of Java. This chapter focuses on OracleAS TopLink's flexible architecture support, which includes:
OracleAS TopLink offers you the flexibility you need to choose your database, architecture, mapping strategy, application server and object-relational modeling. This chapter includes sections on:
This chapter introduces common architectural designs that leverage OracleAS TopLink. This chapter is not intended to give you all the technical information required to build these architectures, but instead introduces the designs and helps you decide which architecture best suits your needs. Other chapters in this document offer details on how to implement the architectures introduced in this chapter, including:
This section introduces concepts that help you evaluate the architectures presented in this chapter.
The architectures in this chapter fall into two categories, depending on whether you use Java objects or EJB entity beans to manage the persistent data.
OracleAS TopLink enables developers to use simple Java objects as the persistent mapped entities in your application. To manage them, developers use the OracleAS TopLink API or optionally, the Java Data Objects (JDO) API.
Enterprise JavaBean (EJB) technology is a component-based architecture that enables developers to develop distributed, object-oriented applications in Java. OracleAS TopLink offers support for EJB entity beans through both bean-managed persistence (BMP) and container-managed persistence (CMP).
Regardless of how you manage persistence, EJB applications require you to integrate the OracleAS TopLink framework with the hosting application server. This integration enables developers to leverage the connection pooling and transaction management offered through the application server's Java Transaction Architecture (JTA) support.
EJBs, developed by Sun Microsystems and its partners, represent a standard in enterprise computing. EJB is not a product, but rather a specification. It provides a framework for developers who create distributed business applications, and vendors who design application servers.
EJB is an important specification because of the widespread support it enjoys from enterprise software vendors.
For more information about EJBs, see the following Web sites:
http://java.sun.com/products/ejb/ http://java.sun.com/products/ejb/docs.html http://java.sun.com/j2ee/white/index.html
An enterprise application integrates multiple heterogeneous systems, such as database servers, legacy applications, and mainframe applications. An enterprise application may also be required to support a diverse range of clients, including:
The multi-tier approach enables developers to build complex enterprise applications that integrate with other systems in the application server tier. Many different types of enterprise architectures use the multi-tier approach.
Java and J2EE applications generally include several tiers, or layers. These layers can include the client tier, the presentation tier, the application tier, and the persistence tier.
An application client tier provides users with access to application functions. Its primary tasks are to present information from the application and to accept user input. For example, Web applications commonly present a browser as the client tier, but may also provide a Java (Swing) interface, a wireless device, or another application.
The presentation tier provides information interchange for the application. This tier is often a Java Server Pages (JSP) or servlet front end, an RMI or CORBA interface, or a Web Service.
The application tier holds the application business logic. Users access this tier either directly from the presentation layer using Java calls or through remote interfaces, such as RMI, CORBA, and EJB.
The application interacts with OracleAS TopLink at the application tier to provide application behavior. The user can query for and manipulate persistent entities through this tier.
The persistence tier provides access to the underlying datasource, after a relational database. In an OracleAS TopLink-enabled application, OracleAS TopLink provides most of the functionality for this tier. The application developer adds queries, mappings, and persistent entities to complete and enable the tier.
The architectures presented in this chapter leverage the different OracleAS TopLink sessions and session components.
For more information about the session components, see Chapter 4, "Sessions".
The session manager is a singleton mechanism that manages the sessions within a given Java virtual machine (JVM). In most systems, the session manager retrieves the sessions from the sessions.xml file. This file contains the information required to instantiate sessions and their related mappings.
The server session manages the persistence for a single OracleAS TopLink project, cached objects, query execution and maintaining shared JDBC resources. The session manager manages the server session.
The server session requires a client session to enable client access.
The client session handles client interaction with the server. The server session manages the client session.
The project contains mapping information for the persistence system. OracleAS TopLink stores the project in either a deployment XML format or a generated class. The OracleAS TopLink Mapping Workbench generates the project file in either of these formats.
The database session is a singleton session used in a two-tier application instead of the Client-Server model used in the three-tier architectures. The main difference is that the database session manages a single JDBC connection (used for both reading and writing). This approach also assumes that there is only a single client involved and the cache is therefore not shared.
The project contains default database login information, including a user name and password. You can also override this information by including alternative login information for a session, either in the sessions.xml file or in custom code.
The Unit of Work, OracleAS TopLink's native transaction mechanism, provides several advantages over a standard database transaction. It is the most efficient mechanism to apply changes to the object model in all OracleAS TopLink usage patterns.
For more information about the Unit of Work, see Chapter 7, "Transactions".
This section summarizes the five basic OracleAS TopLink architectures. These patterns are not mutually exclusive; instead, they are extensions of each other, based on the same core technology. This section introduces:
Two of the architectures presented in this chapter (EJB Entity Beans Using BMP, and EJB Entity Beans Using CMP) use EJB entity beans. EJB entity bean architectures are slightly different from the other architectures, because the EJB entity bean interfaces hide OracleAS TopLink functionality completely from the client application developer.
You can use entity beans in almost any J2EE application. From an OracleAS TopLink perspective, how the application uses the entity beans is not important; what is important to OracleAS TopLink is how each entity bean is mapped and implemented.
The three-tier application is a common architecture in which OracleAS TopLink resides within a Java server (either a J2EE server or a custom server). In this architecture, the server session provides clients with shared access to JDBC connections and a shared object cache. Because it resides on a single JVM, this architecture is simple and easily scalable. The OracleAS TopLink persistent entities in this architecture are generally Java objects.
This architecture often supports Web-based applications in which the client application is a Web client, a Java client, or a server component.
Not all three-tier applications are Web-based; however, the three-tier application is ideally suited to distributed Web applications. In addition, although it is also common to use EJBs in a Web application, this OracleAS TopLink architecture does not do so.
For more information, see "Three-Tier Architecture".
This architecture is an extension of the three-tier pattern, with the addition of EJB Session Beans wrapping the access to the application tier. The EJB Session Beans provide public API access to application operations, enabling you to separate the presentation tier from the application tier. The architecture also enables you to leverage the EJB session beans within a J2EE container.
This type of architecture generally includes JTA integration, and serialization of data to the client.
For more information, see "EJB Session Bean Facade Architecture".
OracleAS TopLink enables developers to leverage EJB entity beans within a J2EE application, using OracleAS TopLink CMP support. This support, which enables OracleAS TopLink to participate in container-managed transactions, requires a tight integration between the J2EE container and the persistence manager.
This architecture is an extension of the three-tier architecture, in which a J2EE container manages OracleAS TopLink mapping, querying, and other calls automatically.
For more information, see "EJB Entity Beans with CMP Architecture".
OracleAS TopLink BMP support enables developers to use EJB Entity beans on all application servers that comply with J2EE. This architecture is an extension of the three-tier architecture, in which the persistent data is bean-managed within an entity bean. The client code accesses the data through the entity bean interface.
The BMP architecture enables developers to leverage a J2EE application server. The resulting application is portable--not tied to a particular J2EE application server. However, the BMP architecture is not common because:
For more information, see "EJB Entity Beans with BMP Architecture".
A two-tier application generally includes a Java client that connects directly to the database through OracleAS TopLink. The two-tier architecture is most common in complex user interfaces with limited deployment. The database session provides OracleAS TopLink support for two-tier applications.
For more information, see "Database Session" .
Although the two-tier architecture is the simplest OracleAS TopLink application pattern, it is also the most restrictive, because each client application requires its own session. As a result, two-tier applications do not scale as easily as other architectures.
For more information, see "Two-Tier Architecture".
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.
The examples and discussions in this guide focus primarily on managing persistent entities on relational databases; however, OracleAS TopLink also offers access to non-relational 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 non-relational information, see "OracleAS TopLink XML Support".
The three-tier Web application architecture generally 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.
The three-tier Web application architecture offers the following advantages:
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 machine 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, 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, 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. Developers 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:
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 an 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:
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 of challenges with relationships, inheritance, and indirection.
For more information about managing relationships, inheritance, and indirection, 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 OracleAS TopLink-enabled Java objects. Session beans execute all OracleAS TopLink-related operations on behalf of the client.
The EJB specification describes session beans as either stateless or stateful.
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 bean's connection 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 an OracleAS TopLink-enabled stateful session bean 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, developers 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 container's persistence manager.
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 OracleAS TopLink-enhanced EJB 2.0-compliant CMP entity beans.
This three-tier application offers the following advantages:
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:
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 OracleAS TopLink-enhanced EJB 2.0-compliant BMP entity beans.
Using BMP with an OracleAS TopLink three-tier architecture offers the following advantages:
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:
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:
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. This makes 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 towards multi-tiered Web applications makes the two-tier architecture less common in-production 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".
|
 Copyright © 2000, 2003 Oracle Corporation. All Rights Reserved. |
|
