Skip to main content
main-content

Über dieses Buch

Serviceorientierte Architektur (SOA) hat sich durchgesetzt. Verteilte Geschäftsprozesse lassen sich damit auf heterogene Systemlandschaften und auf unterschiedlichste Technologien abbilden. Dabei spielt Flexibilität und schnelle Reaktion auf veränderte Marktbedingungen bzw. Anforderungen eine große Rolle. Wer SOA beherrscht, hat damit einen Wettbewerbsvorteil. Die Frage, ob SOA angewendet werden soll, stellt sich bei den meisten Anwendern heute nicht mehr. Statt dessen ist nun die zentrale Frage, wie eine serviceorientierte Architektur praktisch umgesetzt werden kann. Die Autoren geben anhand eines durchgängigen Beispiels einen umfassenden Überblick über die modellgetriebene Softwareentwicklung einer SOA-Anwendung. Sie zeigen, wie sich mit den Notationen von BPMN und UML sowie mit Generatoren die werkzeuggestützte Entwicklung von SOA-Anwendungen effizient und dauerhaft umsetzen lässt.

Inhaltsverzeichnis

Frontmatter

Kapitel 1. Einleitung

Zusammenfassung
Sean hatte sich von allen verabschiedet. Seine Mutter hatte ihn ein letztes Mal umarmt. Sein Vater, reserviert wie immer, hatte ihm die Hand gedrückt, ihm auf die Schulter geklopft und ihm verstohlen noch einen weiteren Schein zugesteckt. Seine Freunde hatten im Glück gewünscht und bei manchem blitze etwas Neid in den Augen. Jetzt war er auf dem Weg. Am Morgen hatte er zügig die Nonabu Sümpfe umgangen. Jetzt lag das Dorf schon einen Tagesmarsch hinter ihm und er befand sich in der Einöde des Vorgebirges.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 2. Grundlagen

Zusammenfassung
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!
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 3. Die ModellierungsmethodikDie Modellierungsmethodik

Zusammenfassung
Die deutsche Wikipedia beschreibt sehr treffend, was in der Softwareentwicklung unter einer Methode zu verstehen ist:
Ganz in diesem Sinne beschreibt MDSOA2 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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 4. Das BeispielDas Beispiel – Überblick über alle Phasen

Vom Geschäftsprozess zur SOA – Von der Vision zur Wirklichkeit
Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 5. InitiationInitiation

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 6. System EvaluationSystem Evaluation

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 7. Architecture Projection

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 8. Construction und Deployment: Generierung, Implementierung und Integration

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 9. Automatisierung

Zusammenfassung
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!
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 10. Dokumentation

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 11. Ausblick und Fazit

Zusammenfassung
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.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Kapitel 12. Anhang

Zusammenfassung
In diesem Abschnitt wird die Entwicklung eines mit SOPERA umgesetzten Webservice auf Grundlage eines aus dem Innovator exportieren WSDL beschrieben.
Um ein neues SOPERA-Projekt anzulegen führen sie einen Rechts-Klick auf den Projekt-Explorer (links) aus und wählen Neu->Projekt, wie in Abb. 12.1 zusehen ist.
Gerhard Rempp, Mark Akermann, Martin Löffler, Jens Lehmann

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise