An Architectural Decision Modeling Framework for Service-Oriented Architecture Design

248 Pages·2010·1.92 MB·English

An
Architectural Decision Modeling
Framework for Service-Oriented
Architecture Design

Von der Fakultät Informatik, Elektrotechnik und Informa-
tionstechnik der Universität Stuttgart zur Erlangung der
Würde eines Doktors der Naturwissenschaften (Dr. rer.
nat.) genehmigte Abhandlung

Vorgelegt von
Olaf Zimmermann

aus Salzgitter, wohnhaft in Zürich (Schweiz)

Hauptberichter: Prof. Dr. Frank Leymann
Mitberichter: Prof. Dr. Michael Papazoglou

Tag der mündlichen Prüfung: 17. März 2009

Institut für Architektur von Anwendungssystemen
der Universität Stuttgart
2009

Zusammenfassung
Die Nutzung von Informationstechnologie ist heutzutage für Unternehmen in na-
hezu allen Branchen unentbehrlich. Unternehmensanwendungen unterstützen die
Ausführung von Geschäftsprozessen und automatisieren diese teilweise. Die Ent-
wicklung und Integration qualitativ hochwertiger Unternehmensanwendungen, die
als geschichtete und verteilte Softwaresysteme charakterisiert werden können,
stellt eine große Herausforderung dar. In den letzen Jahren sind die Konzepte der
dienstorientierten Architektur (engl. Service-Oriented Architecture, SOA) zu ei-
nem wichtigen Architekturstil für die Entwicklung und Integration von Unterneh-
mensanwendungen herangereift. Aus Benutzersicht betont SOA die geschäftliche
Ausrichtung der in Software realisierten Dienste. Aus architektonischer Sicht stel-
len Modularität, loose Kopplung (d.h. Plattform-, Orts-, Protokoll-, und Format-
unabhängigkeit) sowie Schichtenbildung und Flussunabhängigkeit wichtige SOA-
Prinzipien dar. Zentrale SOA-Muster sind Dienstnehmer-Geber-Vertrag, unter-
nehmensweiter Dienstbus (engl. Enterprise Service Bus, ESB), Dienstkomposition
und Dienstverzeichnis.
Dienstnehmer und -geber sowie ESB- und Dienstkompositions-Infrastruktur
müssen zahlreiche nichtfunktionale Anforderungen (NFA) erfüllen. Viele NFA
betreffen Software-Qualitätsattribute in Bereichen wie Zuverlässigkeit, Benutzer-
freundlichkeit, Effizienz, Wartbarkeit, und Portierbarkeit. Andere NFA resultieren
aus unternehmensweiten Architekturrichtlinien und Limitationen von Altanwen-
dungen. Von anderen Architekturstilen bereits bekannte, aber auch neue Heraus-
forderungen sind zu meistern, wie zum Beispiel Schnittstellenvertragsgestaltung
und die gleichzeitige Versorgung vieler heterogener Dienstnehmer. Die resultie-
renden Entwurfsfragen sind nicht einfach zu beantworten; es werden daher
Entwurfsmethoden benötigt. Die heute existierenden Entwurfsmethoden stellen
viele Dienstidentifikations- und Dienstspezifikationstechniken zur Verfügung; sie
decken die Dienstrealisierung jedoch nur unzureichend ab. In der Praxis hat sich
gezeigt, dass zur erfolgreichen Realisierung von Diensten hoher Qualität und Ent-
wurfseleganz wesentlich mehr gehört als die Dienste in fachlichen Anforderungen
zu identifizieren, Web Services Description Language (WSDL)-Schnittstellen für
diese Dienste zu spezifizieren und WSDL-nach-Code-Generatoren aufzurufen:
Zahlreiche Architekturentscheidungen müssen getroffen werden.
Die Modellierung von Architekturentscheidungen ist ein aufkommendes Gebiet
in der Softwarearchitekturforschung. Im Unterschied zu anderen Notationen für
Softwarearchitekturen erfassen Architekturentscheidungsmodelle das Wissen, das
zu bestimmten Entwürfen führt und diese begründet (engl. Rationale). Architek-
turentscheidungen betreffen ein Softwaresystem als Ganzes oder die Kernkompo-
IV Zusammenfassung
nenten eines derartigen Systems. Architekturentscheidungen bestimmen die nicht-
funktionalen Eigenschaften eines Softwaresystems, zum Beispiel seine Qualitäts-
attribute. Jede Entscheidung behandelt ein konkretes Entwurfsproblem, für das ei-
ne oder mehrere Lösungsalternativen auszuwählen sind. Beispiele sind die Wahl
von Programmiersprachen und Werkzeugen sowie von Architekturmustern, Integ-
rationstechnologien und Middlewareprodukten.
Zwei Arten von Architekturentscheidungen, die im SOA-Entwurf erforderlich
sind, resultieren aus den oben aufgezählten SOA-Mustern: Eine Art von Architek-
turentscheidungen behandelt Dienstschnittstellenvertragsgestaltung inklusive der
Frage der Granularität (z.B. Struktur der ausgetauschten Nachrichten, Gruppie-
rung von Dienstoperationen). Eine andere Art von Architekturentscheidungen be-
trifft nichtfunktionale Aspekte der ESB-Integration und der Dienstkomposition
wie zum Beispiel Nachrichtenaustauschmuster und Systemtransaktionsgrenzen.
Durch die Vorauswahl des Architekturstils können Architekten von einem gro-
ßen Fundus an Architekturwissen profitieren. Dieses Wissen kann in zwei Berei-
che eingeteilt werden: Wissen, das zu der Definition der SOA-Prinzipien und
SOA-Muster geführt hat und Wissen, das in Projekten gesammelt wurde, welche
die Prinzipien und Muster zuvor angewendet haben. Beide Wissensbereiche beein-
flussen die Architekturentscheidungen, die in SOA-Projekten zu treffen sind.
Um Architekten durch den Architekturentscheidungsprozess zu führen, ist eine
SOA-Entwurfsmethode erforderlich. Der Entwurf einer derartigen Methode ist das
in dieser Arbeit gelöste Problem:
Wie kann das Fällen von Architekturentscheidungen während des SOA-
Entwurfs organisiert werden, ausgehend von funktionalen und nichtfunktionalen
Anforderungen und bereits gesammeltem Architekturwissen, das in Form von
SOA-Prinzipien und -Mustern dokumentiert ist?
Nach dem heutigen Stand der Technik werden Architekturentscheidungen ad
hoc und retrospektiv im aktuellen Projekt dokumentiert; dabei handelt es sich um
eine zeitintensive Aufgabe ohne unmittelbare positive Auswirkungen. Im Gegen-
satz dazu untersuchen wir die Rolle, die wieder verwendbare Architekturentschei-
dungsmodelle während des SOA-Entwurfs spielen können: Wir behandeln wie-
derkehrende Architekturentscheidungen als genuines Konzept in unserer Methode
und stellen ein Architekturentscheidungsmodellierungsrahmenwerk sowie ein
wieder verwendbares SOA-Entscheidungsmodell vor, das Architekten durch den
Entwurfprozess führt. Unsere Methode arbeitet werkzeuggestützt.
In unserem Rahmenwerk stellen wir eine Technik zur systematischen Identifi-
kation von wiederkehrenden Architekturentscheidungen zur Verfügung. Unser
SOA-Entscheidungsmodell ist nach einem Metamodell strukturiert, das Wieder-
verwendung und Zusammenarbeit unterstützt. Die Modellorganisation folgt den
Prinzipien der modellgetriebenen Architektur und separiert länger aktuell bleiben-
de plattformunabhängige Entscheidungen von sich häufig ändernden plattform-
spezifischen. Auf einer konzeptuellen Ebene werden SOA-Muster referenziert,
was die initiale Befüllung und laufende Pflege des Entscheidungsmodells erleich-
tert. Unser Entscheidungsabhängigkeitsmanagement hilft Architekten, die Mo-
dellkonsistenz zu prüfen und irrelevante Entscheidungen gar nicht erst zu betrach-
Zusammenfassung V
ten. Eine verwaltete Entscheidungsliste (engl. Managed Issue List) führt durch den
Entscheidungsprozess. Um Entscheidungs- und Entwurfsmodelle abzugleichen,
werden Entscheidungsausgangsinformationen in Entwurfsmodelltransformationen
injiziert. Ein Web-basiertes Kollaborationssystem bietet Werkzeugunterstützung
für die Schritte und Konzepte im Rahmenwerk.
Einer der Anwendungsfälle für das Entscheidungsmodellierungsrahmenwerk
und das wieder verwendbare SOA-Entscheidungsmodell ist die Nutzung als Ent-
wurfsmethode; weitere Anwendungsfälle sind Ausbildung, Wissensaustausch, Re-
view-Technik und Steuerungsinstrument (engl. Governance Instrument).
Es folgt eine Zusammenfassung der einzelnen Kapitel.
Kapitel 1: Einleitung
In diesem Kapitel führen wir das Anwendungsgenre der Unternehmensanwendun-
gen sowie SOA-Entwurf als Kontext dieser Arbeit ein. Wir geben einen Überblick
über den Stand der Technik im Bereich SOA-Entwurfsmethoden und leiten sieben
Forschungsprobleme ab. Weiterhin geben wir einen Überblick über unsere Lö-
sung, die aus einem Rahmenwerk für die Modellierung von Architekturentschei-
dungen, einem wieder verwendbaren Architekturentscheidungsmodell für SOA
und Werkzeugunterstützung besteht. Die Kombination von Rahmenwerk und Mo-
dell ergibt die gesuchte entscheidungszentrische SOA-Entwurfsmethode.
Kapitel 2: Stand der Technik und Praxisrealität
In diesem Kapitel charakterisieren wir die Herausforderungen für die Konstrukti-
on von Unternehmensanwendungen und stellen SOA als Architekturstil für die
Entwicklung und Integration von Unternehmensanwendungen vor. Wir verwenden
Architekturprinzipien und -muster, um SOA zu definieren und präsentieren eine
motivierende Fallstudie. Wir zeigen den Stand der Technik in den Bereichen Me-
thoden für Software Engineering und Entwurf, Methoden für Softwarearchitektur-
entwurf, Methoden für Entwicklung und Integration von Unternehmensanwen-
dungen, Methoden für SOA-Entwurf sowie Architekturwissensmanagement auf
und stellen einige in der Praxis verwendete Werkzeuge vor.
Kapitel 3: Anforderungen an SOA-Entwurfsmethoden und
resultierende Forschungsprobleme
In diesem Kapitel etablieren wir zunächst einen Anforderungskatalog für Metho-
den, die den SOA-Entwurf unterstützen. Wir verdichten diesen in die für den Ent-
wurf einer entscheidungszentrischen Methode besonders relevanten Anforderun-
VI Zusammenfassung
gen und formulieren die Forschungsprobleme, die zu lösen sind, damit diese An-
forderungen erfüllt werden können. Abschließend verwenden wir Anforderungs-
katalog und Forschungsprobleme, um die Stärken und Schwächen der den heuti-
gen Stand der Technik repräsentierenden Methoden aus Kapitel 2 zu analysieren.
Kapitel 4: Ein Rahmenwerk zur Modellierung von
Architekturentscheidungen im SOA-Entwurf
In diesem Kapitel führen wir das Konzept eines wieder verwendbaren Architek-
turentscheidungsmodells (engl. Reusable Architectural Decision Model, RADM)
ein. Wir unterscheiden zu treffende Entscheidungen (engl. Issues) von bereits ge-
troffenen (engl. Outcomes). Wir definieren ein Rahmenwerk für die Modellierung
von SOA-Architekturentscheidungen (engl. SOA Decision Modeling, SOAD), das
aus sieben Schritten besteht:
1. Entscheidungen identifizieren.
2. Einzelne Entscheidungen modellieren.
3. Modell strukturieren.
4. Entscheidungen auch zeitlich ordnen.
5. Modell auf Projektbedürfnisse zuschneiden.
6. Entscheidungen treffen unter Verwendung eines Entscheidungsmodells
als Architekturentwurfsmethode.
7. Entscheidungen durchsetzen.
Wir erläutern wie sich das Rahmenwerk in den Software-Lebenszyklus integ-
riert und stellen eine Architektur für die Werkzeugunterstützung des Rahmenwer-
kes vor. Außerdem wenden wir das Rahmenwerk auf den SOA-Entwurf und die
motivierende Fallstudie aus Kapitel 2 an.
Kapitel 5: Umfang wieder verwendbarer
Architekturentscheidungsmodelle festlegen
Entscheidungen identifizieren. Wir stellen eine neuartige Technik für die Identi-
fikation von wieder verwendbarem Architekturentscheidungswissen in Architek-
turmustern als Schritt 1 im Rahmenwerk vor:
Welche Architekturentscheidungen kehren wieder im SOA-Entwurf?
Können solche Entscheidungen systematisch in Mustern identifiziert werden?
Die Technik arbeitet mit mehreren Typen von Entscheidungen:
1. Executive-Entscheidungen zur Projektdefinition und technischen Projekt-
ausrichtung sowie zur Anforderungsanalyse.
2. Entscheidungen zur Selektion und Adoption von konzeptuellen Mustern.
Zusammenfassung VII
3. Technologieentscheidungen wie zum Beispiel Wahl von Containern, Pro-
tokollen, Betriebssystemen sowie Festlegung von technologiespezifi-
schen Nutzungsprofilen (engl. Technology Profiling).
4. Entscheidungen zur Auswahl und Konfiguration von Softwareprodukten.
Wir stellen Identifikationsregeln für diese Typen auf und führen einen Katalog
von architekturstilunabhängigen Meta-Entscheidungen als Technikelemente ein.
Kapitel 6: Befüllen wieder verwendbarer
Architekturentscheidungsmodelle
Einzelne Entscheidungen modellieren. Für Schritt 2 stellen wir ein Metamodell
für die Architekturentscheidungsmodellierung bereit. Es löst das folgende Prob-
lem:
Welche Informationen sind für jede zu treffende und wiederkehrende
Architekturentscheidung (engl. Issue) zu modellieren?
Aufgrund des Umfangs und der inhärenten Komplexität des Entscheidungswis-
sens hat eine Modellierung der Issues Vorteile gegenüber der Erfassung in struktu-
riertem oder unstrukturiertem Text. Es ist unerlässlich, ein einheitliches Format zu
definieren, um das Entscheidungswissen austauschbar und vergleichbar zu ma-
chen. Dazu erweitern wir existierende Arbeiten aus dem Bereich Architekturwis-
sensmanagement. Um die Entscheidungsmodelle wieder verwendbar zu machen,
modellieren wir den wiederkehrenden Entscheidungsbedarf, das Issue, getrennt
vom projektspezifischen Entscheidungsausgang, dem Outcome.
Modell strukturieren. Schritt 3 behandelt die Organisation eines in den vorheri-
gen beiden Schritten gewonnenen Modells:
Wie können Architekturentscheidungsmodelle in einer intuitiven, anwendungsfall-
getriebenen Art und Weise organisiert werden?
Architekturentscheidungsmodelle sind komplex: sie müssen nicht nur die Is-
sues detailliert beschreiben, sondern auch die logischen Beziehungen zwischen
den Issues. Eine Organisation nach Verfeinerungsebenen und Architekturschich-
ten stellt die Benutzbarkeit derartiger Modelle sicher. Weiterhin können mit dieser
Modellorganisation Entwurfsfehler aufgedeckt werden.
Entscheidungen auch zeitlich ordnen. Um Entscheidungsmodelle als Entwurfs-
methode nutzbar zu machen, klären wir im Schritt 4:
Wie können zeitliche Abhängigkeiten von Entscheidungen repräsentiert werden?
Wir können die Entscheidungen geordnet werden in Vorbereitung der Nutzung ei-
nes Entscheidungsmodells als Methode?
Wir erweitern unser Metamodell um Aspekte der kontextabhängigen, dynami-
schen Nutzung des Entscheidungswissens. Dieses ermöglicht uns, dem Architek-
VIII Zusammenfassung
ten nur eine Untermenge der Entscheidungen im Modell anzubieten basierend auf
bereits getroffenen Entscheidungen. Damit ist der Architekt mit weniger Entschei-
dungen konfrontiert, was zu einem effizienteren Entscheidungsprozess führt.
Kapitel 7: Erstellen und Benutzen von
Architekturentscheidungsmodellen in Projekten
Modell auf Projektbedürfnisse zuschneiden. Nachdem Entscheidungen identifi-
ziert, modelliert und organisiert sind, behandelt Schritt 5:
Wie kann ein wieder verwendbares Architekturentscheidungsmodell auf Projekt-
bedürfnisse angepasst werden?
Das in diesem Schritt eingeführte Konzept ist das Filtern von Entscheidungen.
Entscheidungen treffen. Das in Schritt 6 gelöste Problem ist:
Wie kann ein Architekturentscheidungsmodell als SOA-Entwurfsmethode einge-
setzt werden?
Wir führen eine verwaltete Entscheidungsliste (engl. Managed Issue List), ei-
nen projektweiten Makroprozess und einen entscheidungsweiten Mikroprozess
ein. Um den Methodeneinsatz zu demonstrieren, wenden wir die Prozesse auf die
motivierende Fallstudie aus Kapitel 2 an.
Entscheidungen durchsetzen. Schritt 7 führt Modelltransformationen ein, die
Architekturentscheidungen als Eingabeparameter berücksichtigen:
Wie kann durchgesetzt werden, dass die getroffenen Entscheidungen bei den wei-
teren Entwurfs- und Entwicklungsaktivitäten berücksichtigt werden?
Wie kann der Entscheidungsausgang in Entwurfsmodelle und Programmcode ein-
gebracht werden?
Wir fokussieren auf die Beziehung zwischen Architekturentscheidungsmodel-
lierung und modellgetriebener Softwareentwicklung. Zunächst identifizieren wir
die benötigen Plattformmodelle und definieren Modelltransformationen innerhalb
des Entscheidungsmodells. Anschließend integrieren wir Entscheidungsmodelle
mittels Entscheidungsinjektion in die Entwurfsmodelltransformationskette. Das
vorgestellte Konzept ergänzt existierende Ansätze zur Durchsetzung von Ent-
scheidungen.
Zusammenfassung IX
Kapitel 8: Ein Kollaborationswerkzeug für die
Modellierung von Architekturentscheidungen
Der konzeptuelle Entwurf und die Implementierung eines Kollaborationssystems
für Architekten, welches die Konzepte des Rahmenwerkes zur Modellierung von
Architekturentscheidungen unterstützt, stellen den letzten Beitrag der Arbeit dar:
Welche Bausteine muss ein Werkzeug haben, das Architekten beim Untersu-
chen, Treffen und Durchsetzen von Architekturentscheidungen unterstützt?
Wie kann die Zusammenarbeit beim Erstellen und Nutzen von Architekturent-
scheidungsmodellen unterstützt werden?
Kapitel 9: Praxistest der Beiträge
In diesem Kapitel diskutieren wir, wie wir Rahmenwerk, Entscheidungsmodell
und Werkzeug im Hinblick auf Praxisnutzen und Benutzbarkeit validiert haben.
Wir klären zunächst die Ziele und Kriterien für die Validierung und stellen unse-
ren Ansatz vor. In einem zweiten Schritt bewerten wir unsere Lösung hinsichtlich
des Anforderungkatalogs aus Kapitel 3. Auf diese Selbsteinschätzung folgen die
Vorstellung von fünf industriellen Fallstudien und eine Diskussion der Rückmel-
dungen aus der Zielgruppe. Abschließend behandeln wir ergänzende Validie-
rungstypen wie Selbstexperimente und Schulungen und fassen die Validierungser-
gebnisse zusammen.
Kapitel 10: Diskussion von Forschungsansatz und
Forschungsergebnissen
Dieses Kapitel enthält eine Reflektion über den gewählten Forschungsansatz, eine
Interpretation der Validierungsergebnisse hinsichtlich der Stärken und Schwächen
des vorgestellten Ansatzes und einen Vergleich mit verwandten Arbeiten. Wir ge-
hen kurz auf die Möglichkeiten zur Implementierung der vorgestellten Konzepte
in marktgängigen Architektur- und anderen Entwicklungswerkzeugen ein.
Kapitel 11: Zusammenfassung und Ausblick
Die Arbeit schließt mit einer Zusammenfassung der erzielten Ergebnisse, einem
Ausblick auf zukünftige Forschungsaktivitäten sowie einer Vision für eine umfas-
sende Nutzung des Rahmenwerkes und wieder verwendbarer Entscheidungsmo-
dellen im industriellen Umfeld.
X Zusammenfassung
Anhang A: Ernten von Architekturentscheidungswissen
Anhang A stellt einen Prozess für das systematische Extrahieren von Wissen über
Architekturentscheidungen aus Projektartfakten vor.
Anhang B: Auszug aus dem „RADM for SOA“
Anhang B ist ein Auszug aus dem im Rahmen der Validierung der Arbeit erstell-
ten, wieder verwendbaren Entscheidungsmodell „RADM for SOA“.