The connector represents the application in the WebSphere business integration system, performing tasks in support of the application. For example, the connector polls the application for events and sends business objects that represent events to the integration broker. The connector also performs tasks in support of integration-broker requests, such as retrieving or modifying application data.
Figure 3 illustrates the components of a Java connector. The Java connector library is included in the generic services that the connector framework provides.
Figure 3. Components of a Java connector
As Figure 3 shows, a connector has the following components:
The connector framework manages interactions between the connector and the integration broker. IBM provides this component to ease connector development. The connector framework is written in Java and includes a C++ extension to allow the development of the application-specific component in C++.
WebSphere MQ Integrator Broker |
---|
In an IBM WebSphere business integration system that uses WebSphere MQ Integrator Broker as its integration broker, the connector framework is a nondistributed component; that is, it resides entirely on the adapter machine. Figure 4 shows the high-level connector architecture with the WebSphere MQ Integrator Broker. For information on the connector architecture with InterChange Server as the integration broker, see Connector controller. |
Figure 4. High-level connector architecture with WebSphere MQ Integrator Broker
The connector framework provides the
services that Table 4 summarizes.
Table 4. Services of the connector framework
Component | Services |
---|---|
Connector controller (InterChange Server only) |
|
Transport layer |
|
Java connector library |
|
In an IBM WebSphere business integration system that uses InterChange Server as its integration broker, the connector framework is distributed to take advantage of services that InterChange Server provides. This distributed connector framework contains the following components:
Figure 5 illustrates the basic components of a connector within the InterChange Server system. InterChange Server, collaborations, and connector controllers run as a single process, and each connector runs as a separate process.
Figure 5. High-level connector architecture with InterChange Server
The connector controller manages communication between the connector framework and collaborations. The primary type of information that connector components exchange is a business object. Other types of connector communication include startup information and administrative messages.
In addition to the features that the client connector framework provides,
the connector controller provides the services that Table 5 summarizes.
Table 5. Services of the connector controller
Connector controller service | Description |
---|---|
Mapping services | The connector controller calls the map associated with each business object to transfer data between generic business objects and application-specific business objects. |
Business object subscription and publishing | The connector controller manages collaboration subscriptions to business object definitions. It also manages connector queries about subscription status for a business object. |
Service call requests (For more information, see "Initiating a request with InterChange Server".)
| The connector controller delivers collaboration service call requests to connectors. It also accepts return status messages and business objects from the connector and forwards them to InterChange Server. |
Communication between components (For more information, see "Transport mechanism with InterChange Server".) | The connector controller contains a transport driver to handle its side of the mechanism for exchanging business objects and administrative messages between the connector controller and client connector framework. It also performs remote-end synchronization to manages high-level synchronization between itself and the client connector framework. These services enable the connector controller to communicate with the connector, which might be installed remotely. |
The client connector framework sends and receives information in an application-specific business object. However, a collaboration generates information in a generic business object. Because application-specific business objects can differ from generic business objects, the InterChange Server system must convert business objects from one form to another so that data can be transmitted across the system. Data is transformed between generic and application-specific business objects by data mapping.
Data mapping converts business objects from generic to application-specific and from application-specific to generic forms. An application-specific business object closely reflects the data entity that it represents. Its structure and content match that of the entity. A generic business object, on the other hand, typically contains a superset of attributes that represents a typical, cross-application view of an entity's data. This type of business object is a composite of common information that many applications have about a particular entity. A generic business object serves as an intermediate point between data models.
Mapping is initiated by the connector and executed at runtime. For example, when a connector needs to map an application-specific business object to a generic business object, it runs an associated map to transfer data between the application-specific business object and the generic business object before sending the generic business object to a collaboration.
Mapping is handled by the connector controller. Figure 6 illustrates the connector in the InterChange Server system and shows the components of the connector.
Figure 6. Mapping in the InterChange Server System
For more information on data mapping, refer to the Map Development Guide in the IBM WebSphere InterChange Server.
Subscription handling is managed through a subscription list, which is a list of business objects to which collaborations have subscribed. Both the connector framework and the connector controller maintain a subscription list, as follows:
When collaborations start, they subscribe to the business objects that they are interested in by informing the connector controller of their interest. The connector controller stores this information in a subscription list, which contains the name of the subscribing collaboration and the business object definition name and verb.
When the connector controller receives a business object from the client connector framework, it checks its own subscription list to determine which collaborations have subscribed to this type of business object. It then forwards the business object to the subscribing collaboration.
At initialization, the connector downloads its business object definitions and configuration properties from the InterChange Server repository. It also requests the subscription list from the connector controller. The subscription list that the connector controller sends to the client connector framework contains only the names of the business object definitions and verbs for these subscribed business objects. The connector framework stores this subscription list locally. Whenever a new collaboration starts up and subscribes to a business object, the connector controller notifies the connector framework so that the local subscription list is kept current.
As part of the initialization of the client connector framework, the connector framework instantiates a subscription manager. The subscription manager tracks all subscribe and unsubscribe messages that arrive from the connector controller and maintains a list of active business object subscriptions. Through the subscription manager, the application-specific connector component can query the connector framework to find out whether any collaborations are interested in a particular kind of business object.
Figure 7 illustrates the connector architecture for subscription handling.
Figure 7. Subscription handling
For more information on subscriptions, see "Request processing".
The transport layer of the connector framework handles the exchange of information between the connector and the integration broker. The transport layer of the connector framework provides the following services:
Message service | Description |
---|---|
Request processing | Receives a business object from the integration broker and sends it to the application-specific component of the connector |
Event notification | Receives a business object from the application-specific component of the connector and sends it to the integration broker |
The transport mechanism of the transport layer depends on the integration broker in your business integration system:
If the integration broker is InterChange Server (ICS), the transport layer handles the exchange of information between the connector controller, which resides within ICS, and the client connector framework.
As Figure 8 shows, the transport layer for a connector that communicates with InterChange Server might include two transport drivers, one for the Common Object Request Broker (CORBA) and one for some message-oriented middleware (MOM).
Figure 8. Connector architecture for communicating with InterChange Server
Table 6 summarizes the tasks that the transport layer performs and
the transport mechanisms it can use.
Table 6. Tasks of the transport layer
This transport mechanism has the following tasks:
In the CORBA architecture, objects communicate through the Object Request Broker (ORB). The ORB is a set of libraries and services that connects an object, such as a connector controller, with another object, such as a client connector framework. The ORB enables objects to find each other at startup and to invoke methods on each other at runtime.
With the ORB, the CORBA architecture provides a Naming Service that allows an object on the ORB to locate another object by name. At startup, the client connector framework uses the Naming Service to connect to the InterChange Server. The client connector framework then uses the ORB to request its application-specific connector configuration properties and its list of supported business object definitions from the repository. For more information, see Starting up a connector.
Once the client connector framework and connector controller are active and connected, the client connector framework requests its list of business object subscriptions. At this point, connector initialization is complete, and the connector starts polling for events.
Changes in state of the client connector framework can be initiated from System Manager in the WebSphere Business Integration Toolset. Such changes include start, stop, pause, and resume operations, as well as retrieving the status. In addition, administrative messages can specify remote message logging.
CORBA technology includes the Internet Inter-ORB Protocol (IIOP) transport protocol. CORBA IIOP provides a lightweight, high-performance, synchronous communication mechanism that the connector controller and the client connector framework use to interact. Because the IIOP communication mechanism is synchronous, connector components can quickly determine whether a business object exchange was successful and can take appropriate action if necessary.
When CORBA is used for business object subscription delivery, multiple business objects can be delivered concurrently, improving performance for subscription delivery. Using CORBA as a communication mechanism provides particularly good performance on a high-bandwidth LAN network.
A messaging system provides asynchronous message delivery across a network, enabling connector components to send a message and continue processing without waiting for a response. The messaging system also provides persistent messaging, allowing the connector controller and client connector framework to operate independently.
In the messaging communication mechanism, message transport is handled by transport drivers in the client connector framework and the connector controller. The message transport driver implements the low-level mechanism for exchanging data between InterChange Server and the underlying message queuing software. Messages between the components of the connector are transported in a format defined by the messaging software.
This business integration system uses CORBA technology provided by the Borland VisiBroker products. Figure 9 illustrates the CORBA communication mechanism.
Figure 9. Communication within a connector using CORBA IIOP
Supported message-oriented middleware includes:
If the integration broker is WebSphere MQ Integrator Broker, the transport layer handles the exchange of information between the connector framework and WebSphere MQ Integrator Broker. The transport layer for a connector that communicates with InterChange Server includes a single transport driver for the IBM WebSphere MQ messaging suite. Data is exchanged between applications by means of application-specific business objects, which are transported between the connector framework and the integration broker as WebSphere MQ messages. The integration broker removes the message from the MQ queue, and passes it through the message flow for the queue.
This transport mechanism uses WebSphere MQ messages to perform the following tasks:
The connector framework uses a custom data handler to transform the application-specific business object to and from an MQ message of the appropriate wire format for the destination WebSphere MQ queue.
For more detailed information on the use of MQ messages and a connector, see the Implementation Guide for WebSphere MQ Integrator Broker.
The connector framework includes the Java connector library, which provides generic services and utilities for connector development. The primary services provided by the Java connector library are:
For a summary of classes in the Java connector library, see Overview of the Java connector library.
The application-specific component of the connector contains code tailored to a particular application. This is the part of the connector that you design and code. The application-specific component includes:
You develop your code for the application-specific component to use services provided by the connector framework. The connector class library provides access to these services. You can write your connector code in C++ or Java depending on the API provided by the application.
If the application API is written in Java, you write the application-specific portion of the connector in Java, accessing services of the connector framework through the Java connector library.