InterChange Server Express ist ein Java-basiertes, multithreadfähiges Ausführungsframework für Collaborations. InterChange Server Express wird in einer eigenen Java Virtual Machine (JVM) ausgeführt. In diesem Abschnitt werden die folgenden Services und Funktionen von InterChange Server Express beschrieben:
InterChange Server Express speichert jedes Geschäftsobjekt persistent, das während der Ausführung einer Collaboration empfangen wird. Dadurch kann InterChange Server Express die Arbeit nach einer unerwarteten Beendigung oder nach einem Fehler einer Collaboration fortsetzen, ohne Ereignisbenachrichtigungen oder Aufrufe zu verlieren.
Ein Connector-Controller stellt eine Schnittstelle zwischen der Clientseite eines Connectors und InterChange Server Express dar. Ein Connector-Controller leitet Geschäftsobjekte auf ihrem Weg durch das IBM WebSphere Business Integration Server Express-System weiter, indem er die Clientseite von Connectors mit Collaborations verbindet und den Zuordnungsprozess verwaltet.
Der Connector-Controller bietet dem Administrator folgende Möglichkeiten:
InterChange Server Express verwaltet Konfigurationsinformationen und Definitionen aller Objekte in einem persistenten Speicher, der als InterChange Server-Repository bezeichnet wird und aus einer Reihe von Tabellen in einer relationalen Datenbank besteht. Die Tabellen speichern Objektdefinitionen und Konfigurationsdaten in Form von XML-Dokumenten.
Der Datenbankkonnektivitätsservice verwaltet Interaktionen zwischen InterChange Server Express und dem Repository. Der Datenbankkonnektivitätsservice interagiert mit dem Repository über die Java Database Connectivity-API (JDBC-API).
Sie können das System Manager-Tool des IBM WebSphere Business Integration Server Express-Systems zur Definition von Datenbankverbindungspools in InterChange Server Express verwenden. Benutzerdefinierte Datenbankverbindungspools ermöglichen Entwicklern einen direkten Zugriff auf relationale Datenbanken aus einer Collaboration oder Zuordnung heraus. Diese Funktion bietet Unterstützung für:
Das IBM WebSphere Business Integration Server Express-System unterstützt Services, die eine Collaboration so ausführen können, als wäre sie ein Typ von Transaktion.
Transaktionsorientierte Qualitäten sind für Collaborations wünschenswert, bei denen die Datenkonsistenz über Anwendungen hinweg wichtig ist. Ebenso wie andere Transaktionen umfasst eine transaktionsorientierte Collaboration eine Reihe von Schritten. Wenn ein Fehler auftritt, kann InterChange Server Express jeden ausgeführten Schritt durch eine transaktionsartige ROLLBACK-Operation rückgängig machen.
In einigen wichtigen Aspekten unterscheiden sich Collaborations hingegen von traditionellen Transaktionen:
Die Verfahren, mit denen InterChange Server Express transaktionsorientierte Collaborations unterstützt, unterscheiden sich daher von denen, die traditionelle Transaktionen unterstützen. Die den Collaborations zugeordneten Transaktionsebenen definieren den Genauigkeitsgrad, mit dem InterChange Server Express die Transaktionssemantik umsetzt.
Eine InterChange Server Express-Implementierung stellt Funktionen bereit, die die für den Warmstart von InterChange Server Express nach einem Fehler benötigte Zeitdauer verkürzen, die InterChange Server Express bereits vor Abschluss der Wiederherstellung aller Arbeitsabläufe für andere Operationen verfügbar machen und die die erneute Übergabe fehlgeschlagener Ereignisse steuern:
InterChange Server Express wartet mit der Ausführung eines Warmstarts nicht ab, bis Collaborations und Connectors wiederhergestellt sind. Collaborations und Connectors können asynchron wiederhergestellt werden, nachdem InterChange Server Express gestartet wurde. Dadurch können die Fehlerbehebungstools von System Manager, wie zum Beispiel System Monitor, genutzt werden, während die Connectors und Collaborations noch in der Wiederherstellung begriffen sind.
Die Verwendung dieser Funktion ist optional und wird über die Collaboration-Objekteigenschaften konfiguriert. Wenn Sie diese Funktion für eine Collaboration aktivieren, wird die Wiederherstellung der WIP-Abläufe der Collaboration verzögert, bis der Server erneut gestartet wurde, so dass die mit diesen Abläufen verbundene Speicherbelegung eingespart wird. Nach dem erneuten Starten des Servers können Sie die Ereignisse erneut übergeben.
Es ist vielleicht sinnvoll, eine Wiederherstellung daran zu hindern, alle Serviceaufrufe, die im Übergangsstatus waren, als der Fehler auftrat, automatisch erneut zu übergeben, um die Möglichkeit auszuschließen, dass eine nicht transaktionsorientierte Collaboration doppelte Ereignisse an eine Zielanwendung sendet. Dies wird dadurch erreicht, dass die Collaboration (vor dem Serverausfall) so konfiguriert wird, dass sie jedes Serviceaufrufereignis im Übergangsstatus speichert, wenn ein Fehler eintritt und eine Wiederherstellung erfolgt. Wenn InterChange Server Express wiederhergestellt ist, verbleiben die Abläufe, die gerade Serviceaufrufe verarbeiteten, im Übergangsstatus, und Sie können einzelne, nicht aufgelöste Abläufe untersuchen und steuern, wann (oder ob) sie erneut übergeben werden.
Für JMS-Connectors (d. h. Connectors, die JMS als Transportmechanismus verwenden) können die folgenden Merkmale im Hinblick auf eine garantierte Ereigniszustellung in Wiederherstellungsfällen nützlich sein:
Die Funktion für containerverwaltete Ereignisse gilt für JMS-Connectors, die einen JMS-Ereignisspeicher verwenden. Sie stellt sicher, dass bei Auftreten eines Systemabsturzes und Ausführung einer Wiederherstellung ein Ereignis, das gerade zwischen dem Ereignisspeicher und dem Connector-Framework verarbeitet wurde, genau einmal vom Connector-Framework empfangen, und nicht zweimal zugestellt wird. Diese Funktion ist optional und wird über Connectoreigenschaften konfiguriert. Sie wird nur mit Connectors verwendet, die mit JMS als Transportmechanismus arbeiten.
Die Funktion zur Beseitigung doppelter Ereignisse gilt für JMS-Connectors und verwendet eindeutige Ereignis-IDs im anwendungsspezifischen Code des Connectors, um sicherzustellen, dass Ereignisse nicht doppelt an die Zustellungswarteschlange gesendet werden. Diese Funktion ist optional und wird über Connectoreigenschaften konfiguriert. Sie wird nur mit Connectors verwendet, die mit JMS als Transportmechanismus arbeiten.