Grundzüge einer serviceorientierten Architektur
Dienste wagen
Die serviceorientierte Architektur (SOA) gehört zu den Themen, mit denen sich künftig auch der Netzwerker auseinander setzen muss. Schließlich ist er dafür verantwortlich, dass die zugrunde liegende Infrastruktur reibungslos funktioniert. Aus der auf den ersten Blick relativ abstrakt anmutenden Welt der SOA können Unternehmen dabei sogar recht schnell praktische Vorteile ziehen.
Eine der schwierigsten Aufgaben für Unternehmen bei der Flexibilisierung ihrer IT-Infrastruktur
besteht darin, die heterogene Anwendungslandschaft zusammen arbeiten zu lassen. Unter dem Label
Enterprise Application Integration (EAI) gibt es seit Jahren ein vielfältiges Angebot an
Middleware, die über Adapter und so genannte Integrations-Broker den Datenaustausch und die
Interaktion zwischen verschiedenen Applikationen bewerkstelligt. Doch dieser Ansatz stößt in
komplexen Umgebungen schnell an seine Grenzen. Der Grund: EAI löst die Integrationsaufgaben nur
punktuell, indem er die Verbindungen meist über proprietäre Schnittstellen schafft, sodass
implizite Abhängigkeiten entstehen und Änderungen teuer durchzuführen sind. Die Entwicklung der
Webservices hat eine neue Art der Integration möglich gemacht, die die Grenzen der proprietären
EAI-Lösungen und deren Point-to-Point- oder Hub-and-Spoke-Architektur mit einem zentralen
Messaging-Backbone überwinden soll.
Ganzheitliche Betrachtung
Das Konzept einer serviceorientieren Architektur (SOA) steht für eine ganzheitliche
Betrachtungsweise einer IT-Landschaft und der Betriebsabläufe. Anstatt Funktionen wie bisher von
einzelnen Anwendungen ausführen zu lassen, sollen Geschäftsfunktionen und Prozesse als Dienste
bereitstehen. Diese von Anwendungen und Plattformen unabhängigen Komponenten kapseln die komplexe
Anwendungslogik, sind technikneutral, lassen sich miteinander beliebig in einer standardisierten
Form kombinieren und wieder verwenden. Anstelle der früheren monolithischen Anwendungen entstehen
so genannte Composite Applications, deren Komponenten oder Services lose gekoppelt sind. Diese
werden während der Laufzeit dynamisch miteinander verbunden. Beispielsweise könnte jede Anwendung,
die Informationen zu einem Kunden benötigt, einen Dienst namens "Kunden-Lookup" in Anspruch nehmen.
Dabei ist es unerheblich, wo der Service im Netzwerk auf welcher Hardware und Plattform liegt oder
in welcher Programmiersprache er erstellt wurde.
Die Definition von Services ist dabei durchaus weit gefasst: Sie können monolithische
Anwendungen kapseln oder auch Adapter, Operationen wie etwa eine Funktion zur Berechnung von
Preisen oder einen ganzen Prozess ausführen, der Aufruf eines externen Webservices oder auch eine
ganze Geschäftseinheit sein, die an die unternehmensweiten Informationen angebunden werden
will.
Ein Dienst setzt sich aus mehreren Teilen zusammen: Eine Schnittstelle legt unter anderem fest,
wie der Service aufzurufen ist und wo er sich befindet. Die Serviceimplementierung wiederum besteht
aus dem eigentlichen Code, der beim Aufruf des Dienstes ausgeführt wird. Anders als die
Schnittstelle, die in einem neutralen Format definiert wird, ist die Serviceimplementierung
plattformabhängig. Der Dienst verhält sich den Angaben in der Schnittstelle gemäß.
Eine nahe liegende Technik für den Einsatz in einer SOA sind Webservices, dabei vor allem die
beiden Basisspezifikationen WSDL (Web Service Description Language) und SOAP (Simple Object Access
Protocol). WSDL, die auf XML beruhende Sprache, dient der Beschreibung einer Serviceschnittstelle,
und SOAP gilt als das bevorzugte Kommunikationsprotokoll.
Die Verbindung zwischen den Services und deren Interaktion mit bestehenden Systemen übernimmt
eine Integrationsschicht mit einer Kommunikationsinfrastruktur. Als eine zentrale Komponente einer
SOA fungiert der so genannte Enterprise Service Bus (ESB). Diese neue Middleware-Kategorie ist
nicht eindeutig definiert, doch gibt es einige Grundaufgaben, die ein solcher Bus erfüllen
muss.
Dazu gehören Messaging, Datentransformation sowie das inhaltsbezogene Routing von Nachrichten.
Er gilt als Bindeglied zwischen den Messaging-Generationen der proprietären MOM (Message Oriented
Middleware) und SOAP und sorgt für ein föderatives Netzwerk, das ein Raster von lose miteinander
verbundenen Integrationsdiensten und eventuell Messaging-Hubs bildet, zwischen denen es
wohldefinierte Übergänge gibt. Anwendungen können sich nach Bedarf an den Bus anschließen, mit
jeder anderen Applikation im Bus Verbindung aufnehmen und Daten austauschen.
Synchrone Kommunikation
Obwohl sich WSDL und SOAP an unterschiedliche Transportmechanismen binden lassen, eignen sich
die Webservices vor allem für eine synchrone Kommunikation über HTTP. Synchrones Messaging
bedeutet, dass ein Client (Requestor) eine Anfrage an einen Server (Producer) schickt und dann die
Antwort abwartet. Dies ist beispielsweise der Fall, wenn eine Dateneingabe durch den Benutzer
erfolgen soll. Erst wenn der Anfrager eine erfolgreiche Rückmeldung erhält, wird die nächste Aktion
angestoßen – in nicht verteilten Anwendungen die übliche Art der Abarbeitung der Schritte. In
Umgebungen jedoch, wo mehrere Anwendungen und Services parallel miteinander kommunizieren, bietet
das synchrone Modell Nachteile: In erster Linie müssen der Sender und Receiver gleichzeitig online
sein, damit Daten ausgetauscht werden. Kann eine solche Operation aus irgendeinem Grund nicht
erfolgreich abschließen, so werden alle weiteren involvierten Prozesse fehlschlagen. Dies bedeutet
aber, dass jede Anwendung, die eine synchrone Kommunikation nutzt, ein eigenes Error-Handling und
eigene Wiederherstellungslogik benötigt.
Asynchrone Nachrichtenübermittlung mit Store-and-Forward erfordert nicht das gleichzeitige
Online-Vorhandensein des Anfragers und Receivers. Daher stellt diese Art der Kommunikation ein
zwingend notwendiges Grundmuster in einer Architektur mit lose gekoppelten Schnittstellen und
verteilter Prozessbearbeitung dar. Dieses Messaging macht es möglich, dass jede Interaktion
zwischen zwei Prozessen eine selbstständige Arbeitseinheit mit eigenem Kontext und eigenen Daten
ist. Die beteiligten Anwendungen müssen dabei die Details der Aufrufe und Parameter untereinander
nicht kennen. Für die asynchrone Kommunikation ist Message Oriented Middleware (MOM) oder der Java
Messaging Service (JMS) erforderlich. Die neuen Versionen der Webservices-Standards SOAP 1.2 und
WSDL 2.0 unterstützen nun ebenfalls asynchrone Interaktionen. Doch können Webservices noch nicht
alle Funktionen einer MOM ersetzen.
Eine MOM sollte unterschiedliche – asynchrone und synchrone –
Nachrichtenübermittlungsmöglichkeiten und Mechanismen wie Publish-and-Subscribe und
Store-and-Forward liefern. Die einzelnen Teilschritte eines Geschäftsprozesses verlassen sich beim
Absenden einer Nachricht darauf, dass der ESB dafür sorgt, dass die Daten zuverlässig an den
Empfänger gelangen. Auch um die Antwort kümmert sich die Middleware. Details der
Nachrichtenübermittlung können Mechanismen wie Publish-and-Subscribe (ein Absender veröffentlicht
eine Nachricht, die mehrere Adressaten erhalten) oder Store-and-Forward (mehrere für die
Auslieferung der Nachricht). Daraus ergeben sich auch die Regeln für die Quality of Service für
eine Übermittlung von Nachrichten. Für eine zuverlässige Nachrichtenübermittlung gibt es
mittlerweile auch die Webservice-Spezifikation WS-ReliableMessaging, die entsprechende
Erweiterungen für SOAP beschreibt.
Der ESB muss flexibel genug sein, um verschiedene Verbindungstypen und Protokolle (HTTP, TCP/IP,
SOAP) zu unterstützen, also beispielsweise einen Webservice mit einer MOM-Anwendung interagieren zu
lassen. Im Rahmen eines unternehmensweiten Messaging-Backbones sollte die Software sowohl
Webservice-Standards wie WS-Reliability und WS-Reliable Messaging, J2EE-Komponenten wie JMS (Java
Message Service) unterstützen als auch eine proprietäre Message-orientierte Middleware und die J2EE
Connector Architecture (JCA) für die Verbindung zu Anwendungsadaptern ohne
Webservices-Schnittstellen. Ebenfalls aus dem Java-Lager kommt die Java Business Integration (JBI),
die beschreibt, wie Integrationskomponenten verschiedener ESBs miteinander interagieren können.
Datentransformation und XML-Services gehören ebenfalls zur Grundausstattung eines ESBs, denn die
verschiedenen, mit dem Bus verbundenen Komponenten erwarten unterschiedliche Datenformate. Einer
der Vorteile der Middleware besteht eben darin, dass die Services keine Implementierungsdetails
voneinander kennen müssen, um zu interagieren. Für den Nachrichtenaustausch können XML-Services
eingesetzt werden, die über ein XSLT-Stylesheet eine eingehende XML-Nachricht aus einem Dialekt der
Markup-Sprache in einen anderen umzuwandeln.
Schließlich definiert sich ein ESB über die Fähigkeit, intelligentes Routing vorzunehmen. Um
Business-Dienste zu definieren, die aus verschiedenen Komponenten auf dem Bus bestehen, muss er in
der Lage sein, den Ablauf von einem Dienst zum nächsten zu bestimmen und bei Bedarf dynamisch den
Pfad zu ändern. Als Beispiel kann etwa ein Prozessschritt wie "validate" (identifiziert ein
XML-Dokument als das gesuchte) auf der Basis der darin enthaltenen Regeln die Daten
Content-basierend weiterleiten.
Repository und Registry
Zum Konzept einer SOA gehört auch ein Repository oder eine Registry als zentrales Verzeichnis
für alle verfügbaren Dienste. Mit UDDI (Universal Description, Discovery and Integration) existiert
bereits seit Jahren ein Standard für Webservices. Doch setzen in der Praxis nur wenige Unternehmen
diesen Verzeichnisdienst ein, stellten die Marktforscher von Berlecon Research fest. Stattdessen
nutzen die meisten selbst entwickelte Repositories. Die Grundfunktion des zentralen Verzeichnisses
besteht in der Veröffentlichung von verfügbaren Diensten. Neben der Schnittstellenbeschreibung
können hier zusätzliche Daten zur Version oder etwa SLAs hinterlegt werden. Nutzer erhalten auch
die Möglichkeit, nach Services zu suchen, etwa um festzustellen, welche Basisdienste bereits
vorhanden sind, wenn neue Funktionalität implementiert werden soll.
Viele ESB-Produkte halten die Anwendungen in so genannten Containern vor. Dies sind entweder
leichtgewichtige "Plain old Java Object"-Container (POJO) oder J2EE-"Behälter", die einen
Anwendungs-Server oder auch lediglich einen "Lookup"-Dienst beherbergen.
Methoden der Orchestrierung
Fast jede SOA-Plattform liefert zusätzlich zur "Grundausstattung" Methoden für die so genannte
Orchestrierung der Dienste. Dabei geht es darum, die Teilschritte eines Ablaufs zu einem
Geschäftsprozess zusammenzusetzen. Diese Aufgabe obliegt normalerweise einem Tool für das Business
Process Management, doch kann dies ein Service ebenfalls tun. Die Grundlage dafür ist ein Modell
des Ablaufs des Geschäftsprozesses, das mithilfe der Spezifikation Business Process Execution
Language (BPEL) erstellt wurde. Für einen Vorgang, der beispielsweise abhängig von einer
Interaktion eines Benutzers – etwa die Bewilligung eines Bestellauftrags – weitergeleitet wird, ist
ein Mechanismus wichtig, der den Prozessablauf automatisch bis zur erfolgten Aktion unterbricht und
dann den Nachrichtenfluss nach diesem Event wieder aufnimmt. Diesen zustandsbehafteten Mechanismus
kann ein solcher Orchestrierungsservice liefern. Mit dem Vorhandensein eines
Orchestrierungsservices kommt eine serviceorientierte Architektur der Vision von dynamisch
zusammenzustellenden Anwendungen näher.
Es ist schwierig, den zurzeit heiß umkämpften Markt für SOA-Produkte zu kategorisieren. Die
Burton Group beispielsweise unterscheidet zwischen mehreren Architekturtypen, mit deren Hilfe
ESB-Produkte die Zusammenarbeit von Protokollen bewerkstelligt. Zum einen gibt es eine Reihe von
Anbietern, die ihre Software rund um die bereits vorhandene MOM bauen. Dazu gehören traditionelle
EAI-Anbieter wie Tibco, IBM, BEA oder Sonic. Diese Hersteller bieten einen proprietären
Messaging-Backbone, der SOAP-Schnittstellen nativ unterstützt. SOAP-Nachrichten werden über HTTP
oder MOM-Protokolle übermittelt, und jede SOAP-fähige Umgebung hat Zugriff auf Anwendungen mit
einer Webservice-Schnittstelle. Dieser ESB-Typus wird auf mehreren Knoten in einer SOA
implementiert. Ähnlich den Integrations-Brokern gibt es einen oder mehrere zentrale Konten für die
Koordination oder die Knoten bilden ein föderatives Netzwerk.
Ein weiterer Architekturtypus beruht auf dem Protokoll-Switching über eine so genannte Message
Processing Engine und einem Set von Plug-in-Protokolltreibern. Die Engine wählt aufgrund der
Binding-Information in der WSDL-Datei einer Nachricht den jeweils geeigneten Treiber dafür. Zurzeit
ist lediglich das HTTP-Binding für SOAP standardisiert worden, doch der Protokoll-Switch kapselt
alle anderen Protokolle. Die bekanntesten Anbieter dieser ESB-Art sind Microsoft und Iona.
Schließlich spricht die Burton Group von der Gateway-Architektur, in der die Zusammenarbeit der
Protokolle über einen Übersetzer und Vermittler zwischen SOAP und speziellen MOM-Protokollen
fungiert. Vorhandene MOM-Queues werden gekapselt und als Webservice veröffentlicht. Blue Titan und
Systinet gehören zu den Anbietern dieses Vermittlertypus.
Flexible Geschäftsprozesse als Entwicklungsziel
Über den potenziellen Nutzen infolge der Einführung einer SOA herrscht weitgehend Einigkeit: Sie
soll zu flexiblen Geschäftsprozessen führen, die sich einfacher an neue Anforderungen anpassen
lassen, und der Aufwand für die Pflege von gewachsenen IT-Landschaften soll geringer sein. Doch die
Analysten der Burton Group warnen: Kein ESB-Produkt stellt eine Einzellösung für alle
Integrationsanforderungen eines Unternehmens dar – ironischerweise kann es notwendig sein, einen
ESB zu implementieren, um die bereits vorhandenen Busse ineinander zu integrieren.
Lesen Sie mehr zum Thema
