Model Driven SOA

Kapitel 2 stellt ihnen alle Informationen zur Verfügung, die sie für das weitere Verständnis der nachfolgenden Kapitel benötigen. Dabei haben wir Wert darauf gelegt den Inhalt auf das Notwendige zu beschränken. Dieses Kapitel gibt ihnen einen Überblick über die verwendeten Sprachen und Notationen. Es werden die Grundlagen zu UML 2, SoaML, SysML und BPMN 2.0 aufgezeigt. Dabei erfahren sie auch, warum wir welche Notation für was verwenden oder auch warum gerade nicht. Außerdem erhalten sie eine Einführung in die Entwicklung von Modelltransformationen und Generatoren. Da wir hierzu oAW und Java verwenden, werden auch hier die Grundlagen gelegt, die für das weitere Verständnis vorausgesetzt werden müssen. Ein kurzer Abriss über MDA (Modeldriven Architecture) der OMG und die Gegenüberstellung zu MDSD (Modeldriven Softwaredevelopment) hilft die eingesetzte Methodik besser zu verstehen, da sie auch Anleihen aus dem MDA Ansatz nimmt, aber sich nicht nur auf die UML beschränkt. Zu guter Letzt werden auch die Plattform und die verwendeten Werkzeuge vorgestellt. Dies ist wichtig, weil mit der Wahl der Plattform implizite Randbedingungen geschaffen werden, die sich auf die Methodik im plattformnahen Bereich und natürlich auf die Generierung auswirkt. Auch ist zu entscheiden, was aus Modellen erzeugt wird und was besser mit den Werkzeugen der Plattform umgesetzt wird. Nach Kap. 2 sind sie gut gerüstet, den Rest des Weges zusammen mit unserem Adepten Sean zu gehen, der sich aufgemacht hat, ein Meister zu werden!

Die deutsche Wikipedia beschreibt sehr treffend, was in der Softwareentwicklung unter einer Methode zu verstehen ist:

Ganz in diesem Sinne beschreibt MDSOA² die Verwendung verschiedener Methoden und Notationen, die Verfeinerung der Modelle über automatisierte Modelltransformationen und die Generierung von Artefakten mit Generatoren. Unser Anwendungsbereich in diesem Buch ist die serviceorientierte Architektur. Grundsätzlich ist MDSOA für beliebige Softwareentwicklungsprozesse anwendbar. Kapitel 3 beschreibt die Methodik und die verwendeten Methoden auf einer abstrakten Ebene. Die Methodik mit ihren einzelnen aufeinander aufbauenden Phasen tendiert grundsätzlich dazu relativ stabil zu bleiben. Hingegen ist die Ausgestaltung im Projekt und die konkret verwendete Notation relativ variabel. Die M³ kann somit für SOA, aber auch für SAP, EJB3 und den Embedded Bereich eingesetzt werden. Dabei bleibt der grundsätzliche Charakter der einzelnen Phasen erhalten. Es dürfte aber klar sein, das die Analyse eines Parkleitsystems mit der SysML den Schwerpunkt auf anderen Inhalte legt, als die Entwicklung einer SOA Anwendung.

Für diejenigen unter den Lesern, die selbst schon Erfahrungen mit dem MDSD Ansatz gemacht haben und die sich rasch einen Überblick verschaffen wollen, empfehlen wir Kap. 4 „Das Beispiel – Überblick über alle Phasen“. Experten der modellgetriebenen Softwareentwicklung können sich hier informieren und die dargestellte Methodik mit ihren ganz persönlichen Ideen und Vorgehensweisen vergleichen. Kapitel 4 geht auf die konkrete Ausgestaltung der M³ im Zuge der Entwicklung von SOA ein. Es wird für die jeweilige Phase beschrieben, welche Notationen verwendet werden, welche Inhalte damit dargestellt werden, welche Modelltransformationen durchgeführt werden und welche Ergebnisse am Ende jeweils vorliegen. Es nimmt aber noch nicht alle Details vorweg, die in den Kapiteln für die jeweiligen Phasen tiefer diskutiert werden. Kapitel 4 sollte aus unserer Sicht auf jeden Fall gelesen werden, bevor man in den nachfolgenden Kapiteln in die tieferen Details der einzelnen Phasen eintaucht.

Nach den notwendigen Grundlagen und der Übersicht geht es nun in Kap. 5 in die erste Phase der M³. Es wird gezeigt, wie aus einem initialen Wurf der fachlichen Aufnahme der Geschäftsprozesse in mehreren Iterationen ein detailreicher und ausformulierter Geschäftsprozess mit der BPMN 2.0 modelliert wird. Dabei wird auch auf die einzelnen Entscheidungen eingegangen, die der Businessanalyst gefällt hat. Da die Initiation Phase die Grundlage aller folgenden Phasen bildet – SOA soll ja idealerweise Geschäftsprozesse optimal unterstützen – ist sie eine sehr wichtige Phase. Die Inhalte werden von den Fachexperten bestimmt und spiegeln das gelebte oder erwartete Verhalten aller Beteiligten an einem Geschäftsprozess wider. Grundsätzlich dienen die modellierten Inhalte dazu, die Fachlichkeit zu verstehen und zu durchdringen. Um die späteren Anwender besser zu unterstützen muss verstanden werden, wie diese täglich ihre Arbeit erledigen. Die Inhalte sind Voraussetzung für einen vernünftigen und zielgerichteten Serviceschnitt. Immer wieder Anlass zur Diskussion: die Granularität von Services. In der Initiation Phase werden die Services nach fachlichen Anforderungen geschnitten. Wie genau und warum, darauf geht diese Kapitel ebenfalls ein. Alles wird anhand des durchgängigen Beispiels transparent gemacht.

Die Initiation Phase ist durch die Erfassung der fachlichen Anforderungen bestimmt. Sie bildet die Grundlage für das weitere Ausarbeiten der Inhalte in der Evaluation Phase. In der Evaluation Phase wird ausgeführt, wie für die fachlichen Prozesse der Initiation Phase die technischen Prozesse definiert werden. Dabei wird auch entschieden, was aus dem fachlichen Prozess automatisiert auf einer Prozessengine ablaufen soll. Inhalt ist zunächst der Abgleich der fachlichen Services gegen eventuell schon vorhandene Services. Kann die Funktionalität nicht vollständig abgedeckt werden, dann müssen vorhandene Services angepasst oder neue Services spezifiziert werden. Ein weiteres Thema ist, welcher Typ von Service verwendet werden soll und wie genau die Nachrichten formuliert werden. Für die Daten werden entsprechende Fachklassen definiert, welche die Grundlage für die Persistierung und später der Generierung von Entity-Beans sind. Es wird gezeigt, wie der technische Prozess mit den vorhandenen und neuen Services aufgebaut wird und wie über Service-Kollaborationen der Grundstein für die Generierung von BPEL gelegt wird. Auch hier machen Beispiele die Entscheidungen und Modellinhalte transparent.

Das Kapitel Architecture Projection geht auf die Architektur und das Design ein. Zunächst wird gezeigt, wie eine n-Tier-Architektur im Modell abgebildet werden kann und wie über Modelltransformationen Inhalte aus der Evaluation Phase auf Komponenten und Klassen in der Architecture Phase abgebildet werden. Die erzeugten Komponenten werden weiter ausgestaltet, denn aus ihnen werden die zu implementierenden Services generiert. Ebenso die entsprechenden Klassen der Persistenzschicht. Für das leichtere Verständnis werden außerdem Architekturdiagramme erstellt, die zeigen, wie die einzelnen Komponenten miteinander zusammenhängen. Der Designaspekt zeichnet sich zum Beispiel durch die genauere Typisierung von Komponenten, Klassen und Attributen aus. Es wird am Beispiel erklärt, welche Zielartefakte aus den Inhalten der Architecture Phase generiert werden.

Das Kapitel „Construction und Deployment“ führt aus, wie alle notwendigen Artefakte zum Bau einer SOA Anwendung aus den diversen Modellinhalten generiert, plattformspezifisch bis zur Lauffähigkeit ausformuliert und auf der Plattform integriert werden. Hier zeigt sich, wie sich einzelne Entscheidungen des modellgetriebenen Vorgehens auswirken und wie generierte Inhalte mit manuell erstellen Inhalten zusammenspielen. Da jede Plattform auch ihre eigenen Werkzeuge mitbringt, gehen wir auch darauf ein. Ergebnis ist die komplette SOA Anwendung, die über die Benutzeroberfläche den Workflow abbildet, Prozesse und Aktivitäten über Webservices nutzt und so ihre Leistung für den Anwender erbringt. Anschauliche Beispiele helfen die Zusammenhänge zu verstehen und nach zu vollziehen.

Kapitel 9 geht im Detail auf den Aspekt der Automatisierung innerhalb der modellgetriebenen Softwareentwicklung ein. Wie genau und nach welchen Gesichtspunkten werden Modeltransformationen und Generatoren gebaut? Welche Entscheidungen wurden gefällt und warum? Welche Werkzeuge werden verwendet? Nachdem in den vorhergehenden Kapiteln mehr die Nutzung der Automatisierung und deren Ergebnisse im Vordergrund stand, wird nun auf die Details der Herstellung von Automatisierungen eingegangen. Die Vorteile des modellgetriebenen Vorgehens werden durch Automatisierung im Softwareentwicklungsprozess erst richtig greifbar. Automatisierung hat auch auf die betriebswirtschaftliche Gesichtspunkte einen großen Einfluss. Eine spannenden Frage ist hier auch, wie „Overengineering“ vermieden werden kann, wie finde ich den Mittelweg zwischen Notwendigkeit, Ansprüchen, Wünschen und ökonomischer Umsetzung. Denn ein modellgetriebenes Vorgehen ist dann erfolgreich, wenn es anwendbar ist. Damit ist Weniger oft Mehr!

Hand aufs Herz: Wer schreibt gerne Dokumentationen? Jeder weiß, dass wichtige Aspekte und Inhalte im Softwareentwicklungsprozess auch dokumentiert werden müssen. Einerseits geht es hier um Dinge wie der Dokumentation von Architekturentscheidungen, da sich diese Entscheidungen auch auf die Inhalte in den Modellen bis hin zur konkreten Umsetzung von Generatoren auswirken. Andererseits geht es auch um Dinge wie Einarbeitung von neuen Kollegen, Kommunikation zwischen unterschiedlichen Bereichen im Unternehmen, die Optimierung von Prozessen, den Austausch von Informationen mit Lieferanten, Lasten- und Pflichtenhefte und vieles andere mehr.. Auch beim Thema Dokumentation kann uns das modellgetriebene Vorgehen unterstützen. Getreu dem Motto „The Model is the Source“, werden konsequenterweise auch Dokumentationen in Word oder HTML aus den Modellen erzeugt. Kapitel 10 „Dokumentation“ zeigtwie.

In den vorhergehenden Kapiteln haben sie kennengelernt, was sie für das modellgetriebene Vorgehen zur Erstellung von SOA Anwendungen benötigen. Dies wurde anschaulich an einem durchgängigen Beispiel aufgezeigt und alle Quellen liegen Ihnen vor. In Kap. 11 wollen wir noch einen Blick in die Zukunft wagen und außerdem zeigen, was noch alles möglich gewesen wäre, aber zum Beispiel aus zeitlichen Gründen nicht mehr in das Buch aufgenommen wurde. Es soll dem Leser auch als Anregung dienen, eigene Ideen zu entwickeln und selbst Hand anzulegen. Wagen sie den Schritt in die modellgetriebene Welt! Modellgetriebenes Vorgehen bietet viele Vorteile, die auch in Zukunft an Relevanz nicht verlieren werden.