Unterschiedliche Verfahren für den personalisierten Zugriff
Auch hinsichtlich eines personalisierten Zugriffs auf Kernsysteme arbeiten die Architekturen unterschiedlich. Ist eine Zustimmung zu einem Vertrag notwendig oder eine Reisekostenabrechnung zu genehmigen, sollte dies zur späteren Nachvollziehbarkeit möglichst durch eine identifizierbare Person geschehen. Eine persönliche Authentifizierung des Benutzers am Kernsystem ist für die gesamte Dauer der Transaktion erforderlich. Web-Services sind grundsätzlich statuslos.
Web-Services-Architekturen und die Integration auf Basis von Werkzeugen für Enterprise Application Integration stellen Alternativen ohne Widerspruch dar. Durch das Ausnutzen der Stärken der jeweiligen Technologie entsteht ein klares Miteinander. Während EAI-Werkzeuge höhere Investitionen bei den Lizenzen erfordern, ist bei den Web-Services von erheblich höherem Implementierungsaufwand auszugehen. Für beide Ansätze lassen sich klare Einsatzgebiete identifizieren: Web-Services in der unternehmensübergreifenden, EAI in der unternehmensinternen Integration.
Um dennoch einen Status zu erhalten, ist mit Hilfe des Applikations-Servers eine spezielle Session-Komponente zu implementieren. Diese nimmt beim Login zum Beispiel ein Logon-Ticket auf, was sich in den folgenden Diensteaufrufen als Identifikation nutzen lässt. Das ist ein nicht zu unterschätzender Implementierungsaufwand. Ein EAI-Werkzeug, das über eine ausgereifte Adapter-Technologie verfügt, kann solche Sessions einfacher betreiben. Sind viele personalisierte Zugriffe erforderlich, kann der Implementierungsaufwand mit EAI wesentlich geringer ausfallen.
Ein weiteres Differenzierungsmerkmal ergibt sich beim Vergleich der Architekturen im Hinblick auf Verfügbarkeit, insbesondere bei der Ausführung verteilter Transaktionen. Diese sind generell nach dem Acid-Prinzip (Acid = Atomic, Consistent, Isolated, Durable) durchzuführen. Dabei steht Atomic für „ganz oder gar nicht“. Consistent bedeutet, dass alle Restriktionen zu beachten sind. Isolated beschreibt die Sicherheit, mit der die Transaktion durchgeführt wird, und Durable verlangt den Schutz vor Fehlern. Eine solche Fehlerquelle kann bei verteilten Transaktionen die mangelnde Verfügbarkeit eines Systems sein. Jede Integrationsarchitektur hat also sicherzustellen, dass das aufgerufene System die erhaltene Arbeitsanweisung auch durchführt.
EAI-Werkzeuge regeln dies typischerweise über Message Queues, die unabhängig von der Systemverfügbarkeit die zu verarbeitenden Nachrichten aufnehmen. Für Transaktionen bedeutet dies, dass nicht ausführbare Anweisungen zunächst in einer Queue zwischengespeichert werden. Ist das Kernsystem innerhalb eines gesetzten Timeout wieder verfügbar, kann es die Transaktion wie gewünscht abschließen und einen Commit senden. Ist dies nicht der Fall, reagiert das EAI-Werkzeug mit einem Rollback über die ursprünglichen Systeme und löscht die Anweisung wieder aus der Queue (Prinzip des 2-Phase-Commit). Darüber hinaus verfügen die hochrangigen EAI-Werkzeuge über Schnittstellen zu System-Management-Suiten wie Tivoli oder Unicenter, um die Verfügbarkeit von Kernsystemen zu prüfen beziehungsweise auf