Understanding Adapters

 

BEA WebLogic Application Integration provides a WebLogic-based integration solution that supports existing and forthcoming standards for integrating applications.

This guide provides information on the following subjects:

• What Is a J2EE-Compliant Adapter?

• Adapters and Their Components

 

---

What Is a J2EE-Compliant Adapter?

An adapter is a software component that provides an interface between an application and an integration server. A J2EE adapter is an adapter that conforms to the J2EE specification as defined by Sun. Such an adapter can be hosted in any J2EE-compliant application server. This allows a simple adapter to be used in a wide range of software environments.

The advent of standards for adapters will also encourage developers to write a wider variety of adapters, thus providing more choices for implementing applications that make use of one or more EIS. An adapter developed using the Application Integration ADK and running in the BEA WebLogic Application Integration environment can provide value-added features that go beyond those of J2EE Connector Architecture. These features include the ability to generate events and to expose XML interfaces to services.

Adapters developed with the Application Integration ADK can also run outside of the WebLogic Server environment, but they will not have the ability to generate events and expose application view interfaces. For information about adapter components, see Adapters and Their Components.

BEA WebLogic Application Integration provides the tools to build and use two types of adapters:

• Service Adapters

• Event Adapters

Service Adapters

Service adapters are J2EE adapters with extended capabilities. Service adapters receive an XML request document from a client and invoke a specific function in the underlying EIS. They are consumers of XML and may or may not provide a response. There are two types of service adapters: asynchronous and synchronous. Service adapters perform the following four functions:

• Receiving service requests from a client (an XML document) as input.

• Transforming the XML request document into the EIS-specific format. The request document conforms to the request XML schema for the service. The request XML schema is based on metadata in the EIS.

• Invoking the underlying function in the EIS and wait for its response.

• Transforming the response from the EIS-specific data format to an XML document that conforms to the response XML schema for the service. The response XML schema is based on metadata in the EIS.

Event Adapters

Event adapters are designed to propagate information from an EIS into the Application Integration environment. This type of adapter can be described as a publisher of information.

There are two basic types of event adapters: in-process and out-of-process. In-process event adapters execute within the same process as the EIS. Out-of-process adapters execute in a separate process.

The ADK implements basic event generation support capabilities in the form of base Java classes that may be extended. This allows adapter developers to focus on the EIS-specific aspects of the adapter. Within the BEA WebLogic Application Integration environment, all event adapters perform the following three functions:

• Responding to "events" that occur inside the running EIS and extract data about the event from the EIS into the adapter.

• Transforming event data from the EIS specific format to an XML document that conforms to the XML schema for the event. The XML schema is based on metadata in the EIS.

• Propagating the event into the Application Integration environment that delivers it to one or more clients.

 

---

Adapters and Their Components

An adapter is composed of two major components. The first component is called the design-time component, which leverages web interfaces to enable metadata browsing and definitions of application views, events, and services. The second component is called the run-time component. At runtime it handles generation of events and the invocation of system-level functions in response to requests by the application view.

Adapter Design-Time Component

The design-time component of an adapter is implemented as a series of Java Server Pages (JSP) pages. The ADK provides many of these JSPs, which an adapter developer can extend. This component is responsible for presenting a view of the metadata within the EIS instance. The design-time component is connected to the view by making use of the adapter's run-time component to communicate with the EIS. Figure 2-1 shows the design-time component and its relationship to the run-time adapter component.

Figure 2-1 Adapter Design-Time Component

 

Adapter Run-Time Component

An adapter is capable of supporting both Application Integration-to-EIS communication, in the form of services, and EIS-to-Application Integration communication in the form of events. These two types of communication are handled by two distinct software components within the adapter:

• Application Integration-to-EIS (Service Adapter Component)

• EIS-to-Application Integration (Event Adapter Component)

Application Integration-to-EIS (Service Adapter Component)

The software component of an adapter that is responsible for handling service invocations, called the service adapter component, is an industry standard, J2EE specification-compliant adapter. The J2EE engine hosts this component and manages physical connections to the EIS, login authentication, and transaction management as specified by the J2EE standard.

EIS-to-Application Integration (Event Adapter Component)

The software component of an adapter that is responsible for handling event generation and delivery is called the EIS-to-Application Integration adapter component. This software component leverages industry standard JMS technologies to allow an EIS to notify interested parties of events within itself. This capability is not addressed in the J2EE specification is unique to Application Integration. The event adapter component is composed of an event generator component and an event router component.

Event Generator

The event generator, which is specifically designed for each EIS, is responsible for detecting events within the EIS and generating an event object that reflects the event and the context in which it occurred. The event generator then passes the event object to the event router for delivery to clients subscribed.

Event Router

The event router is a generic software component provided by the Integration Framework component that manages subscriptions to event notifications by subscribed clients and handles the delivery of event objects to those clients when event objects of a given type are published by the event generator. Event subscribers are application views that subscribe to the event types that have been configured within them. The event generator is capable of delivering a single event object to any number of subscribing application views in any number of Application Integration instances. This allows a single EIS system to supply event notifications to multiple Application Integration instances.

Figure 2-2 Adapter Run-time Component

 

This figure illustrates the following steps:

1. Some event occurs within the EIS.

2. The event generator detects the event and checks to see if anyone is subscribed to this type of event. To do this, the event generator checks the types of events that have subscriptions, as maintained by the event router. The event generator creates an event object containing pertinent data about the event and sends it to the event router.

3. The event router sends the event object to all application views that are subscribed to the type of event object it received from the event generator.

4. The application view receives the event object, and notifies any listeners that have registered for the type of event. It is assumed that a WebLogic Process Integrator process flow or some custom business logic code is listening for the designated type of event.

5. The process flow or custom code processes the event object and its data and determines that it should invoke a service in response to the event.

6. The application view combines the data from the event object with data it has in its state variables and makes the service invocation.

7. The application view accepts the service request and determines which interaction to request on the resource adapter. This mapping from service name to adapter interaction allows the service to be business-centric and not system function-centric.

8. The resource adapter carries out the request interaction with the EIS and passes the data it received from the application view.

The EIS processes the request and responds to the adapter. This response propagates back out through the application view and is received by the process flow or custom code component. This component may take further action based on the response.