WebSphere connector architecture evolution.

Applications need access to many types of resources. A resource may be located on the same machine as the application or on a remote machine and may have no restrictions on its access or a multitude of restrictions. Access to a resource starts with a connection, which is simply a path from an application to a resource that it wants to use (see Figure 1). the process of establishing a connection may be as simple as opening a file descriptor for a file that is located on the same machine as the application, or it can be as complicated as accessing databases that are located on remote machines. The path to the resource may involve going through a number of protocols before finally reaching the resource.

The design and implementation of code that accesses resources can be a complicated and time-consuming task. It makes sense to move as much of the management of connections as possible outside of the application so that application developers can focus on business logic instead of connection logic. The technology for making and using connections has evolved to make getting a connection easier and to improve the performance, security, and robustness of the connection itself.

The following considerations are common to all connections.

1. Creating a connection can be expensive.

Setting up a connection can take much time when compared to the amount of time the connection is actually used.

2. Connections often need to be secure.

Securing the connection is often a joint effort between the application and the server working with the resource.

3. Connections need to perform well.

Connection performance can be critical to the success of an application and is a function of application server performance and resource performance.

4. Connections need to be monitorable and have good diagnostics.

The quality of the diagnostics for a connection depends on information regarding server status and resource status.

5. Methods for connecting to and working with a resource generally vary for each type of resource.

For example, relational databases such as DB2 * are accessed via SOL (structured query language), whereas hierarchical databases such as IMS * (Information Management System) are accessed via transactional procedures.

6. Access to a resource might require a certain quality of service.

For example, the application might want the ACID (atomicity, consistency, isolation, and durability) properties that can be obtained when using data in the management of a transaction.

Connection technology has evolved based on two types of access that applications have historically utilized: client application access to Web-server- or application-server-managed resources, and server-managed component access to enterprise legacy resources.

Client access to server-managed resources. Assume a client application wants to connect with a resource that is being managed by a server process that is most likely running on a different machine. The resource might be a Web page that is managed by a Web server process or a component, such as a servlet or an Enterprise JavaBean ** (EJB), (1) that is managed by an application server process. These are relatively new types of resources that have emerged with the development of the Internet and are expected to be readily available, a reflection of the Internet environment they were developed for. They are often available to the general public, such as the home page of a business, which is usually available and easily located by anyone.

Some resources may contain all the data and logic that the application needs to access. Other resources may contain business logic that the client wants to execute, and as part of that execution, the resource may need to access data in an Enterprise Information System (EIS). (2) An EIS is a system running in its own set of processes that exists outside of the application server process.

Some examples of server-managed resources are HTML (HyperText Markup Language) documents, CGI (Common Gateway Interface) scripts, applets, servlets, JavaServer Pages ** (JSP **), and EJBs (such as session beans, Container Managed Persistence [CMP] beans, and message-driven beans).

Component access to enterprise resources. Enterprise resources are often legacy resources that were developed over time by a business and are external to the application server process. Each type of resource has its own connection protocol and a proprietary set of interfaces to the resource. This means that the resource has to be adapted to be accessible from a JVM **-based (Java Virtual Machine-based) process such as an application server. The resource is usually important to the business and is protected from unauthorized access by strict rules governing how it is used.

In the following subsection, we present a brief review of connector architectures and their evolution.

A brief history of connecting. In early connector architectures, a client machine, using a Web browser, could connect to anything it wanted on the Internet as long as it was a Web page. While this was very useful, there was a need to access resources that existed outside of the Web page. CGI scripts became a popular way to provide some of this access but had limited capabilities and were not an object-based solution. A designer of CGI scripts had to be careful not to introduce means for the user to intentionally or unintentionally initiate actions beyond that which the script intended. Some of these "holes" were not always immediately apparent until a clever (or unfortunate) user discovered them.

Applets constituted an object-based solution that provided a better way to execute code in a Web page, eliminating security exposures by not allowing access to resources outside of the machine on which the application was running (see Figure 2). Despite these advantages, a solution that would allow access to enterprise assets that was secure, easy to develop, and easy to deploy was needed.

[FIGURE 2 OMITTED]

With the advent of the servlet, an object-oriented way to execute code that could access external resources became available. The servlet could be used to access resources managed by a server, such as EJBs, or it could be used to access enterprise resources directly. Java Database Connectivity (JDBC (3)) provided a standardized way to access relational databases (see Figure 3). JDBC ** functions were supplemented and enhanced by the Common Connector Framework (CCF) and later by the J2EE ** Connector Architecture (J2CA). The remainder of this paper describes the implementations of these technologies in the context of WebSphere, their benefits, and their trade-offs, and presents the WebSphere Channel Framework Architecture.

[FIGURE 2 OMITTED]

Access to relational databases

The introduction of JDBC offered new capabilities in accessing relational databases. In the WebSphere Application Server, JDBC calls are intercepted by the WebSphere Connection Manager (CM), as shown in Figure 4. CM provides a layer between the JDBC calls and the JDBC drivers. This layer provides a common dynamic connection pool scheme regardless of which database is being used, connection cleanup at the end of a transaction, an easy way to configure drivers and connection information, configured connection testing, common prepared statement caching, and common exception handling for "stale" connections.

[FIGURE 4 OMITTED]

The common dynamic connection pool ensures that connection pooling is available regardless of whether the JDBC driver provides it. Configuration options for pooling provide a great deal of control to administrators. Administrators can control the minimum and maximum number of connections in the pool, how long connections can be inactive in the pool before they are discarded, how long an application can keep open a connection that is inactive before it is discarded, and how long to wait to get a connection before the attempt is abandoned. Stale connection handling provides an easy way for applications to find out that a connection is no longer usable and implement a strategy for handling this type of situation without having to interpret each error code from the specific JDBC vendor for this condition. Customers can add more error codes to the list of stale connection exceptions to improve stale connection detection.

The use of JDBC directly by the servlet required the application developer to learn JDBC. An alternative to direct JDBC use, EJBs provided a better access model with the "bean" providing a way to access data that takes care of data caching, security, transactions, and persistence scenarios. BMPs (bean-managed persistence beans) could be written by bean developers to encapsulate the JDBC calls. Application developers could then use the BMP to access the data without having to learn how to write JDBC code.

Using beans for data access was an advantage over using JDBC directly because this model could later be used to access other types of resources as well as relational databases, when the appropriate beans became available. For bean providers, CMPs provided an even greater advantage, as the tools embedded the JDBC calls into the bean; therefore, the bean provider no longer had to learn a specific resource's API (application programming interface). Additionally, the EJB container took over the handling of security and transactions for BMPs and CMPs and data isolation for CMPs. The Web container also provided some transaction and security capabilities.

Access to procedural and hierarchical resources