Dynamische Visualisierung serviceorientierter Architekturen
©2007
Diplomarbeit
128 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Die Geschäftsprozesse in Unternehmen sind gekennzeichnet von einer kontinuierlichen Dynamik. Die variierenden Rahmenbedingungen im Bezug auf Kunden, Wettbewerber und Märkte, resultieren in wechselnden Anforderungen an die Prozesse. Um den Anforderungen gerecht zu werden, müssen Geschäftsprozesse sich flexibel gestalten lassen. Entsprechend flexibel müssen auch die Softwaresysteme und deren Architekturen sein, die den Prozessen zugrunde liegen. Damit eine Anpassung möglichst dynamisch erfolgen kann, werden serviceorientierte Architekturen eingesetzt. Sie sollen durch die Nutzung kombinierbarer und wiederverwendbarer Softwarekomponenten, eine schnellere und einfachere Veränderung von Softwarearchitekturen in Unternehmen realisieren. Mit dem Ziel diese Architekturen dynamischer auf die Geschäftsprozesse und deren Anforderungen ausrichten zu können, als dies in der Vergangenheit der Fall war.
Nicht allein im Bezug auf serviceorientierte Architekturen ist dabei zu beachten, dass die Entwicklung und Wartung von Softwarearchitekturen einen umfangreichen und vielschichtigen Prozess darstellt. Voraussetzung für die erfolgreiche Durchführung eines derartigen Prozesses, ist das Verständnis der beteiligten Personen. Ein solches Verständnis zu erlangen wird in zunehmendem Maße wichtiger, angesichts immer komplexerer Softwaresysteme und gleichzeitig kürzerer Softwarelebenszyklen. Aufgrund der Größe und Komplexität der meisten Systeme, ist ein Verständnis dafür jedoch nicht ohne weiteres erreichbar. Dies gilt besonders für serviceorientierte Architekturen, deren Einsatz auch mit einer stärkeren Vernetzung der technischen und wirtschaftlichen Ebene in Unternehmen einhergeht. Die infolgedessen bestehenden Beziehungen zwischen diesen Ebenen, steigern zusätzlich die Komplexität serviceorientierter Architekturen.
Aus diesen Gründen sind Werkzeuge erforderlich, welche dabei helfen die Komplexität von Softwaresystemen zu reduzieren und somit ein Verständnis für sie zu ermöglichen. Die Softwarevisualisierung stellt ein Werkzeug dieser Art dar. Sie versucht mit Hilfe graphischer Darstellungen, das Verständnis für unterschiedliche Aspekte von Softwaresystemen zu schaffen und zu verbessern. Um dies zu erreichen, wurden in den vergangenen Jahren zahlreiche Ansätze und Tools für die Visualisierung von Software entwickelt. Die Ansätze und die ihnen zugrunde liegenden Konzepte, fokussieren in ihrer Ausrichtung allerdings primär objektorientierte […]
Die Geschäftsprozesse in Unternehmen sind gekennzeichnet von einer kontinuierlichen Dynamik. Die variierenden Rahmenbedingungen im Bezug auf Kunden, Wettbewerber und Märkte, resultieren in wechselnden Anforderungen an die Prozesse. Um den Anforderungen gerecht zu werden, müssen Geschäftsprozesse sich flexibel gestalten lassen. Entsprechend flexibel müssen auch die Softwaresysteme und deren Architekturen sein, die den Prozessen zugrunde liegen. Damit eine Anpassung möglichst dynamisch erfolgen kann, werden serviceorientierte Architekturen eingesetzt. Sie sollen durch die Nutzung kombinierbarer und wiederverwendbarer Softwarekomponenten, eine schnellere und einfachere Veränderung von Softwarearchitekturen in Unternehmen realisieren. Mit dem Ziel diese Architekturen dynamischer auf die Geschäftsprozesse und deren Anforderungen ausrichten zu können, als dies in der Vergangenheit der Fall war.
Nicht allein im Bezug auf serviceorientierte Architekturen ist dabei zu beachten, dass die Entwicklung und Wartung von Softwarearchitekturen einen umfangreichen und vielschichtigen Prozess darstellt. Voraussetzung für die erfolgreiche Durchführung eines derartigen Prozesses, ist das Verständnis der beteiligten Personen. Ein solches Verständnis zu erlangen wird in zunehmendem Maße wichtiger, angesichts immer komplexerer Softwaresysteme und gleichzeitig kürzerer Softwarelebenszyklen. Aufgrund der Größe und Komplexität der meisten Systeme, ist ein Verständnis dafür jedoch nicht ohne weiteres erreichbar. Dies gilt besonders für serviceorientierte Architekturen, deren Einsatz auch mit einer stärkeren Vernetzung der technischen und wirtschaftlichen Ebene in Unternehmen einhergeht. Die infolgedessen bestehenden Beziehungen zwischen diesen Ebenen, steigern zusätzlich die Komplexität serviceorientierter Architekturen.
Aus diesen Gründen sind Werkzeuge erforderlich, welche dabei helfen die Komplexität von Softwaresystemen zu reduzieren und somit ein Verständnis für sie zu ermöglichen. Die Softwarevisualisierung stellt ein Werkzeug dieser Art dar. Sie versucht mit Hilfe graphischer Darstellungen, das Verständnis für unterschiedliche Aspekte von Softwaresystemen zu schaffen und zu verbessern. Um dies zu erreichen, wurden in den vergangenen Jahren zahlreiche Ansätze und Tools für die Visualisierung von Software entwickelt. Die Ansätze und die ihnen zugrunde liegenden Konzepte, fokussieren in ihrer Ausrichtung allerdings primär objektorientierte […]
Leseprobe
Inhaltsverzeichnis
Christian Kahl
Dynamische Visualisierung serviceorientierter Architekturen
ISBN: 978-3-8366-0408-6
Druck Diplomica® Verlag GmbH, Hamburg, 2007
Zugl. Universität Duisburg-Essen, Standort Essen, Essen, Deutschland, Diplomarbeit,
2007
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplom.de, Hamburg 2007
Printed in Germany
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Abbildungsverzeichnis ... V
Abkürzungsverzeichnis... VII
1
Einführung und Motivation... 1
2
Grundlagen serviceorientierter Architekturen... 5
2.1
Motivation... 5
2.2
Definition... 6
2.3
Ziele ... 8
2.3.1
Einfachheit ... 8
2.3.2
Flexibilität und Wartbarkeit ... 9
2.3.3
Wiederverwendbarkeit ... 9
2.3.4
Entkopplung von Funktionalität und Technologie ... 9
2.4
Elemente ... 10
2.4.1
Service und Servicerollen ... 10
2.4.2
Servicebeschreibung... 11
2.4.2.1
Erreichbarkeit... 11
2.4.2.2
Funktionalität ... 11
2.4.2.3
Policies ... 12
2.4.2.4
Service Interface ... 12
2.4.2.5
Servicevertrag... 13
2.4.3
Ausführungskontext... 13
2.5
Konzepte ... 14
2.5.1
Sichtbarkeit... 14
2.5.1.1
Bewusstsein ... 14
2.5.1.2
Bereitschaft... 15
2.5.1.3
Erreichbarkeit... 15
2.5.2
Interaktion ... 15
2.5.3
Realwelt Effekt... 16
2.6
Aufbau und Kontext... 16
2.6.1
Anwendungsschicht ... 19
2.6.2
Serviceschicht... 19
2.6.2.1
Anwendungsserviceschicht ... 20
2.6.2.2
Geschäftsserviceschicht ... 20
2.6.2.3
Orchestrierungsserviceschicht... 21
2.6.3
Prozessschicht ... 21
2.7
Charakteristika ... 22
2.7.1
Wiederverwendbarkeit ... 22
Inhaltsverzeichnis
II
2.7.2
Formaler Vertrag ...22
2.7.3
Lose Kopplung...23
2.7.4
Abstraktion ...23
2.7.5
Kombinierbarkeit ...23
2.7.6
Autonomie ...24
3
Grundlagen der Softwarevisualisierung ... 25
3.1
Motivation ...25
3.2
Definition ...26
3.3
Ziele ...27
3.4
Anforderungen ...28
3.4.1
Expressivität ...28
3.4.2
Effektivität ...28
3.4.3
Angemessenheit ...29
4
Konzepte und Techniken der Softwarevisualisierung... 31
4.1
Verständnisstrategien...31
4.1.1
Bottom Up ...31
4.1.2
Top Down ...32
4.1.3
Wissensbasiert ...33
4.1.4
Systematisch und nach Bedarf ...33
4.1.5
Integriert...33
4.2
Visualisierungspipeline ...34
4.2.1
Datenaufbereitung ...34
4.2.2
Datenabbildung ...34
4.2.3
Bildgenerierung ...35
4.3
Sichtenkonzept ...35
4.3.1
Logische Sicht ...37
4.3.2
Prozesssicht ...37
4.3.3
Entwicklungssicht...38
4.3.4
Physische Sicht...38
4.3.5
Szenarios...38
4.4
Visuelle Konzepte ...39
4.4.1
Multiple Sichten ...39
4.4.2
Filterung ...40
4.4.3
Aggregation ...40
4.4.4
Pan und Zoom ...41
4.4.5
Kontext und Detail ...42
5
Ansätze und Probleme der Softwarevisualisierung ... 43
5.1
Charakterisierung ...43
Inhaltsverzeichnis
III
5.1.1
Inhalt ... 44
5.1.2
Form ... 45
5.2
Bestehende Ansätze ... 48
5.2.1
Unified Modeling Language ... 48
5.2.1.1
Inhalt... 48
5.2.1.2
Form ... 50
5.2.2
BLOOM ... 51
5.2.2.1
Inhalt... 52
5.2.2.2
Form ... 52
5.2.3
Simple Hierarchical Multi Perspective... 53
5.2.3.1
Inhalt... 53
5.2.3.2
Form ... 54
5.2.4
Code Crawler ... 55
5.2.4.1
Inhalt... 55
5.2.4.2
Form ... 55
5.2.5
Source Viewer 3D... 56
5.2.5.1
Inhalt... 57
5.2.5.2
Form ... 57
5.2.6
Software Landscapes ... 59
5.2.6.1
Inhalt... 59
5.2.6.2
Form ... 60
5.3
Probleme ... 62
5.3.1
Darstellung... 62
5.3.2
Komplexität und Skalierbarkeit... 63
5.3.3
Dynamik ... 65
5.3.4
Ganzheitlichkeit ... 68
5.3.5
Anwendung ... 69
5.3.5.1
Automatisierung ... 69
5.3.5.2
Evaluation... 70
5.3.5.3
Anwendung in der Praxis... 71
6
Modell der dynamischen Visualisierung ... 73
6.1
Motivation... 73
6.2
Definition und Ziele ... 75
6.3
Anforderungen... 77
6.3.1
Dynamik ... 77
6.3.2
Multidimensionalität... 77
6.3.3
Skalierbarkeit ... 77
6.3.4
Ganzheitlichkeit ... 78
Inhaltsverzeichnis
IV
6.4
Aufbau und Kontext ...78
6.4.1
Stakeholder ...79
6.4.2
Serviceorientierte Architektur ...81
6.4.3
Softwarevisualisierung...81
6.4.4
Visualisierungsprozess ...82
6.5
Dynamische Sicht ...84
6.5.1
Inhalt ...85
6.5.2
Form ...88
6.5.2.1
Multiple Subsichten...89
6.5.2.2
Informationshierarchie ...93
6.5.2.3
Information on Demand...96
6.5.2.4
Filterung ...98
6.5.2.5
Aggregation ...100
6.5.2.6
Kontext und Detail...102
7
Zusammenfassung und Ausblick... 105
Literaturverzeichnis ... 109
Abbildungsverzeichnis
V
Abbildungsverzeichnis
Abbildung 1.1: Aufbau der Arbeit ... 2
Abbildung 2.1: Das Service Konzept ... 7
Abbildung 2.2: Aufbau der Unternehmenslogik... 17
Abbildung 2.3: Aufbau einer serviceorientierten Architektur ... 18
Abbildung 2.4: Subschichten der Serviceschicht ... 20
Abbildung 4.1: Die Visualisierungspipeline... 34
Abbildung 4.2: Das 4+1 Sichten Modell... 37
Abbildung 4.3: Schematische Sicht ... 39
Abbildung 4.4: Das Konzept der multiplen Sichten... 39
Abbildung 4.5: Das Konzept der Filterung ... 40
Abbildung 4.6: Das Konzept der Aggregation ... 41
Abbildung 4.7: Das Pan und Zoom Konzept ... 41
Abbildung 4.8: Das Kontext und Detail Konzept ... 42
Abbildung 5.1: Sichten der UML nach Kategorien... 49
Abbildung 5.2: Beispiel für ein UML Klassendiagramm... 51
Abbildung 5.3: Beispiel für ein UML Zustandsdiagramm... 51
Abbildung 5.4: Beispiele für Visualisierungen in BLOOM... 53
Abbildung 5.5: Schrittweise Anzeige von Details in SHriMP ... 54
Abbildung 5.6: Beispiel einer Visualisierung in SHriMP... 55
Abbildung 5.7: Beispiel einer Visualisierung in Code Crawler ... 56
Abbildung 5.8: Beispiel einer Visualisierung in SV3D ... 58
Abbildung 5.9: Überblicksdarstellung in SV3D (Ausschnitt) ... 58
Abbildung 5.10: Visualisierung von Relationen in Software Landscapes... 61
Abbildung 5.11: Beispiel einer Visualisierung bei Software Landscapes ... 61
Abbildung 5.12: Beispiele für die Komplexität von Visualisierungen... 64
Abbildung 6.1: Die Softwarevisualisierung im Kontext... 73
Abbildung 6.2: Das Modell der dynamischen Visualisierung ... 79
Abbildung 6.3: Der Visualisierungsprozess im MDV ... 82
Abbildung 6.4: Schematische serviceorientierte Architektur ... 89
Abbildung 6.5: Dynamische Sicht mit zwei Subsichten ... 90
Abbildung 6.6: Die Informationshierarchie auf der Anwendungsschicht ... 94
Abbildung 6.7: Information on Demand am Beispiel eines Services ... 97
Abbildung 6.8: Ausblendung von Elementen durch Filterung ... 99
Abbildung 6.9: Aggregation von Elementen ...101
Abbildung 6.10: Betrachtung von Details und Kontext...103
Abkürzungsverzeichnis
VII
Abkürzungsverzeichnis
BPEL... Business Process Execution Language
IT... Informationstechnik
JAVA EE ... JAVA Enterprise Edition
MDV ... Modell der dynamischen Visualisierung
UML... Unified Modeling Language
WSDL ... Web Service Description Language
XML... Extended Markup Language
Einführung und Motivation
1
1
Einführung und Motivation
Die Geschäftsprozesse in Unternehmen sind gekennzeichnet von einer kontinu-
ierlichen Dynamik. Die variierenden Rahmenbedingungen im Bezug auf Kunden,
Wettbewerber und Märkte, resultieren in wechselnden Anforderungen an die Pro-
zesse. Um den Anforderungen gerecht zu werden, müssen Geschäftsprozesse
sich flexibel gestalten lassen. Entsprechend flexibel müssen auch die Software-
systeme und deren Architekturen sein, die den Prozessen zugrunde liegen. Damit
eine Anpassung möglichst dynamisch erfolgen kann, werden serviceorientierte
Architekturen eingesetzt. Sie sollen durch die Nutzung kombinierbarer und
wiederverwendbarer Softwarekomponenten, eine schnellere und einfachere Ver-
änderung von Softwarearchitekturen in Unternehmen realisieren. Mit dem Ziel
diese Architekturen dynamischer auf die Geschäftsprozesse und deren Anforde-
rungen ausrichten zu können, als dies in der Vergangenheit der Fall war.
Nicht allein im Bezug auf serviceorientierte Architekturen ist dabei zu beachten,
dass die Entwicklung und Wartung von Softwarearchitekturen einen umfangrei-
chen und vielschichtigen Prozess darstellt. Voraussetzung für die erfolgreiche
Durchführung eines derartigen Prozesses, ist das Verständnis der beteiligten
Personen. Ein solches Verständnis zu erlangen wird in zunehmendem Maße
wichtiger, angesichts immer komplexerer Softwaresysteme und gleichzeitig kür-
zerer Softwarelebenszyklen. Aufgrund der Größe und Komplexität der meisten
Systeme, ist ein Verständnis dafür jedoch nicht ohne weiteres erreichbar. Dies
gilt besonders für serviceorientierte Architekturen, deren Einsatz auch mit einer
stärkeren Vernetzung der technischen und wirtschaftlichen Ebene in Unterneh-
men einhergeht. Die infolgedessen bestehenden Beziehungen zwischen diesen
Ebenen, steigern zusätzlich die Komplexität serviceorientierter Architekturen.
Aus diesen Gründen sind Werkzeuge erforderlich, welche dabei helfen die Kom-
plexität von Softwaresystemen zu reduzieren und somit ein Verständnis für sie
zu ermöglichen. Die Softwarevisualisierung stellt ein Werkzeug dieser Art dar.
Sie versucht mit Hilfe graphischer Darstellungen, das Verständnis für unter-
schiedliche Aspekte von Softwaresystemen zu schaffen und zu verbessern. Um
dies zu erreichen, wurden in den vergangenen Jahren zahlreiche Ansätze und
Tools für die Visualisierung von Software entwickelt. Die Ansätze und die ihnen
zugrunde liegenden Konzepte, fokussieren in ihrer Ausrichtung allerdings primär
objektorientierte Systeme. Serviceorientierte Softwaresysteme und ihre Archi-
tekturen finden dagegen bislang wenig Berücksichtigung. Obwohl ihnen in der
Softwareentwicklung eine wachsende Bedeutung zuteil wird und obwohl gerade
hier, aufgrund der skizzierten Komplexität dieser Architekturen, geeignete Werk-
Einführung und Motivation
2
zeuge notwendig sind, um ein Verständnis zu ermöglichen. Es stellt sich daher
die Frage, inwieweit heute bestehende Ansätze der Softwarevisualisierung und
die darin verwendeten Konzepte, in der Lage sind, serviceorientierte Architektu-
ren adäquat zu visualisieren.
Ausgehend von dieser Frage, soll im Rahmen der vorliegenden Arbeit zunächst
gezeigt werden, dass die Konzepte der Softwarevisualisierung und die Art in der
sie bisher angewendet werden, für eine geeignete Visualisierung service-
orientierter Architekturen nicht ausreichen. Ziel der Arbeit ist die Identifikation
der Schwächen bestehender Visualisierungsansätze und darauf aufbauend die
Entwicklung eines Modells, dass die Visualisierung serviceorientierter Architek-
turen beschreibt. Das Modell soll einen ganzheitlichen Ansatz für die visuelle
Darstellung derartiger Architekturen repräsentieren. Grundlage hierfür ist die
explizite Ausrichtung eines solchen Ansatzes an den spezifischen Charakteristika
serviceorientierter Architekturen und ein angemessener Einsatz von Konzepten
der Softwarevisualisierung. Damit soll das Modell die Grundlage schaffen für eine
nachhaltige Förderung des Verständnisses, bei allen Personen (Stakeholder), die
ein Interesse an einer solchen Architektur haben.
Abbildung 1.1: Aufbau der Arbeit
Um die Zielsetzung zu erreichen (vgl. Abbildung 1.1), sind zunächst service-
orientierte Architekturen und ihre Grundlagen, Gegenstand dieser Arbeit (vgl. 2).
Hierbei erfolgt vor allem eine Betrachtung der Konzepte, welche diesen Architek-
turen zugrunde liegen und der Bestandteile, aus denen sie sich zusammen-
setzen. Ziel dieses Teils der Arbeit ist es, einen Überblick zu geben, was service-
Einführung und Motivation
3
orientierte Architekturen sind und über welche charakteristischen Eigenschaften
sie verfügen.
Serviceorientierte Architekturen sind in diesem Kontext beispielhaft für die Kom-
plexität von Softwaresystemen und ihren Architekturen zu sehen. Ausgehend
davon betrachten die anschließenden Kapitel die Softwarevisualisierung als Mög-
lichkeit, zur Reduktion von Komplexität und zur Schaffung von Verständnis. Im
Mittelpunkt stehen die Grundlagen der Softwarevisualisierung (vgl. 3), gefolgt
von spezifischen Konzepten und Techniken (vgl. 4).
Darauf aufbauend stellt Kapitel 5 einige exemplarische Ansätze der Softwarevi-
sualisierung vor, um Beispiele für ihre Anwendung in der Praxis zu geben. Hier-
bei zeigt sich allerdings auch, dass mit den bestehenden Ansätzen einige Prob-
leme verbunden sind. Probleme, die insbesondere im Bezug auf serviceorientier-
te Architekturen von Bedeutung sind. Aus diesem Grund findet abschließend die
Vorstellung eines neuen Ansatzes der Softwarevisualisierung statt (vgl. 6), der
speziell diese Architekturform fokussiert.
Für ein umfassendes Verständnis serviceorientierter Systeme in Unternehmen ist
neben einer Betrachtung der Struktur auch die Betrachtung ihres Verhaltens von
Bedeutung. Eine derartige Betrachtung würde jedoch über den Rahmen dieser
Arbeit hinausgehen. Die Ausrichtung des vorgestellten Modells, auf ausschließlich
die Architektur und damit strukturelle Aspekte serviceorientierter Systeme, stellt
daher eine notwendige Einschränkung dar.
Bezüglich der Verwendung von Begriffen sollte beachtet werden, dass die Begrif-
fe Software, Softwaresystem und System im Folgenden synonym verwendet
werden. Gleiches gilt, sofern nicht anders beschrieben, für die Begriffe Soft-
warearchitektur und Architektur.
Grundlagen serviceorientierter Architekturen
5
2
Grundlagen serviceorientierter Architek-
turen
Serviceorientierte Architekturen stellen eine besondere Form von Software-
architekturen dar. Eine Form, die ein hohes Maß an Flexibilität ermöglichen soll,
die aber gleichermaßen neue Herausforderungen bedingt. Die folgenden Ab-
schnitte beschäftigen sich mit den Grundlagen serviceorientierter Architekturen.
Dabei steht zunächst im Mittelpunkt, welche Motivation dieser Architekturform
zugrunde liegt, wie sie definiert werden kann und welche Ziele mit ihrem Einsatz
verbunden sind. Daran schließt sich eine Betrachtung wesentlicher Elemente an,
aus denen serviceorientierte Architekturen bestehen, bevor die mit ihnen ver-
bundenen Konzepte vorgestellt werden. Wie die einzelnen Bestandteile im Rah-
men des Aufbaus serviceorientierter Architekturen in Beziehung zueinander
stehen und welche Charakteristika sich daraus ergeben, ist Gegenstand der
letzten beiden Abschnitte dieses Kapitels.
2.1
Motivation
Im globalen Wettbewerb sind Unternehmen einer stetigen Dynamik ausgesetzt.
Die Märkte auf denen sie agieren, die Bedürfnisse ihrer Kunden und nicht zuletzt
die technischen Rahmenbedingungen, verändern sich schnell und die Lebens-
zyklen von Produkten und Entscheidungen werden zunehmend kürzer. Dies hat
zur Folge, dass die Geschäftsprozesse in Unternehmen kontinuierlich angepasst
werden müssen, um den sich ändernden Rahmenbedingungen gerecht zu wer-
den. Entsprechende Adaptionen müssen auch die Softwaresysteme ermöglichen,
welche die Durchführung der Geschäftsprozesse umsetzen und somit deren Basis
auf technischer Ebene bilden.
Die Problematik liegt darin, dass die eingesetzten Softwaresysteme oft nicht so
flexibel, agil und effizient anpassbar an veränderte Anforderungen sind, wie es
notwendig wäre, um der wirtschaftlichen Dynamik in technischer Hinsicht zu ent-
sprechen. Vor allem die Struktur der Systeme ist vielfach zu unflexibel für grund-
legende Veränderungen [KrBS2005, 2]. Viele kleinere Änderungen werden zu-
dem oftmals nur dann eingefügt, wenn gerade die Notwendigkeit dafür besteht.
Sie erfüllen folglich zwar in einem Teilbereich eines Softwaresystems ihren
Zweck, unterliegen aber keinem übergeordneten Konzept, so dass die Auswir-
kungen, welche sie für das gesamte System haben können, kaum oder gar nicht
absehbar sind [KrBS2005, 3]. Aufgrund dieser Einschränkung, lassen sich die
aus den dynamischen Rahmenbedingungen resultierenden Anforderungen nicht
ausreichend schnell in den Systemen umsetzen. Dies führt zu einer Minderung
der Reaktionsfähigkeit der Unternehmen.
Grundlagen serviceorientierter Architekturen
6
Die Softwaresysteme in Unternehmen erfordern zudem nicht nur Flexibilität und
Adaptierbarkeit, sondern auch eine starke Einbindung in die Organisation und in
die Geschäftsprozesse, welche das Unternehmen ausmachen. Dabei müssen die
entsprechenden Systeme unternehmensweit betrachtet werden, da sich Ge-
schäftsprozesse nicht auf einzelne Teilbereiche beschränken [KrBS2005, 3ff].
Die genannten Aspekte legen die Schlussfolgerung nahe, dass Softwaresysteme
und ihre Architekturen, in den Formen in denen sie heute in vielen Unternehmen
existieren, den Anforderungen ihres Einsatzgebietes nicht oder zumindest nicht
in ausreichendem Maße genügen. Vor diesem Hintergrund werden serviceorien-
tierte Architekturen als eine Möglichkeit betrachtet, um Softwaresysteme in
Unternehmen besser integrieren und die Anforderungen an die Geschäfts-
prozesse flexibler und schneller umsetzen zu können [MLMB2006, 11; KrBS2005,
6].
2.2
Definition
Dem Konzept der serviceorientierten Architektur ist in den vergangenen Jahren
große Beachtung zuteil geworden. Dabei existiert eine Vielzahl von unterschiedli-
chen und zum Teil gegensätzlichen Definitionen für diesen Begriff [MLMB2006,
4]. Ähnlich wie im Hinblick auf den Begriff der Softwarearchitektur, gibt es bezo-
gen auf die serviceorientierte Architektur ebenso keine eindeutige und allgemein
anerkannte Definition. Serviceorientierte Architekturen stellen eine besondere
Form der Softwarearchitektur dar. Eine Softwarearchitektur kann allgemein defi-
niert werden, als die Struktur der Strukturen eines Softwaresystems. Unter einer
Struktur sind Softwareelemente (z.B. Komponenten, Module) und die Beziehun-
gen zwischen diesen Elementen zu verstehen [BaCK2003, 3; CBBG2003, 1ff]
1
.
Die Elemente einer Architektur werden auch als Artefakte bezeichnet. Die Soft-
warearchitektur beschreibt die technische Struktur sowie die Bedingungen und
Charakteristiken, welche für ein Softwaresystem gelten [KrBS2005, 56]. Analog
zu der Architektur eines Gebäudes in der Realwelt, die dessen Struktur und Auf-
bau beschreibt.
In Abgrenzung zu anderen Architekturformen, liegt serviceorientierten Archi-
tekturen das Paradigma der Serviceorientierung zugrunde. Das Paradigma be-
trachtet Softwaresysteme, im Kontext von Unternehmen, hinsichtlich ihrer Rolle
als Dienstleister. Ausgangspunkt ist die Vorstellung, dass Entitäten, in Form von
Personen oder Unternehmen, Probleme lösen müssen, mit denen sie in ihrer
1
Weitere Definitionen: http://www.sei.cmu.edu/architecture/definitions.html
Grundlagen serviceorientierter Architekturen
7
Geschäftsumwelt konfrontiert sind. Eine Problemlösung stellt in diesem Fall eine
Leistung dar, die von einer Entität erbracht und an andere Entitäten bereitge-
stellt wird, um deren Probleme zu lösen und ein bestimmtes Bedürfnis zu erfüllen
[MLMB2006, 8]. Die Entität welche die Leistung erbringt, tritt demzufolge als
Dienstleister (Anbieter) für einen Konsumenten (Nachfrager) auf. Im Falle eines
Unternehmens, wird eine solche, oftmals komplexe Leistung, zusätzlich in ein-
zelne kleinere und weniger komplexe Teilaufgaben zerlegt, die von den Abteilun-
gen und deren Mitarbeitern durchgeführt werden. Ein Service tritt dabei als
Vermittler auf, der einem Nachfrager die Nutzung der Leistung eines Anbieters
ermöglicht (vgl. Abbildung 2.1).
Abbildung 2.1: Das Service Konzept
Verdeutlichen lässt sich die Serviceorientierung an einem Beispiel aus der Real-
welt. Angenommen, eine Person hat das Bedürfnis eine Reise zu buchen. Eine
Fluglinie bietet in diesem Fall die Möglichkeit, das Bedürfnis zu befriedigen, in-
dem sie Flugreisen anbietet. Die Person tritt somit als Nachfrager einer Leistung
(Flugreise) gegenüber einem Anbieter (Fluglinie) auf. Die Buchung erfolgt aber
nicht direkt bei der Fluglinie. Vielmehr nutzt die Person deren Internetseite, für
die Buchung des Fluges. Die Internetseite repräsentiert damit den Service, wel-
cher die Leistung des Anbieters an den Nachfrager vermittelt.
Im Bezug auf Softwaresysteme in Unternehmen gilt es, Probleme in Form der
Durchführung von Geschäftsprozessen zu lösen und damit Bedürfnisse von Kun-
den zu erfüllen. Unter einem Geschäftsprozess wird ein Arbeitsablauf verstan-
den, für dessen Durchführung eine Menge einzelner Arbeitsschritte, in einer
bestimmten zeitlichen Abfolge erforderlich ist [Erl2005, 288; KrBS2005, 57]. Die
Arbeitsschritte werden als Aktivitäten bezeichnet. Sie repräsentieren die Tätig-
keiten, welche zur Erbringung einer Leistung notwendig sind. Zur Durchführung
der Aktivitäten, werden unterschiedliche Softwaresysteme im Unternehmen
genutzt. Jedes Softwaresystem erbringt eine Leistung, ähnlich wie ein Mitarbeiter
oder eine Abteilung im Unternehmen. Damit diese Leistung von anderen Elemen-
ten in einem System genutzt werden kann, ist es erforderlich sie über eine
Schnittstelle verfügbar zu machen. Diese Schnittstelle wird durch einen Service
repräsentiert. Über den Service kann die Leistung der Softwaresysteme im
Grundlagen serviceorientierter Architekturen
8
Rahmen von Geschäftsprozessen genutzt werden. Die Softwaresysteme treten
somit als Dienstleister auf. Sie führen eine bestimmte Funktionalität aus, erbrin-
gen dadurch eine bestimmte Leistung und ermöglichen so die erfolgreiche
Durchführung einer Aktivität. Ebenso ist es möglich, dass Leistungen system-
oder unternehmensübergreifend und damit verteilt, bereitgestellt und verwendet
werden [MLMB2006, 8; Erl2005, 32f].
Eine serviceorientierte Architektur wird demnach, in Anlehnung an [MLMB2006,
8], als ein Paradigma für die Organisation und Verwendung von verteilten Funk-
tionalitäten definiert. Im technischen Sinn repräsentiert eine Funktionalität hier-
bei eine Leistung. Die Funktionalitäten können sich unter der Kontrolle verschie-
dener Besitzer befinden. Eine serviceorientierte Architektur umfasst die Bereit-
stellung und Nutzung von im Rahmen des Softwaresystems zur Verfügung ste-
henden Funktionalitäten über Services [KrBS2005, 56; Gart2004, 325].
2.3
Ziele
Betrachtet man die zuvor geschilderten Problematiken von Softwaresystemen in
Unternehmen (vgl. 2.1), so stellt die Serviceorientierung (vgl. 2.2) generell eine
mögliche Lösung dieser Probleme dar. Im Kern ist es folglich Ziel des Paradigmas
der Serviceorientierung, die Softwaresysteme in Unternehmen gemäß den Erfor-
dernissen, welche aus den Geschäftsprozessen resultieren, anlegen und gestal-
ten zu können [MLMB2006, 8; BLBB2000, 3f]. Um dies zu erreichen, gibt es
einige explizite Ziele, die serviceorientierte Architekturen in der Praxis erfüllen
sollten. Nach [KrBS2005, 6f] gehören dazu Einfachheit, Flexibilität und Wartbar-
keit, Wiederverwendbarkeit sowie die Entkopplung von Funktionalität und Tech-
nologie. Diese Ziele sind prägend für das Design serviceorientierter Archi-
tekturen.
2.3.1
Einfachheit
Eine Softwarearchitektur dient immer auch dem Zweck der Kommunikation
zwischen einzelnen Stakeholdern [BaCK2003, 26ff]. Da serviceorientierte Archi-
tekturen eine besondere Form von Softwarearchitekturen repräsentieren, gilt
dies für sie gleichermaßen. Für die Ermöglichung einer effizienten Kommunika-
tion zwischen den Stakeholdern, sollte eine serviceorientierte Architektur einfach
sein, so dass sie allen verständlich ist. Ein solches Verständnis ist vor allem im
Hinblick auf die Rollen und Aufgaben wichtig, welche den verschiedenen Stake-
holdern im Unternehmen zukommen. Das Verständnis ist Voraussetzung dafür,
dass die Stakeholder, die sich hinsichtlich ihrer Rolle sowie ihrer Interessen,
Fähigkeiten und Kenntnisse unterscheiden, ihre jeweiligen Aufgaben adäquat
durchführen können [KrBS2005, 6].
Grundlagen serviceorientierter Architekturen
9
2.3.2
Flexibilität und Wartbarkeit
Eine serviceorientierte Architektur soll Unternehmen flexibler machen, damit die
Unternehmen und ihre Geschäftsprozesse den Anforderungen gerecht werden
können, die sich ihnen im Rahmen ihrer Geschäftsumwelt stellen. Ziel ist es,
schnell und effizient auf neue oder veränderte Anforderungen reagieren und die
Architektur entsprechend anpassen zu können [MLMB2006, 11]. Für die Er-
reichung dieses Ziels, muss eine serviceorientierte Architektur entsprechend
flexibel und anpassbar sein.
Die Architektur sollte deshalb aus einzelnen, abgeschlossenen Komponenten be-
stehen, die sich in verschiedener Weise, flexibel miteinander kombinieren lassen
[KrBS2005, 6]. Die einzelnen Komponenten müssen darüber hinaus effizient
wartbar sein, etwa für die Erweiterung um zusätzliche Funktionalitäten. Services
repräsentieren eine solche Form von Komponenten [KrBS2005, 67].
2.3.3
Wiederverwendbarkeit
Die Elemente aus denen Softwaresysteme in Unternehmen bestehen, beinhalten
jeweils eine Menge spezifischer Funktionalitäten. Ziel einer serviceorientierten
Architektur ist es, dass diese Funktionalitäten sich in unterschiedlichen Kontex-
ten zur Durchführung wechselnder Aufgaben wiederverwenden lassen. Damit soll
Redundanz bezüglich der Funktionalitäten vermieden und Kosten gesenkt wer-
den [KrBS2005, 6f].
Wiederverwendbarkeit kann auch durch die Bereitstellung von Mechanismen
erfolgen, welche das Auffinden von Services ermöglichen. Etwa durch Service
Repositories, in denen anhand bestimmter Kriterien nach entsprechenden Servi-
ces gesucht werden kann [KrBS2005, 6f].
2.3.4
Entkopplung von Funktionalität und Technologie
Serviceorientierte Architekturen sollen die Unabhängigkeit von Funktionalitäten
und den ihnen zugrunde liegenden Technologien ermöglichen. Das bedeutet,
dass eine Entkopplung und damit die Unabhängigkeit der Geschäftsprozesse, von
deren technischer Implementierung ermöglicht werden soll [KrBS2005, 57].
Wesentlich für dieses Ziel ist der potenziell lange Lebenszyklus von Geschäfts-
prozessen, der kurzen technologischen Entwicklungszyklen gegenüber steht.
Eine Entkopplung von Funktionalität und Technologie soll vermeiden, dass sich
die Änderung einer Technologie auf die Geschäftsprozesse auswirkt, welche die
Funktionalitäten nutzen [KrBS2005, 7]. Änderungen auf technischer Ebene, etwa
bei der Implementierung bestimmter Funktionalitäten oder der Nutzung spezifi-
scher Technologien, sind so ohne Auswirkungen auf Geschäftsprozesse möglich.
Grundlagen serviceorientierter Architekturen
10
Eine derartige Trennung geht folglich mit einer verminderten Technikzentrierung
von Softwarearchitekturen in Unternehmen einher. Damit werden heterogene
Systemlandschaften realisierbar, innerhalb derer ein Geschäftsprozess die Funk-
tionen verschiedener Systeme nutzen kann, während diese unabhängig von-
einander austauschbar sind.
2.4
Elemente
Für die Umsetzung des Paradigmas der Serviceorientierung (vgl. 2.2) und die
Erreichung der damit assoziierten Ziele (vgl. 2.3), existieren bestimmte Ele-
mente. Hierbei handelt es sich um fundamentale Bestandteile, aus denen servi-
ceorientierte Architekturen aufgebaut sind. Die folgenden Abschnitte stellen mit
dem Service, der Servicebeschreibung sowie dem Ausführungskontext, diese
Elemente im Detail vor.
2.4.1
Service und Servicerollen
Dem Paradigma der Serviceorientierung folgend (vgl. 2.2), stellt ein Service
allgemein einen Mechanismus für die Vermittlung von Leistungen zwischen ei-
nem Anbieter und einem Nachfrager in Unternehmen dar. In technischer Hinsicht
bietet ein Service die Möglichkeit, auf eine Leistung oder eine Menge von Leis-
tungen zugreifen und diese nutzen zu können [MLMB2006, 12; KrBS2005, 59].
Unter einer Leistung kann eine Funktionalität verstanden werden, die von einem
Softwaresystem oder einem Teilsystem dessen erzeugt wird.
Demzufolge lassen sich im Bezug auf Services zwei Rollen identifizieren. Die des
Anbieters und die des Nachfragers einer Leistung. Anbieter und Nachfrager stel-
len technische Entitäten dar, welche mit dem Service interagieren. Der Nach-
frager (Service Consumer) hat ein bestimmtes Bedürfnis in Form einer Aufgabe
die durchgeführt werden muss. Um dieses Bedürfnis zu befriedigen, nimmt der
Service Consumer die Leistung bzw. Funktionalität einer anderen Entität in
Anspruch. Diese Leistung, in dem Fall die Durchführung der entsprechenden Auf-
gabe, wird durch den Anbieter (Service Provider) erstellt. Der Service stellt die
technische Schnittstelle zwischen beiden Parteien dar. Er bietet dem Service
Consumer die Möglichkeit, die Leistung des Service Providers zu nutzen. Ein Ser-
vice kapselt damit die Leistungen, welche von einem Service Provider angeboten
werden. Das bedeutet die Interaktion zwischen Service Provider und Consumer
findet nur über den Service, aber nicht direkt statt. Der potenzielle Service Con-
sumer muss dem Service Provider daher auch nicht bekannt sein [MLMB2006,
12].
Grundlagen serviceorientierter Architekturen
11
Zu betonen ist an dieser Stelle die klare Trennung zwischen der Rolle des Service
Providers und der des Service Consumers. Der Service selbst ist lediglich Ver-
mittler zwischen Anbieter und Nachfrager, der den Zugang zu einer Leistung
bereitstellt, nicht jedoch die Leistung selber erbringt [MLMB2006, 13]. Bezüglich
der Terminologie finden in der Literatur zum Teil auch die Begriffe Client für
Service Consumer und Server für Service Provider Verwendung [KrBS2005, 14].
2.4.2
Servicebeschreibung
Die Servicebeschreibung (Service Description) dient der Dokumentation eines
Services. Sie stellt alle Informationen bereit, welche für die Interaktion mit dem
Service erforderlich sind [MLMB2006, 20]. Die Servicebeschreibung kann sowohl
von einem Service Consumer als auch von einem Service Provider genutzt wer-
den. Insbesondere wird es dem Service Consumer dadurch ermöglicht, auf Basis
der Informationen über unterschiedliche Services denjenigen auszuwählen, der
für die Nutzung in einer konkreten serviceorientierten Architektur am besten
geeignet erscheint [MLMB2006, 21].
Zu den Informationen die ein Service bereitstellen muss, zählen Informationen
darüber, welche Leistungen er anbietet und wie die angebotenen Leistungen ge-
nutzt werden können. Weiterhin muss die Beschreibung Angaben über die be-
züglich der Interaktion mit dem Service geltenden Bedingungen enthalten
[MLMB2006, 21]. Im Detail umfassen die Bestandteile einer Servicebeschreibung
die Aspekte Erreichbarkeit, Funktionalität, Policies, Service Interface und Servi-
cevertrag.
2.4.2.1
Erreichbarkeit
Grundlage einer Interaktion zwischen einem Service und einem Service Con-
sumer oder Provider ist die technische Erreichbarkeit des Services über ein
Netzwerk. Die Servicebeschreibung muss entsprechend Informationen darüber
enthalten, wo und wie ein Service zum Zweck der Nutzung erreichbar ist. Hierbei
kann es sich etwa um Details über den Standort des Services sowie die von ihm
unterstützten Protokolle zur Kommunikation handeln. Ebenso wie Informationen
über seine aktuelle Verfügbarkeit. Angaben dieser Art sind Voraussetzung für
eine Interaktionsbeziehung mit dem Service [MLMB2006, 21f].
2.4.2.2
Funktionalität
In der Servicebeschreibung sollte die vom Service bereitgestellte Funktionalität
bzw. Leistung sowie die mit deren Nutzung verbundenen Auswirkungen (Realwelt
Effekt) (vgl. 2.5.3), eindeutig spezifiziert werden. Eine derartige Auswirkung
kann zum Beispiel das Ergebnis der Durchführung einer bestimmten Berechnung
Grundlagen serviceorientierter Architekturen
12
sein, welches der Service Consumer als Resultat der Servicenutzung erhält
[MLMB2006, 21].
Inhalt dieses Teils der Servicebeschreibung können eine textuelle Beschreibung
der Funktionalität für den menschlichen Nutzer eines Services sein sowie tech-
nische Informationen, wie beispielsweise Schlüsselwörter oder Bezeichner, für
die prozessuale Verarbeitung und die Nutzung durch einen maschinellen Nach-
frager (z.B. einen anderen Service). Das für eine Beschreibung auf Textbasis
gewählte Vokabular, muss dabei einerseits ausreichend sein, um die Funktio-
nalität in adäquater Form auszudrücken, andererseits aber verständlich für den
Benutzer bleiben. Zudem können auch eventuell geltende technische Voraus-
setzungen sowie Einschränkungen für die Servicenutzung beschrieben werden
[MLMB2006, 21f].
2.4.2.3
Policies
Die Policies stellen Richtlinien bzw. Bedingungen dar, welche in Verbindung mit
dem Service und der Interaktion mit diesem gelten. Eine Policy beschreibt, auf
die Verwendung des Services ausgerichtete, Bedingungen und Beschränkungen
[MLMB2006, 22]. Diese beziehen sich auf technische Aspekte, wie etwa Sicher-
heit, Vertraulichkeit oder die Servicequalität aber auch auf geschäftliche Aspekte,
wie die Zeiten der Verfügbarkeit eines Services oder gegebenenfalls anfallende
Gebühren für dessen Nutzung [MLMB2006, 23].
Zu den Bestandteilen einer Policy gehört die Policy Aussage (Policy Assertion).
Sie stellt eine allgemeine Aussage über den Umgang mit einem Service dar. Eine
solche Aussage muss durch die Interaktionsteilnehmer verarbeitbar sein. Weiter-
hin ist sie bewertbar und kann infolgedessen wahr oder falsch sein. Ein Beispiel
wäre eine Aussage der Form ,,Alle Nachrichten sind verschlüsselt.". Zudem ist die
Policy immer einem Besitzer (Policy Owner) zugeordnet, für den sie Gültigkeit
hat. Darüber hinaus umfasst die Policy Regeln für ihre Durchsetzung (Policy En-
forcement) [MLMB2006, 23]. Sie ermöglichen es eine Policy zu erzwingen, um
die Einhaltung der Policy Aussage zu gewährleisten. Auf diese Weise soll die
Durchführung nicht zulässiger Aktionen an einem Service und damit das poten-
zielle Auftreten eines ungültigen Zustandes verhindert werden [MLMB2006, 23].
2.4.2.4
Service Interface
Die Nutzung der Leistungen welche ein Service anbietet, erfolgt über das Service
Interface. Das Service Interface stellt einen Zugang zu den Leistungen des
Service Providers für die Service Consumer bereit [MLMB2006, 12; KrBS2005,
60]. Es verkörpert somit die Schnittstelle eines Services zu seinen Interaktions-
partnern.
Grundlagen serviceorientierter Architekturen
13
Das Service Interface ermöglicht die Interaktion mit dem Service. Dazu enthält
es Informationen über die Protokolle und Befehle, mit Hilfe derer die Leistungen
abgerufen werden, welche im Rahmen der Beschreibung der Funktionalitäten
(vgl. 2.4.2.2) verbal definiert worden sind. Dies beinhaltet eine Spezifikation
jener Informationen, die dem Service für die Nutzung der Funktionalitäten vom
Service Consumer zur Verfügung gestellt werden müssen (z.B. Aufrufparameter)
[KrBS2005, 59f].
Wichtig ist in diesem Zusammenhang, dass ein Interface den öffentlich zugäng-
lichen Teil eines Services repräsentiert [KrBS2005, 60]. Es stellt die Leistungen
des Services nach außen hin für einen Service Consumer bereit, so dass dieser
sie, unabhängig von ihrer konkreten technischen Implementierung, nutzen kann.
Entsprechend bleibt die technische Realisierung der angebotenen Leistung dem
Service Consumer verborgen [MLMB2006, 12].
2.4.2.5
Servicevertrag
Der Servicevertrag (Service Contract) stellt eine Vereinbarung zwischen zwei
oder mehreren Teilnehmern einer Leistung dar [MLMB2006, 24; Erl2005, 37].
Mit Teilnehmern sind in diesem Fall Services und Service Consumer gemeint. Im
Servicevertrag wird der Zweck, die Funktionalität, sowie die Bedingungen für
eine Verwendung des Services spezifiziert [KrBS2005, 59]. Im einzelnen können
dazu unter anderem Vereinbarungen zur Qualität der angebotenen Leistung, zur
Schnittstelle über die diese bereitgestellt wird, bis hin zu wirtschaftlichen Verein-
barungen gehören [MLMB2006, 24].
Mit dem Vertrag verbunden ist dadurch auch eine messbare Definition, der
Anforderungen und Erwartungen zweier oder mehrerer Parteien (Service, Service
Consumer, Service Provider) [MLMB2006, 24]. Aufgrund dessen muss, als
Grundlage der Interaktion mit einem Service, immer ein derartiger Servicever-
trag existieren [KrBS2005, 60; Erl2005, 291]. Er kann sowohl in maschinell les-
barer Form verfasst sein, als auch in verbaler Form [MLMB2006, 24].
2.4.3
Ausführungskontext
Die Durchführung von Interaktionen mit einem Service erfolgt immer in einem
Ausführungskontext [MLMB2006, 8]. Der Ausführungskontext repräsentiert die
Gesamtheit der Elemente, welche den Kontext der Ausführung einer Interaktion
bilden [MLMB2006, 24]. Er beinhaltet als wesentliche Bestandteile die Infra-
strukturelemente, Richtlinien und Übereinkünfte, welche im Rahmen der Inter-
aktion als Grundlage der Vermittlung zwischen den teilnehmenden Parteien
gelten [MLMB2006, 24f]. Der Ausführungskontext kann außerdem von dritten
Grundlagen serviceorientierter Architekturen
14
Parteien aufgestellte Regeln und Einschränkungen einbeziehen (z.B. Gesetze,
Vorschriften) [MLMB2006, 25].
Da jede Service Instanz sich in einem eigenen Ausführungskontext befindet, er-
laubt dieser auch die Unterscheidung unterschiedlicher Instanzen desselben
Services [MLMB2006, 25]. Die Bedingungen des Ausführungskontextes können
im Laufe einer Interaktion variieren. Beispielsweise wäre es möglich, dass die
Interaktionspartner ab einem bestimmten Schritt der Interaktion entscheiden,
dass Nachrichten ab sofort nur noch verschlüsselt übertragen werden
[MLMB2006, 25].
2.5
Konzepte
Im Zusammenhang mit ihren Bestandteilen (vgl. 2.4), sind serviceorientierte
Architekturen gekennzeichnet durch verschiedene Grundkonzepte. Als elemen-
tare Konzepte sind hier die Sichtbarkeit, die Interaktion und der Realwelt Effekt
zu nennen [MLMB2006, 8]. Sie repräsentieren Schlüsselkonzepte für service-
orientierte Architekturen und beziehen sich vor allem auf die Services und auf
deren Interaktion.
2.5.1
Sichtbarkeit
Wie in der Realwelt, müssen als Voraussetzung für eine Interaktion zwischen
dem Nachfrager und dem Anbieter einer Leistung bestimmte Bedingungen erfüllt
sein und Informationen über die Interaktionspartner vorliegen [MLMB2006, 8;
MLMB2006, 13]. Um diese, unter dem Aspekt der Sichtbarkeit zusammenge-
fassten, Voraussetzungen gewährleisten zu können, werden die Servicebeschrei-
bungen bereitgestellt (vgl. 2.4.2). Sie enthalten unter anderem Informationen
bezüglich der Funktionen, technischen Anforderungen und Beschränkungen eines
Services [MLMB2006, 8].
Die Sichtbarkeit setzt sich zusammen aus dem Bewusstsein, der Bereitschaft
und der Erreichbarkeit. Diese Aspekte müssen als Voraussetzung für eine erfolg-
reiche Interaktion zwischen deren Teilnehmern erfüllt sein.
2.5.1.1
Bewusstsein
Primäre Voraussetzung für eine Interaktion ist das Bewusstsein der Interaktions-
partner. Sie müssen sich der Existenz des jeweils anderen bewusst sein bzw.
Kenntnis von dessen Existenz haben. Dies impliziert für den Service, als Ver-
mittler der Leistung des Anbieters, das Vorhandensein einer Beschreibung und
einer Policy der Leistungen (vgl. 2.4.2) [MLMB2006, 14f].
Grundlagen serviceorientierter Architekturen
15
Im Gesamtkontext einer serviceorientierten Architektur setzt dies darüber hinaus
die Existenz von Möglichkeiten des Zugangs zu solchen Informationen voraus,
damit potenzielle Service Consumer die Services identifizieren können, welche
für spezifische Aufgaben geeignet sind [MLMB2006, 14f]. Eine Möglichkeit ent-
sprechende Informationen zugänglich zu machen, kann zum Beispiel ein Servi-
ceverzeichnis (Service Repository) sein, das einen Überblick einschließlich einer
Beschreibung verfügbarer Services bietet [Erl2005, 44].
Bewusstsein bedeutet allerdings nicht zwangsläufig, dass die Interaktionspartner
auch miteinander interagieren wollen (Aspekt der Bereitschaft) oder technisch
dazu in der Lage sind (Aspekt der Erreichbarkeit).
2.5.1.2
Bereitschaft
Neben den Informationen, welche die Teilnehmer als Grundlage für eine Inter-
aktion benötigen, ist eine zweite Voraussetzung für die Sichtbarkeit die gemein-
same Bereitschaft der Teilnehmer, miteinander zu interagieren. Die Initiierung
und Durchführung einer Interaktion mit einem Service stellt demzufolge immer
eine bewusste Handlung dar [MLMB2006, 15]. Der Aspekt der Bereitschaft be-
schränkt sich dabei auf die Interaktion selbst und meint nicht die Bereitschaft
der tatsächlichen Erbringung oder Nutzung einer Leistung. Die Regelung der Be-
dingungen einer Bereitschaft zur Interaktion, erfolgt über die Policies im Rahmen
der Servicebeschreibung [MLMB2006, 15].
2.5.1.3
Erreichbarkeit
Das Bewusstsein der Teilnehmer einer Interaktion für die Existenz des jeweils
anderen sowie die Bereitschaft miteinander zu interagieren, reichen für die
Durchführung der Interaktion alleine nicht aus. Zusätzlich müssen die notwen-
digen technischen Rahmenbedingungen für eine Interaktion erfüllt sein.
Als dritte Voraussetzung für die Sichtbarkeit ist es daher erforderlich, dass die
Interaktionspartner grundsätzlich in der Lage sind, miteinander zu interagieren.
Dies erfordert auf technischer Ebene insbesondere die Möglichkeit der Kommuni-
kation, um Informationen, etwa in Form von Nachrichten, austauschen zu kön-
nen. Andernfalls kann etwa das Fehlen einer Kommunikationsverbindung zwi-
schen Service Consumer und Service auch bei vorhandenem Bewusstsein und
Bereitschaft eine Interaktion verhindern [MLMB2006, 15].
2.5.2
Interaktion
Das Konzept der Interaktion beschreibt die Art und Weise, in der eine angebote-
ne Leistung im Rahmen einer serviceorientierten Architektur nutzbar ist
[MLMB2006, 8]. Zu diesem Zweck findet eine Interaktion zwischen dem Service
Grundlagen serviceorientierter Architekturen
16
Consumer und dem Service statt. Diese erfolgt in Form eines Austauschs von
Nachrichten zwischen den beiden Parteien [MLMB2006, 8; MLMB2006, 15].
Das Referenzmodell serviceorientierter Architekturen definiert im Zusammen-
hang mit dem Konzept der Interaktion weiterhin das Informationsmodell und das
Verhaltensmodell. Das Informationsmodell [MLMB2006, 16f] beinhaltet Aspekte
im Bezug auf die Informationen, die mit einem Service ausgetauscht werden
können. Es beschreibt die Struktur und die Semantik der ausgetauschten Nach-
richten, als Grundlage der effektiven Kommunikation mit dem Service. Das Ver-
haltensmodell [MLMB2006, 17f] beinhaltet Aspekte im Hinblick auf die Aktionen,
die ein Service zur Verfügung stellt. Es fokussiert besonders die Kenntnis der
Aktionen und ihrer Rückgaben (Aktionsmodell) sowie die zeitlichen Abhängig-
keiten zwischen den Aktionen und Ereignissen im Rahmen einer Service-
interaktion (Prozessmodell).
2.5.3
Realwelt Effekt
Der Realwelt Effekt bezeichnet den Effekt, der als Resultat einer Interaktion
eines Service Consumers mit einem Service eintritt [MLMB2006, 8]. Der Realwelt
Effekt beschreibt somit die Auswirkungen der Nutzung des Services bzw. der von
dem Service bereitgestellten Leistung. Die Erreichung eines solchen Effektes
durch die Verwendung des Services, ist das Ziel einer Interaktion mit dem Ser-
vice. Dieses Ziel wird mit der Erbringung der mit dem Service assoziierten Leis-
tung durch den Service Provider erfüllt [MLMB2006, 18]. Ein Realwelt Effekt
wäre beispielsweise die Antwort auf eine spezifische Anfrage, die Änderung des
Zustandes einer Entität, oder die Rückgabe bestimmter Informationen
[MLMB2006, 8].
Eine Beschreibung des Realwelt Effektes sollte Bestandteil der Servicebe-
schreibung sein. Sie zeigt dem Service Consumer, welche Effekte ein Service
bewirken kann und ob er damit die vom Service Consumer gewünschten Funkti-
onalitäten erfüllt [MLMB2006, 8].
2.6
Aufbau und Kontext
Im Kontext von Unternehmen, wird das Konzept der Serviceorientierung (vgl.
2.2) und die damit verbundenen Elemente (vgl. 2.4) und Konzepte (vgl. 2.5),
auf die Unternehmenslogik angewendet. Die Unternehmenslogik setzt sich zu-
sammen aus den Bereichen Geschäftslogik und Anwendungslogik (vgl. Abbildung
2.2). Beide Bereiche ändern sich kontinuierlich und unterliegen sowohl internen
als auch externen Einflüssen [Erl2005, 280].
Grundlagen serviceorientierter Architekturen
17
Abbildung 2.2: Aufbau der Unternehmenslogik
Quelle: in Anlehnung an [Erl2005, 281]
Die Geschäftslogik umfasst nach [Erl2005, 281], ausgehend von den Geschäfts-
bereichen des Unternehmens, eine Dokumentation der implementierten Ge-
schäftsanforderungen. Die Geschäftsanforderungen drücken sich in den Ge-
schäftsprozessen aus. Diese bilden, einschließlich der geltenden Einschrän-
kungen, vorhandenen Abhängigkeiten sowie den äußeren Einflüssen, in ihrer
Gesamtheit die Geschäftslogik [Erl2005, 281].
Die Anwendungslogik stellt eine Implementierung der Geschäftslogik in Form
unterschiedlicher technischer Lösungen dar [Erl2005, 281]. Im Rahmen der An-
wendungslogik werden Geschäftsprozessabläufe durch eingekaufte oder selbst-
entwickelte Softwaresysteme (Anwendungen) repräsentiert. Die Grenzen der
Anwendungslogik bildet die gesamte IT-Infrastruktur des Unternehmens. Dazu
zählen auch die Sicherheitsbeschränkungen der Infrastruktur, die technischen
Fähigkeiten ihrer Bestandteile und gegebenenfalls vorhandene Abhängigkeiten
von Anbietern einzelner Bestandteile [Erl2005, 288].
Im Kontext der Serviceorientierung, kann als dritter Bereich in einer Orga-
nisation die Servicelogik betrachtet werden. Sie besteht zwischen Geschäfts- und
Anwendungslogik und dient im Sinne des Paradigmas der Serviceorientierung
(vgl. 2.2) zur Vermittlung zwischen den Anbietern von Leistungen und deren
Nachfragern innerhalb von Geschäftsprozessen. Die Servicelogik repräsentiert
damit eine neue Konzeption, besonders im Bezug auf das Verständnis und die
Grundlagen serviceorientierter Architekturen
18
Repräsentation der Unternehmenslogik [Erl2005, 281]. Sie überträgt das Para-
digma der Serviceorientierung auf Unternehmen.
Abbildung 2.3: Aufbau einer serviceorientierten Architektur
Quelle: in Anlehnung an [Erl2005, 282]
Die drei Bereiche unterscheiden sich jedoch nicht nur hinsichtlich ihrer Konzep-
tion. Vielmehr variieren sie auch bezüglich der Technologien, mit denen sie sich
umsetzen lassen [MLMB2006, 9]. Zu betonen ist, dass Serviceorientierung ein
allgemeines Konzept darstellt, welches nicht an konkrete Technologien gebunden
ist. Die technische Umsetzung kann somit auf unterschiedliche Weise erfolgen
[KrBS2005, 14].
Die Darstellung einer serviceorientierten Gesamtarchitektur, kann demnach in
Form eines dreischichtigen Modells erfolgen (vgl. Abbildung 2.3). Das Modell
umfasst die Anwendungslogik in Form einer Anwendungsschicht, die Servicelogik
in Form einer Serviceschicht und die Geschäftslogik in Form einer Prozessschicht
Grundlagen serviceorientierter Architekturen
19
[Erl2005, 281; Arsa2004]. Alle drei Schichten einschließlich ihrer Bestandteile
und Beziehungen, sind Gegenstand der nächsten Abschnitte.
2.6.1
Anwendungsschicht
Die Anwendungsschicht bildet das Fundament einer serviceorientierten Archi-
tektur. Sie stellt die niedrigste Abstraktionsstufe, bezüglich der technischen Rea-
lisation von Leistungen, im Kontext einer serviceorientierten Architektur dar. Als
Anwendung kann eine Menge von Softwareartefakten gesehen werden, die eine
bestimmte Funktionalitäten umsetzen [KrBS2005, 56]. Diese Funktionalitäten
repräsentieren die Leistung, welche von einer Anwendung erstellt wird.
Die verschiedenen in einem Unternehmen eingesetzten Softwaresysteme bzw.
Anwendungen, bestehen aus unterschiedlichen Artefakten, wie etwa Klassen
oder Komponenten. Sie grenzen sich vor allem was ihre Funktionalität und die
ihnen jeweils zugrunde liegende technische Plattform betrifft (z.B. JAVA EE,
.NET), voneinander ab [Erl2005, 282]. Die Gesamtheit aller Anwendungen in
einem Unternehmen wird auch mit dem Begriff der Anwendungslandschaft be-
zeichnet [KrBS2005, 56].
2.6.2
Serviceschicht
Die Serviceschicht bildet sich aus der Gesamtheit der Services, die in einer
serviceorientierten Architektur existieren. Jeder Service stellt eine logische, in
sich geschlossene Einheit dar, welche eine bestimmte Anwendungsfunktionalität
kapselt und zur Verfügung stellt (vgl. 2.4.1) [Erl2005, 282]. Die Realisation der
Anwendungsfunktionalität erfolgt auf der Anwendungsschicht (vgl. 2.6.1)
[Erl2005, 283]. Der Service ermöglicht es den Prozessen der Prozessschicht (vgl.
2.6.3), auf die Funktionalitäten zuzugreifen, welche sie zur Durchführung ihrer
jeweiligen Aufgabe benötigen [Erl2005, 281f]. Auf diese Weise bildet die Servi-
ceschicht eine Abstraktionsebene zwischen der Anwendungsschicht und der
Prozessschicht
[Erl2005, 281].
Services können innerhalb der Serviceschicht aggregiert werden. Somit ist es
möglich, dass ein Service mehrere andere Services und die von Ihnen bereitge-
stellten Funktionalitäten kapselt. Dementsprechend lassen sich innerhalb der
Serviceschicht weitere (optionale) Subschichten unterteilen, die jeweils eigene
Abstraktionsebenen darstellen (vgl. Abbildung 2.4) [Erl2005, 282]. Die Sub-
schichten der Serviceschicht umfassen die Anwendungsserviceschicht, Ge-
schäftsserviceschicht und die Orchestrierungsserviceschicht.
Grundlagen serviceorientierter Architekturen
20
Abbildung 2.4: Subschichten der Serviceschicht
Quelle: in Anlehnung an [Erl2005, 337]
2.6.2.1
Anwendungsserviceschicht
Die in dieser Subschicht existenten Services werden auch als Anwendungs-
services bezeichnet. Sie kapseln einfache, wiederverwendbare Funktionalitäten,
welche durch die Anwendungsschicht
(vgl. 2.6.1) realisiert werden [Erl2005,
337].
Die Anwendungsservices setzen damit direkt auf den vorhandenen Anwendungen
auf, indem sie einzelne Funktionalitäten dieser bereitstellen, welche für unter-
schiedliche Aufgaben wiederverwendbar sind. Zusätzlich können eingekaufte
Anwendungsservices von proprietären Herstellern Bestandteil dieser Schicht sein
[Erl2005, 338f]. Die Anwendungsservices fungieren damit prinzipiell als Werk-
zeuge, welche für die Realisation komplexerer Aufgaben im Rahmen der nächst-
höheren Subschicht (Geschäftsserviceschicht), verwendbar sind. Sie können
auch aus anderen, Anwendungsservices zusammengesetzt sein [Erl2005, 338f].
2.6.2.2
Geschäftsserviceschicht
Die Geschäftsserviceschicht enthält die eigentlichen Geschäftsservices. Diese
bilden aus Funktionalitäten der darunter liegenden Anwendungsservices Teile der
Geschäftslogik, welche im Rahmen der Durchführung von Geschäftsprozessen
auf der Prozessschicht verwendet wird. Ein Geschäftsservice repräsentiert somit
einen spezifischen Teil der Geschäftslogik, der von den darunter liegenden An-
wendungsservices realisiert wird. Geschäftsservices grenzen sich daher von
Anwendungsservices ab, welche eher technische Funktionalitäten kapseln und
bereitstellen. Die Geschäftsservices bilden den Kern einer serviceorientierten
Architektur [Erl2005, 341].
Die Services können unterschieden werden in aufgabenzentrierte sowie enti-
tätenzentrierte Geschäftsservices. Aufgabenzentrierte Geschäftsservices stellen
Geschäftslogik bereit, die Bestandteil einer konkreten Aktivität im Kontext eines
Grundlagen serviceorientierter Architekturen
21
Geschäftsprozesses ist. Entitätenzentrierte Geschäftsservices stellen die Ge-
schäftslogik bereit, die zu einer Entität (z.B. einer Rechnung) gehört [Erl2005,
342].
2.6.2.3
Orchestrierungsserviceschicht
Wie in der Realwelt auch, besteht zwischen dem Leistungsangebot einzelner An-
bieter - in diesem Fall repräsentiert durch Services - und dem Bedarf einzelner
Nachfrager - in diesem Fall repräsentiert durch die Aktivitäten eines Prozesses -
nicht zwangsläufig eine eindeutige Beziehung. Das bedeutet, es reicht nicht im-
mer die Leistung eines einzelnen Anbieters aus, um ein Bedürfnis zu befriedigen.
Daher kann es aus Nachfragersicht notwendig sein, für die Erfüllung eines be-
stimmten Bedürfnisses die Leistungen mehrerer Anbieter in Anspruch zu neh-
men.
Im Bezug auf Services in einer serviceorientierten Architektur kann es infolge-
dessen erforderlich sein, die von unterschiedlichen Services bereitgestellten
Funktionalitäten zu kombinieren [MLMB2006, 8]. Die Kombination der Funktio-
nalitäten mehrerer Services durch einen einzelnen, übergeordneten Service, wird
als Orchestrierung bezeichnet [Erl2005, 200f]. Sie findet auf der Orchestrie-
rungsserviceschicht statt. Dabei können orchestrierte Services auch wieder Be-
standteil größerer Serviceorchestrierungen sein. Die Granularität ist hierbei vari-
abel und kann von einfachen Orchestrierungen, die nur einige wenige Services
kapseln, bis hin zu hochkomplexen Orchestrierungen reichen, welche die Funkti-
onalität einer Vielzahl von Services repräsentieren [MLMB2006, 8].
Durch Orchestrierung werden zusammengesetzte Services geschaffen, die sich,
was die durch sie repräsentierten Funktionalitäten betrifft, an den konkreten
Aktivitäten von Geschäftsprozessen orientieren. Die Orchestrierungsservice-
schicht verknüpft damit die Geschäftslogik der Prozessschicht (vgl. 2.6.3) mit
der Servicelogik auf der Serviceschicht (vgl. 2.6.2)
[Erl2005, 344].
2.6.3
Prozessschicht
Die Prozessschicht beinhaltet die Geschäftsprozesse eines Unternehmens, ein-
schließlich der Aktivitäten, aus denen diese bestehen [Erl2005, 288]. Die Pro-
zessschicht wird zum Teil auch als Geschäftsprozessschicht bezeichnet. Für die
Durchführung der einzelnen Aktivitäten werden die Leistungen technischer Sys-
teme benötigt. Diese Leistungen werden durch die vorhandenen Software-
systeme auf der Anwendungsschicht realisiert (vgl. 2.6.1) und sind über die
Services der Serviceschicht
(vgl. 2.6.2), im Rahmen von Geschäftsprozessen
nutzbar.
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Erscheinungsjahr
- 2007
- ISBN (eBook)
- 9783836604086
- DOI
- 10.3239/9783836604086
- Dateigröße
- 1.6 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Universität Duisburg-Essen – Wirtschaftswissenschaft
- Erscheinungsdatum
- 2007 (Juni)
- Note
- 1,0
- Schlagworte
- serviceorientierte architektur visualisierung software informatik unified modeling language stakeholder
- Produktsicherheit
- Diplom.de
