In meinem letzten Beitrag zu SOA habe ich erörtert was eine serviceorientierte Architektur dem Management verspricht. Noch einmal auf die Essenz gebracht, sind hier folgende Punkte aufzuführen:

  1. Prozesse sind an die sich schnell veränderbaren Anforderungen des Marktes anpassbar
  2. Die Komponenten einer Anwendung sind durch Austausch und Kombination von Services leicht modifizierbar
  3. Neue Produkte können schneller an den Markt gebracht werden (Time-to-Market)
  4. Einfachere Konsolidierung von Unternehmen durch Services (M&As)

In diesem zweiten von drei Beiträgen möchte ich die generelle Architektur einer SOA aufzeigen, wie diese Ziele umgesetzt werden könnten. Dabei möchte ich mich bewußt abstrakt halten, im dritten Teil der Beitragsserie werde ich dann konkreter bzgl. eingesetzter Techniken, kommerzielle Produkte und OpenSource-Lösungen.

Nun, was ist eine SOA? Ist es wirklich eine Archtiektur? Gibt es eine einheitliche Vorstellung davon, was eine SOA sei? Wenn ja, wer definiert diese? Oder ist es nur alter Wein in neuen Schläuchen, damit die Großen die nächste Version ihrer Plattformen erfolgsversprechend verkaufen? Ob ich mich mit den IT-Spezialisten in meiner unmittelbaren Umgebung unterhalte oder im Internet danach suche, ein wirklicher Konsens ist nicht so einfach zu finden. Was im übrigen wieder einmal mein “subjektives-konstruktivistisches” Weltbild bestätigt. Als Organisation und Referenzquelle was SOA sein soll, habe ich natürlich die OASIS gefunden, welche am SOA-Refrenzmodell arbeitet. Man kann hier keinesfalls eine Stringenz feststellen, wie man dies beispielsweise bei dem J2EE-Standard und einer J2EE-konformen Implementierung eines Applikationsservers kennt. Trotzdem haben die Hersteller schon alle ihre neuen (“fertigen”?) Plattformen am Markt, obwohl das Papier der OASIS noch sehr “draftig” aussieht (immerhin schon in der Version 2.0 mit einem Umfang von ca. 33 Seiten) :-) Man kann also sagen, das Ganze ist “offener und abstrakter”. Daher lässt sich auch nicht so einfach sagen was eine SOA ist. Interessant fand ich auch die Seite http://www.orechestrationpatterns.com zum Begriff der Orchestrierung im SOA-Kontext. Auf den Begriff der Orchestrierung möchte ich später noch näher eingehen. Die Autoren der Seite versuchen die ersten SOA-Patterns zu finden, z. B. für eine Service-Defintion , Service-Implementierung und die Service-Versionierung. Unter SOA-Orchestrieungspatterns darf man sich allerdings nicht Patterns im Sinne von GoF-Patterns oder J2EE-Patterns vorstellen. Das “Ganze” bewegt sich eher auf abstraktem Niveau, obwohl die Patterns in ihrem Abstraktionsgrad konkreter werden als etwa die meisten SOA-Definitionen. Unter http://www.orechestrationpatterns.com findet man nicht nur SOA-Patterns, sondern auch einen Versuch einer SOA-Definition. Die Autoren schreiben hierzu:

Many people talk about it, yet there is little agreement of what this widely popular three letter acronym actually represents.
The many competing definitions in place make it hard to sort out its true essence.
SearchWebServices.com announced a contest for the best definition.

Dies kann ich nun endlos fortführen und ich könnte jetzt stundenlang durch das Internet streifen… Deshalb gebe ich hier meine Suche nach SOA-Definitonen auf. Dieser Beitrag beschreibt deshalb meine Konstruktion von SOA und ist nicht als eine weitere SOA-Definition zu verstehen.

Prozesse und Services

Die Anpassbarkeit des Unternehmens durch die Anpassbarkeit der IT soll durch eine Serviceorientierung auf Prozessebene stattfinGoogle WSDLden. Genau hier könnte man sagen das SOA alter Wein in neuen Schläuchen sei, wie dies auch oft geäußert wird. Da alte Konzepte wie funktionalorientierte Programmiersprachen, Modularisierung, Objektorientierung und das Konzept der losen Kopplung bereits die Wiederverwendbarkeit von Softwarekomponenten erhöht und die Aufwände für die Wartung reduziert. Einen entscheidenden Unterschied gibt es hier jedoch zu den alten Konzepten. Die servieorientierte Architektur orientiert sich an den Businessprozessen in Form von Services. Services stellen Kommunikationsendpunkte, Fragmente, Teilfunktionen von Prozessen dar. Damit ist man näher an der Sache, die SAP so erfolgreich gemacht hat, nämlich die Businessorientierung. Aus meiner Sicht ist das auch eine der hauptsächlichen Herausforderung des Designs einer SOA: Die Bestimmung der Granularität der Services und wie die Services miteinander kommunizieren, um einen Prozess darzustellen. So würde ich mich z.B. sehr wundern, wenn ich eine Funktion getBytes() in einem Service finden würde. Hier erwarte ich vielmehr Funktionen der Art doGoogleSearch(). Einen solchen Aufruf bietet Google bereits anProzesse und Services unter http://www.google.com/apis/.

Ein solcher Aufruf könnte jetzt aus einem Service innerhalb einer Prozesskette diesen Google-Service aufrufen. Nebenstehende Grafik soll dies veranschaulichen. So sind Service-Endpoints mit anderen Service-Endpoints innerhalb des Prozesses oder mit Service-Endpoints außerhalb des eigentlichen Prozesses verbunden.

Service Repository

Das Service Repository stellt einen Dienst dar, ähnlich einen Namensdienst, der die jeweiligen Services eines Anbieters transparent nach außen beschreibt. Geschäftspartner können auf dieses Repository zugreifen, die entsprechenden “Services” heraussuchen und verwenden. Ein solcher Namensdienst wird i.d.R. durch den Standard Universal Description, Discovery and Integration (UDDI) bereitgestellt. Ein UDDI-Server gibt dann die Beschreibung für einen Service heraus, in Form der Web Service Description Language (WSDL).

Orchestrierung

Die Orchestration-Engine bietet die Möglichkeit “Prozesse zu assemblieren”. Einfach gesagt, werden hier Services und deren Ablaufreihenfolge miteinander verdrahtet. Dies sollte mit einem bequemen Modeller möglich sein, so wie man das bisher z.B. von ARIS kennt. Wie sich für die Definition von Services die WSDL etabliert hat, kristallisiert sich hier die Business Process Execution Language (BPEL) heraus, welche ebenfalls eine XML-Beschreibung darstellt. Bei der Spezifikation der Business Execution Language for Web Services (BPEL4WS) hat IBM. Die Spezifikation ist bereits von May 2003. Die Alphaworks-Gruppe von IBM stellt hier einen Modeller-PlugIn für Eclipse sowie einen BPEL-Server für WebSphere und Tomcat bereit.

Process Engine

Die Process-Engine ist für den korrekten Ablauf eines Prozesses verantwortlich. D.h. die orchestrierten Prozesse müssen von der Process-Engine so ausgeführt werden, das Sie in ihrem Ablauf korrekt ausgeführt werden. Auch dies ist eine anspruchsvolle Herausforderung, da es Workflow-Engines schon seit “IBMs Lotus-Notes-Zeiten” gibt und in der Praxis immer wieder zu Überraschungen führten.

Enterprise Service Bus

Der Enterpirse-Service-Bus (ESB) ist die Middleware die Alles mit Allem verbindet. Vollgestopft mit Adaptern, XML, RMI, CORBA usw. sorgt diese Middleware dafür das Services mit Services, prozessübergreifend miteinander sprechen können.
Links:

http://orchestrationpatterns.com/files/SOADefined.pdf

http://www.softwareag.com/de/Images/20050930EAI_Competence_Day_SAG_Vortrag_tcm17-16000.pdf