InterChange Server

InterChange Server is a multi-threaded, Java-based execution framework for collaborations. InterChange Server runs within its own Java Virtual Machine (JVM). InterChange Server runs on Windows and UNIX systems. This section describes the following the services and features of InterChange Server:

Event management service

InterChange Server persistently stores every business object that it receives during the execution of a collaboration. This allows InterChange Server to recover from an unexpected termination or from the failure of a collaboration without losing event notifications or calls.

Connector controllers

A connector controller is an interface between the client-side of a connector and InterChange Server. A connector controller routes business objects as they traverse the IBM WebSphere InterChange Server system, linking the client-side of connectors to collaborations and managing the mapping process.

Through the connector controller, an administrator can:

Repository

InterChange Server maintains configuration information and definitions of all objects in a persistent store called the InterChanger Server repository, which consists of a set of tables in a relational database. The tables store object definitions and configuration information in the form of XML documents.

Database connectivity service

The database connectivity service manages interactions between InterChange Server and the repository. The database connectivity service interacts with the repository by means of the Java Database Connectivity API (JDBC), as Figure 14 illustrates.

Figure 14. Database connectivity service and the repository


Note:
Some databases have Open Database Connectivity (ODBC) drivers but do not have native JDBC drivers. For those databases, you can use an available JDBC-to-ODBC bridge.

An InterChange Server implementation supports a number of database vendors and continues to certify additional databases. For the current list of supported databases, refer to the System Installation Guide for Windows or for UNIX.

Database connection pools

You can use the System Manager tool of the IBM WebSphere InterChange Server system to define database connection pools in InterChange Server. User-defined database connection pools make it possible for developers to directly access relational databases from within a collaboration or map. This feature provides support for

High availability

The IBM WebSphere InterChange Server system can be configured to provide high availability (HA) for InterChange Server (ICS).

On Windows systems, the HA configuration runs under Microsoft Cluster Server (MSCS) software. The HA configuration requires two Microsoft-certified cluster server machines. The servers are set up with identical InterChange Server system configurations and are designated in the MSCS software as a cluster system. One machine is configured in MSCS as the primary (the active server until a failure occurs), and the other as the backup. The two machines share a cluster name and a cluster IP address that external processes use for accessing the active server. Both the primary and backup servers have access to a shared RAID storage system, which is controlled by the active server.

When a hardware failure is detected, the HA configuration provides shutdown of the ICS, and automatic migration and restart of the ICS (and the third-party software, and HA-supported connectors) on the cluster backup system. The cluster backup server becomes the active server, assuming the cluster name and IP address of the primary server, and automatically takes over system processing until such time that you correct the failure on the primary server and initiate a failback (that is, manually return processing to the primary server)

For an overview of the HA environment, see the System Administration Guide. For information on how to configure ICS for use in an HA environment, see your System Installation Guide.

Transaction service

Any application integration solution encounters risks as it moves data from one application to another. When data leaves the protected realm of one application and its database and travels across a network to another application, any number of problems can occur. For example:

Consider a collaboration that involves three applications: human resources, payroll, and product cost accounting. Each stores employee salaries. Figure 15 is a high-level view of the cross-application business logic for handling an employee's salary increase.

Figure 15. Three applications process employee salaries


When an employee gets a raise, someone enters a new salary into the human resources application. The collaboration automatically updates the employee salary in the payroll application, and then adjusts the project cost in the product cost accounting application.

If a system error prevents the salary update from reaching the product cost accounting application, data inconsistency can result. The value for the employee's salary is now different in the various applications, and the product cost is incorrectly computed.

Traditionally, painstaking cross-checking was required or the data remained faulty until someone noticed the problem. The IBM WebSphere InterChange Server system, however, offers a higher level of service with strict controls to which you can trust enterprise data, with services that can run a collaboration as if it were a type of transaction.

Transactional collaborations

Transactional qualities are desirable and achievable for collaborations where data consistency is important across applications. Like other transactions, a transactional collaboration involves a set of steps. If an error occurs, InterChange Server can undo each completed step, performing a transaction-like rollback.

However, collaborations are different from traditional transactions in some important ways:

The techniques that InterChange Server uses to support transactional collaborations, therefore, differ from those that support traditional transactions. The transaction levels associated with collaborations define the rigor with which InterChange Server enforces transactional semantics.

Recovery features

An InterChange Server implementation provides features for improving the time it takes ICS to reboot after a failure, for making ICS available for other work before all flows have been recovered, and for controlling the resubmission of failed events:

Copyright IBM Corp. 1997, 2004