Ansätze zur Bestimmung einer optimalen Granularität von Diensten in einer Service Orientierten Architektur

Inhaltsverzeichnis

Abkürzungen

Abbildungs- und Tabellenverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung
1.3 Aufbau der Arbeit

2 Service-Orientierte Architekturen
2.1 Definition und Ziele einer SOA
2.2 Struktur einer SOA
2.3 Technologische Abgrenzungen

3 Merkmale der Granularität
3.1 Definition der Granularität
3.2 Arten und Ausprägungen der Granularität
3.2.1 Funktionale Granularität
3.2.2 Schnittstellen- oder Datengranularität
3.2.3 Granularitätsgrade

4 Instrumente zur Bestimmung der Granularität
4.1 Bestimmungsfaktoren
4.1.1 Zielsetzungen der Bestimmungsfaktoren
4.1.2 Wiederverwendbarkeit
4.1.3 Flexibilität
4.1.4 Kommunikation
4.1.5 Geschäftswert
4.2 Mittel zur Bestimmung der Granularität
4.2.1 Wirkung von Architektur-Design-Prinzipien
4.2.2 Kopplung und Kohäsion
4.2.3 Trennung der Zuständigkeiten
4.2.4 Abstraktion und Kapselung
4.2.5 Modularität und Autonomie
4.3 Verfahren zur Bestimmung der Granularität von Diensten
4.3.1 Metriken der Granularität
4.3.2 Prozess zur Dienstidentifikation

5 Vergleich mit früheren Software-Engineering-Paradigmen
5.1 Evolution zur SOA
5.2 Objektorientierung
5.3 Komponentenorientierung
5.4 Gemeinsamkeiten und Unterschiede der SE-Paradigmen

6 Die Bestimmung der Granularität in der Praxis
6.1 Fallstudie zur Bedeutung der Granularität von Diensten
6.2 Ergebnisse der Fallstudie und Bedeutung für die Praxis

7 Resümee und Ausblick

Anhang

Glossar

Literaturverzeichnis

Anlage

Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

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 Einleitung

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^[2] vor einiger Zeit eine aktuelle Studie zu den IT-Budgets zusammen. Im Vordergrund stehen dabei Zukunftsprojekte zur weiterführenden Prozessauto- matisierung 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 wesent- licher Erfolgsfaktor.

Derartige Wettbewerbsvorteile können durch Innovation und Kosteneinsparungen er- reicht werden. „Wir müssen so viel besser sein, wie wir teurer sind. Das ist das, was uns leiten muss“^[3], 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^[4].

Die Computerwoche führte in diesem Zusammenhang und ebenfalls mit Bezug zu einer anderen europaweit durchgeführten Studie an, dass Service Orientierte Archi- tekturen (SOA), eine wesentliche Voraussetzung für eine Prozessautomatisierung darstellen^[5]. Ihre Bedeutung nahm in den letzten Jahren kontinuierlich zu^[6].

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^[7].

Doch leider bleibt dieser Nutzen oftmals aus. Viele SOA- Projekte bleiben weit hinter den Erwartungen zurück oder scheitern gänzlich^[8]. 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"^[9].

Die Bestimmung der optimalen Granularität der Dienste ist somit ein entscheidender Erfolgsfaktor bei der Umsetzung einer SOA^[10].

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.

1.3 Aufbau 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 ent- wickelt, 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 Hauptfrage- stellungen aus der Einleitung aufgenommen und systematisch und nachvollziehbar be- handelt sowie die Zusammenhänge aufgezeigt werden. Anhand dessen ist eine Be- stimmung 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 Zu- sammenhä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.

2 Service-Orientierte Architekturen

2.1 Definition und Ziele einer SOA

Der Begriff Service-Orientierung und die daraus entstandene Service-Orientierte Archi- tektur wird in der Literatur nicht einheitlich verwendet^[11]. Der Service-Orientierung liegt aber trotz unterschiedlicher Schwerpunkte der Autoren ein Paradigma zugrunde, das Wertvorstellungen und Techniken definiert. Es stellt damit einen Abgleich von unter- schiedlichen Beurteilungen und Erfahrungen dar und liefert die notwendige Orientierung^[12]. 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“^[13]. 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“^[14]. Die OASIS (Organization for the Advancement of Structured Information Standards) erklärt SOA als "Paradigma zur Organisation und Nutzung der verteilten Ressourcen, bzw. Fähig- keiten, die gegebenenfalls zu verschiedenen Bereichen gehören und von diesen kontrolliert werden"^[15].

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^[16].

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 Grund- lage zur weiteren Bearbeitung des Themas. Je nach Schwerpunkt des Einsatzes einer SOA ergeben sich verschiedene aufeinander aufbauende Sichtweisen: Eine SOA kann überblicksartig als eine:

- Komponentenarchitektur, die Bausteine in Form von Diensten bereitstellt,
- Integrationsarchitektur, die bestehende Anwendungen in einem Unternehmen durch eine asynchrone nachrichtenbasierte Kommunikation miteinander verbindet und die so genannte Enterprise Applikation Integration (EAI) zu einer Unternehmensanwendung integriert,
- geschäftsprozessgetriebene Architektur, die innerhalb vom so genannten

Business Prozess Management (BPM)-Ansatz Dienste aus Prozessen ableitet, angesehen werden^[17].

Infolgedessen ist es das Ziel einer SOA, „eine an den Geschäftsprozessen aus- gerichtete IT, die schnell auf Veränderungen reagieren kann“^[18], 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 Ver- fügung^[19].

Aus der Dienstdefinition ergeben sich weitere Eigenschaften, wie:^[20]

- der Grad an Autonomie.
- die genaue Grenze zwischen System und Umgebung, die durch die Schnitt- stelle gebildet wird.
- 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^[21].

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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Dienst Architekturstruktur^[22]

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^[23]. Rosen schlägt zur Strukturierung einer SOA in einer Organisation eine SOA-Referenzarchitektur vor. Solche abstrakten Grund- konstruktionen beschreiben Software-Elemente für einen gesamten Anwendungs- bereich. 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^[24]. Zur ihrer Erstellung werden Arten von Diensten definiert und klassifiziert sowie eine Hierarchie der Dienste beschrieben. Ferner wird dargelegt, wie Dienste in die be- stehende Applikationslandschaft einfügt werden^[25].

Abbildung in dieser Leseprobe nicht enthalten

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^[27]. 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.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Beispiel Beschreibung von Diensttypen^[28]

Diese Diensttypen haben unterschiedliche Beziehungen zueinander.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Beispiel einer Diensthierarchie^[29]

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^[30].

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^[31]. Der Nachrichtenaustausch ist dann z. B. XML-basiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Architekturbeispiel Legacy Anbindung^[32]

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

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)^[35] und sind plattformunabhängig^[36].

Das Konzept eines Dienstes kann in der konkreten Implementierung einem

Webservice entsprechen. Die notwendige Dienstbeschreibung erfolgt in der so ge- nannten Webservice Definition Language, einer ebenfalls XML-basierten Notation^[37].

Webservices basieren auf ähnlichen Eigenschaften wie das Internet. Der Aufruf eines Webservice erfolgt mittels einer POST-Methode über HTTP. Der Aufruf (Request) ent- hält eine SOAP-Meldung, welche die notwendigen Aufrufparameter enthält. SOAP ent- koppelt das Datenformat und das darunter liegende HTTP-Protokoll durch die Ver- wendung der plattformunabhängigen XML. Das HTTP dient dabei als standardisiertes Transportprotokoll für den Nachrichtenaustausch über das Netz. Die Verbindung zwischen zwei Punkten wird über TCP/IP hergestellt^[38]. 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.^[39] 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]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Vergleich von Webservice-Typen41

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^[42]. 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^[43]. Dies widerspricht dem Grundsatz, dass Dienste sich nicht gegenseitig kennen müssen^[44].

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

3 Merkmale der Granularität

3.1 Definition der Granularität

Der Begriff Granularität wird in der wissenschaftlichen Literatur je nach Kontext unter- schiedlich verwendet. Im Allgemeinen wird unter Granulation die Bildung einer körnigen Struktur verstanden.^[46] Bezogen auf das Design eines Software-Programmes wird der Begriff Granularität gewöhnlich verwendet, um den Grad der Detaillierung^[47] zu beschreiben. Konkreter kann auch vom "Grad der Feinheit der Problemzerlegung"^[48] gesprochen werden. Das Ausmaß der Feinheit der Problemzerlegung kann hin- wiederum als "Größe der Entitäten, die in einem System unabhängig adressierbar sind"^[49] näher bestimmt werden. Innerhalb einer SOA entsprechen den Entitäten die einzelnen Dienste.^[50] Die Granularität ist demnach die Aufteilung eines Problem- bereiches, einer so genannten Domäne, in Gruppen kleinerer Elemente. Jede Gruppe wird dabei als unteilbare Einheit betrachtet^[51], wobei eine Domäne einen thematisch in sich abgeschlossenen Anwendungsbereich darstellt. Für einen Dienst im Kontext einer SOA kommt die Granularität dem "Grad der ausgeführten Arbeit"^[52] gleich. Diesem ent- spricht die Funktionalität eines Dienstes^[53], die bei einem Aufruf und Datenaustausch ausgeführt wird.^[54]

Da Dienste einer SOA gemeinhin auch Nachrichten austauschen, bezieht sich Granularität als Grad der Detaillierung u.a. auch auf die übertragenen Daten.^[55]

Infolgedessen ist eine reine Beschränkung der Granularität auf den Grad der Funktionalität für eine Bestimmung einer optimalen Granularität von Diensten nicht hinreichend. Im eigentlichen abstrakten Sinne ist Granularität weiter fassend^[56]. Also ist die Granularität das Festlegen der richtigen Größe eines Dienstes im Hinblick auf Funktionalität und Datenaustausch.

3.2 Arten und Ausprägungen der Granularität

3.2.1 Funktionale Granularität

Dienste einer SOA stellen einen bestimmten Grad an Funktionalität einer Domäne über eine Schnittstelle zur Verfügung. Die Granularität einer Funktionalität bezieht sich also zum Einen auf die Problemzerlegung der Domäne, zum Anderen bezieht sie sich auf die weitere Problemzerlegung des Dienstes und die damit erforderliche Zuordnung der Funktionalität zu den Methoden des Dienstes.^[57]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Granualritätsebenen^[58]

Der Funktionsumfang eines Dienstes kann durch weitere Untergliederung noch genauer beschrieben werden. Hierzu wird die funktionale Granularität weiter in 'standardmäßig bereitgestellte Funktionalität' und 'parametrisierte Funktionalität' unterteilt. Die standardmäßige Funktionalität wird dabei in jedem Fall vom Dienst an- geboten. Ein Beispiel für solche Funktionalität sind die so genannten CRUDS (Create, Read, Update, Delete, Search)-Funktionen. CRUDS-Methoden sind aber vielfach 'ein- fach', da sie nur den Zweck der Datenmanipulation haben. Folglich fehlt ihnen der Ge- schäftswert^[59]. Die parametrisierte Funktionalität wird optional angeboten. Der Nutzer des Dienstes hat z. B. die Möglichkeit über die Eingabeparameter den Dienst zu konfigurieren. Der Dienst wird dadurch äußerst generisch.^[60] Die Konfiguration erfolgt über die Anzahl und den Typ der Parameter. Die Granularität generischer Dienste kann je nach Grad der parametrisierten Funktionalität deutlich variieren. Ihr Geschäftswert ist in der Regel höher als der von CRUDS-Funktionen. Der fehlende Geschäftswert, und die Trivialität dieser Dienste sind auch der Grund, warum diese Methoden von parametrisierten Funktionen hinsichtlich ihrer funktionalen Granularität zu unter- scheiden sind^[61]. Vielfach werden sie bei der Dienstmodellierung ausgelassen^[62] oder in so genannte Data-Source-Services ausgelagert.^[63] Das Anlegen eines Kunden ist z. B. durch eine Create-Funktion unter Umständen weniger umfangreich als die Ausführung einer komplexen Preiskalkulation für den Kunden. Dementsprechend ist der Funktions- umfang als Maß für die Granularität immer auch abhängig von der zugrunde liegenden Komplexität. Eine z. B. versicherungsmathematische Berechnung zur Kalkulation einer Schiffsladung ist in der Regel im Hinblick auf die verwendeten Rechenoperationen und die Anzahl der zu berücksichtigenden Einzelinformationen komplexer als die Preis- kalkulation für ein Lebensmittel oder Konsumgut.

Der Grad der Problemzerlegung einer Domäne, also die Zuordnung der Funktionalität zu einzelnen Diensten und deren weitere Detaillierung in Methoden, bestimmt die Größe und den Umfang eines Dienstes und somit seine funktionale Granularität^[64].

3.2.2 Schnittstellen- oder Datengranularität

Zusätzlich zur Granularität der Funktionalität eines Dienstes muss auch über die Granularität der zugehörigen Daten einer Schnittstelle entschieden werden^[65]. Die so genannte Datengranularität^[66] wird vereinzelt in der Literatur auch als datenbezogene Granularität^[67] oder Schnittstellengranularität^[68] bezeichnet. Das Ausmaß des Objekt- modells, welches der Dienst bearbeitet, wird als Schnittstellengranularität definiert^[69].

Zur Ausführung ihrer Funktionalität tauschen Dienste Daten in Form von Nachrichten aus. Die Datengranularität bezieht sich somit auf das Datenvolumen, das ein Dienst austauscht^[70]. Der Austausch erfolgt durch Eingabe- und Ausgabedaten, die jeweils eine unterschiedliche Struktur haben. Es ist daher sinnvoll zur weiteren Detaillierung der Datengranularität in Eingabe- und Ausgabedatengranularität zu untergliedern. Die Granularität der Eingabedaten wird bestimmt durch die Anzahl der Parameter und ihrer verwendeten Datentypen. Ausgabedaten beziehen sich auf die an den Dienst- nutzer zurückgegebenen Daten nach Aufruf eines Dienstes. Diese Daten können dynamisch gestaltet werden, indem Listen von Datenelementen, z. B. Array Daten- typen oder andere komplexe Datentypen, zurückgegeben werden. Diese Art der Ge- staltung hat daher ebenso großen Einfluss auf die Granularität des Dienstes.^[71]

[...]

---

^[2] Vgl. Koenen J., IT-Investitionen 2009, o.S.

^[3] Merkel, A. Bulletin 2007, Nr. 93-3.

^[4] Quelle: ECIN 2008.

^[5] Vgl. Schaffry, A., IT-Budget 2009, o.S.

^[6] Vgl. Heckel, R., Architectural Transformations, 2008, S. 139.

^[7] Vgl. Lochmaier, L., Mittelständler 2009, o.S.

^[8] Vgl. Pütter, C., Scheitern von SOA 2009, o.S.

^[9] Leymann, F., zitiert nach Ramspeck, J., SOA Fehlerquellen 2008, o.S.

^[10] Vgl. von Henning, H., Service-Granularität 2007, S. 343.

^[11] Vgl. Masak, D., SOA 2007, S. 8.

^[12] Vgl. Kuhn, T., wissenschaftliche Revolutionen 1976, S. 25ff.

^[13] Masak, D., It-alignment 2007, S. 112.

^[14] Heutschi, R., Service Orientierte Architektur 2007, S. 21ff.

^[15] 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 own- ership domains."

^[16] Vgl. Finger, P., et al., SOA Webservices 2009, S. 11.

^[17] Vgl., Völter, M., Modelle 2007, S. 423ff.

^[18] Buchmann, J., et al., Governance Modell 2008, S. 154.

^[19] Vgl., Burbiel, H., Webservices Praxis 2007, S. 481.

^[20] Vgl. Masak, D., SOA 2007, S. 18ff.

^[21] Vgl. Melzer, I., SOA Web Services 2007, S. 14ff.

^[22] Eigene Darstellung in Anlehnung an Heutschi, R. Service Orientierte Architektur 2007, S. 27.

^[23] Vgl. Szyperski, C., Component Software 2002, S. 162f.

^[24] Vgl. Beneken, G., Referenzarchitekturen 2006, S. 375.

^[25] Vgl. Rosen, M. et al., Applied SOA 2008, S. 18f.

^[26] Vgl. Rosen, M. et al., a.a.O., S. 19.

^[27] Vgl. Anhang 1.

^[28] Vgl. Kulkarni, N., et al., Service Granularity Role 2008, S.425.

^[29] Quelle: Kulkarni, N., et al. a.a.O., S.425.

^[30] Vgl. o.V., Cloud Computing 2009, S. 2., vgl. Anhang 2.

^[31] Vgl. Gamma, E. et al., Entwurfsmuster 1996, S. 172.

^[32] Vgl. Schmietendorf, I., et al., Industrial Web Services Granularity 2007, S. 94.

^[33] Vgl. Masak, D., SOA 2007, S. 106.

^[34] Vgl. Schill, A. et al., Verteilte Systeme 2007, S. 20.

^[35] Vgl. Liebhart, D. et al. Architecture Blueprints 2007, S. 292.

^[36] Vgl. Finger. P., et al., SOA Webservices 2009, S. 37.

^[37] Vgl. Erl, T., Service-Oriented Architecture 2004, S. 50.

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

^[39] Vgl. Papazoglou, M., Web Services Principles 2008, S. 18.

^[40] Vgl. Papazoglou, M., a.a.O., S. 18.

^[41] Vgl. Jankovska A., et al., SOA Mobile Access 2005, S. 374.

^[42] Vgl. Weinaug, H. et al., Web Support 2008, S. 224.

^[43] Vgl. Karakostas, B. et al., Engineering Service Oriented Systems 2008, S. 272

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

^[45] Vgl. Schill, A. et al., Verteilte Systeme 2007, S. 20.

^[46] Vgl. Duden, 1996, S. 323.

^[47] Vgl. Erl, T., Service Design, 2008, S. 115. Ähnlich auch bei Allen, P., Service Orientation, 2006, S. 71.

^[48] Wollny, S., Expertensysteme, 2003, S. 15.

^[49] Baker, S., Dobson, S., Comparing SOA 2005, S. 635.

^[50] Vgl. Baker S. et al., a.a.O., S. 635.

^[51] Vgl. Bettini, C., time granularity 2003, S. 1.

^[52] Vgl. Hohmann, L., Beyond software architecture 2003, S. 19.

^[53] Vgl. Erl, T., Concepts 2005, S. 299.

^[54] Vgl. Rosen, M. et al., Applied SOA 2008, S. 56.

^[55] Vgl. Erl, T., Service Design 2008, S. 116, vgl. z. B. Haesen, R., et al., Service Granularity Definition 2008, S. 386.

^[56] Vgl. Anhang 3.

^[57] Vgl. McGovern, J., et al., Java Web Service Architecture 2003, S. 50.

^[58] Quelle: Eigene Darstellung

^[59] Vgl. Keller, W., Schnittstellendesign 2007, S. 362., vgl. Rosen, M. et al., Applied SOA 2008, S. 386.

^[60] Vgl. Haesen, R., et al., a. a. O., S. 382.

^[61] Masak, D., SOA 2007, S. 138.

^[62] Vgl. z. B. Zimmermann, O., et al., Second Generation SOA 2004, S. 288.

^[63] Vgl. Keller, W., a. a. O., S. 362.

^[64] Vgl. Rosen, M. et al., a. a. O., S. 56.

^[65] Vgl. McGovern, J., a.a.O., S. 52.

^[66] Vgl. z. B. Haesen, R. et al., a. a. O., S. 379.

^[67] Vgl. Rud, D., et al., Granularitätsmetriken für serviceorientierte Architekturen, 2007, S.299.

^[68] Vgl. Heutschi, R., Serviceorientierte Architektur, 2007, S. 43.

^[69] Vgl. Masak, D., SOA 2007, S. 275.

^[70] Erl, T., Service Design 2008, S. 118.

^[71] Vgl. Haesen, R. et al., a. a. O., S. 379ff.