The modular architecture of an InterChange Server implementation constitutes a distributed system that accommodates many different types of site configurations. InterChange Server implementation architecture enables distributed interaction over multiple machines on a network, and distributed interaction across Internet firewalls.
Interactions between distributed InterChange Server components on a network are enabled by the Common Object Request Broker Architecture (CORBA) and by messaging technologies, including native WebSphere MQ messaging and Java Messaging Service (JMS).
Different configurations are possible. CORBA might be used for request/response interactions and administrative communications between the connector agent and ICS, with native WebSphere MQ performing the delivery of events in publish-and-subscribe operations. Alternatively, Java Messaging Service might be used for all communications and interactions between a connector agent and ICS.
The Common Object Request Broker Architecture (CORBA) defines a set of standards and interfaces for distributed objects on a network. The Object Request Broker (ORB) is a set of libraries and other components that client applications and object servers use to communicate. InterChange Server uses the IBM Java ORB product.
The ORB makes InterChange Server accessible to its clients, the connector agent, and System Manager. An InterChange Server registers with the ORB's name service, from which a client obtains the information it needs to find and start interacting with the server. The client and server perform object-to-object interactions by means of the ORB's Interface Definition Language ( IDL). At a transport level, they communicate by means of the Internet Inter-ORB Protocol (IIOP). ORB-based communication is typically used for the following purposes:
In the IIOP request/response protocol, communication either succeeds or fails immediately, so both programs must be running for the components to communicate. However, for request/response interactions in an InterChange Server implementation, you can use a connector property to set a store-and-forward mode, specifying how a connector controller will respond to a collaboration's request in a situation where the connector agent is unavailable:
Figure 16 shows the components that constitute the IBM Java ORB for use with InterChange Server. There are different components for the different languages in which InterChange Server components address their ORB drivers, but the C++ and Java components communicate with each other as one system. The IBM Transient Naming Server provides the naming service.
Figure 16. ORB components in the WebSphere InterChange Server system
These ORB components need not be separated. At some sites, all of them might reside on the same machine.
Messaging embodies a communication style in which programs asynchronously exchange discrete units of data (messages). Programs that use a messaging transport need not establish connections or wait for messages; each program asynchronously sends and receives messages by interacting with the messaging service. The messaging service provides guaranteed delivery, storing the message if the destination program is unavailable and retrying until it is available.
Messaging systems supported with an InterChange Server environment include both native IBM WebSphere MQ messaging and Java Messaging Service (JMS) software. A common implementation approach is to use a messaging system for the delivery of events in publish-and-subscribe interactions, and to use the ORB for request/response interactions. However, there can be circumstances where JMS is used for both types of interactions.
When JMS is the delivery transport mechanism, data persistence can be provided through the long-lived business processes feature. When this feature is used, a process initiated by a request on a collaboration can be placed in a waiting state with a timeout value, so that the process will be resumed if and when a specified data response is received. Use of this feature requires that the feature be enabled during the creation of the collaboration template.
The InterChange Server system supports secure socket layer (SSL) communication for distributing connector controller/connector agent interactions across Internet firewalls.
The implementation is a hub-and-spoke relationship, in which the hub is a site that has installed a complete IBM WebSphere InterChange Server system, and the spokes are remote sites that exchange data with the hub across firewalls. A spoke site requires a remote connector agent, but does not require a complete IBM WebSphere InterChange Server system.
Two alternative configurations can be used: