Um die Vor- oder Nachteile einer Web-Services-Architektur (WSA) im Vergleich zu einer Architektur abzuwägen, in der ein EAI-Werkzeug im Zentrum steht, ist das Einsatzspektrum der Integration zu klären. Dabei lassen sich unternehmensinterne und unternehmensübergreifende Integration unterscheiden. Im ersten Fall sind die hausinternen Anwendungen untereinander zu verbinden, um stets einen konsistenten Zustand über alle Applikationen zu erreichen.
EAI- und Web-Services-Architekturen gleichen sich - auf den ersten Blick.
Der Vorteil einer hausinternen Integrationsmaßnahme ergibt sich einerseits aus der kanalunabhängigen Korrektheit und Aktualität der Informationen. Andererseits entsteht durch die Abstraktion des Geschäftsprozesses von der Verarbeitungslogik in den Kernsystemen (beispielsweise ERP oder CRM) eine Art „Meta-Ebene der Geschäftslogik“. Änderungen an den Geschäftsprozessen, wie die Erweiterung um einen Kontrollschritt oder die Weitergabe eines Datums an ein zusätzliches System, lassen sich somit vergleichsweise einfach in den Prozess einfügen. Dabei sind keine Änderungen an den Kernsystemen erforderlich. Dies führt bei konstanter Infrastruktur zu erhöhter Flexibilität. Die schnelle Adaption an ein sich schnell änderndes Geschäftsumfeld wird möglich.
Unternehmensübergreifende Integration erstreckt sich entlang der Wertschöpfungskette mit Abnehmern und Zulieferern. Hier ist insbesondere durch den zunehmend dynamischeren Wechsel der Partner von variierenden Infrastrukturen auszugehen. Die Integration sollte also möglichst lose gekoppelt und flexibel sein. Für eine erfolgreiche unternehmensübergreifende Integration sind zunächst hausintern die Voraussetzungen zu schaffen. Nur wenn innerhalb des Unternehmens die Prozesse integriert sind und Informationen ohne Medienbrüche fließen, lassen sie sich auch gewinnbringend für externe Zwecke bereitstellen.
Die Architekturen für Web-Services und EAI unterscheiden sich auf den ersten Blick nicht wesentlich voneinander. Während in der WSA Kernsysteme ihre Dienste als Web-Services bereitstellen, beispielsweise via Web-Services-Wrapper (WSW), geschieht dies bei EAI über Adapter. Die Unterschiede liegen im Detail: Der Wrapper beschreibt seine Schnittstelle und die damit verfügbare Funktionalität über die Web Services Definition Language (WSDL) und stellt das Dokument in ein zentrales Repository (UDDI) oder Verzeichnis. Dieses dient einer Process Engine, die typischerweise in einem Web-Application-Server läuft, als Grundlage für die Modellierung der Geschäftsprozesse. Durch die Kombination mehrerer WSDLs mit Hilfe der Web Services Flow Language (WSFL) entsteht ein systemübergreifender Geschäftsprozess.
Web-Services-Wrapper noch in den Kinderschuhen
Die Aufgaben der Integration liegen in der Definition der Prozesse sowie der dazu benötigten Wrapper und WSDLs sowie deren Entwicklung. Derzeit arbeiten Hersteller von Standardsystemen wie SAP, Peoplesoft oder Oracle daran, entsprechende Web-Services-Wrapper für ihre Systeme bereitzustellen. Konkrete Implementierungen befinden sich derzeit jedoch noch im Anfangsstadium. Zudem sind die erforderlichen Enterprise Javabeans (EJBs) zur Bestimmung von Stati und das Mapping von Datenobjekten zu designen und zu entwickeln.
EAI-Werkzeuge verfügen für Standardsoftware wie SAP, Peoplesoft oder gängige Datenbanken über teils recht leistungsfähige Standardadapter. Diese entsprechen primär dem Web-Services-Wrapper: Sie machen die Leistung des Kernsystems nach außen verfügbar. Diese Funktionalität stellen EAI-Werkzeuge in einem zentralen Repository für die Prozessmodellierung zur Verfügung. Auch hier sind für proprietäre Anwendungen die Adapter eigens zu entwickeln, wobei sich die Aufwände durch die seitens der EAI-Hersteller zur Verfügung gestellten Entwicklungswerkzeuge erheblich reduzieren lassen.
Damit bestimmt der Standardisierungsgrad der Systemlandschaft den Integrationsaufwand. Die erforderlichen Data-Mappings lassen sich bei geeigneten Werkzeugen auf Basis einer grafischen Benutzeroberfläche definieren und verteilen. Je nach Reifegrad des EAI-Tools sind die Implementierungsaufwände an dieser Stelle wesentlich geringer als bei einer Web-Services-Architektur.
Ein anderer wesentlicher Unterschied zwischen beiden Architekturen besteht darin, dass die WSA nur Schnittstellen offen legt, das Mapping und die Prozessabwicklung jedoch auf dem Applikations-Server stattfinden. Geeignete EAI-Adapter hingegen können diese Aufgaben selbst übernehmen und reduzieren somit die Last des EAI-Servers. Aufgrund der guten Skalierbarkeit gängiger Applikations-Server stellt sich somit eher die Frage nach den versteckten Kosten einer WSA.
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
Ausfälle entsprechend reagieren zu können.
Um im Rahmen einer WSA eine 2-Phase-Commit-Fähigkeit zu erhalten, ist es erforderlich, die Web-Services mit den Diensten eines EJB-Containers abzuwickeln. Nur dann können sie Gebrauch von den Java Transaction Services (JTS) machen, die ein 2-Phase-Commit unterstützen. Eine Integration mit System-Management-Umgebungen wäre jedoch individuell zu implementieren, was ebenfalls mit hohen Aufwänden verbunden sein kann.
Einfaches Vehikel zur Dienstepublikation
Anders sieht es bei der Bereitstellung von Diensten in unternehmensübergreifenden Architekturen aus. Sind die Prozesse und Dienste erst einmal verfügbar, können Web-Services als einfaches Vehikel zur Publikation außerhalb der Unternehmensgrenzen dienen. Ob hausintern eine EAI- oder eine Web-Services-Architektur existiert, spielt dann keine Rolle mehr. Geeignete EAI-Werkzeuge erlauben die Bereitstellung der abgebildeten Prozesse als WSDL.
Einen Unterschied stellt aber der Zugang zu älteren Integrationskanälen wie beispielsweise EDI dar. EAI-Werkzeuge stammen aus dieser Welt und spre-chen diese Sprachen. Sie eignen sich also für eine schrittweise Migration. Einer reinen Web-Services-Architektur ist dagegen erst einmal die EDI-Fähigkeit mit entsprechendem Aufwand beizubringen.
Grundsätzlich stellt sich bei unternehmensübergreifender Integration auch die Frage nach Sicherheit wie Authentifizierung, Verschlüsselung und Abrechnung. Es ist davon auszugehen, dass Mitte bis Ende 2003 die einschlägigen Konsortien die derzeit noch ausstehenden Spezifikationen in diesem Bereich für eine umfassende Web-Services-Architektur bereitstellen werden.
Fazit
Web-Services gelten im Hinblick auf Lizenzen als eine kostengünstige Lösung zur Bereitstellung der Dienste eines Kernsystems. Die Kosten verlagern sich jedoch stark in die schlechter messbaren Bereiche Umsetzung und Skalierung. Die in Zukunft verfügbaren Spezifikationen zur Orchestrierung (WSFL) und Sicherheit sowie das Konzept der losen Kopplung lassen Web-Services mittelfristig als geeignete Basis für die dynamisch wechselnden Umgebungen im Bereich der unternehmensübergreifenden Integration erscheinen.
Im Bereich des stabilen Umfeldes einer hausinternen Integration mit detaillierten technischen Herausforderungen wie personalisierten Zugriffen oder Systemverfügbarkeiten bieten jedoch die in der Anschaffung etwas teureren EAI-Werkzeuge eine stabilere Basis und einen besser messbaren Return on Investment.
Um den richtigen Einsatzbereich für Web-Services zu identifizieren, sollten sich Entscheider daher zunächst mit Hilfe detaillierter fachlicher Analysen die wesentlichen Herausforderungen der hausinternen Integration aufzeigen lassen. Aus diesen Erkenntnissen lässt sich mit Hilfe spezialisierten Know-hows schnell eine Entscheidung pro oder contra eine Web-Services-Architektur fällen.