InterChange Server Express is a multi-threaded, Java-based execution framework for collaborations. InterChange Server Express runs within its own Java Virtual Machine (JVM). This section describes the following services and features of InterChange Server Express:
The InterChange Server Express persistently stores every business object that it receives during the execution of a collaboration. This allows the InterChange Server Express 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 the InterChange Server Express. A connector controller routes business objects as they traverse the IBM WebSphere Business Integration Server Express system, linking the client-side of connectors to collaborations and managing the mapping process.
Through the connector controller, an administrator can:
The InterChange Server Express 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 the InterChange Server Express and the repository. The database connectivity service interacts with the repository by means of the Java Database Connectivity API (JDBC).
You can use the System Manager tool of the IBM WebSphere Business Integration Server Express system to define database connection pools in InterChange Server Express. 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 Business Integration Server Express system supports services that can run a collaboration as if it were a type of transaction.
Transactional qualities are desirable for collaborations where data consistency is important across applications. Like other transactions, a transactional collaboration involves a set of steps. If an error occurs, the InterChange Server Express can undo each completed step, performing a transaction-like rollback.
However, collaborations are different from traditional transactions in some important ways:
The techniques that the InterChange Server Express uses to support transactional collaborations, therefore, differ from those that support traditional transactions. The transaction levels associated with collaborations define the rigor with which the InterChange Server Express enforces transactional semantics.
An InterChange Server Express 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 Express 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 Express has booted. This makes it possible to use System Manager troubleshooting tools, such as System Monitor, 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 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 Express recovers, the flows that were processing service calls remain in the In-Transit state, and you can 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