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 Architekturen 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 Umsetzung 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 wesentlichen 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 Bausteine oder Orchestrierungen dieser, einen maximalen Grad an Wiederverwendbarkeit aufweisen. 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 erwartender wirtschaftlicher Nutzen einer Serviceorientierung abhängt. Die Produktion qualitativ hochwertiger Services darf nicht von glücklichen Umständen abhängen (Vgl. Erl 2008, S. 17), sondern muss im Rahmen festgelegter Regeln und standardisierter Vorgehensweisen betrieben und im Kontext einer SOA Governance fortlaufend kontrolliert werden (Vgl. Finger et al. 2009, S. 87).
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 Architekturen 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 Umsetzung 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 wesentlichen 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 Bausteine oder Orchestrierungen dieser, einen maximalen Grad an Wiederverwendbarkeit aufweisen. 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 erwartender wirtschaftlicher Nutzen einer Serviceorientierung abhängt. Die Produktion qualitativ hochwertiger Services darf nicht von glücklichen Umständen abhängen (Vgl. Erl 2008, S. 17), sondern muss im Rahmen festgelegter Regeln und standardisierter Vorgehensweisen 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 Unternehmens für oder wider einer SOA-Einführung mit langfristigen und oftmals beträ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 Allgemeinen 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 theoretische 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 Ausgangspunkt für die Entwicklung einer Untersuchungsstrategie, der Auswahl einer relevanten Analysemethode und der Selektion eines Teils des gesamten Untersuchungsgegenstandes (Vgl. Gläser 2009, S. 62).
Diesem Konzept folgend wird der Untersuchungsrahmen dieser Arbeit auf die „Relevanz von Entwurfs-Prinzipien “ eingegrenzt und dem gesamten Umfang angemessen, auf die Betrachtung des Service-Merkmals „ Wiederverwendbarkeit “ beschränkt. Entsprechend steht hier also folgende Fragestellung im Mittelpunkt der Untersuchung:
Welche Relevanz haben Entwurfsprinzipien in Unternehmen, den Grad der Wiederverwendbarkeit 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 allgemeingü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 Realisierung 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 Datenmaterials mit Hilfe von Experteninterviews, „in denen die Befragten als Spezialisten für bestimmte Konstellationen befragt werden ...“ (Vgl. Gläser 2009, S. 12) und der „Qualitativen 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 Beeinflussung des Wiederverwendungsgrades von Services in der Praxis nachzuweisen ist.
Die Aussagekraft auch qualitativer Untersuchungen[2] erfordert eine Mindestmenge auswertbaren 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öglichkeit einer im größeren Stil angelegten Untersuchung dieser Fragestellung zu dienen. Dementsprechend liegt der Schwerpunkt auf der Erarbeitung eines strukturierten Untersuchungsverfahrens, dass sich an den klassischen Gütekriterien[3] qualitativer Inhaltsanalyse orientiert.
2 Serviceorientierte Architektur
2.1 Schlüsselkonzepte einer SOA
Die im ersten Kapitel formulierten Herausforderungen an das Management von Geschäftsprozessen führen im Bestreben einer konsequenten Umsetzung zu einem neuen Denkansatz in der Softwarearchitektur, der auf den Schlüsselkonzepten AnwendungsFrontend, 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 vorhandener 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 Informationssysteme durch lose miteinander verbundener Services zu ersetzen, die es erlauben Business-Anforderungen im Idealfall automatisiert und somit zeitnah zu realisieren, stellt das Credo einer SOA dar und kann es leisten, die Kluft zwischen betriebswirtschaftlicher 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 Anwendungen aufgelöst, um indirekt über eine Vermittlungsschicht (Enterprise-Service-Bus) verbunden zu werden. Diese serviceorientierte Grundforderung nach einer lose gekoppelten Anwendungslandschaft erlaubt esjeder angeschlossenen Komponente, Daten und Funktionen anderer Komponenten zu verwenden. Neben einer besseren Übersichtlichkeit 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 einsetzen 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 Perspektive 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 Flexibilität innerhalb einer Software-Architektur (Vgl. Finger et al. 2009, S. 7). Lose Kopplung und damit Unabhängigkeit der beteiligten Softwarekomponenten wird erreicht, wenn die Implementierung der eigentlichen Programmfunktionalität nach außen gekapselt (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 Anwendungslandschaft 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 Technologien gekennzeichnet, die durch historische Gegebenheiten, persönliche Vorlieben, Geschä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ösungsansä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, sondern 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 Abbildung 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 fundamentales 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 Interoperabilitä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 Umgebungen vor Augen hält, in dem unterschiedliche Geschäftsprozesse durch Wiederverwendung 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 entwickelt wird und hält einem Vergleich mit der kommerziellen Entwicklung von Massenprodukten 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 erforderlich, wobei die Herausforderung nicht darin zu sehen ist, absolute Wiederverwendung 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 Wiederverwendung 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 Geschäftsprozesse sind die Verringerung der zu pflegenden Lösungslogik und eine kontinuierliche 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 wiederverwendbarer 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ückfü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 werden 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 Erfüllung einer Teilaufgabe kombinieren, und das Resultat ihres Dienstes, wie in Abbildung 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 Services erfolgt durch speziell für diese Aufgabe entwickelte Anwendungen, die eine Modellierung 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 Orchestrierungsebene 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, standardisierten 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 Funktionen 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 Speicherung und zum Provider des Dienstes, sowie technische Beschränkungen und Transaktions- 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 Metainformationen konsistent zu dokumentieren, weil in der frühen Phase der Modellierung Geschä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 serviceorientierten 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öffentlichen, 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 öffentlichen Zugriff bereit. Damit übernimmt er gleichzeitig die Verantwortung für die Verfü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 Schnittstelle des Dienstes bereit. Nach erfolgreicher Suche eines Dienstes erstellt der ServiceNachfrager einen Verweis (URL) zum Speicherort des Dienstes in seiner Client-Anwendung. 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 unterteilt (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 Service (Dienst) ist kein IT-Begriff, sondern die Bezeichnung eines generellen Denkansatzes 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 serviceorientierten 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. Serviceorientierung 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 entsprechen 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 Softwarekomponenten 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ähigkeit 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 dynamischen 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 Subjekten gestattet wird (Vgl. Starke et al. 2007, S. 257).
[12] Authentizität ist die Voraussetzung für wechselseitiges Vertrauen über die Echtheit von Nutzern, Anbietern 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 Aufgabe in möglichst verschiedenen Elementen der Lösung repräsentiert sind.
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.