Der Wertbeitrag einer SOA in Abhängigkeit des Wiederverwendungsgrads ihrer Services

Inhaltsverzeichnis

1 EINLEITUNG
1.1 Motivation
1.2 Ziele

2 SERVICEORIENTIERTE ARCHITEKTUR
2.1 Schlüsselkonzepte einer SOA
2.2 Wesentliche Merkmale einer SOA
2.2.1 Lose Kopplung
2.2.2 Interoperabilität
2.2.3 Wiederverwendung
2.2.4 Komponierbarkeit
2.3 Service-Repository
2.4 Akteure und Rollen

3 SERVICEORIENTIERUNG
3.1 Theorie der Serviceorientierung
3.2 Definition aus Sicht des Service-Entwurfs
3.3 Wurzeln der Serviceorientierung
3.3.1 Objektorientierung
3.3.2 Webservices
3.3.3 Business Process Management (BPM)
3.3.4 Enterprise Application Integration (EAI)

4 SERVICE
4.1 Klassifizierung
4.1.1 Basis-Service
4.1.1.1 Daten-Service
4.1.1.2 Logik-Service
4.1.2 Komponierter-Service
4.1.3 Prozess-Service
4.2 Motivation für Webservices
4.3 Architektur von Webservices
4.4 Standardisierte Webservice-Technologien
4.4.1 SOAP
4.4.2 WSDL
4.4.3 UDDI
4.4.4 Sicherheitsspezifikationen

5 ZWISCHENFAZIT UND VORSCHAU

6 SERVICE-ENTWURF
6.1 Governance
6.2 Service-Lifecycle
6.3 Service-Identifikation
6.4 Entwurfsprinzipien im Überblick
6.4.1 Standardisierter Service-Vertrag
6.4.2 Lose Kopplung
6.4.3 Abstraktion
6.4.4 Autonomie
6.4.5 Zustandslosigkeit
6.4.6 Auffindbarkeit
6.4.7 Kompositionsfähigkeit
6.4.8 Wiederverwendbarkeit
6.5 Wiederverwendbarkeit im Fokus

7 GENERIERUNG DES DATENMATERIALS
7.1 Literarische Erhebung
7.2 Empirische Erhebung
7.2.1 Auswahl der geeigneten Interviewtechnik
7.2.2 Auswahl der Experten
7.2.3 Semistrukturiertes Leitfadeninterview
7.3 Qualitative Inhaltsanalyse
7.3.1 Auswahlkriterien für die Analysemethode
7.3.2 Vorgang der „Inhaltlichen Strukturierung“
7.3.3 Auswertung des Datenmaterials
7.3.4 Ablaufmodell der Analyse

8 FAZIT

9 LITERATURVERZEICHNIS

Abbildungsverzeichnis

Abbildung 1: Komponenten einer SOA

Abbildung 2: Point to Point

Abbildung 3: Enterprise-Service-Bus

Abbildung 4: Feste Kopplung vs. Lose Kopplung

Abbildung 5: Hub & Spoke - EAI

Abbildung 6: Wiederverwendung von Services

Abbildung 7: Komponierter Service

Abbildung 8: Metainformationen gewinnen

Abbildung 9: Magisches Dreieck der SOA

Abbildung 10: Menschu. Service - Fähigkeiten

Abbildung 11: Service-Kategorien u. -Ebenen

Abbildung 12: Architektur eines Webservice

Abbildung 13: Zwiebelschalenmodell derWebservice-Architektur

Abbildung 14: Kompletter Lifecycle eines Service

Abbildung 15: Business-Process-Modeling und Service-Identifikation

Abbildung 16: SOA vereint traditionelle u. kommerzielle Produktion

Abbildung 17: Ablaufmodell strukturierenderlnhaltsanalyse

Tabellenverzeichnis

Tabelle 1: Speicherort des Zustands und Konstellation

Tabelle 2: Sicherheitsanforderungen

Tabelle 3: Bestandteile einer SOA-Governance

Tabelle 4: Acht wertsteigernde Entwurfsmerkmale

Tabelle 5: Entwurfsprinzip - Standardisierter Service-Vertrag

Tabelle 6: Entwurfsprinzip - Kopplung von Services

Tabelle 7: Entwurfsprinzip - Abstraktion von Services

Tabelle 8: Entwurfsprinzip - Autonomie von Services

Tabelle 9: Entwurfsprinzip - Zustandslosigkeit von Services

Tabelle 10: Entwurfsprinzip - Auffindbarkeit von Services

Tabelle 11: Entwurfsprinzip - Kompositionsfähigkeit von Services

Tabelle 12: Entwurfsprinzip - Wiederverwendbarkeitvon Services

Tabelle 13: Beispiel - Kategoriensystem

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten^[1]

1 Einleitung

1.1 Motivation

Ziel serviceorientierter Softwarearchitekturen ist es, die Informationsverarbeitung in Unternehmen schneller und besser an immer volatilere Anforderungen moderner Geschäftsprozesse anpassen zu können als dies in traditionell monolithischen Archi­tekturen möglich ist. Die zugrunde liegende Idee dabei ist, Geschäftsprozesse durch flexible und lose gekoppelte Softwaredienste (Webservices) in die IT-Landschaft zu adaptieren. Strategisch ausgerichtete Geschäftsprozessmodelle fungieren bei der Um­setzung als Bindeglied zwischen Business und IT und begründen die Forderung nach der Aufhebung künstlicher Grenzen hin zu einem interdisziplinären Lösungsansatz.

Die größten Hindernisse der Vergangenheit, wie u.a. die offenen Fragen zur Sicherheit und Zuverlässigkeit (QoS) webbasierter Lösungen, die einer breiten Akzeptanz zur Umsetzung des neuen Architektur-Paradigmas in den Unternehmen im Wege standen, sind durch die Schaffung technologischer Standards beseitigt und haben dazu geführt, dass seit dem Jahr 2009 laut statistischer Erhebungen ca. 89 % aller Großunternehmen mit der Nutzung von Webservices begonnen haben (Vgl. Ried 2009, S. 38).

Agilität, Wiederverwendbarkeit und Reduzierung der IT-Kosten gehören zu den wesent­lichen Potenzialen einer ausgereiften serviceorientierten Architektur. Es wäre aber falsch anzunehmen, dass die reine Existenz einer SOA bereits einen Business Case darstellt. "Zur Erinnerung: Nur ein sparsames Auto zu besitzen ist auch noch kein Business Case. Der Aufbau einer Car-Sharing-Gemeinschaft kann jedoch mit einem klaren wirtschaftlichen Vorteil rechnen ..." (Vgl. Ried 2009, S. 39).

Um einen messbaren Wertbeitrag zum Unternehmenserfolg haben zu können, ist es also von größter Bedeutung, ein Service-Repository zu entwickeln, dessen kleinste Baustei­ne oder Orchestrierungen dieser, einen maximalen Grad an Wiederverwendbarkeit auf­weisen. Webservices, die sich als bestgeeignete Technologie zur Modularisierung von Geschäftprozessen etabliert haben, ist diese Eigenschaft nicht automatisch inhärent. Vielmehr ist dies einer der neuralgischen Punkte, von denen ein langfristig zu erwar­tender wirtschaftlicher Nutzen einer Serviceorientierung abhängt. Die Produktion quali­tativ hochwertiger Services darf nicht von glücklichen Umständen abhängen (Vgl. Erl 2008, S. 17), sondern muss im Rahmen festgelegter Regeln und standardisierter Vorge­hensweisen betrieben und im Kontext einer SOA Governance fortlaufend kontrolliert werden (Vgl. Finger et al. 2009, S. 87). Vorhersagbarkeit und Wiederholbarkeit, kurz Berechenbarkeit, sind Kriterien, die den strategischen Entscheidungsprozess eines Un­ternehmens für oder wider einer SOA-Einführung mit langfristigen und oftmals be­trächtlichen Investitionen beeinflussen (Vgl. Erl 2008, S. 17).

1.2 Ziele

Angesichts der oben geschilderten Situation, in der Unternehmen unter dem Druck der Erneuerung und der gleichzeitigen Verpflichtung unternehmerischer Risikoabwägung nach Lösungen für das entstandene Dilemma suchen und der zur gleichen Zeit in den Medien häufig sehr kontrovers diskutierten Einschätzungen zum Thema SOA im Allge­meinen und dem Einlösen der damit verbundenen Versprechungen im Speziellen, muss die Frage geklärt werden, inwieweit die Inhalte theoretischer Grundlagenforschung überhaupt als Ausgangspunkt für die praktische Umsetzung einer SOA dienlich sind.

An dieser Stelle setzt die vorliegende Arbeit an, indem sie durch eine vertiefte theore­tische und empirische Auseinandersetzung mit dem Kernelement Service, respektive den für deren planbaren Entwurf verfügbaren Prinzipien, auf praktische Anwendbarkeit und tatsächlich damit zu erreichende Ziele überprüfen will.

Jeder empirischen Untersuchung unterliegt eine zentrale Fragestellung als Ausgangs­punkt für die Entwicklung einer Untersuchungsstrategie, der Auswahl einer relevanten Analysemethode und der Selektion eines Teils des gesamten Untersuchungsgegen­standes (Vgl. Gläser 2009, S. 62).

Diesem Konzept folgend wird der Untersuchungsrahmen dieser Arbeit auf die „Rele­vanz von Entwurfs-Prinzipien “ eingegrenzt und dem gesamten Umfang angemessen, auf die Betrachtung des Service-Merkmals „ Wiederverwendbarkeit “ beschränkt. Ent­sprechend steht hier also folgende Fragestellung im Mittelpunkt der Untersuchung:

Welche Relevanz haben Entwurfsprinzipien in Unternehmen, den Grad der Wieder­verwendbarkeit von Services innerhalb derSOA zu beeinflussen?

Um diesemVorhaben gerecht werden zu können und der Tatsache schuldend, dass SOA oftmals ganz unterschiedlich definiert wird, ist es notwendig, grundlegende SOA-Kon- zepte unter Bezugnahme führender Fachautoren zunächst in der Breite und allgemein­gültig darzustellen. Diese Vorgehensweise, in der eine genaue Quellenkunde samt ihrer Entstehungsgeschichte an den Anfang der Untersuchung gestellt wird, entspricht den grundsätzlichen Anforderungen an eine qualitative Inhaltsanalyse (Vgl. Mayring 1988, S. 27). Hieran anschließend wird vom allgemeinen Rahmen der SOA auf die Bedeutung des Service und seiner Merkmale fokussiert, um darauf aufbauend Prinzipien zur Reali­sierung von Service-Merkmalen an Hand der aktuellen Fachliteratur zu extrahieren.

Der methodische Handlungsrahmen dieser rekonstruierenden Untersuchung basiert auf den von (Mayring 1988) entwickelten Techniken zur Gewinnung textuellen Datenmate­rials mit Hilfe von Experteninterviews, „in denen die Befragten als Spezialisten für be­stimmte Konstellationen befragt werden ...“ (Vgl. Gläser 2009, S. 12) und der „Quali­tativen Inhaltsanalyse“ zur Auswertung textbasierter Daten.

Zusammenfassend soll also das eingegrenzte Ziel dieser Arbeit darin gesehen werden, mit Hilfe systematischer Analyse empirisch erhobener Daten Erkenntnisse darüber zu gewinnen, ob der hypothetische Gehalt der aktuell erforschten Prinzipien zur Beein­flussung des Wiederverwendungsgrades von Services in der Praxis nachzuweisen ist.

Die Aussagekraft auch qualitativer Untersuchungen^[2] erfordert eine Mindestmenge aus­wertbaren Materials. Gleichzeitig ist die Gewinnung von Experten für ein Interview schon allein dadurch sehr schwierig, weil es naturgemäß nur wenige gibt und deren Zeit für Interviews eher eng bemessen ist. Dieser Willkür entgegenzutreten, soll dass Hauptinteresse dieser Arbeit darin bestehen, als konzeptionelle Vorlage für die Mög­lichkeit einer im größeren Stil angelegten Untersuchung dieser Fragestellung zu dienen. Dementsprechend liegt der Schwerpunkt auf der Erarbeitung eines strukturierten Unter­suchungsverfahrens, dass sich an den klassischen Gütekriterien^[3] qualitativer Inhalts­analyse orientiert.

2 Serviceorientierte Architektur

2.1 Schlüsselkonzepte einer SOA

Die im ersten Kapitel formulierten Herausforderungen an das Management von Ge­schäftsprozessen führen im Bestreben einer konsequenten Umsetzung zu einem neuen Denkansatz in der Softwarearchitektur, der auf den Schlüsselkonzepten Anwendungs­Frontend, Service, Service-Repository und Service-Bus basiert (Vgl. Krafzig 2007, S. 77). Die folgende Abbildung stellt die Beziehungen der Komponenten einer SOA hierarchisch dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Komponenten einer SOA (In Anlehnung an Finger et al. 2009, S. 9)

Serviceorientierte Architekturen eröffnen die Chance, die Integration bereits vorhan­dener und neu zu entwickelnder Informationssysteme flexibel, prozessorientiert und evolutionär durchführen zu können und orientieren sich an dem Ziel, eine IT-Infra- struktur zu gestalten, die den Geschäftsprozess in den Mittelpunkt stellt (Vgl. Juric 2006, S. 12). Die Aussicht, langfristig komplex-monolithisch gewachsene Informations­systeme durch lose miteinander verbundener Services zu ersetzen, die es erlauben Busi­ness-Anforderungen im Idealfall automatisiert und somit zeitnah zu realisieren, stellt das Credo einer SOA dar und kann es leisten, die Kluft zwischen betriebswirtschaft­licher und technischer Prozessmodellierung zu überwinden. Abbildung 2 zeigt, wie Anwendungen in gewachsenen IT-Systemen durch „Point-to-Point-Beziehungen“ fest miteinander verbunden sind. Die Gartner-Group spricht in diesem Zusammenhang bereits 1999 vom „Application Spaghetti“, dessen Verbindungen nicht nur äußerst unübersichtlich und unflexibel sind, sondern darüber hinaus hohe Kosten für Pflege und Wartung erzeugen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Point to Point (In Anlehnung an Finger et al. 2009, S. 6)

In der folgenden Abbildung 3 wurden die festen Verbindungen zwischen den Anwen­dungen aufgelöst, um indirekt über eine Vermittlungsschicht (Enterprise-Service-Bus) verbunden zu werden. Diese serviceorientierte Grundforderung nach einer lose gekop­pelten Anwendungslandschaft erlaubt esjeder angeschlossenen Komponente, Daten und Funktionen anderer Komponenten zu verwenden. Neben einer besseren Übersichtlich­keit ergeben sich weitere Vorteile wie flexible Änderbarkeit, leichte Wartbarkeit,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Enterprise-Service-Bus (In Anlehnung an Finger et al. 2009, S. 7)

Wiederverwendbarkeit, erweiterte Nutzbarkeit vorhandener Software, Skalierbarkeit und die Möglichkeit, unterschiedliche Technologien auf der Ebene des Service-Bus ein­setzen zu können (Vgl. Finger et al. 2009, S. 5f).

2.2 Wesentliche Merkmale einer SOA

In der Literatur werden eine Vielzahl unterschiedlicher Merkmale zur Charakterisierung einer SOA vorgestellt, die aus oftmals sehr unterschiedlichen Blickwinkeln entstanden sind. Die wesentlichen Merkmale, bei denen es allgemeine Übereinstimmung gibt, sollen im Folgenden aus einer verallgemeinernden, informationstechnischen Perspek­tive beschrieben werden.

2.2.1 LoseKopplung

Das Maß der Abhängigkeit zweier Systeme kann durch die Einführung des Prinzips „Lose Kopplung von Services“ vermindert werden und führt zur Erhöhung der Flexi­bilität innerhalb einer Software-Architektur (Vgl. Finger et al. 2009, S. 7). Lose Kopp­lung und damit Unabhängigkeit der beteiligten Softwarekomponenten wird erreicht, wenn die Implementierung der eigentlichen Programmfunktionalität nach außen gekap­selt (verborgen) und eine Kommunikation ausschließlich nachrichtenbasiert über eine offen gelegte Service-Schnittstelle angeboten wird (Vgl. Juric 2006, S. 42), wie es die Abbildung 4 verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Die Vermeidung der bereits weiter oben beschriebenen „Point-to-Point-Beziehungen“ herkömmlicher Architekturen hilft dabei, die Komplexität zu reduzieren und die An­wendungslandschaft insgesamt agiler hinsichtlich Systemwartung und Änderungen zu machen. Das Anpassungsrisko implementierter Programmlogik wird dadurch verringert, weil es lokal begrenzt und überschaubar bleibt (Vgl. Krafzig 2007, S. 67).

2.2.2 Interoperabilität

Heutige Anwendungslandschaften sind durch eine Vielzahl unterschiedlicher Technolo­gien gekennzeichnet, die durch historische Gegebenheiten, persönliche Vorlieben, Ge­schäftsübernahmen und nicht zuletzt durch vertikale Organisationsstrukturen und deren impliziter Funktions- und Datenredundanz gewachsen sind. Diese Heterogenität ist ein Faktum, gegen das sich Unternehmen in der Vergangenheit zunächst durch Daten- und

Funktionsintegration mit Standardsoftware und später durch die Einführung eines EAI- Konzepts (Enterprise-Application-Integration) gestemmt haben, um den Übergang von funktionsorientierten zu prozessorientierten IT-Systemen zu schaffen. Diese Lösungs­ansätze sind als Vorstufen der heutigen SOA zu verstehen und führen in Anbetracht ihres Ergebnisses zu der Erkenntnis, dass man Heterogenität nicht aufheben kann, son­dern als eine natürliche Gegebenheit zu akzeptieren ist, die es zu verwalten gilt (Vgl. Krafzig 2007, S. 70f).

Wenn es gelingt, eine Verbindung zwischen Systemen schnell und einfach herzustellen, spricht man von einer hohen Interoperabilität. Dies ist das Hauptziel von EAI-Projekten, bei denen die Applikationen unverändert über eine zentrale Middleware^[4] (siehe Abbil­dung 5) verbunden werden, um gegenseitig Daten austauschen zu können.

Abbildung in dieser Leseprobe nicht enthalten

Für SOA ist diese Anforderung nur ein Teilziel, das die Basis für weitere Konzepte liefert, fachliche Funktionalität in Services zu verpacken und technisch einfach über verschiedene verteilte Systeme abzuwickeln (Vgl. Josuttis 2009, S. 21).

„Services werden inhärent interoperabel entworfen, unabhängig davon, wann und für welchen Zweck sie bereitgestellt werden. Die inhärente Interoperabilität ist ein funda­mentales Ziel der Serviceorientierung und legt die Basis für die Realisierung anderer strategischer Ziele und Vorteile“ (Vgl. Erl 2008, S. 72).

2.2.3 Wiederverwendung

Die Wiederverwendbarkeit von Lösungslogik als Service gehört zu den elementaren Zielen der SOA und beinhaltet langfristig betrachtet, neben dem Merkmal Interope­rabilität, das größte Rentabilitätspotenzial einer Investition (Vgl. Erl 2008, S. 105f). Die Bedeutung dieses Merkmals wächst, wenn man sich das Szenario automatisierter Um­gebungen vor Augen hält, in dem unterschiedliche Geschäftsprozesse durch Wiederver­wendung gleicher Services zur technischen Umsetzung herangezogen werden. Die zur Realisierung dieses Merkmals erforderliche Fähigkeit wird häufig damit verwechselt, die Zukunft vorhersagen zu können und deutet auf eine falsche Entwurfsstrategie hin. Wiederverwendungspotenziale entstehen, wenn Servicelogik in einem agnostischen (umgebungsneutralen) Kontext und der genauen Kenntnis ihrer potenziellen Nutzer ent­wickelt wird und hält einem Vergleich mit der kommerziellen Entwicklung von Mas­senprodukten am Gütermarkt, bei der die Kenntnis von Zielgruppe und Anforderung durch Marktanalyse identifiziert und als Vorgabe verwendet werden, stand. Hierfür ist ein interdisziplinärer Informationsaustausch zwischen Business und IT zwingend erfor­derlich, wobei die Herausforderung nicht darin zu sehen ist, absolute Wiederverwen­dung zu realisieren, sondern darin, die geeignete Art und Menge von Lösungslogik auf der Basis sachkundiger Analysen festzulegen und in einem Service zu kapseln. (Vgl. Erl 2008, S. 266). In Abbildung 6 wird gezeigt, wie zwei Anwendungsfrontends (Clients) die gleichen Services verwenden und somit redundante Lösungslogik durch Wiederver­wendung vermieden werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Wiederverwendung von Services (Eigene Darstellung)

Neben der drastischen Verkürzung der Entwicklungs- bzw. Anpassungszeit neuer Ge­schäftsprozesse sind die Verringerung der zu pflegenden Lösungslogik und eine konti­nuierliche Verbesserung in der Service-Qualität die entscheidenden Ergebnisse der Wie-derverwendung von Services. In der Vergangenheit sahen Unternehmen ihre Initiativen, eine SOA einzuführen, oftmals darin gescheitert, dass die Erzeugung wiederverwend­barer Lösungslogik in nicht ausreichendem Ausmaß realisiert werden konnte (Vgl. Erl 2008, S. 206). Die Gründe hierfür sind vielfältig, lassen sich aber letztlich auch auf das Fehlen beispielhafter und regelnder Vorgehensmodelle für den Service-Entwurf zurück­führen.

2.2.4 Komponierbarkeit

Die oben beschriebene Ausgangslage, in der Services wiederverwendbare Lösungslogik bereitstellen, um durch verschiedene Clients in beliebiger Reihenfolge^[5] kombiniert wer­den zu können, verlagert einen Großteil der Komplexität der Aufrufsteuerung und des Datenaustausches auf das Anwendungsfrontend, wie es in Abbildung 7 deutlich wird (Vgl. Krafzig et al. 2007, S. 108). Diese Komplexität auf der Client-Seite kann reduziert werden, wenn Services entworfen werden, die selbst wiederum andere Services zur Er­füllung einer Teilaufgabe kombinieren, und das Resultat ihres Dienstes, wie in Abbil­dung 7 gezeigt, in nur einer einzigen Schnittstelle anbieten.

Abbildung in dieser Leseprobe nicht enthalten

Durch Komposition von Basis-Services^[6] entstehen Services auf höherer Ebene, die durchaus mit der einer traditionellen Anwendung vergleichbar sind (Vgl. Erl 2008, S. 53). Ein wesentlicher Unterschied hierzu ist allerdings, dass die Bereitstellung der Funktionalität in Kompositionen ausschließlich über lose Kopplung und nicht über feste Point-To-Point-Beziehungen realisiert wird. Die Steuerung dieser orchestrierten Ser­vices erfolgt durch speziell für diese Aufgabe entwickelte Anwendungen, die eine Mo­dellierung der Prozesse^[7] mit Hilfe der Business-Process-Execution-Language (BPEL) und grafischen Tools unterstützen. Das Prinzip der Wiederverwendung einzelner oder kombinierter Services kommt genau an dieser Stelle besonders zum Tragen. Die Or­chestrierungsebene stellt somit den Dreh- und Angelpunkt für die Flexibilisierung der Geschäftsprozesse dar.

2.3 Service-Repository

Damit eine Orchestrierung auf der Basis wiederverwendbarer Services überhaupt erst möglich wird, bedarf es eines Prozesses für das Wiederfinden und Interpretieren (Disco- very-Mechanismen^[8] ) bereits vorhandener Ressourcen (Vgl. Erl 2008, S. 369). Diese Aufgabe übernimmt ein Service-Repository als UDDI-Verzeichnisdienst^[9], der alle zur Verfügung stehenden Services registriert und die dazugehörigen Schnittstellen, als die von einem Nutzer zugreifbaren Operationen, in einem maschinenlesbaren, standardi­sierten Format beschreibt (Vgl. Melzer 2009, S. 9). Im Kontext von Webservices ist hier ein Service-Vertrag in Form eines WSDL-Dokumentes realisiert, in dem die Funkti­onen und mögliche Beschränkungen zur Nutzung des Dienstes für die Gewährleistung einer reibungslosen Kommunikation spezifiziert sind (Vgl. Finger et al. 2009, S. 20). Des Weiteren werden nichtfunktionale Angaben (Policy) zur physikalischen Speiche­rung und zum Provider des Dienstes, sowie technische Beschränkungen und Transak­tions- oder Sicherheitsbestimmungen einer Wiederverwendung offengelegt (Vgl. Finger et al. 2009, S. 24). Angesichts der Bedeutung eines Service-Repository für die Auffind- barkeit und somit der Wiederverwendbarkeit vorhandener Dienste ist bei der Bereitstel-lung insbesondere auf die Qualität der zu hinterlegenden Metainformationen zu achten. Hierzu ist es nötig, bereits zu Beginn der Serviceerstellung alle relevanten Metainfor­mationen konsistent zu dokumentieren, weil in der frühen Phase der Modellierung Ge­schäfts- und Technologieexperten zusammenarbeiten und sich die Chance bietet, neben technischen eben auch die geschäftsrelevanten Metainformationen zu erkennen und zu dokumentieren, solange sie zugänglich sind (Vgl. Erl 2008, S. 378).

Korrektheit, Aktualität und übergreifende Verfügbarkeit der Informationen zu einem Service sind in einer unternehmensweiten SOA kritische Erfolgsfaktoren. Nur Dienste, deren Eigenschaften allen Beteiligten bekannt sind, können wiederverwendet werden (Vgl. Starke 2007, S. 21). Auffindbarkeit und Auffindbarkeit und

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Metainformationen gewinnen (In Anlehnung an Erl 2008, S. 378)

Die obige Abbildung 8 zeigt, wie Auffindbarkeit bereits während der serviceorientier­ten Analyse und in der Entwurfsphase verbessert werden kann.

2.4 Akteure und Rollen

Das Prinzip einer SOA basiert auf dem Zusammenspiel unterschiedlicher Akteure und den ihnen darin zugewiesenen Rollen als Service-Anbieter, Service-Nachfrager und

Service-Verzeichnisdienstleister. Dieses Beziehungsdreieck^[10], das unabhängig von der jeweiligen technologischen Plattform grundsätzlich entsteht, realisiert das Veröffent­lichen, Suchen und Anbinden von Diensten. In der folgenden Abbildung 9 wird dieser Zusammenhang anschaulich dargestellt. Der Service-Anbieter stellt Dienste innerhalb eines Netzwerks durch die Registrierung beim Service-Verzeichnisdienst für den öffent­lichen Zugriff bereit. Damit übernimmt er gleichzeitig die Verantwortung für die Ver­fügbarkeit und Wartung der Dienste und den sicheren Zugriff mit Authentifizierung^[11] und Authentizität^{[12] [13]} auf diese.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Magisches Dreieck der SOA (In Anlehnung an Melzer 2009, S. 12)

Das primäre Ziel des Service-Verzeichnisses13 ist die Bereitstellung aller erforderlichen Informationen für das automatisierte Auffinden von Diensten durch einen potenziellen Service-Nachfrager. Gleichzeitig stellt es technische Informationen über die Schnittstel­le des Dienstes bereit. Nach erfolgreicher Suche eines Dienstes erstellt der Service­Nachfrager einen Verweis (URL) zum Speicherort des Dienstes in seiner Client-Anwen­dung. Dieses Anbinden erlaubt dem Client die Verwendung (consume) aller vomjewei- ligen Dienst angebotenen (provide) Funktionen. An dieser Stelle sei nochmals darauf hingewiesen, dass es sich beim Anbinden um eine lose und nicht fest programmierte Verbindung handelt. Der Service-Anbieter kennt den Nachfrager normalerweise nicht, und eine Verbindung tritt erst dann zur Laufzeit in Kraft, wenn eine Funktion des Dienstes verwendet wird. (Vgl. Melzer 2009, S. 14f).

3 Serviceorientierung

3.1 Theorie der Serviceorientierung

Grundsätzlich basiert die Theorie der Serviceorientierung auf der Annahme, dass ein großes Problem besser lösbar wird, wenn man es in mehrere Teilaufgaben zerlegt^[14] und die erforderliche Logik zur Lösung jeder einzelnen Anforderung nach Fähigkeit unter­teilt (Vgl. Erl 2008, S. 86). Bezogen auf die technische Umsetzung eines komplexen Geschäftsprozesses bedeutet dies, dass dieser zunächst in kleinere Teilprozesse zerteilt würde, um dafür jeweils einen in sich abgeschlossenen Lösungsansatz zu entwickeln. Die sinnvolle Verkettung dieser, als Services entwickelten Teillösungen entspräche der Lösung des Gesamtproblems (Vgl. Erl 2008, S. 83f).

Der in diesem Zusammenhang als Kernelement der Serviceorientierung dienende Ser­vice (Dienst) ist kein IT-Begriff, sondern die Bezeichnung eines generellen Denkan­satzes und repräsentiert eine Ressource, die einen Output liefert, einen Input benötigt und deren Fähigkeiten klar definiert sind (Vgl. Eichhorst 2008, S. 1).

3.2 Definition aus Sicht des Service-Entwurfs

„Serviceorientierung ist ein Entwurfsparadigma, das aus einer bestimmten Menge von Entwurfsprinzipien besteht. Die Anwendung dieser Prinzipien auf den Entwurf der Lö­sungslogik führt zu einer serviceorientierten Lösungslogik. Die Basiseinheit der ser­viceorientierten Lösungslogik ist der Service.“ (Vgl. Erl 2008, S. 53)

3.3 Wurzeln der Serviceorientierung

Der serviceorientierte Entwurfsansatz ist das Resultat einer evolutionären Entwicklung der Informationstechnologie auf der Suche nach einem Weg zur Definition verteilter Lösungen und der Wahrung ihrer Konsistenz auch in verschiedenen Umgebungen. Ser­viceorientierung hat daher viele Wurzeln in älteren Paradigmen und Technologien.

[...]

---

^[1] Die Abkürzung SOAP wird offiziell seit der Version 1.2 nicht mehr als Akronym verwendet und steht nun als Begriff für sich selbst. (Vgl. World Wide Web Consortium (W3C) 2007, S. 1)

^[2] Die Häufigkeit des Auftretens zuvor festgelegter Kategorien im Text sind Quantifizierungen und ent­sprechen der methodologischen Annahme, dass es einen Zusammenhang zwischen der Häufigkeit und der Bedeutung des zugrunde liegenden Sachverhaltes gibt. (Vgl. Gläser 2009, S. 198)

^[3] „Die ... Methodenlehre teilt die Gütekriterien ein in Maße der Reliabilität (Zuverlässigkeit) ... und in Maße der Validität (Gültigkeit) ...“ (Vgl. Mayring 1988, S. 93)

^[4] Middleware ist eine Dienstleistungssoftware, die den Datenaustausch zwischen entkoppelten Soft­warekomponenten durch feste Point-To-Point-Verbindungen auf der Ebene ihrer Prozesse ermöglicht (Vgl. Starke 2007, S. 128).

^[5] Natürlich geht es bei der Kombination von Services immer darum, einen wohldefinierten Teilbereich eines Geschäftsprozesses abzubilden.

^[6] "In der Terminologie von SOA wird die Komposition neuer Services aus existierenden Services Orchestrierung genannt..." (Vgl. Josuttis 2009, S. 87).

^[7] Geschäftsprozesse werden auf der technischen Seite durch komponierte Services repräsentiert.

^[8] "Discovery ist der Prozess, einen Service zu finden, und Interpretation ist der Prozess, seinen Zweck und seine Fähigkeiten zu verstehen. Auffindbarkeit und Interpretierbarkeit sind Maße für die Fähig­keit eines Service, die Prozesse der Discovery und Interpretation zu unterstützen." (Vgl. Erl 2008, S. 370)

^[9] UDDI ist ein standardisierter Verzeichnisdienst, der die zentrale Rolle in einem Umfeld von dyna­mischen Webservices spielt.

^[10] Auch als „Magisches Dreieck einer SOA“ bezeichnet (Vgl. Melzer 2009, S. 12).

^[11] Authentifizierung regelt, dass der Zugriff auf Services und deren Informationen nur autorisierten Sub­jekten gestattet wird (Vgl. Starke et al. 2007, S. 257).

^[12] Authentizität ist die Voraussetzung für wechselseitiges Vertrauen über die Echtheit von Nutzern, An­bietern und den ausgetauschten Nachrichten (Vgl. Starke et al. 2007, S. 257).

^[13] Das Service-Verzeichnis wird in der Literatur auch als Registry oder Repository bezeichnet (Vgl. Melzer 2009, S. 14).

^[14] Separation of Concerns ist eine wissenschaftliche Theorie, in der verschiedene Elemente einer Auf­gabe in möglichst verschiedenen Elementen der Lösung repräsentiert sind.