SOA I: Serviceorientierte Architektur - The Buzzword strikes again

SOA ist ein Paradigma

SOA sollte man nicht als fest definierten Begriff sondern als Paradigma sehen. Das Paradigma umschreibt, wie Dienste / Prozesse einer Organisation informationstechnisch strukturiert und genutzt werden. Die Prozesse besitzen unterschiedliche Wertigkeiten und bestehen in der niedrigsten Ebene aus einem Dienst, höhere Dienste bestehen aus n Diensten. Die Kunst besteht also darin, die höheren Diensten mit den benötigten unteren Diensten zu kombinieren.
Beispiel: Die Bäckerei Bernd Brot GmbH soll ein Hotel beliefern. Die Liefermenge wird allabendlich durch das Hotel in Auftrag gegeben. Das Anlegen des Hotel als Kunde wäre ein Prozess. Die abendliche Auftragsannahme besteht stark vereinfacht aus zwei Prozessen:

1. Heraussuchen des Kunden
2. Lieferauftrag erfassen

Jeder dieser Prozesse steht nun in der Architektur der Bernd Brot GmbH als Service bereit. Die SOA kümmert sich nun um die entsprechende Orchestrierung der Services. Dies beinhaltet die Zusammenführung und Bereitstellung der einzelnen Services zu höheren Aufgaben mit dem entsprechenden Workflow.
Die Diversifizierung in mehrere Services kann es nun ermöglichen, Geschäftsprozesse agil zu ändern. Da die Services autark, änderbar, lose und fachlich orientiert sind, können evtl. Änderungen am Service punktgenau vorgenommen werden. Strukturelle Änderungen im oder am Unternehmen können durch eine neue Orchestrierung vorgenommen werden.

SOA ist Kommunikation

Die Services zeichnen sich dadurch aus, dass sie über öffentliche Schnittstellen aufgerufen werden. Öffentlich heißt, dass die Schnittstellen in einem definertem Rahmen (Intranet, Internet) frei zugänglich sind. Services werden niemals in Applikationen eingebettet sondern aufgerufen und besitzen dadurch ein deutliches Unterscheidungsmerkmal gegenüber Bibliotheken oder Komponenten.
In unserem Beispiel könnte die Bäckerei z.B. soweit gehen, dass sie dem Hotel einen Service "Wo bleibt meine Bestellung" bereitstellt. Wie der Service aufgerufen wird, bleibt nun dem Hotel überlassen. Der Aufruf des Service kann z.B. aus einer Webapplikation, einer typischen Desktop-Anwendung oder auch aus Excel heraus erfolgen. Deutlich wird hier auf jeden Fall ein großer Vorteil einer SOA. Es bietet eine definierte Möglichkeit der Kommunikation im B2B-Bereich.
Da man durch die freie Zugänglichkeit nicht unbedingt den oder die Konsumenten kennt, ist eine genaue Spezifikation und Dokumentation des Service unumgänglich. Dem Konsumenten ist letzlich nur bekannt, dass dieser Dienst existiert und angeboten wird. Die Logik und Vorgehensweise innerhalb des Service ist für ihn völlig transparent.

SOA ist Technologie

Aus technischer Sicht sind die Services als Webservice benamt. Ein Webservice ist durch eine URI eindeutig identifizierbar, die Schnittstellen sind als XML-Artefakte definiert und beschrieben. Die Interaktion mit Applikationen die den Webservice konsumieren wollen, erfolgt mit XML-basierten Nachrichten über internetbasierte Protokolle. Eine Beschränkung auf HTTP(s) gibt es somit nicht.
Bei einer Interaktion lassen sich drei Instanzen identifizieren:

• Client
• Server
• Verzeichnis

Im Verzeichnis veröffentlicht der Server die Beschreibung seiner Dienste. Der Client durchsucht das Verzeichnis und greift auf den gewünschten Dienst zu. Nach Austausch weiterer eventueller Protokolldetails, ist der Client an den Server angebunden und der Zugriff auf die gewünschte Methode wird möglich.
Diesem Prozess liegen folgende (XML basierte) Standards zu Grunde:

• UDDI als Verzeichnisdienst zur Registrierung von Webservices. Er ermöglicht das Auffinden des Web Services durch den Client
• WSDL zur Beschreibung der unterstützen Methoden und deren Parameter für den Programmierer
• SOAP oder XML-RPC zur Kommunikation

Was ist SOAP?

SOAP wurde als Protokoll zum Austausch zwischen heterogenen Systemen entwickelt. XML wird zur Repräsentation der Daten verwendet, zum Versand internetbasierte Protokolle.

Wie funktioniert SOAP?

Will der Client eine entfernte Methode aufrufen, wird dieser Aufruf clientseitig in einen sogenannten SOAP-Envelope verpackt. Dieser "Umschlag" enthält optional einen Header mit Metainformationen und einen Body, der die eigentlichen Nutzdaten enthält. In diesem Beispiel also den Methodenaufruf.
Der Client versendet nun diesen Umschlag an den Server, der die Nachricht entgegennimmt, parst und die Anfrage an die entsprechende Methode weiterleitet. Diese produziert die Ausgabe, verpackt sie wiederum in einen Umschlag und der Versand vom Server zum Client findet statt.

Wenn Beispielsweise unser Hotel bei der Bäckerei den Status ihrer Bestellung über den ihr zugänglichen Service "BakeryService" mit der Operation "whereIsMyOrder" abfragt, könnte der Response des Service wie folgt aussehen:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:whereIsMyOrderResponse";charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 18 Jul 2008 20:22:30 GMT

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns2:whereIsMyOrderResponse xmlns:ns2="http://bakery">
<ns2:return>
<ns1:statusId xmlns:ns1="http://bean.bakery/xsd">
123</ns1:statusId>
<ns1:statusText xmlns:ns1="http://bean.bakery/xsd">
Your order is on the way</ns1:statusText>
</ns2:return>
</ns2:whereIsMyOrderResponse>
</soapenv:Body>
</soapenv:Envelope>


Weitere Links

Serviceorientierte Architektur – Wikipedia
CIO Online: SOA
SAP Deutschland - Service-Oriented Architecture - Überblick
TecChannel.de: In zehn Schritten zur SOA
InformationWeek: SOA