Connector components

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 C++ connector. The figure includes the C++ translation layer, which translates business objects between the C++ and Java environments. The figure also shows the C++ connector library in the generic services that the connector framework provides.

Figure 3. Components of a C++ connector


As Figure 3 shows, a connector has the following components:

Connector framework

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++.

Other integration brokers

In an IBM WebSphere business integration system that uses a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message Broker), or WebSphere Application Server 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 message broker or WebSphere Application Server. For information on the connector architecture with InterChange Server as the integration broker, see Connector controller..

Figure 4. High-level connector architecture with a WebSphere message 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)
  • Provides mapping between application-specific and generic business objects, and manages business object transfers between the connector and collaborations running in InterChange Server.
  • Provides other management services, such as monitoring the status of the connector

Transport layer
  • Handles the exchange of business objects between the connector and the integration broker
  • Manages the exchange of startup and administrative messages between the connector controller and the client connector framework
  • Keeps a list of subscribed business objects

C++ translation layer
  • Provides a Java-to-C++ translation layer that translates business objects between the C++ and Java environments.

C++ connector library on page C++ connector library.

  • Provides generic services to the application-specific component in the form of C++ classes and methods

Connector controller

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 WebSphere 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.

Note:
A connector controller is instantiated by InterChange Server for each connector that has been defined in the InterChange Server repository. You do not need to provide code for the connector controller, as this component is internal to InterChange Server.

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.

Note:
The connector controller handles its own internal errors as well as errors from the client connector framework. In general, the connector controller logs exceptions and then evaluates whether further action is needed. When status messages are returned by the client connector framework, the connector controller forwards the messages to the collaboration.

Mapping services

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 documentation set.

Business object subscription and publishing

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:

Figure 7 illustrates the connector architecture for subscription handling.

Figure 7. Subscription handling


For more information on subscriptions, see "Request processing".

Transport layer

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:

The transport mechanism of the transport layer depends on the integration broker in your business integration system:

Transport mechanism with InterChange Server

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.

Note:
For more information, see "Connector controller".

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

Transport-layer task Transport mechanism
Connector startup and exchange of startup messages between the connector controller and the client connector framework CORBA
Administrative messages about the state of the client connector framework CORBA
Sending business objects to the connector, initiated with a collaboration service call request CORBA
Sending business objects from the connector, initiated with an event delivery CORBA A message-oriented middleware system, including one of the following:
  • WebSphere MQ
  • Java Messaging Service (JMS)

This transport mechanism has the following tasks:

This business integration system uses CORBA technology provided by the IBM Object Request Broker (ORB). Figure 9 illustrates the CORBA communication mechanism.

Figure 9. Communication within a connector using CORBA IIOP


Supported message-oriented middleware includes:

Note:
To configure a connector's transport mechanism for event delivery, set the DeliveryTransport standard property. For more information on this property, see Appendix A, Standard configuration properties for connectors

Transport mechanism with other integration brokers

If the integration broker is a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message Broker) or WebSphere Application Server, the transport layer handles the exchange of information between the connector framework and the integration broker. The transport layer for a connector that communicates with the broker 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 your integration broker.

C++ connector library

The connector framework includes the C++ connector library, which provides generic services and utilities for connector development. The primary services provided by the C++ connector library are:

Note:
For a summary of the C++ connector library and its classes, see Overview of the C++ connector library.

The C++ connector library is available on both Windows and UNIX operating systems to support the execution of C++ connectors:

Because Java is operating-system-independent, the Java connector library is available on all systems that the WebSphere Business Integration Adapters product supports

Application-specific component

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 application programming interface (API) provided by the application.

If the application API is written in C or C++, you write the application-specific portion of the connector in C++, accessing services of the connector framework through the C++ connector library. At runtime, the application-specific component is invoked from a Java class in the connector framework.

Copyright IBM Corp. 1997, 2004