Transparenz für SOA SOA: Enterprise Service Bus steuert Services

Die Forderungen nach Flexibilität und Agilität haben die IT an ihre Grenzen geführt: monolithische Systeme sind für die neuen Anforderungen zu starr, ihre Alternativen zu komplex. Mit SOA setzt sich nun eine neue, ge-schäftsorientierte Sichtweise durch. Der Enterprise Ser-vice Bus sorgt dabei für eine transparente Infrastruktur.

Anbieter zum Thema

Rittal GmbH & Co. KG

Schneider Electric GmbH

EPS Rechenzentrum Infrastruktur GmbH

Verstärkte internationale Aktivitäten, Unternehmenszusam-menschlüsse und Ausgründungen, neue Geschäftsmodelle, neue Kostenstrukturen, neue Organisationsformen, neue Technologien: um das nicht nur abzubilden, sondern auch noch aktiv voranzutreiben, muss die IT flexibel und agil sein.

Seit etwa drei Jahren zeichnet sich ein ganz neues Software-Konzept ab. Die Service-orientierte Architektur (SOA) betrachtet die Geschäftsprozesse nicht von der IT-Seite aus, sondern blickt in umgekehrte Richtung. Sie löst Software in funktionelle Services auf, in gekapselte Komponenten, die sich aber nicht an technischen Aspekten, sondern an den Geschäftsprozessen orientieren. Solche Services lassen sich flexibel in Prozesse einbinden und sie sind auf Grund durchgängiger Standardisierung weder an räumliche noch an Unternehmensgrenzen gebunden.

Unternehmen können mit SOA schnell auf neue Anforderun-gen reagieren. Sie sind in der Lage, Services sofort umzu-strukturieren und sie eventuell zu ergänzen, aber im We-sentlichen können sie die bestehenden Funktionalitäten wieder verwenden. Anders als bei frühren Ansätzen der Wiederverwendbarkeit steht nicht der Kostenaspekt im Vor-dergrund, sondern die damit erreichbare Agilität.

Da Services nach außen über definierte Schnittstellen kom-munizieren, wirken sich Änderungen in der Software nur ein einem geschützten Bereich aus. Schlimmstenfalls steht der Service nicht mehr zur Verfügung, andere Service laufen weiter. In einem monolithischen System dagegen kann die geringste Änderung zu unabsehbaren Folgen führen.

Servicegedanke ohne Grenzen

Die SOA bringt in dieses Grundkonzept einige spezifische Leistungen ein:

• Sie basiert auf den Standards der Web-Technologie, auf WSDL, UDDI und SOAP. Damit bietet SOA weltweite Intero-perabilität – zwei Unternehmen können auf dieser Basis ihre Anwendungssysteme mit erheblich weniger Aufwand verlin-ken, etwa im Rahmen einer unternehmensübergreifenden Supply-Chain.
• Die Services sind nur lose über ihre Schnittstellen gekoppelt, sie lassen sich also bei Bedarf in neuen Kontext neu arran-gieren; damit wird ein ganz neues Niveau an Flexibilität erreicht.
• Die Services können auch von Dritten, zum Beispiel von Geschäftspartnern, genutzt werden, so dass sie als Hebel der Integration wirken.
• Im Rahmen der SOA lassen sich auch vorhandene Systeme einbinden, so dass bestehende Algorithmen, etwa aus Legacy-Systemen, weiter genutzt werden können. Damit kön-nen die Investition in die monolithische Welt zumindest teil-weise erhalten werden.

Prozesse maßgeschneidert definieren

Ausgehend von den Geschäftsprozessen lässt sich die Granularität definieren, je nach Vorgang können sie grob- oder feinkörnig strukturiert sein. Services sollten mehr sein als rein technische Komponenten, wie sie etwa im CORBA-Umfeld üblich waren. Sie beinhalten also nicht nur einen Druckeraufruf und eine Datenbank-Anfrage, sondern können bei Bedarf einen kompletten Geschäftsprozess umfassen, zum Beispiel eine SCHUFA-Abfrage.

Dabei ist es eine ziemlich akademische Frage, ob so eine SCHUFA-Abfrage ihrerseits überhaupt ein Geschäftsprozess ist oder nur Teil eines Prozesses namens Kreditgewährung. Services können eben Prozesse und/oder Sub-Prozesse umfassen. Das besondere bei SOA ist, dass sich eine derar-tige Abfrage auch in einen anderen Kontext stellen lässt und dass ihre Algorithmen innerhalb der bestehenden Prozesse neu definiert werden können, ohne die gesamte Prozessket-te zu stören. Die Änderung des Service endet genau an seiner Schnittstelle.

ESB schafft Transparenz

Dennoch, auch wenn einzelne Geschäftsprozesse als Services dargestellt werden, wird ein Unternehmen, das seine Software auf Basis der SOA organisiert, schnell ein paar tausend Services ansammeln. Soll die bessere Ausrichtung auf wirtschaftliche Anforderungen nicht erneut in einer aus-ufernden Komplexität untergehen, benötigen die Services eine Infrastruktur, die ihre Kommunikation regelt und über-wacht. Diese Infrastruktur stellt der Enterprise Service Bus (ESB) zur Verfügung. Er bietet ein Medium, einen dyna-misch konfigurierten Nervenstrang über das die Services jene inhaltliche und statusbezogene Informationen austau-schen, die sie überhaupt erst befähigen, ihre jeweiligen Funktionen auszuüben.

ESB stellt den Service an den richtigen Platz, passt auf dass er dort bleibt und was er macht. Dabei erstreckt sich der ESB über Cluster und Sicherheitsinfrastrukturen hinweg und bildet eine verteilte Umgebung, die an jedem Punkt verwaltet werden kann. Anders ausgedrückt: ESB macht SOA transparent.

Leistungen der Infrastruktur

Die Services werden über den ESB flexibel und dynamisch verbunden, Verbindungen müssen nicht programmiert wer-den. Diese Verbindungen erfolgen im Wesentlichen asyn-chron auf Basis des Messaging-Konzepts. Der ESB, wie er erstmals von Sonic realisiert wurde, besteht seinerseits aus verschiedenen Komponenten. Sie sorgen zum einen für die Verbindung zwischen Infrastruktur und Services Zum ande-res verfügt der ESB über eigene Services, die das Manage-ment der Infrastruktur übernehmen und die Kommunikation der Services steuern und kontrollieren.

Dazu gehören unter anderem folgende Leistungen:

• Servicekommunikation: Über eine robuste und skalierbare Datenübertragung werden Services unterschiedlicher Her-kunft und Technologie, also beispielsweise ERP-Systeme, Web-Services, J2EE-; .NET oder Legacy-Applikationen im gesamten Unternehmen verbunden.
• Servicevermittlung: Durch den Abgleich zwischen nicht kompatiblen Protokollen, Datenformaten und Interaktions-mustern wird eine flexible Kombination verbundener Services erleichert. Das konfigurationsgesteuerte Design beseitigt unflexible, hart-kodierte Serviceabhängigkeiten, so dass Änderungen ohne Unterbrechung des Betriebs dynamisch vorgenommen werden können.
• Serviceorchestrierung: Die Modellierung von Prozessen und die Automatisierung von langfristigen, zustandsabhängigen Transaktionen sowie komplexen Datenflüssen ermöglicht ein umfassendes Management von Geschäftsprozessen. Menschliche Arbeitsprozesse sowie alle mit dem ESB ver-bundenen IT-Ressourcen werden zu einem koordinierten und geregelten Geschäftsprozess zusammengefasst.
• Serviceinstallation und -administration: Die verteilte Infra-struktur macht einen zentralen Hub überflüssig, dennoch erfolgen Installation, Administration und Überwachung zentral. Die Services können unabhängig voneinander skaliert, konfiguriert und installiert werden.
• Operative Datenservices: Die Benutzer können alle aktuellen Betriebsdaten kontrollieren, auswerten und in gängigen Formaten wie XML weiterverarbeiten. Damit sind auch eine umfassende Dokumentation und ein lückenloses Auditing sichergestellt.

Beispiel Finanzhandel

In der Praxis könnte die Steuerung von Services über einen ESB folgendermaßen aussehen, beispielsweise für die Integration und Mediation eines Multi-Channel-Prozesses im Finanzhandel: Dabei werden bestehende Systeme, die mit einer Services-Schnittstelle versehen wurden und neu entwickelte Dienste verbunden. Das Beispiel verdeutlicht, wie die Datenelemente eines Auftrags im Wertehandel aus einem Order Management Service so umgewandelt werden, dass sie den Anforderungen des Trading- und Compliance-Services entsprechen.

Im weiteren Prozessablauf wird ein Trigger für einen Geld-transfer vom Funds-Transfer-Service angestoßen und der Auftrag schließlich als ausgeführte Transaktion im Logging Service abgelegt. Der Trade-Prozess wird nicht als integrierte Anwendung ausgeführt, sondern als eine Sequenz von heterogenen Prozessschritten, die von der SOA-Infrastruktur koordiniert werden (vgl. Abbildung 1).

Der ESB ist dabei für die Kommunikation und das Routing zwischen den Diensten über ihre Schnittstellen verantwort-lich; er regelt die Abfolge der Services und steuert damit den gesamten Geschäftsprozess. Dem Grundgedanken von SOA zufolge kann man einen einzelnen Service, hier bei-spielsweise den Trading-Service oder die XML-Transformation auch in einem völlig anderen Kontext nutzen oder umgekehrt einen neuen Service, zum Beispiel die Kommunikation mit einem Management-Informationen-System, einschleusen. Über die Orchestrierung würde dann festgelegt wie und wann dieser Service zum Einsatz kommt.

Der Nutzen einer derartigen Infrastruktur liegt auf der Hand: in einem monolithischen System ließe sich eine solche Än-derung nur mit erheblichem Aufwand realisieren. Natürlich ist auch für den Aufbau einer SOA samt ESB-Infrastruktur einiger Aufwand erforderlich, hat man die Klippe des Ein-stiegs in die neue Welt einmal hinter sich, so kann man vor einer bisher nicht gekannten Flexibilität profitieren.

*Oliver Vermeer ist Field Services Manager DACH bei Progress Software GmbH

(ID:2005074)