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:
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.
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:
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.
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
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.
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
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.
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 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.
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:
InterChange Server does not wait for collaborations and connectors to recover before it completes boot-up; collaborations and connectors are allowed to recover asynchronously after InterChange Server has booted. This makes it possible to use System Manager troubleshooting tools, such as System Monitor and the Administer Unresolved Flows dialog, while the connectors and collaborations are still recovering.
Use of this feature is optional and is configured through the use of collaboration object properties. If you enable this feature for a collaboration, when an ICS failure occurs, the recovery of the collaboration's WIP flows is deferred until after the server has rebooted, thereby saving the memory usage associated with those flows. After the server has rebooted, you can use the Administer Unresolved Flows dialog in System Manager to resubmit the events.
You may want to prevent a recovery from automatically resubmitting all service calls that were in transit when a failure occurred, to avoid the possibility of a nontransactional collaboration sending duplicate events to a destination application. This is accomplished by configuring the collaboration (prior to the server failure) so that it will persist any service call event in the In-Transit state when a failure and recovery occurs. When InterChange Server recovers, the flows that were processing service calls remain in the In-Transit state, and you can use the Administer Unresolved Flows dialog to examine individual unresolved flows and control when (or if) they are resubmitted.
For JMS-enabled connectors (connectors that use JMS as their transport mechanism), the following features can be useful for guaranteed event delivery in recovery situations:
The container managed events feature is valid for JMS-enabled connectors that use a JMS event store. It ensures that if a system crash and recovery occurs, an event that was in process between the event store and the connector framework will be received exactly once by the connector framework, and will not be delivered twice. This feature is optional and configured through connector properties; it is used only with connectors that use JMS as their transport mechanism.
The duplicate event elimination feature, valid for JMS-enabled connectors, uses unique event identifiers in the application-specific code of the connector to ensure that events will not be delivered in duplicate to the delivery queue. This feature is optional and configured through connector properties; it is used only with connectors that use JMS as their transport mechanism