- II - SOKRATES:"Wenn man nun von den Urbestandteilen und Verknüpfungen, deren wir selbst erfahren sind, auch auf die anderen schließen darf, so werden wir sagen müs-sen, daß die Erkenntnis der Urbestandteile viel deutlicher sei und viel wirksamer, als die der Verknüpfungen, um jegliche Sache vollkommen zu erlernen. Und wenn jemand sagt, die Verknüpfung sei ihrer Natur nach erkennbar, der Urbestandteil aber nicht, so wollen wir dafürhalten, er treibe Scherz, es sei nun wissentlich oder unwissentlich". (Platon, Theaitetos) 1

Für Aaron, den kleinen Teil, der erst das große Ganze ausmacht.

¹ Platon, Theaitetos 2005, S. 203.

- III -

Inhaltsverzeichnis

Inhaltsverzeichnis.   III

Abk  ürzungen  IV

Abbildungs  - und Tabellenverzeichnis  VI

1  Einleitung  1

1.1  Problemstellung.  1

1.2  Zielsetzung  2

1.3  Aufbau der Arbeit.  3

2  Service-Orientierte Architekturen.  4

2.1  Definition und Ziele einer SOA  4

2.2  Struktur einer SOA  5

2.3  Technologische Abgrenzungen  9

3  Merkmale der Granularität  11

3.1  Definition der Granularität.  11

3.2  Arten und Ausprägungen der Granularität.  11

3.2.1  Funktionale Granularität  11

3.2.2  Schnittstellen- oder Datengranularität  13

3.2.3  Granularitätsgrade.  14

4  Instrumente zur Bestimmung der Granularität  16

4.1  Bestimmungsfaktoren.  16

4.1.1  Zielsetzungen der Bestimmungsfaktoren  16

4.1.2  Wiederverwendbarkeit.  16

4.1.3  Flexibilität.  18

4.1.4  Kommunikation.  20

4.1.5  Geschäftswert.  22

4.2  Mittel zur Bestimmung der Granularität  24

4.2.1  Wirkung von Architektur-Design-Prinzipien  24

4.2.2  Kopplung und Kohäsion  25

4.2.3  Trennung der Zuständigkeiten.  27

4.2.4  Abstraktion und Kapselung.  28

4.2.5  Modularität und Autonomie.  29

4.3  Verfahren zur Bestimmung der Granularität von Diensten.  30

4.3.1  Metriken der Granularität.  30

4.3.2  Prozess zur Dienstidentifikation  33

5  Vergleich mit früheren Software-Engineering-Paradigmen.  37

5.1  Evolution zur SOA  37

5.2  Objektorientierung  38

5.3  Komponentenorientierung  39

5.4  Gemeinsamkeiten und Unterschiede der SE-Paradigmen.  40

6  Die Bestimmung der Granularität in der Praxis.  42

6.1  Fallstudie zur Bedeutung der Granularität von Diensten.  42

6.2  Ergebnisse der Fallstudie und Bedeutung für die Praxis.  43

7  Resümee und Ausblick  46

Anhang.   51

Glossar.   64

Literaturverzeichnis   65

Anlage   74

Anm. d. Verf. Anmerkung des Verfassers

BPM Business Process Management

BPMN Business Process Modelling Notation

CDOS Context Dependence of Operations

CORBA Common Object Request Broker Architecture

COTS Commercial of the Shelf

CRUDS Create, Read, Update, Delete, Search

DAS Domains Affected by the Services

DCCS Domains Completely Covered by the Services

DCE Distributed Computing Environment,

DGOS Data-oriented Granularity of Operations of Services

EAI Enterprise Applikation Integration

EPK Ereignis Prozessketten

et al. und andere

GQM Goal Question Metric

i.S.v. im Sinne von

IS Informationssystem

IT Informationstechnologie

JS Java Skript

o.S. Ohne Seitenangabe

o.V. ohne Verfasser

OASIS Organization for the Advancement of Structured Information Standards

OOD Objektorientiertes Design

- V - OSGi Open Services Gateway initiative

RPC Remote Procedure Call

SE Software-Engineering

SOA Service Orientierte Architektur

SOAP Simple Object Access Protocol

u. a. unter anderem

Ü. d. Verf. Übersetzung des Verfassers

u.U. Unter Umständen

USD Dollar, Währung der Vereinigten Staaten von Amerika

W3C World Wide Web Consortium

WAN Wide Area Network

wörtl. wörtlich

WSDL Web Service Discription Language

XML Extensible Markup Language

- VI -

Abbildungs  - und Tabellenverzeichnis  

Abbildung  1: Dienst Architekturstruktur  

Abbildung  2: Die wichtigsten Gesichtspunkte einer Referenzarchitektur  

Abbildung  3: Beispiel einer Diensthierarchie  

Abbildung  4: Architekturbeispiel Legacy Anbindung  

Abbildung  5: Granualritätsebenen  

Abbildung  6: Prinzipien und deren Wirkungszusammenhänge  

Abbildung  7: Kopplung und Kohäsion  

Abbildung  8: Grafik zur Tabelle 3  

Abbildung  9: Client-Server Modell  

Abbildung  10: Kontexbezug von Diensten  

Abbildung  11: Cloud Services Modell  

Abbildung  12: Beispiel Aufruf eines Clouds  

Abbildung  13: Beispiel von Ausprägungen der Granularitätsarten  

Abbildung  14: Multigranularer Dienst  

Abbildung  15: Beispiel Texuteller Geschäftsprozess  

Abbildung  16: Beispiel Darstellung eines Geschäftsprozesses  

Tabelle 1:  Beispiel Beschreibung von Diensttypen  

Tabelle 2:  Vergleich von Webservice-Typen  

Tabelle 3:  Interpretation von Granularitätsmetriken  

- 1 - 1Einleitung

1.1 Problemstellung

Die Investitionen für Informationstechnologie (IT) in den Unternehmen werden gezielter für Zukunftsprojekte eingesetzt und weniger für den laufenden Betrieb, so fasste das Handelsblatt ² vor einiger Zeit eine aktuelle Studie zu den IT-Budgets zusammen. Im Vordergrund stehen dabei Zukunftsprojekte zur weiterführenden Prozessautomatisierung und zur Stückkostenreduzierung. Dies ist in Anbetracht des immer stärker werdenden Preisdruckes in vielen Branchen und in Zeiten der Globalisierung häufig auch die einzige Möglichkeit, im Wettbewerb zu bestehen. Für Hochlohnländer wie Deutschland ist die Produktivität und damit die Effizienz entscheidend und ein wesentlicher Erfolgsfaktor.

Derartige Wettbewerbsvorteile können durch Innovation und Kosteneinsparungen erreicht werden. „Wir müssen so viel besser sein, wie wir teurer sind. Das ist das, was uns leiten muss“ ³ , unterstrich Bundeskanzlerin Dr. Angela Merkel anlässlich der Eröffnung der IAA im Jahre 2007. Dies gilt insbesondere auch für die Effizienz der Prozessabläufe in den Unternehmen. Mit Stundenlöhnen für Hochlohngruppen, wie z. B. einen Ingenieur, von etwa 2,6 USD in Rumänien oder sogar 2,4 USD in Indien kann Deutschland auf Dauer nur konkurrieren, wenn die Abläufe und damit die Geschäftsprozesse kosteneffizient sind ⁴ .

Die Computerwoche führte in diesem Zusammenhang und ebenfalls mit Bezug zu einer anderen europaweit durchgeführten Studie an, dass Service Orientierte Architekturen (SOA), eine wesentliche Voraussetzung für eine Prozessautomatisierung darstellen ⁵ . Ihre Bedeutung nahm in den letzten Jahren kontinuierlich zu ⁶ .

Dabei geht es weiterhin auch darum, die Vielzahl unterschiedlicher Software-basierter Anwendungen in einem Unternehmen zu reduzieren, bzw. in die Geschäftsprozesse sinnvoll zu integrieren. Allerdings müssen SOA eine erkennbare Rentabilität aufweisen, damit sie einen Nutzen bringen ⁷ .

Doch leider bleibt dieser Nutzen oftmals aus. Viele SOA- Projekte bleiben weit hinter den Erwartungen zurück oder scheitern gänzlich ⁸ . Die Gründe hierfür liegen laut Frank Leymann, Professor an der Universität Stuttgart, in der unzureichenden "Festlegung der Granularität der Dienste, ihren nichtfunktionalen Eigenschaften und der Governance" ⁹ .

² Vgl. Koenen J., IT-Investitionen 2009, o.S.

³ Merkel, A. Bulletin 2007, Nr. 93-3.

⁴ Quelle: ECIN 2008.

⁵ Vgl. Schaffry, A., IT-Budget 2009, o.S.

⁶ Vgl. Heckel, R., Architectural Transformations, 2008, S. 139.

⁷ Vgl. Lochmaier, L., Mittelständler 2009, o.S.

⁸ Vgl. Pütter, C., Scheitern von SOA 2009, o.S.

⁹ Leymann, F., zitiert nach Ramspeck, J., SOA Fehlerquellen 2008, o.S.

- 2 - DieBestimmung der optimalen Granularität der Dienste ist somit ein entscheidender Erfolgsfaktor bei der Umsetzung einer SOA ¹⁰ .

1.2 Zielsetzung

Bei der Betrachtung von Ansätzen zur Bestimmung der Granularität einer SOA werden zwei zentrale Fragen vorangestellt:

1. Wie kann die optimale Granularität einer Service Orientierten Architektur bestimmt werden?

2. Welche Lösungsansätze, bzw. Konzepte werden zur Bestimmung der Granularität zur Verfügung gestellt?

Das Ziel dieser Arbeit liegt vor allem in der Erörterung der unterschiedlichen Gesichtspunkte der Ansätze zur Bestimmung der optimalen Granularität, um das Thema in seiner Breite und Tiefe möglichst umfassend darstellen zu können. Das Ergebnis soll ein Rahmenkonzept sein, in dem Methoden und Vorgehensweisen über alle Zwischenschritte bis hin zu den Wirkungen skizziert sind.

Demnach ist im Sinne des Titels dieser Arbeit ein Konzept eine methodisch entwickelte und in sich schlüssige Technik, bzw. Heuristik zur Bestimmung der Granularität einer SOA.

Hiervon ausgehend ergeben sich weitere Fragestellungen: Warum und wofür ist die Granularität wichtig oder gar entscheidend? Was sind die Einflussfaktoren auf die Granularität? Welche Auswirkungen hat eine unzureichende, bzw. optimale Granularität auf eine SOA? Mit welchen Mitteln wird die Granularität realisiert? Kann Granularität gemessen werden, und wenn ja, wie? Und: Was bedeutet dies für den Erfolg oder Misserfolg in einem Projekt? Eine weitere Fragestellung ist, in wieweit sich ein Dienst hinsichtlich seiner Granularität von einem Modul und/oder einem Objekt unterscheidet.

Weiterhin soll die Bestimmung der Granularität Service Orientierter Architekturen in der Praxis anhand einer Fallstudie dargestellt werden.

Die aufgetretenen Probleme und labilen Punkte bei der Bestimmung der Granularität einer Service Orientierten Architektur und die positiven Erfahrungen bieten sodann eine Grundlage für die Einführung des Konzeptes in den Unternehmen.

Die qualitative Analyse, Planung und Bewertung einer SOA steht nicht im Mittelpunkt dieser Arbeit, da dies über den gesetzten Rahmen hinausgehen würde.

¹⁰ Vgl. von Henning, H., Service-Granularität 2007, S. 343.

- 3 - 1.3Aufbau der Arbeit

Um die Bestimmung der Granularität von Diensten Service Orientierter Architekturen in ihrer Breite und Tiefe erörtern zu können, werden die einzelnen Sachverhalte der konzeptionellen Ansätze herausgearbeitet. Hierzu werden zunächst allgemeine Grundlagen einer SOA dargestellt, da das Paradigma Service Orientierte Architektur in der Literatur nicht einheitlich verwendet wird. Das erste Kapitel liefert die Grundlage für ein erforderliches Verständnis des Themas.

Daran anschließend wird eine wesentliche Vorstellung vom Begriff Granularität entwickelt, indem der abstrakte Begriff Granularität genauer bestimmt und in Bezug auf Service Orientierte Architekturen erklärt, strukturiert und gegliedert wird. Dieses Kapitel bildet dadurch die Voraussetzung für die weitere Bearbeitung des Themas.

Im nächsten Schritt, dem Kapitel vier, werden die Methoden und Mittel zur Bestimmung der optimalen Granularität aufgezeigt und erläutert. Dabei sollen die Hauptfragestellungen aus der Einleitung aufgenommen und systematisch und nachvollziehbar be-handelt sowie die Zusammenhänge aufgezeigt werden. Anhand dessen ist eine Bestimmung der optimalen Granularität mit den dargestellten Wirkungskriterien und ihren Zusammenhängen möglich. Dieses Kapitel bildet den Schwerpunkt der Arbeit.

Nachfolgend werden im fünften Kapitel die Unterschiede zur Objekt- und Komponentenorientierung untersucht und zu den zuvor gezeigten Kriterien und Zusammenhängen in Bezug gesetzt. Dabei werden die Bestimmungsfaktoren und deren Wirkungszusammenhänge zur Bestimmung der optimalen Granularität mit früheren Software-Engineering-Paradigmen (SE-Paradigmen) verglichen und Gemeinsamkeiten und Unterschiede aufgezeigt. Der Veränderungsprozess der SE-Paradigmen, seine Ursachen und deren Bedeutung für die Granularität einer Software-Architektur sollen in diesem Kapitel ebenfalls angerissen werden.

Im sechsten Kapitel wird eine Fallstudie zur Bestimmung der Granularität vorgestellt und es werden die Ergebnisse und ihre Bedeutung für die Praxis erörtert.

Das siebte Kapitel bildet mit dem Resümee und einem Ausblick den Abschluss der Arbeit.

- 4 - 2Service-Orientierte Architekturen

2.1 Definition und Ziele einer SOA

Der Begriff Service-Orientierung und die daraus entstandene Service-Orientierte Architektur wird in der Literatur nicht einheitlich verwendet ¹¹ . Der Service-Orientierung liegt aber trotz unterschiedlicher Schwerpunkte der Autoren ein Paradigma zugrunde, das Wertvorstellungen und Techniken definiert. Es stellt damit einen Abgleich von unterschiedlichen Beurteilungen und Erfahrungen dar und liefert die notwendige Orientierung ¹² . Eine geeignete und häufige Definition wird neben vielen anderen Autoren u.a. auch von Masak verwendet. Eine SOA modelliert nach ihm “die gesamte Organisation als eine Ansammlung von Services, welche über die Organisation verteilt und jedem zugänglich sind“ ¹³ . Weitere Definitionen zur SOA führt Heutschi auf und stellt zusammenfassend eine eigene generische Begriffserläuterung auf. Eine SOA ist bei ihm „eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt und dabei bestimmte Designprinzipien berücksichtigt“ ¹⁴ . Die OASIS (Organization for the Advancement of Structured Information Standards) erklärt SOA als "Paradigma zur Organisation und Nutzung der verteilten Ressourcen, bzw. Fähigkeiten, die gegebenenfalls zu verschiedenen Bereichen gehören und von diesen kontrolliert werden" ¹⁵ .

Die Services bzw. Dienste einer SOA sind eigenständige funktionale Einheiten, die als Dienstgeber (Service Provider) mittels eines Vertrages (Service Contract) mit einem Dienstnehmer (Service Consumer) interagieren. Ein Dienstvertrag ist die Definition eines Dienstes. Er beschreibt die erforderliche Schnittstelle und die Daten zur Verwendung der einzelnen Dienste ¹⁶ .

Die von Masak, Heutschi und Finger verwendeten Definitionen für eine SOA haben sich bei der in dieser Arbeit zugrunde liegenden Literatur als die größte Schnittmenge und die am häufigsten verwendeten herauskristallisiert. Sie bilden deshalb die Grundlage zur weiteren Bearbeitung des Themas. Je nach Schwerpunkt des Einsatzes einer SOA ergeben sich verschiedene aufeinander aufbauende Sichtweisen: Eine SOA kann überblicksartig als eine:

o Komponentenarchitektur, die Bausteine in Form von Diensten bereitstellt,

o Integrationsarchitektur, die bestehende Anwendungen in einem Unternehmen durch eine asynchrone nachrichtenbasierte Kommunikation miteinander ver-

¹¹ Vgl.Masak, D., SOA 2007, S. 8.

¹² Vgl. Kuhn, T., wissenschaftliche Revolutionen 1976, S. 25ff.

¹³ Masak, D., It-alignment 2007, S. 112.

¹⁴ Heutschi, R., Service Orientierte Architektur 2007, S. 21ff.

¹⁵ OASIS, Reference Model 2006, S. 8. Ü. d. Verf., Originaltext: "Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains."

¹⁶ Vgl. Finger, P., et al., SOA Webservices 2009, S. 11.

- 5 - bindetund die so genannte Enterprise Applikation Integration (EAI) zu einer Unternehmensanwendung integriert,

o geschäftsprozessgetriebene Architektur, die innerhalb vom so genannten Business Prozess Management (BPM)-Ansatz Dienste aus Prozessen ableitet,

angesehen werden ¹⁷ .

Infolgedessen ist es das Ziel einer SOA, „eine an den Geschäftsprozessen ausgerichtete IT, die schnell auf Veränderungen reagieren kann“ ¹⁸ , bereitzustellen. Zur Vermeidung von Redundanzen werden hierzu dieselben Dienste in verschiedenen Kontexten eingesetzt und somit wiederverwendet.

2.2 Struktur einer SOA

Dienste einer SOA zeichnen sich durch eine Reihe von Eigenschaften aus. So sind sie von einander unabhängig und stellen nur eine bestimmte Funktionalität, nach innen gekapselt und nach außen über eine definierte Schnittstelle abstrahiert, zur Verfügung ¹⁹ .

Aus der Dienstdefinition ergeben sich weitere Eigenschaften, wie: 20

o der Grad an Autonomie.

o die genaue Grenze zwischen System und Umgebung, die durch die Schnittstelle gebildet wird.

o der Umstand, dass Dienstnutzer und Dienstanbieter keine Kenntnis von-einander haben. Aus diesem Grund besteht zwischen den beiden eine so genannte 'lose Bindung'. Der Dienstanbieter stellt den Zugriff über ein Netzwerk auf mindestens einen Dienst zur Verfügung. Die Kommunikation erfolgt über ein Protokoll, welches beiden bekannt ist ²¹ .

Service-orientierte Architekturen sind wie andere Software-Architekturen auch in Schichten, so genannten Layern strukturiert. Solche Schichten bilden eine Art Grenzlinie zwischen zusammengehörenden Funktionsteilen. Eine derartige Schichtenbildung ist in Abbildung 1 erkennbar.

¹⁷ Vgl., Völter, M., Modelle 2007, S. 423ff.

¹⁸ Buchmann, J., et al., Governance Modell 2008, S. 154.

¹⁹ Vgl., Burbiel, H., Webservices Praxis 2007, S. 481.

²⁰ Vgl. Masak, D., SOA 2007, S. 18ff.

²¹ Vgl. Melzer, I., SOA Web Services 2007, S. 14ff.

Dem Prinzip nach bauen die einzelnen Schichten aufeinander auf. Die Implementierung einer Schicht kann nur auf die Schnittstellen der nächsten darunter liegenden Schicht zugreifen ²³ . Rosen schlägt zur Strukturierung einer SOA in einer Organisation eine SOA-Referenzarchitektur vor. Solche abstrakten Grundkonstruktionen beschreiben Software-Elemente für einen gesamten Anwendungsbereich. Sie legen u.a. auch die zulässigen Beziehungen und die Kommunikation der Elemente fest. Referenzarchitekturen werden bereits zu Beginn der Einführung einer SOA erstellt und eignen sich besonders zur späteren Validierung einer SOA ²⁴ . Zur ihrer Erstellung werden Arten von Diensten definiert und klassifiziert sowie eine Hierarchie der Dienste beschrieben. Ferner wird dargelegt, wie Dienste in die bestehende Applikationslandschaft einfügt werden ²⁵ .

²² Eigene Darstellung in Anlehnung an Heutschi, R. Service Orientierte Architektur 2007, S. 27.

²³ Vgl. Szyperski, C., Component Software 2002, S. 162f.

²⁴ Vgl. Beneken, G., Referenzarchitekturen 2006, S. 375.

²⁵ Vgl. Rosen, M. et al., Applied SOA 2008, S. 18f.

Abbildung 2: Die wichtigsten Gesichtspunkte einer Referenzarchitektur 26

Dienste kapseln außerdem Funktionalität in Bezug zu einem bestimmten Kontext. Der Kontext kann z. B. aus einer Zusammenfassung mehrerer Geschäftsprozessschritte zu einer Einheit bestehen oder aus z. B. nur einem Schritt. Der Kontextumfang kann folglich beliebig groß sein ²⁷ . Die jeweiligen Kontexte können, in Abhängigkeit von der Zielsetzung, zu Klassen mit gleicher Ausrichtung zusammengefasst werden, so dass unterschiedliche Typen von Diensten entstehen. Werden diese Diensttypen je nach Verwendungszweck abstrahiert, entstehen unterschiedliche Ebenen bzw. Schichten von Diensttypen oder eine so genannte Diensthierarchie.

²⁶ Vgl. Rosen, M. et al., a.a.O., S. 19.

²⁷ Vgl. Anhang 1.

Diese Diensttypen haben unterschiedliche Beziehungen zueinander.

Die Architektur der Service-Orientierung ermöglicht es außerdem, etwas zu einem externen Vertragspartner auszulagern. Ziel dieser Auslagerung, die auch als 'Cloud Computing' bezeichnet wird, ist es in erster Linie, Kosteneinsparungen zu realisieren und eine Vereinheitlichung des Zugriffs zu ermöglichen ³⁰ .

Aber auch bereits bestehende IS-Anwendungen, die so genannten Legacy-Systeme, sind in der Regel im Unternehmen einzubeziehen. Die Anbindung erfolgt über Adapterobjekte, die so genannten Wrapper ³¹ . Der Nachrichtenaustausch ist dann z. B. XML-basiert.

²⁸ Vgl. Kulkarni, N., et al., Service Granularity Role 2008, S.425.

²⁹ Quelle: Kulkarni, N., et al. a.a.O., S.425.

³⁰ Vgl. o.V., Cloud Computing 2009, S. 2., vgl. Anhang 2.

³¹ Vgl. Gamma, E. et al., Entwurfsmuster 1996, S. 172.

Werden Dienste aus bestehenden Diensten zusammengesetzt, bei denen ein Dienst oder Prozess die Kontrolle ausübt, so wird dies als Orchestrierung bezeichnet ³³ . Hingegen wird von Choreografie gesprochen, wenn Dienste zu einem neuen Geschäftsprozess zusammengefasst werden ³⁴ .

2.3 Technologische Abgrenzungen

In den letzten Jahren konnten sich so genannte 'Webservices' als SOA-Technologiestandards zunehmend durchsetzen. Sie sind durch das World Wide Web Consortium (W3C) standardisiert, basieren auf der Extensible Markup Language (XML) ³⁵ und sind plattformunabhängig ³⁶ .

Das Konzept eines Dienstes kann in der konkreten Implementierung einem Webservice entsprechen. Die notwendige Dienstbeschreibung erfolgt in der so genannten Webservice Definition Language, einer ebenfalls XML-basierten Notation ³⁷ .

Webservices basieren auf ähnlichen Eigenschaften wie das Internet. Der Aufruf eines Webservice erfolgt mittels einer POST-Methode über HTTP. Der Aufruf (Request) enthält eine SOAP-Meldung, welche die notwendigen Aufrufparameter enthält. SOAP entkoppelt das Datenformat und das darunter liegende HTTP-Protokoll durch die Verwendung der plattformunabhängigen XML. Das HTTP dient dabei als standardisiertes Transportprotokoll für den Nachrichtenaustausch über das Netz. Die Verbindung

³² Vgl. Schmietendorf, I., et al., Industrial Web Services Granularity 2007, S. 94.

³³ Vgl. Masak, D., SOA 2007, S. 106.

³⁴ Vgl. Schill, A. et al., Verteilte Systeme 2007, S. 20.

³⁵ Vgl. Liebhart, D. et al. Architecture Blueprints 2007, S. 292.

³⁶ Vgl. Finger. P., et al., SOA Webservices 2009, S. 37.

³⁷ Vgl. Erl, T., Service-Oriented Architecture 2004, S. 50.

- 10 - zwischenzwei Punkten wird über TCP/IP hergestellt ³⁸ . Die Interaktion kann bei einem Webservice synchron oder asynchron erfolgen. Erfolgt der Aufruf synchron, so dient das HTTP als Transportprotokoll für die so genannten XML-basierten Remote Procedure Call (RPC)-Transaktionen. Der Client übergibt mit dem Aufruf die einzelnen geforderten Eingabedaten und erhält mit der Antwort einem Wert zurück. Als synchron wird dieser Aufruf bezeichnet, weil die Weiterverarbeitung erst dann fortgesetzt wird, wenn der Dienstnutzer eine Antwort erhält. ³⁹ Hingegen wird bei einem Aufruf eines asynchronen Dienstes ein Datendokument übergeben, das sämtliche Informationen enthält und nicht eine Anzahl von Einzelparametern. Ein solches Dokument kann z.B. eine komplette Auftragsbearbeitung beinhalten. Der Dienst empfängt die Nachricht und verarbeitet sie. Eine Antwort muss nicht abgewartet werden. Solche asynchronen Dienste werden auch als dokumenten- oder nachrichtenbasiert bezeichnet. 40

Neben Webservices besteht aber grundsätzlich auch die Möglichkeit, eine SOA mit Hilfe anderer Technologien, wie z. B. CORBA, DCE, JINI/JS, OSGi und MQSERIES, zu realisieren ⁴² . Allerdings sind CORBA und z. B. auch Java RMI für eine SOA nur bedingt geeignet, da die miteinander kommunizierenden Elemente unbedingt kompatibel zueinander sein müssen ⁴³ . Dies widerspricht dem Grundsatz, dass Dienste sich nicht gegenseitig kennen müssen ⁴⁴ .

Anzumerken ist, dass Technologien bei der Sicht auf eine SOA eine untergeordnete Rolle spielen. Das zugrunde liegende Basiskonzept ist die Prozessorientierung ⁴⁵ . Zur Realisierung einer SOA sind sie dennoch notwendig.

³⁸ Vgl. McGovern J., et al., Java Web Service Architecture 2003, S. 99. Anm. d. Verf.: Erläuterung zu den Begriffen siehe Glossar.

³⁹ Vgl. Papazoglou, M., Web Services Principles 2008, S. 18.

⁴⁰ Vgl. Papazoglou, M., a.a.O., S. 18.

⁴¹ Vgl. Jankovska A., et al., SOA Mobile Access 2005, S. 374.

⁴² Vgl. Weinaug, H. et al., Web Support 2008, S. 224.

⁴³ Vgl. Karakostas, B. et al., Engineering Service Oriented Systems 2008, S. 272

⁴⁴ Anm. d. Verf. Ein Vergleich der einzelnen Technologien zur Umsetzung einer SOA würde über den gesetzten Rahmen dieser Arbeit hinausgehen.

⁴⁵ Vgl. Schill, A. et al., Verteilte Systeme 2007, S. 20.