Introducing Connector Architecture

The Java solution to application integration in a heterogeneous environment is the J2EE Connector architecture. The architecture provides a standard way to connect to legacy and non-Java systems. As you will learn, the architecture allows EIS providers to create a single resource that allows any J2EE application server to access the EIS. In addition, the architecture defines a standard API that allows you to program against any supported EIS by using a standard set of API calls.

Overview of the Architecture

The J2EE Connector architecture defines two categories of contract—system and application. The system contract defines the relationship between a J2EE application server, or a container, and an EIS. The system-level contract requires the application server and the EIS to collaborate to hide system-level functionality from developers and components. The EIS provider implements its part of the contract through a resource adapter, which plugs into the application server to form a bridge between components and EISs. Figure 19.2 shows the resource adapter within the J2EE connector architecture.

Figure 19.2 also shows how application components, such as an EJB or JSP, communicate with an EIS through the resource adapter—not through direct communication. The application contract governs this communication through a client API—you will learn more about this contract later in the “Using the Common Client Interface” section of today's lesson.

To draw a comparison with other elements of J2EE, you can consider a resource adapter to be similar to a JDBC driver. In both cases, a service provider or a third-party provides a bridge between a non-Java application and Java components. In the case of JDBC, the bridge is a JDBC driver and, in the case of the Connector architecture, the bridge is a system-level software driver known as a resource adapter. In both instances, components communicate to the underlying service via the bridge.

After an EIS provider has written a resource adapter, any J2EE-compliant application server can use that adapter. This means that the EIS provider only has to write one resource adapter to support many application servers. An application server can host several resource adapters—one for each EIS—and, thus, support multiple EISs. To offer you a deeper insight into the relationship between EIS, application server, and application component, the next section of today's lesson looks at the roles and responsibilities the Connector architecture specification defines. In addition, the next section takes a closer look at the service and application contracts.

Roles and Responsibilities

Figure 19.3 shows a simplified representation of the roles, which relate to the process Figure 19.2 outlines.

Typically, but not exclusively, the EIS provider and the resource adapter provider are the same person or organization. The resource adapter plugs into the application server, so that the server can provide application components with connectivity to the EIS. The application server manages security, resources, and transactions on behalf of the EIS, so that these system-level functions are transparent to the application component.

Previously, in Figure 19.2, you saw how a system contract governs the relationships between an EIS and an application server. The system contract comprises of three separate contracts:

• Connection contract

• Transaction Management contract

• Security contract

The remainder of this section of today's lesson examines each of these contracts, so that you can gain an understanding of the services available to you as an application developer. If you want to explore these areas in more depth, please refer to the J2EE Connector architecture specification, the current version of which is available at http://java.sun.com/j2ee/connector/index.html.

The Connection Contract

The connection contract allows the application server to pool connections to the EIS, and allows application components to connect to the EIS. Typically, when connecting to an EIS, you write code that performs a lookup in the JNDI namespace for a connection factory, which you use to gain a connection to an underlying EIS. The connection factory, on receiving a request for a connection, delegates responsibility to a connection manager on the application server. The connection manager is then responsible for checking the connection pool for a connection and, together with the application server, providing a connection instance that you can use to access the underlying EIS. Because the application server pools connections, multiple clients can connect to multiple EISs. For example, the application could manage the connections between multiple servlet instances and an ERP system and a legacy database system.

The Transaction Management Contract

The transaction management contract allows an application server to manage transactions across multiple EISs if appropriate. Figure 19.4 shows the different types of transactions the Connector architecture recognizes, and it also shows how these transactions are managed.

As you can see, the architecture defines two main categories of transactions—XA or JTA transactions and local transactions. The former category includes those transactions that a transaction manager on the application server manages on behalf of the EIS. In this scenario, the application server provides all runtime support for transactions, so you do not need to concern yourself with these types of transactions. The latter category, local transactions, includes transactions that the EIS manages itself. In this instance, the server-side must perform some form of transaction demarcation. The server-side can perform this demarcation in one of two ways:

• Container managed

• Component managed

Container-managed demarcation is where the component container performs demarcation on behalf of the component. For example, the EJB specification requires an EJB container to support the container-managed transactions demarcation model. Therefore, an EJB container can manage demarcation so that you do not have to explicitly begin, commit, or rollback transactions. Unlike container-managed demarcation, component-managed demarcation requires you to manage the demarcation of a transaction. You will learn how to do this in the second of the example applications in today's lesson. With regard to J2EE application components, EJB containers must support component-managed transaction demarcation, and so must Web containers that house JSPs and servlets.

The Security Contract

An EIS will often hold information that might be sensitive (credit card details) or mission critical (prospects details in a call center). It is vitally important for an organization to know that this information is only available to authorized persons. The J2EE Connector architecture security contract stipulates how this security is maintained when J2EE components connect to EISs. The contract aims to achieve this by extending the J2EE security model to EIS integration through the Connector architecture. One of the key goals of the contract specification is to keep security mechanism neutral. That is, the security contract is flexible enough to support a wide-range of security technologies and EISs. The two principal ways it achieves this are by not stating

• A mandatory, specific security policy

• A mandatory, specific security technology

For example, the Connector architecture specification identifies the two most commonly used authentication (identifying a user) mechanisms—basic user-password that is specific to an EIS and Kerberos Version 5. Although the specification identifies these mechanisms, it does not stipulate that a given application server or EIS should support them. Likewise, the specification provides a great deal of flexibility with regard to authorizing users. In this instance, checking whether a given user is allowed access to a particular resource can be performed either by the EIS or the application server (you will see this in the code examples in the “Using the Common Client Interface” section of today's lesson).

The whole process of signing on to an EIS from an application can occur in two ways. The first is container managed. This is where the application server takes responsibility for signing onto an EIS. Alternatively, the sign on process can be component managed. In this instance, you are responsible for writing the code that provides the authentication and authorization credentials required for sign-on.