Um eine SOA-Strategie zu realisieren, ersetzen Unternehmen nicht einfach ihre bestehende Infrastruktur. Aus Kostengründen und mit Blick auf die Komplexität der Applikationen werden bestehende Programme als Services zur Verfügung gestellt. Damit lassen sie sich auch für andere Geschäftsprozesse und Anwendungen verwenden. Deswegen ist das Herz jeder SOA ein Integrations-Layer, der dynamische Interaktionen zwischen Services in einer heterogenen Umgebung unterstützt.

Dieser Layer muss Veränderungen in der IT bewältigen, die beispielsweise erforderlich sind, wenn das Geschäft wächst und neue Kunden und Partner angesprochen werden sollen. Dazu unterstützt er die Weiterentwicklung bestehender und die schnelle Ergänzung neuer Services. Gleichzeitig ist es erforderlich, die Servicenutzer von Änderungen an den Serviceendpunkten abzuschirmen. Der Integrations-Layer ist deshalb so ausgelegt, dass Interaktionen zwischen den Services nicht mehr von den Endpunkten selbst aus verwaltet werden müssen. Ein solcher Layer wird Enterprise Service Bus (ESB) genannt.

Kernfunktionen

ESBs bieten folgende Schüsselfunktionen: eine Registry für Publishing, Versionsverwaltung von Services und Message Brokering, ferner dynamisches Routing und Transformation zwischen Services. Darüber hinaus unterstützen ESBs die Message- und Transportsicherheit. Als verteilte Übermittler ermöglichen sie die Umsetzung der Policies, die mit Routing-Regeln, Transformationen, Sicherheit und Zugang verbunden sind.

Wie lässt sich ein ESB mit anderen Infrastruktur-Integrations-Layern vergleichen? Web-Services fügen einer IT-Architektur einen Abstraktions-Layer hinzu. Um einen einfachen und verständlichen Zugang zu den Applikationen zu ermöglichen, verwenden sie offene Standards. Trotzdem sind Web-Services allein für allgemeine Integrationsprojekte nicht ausreichend. Ihren Standards fehlt es an Spezifikationen für das Reliability- und Security-Management. Sie bieten auch nicht die umfassende Koordination und das Prozess-Management, die erforderlich sind, um zwischen den Anfragen der Servicenutzer und den Ressourcen der Servicehersteller zu vermitteln.

Application Platform Suites (APS) haben ähnliche Nachteile. Sie sind in einem verteilten Netz mit verschiedenen Servern schwierig zu implementieren oder zu rekonfigurieren. Eine APS bietet Sichtbarkeit und Management für Geschäftsprozesse, die auf einem einzigen Server oder einem Cluster von Servern laufen. Sie können aber keinen umfassenden Überblick verschaffen oder Prozesse verwalten, die auf Systemen in einer heterogenen Umgebung laufen. Deswegen sind Architekturen wie Microsofts .NET oder EJB Container (EJB = Enterprise Javabeans) kaum dafür geeignet, eine größere Zahl von dynamisch konfigurierten Services in einer SOA zu verwalten.

Im Gegensatz zu APS ermöglichen ESB-Service-Container den selektiven Einsatz von Vermittlungsservices genau zu dem Zeitpunkt und an dem Ort, an dem sie gebraucht werden. Dagegen müssen Unternehmen überall dort einen kompletten Applikations-Server-Stack installieren, wo individuelle Integrationsfunktionen erforderlich sind. Das führt zu unnötigen Mehrkosten für die Lizenzierung, die Installation und den Betrieb während der gesamten Laufzeit.

Traditionelle EAI-Produkte wurden speziell für die Anwendungsintegration entwickelt. Sie leisten ein Mapping von Applikation zu Applikation in einem Hub-and-Spoke-Modell. Das konzentriert sehr viel Komplexität auf einem einzigen Integrationspunkt. In der Entwicklung ist es teuer und unpraktikabel, ein Projekt mit IT-Experten zu besetzen, die sowohl fundierte Kenntnisse des EAI-Produkts als auch der semantischen Details aller zu integrierenden Applikationen besitzen. Die Skalierung, sprich Erweiterung der zentralisierten Hub-and-Spoke-Architektur eines EAI-Produkts, erfordert erheblich mehr Rechenressourcen.

Agile IT-Infrastruktur

Obwohl heute viele Infrastrukturlösungen als ESBs beschrieben werden, erfüllen nicht alle die Anforderungen für die Serviceintegration in heterogenen IT-Umgebungen. ESBs müssen Interaktionen zwischen Services ermöglichen, die auf unterschiedlichsten Applikationsplattformen wie beispielsweise Legacy-Stacks, .NET oder J2EE laufen. In einer SOA sind die Services wie Konsumenten angelegt, die auf die Werte anderer Services zugreifen und diese nutzen. Der ESB muss die Servicekonsumenten und -Provider von der Komplexität, die sich aus den Unterschieden der implementierten Transportprotokolle und Message-Formate ergibt, abschirmen. Er ist darauf ausgelegt, die Schwierigkeiten zwischen der "Sprache" des einen Service und der eines anderen zu beseitigen. Ein ESB ermöglicht dynamische Transformationen zwischen verschiedenen Service-Endpunkten unter Verwendung interoperabler Standards wie XQuery.

Verwaltbarkeit ist Bedingung

Wenn Services mit einem intelligenten Vermittler verbunden sind und Routing und Transformation für die Unterstützung von heterogenen Serviceinteraktionen eingesetzt werden, muss die IT die Verfügbarkeit dieser Interaktionen kontrollieren können. Nur so lässt sich die Zuverlässigkeit gewährleisten, die bei heutigen Geschäftstransaktionen erwartet wird. Eine intelligente, verwaltbare Infrastruktur als Teil eines einzigen zusammengefassten Layers erlaubt es, alle registrierten Services zu verwalten. Messages werden erfasst, die Performance wird überwacht. Zudem können Service- Level-Agreements (SLAs) getroffen werden, um die Qualität der Dienste zu gewährleisten.

Alles verbinden

Langfristig werden solche Serviceinfrastruktur-Lösungen erfolgreich sein, deren Funktionen sowohl aus der Sicht der Entwickler als auch der des Managements integriert sind. Gleichzeitig müssen sie offen und mit Hilfe von etablierten Standards, Protokollen und Schnittstellen erweiterbar sein. Den Kern dieser Implementierungen wird ein vereinheitlichtes Metadata Repository bilden, das alle Fähigkeiten der Infrastruktur untermauert. (wh)