Jakarta Connectors

An EIS provides the information infrastructure for an enterprise. An EIS offers a set of services to its clients. These services are exposed to clients as local and/or remote interfaces. Examples of an EIS include:

There are two aspects of an EIS:

An architecture for integrating Jakarta EE servers with EISs. There are two parts to this architecture: an EIS vendor-provided resource adapter and an application server that allows this resource adapter to be plugged in. This architecture defines a set of contracts (such as transactions, security, connection management) that a resource adapter has to support to plug in to an application server.

These contracts support bi-directional communication (outbound and inbound) between an application server and an EIS by way of a resource adapter. That is, the application server may use the resource adapter for outbound communication to the EIS, and it may also use the resource adapter for inbound communication from the EIS.

An EIS resource provides EIS-specific functionality to its clients. Examples are:

A resource manager manages a set of shared EIS resources. A client requests access to a resource manager to use its managed resources. A transactional resource manager can participate in transactions that are externally controlled and coordinated by a transaction manager.

In the context of the connector architecture, a client of a resource manager can either be a middle-tier application server or a client-tier application. A resource manager is typically in a different address space or on a different machine from the client that accesses it.

This document refers to an EIS as a resource manager when it is mentioned in the context of transaction management. Examples of resource managers are a database system, a mainframe TP system, and an ERP system.

A managed environment defines an operational environment for a Jakarta EE-based, multi-tier, web-enabled application that accesses EISs. The application consists of one or more application components—Jakarta Enterprise Beans, Jakarta Server Pages, servlets—which are deployed on containers. These containers can be one of the following:

A non-managed environment defines an operational environment for a two-tier application. An application client directly uses a resource adapter to access the EIS, which defines the second tier of a two-tier application.

A connection provides connectivity to a resource manager. It enables an application client to connect to a resource manager, perform transactions, and access services provided by that resource manager. A connection can be either transactional or non-transactional. Examples include a database connection and an SAP R/3 connection. A connection to a resource manager may be used by a client for bi-directional communication, depending on the capabilities of the resource manager.

An application component can be a server-side component, such as an Jakarta Enterprise Bean, Jakarta Server Page, or servlet, that is deployed, managed, and executed on an application server. It can also be a component executed on the web-client tier but made available to the web-client by an application server. Examples of the latter type of application component include a Java applet, and a DHTML page.

A container is a part of an application server that provides deployment and runtime support for application components. It provides a federated view of the services provided by the underlying application server for the application components. For more details on different types of standard containers, refer to the Jakarta Enterprise Beans (see Jakarta™ Enterprise Beans Specification, Version 3.2, Jakarta Server Pages, and servlet specifications.

A standard architecture is needed to integrate various EISs with an application server. Without a standard, EIS vendors and application server vendors may have to use vendor-specific architectures to provide EIS integration.

Jakarta Connectors provides a Java solution to the problem of bi-directional connectivity between the multitude of application servers and EISs. By using the Jakarta Connectors, it is no longer necessary for EIS vendors to customize their product for each application server. An application server vendor who conforms to the Jakarta Connectors also does not need to add custom code whenever it wants to extend its application server to support connectivity to a new EIS.

Jakarta Connectors enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server and provides the underlying infrastructure for the integration between an EIS and the application server.

An application server vendor extends its system only once to support Jakarta Connectors and is then assured of connectivity to multiple EISs. Likewise, an EIS vendor provides one standard resource adapter and it has the capability to plug in to any application server that supports Jakarta Connectors.

The following figure shows that a standard EIS resource adapter can plug into multiple application servers. Similarly, multiple resource adapters for different EISs can plug into an application server. This system-level pluggability is made possible through Jakarta Connectors.

If there are m application servers and n EISs, Jakarta Connectors reduces the scope of the integration problem from an m x n problem to an m + n problem.

Figure System Level Pluggability Between Application Servers and EISs

An enterprise tools vendor provides tools that lead to a simple application programming model for EIS access, thereby reducing the effort required in EIS integration. An EAI vendor provides a framework that supports integration across multiple EISs. Both types of vendors need to integrate across heterogeneous EISs.

Each EIS typically has a client API that is specific to the EIS. Examples of EIS client APIs are RFC for SAP R/3 and ECI for CICS.

An enterprise tools vendor adapts different client APIs for target EISs to a common client API. The adapted API is typically specific to a tools vendor and supports an application programming model common across all EISs. Adapting the API requires significant effort on the part of a tools vendor. In this case, the m x n integration problem applies to tools vendors.

Jakarta Connectors provides a solution for the m x n integration problem for tools and EAI vendors. Jakarta Connectors specifies a standard Common Client Interface (CCI) that supports a common client API across heterogeneous EISs.

All EIS resource adapters that support CCI are capable of being plugged into enterprise tools and EAI frameworks in a standard way. A tools vendor need not do any API adoption; the vendor can focus on providing its added value of simplifying EIS integration.

The CCI drastically reduces the effort and learning requirements for tools vendor by narrowing the scope of an m x n problem to an m + n problem if there are m tools and n EISs.

The resource adapter provider is an expert in the technology related to an EIS and is responsible for providing a resource adapter for an EIS. Since this role is highly EIS specific, an EIS vendor typically provides the resource adapter for its system.

A third-party vendor (who is not an EIS vendor) may also provide an EIS resource adapter and its associated set of application development tools. Such a provider typically specializes in writing resource adapters and related tools for a large number of EISs.

The application server vendor provides an implementation of a Jakarta EE-compliant application server that provides support for component based enterprise applications. A typical application server vendor is an OS vendor, middleware vendor, or database vendor. The role of an application server vendor is typically the same as that of a container provider.

The Jakarta EE platform specification (see Jakarta Platform, Enterprise Edition (Jakarta EE) Specification, version 9) specifies requirements for a Jakarta EE platform provider.

The container provider is responsible for providing a container implementation for a specific type of application component. For example, the container provider may provide a container for Jakarta Enterprise Beans components. Each type of application component—Jakarta Enterprise Bean, Jakarta Servlet, Server Pages—has its own set of responsibilities for its container provider. The respective specifications outline these responsibilities.

A container implementation typically provides the following functionality:

The expertise of the container provider is system-level programming, with its focus on the development of a scalable, secure, and transaction-enabled container.

The container provider is also responsible for providing deployment tools necessary for the deployment of application components and resource adapters. It is also required to provide runtime support for the deployed application components.

The container provider typically provides tools that allow the system administrator to monitor and manage a container and application components during runtime.

In the context of the connector architecture, the application component provider produces an application component that accesses one or more EISs to provide its application functionality.

The application component provider is an application domain expert. In the case of application components targeted towards integration with multiple EISs, various business tasks and entities are implemented based on access to EIS data and functions.

The application component provider typically programs against easy-to-use Java abstractions produced by application development tools. These Java abstractions are based on the Common Client interface (CCI).

The application component provider is not required to be an expert at system level programming. The application component provider does not program transactions, security, concurrency, or distribution, but relies on a container to provide these services transparently.

The application component provider is responsible for specifying structural information for an application component and its external dependencies. This information includes, for example, the name and type of the connection factories, and security information.

The output of an application component provider is a Java™ Archive (JAR) file that contains the application components and any additional Java classes required to connect to EISs.

The application component provider relies on tools to simplify application development and EIS integration. Since programming client access to EIS data and functions is a complex application development task, an application development tool reduces the effort and complexity involved in this task.

Enterprise tools serve different roles in the application development process, as follows:

A number of these tools may be integrated together to form an end-to-end application development environment.

In addition, various tools and middleware vendors offer EAI frameworks that simplify integration across heterogeneous EISs.

The application assembler combines various application components into a larger set of deployable units. The input of the application assembler is one or more JAR files produced by an application component provider and the output is one or more JAR files with a deployment descriptor. A deployment descriptor may not be provided by the application assembler if metadata annotations (see Metadata Annotations) are used to describe deployment information.

The application assembler is typically a domain expert who assembles application components to produce an enterprise application. To achieve this goal, the application assembler takes application components, possibly from multiple application component providers, and assembles these components.

The deployer takes one or more deployable units of application components, produced by the application assembler or component provider, and deploys the application components in a target operational environment. An operational environment is comprised of an application server and multiple connected EISs.

The deployer is responsible for resolving all external dependencies declared by the application component provider. For example, the deployer ensures that all connection factories used by the application components are present in an operational environment. To perform its role, the deployer typically uses the application server-provided deployment tools.

The deployer is also responsible for the deployment of resource adapters. Since an operational environment may include multiple EISs, the role of the deployer is more intensive and complex than that in a non-EIS scenario. The deployer has to understand security, transaction, and connection management-related aspects of multiple EISs that are configured in an operational environment.

The system administrator is responsible for the configuration and administration of a complete enterprise infrastructure that includes multiple containers and EISs.

In an operational environment that has multiple EISs, the deployer should manage the operational environment by working closely with the system administrators of respective EISs. This enables the deployer to resolve deployment issues while deploying application components and resource adapters in a target operational environment.

This chapter introduced the roles involved in the connector architecture. The later chapters specify responsibilities for each role in more detail.

ERP Software Inc. is an enterprise system vendor that provides an enterprise resource planning (ERP) system. ERP Software wants to integrate its ERP system with various application servers. It achieves this goal by providing a standard resource adapter for its ERP system. The resource adapter for ERP systems supports the standard inbound communication, transaction, connection management and security contracts. The resource adapter also supports the Common Client Interface (CCI) as its client API.

TPSoft Inc. is another enterprise system vendor that provides a transaction processing (TP) system. TPSoft has also developed a standard resource adapter for its TP system. The resource adapter library supports CCI as part of its implementation.

AppServer Inc. is a system vendor that has an application server product which supports the development and deployment of component-based enterprise applications. This application server product has an Jakarta Enterprise Beans container that provides deployment and runtime support for Jakarta Enterprise Bean components. The application server supports the system-level contracts that enable a resource adapter, which also supports these contracts, to plug into the application server and provide bi-directional connectivity to the underlying EIS. The Jakarta Enterprise Beans container insulates Jakarta Enterprise Bean components from the communication, transaction, security, and connection management mechanisms required for connecting to the EIS.

Manufacturer Corp. is a big manufacturing firm that uses a purchase order processing system based on the ERP system for its business processes. Recently, Manufacturer has acquired a firm that uses TPSoft’s TP system for its purchase order processing. Manufacturer aims to integrate these two systems together into a single integrated purchase order system. It requires a scalable, multi-user, secure, transaction-enabled integrated purchase order system that is not tied to a specific computing platform. Manufacturer plans to deploy the middle-tier of this system on the application server from AppServer Inc.

The MIS department of Manufacturer develops a PurchaseOrder Jakarta Enterprise Bean that provides an integrated view of the two underlying purchase order systems. While developing PurchaseOrder Jakarta Enterprise Bean, the bean provider does not program the transactions, security, connection management or inbound communication mechanisms required for connectivity to the ERP and TP systems; it relies on the Jakarta Enterprise Beans container and application server to provide these services.

The bean provider uses an application programming model based on the CCI to access the business objects and function modules for purchase order processing in the ERP system. The bean provider uses a similar application programming model based on the CCI to access the purchase order processing programs in the TP system.

The MIS department of Manufacturer assembles an integrated web-based purchase order application using PurchaseOrder Jakarta Enterprise Bean with other types of application components, such as Jakarta Server Pages and Jakarta Servlets.

The MIS department installs and configures the application server, ERP, and TP system as part of its operational environment. It then deploys the integrated purchase order application on this operational environment. As part of the deployment, the MIS department configures the operational environment based on the deployment requirements for the various application components that have been assembled into the integrated enterprise application.

After deploying and successfully testing the integrated purchase order system, the MIS department makes the system available for other departments to use.

The implementation class name of the ResourceAdapter interface is specified in the resource adapter deployment descriptor or through the Connector annotation described in @Connector. The ResourceAdapter class must be a JavaBean. Refer to JavaBean Requirements. During resource adapter deployment, the resource adapter deployer creates a ResourceAdapter JavaBean and configures it with the appropriate properties.

When a resource adapter is deployed, or during application server startup, an application server bootstraps an instance of the resource adapter in its address space. In order to bootstrap a resource adapter instance, the application server must use the configured ResourceAdapter JavaBean and call its start method. The start method call is a startup notification from the application server, and this method is called by an application server thread.

During the start method call the ResourceAdapter JavaBean is responsible for initializing the resource adapter instance. This may involve creating resource adapter instance specific objects, creating threads (refer to Work Management), and setting up network endpoints. A ResourceAdapter JavaBean represents exactly one functional resource adapter unit or instance. The application server must instantiate exactly one ResourceAdapter JavaBean per functional resource adapter instance. The application server must create at least one functional resource adapter instance per resource adapter deployment. An application server may create more than one functional resource adapter instance per resource adapter deployment, in order to create replicas of a single functional resource adapter instance on multiple Java™ Virtual Machines (2). In general, however, there should be just one functional resource adapter instance per deployment.

The application server is allowed to have multiple instances of a ResourceAdapter JavaBean active simultaneously, in the same JVM™ instance, provided the instances are not equal. Their equality is determined using the equals method, and therefore, the ResourceAdapter JavaBean is required to implement the equals method.

During the start method call, an application server must provide a BootstrapContext instance containing references to some of the application server facilities (for example, WorkManager ) for use by the resource adapter instance. The application server facilities exposed through the BootstrapContext instance may be used by the resource adapter instance during its lifetime.

During the start method call, the resource adapter instance initializes itself, and may use the WorkManager to submit Work instances for execution (see Work Management). The start method call should return in a timely manner, and should avoid blocking calls, such as use of doWork method call on the WorkManager instance. The application server may throw a WorkRejectedException in response to any or all doWork method calls on the WorkManager instance, in order to enforce that a start method call does not block. Resource adapter implementations are strongly recommended to use startWork and scheduleWork methods on the WorkManager , instead of the doWork method.

Any exception thrown during the start method call indicates an error condition, and the attempt by the application server to create a resource adapter instance fails. A future version of the specification may add a two-phase startup procedure.

A resource adapter instance at runtime may contain several objects that may be created and discarded during its lifetime. Such objects include ManagedConnectionFactory JavaBean (refer to Connection Management), ActivationSpec JavaBean (refer to Message Inflow), various connection objects, resource adapter private objects, and other resource adapter specific objects that are exposed to applications.

The ResourceAdapter JavaBean represents a resource adapter instance and contains the configuration information pertaining to that resource adapter instance. This configuration information may also be used as global defaults for ManagedConnectionFactory and ActivationSpec JavaBeans. That is, when ManagedConnectionFactory or ActivationSpec JavaBeans are created they may inherit the global defaults (ResourceAdapter JavaBean configuration information), which make it easier to configure them.

A resource adapter instance may provide bi-directional connectivity to multiple EIS instances. A ManagedConnectionFactory JavaBean can be used to provide outbound connectivity to a single EIS instance. An ActivationSpec JavaBean can be used to provide inbound connectivity from an EIS instance. A resource adapter instance may contain several such ManagedConnectionFactory and ActivationSpec JavaBeans. The following figure describes the association between a resource adapter instance and its various ManagedConnectionFactory and ActivationSpec JavaBeans.

Resource Adapter Instance (Composition)

A ManagedConnectionFactory JavaBean represents outbound connectivity information to an EIS instance from an application by way of a specific resource adapter instance. This contains the configuration information pertaining to outbound connectivity to an EIS instance. Refer to Connection Management for more details on the ManagedConnectionFactory JavaBean.

When a ManagedConnectionFactory JavaBean is created, it may inherit the ResourceAdapter JavaBean (which represents the resource adapter instance) configuration information, and overrides specific global defaults, if any, and may add other configuration information specific to outbound connectivity.

That is, in the case of outbound communication, the outbound connectivity configuration is a union of ResourceAdapter JavaBean and ManagedConnectionFactory JavaBean configuration, with the intersecting configuration properties based on the ManagedConnectionFactory JavaBean settings.

Outbound communication is initiated by an application and the communication occurs in the context of an application thread, even though resource adapter threads may be involved in the interaction. Note, a resource adapter may use the work management contract (refer to Work Management) to request threads to do work.

The ResourceAdapterAssociation interface specifies the methods to associate a ManagedConnectionFactory JavaBean with a ResourceAdapter JavaBean.

Prior to using a ManagedConnectionFactory JavaBean, the application server must create an association between the ManagedConnectionFactory JavaBean and a ResourceAdapter JavaBean, by calling the setResourceAdapter method on the ManagedConnectionFactory JavaBean. A successful association is established only when the setResourceAdapter method on the ManagedConnectionFactory JavaBean returns without throwing an exception.

The setResourceAdapter method on the ManagedConnectionFactory JavaBean must be called exactly once; that is, the association must not change during the lifetime of a ManagedConnectionFactory JavaBean.

An ActivationSpec JavaBean represents inbound connectivity information from an EIS instance to an application by way of a specific resource adapter instance. This contains the configuration information pertaining to inbound connectivity from an EIS instance. Refer to Message Inflow for more details on the ActivationSpec JavaBean.

When an ActivationSpec JavaBean is created, it may inherit the ResourceAdapter JavaBean (which represents the resource adapter instance) configuration information, and overrides specific global defaults, if any, and may add other configuration information specific to inbound connectivity.

That is, in the case of inbound communication, the inbound connectivity configuration is a union of ResourceAdapter JavaBean and ActivationSpec JavaBean configuration, with the intersecting configuration properties based on the ActivationSpec JavaBean settings.

Inbound communication is initiated by an EIS instance and the communication occurs in the context of a resource adapter thread. There are no application threads involved. Note, a resource adapter may use the work management contract (refer to Work Management) to request threads to do work.

The ResourceAdapterAssociation interface specifies the methods to associate an ActivationSpec JavaBean with a ResourceAdapter JavaBean.

Prior to using an ActivationSpec JavaBean, the application server must create an association between the ActivationSpec JavaBean and a ResourceAdapter JavaBean, by calling the setResourceAdapter method on the ActivationSpec JavaBean. A successful association is established only when the setResourceAdapter method on the ActivationSpec JavaBean returns without throwing an exception.

The setResourceAdapter method on the ActivationSpec JavaBean must be called exactly once; that is, the association must not change during the lifetime of an ActivationSpec JavaBean.

The following are some likely situations during which an application server would shutdown a resource adapter instance:

Irrespective of what causes a resource adapter instance to be shutdown, the application server must use the following two phases to shutdown a resource adapter instance.

Resource Adapter Lifecycle (State Diagram)

The ResourceAdapter JavaBean should be treated as a central authority or registry for resource adapter instance specific information, and it should have access to the overall state of the resource adapter instance (network endpoints, etc.). This helps in the manageability of the resource adapter instance, and in performing an orderly shutdown.

Some conventions to follow:

The above conventions enable a ResourceAdapter JavaBean to effectively manage the resource adapter instance and to perform an orderly shutdown of the resource adapter instance.

There is at most one ResourceAdapter JavaBean instance per resource adapter instance. But there can be many ManagedConnectionFactory, ActivationSpec or administered object instances (Administered Objects) per resource adapter instance.

The ResourceAdapter JavaBean instance is created and configured during resource adapter deployment. The ManagedConnectionFactory, ActivationSpec and administered object instances are created and configured during the lifetime of a resource adapter instance.

At runtime, the resource adapter internally uses a union of the configured ResourceAdapter and ManagedConnectionFactory JavaBean properties, to represent outbound communication configuration.

Similarly, at runtime, the resource adapter internally uses a union of the configured ResourceAdapter and ActivationSpec JavaBean properties, to represent inbound communication configuration.

Although the lifecycle management contract is primarily intended for a managed environment, it may still be used in a non-managed environment provided that the application that bootstraps a resource adapter instance is capable of managing its lifecycle.

Lifecycle Management Model (Sequence Diagram)

The application server uses the deployment information specified by way of the deployment descriptor mechanism (specified in section Requirements) and metadata annotations (specified in Deployment Descriptors and Annotations) to configure the resource adapter in the operational environment.

The resource adapter provides connection and connection factory interfaces. A connection factory acts as a factory for EIS connections. For example, javax.sql.DataSource and java.sql.Connection interfaces are JDBC-based interfaces for connecting to a relational database.

The CCI (specified in Common Client Interface) defines jakarta.resource.cci.ConnectionFactory and jakarta.resource.cci.Connection as interfaces for a connection factory and a connection, respectively.

The application component does a lookup of a connection factory in the Java Naming and Directory Interface™ (JNDI) name space. It uses the connection factory to get a connection to the underlying EIS. The connection factory instance delegates the connection creation request to the ConnectionManager instance.

The ConnectionManager enables the application server to provide different quality-of-services in the managed application scenario. These quality-of-services include transaction management, security, error logging and tracing, and connection pool management. The application server provides these services in its own implementation-specific way. The connector architecture does not specify how the application server implements these services.

The ConnectionManager instance , on receiving a connection creation request from the connection factory , does a lookup in the connection pool provided by the application server. If there is no connection in the pool that can satisfy the connection request, the application server uses the ManagedConnectionFactory interface (implemented by the resource adapter) to create a new physical connection to the underlying EIS. If the application server finds a matching connection in the pool, it uses the matching ManagedConnection instance to satisfy the connection request.

If a new ManagedConnection instance is created, the application server adds the new ManagedConnection instance to the connection pool.

The application server registers a ConnectionEventListener with the ManagedConnection instance. This listener enables the application server to get event notifications related to the state of the ManagedConnection instance. The application server uses these notifications to manage connection pooling, manage transactions, cleanup connections, and handle any error conditions.

The application server uses the ManagedConnection instance to get a connection instance that acts as an application-level handle to the underlying physical connection. An instance of type jakarta.resource.cci.Connection is an example of such a connection handle. An application component uses the connection handle to access EIS resources.

The resource adapter implements the XAResource interface to provide support for transaction management. The resource adapter also implements the LocalTransaction interface so that the application server can manage transactions internal to a resource manager. The chapter on transaction management describes this transaction management contract between the application server (and its transaction manager) and the resource adapter (and its underlying resource manager).

Architecture Diagram: Managed Application scenario

The following steps are involved in a managed scenario:

1 The application assembler or component provider specifies connection factory requirements for an application component using a deployment descriptor mechanism. For example, a bean provider specifies the following elements in the deployment descriptor for a connection factory reference. Note that the connection factory reference is part of the deployment descriptor for Jakarta Enterprise Bean components and not the resource adapter. Refer Jakarta Enterprise Beans specification (see Jakarta Enterprise Beans Specification, version 4.0) for details on the deployment mechanism for Jakarta Enterprise Bean components:

2 During resource adapter deployment, the deployer sets the configuration information (example: server name, port number) for the resource adapter. The application server uses a configured resource adapter to create physical connections to the underlying EIS. Refer to API Requirements for details on packaging and deployment of a resource adapter.

3 The application component looks up a connection factory instance in the component’s environment using the JNDI interface.

The JNDI name passed in the method NamingContext.lookup is the same as that specified in the res-ref-name element of the deployment descriptor. The JNDI lookup results in a connection factory instance of type jakarta.resource.cci.ConnectionFactory as specified in the res-type element.

4 The application component invokes the getConnection method on the connection factory to get an EIS connection. The returned connection instance represents an application-level handle to an underlying physical connection.

An application component obtains multiple connections by calling the method getConnection on the connection factory multiple times.

jakarta.resource.cci.Connection cx = cxf.getConnection();

5 The application component uses the returned connection to access the underlying EIS by way of the resource adapter. Common Client Interface specifies in detail the application programming model for EIS access.

6 After the component finishes with the connection, it closes the connection using the close method on the Connection interface.

cx.close();

7 If an application component fails to close an allocated connection after its use, that connection is considered an unused connection. The application server manages the cleanup of unused connections. When a container terminates a component instance, the container cleans up all connections used by that component instance. Refer section ManagedConnection and Scenario: Connection Event Notifications and Connection Close for details on the cleanup of connections.

In a non-managed application scenario, the application developer follows a similar programming model to the managed application scenario. The non-managed case involves looking up of a connection factory instance, getting an EIS connection, using the connection for EIS access, and finally closing the connection.

Connection handles are application level handles to underlying physical connections and are light-weight objects, especially when dissociated from the ManagedConnection . Creation of a connection handle does not necessarily result in the creation of a new physical connection to the EIS. The ManagedConnection , which represents the actual underlying physical connection, should maintain any session or transaction state data associated with that connection to the EIS. An application component may not derive much benefit from caching these handles, although this is allowed in this specification. Application components are recommended to obtain and cache the Connection Factory objects instead. For more information, see ConnectionFactory and Connection.

An application component is recommended to obtain a connection handle from the connection factory, use the connection handle to interact with the EIS by way of the resource adapter, and close the connection handle after finishing with it.

The application component is recommended to explicitly close the connection handle as soon as the handle has been used and is not required later. This reduces the possibility of connection leaks and enhances the application server’s ability to pool physical connections to the EIS (see Connection Pool Implementation).