Einer der größten Trends, die die IT-Welt in den letzten Jahren geprägt haben, sind die sog. serviceorientierten Architekturen (SOA, vgl. [Alex2007]). Im folgenden Kapitel wird diese Form von Softwarearchitekturen vorgestellt und definiert. Es wird gezeigt, welche Elemente zu den grundlegenden Bestandteilen dieses Architekturtyps gehören und aus welchen Gründen Unternehmen eine SOA einführen und darüber hinaus nutzen sollten. Zum Abschluss dieses Kapitels wird erklärt, welche Rolle Portale hierbei spielen. Das Ziel dieses Kapitel ist eine grundlegende Einführung in die Welt der SOAs, bei der die wichtigsten Konzepte und Fragestellungen zu diesem Thema vorgestellt werden.
Für den Begriff SOA gibt es keine einheitliche, standardisierte Definition, jedoch ähneln sich die unterschiedlichen Begriffsbestimmungen inhaltlich sehr (vgl. [Heut2007, 21 ff.]), wie folgende Beispiele zeigen:
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” [MLMB2006, 8]
“A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components – services – that can be reused and combined to address changing business priorities.” [BBFJ2006, 5]
“A set of components which can be invoked, and whose interface descriptions can be published and discovered.” [W3C2004]
Die verschiedenen Definitionen haben gemeinsam, dass eine SOA eine Softwarearchitektur ist, „die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt“ [Heut2007, 22]. Als Elemente dieser Softwarearchitektur lassen sich dabei das Anwendungs-Frontend, die
Services, das Service-Repository und der (Enterprise) Service-Bus identifizieren (vgl. [KrBS2007, 76 ff.]). Im Groben lässt sich das Grundkonzept der Service-orientierung wie folgt erklären: Ein Service Anbieter (Service Provider) veröffentlicht einen Service und bietet diesen zur Nutzung an. Dieser wird in einem zen-tralen Service-Verzeichnis (Service Registry) verwaltet und kann hierüber gefunden werden. Ein Service-Nutzer (Service Requestor) findet diesen Service samt seiner Quelle im Verzeichnis und kann diesen verwenden. Die Nutzung beruht auf einem direkten Datenaustausch zwischen Service-Nutzer und Service-Anbieter (vgl. auch [MSJL2006, xxi ff.; Erl2006, 74 ff.; Kaye2003, 95 ff.]). Abbildung 5 verdeutlicht dieses Grundprinzip der Serviceorientierung anhand der Beziehungen von Service-Nutzer, Service-Anbieter und Service-Verzeichnis untereinander.
Abbildung 5: Das Prinzip der Serviceorientierung
Quelle: in Anlehnung an [MSJL2006, xxii; Erl2006, 75; Kaye2003, 96]
Das Konzept der Serviceorientierung ermöglicht es, dass die einzelnen Services gekoppelt und wieder verwendet werden können. Das Prinzip der Kopplung von verschiedenen, voneinander unabhängigen Services zu einer Anwendung wird auch Loose Coupling (lose Kopplung) genannt (siehe [Kaye2003; Erl2006, 315]). Dabei werden die einzelnen Services, die in ihrer Kombination eine funktionierende Anwendung ergeben, zur Laufzeit dieser zusammengefügt und verwendet. Im Vergleich zur traditionellen Anwendungsarchitektur ergibt sich dabei ein Vorteil hinsichtlich der Entwicklungszeit von Anwendungen sowie einer geringeren Komplexität der Entwicklung. Es müssen eventuell nur noch kleine, nicht sehr umfangreiche Komponenten einer Anwendung neuentwickelt werden, während andere, als Service vorliegende Komponenten erneut verwendet werden können (vgl. [Kaye2003, 92 ff.]).
Aufbauend auf den offenen Schnittstellen der Services (siehe Kapitel 3.2.1), wird die Interoperabilität zwischen unterschiedlichen Systemen ermöglicht (vgl. [BBFJ2006, 4 ff.]). Die meisten Definitionen sehen Web Services als die typische Implementierungsform von Services innerhalb einer SOA. Daraus folgt, dass eine SOA eine Architektur beschreibt, die auf den grundlegenden Web Service-Technologien (wie SOAP, WSDL und UDDI) basiert (vgl. [BBFJ2006, 5]). Es ist jedoch bei dieser Form von Softwarearchitekturen nicht zwingend vorgeschrieben, die Services auf der Grundlage von Web Services umzusetzen. In den meisten Fällen werden Web Services aber als die Basistechnologie betrachtet (vgl. [Cart2007, 76 ff.]).
Für eine genauere Beschreibung einer SOA, werden im folgenden Abschnitt die Kernelemente Services, Anwendungs-Frontend, Service-Repository und Service Bus detaillierter beschrieben. Dabei wird vor allem die Bedeutung der Services in den Vordergrund gestellt. Diese Kernelemente bilden das Schlüsselkonzept im Rahmen einer SOA.
Die Kernkomponente einer SOA sind, wie bereits angedeutet wurde, die sog. Services. Dieses sind Softwarekomponenten mit speziellen Funktionen, die sich wie folgt definieren lassen:
„Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionen anbietet.“ [Heut2007, 22]
Der Service stellt sozusagen einen Dienst für andere Services oder Softwarekomponenten bereit. Der Vorteil bei der Verwendung von Services ist, dass Geschäftsprozesse viel einfacher an unternehmerische Anforderungen angepasst werden können, da sie miteinander gekoppelt und wieder verwendet werden können. Dies geschieht durch die Möglichkeit, dass unterschiedliche Services zu neuen Anwendungen kombiniert werden können. Dabei greifen die einzelnen Komponenten auf Funktionen der anderen Komponenten zu. In Abbildung 6 greift Service B auf die Funktionen von Service A zu. Die Anwendung ABCD ergibt sich daraufhin aus einer Kombination der Services B, C und D. Insgesamt sind dabei die vier Services A, B, C und D mit ihren Funktionen an der Anwendung ABCD beteiligt, die nun wiederum selbst einen nutzbaren Service darstellt. Die Aggregation oder besser gesagt die Kopplung wird auch als „Service Composition“ bezeichnet (vgl. [Erl2008, 39; WoMa2006, 142]). Dahinter verbirgt sich wiederum, das bereits oben vorgestellte Prinzip der losen Kopplung, welches vorsieht, dass Services untereinander keine Abhängigkeiten vorweisen und dementsprechend unabhängig voneinander genutzt und gekoppelt werden können. Das bedeutet, dass kein Service die Funktionen eines anderen voraussetzt (vgl. [Kaye2003, 131 ff.; Erl2006, 315]). Die SOA wird dadurch sehr flexibel hinsichtlich der Nutzung ihrer Komponenten (vgl. [BBFJ2006, 4 ff.]), da die unterschiedlichen Services für weitere Anwendungen wiederverwendet werden können (vgl. [Erl2006, 292 ff.]). Die Bestandteile eines Services sind der Service-Vertrag, Schnittstellen, die Implementierung sowie Geschäftslogik und Daten (vgl. [KrBS2007, 78 ff.] sowie Abbildung 7), welche im Folgenden näher vorgestellt werden.
Abbildung 6: Service Composition
Der Service-Vertrag beschreibt informell den Zweck, die Funktionalität, die Beschränkungen und die Nutzung des Services. Dazu kann ebenfalls eine for-male Schnittstellendefinition auf Basis von IDL oder WSDL vorhanden sein (dies ist aber nicht zwingend erforderlich). Der Vertrag liefert demzufolge Informationen über einen Service und stellt keine formale Spezifikation dar (vgl. [KrBS2007, 79; Erl2006, 313 ff.]). Der Service-Vertrag beschreibt zudem sämt-liche Ein- und Ausgabeoperationen, sowie deren Ein- und Rückgabewerte, des jeweiligen Services (vgl. [Erl2006, 295]). Anders gesagt: er beinhaltet sämtliche Metadaten eines Services hinsichtlich der Regeln und Bedingungen die erfüllt werden müssen, wenn mit dem Service interagiert wird (vgl. [Erl2006, 313 ff.]).
Die einzelnen Funktionen eines Services werden dem Client[21] über Schnittstellen bereitgestellt. Zwar werden die Schnittstellen im zuvor genannten
Service-Vertrag beschrieben, jedoch werden sie als Service-Stubs[22] implementiert, die von Clients des Services und einem Dispatcher verwendet werden (vgl. [KrBS2007, 79]).
Die Implementierung stellt die technische Umsetzung des Service-Vertrages dar, bestehend aus verschiedenen Elementen, wie Programmen oder Daten-banken und enthält zudem die Geschäftslogik und die entsprechenden Daten (vgl. [KrBS2007, 79]).
Abbildung 7: Bestandteile eines Service
Quelle: in Anlehnung an [KrBS2007, 78]
Abschließend bleibt zu erwähnen, dass ein Service eine Einheit mit einer spezi-ellen funktionalen Bedeutung darstellt. Clients haben somit einen transparenten Blick auf die Funktion eines Services und haben zwar Kenntnis darüber, welchen Zweck ein Service erfüllt, aber nicht wie. Es wird demnach von der technischen Funktionsweise abstrahiert. Der Service stellt somit eine geschlossene Blackbox dar, die einen speziellen Dienst anbietet (vgl....
