The three-tier Web application architecture generally includes the connection of a server-side Java application to the database through a JDBC connection (see Figure 2-3). In this pattern, 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 Common Object Request Broker Architecture (CORBA).
The three-tier application is a common architecture in which 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 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.
Although not all three-tier applications are Web-based, this architecture is ideally suited to distributed Web applications. In addition, although it is also common to use EJB in a Web application, this TopLink architecture does not.
Example ImplementationsExamples of three-tier architecture implementation include the following:
A Model-View-Controller Model 2 architectural design pattern that runs in a J2EE container with servlets and JSP that uses TopLink to access data without EJB.
A Swing or Abstract Window Toolkit (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 it is less standard than EJB.
Variation Using Remote SessionsTopLink includes a session type called remote session. The session offers the full session API and contains a cache of its own, but exists on the client system rather than on the TopLink server. Communications can be configured to use RMI or RMI-Internet Inter-Object Request Broker Protocol (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.
For more information, see "Remote Sessions".
Technical ChallengesThe three-tier application with a stateless client presents several technical challenges, including the following:
Transaction management in a Stateless Environment
A common design practice is to delimit client requests within a single unit of work (transactional session). 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.
Optimistic Locking in a Stateless Environment
In a stateless environment, take 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. In this 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 "Configuring Locking Policy".
External JDBC Pools
By default, TopLink manages its own connection pools. You can also configure 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 (see "Configuring External Connection Pooling").
JTA/JTS Integration
JTA and JTS are standard Java components that enable sessions to participate in distributed transactions. You must configure TopLink to use JTA/JTS to use session beans in the architecture (see "Integrating the Unit of Work With an External Transaction Service").
Cache Coordination
If you choose to use multiple servers to scale your application, you may require TopLink cache coordination (see "Understanding the Cache").
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3