×
![]( "Buchcover ISBN 9783866244382")
An Architectural Decision Modeling Framework for Service-Oriented Architecture Design
von Olaf ZimmermannDie Nutzung von Informationstechnologie ist heutzutage für Unternehmen in nahezu allen Branchen unentbehrlich. Unternehmensanwendungen unterstützen die Ausführung von Geschäftsprozessen und automatisieren diese teilweise. Die Entwicklung 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 einem wichtigen Architekturstil für die Entwicklung und Integration von Unternehmensanwendungen herangereift. Aus Benutzersicht betont SOA die geschäftliche Ausrichtung der in Software realisierten Dienste. Aus architektonischer Sicht stellen Modularität, loose Kopplung (d. h. Plattform-, Orts-, Protokoll-, und Formatunabhängigkeit) sowie Schichtenbildung und Flussunabhängigkeit wichtige SOAPrinzipien dar. Zentrale SOA-Muster sind Dienstnehmer-Geber-Vertrag, unternehmensweiter 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, Benutzerfreundlichkeit, Effizienz, Wartbarkeit, und Portierbarkeit. Andere NFA resultieren aus unternehmensweiten Architekturrichtlinien und Limitationen von Altanwendungen. Von anderen Architekturstilen bereits bekannte, aber auch neue Herausforderungen sind zu meistern, wie zum Beispiel Schnittstellenvertragsgestaltung und die gleichzeitige Versorgung vieler heterogener Dienstnehmer. Die resultierenden 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 Entwurfseleganz 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). Architekturentscheidungen betreffen ein Softwaresystem als Ganzes oder die Kernkomponenten eines derartigen Systems. Architekturentscheidungen bestimmen die nichtfunktionalen Eigenschaften eines Softwaresystems, zum Beispiel seine Qualitätsattribute. Jede Entscheidung behandelt ein konkretes Entwurfsproblem, für das eine oder mehrere Lösungsalternativen auszuwählen sind. Beispiele sind die Wahl von Programmiersprachen und Werkzeugen sowie von Architekturmustern, Integrationstechnologien und Middlewareprodukten.
Zwei Arten von Architekturentscheidungen, die im SOA-Entwurf erforderlich sind, resultieren aus den oben aufgezählten SOA-Mustern: Eine Art von Architekturentscheidungen behandelt Dienstschnittstellenvertragsgestaltung inklusive der Frage der Granularität (z. B. Struktur der ausgetauschten Nachrichten, Gruppierung von Dienstoperationen). Eine andere Art von Architekturentscheidungen betrifft 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 Bereiche 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 beeinflussen 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:
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 Gegensatz dazu untersuchen wir die Rolle, die wieder verwendbare Architekturentscheidungsmodelle während des SOA-Entwurfs spielen können: Wir behandeln wiederkehrende 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 Identifikation von wiederkehrenden Architekturentscheidungen zur Verfügung. Unser SOA-Entscheidungsmodell ist nach einem Metamodell strukturiert, das Wiederverwendung und Zusammenarbeit unterstützt. Die Modellorganisation folgt den Prinzipien der modellgetriebenen Architektur und separiert länger aktuell bleibende plattformunabhängige Entscheidungen von sich häufig ändernden plattformspezifischen. Auf einer konzeptuellen Ebene werden SOA-Muster referenziert, was die initiale Befüllung und laufende Pflege des Entscheidungsmodells erleichtert. Unser Entscheidungsabhängigkeitsmanagement hilft Architekten, die Modellkonsistenz zu prüfen und irrelevante Entscheidungen gar nicht erst zu betrachten. 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 Entwurfsmethode; weitere Anwendungsfälle sind Ausbildung, Wissensaustausch, Review-Technik und Steuerungsinstrument (engl. Governance Instrument).
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, Benutzerfreundlichkeit, Effizienz, Wartbarkeit, und Portierbarkeit. Andere NFA resultieren aus unternehmensweiten Architekturrichtlinien und Limitationen von Altanwendungen. Von anderen Architekturstilen bereits bekannte, aber auch neue Herausforderungen sind zu meistern, wie zum Beispiel Schnittstellenvertragsgestaltung und die gleichzeitige Versorgung vieler heterogener Dienstnehmer. Die resultierenden 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 Entwurfseleganz 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). Architekturentscheidungen betreffen ein Softwaresystem als Ganzes oder die Kernkomponenten eines derartigen Systems. Architekturentscheidungen bestimmen die nichtfunktionalen Eigenschaften eines Softwaresystems, zum Beispiel seine Qualitätsattribute. Jede Entscheidung behandelt ein konkretes Entwurfsproblem, für das eine oder mehrere Lösungsalternativen auszuwählen sind. Beispiele sind die Wahl von Programmiersprachen und Werkzeugen sowie von Architekturmustern, Integrationstechnologien und Middlewareprodukten.
Zwei Arten von Architekturentscheidungen, die im SOA-Entwurf erforderlich sind, resultieren aus den oben aufgezählten SOA-Mustern: Eine Art von Architekturentscheidungen behandelt Dienstschnittstellenvertragsgestaltung inklusive der Frage der Granularität (z. B. Struktur der ausgetauschten Nachrichten, Gruppierung von Dienstoperationen). Eine andere Art von Architekturentscheidungen betrifft 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 Bereiche 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 beeinflussen 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:
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 Gegensatz dazu untersuchen wir die Rolle, die wieder verwendbare Architekturentscheidungsmodelle während des SOA-Entwurfs spielen können: Wir behandeln wiederkehrende 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 Identifikation von wiederkehrenden Architekturentscheidungen zur Verfügung. Unser SOA-Entscheidungsmodell ist nach einem Metamodell strukturiert, das Wiederverwendung und Zusammenarbeit unterstützt. Die Modellorganisation folgt den Prinzipien der modellgetriebenen Architektur und separiert länger aktuell bleibende plattformunabhängige Entscheidungen von sich häufig ändernden plattformspezifischen. Auf einer konzeptuellen Ebene werden SOA-Muster referenziert, was die initiale Befüllung und laufende Pflege des Entscheidungsmodells erleichtert. Unser Entscheidungsabhängigkeitsmanagement hilft Architekten, die Modellkonsistenz zu prüfen und irrelevante Entscheidungen gar nicht erst zu betrachten. 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 Entwurfsmethode; weitere Anwendungsfälle sind Ausbildung, Wissensaustausch, Review-Technik und Steuerungsinstrument (engl. Governance Instrument).