SOA - Merkmale service-orientierter Architekturen und Aspekte der Entkopplung

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Grundlagen service-orientierter Architekturen
2.1 Definitionen von SOA
2.2 Das Service Konzept
2.2.1 Service Consumer
2.2.2 Service Provider
2.2.3 Service Registry
2.2.4 Publish-Find-Bind Pattern

3 Merkmale service-orientierter Architekturen
3.1 Abstraktion und Kapselung
3.2 Agilität und Flexibilität
3.3 Unterstützung der Wiederverwendung
3.4 Technologieunabhängigkeit
3.5 Integration von Legacy Systemen
3.6 Geschäftsprozessorientierung und Komposition
3.7 Autonomie
3.8 Lose Kopplung

4. Service-orientierte Architekturen und Aspekte der Entkopplung
4.1 Kommunikationsmechanismen
4.1.1 Synchrone Kommunikation
4.1.2 Asynchrone Kommunikation
4.2 Bindung durch Service Registry
4.2.1 Statischen Binden
4.2.2 Dynamisches Binden
4.3 Event Driven Architecture
4.4 Domänenmodell
4.5 Business Rules

5 Bewertung und Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1: Rollen in einer SOA

Abbildung 3.1: Kapselung / Abstraktion

Abbildung 3.2: SOA Governance und SOA Management im Spannungsfeld von IT und Business

Abbildung 4.1: Synchrone Kommunikation

Abbildung 4.2: Asynchrone Kommunikation

Abbildung 4.3: Statisches Binden

Abbildung 4.4: Umsetzung EDA in SOA

Abbildung 4.5: Business Rules

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In der folgenden Arbeit wird dem Leser die Thematik der service-orientierten Architekturen näher gebracht. Dabei wird zunächst die Kontroverse in Bezug auf die eigentliche Definition einer SOA dargestellt und erläutert. Des Weiteren folgt eine Beschreibung und Erläuterung der Rollen des ‚Publish Find Bind’ Patterns zur Funktionsweise einer SOA. Danach werden dem Leser die zentralen Merkmale einer service-orientierten Architektur näher gebracht, wobei hier eine Art ‚best of’ Auswahl getroffen wurde, da auch in diesem Kontext keine einheitliche Darstellung in der Literatur vorherrscht. Ausgehend von dieser Betrachtung wird im letzen Kapitel dieser Arbeit gesondert auf verschiedene Aspekte der Entkopplung eingegangen, da die lose Kopplung in service-orientierten Architekturen eine zentrale Rolle spielt. In dem Zusammenhang wird zusätzlich der jeweilige Aspekt hinsichtlich der Integrationsmöglichkeit in eine SOA betrachtet.

2 Grundlagen serviceorientierter Architekturen

2.1 Definitionen von SOA

In der Literatur existiert eine Vielzahl unterschiedlicher Definitionen, es ist folglich ersichtlich, dass es bis heute keine eindeutige Auslegung einer service-orientierten Architektur gibt. Es sind zwar teilweise Überlappungen festzustellen, jedoch wird deutlich, dass man sich bei einer Definition von service-orientierten Architekturen immer auf eine Gradwanderung zwischen unterschiedlichen Betrachtungsebenen einlässt. Zum einen wird häufig eine eher allgemeine Abstraktion gewählt, welche hauptsächlich architekturbezogene Aspekte beleuchtet, zum anderen wird eine technisch bezogene Sicht in den Fokus gestellt, wo Ansätze konkreter Technologien zu erkennen sind.

Im Folgenden werde ich einige Definitionen vorstellen und erläutern, wobei festgehalten werden muss, dass es keine einzig richtige Definition service-orientierter Architekturen gibt. [vgl. DJMZ2005, 11]

Erl kommt zu folgender Definition einer SOA:

„SOA is a form of technology architecture that adheres to the principles of servcie-orientiation. When realized trough the Web Services technology platform, SOA establishes the potential to support and promote these principles troughout the business process and automation domains of an enterprise” [Erl2005, 54]

Hier wird SOA als technologische Architektur beschrieben, die die Prinzipien der Service-Orientierung verfolgt. Dabei ermöglicht eine webservice-basierte Implementierung einer SOA, dass diese Prinzipien auf die Geschäftsprozesse und automatisierte Bereiche übertragen werden können. Grundsätzlich wird hier eine eher technische Betrachtungsweise in Bezugnahme der zentralen Prinzipien der Serviceorientierung dargestellt, so werden hier Webservices als zentrale Umsetzung einer SOA genannt. An anderer Stelle beschreibt Erl jedoch, dass diese von ihm genannten Prinzipien bis in die Ebene der Geschäftsprozesse hinein greifen und weist auf SOA als ganzheitliches Konzept hin, wobei jedoch die technischen Aspekte überwiegen. [vgl. Erl2005, 88]

Krafzig hingegen bietet eine Definition, in der konkrete Komponenten, welche eine service-orientierte Architektur ausmachen, benannt werden.

„A Service Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application frontend, service, service repository, and service bus. A Service consists of a contract, one or more interfaces , and an implementation.” [KrBS2004, 57]

In diesem Zusammenhang veranschaulicht Krafzig eine Softwarearchitektur als eine Beschreibung verschiedener Softwarekomponenten und deren Beziehungen untereinander. Des Weiteren dient die Architektur als eine Art ‚Blaupause’, bzw. ein ‚High Level Plan’ für die eigentliche Konstruktion des IT Systems. [vgl. KrBS2005, 56] Krafzig legt hier großen Wert auf die Schlüsselkonzepte ‚Endnutzer-anwendung’, ‚service’, ‚service repository’ und ‚service bus’ und deutet damit bereits konkrete Technologiekonzepte an.

Dostal definiert eine service-orientierte Architektur hingegen folgendermaßen und lässt hier konkrete Technologien mit Absicht außen vor:

„Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wieder verwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht.“ [DJMZ2005, 11]

Diese Festlegung deutet auf einige zentrale Merkmale, wie Wiederverwendung oder Autonomie der Services einer SOA hin, wobei offen gelassen wird, in welchem Rahmen diese Systemarchitektur zu sehen ist.

Ausgehend von den vorangestellten Definitionen ist es im Kontext einer SOA wichtig zu erkennen, dass diese in einem globaleren Kontext gesehen werden sollte, denn diese verkörpert eine neuartige Denkweise. Durch das Service-Konzept wird es möglich, ausgehend von der damit verbundenen Geschäftsprozessorientierung, eine gemeinsame und integrative Betrachtung hinsichtlich der Geschäfts- und IT-Ebene zu gewährleisten. Dadurch wird eine enge Abstimmung zwischen Software- und Unternehmensarchitektur ermöglicht und führt dazu, Potentiale für die optimale Unterstützung der Unternehmung durch die IT freizulegen.

2.2 Das Service Konzept

Eine service-orientierte Architektur beschreibt eine Software-Infrastruktur, in der die wesentlichen Funktionen einer Anwendung in Services gekapselt werden. Services werden in diesem Zusammenhang als Softwarekomponenten bezeichnet, welche bestimmte, klar abgegrenzte und eigenständig nutzbare Funktionen implementieren und von anderen Services genutzt werden können. [vgl. OWRB2005, 210] Dabei spielt die Verteilung der Services keine Rolle, da diese über standardisierte Schnittstellenbeschreibungen Kommunikationsbeziehungen aufbauen können. Darauf aufbauend tauschen diese unabhängig von der zu Grunde liegenden technologischen Plattform Daten aus, wodurch auch monolithische Abhängigkeiten wie durch ‚Client/Server Verbindungen’ aufgelöst werden. Diese Grundlage bietet die Möglichkeit, Services flexibel an den Prozessen der Unternehmung zu orientieren und anzupassen. [vgl. MaPa2004] Dabei wird deutlich, dass SOA eine neue Denkweise anstößt, indem, ausgehend von den Geschäftsprozessen, sinnvolle Applikationsfunktionalitäten als Services realisiert werden. Dabei wird eine SOA jedoch nicht als eigentliche Technologie betrachtet, sondern umfasst ein vollständiges Architekturkonzept, wobei durch konsequente Anwendung von SOA-Prinzipien, Vorteile auf allen Ebenen einen Unternehmensarchitektur realisiert werden können. Dementsprechend kann SOA auch als ganzheitlicher Rahmen bezeichnet werden, der ausgehend von Aspekten der eigentlichen unternehmensbezogenen Aufgaben eine Umsetzung auf IT--Ebene unterstützt und somit eine enge Verzahnung von IT und Unternehmung ermöglicht. [vgl. WeDS2006] Im Folgenden wird zunächst die eigentliche Funktionsweise einer SOA, ausgehend von den verschiedenen Rollen betrachtet und erläutert, um dem Leser einen ersten Einblick in das Service-Konzept und dessen Ablauf zu geben. Dabei ist festzuhalten, dass es sich hier lediglich um ein Pattern auf Mikro-Ebene handelt, welches in der Literatur vielfach aufgezeigt und beschrieben wird. Auf technischer Ebene gibt es unterschiedlichste Varianten zur Implementierung einer SOA, wobei sich jedoch fast alle auf dieses Pattern beziehen lassen.

2.2.1 Service Consumer

Der ‚Service Consumer’ kann im Kontext der Rollenverteilung innerhalb einer SOA mit einem Client in einer klassischen Client/Server Architektur verglichen werden. Unterscheidungen sind lediglich bei den Schritten zum Aufruf des Dienstes zu erkennen, so wird eine lose Bindung und eine Auswahl des gewünschten Dienstes bei der ‚Service Registry’ erst zur Laufzeit, ohne explizite Kodierung im klassischen System, vollzogen. Dem Dienstnutzer ist durch die lose Kopplung nicht ersichtlich wer den Dienst konkret anbietet, umgekehrt muss der Dienstanbieter keine Kenntnis von dem Client haben. Um dies jedoch gewährleisten zu können, ist es wichtig, dass Standards eingehalten werden. So muss der Dienst in der Lage sein dem Dienstnutzer seine Schnittstelle vollständig darzulegen, was nur möglich ist, wenn beide auf gemeinsame Konstrukte zurückgreifen können und diese interpretieren. Dieser Sachverhalt wird durch eine einheitliche, sprachunabhängige und standardisierte Dienstbeschreibungssprache realisiert. Die Kommunikation findet dann über ein Protokoll statt, dass sowohl Dienstanbieter als auch Dienstnutzer bekannt ist. Grundsätzlich kann ein Dienstnutzer aus einer Anwendung, einem anderen Service oder einem anderen Typ Software bestehen. [vgl. DJMZ2005, 15]

2.2.2 Service Provider

Der Dienstanbieter registriert die, von ihm zur Verfügung gestellten Dienste über eine standardisierte Schnittstellenbeschreibung bei einem Verzeichnisdienst, die Service Registry, sodass dem Dienstnutzer die Möglichkeit zur Suche nach diesem Service ermöglicht wird. Dieser interpretiert die ihm zugewiesene Schnittstellenbeschreibung und bekommt alle notwendigen Informationen, um den Dienst nutzen zu können. Dem Dienstanbieter werden in dem Zusammenhang einige Aufgaben zugesprochen, wie beispielsweise die Sicherstellung der Verfügbarkeit des Dienstes. Häufig ist die Nutzung von Services von wirtschaftlich großem Interesse, denn ein Ausfall würde wirtschaftliche Schäden zur Folge haben. Des Weiteren muss der Dienstanbieter die Authentifizierung und Authentisierung übernehmen, wobei sichergestellt werden muss, dass der Dienstnutzer derjenige ist, für den er sich ausgibt und die Zugriffsberechtigung für den Service besitzt. Der Dienstanbieter ist darüber hinaus in der Lage mehrere Dienste nach außen hin zu kapseln, sodass er nicht alle Dienste selbst entwickeln und implementieren muss. So könnte ein vereinfachter Zugriff auf einen Dienst ermöglicht werden, wobei jedoch die oben genannten Aufgaben, auch bei gekapselten Diensten, gewährleistet werden müssen [vgl. DJMZ2005, 14]

2.2.3 Service Registry

Die Service Registry stellt ein zentrales Dienstverzeichnis dar und beinhaltet die primäre Aufgabe Suchanfragen entgegenzunehmen und dem Service Consumer eine Verbindung zu einem Dienst zu ermöglichen. Die Service Registry muss in diesem Kontext die Dienstbeschreibung zur Verfügung stellen, worin die von dem Dienst verfügbaren Schnittestellen beschrieben sind. Darüber hinaus sind jedoch auch nicht funktionale Aspekte von Bedeutung, welche ebenfalls in der Dienstbeschreibung festgelegt werden. In diesem Kontext wird oft von dem ‚Service Level Agreement’ gesprochen, welches beispielsweise die maximale Antwortzeit eines Services darlegt. Dienstanbieter können diese in der Registry durch eine standardisierte Beschreibungssprache veröffentlichen und somit anderen Nutzern zur Verfügung stellen. Die Service Registry trägt somit wesentlich zur Entkopplung des den Dienstnutzers vom Dienstanbieter bei, da die Suche und die Bindung an einen speziellen Service erst zur Laufzeit erfolgt. Je nach Anwendungsfall kann eine Service Registry auf unterschiedliche Weise implementiert werden und beispielsweise auch eine attributierte Anfrage entgegennehmen, so dass der Dienstnutzer differenziertere Anfragen stellen kann und somit eine qualitativ bessere Nutzungsmöglichkeiten erwarten darf.

Ausgehend von dem angefragten funktionalen Kontext kann die Service Registry dementsprechend zusätzliche Kriterien für eine optimale Suche hinzuziehen. [vgl. DJMZ2005, 15] Die Service Registry stellt somit alle Informationen zur Verfügung, die notwendig sind, um einen Dienst zu nutzen. [vgl. Erl2005, 60]

2.2.4 Publish-Find-Bind Pattern

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Rollen in einer SOA

Quelle: in Anlehnung an [vgl. Haas2003]

Ausgehend von den zuvor beschriebenen Rollen einer SOA, umfasst das ‚Publish-Find-Bind Pattern’ einige Aktionen um das Zusammenspiel zwischen den einzelnen Akteuren zu gewährleisten. Anhand von Abbildung 2.1 lassen sich folgende wesentliche Aktionen identifizieren. Dabei umfasst die ‚publish’ Aktion das Veröffentlichen aller Informationen, die zur Nutzung notwendig sind. Um des Weiteren eine uneingeschränkte Nutzung zu gewährleisten, muss ein Service vor der Registrierung bei der ‚Service Registry’ zunächst in einer entsprechenden Umgebung installiert werden. Das Auffinden eines Services durch eine Anfrage an die Service Registry kann als weitere Aktion identifiziert werden, wobei die Service Registry einen ‚best fit’ Abgleich mit den schon registrierten Services und dessen Schnittstellenbeschreibungen durchführt. Zu guter Letzt findet das Binden des Service Consumers an den Service Provider und die eigentliche Nutzung statt, bei der die, durch Schnittstellenbeschreibung festgelegten Parameter bezüglich Verschlüsselung oder ähnlichem einzuhalten sind. [vgl. DJMZ2005, 16]

3 Merkmale service-orientierter Architekturen

Im Folgenden wird auf die zentralen Merkmale eingegangen, die eine service-orientierte Architektur charakterisieren. Dabei ist zu beachten, dass in der Literatur, auf Grund einer fehlenden einheitlichen Definition, eine Vielzahl unterschiedlicher Merkmale aufgeführt wird, die sich jedoch nicht durch eine einheitliche Betrachtung auszeichnen. Dabei wird versucht, das jeweilige Merkmal aus einem allgemeinen Betrachtungswinkel zu erläutern, um darauf folgend den wesentliche Fokus auf den Kontext einer SOA zu legen.

3.1 Abstraktion und Kapselung

Abstraktion stellt in Bezug auf Software-Architekturen einen wichtigen Aspekt zur Komplexitätsreduktion dar, indem Details, die für einen bestimmten Kontext nicht von Relevanz sind, ausgeblendet werden. [vgl. Albi2003, 144] Ausgehend von einem hohen Abstraktionsniveau wird hier eine sehr zentrale Grundlage zur Entwicklung von Software-Architekturen geschaffen, da durch die Architektur eine gemeinsame Kommunikationsgrundlage vorhanden ist, die eine Verständigung verschiedener Individuen, mit unterschiedlichem Wissenshintergrund ermöglicht. Gerade in Bezug auf die Verständigungs- und Akzeptanzprobleme zwischen Unternehmensführung und IT ist dieser Aspekt von herausragender Bedeutung. Um jedoch dem Informationsbedarf einzelner Betrachter gerecht zu werden, können verschiedene Dekompositionen durchgeführt werden. Diese ermöglichen die Betrachtung der Architektur auf gewisse Sichten zu erweitern, um damit einen spezielleren Kontext und die damit verbundenen Informationen abzubilden. [vgl. DuGH2003, 2f.] Durch Abstraktion wird auch das Prinzip der Kapselung vorangetrieben, welches im Wesentlichen das Ziel verfolgt, nach außen so wenig Informationen wie möglich offen zu legen, um dadurch zusätzlich Abhängigkeiten zu reduzieren. [vgl. Rieb2006, 74] Die Services bieten somit eine geschäftsprozessorientierte Abstraktion und gewähren eine transparente Sicht auf die dahinter liegende tatsächliche Umsetzung einzelner Teilprozesse. Die Kapselung wird in diesem Kontext durch die von den Services zur Verfügung gestellten Schnittstellen gewährleistet. Services fungieren bei ihrer Nutzung innerhalb einer SOA somit als eine Art Blackbox, die ihre zugrunde liegenden Funktionen vor der Außenwelt verstecken, wobei nur die Schnittstellenbeschreibungen öffentlich zugreifbar sind. [vgl. Erl2005, 298ff.] In der folgenden Abbildung 3.1 wird deutlich, dass der ‚Business Service’ als Service Consumer komplett von der eigentlichen Implementierung des ‚Order Process’ Services abstrahieren kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Kapselung / Abstraktion

Quelle: in Anlehnung an [vgl. WiVe2004]

Er interagiert lediglich über die, durch den ‚Order Process’ Service zur Verfügung gestellten Schnittstellen, ohne von der dahinter liegenden eigentlichen Implementierung und Abwicklung Kenntnis haben zu müssen. Somit kapselt der ‚Order Process’ Service den Zugriff durch den ‚Business Service’ und stellt eine Facade für die von außen zugreifenden Clients dar. [vgl. WiVe2004]

[...]