Managing Connections with J2EE Connector Architecture
- Connection Management Contract
- Connection Management Architecture
- Application Programming Model
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter discusses how an application creates and uses connections to an underlying EIS. In particular, it focuses on the need for connection pooling and describes the different scenarios under which connection pooling is accomplished.
To provide some background and context, we begin by discussing the need for connection pooling. Enterprise applications that integrate with EISs run in either a two-tier or a multi-tier application environment. (Note that a two-tier environment is also called a nonmanaged environment, whereas a multi-tier environment is called a managed environment.) Figure 3.1 provides a simplified illustration of these two environments.
)
Figure 3.1. Managed and Nonmanaged Environments.
In a two-tier application environment, a client accesses an EIS that resides on a server. The client application creates a connection to an EIS. In this case, a resource adapter may provide connection pooling, or the client application may manage the connection itself.
In a multi-tier application environment, Web-based clients or applications use an application server residing on a middle tier to access EISs. The application server manages the connection pooling and provides this service to the applications deployed on the application server.
Applications require connections so that they can communicate to an underlying EIS. They use connections to access enterprise information system resources. A connection can be a database connection, a Java Message Service (JMS) connection, a SAP R/3 connection, and so forth. From an application's perspective, an application obtains a connection, uses it to access an EIS resource, then closes the connection. The application uses a connection factory to obtain a connection. Once it has obtained the connection, the application uses the connection to connect to the underlying EIS. When the application completes its work with the EIS, it closes the connection.
Why is there a need for connection pooling? Connection pooling is a way of managing connections. Because connections are expensive to create and destroy, it is imperative that they be pooled and managed properly. Proper connection pooling leads to better scalability and performance for enterprise applications.
Often many clients want concurrent access to the EISs at any one time. However, access to a particular EIS is limited by the number of concurrent physical connections that may be created to that EIS. The number of client sessions that can access the EIS is constrained by the EIS's physical connection limitation. An application server, by providing connection pooling, enables these connections to be shared among client sessions so that a larger number of concurrent sessions can access the EIS.
Web-based applications, in particular, have high scalability requirements. Note that the Connector architecture does not specify a particular mechanism or implementation for connection pooling by an application server. (Our example implementation presented later does demonstrate one possible approach to connection pooling.) Instead, an application server does its own implementation-specific connection pooling mechanism, but, by adhering to the Connector architecture, the mechanism is efficient, scalable, and extensible.
Prior to the advent of the J2EE Connector architecture, each application server implementation provided its own specific implementation of connection pooling. There were no standard requirements for what constituted connection pooling. As a result, it was not possible for EIS vendors to develop resource adapters that would work across all application servers and support connection pooling. Applications also could not depend on a standard support from the application server for connection pooling.
J2EE application servers that support the Connector architecture all provide standard support for connection pooling. At the same time, they keep this connection pooling support transparent to their applications. That is, the application server completely handles the connection pooling logic and applications do not have to get involved with this issue.
3.1 Connection Management Contract
The Connector architecture provides support for connection pooling and connection management through its connection management contract, one of the three principal contracts defined by the Connector architecture. The connection management contract is of most interest to application server vendors and resource adapter providers because they implement it. However, application developers will also benefit from understanding the application programming model based on the connection management contract.
The connection management contract is defined between an application server and a resource adapter. It provides support for an application server to implement its connection pooling facility. The contract enables an application server to pool its connections to an underlying EIS. It also enables individual application components to connect to an EIS.
The connection management contract defines the fundamentals for the management of connections between applications and underlying EISs. The application server uses the connection management contract to:
Create new connections to an EIS.
Configure connection factories in the JNDI namespace.
Find the matching physical connection from an existing set of pooled connections.
The connection management contract provides a consistent application programming model for connection acquisition. This connection acquisition model is applicable to both managed and nonmanaged environments. More details on the connection acquisition model are given later in this chapter in the section Application Programming Model. Chapter 12, Connection Management Contract, provides more information on the connection contract itself.