Service-orientierte Anwendungen in Java modellgetrieben entwickeln

objectiF at work

Kern einer service-orientierten Anwendung ist ein automatisierter Geschäftsprozess. Er beschreibt eine zeitliche Abfolge von fachlichen Aktivitäten. Die Aktivitäten führen selbst keine wesentliche Verarbeitung durch. Dafür nehmen sie Services in Anspruch. Gemeint sind hier WebServices, die entweder im Unternehmen selbst vorhanden sind oder von externen Geschäftspartnern bereitgestellt werden.

Die fachliche Architektur gestalten

Der erste Schritt bei der Entwicklung einer service-orientierten Anwendung mit objectiF ist die Gestaltung eines fachlichen, also plattformunabhängigen Modells. objectiF bringt die Grundstruktur des Modells mit: Es besteht aus vier aufeinander abgestimmten Einzelmodellen, die zusammen die fachliche Leistung einer service-orientierten Anwendung spezifizieren:

• Präsentationsmodell: Das Präsentationsmodell beschreibt den Page Flow der Web-Seiten der Benutzerschnittstelle. Als Beschreibungsmittel werden Zustandsdiagramme der UML benutzt: Ihre Zustände repräsentieren Web-Seiten. Die Zustandsübergänge stellen die Seitenwechsel dar, die durch Anwenderereignisse ausgelöst werden. Bei einem Zustandsübergang können Aktivitäten eines Geschäftsprozesses angestoßen werden.
• Service-Modell: In Service-Modellen werden Services in UML-Klassendiagrammen spezifiziert. Die Konventionen dazu – speziell die zu verwendenden Stereotypen – sind in objectiF angelegt: Ein Service-Modell beschreibt Services und ihre Nachrichten als Klassen vom Stereotyp «BusinessService» und «BusinessMessage». Die Methoden einer Klasse vom Stereotyp. «BusinessService» bilden die Service-Operationen ab. Sie erhalten den Stereotyp «BusinessOperation». BusinessOperations verwenden BusinessMessages als Parameter. Der Vorteil dieser Abbildungstechnik: Mithilfe von Service-Modellen können Aktivitäten eines Geschäftsprozesses auf grafischem Niveau mit Service-Operationen orchestriert werden. Liegt für einen Service eine Beschreibung in der Web Service Description Language (WSDL) vor, kann ein zugehöriges Service-Modell durch WSDL-Reverse-Engineering mit objectiF automatisch erzeugt werden.
• Prozessmodell: Im Prozessmodell werden Geschäftsprozesse durch Geschäftsprozessdiagramme in der Business Process Modeling Notation (BPMN) beschrieben. Die BPMN-Diagramme werden von objectiF direkt in WS-BPEL Code umgesetzt. Jeder Geschäftsprozess ist selbst ein Service, der zusätzlich – wie im Service-Modell – mit UML-Klassen beschrieben wird. Er kann somit zur Orchestrierung höherer Geschäftsprozesse verwendet werden. Mit dieser Konvention unterstützt objectiF das rekursive Aggregationsmodell für Services, das ein wichtiges Gestaltungsmittel service-orientierter Architekturen darstellt.
• Entity-Modell: Es dient der Spezifikation der persistenten Geschäftsdaten, die von Service-Operationen benutzt werden. Darstellungsmittel sind wieder UML-Klassendiagramme mit Geschäftsklassen von Stereotyp «BusinessEntity».

Die fachliche Architektur einer SOA-Anwendung – konzeptionell...

...und als UML-Package-Diagramm für eine Beispielanwendung in objectiF

Fachliche in technische Modelle maschinell transformieren

objectiF bietet Transformationen an, die die fachlichen Modelle in technische Modelle umsetzen und dabei gleichzeitig große Teile des Quellcodes generieren. Die Transformation eines Modells wird einfach per Kontextmenüfunktion angestoßen.

Von den fachlichen zu den technischen Modellen einer SOA-Anwendung – durch maschinelle Modelltransformationen

Für den automatisierten Weg vom fachlichen zum technischen Modell enthält objectiF vier Modelltransformationen: je eine zur maschinellen Umsetzung

• des Präsentationsmodells in JavaServer Faces-Artefakte,
• des Prozessmodells in WS-BPEL- und WSDL-Code,
• der Service-Modelle in EJB SessionBeans mit UML-Darstellung als Klassendiagramm
• des Entity-Modells in EntityBeans mit Annotations für die persistente Speicherung ebenfalls mit UML-Darstellung als Klassendiagramm.

Neben dem Layout der JavaServer Pages lässt sich bei diesem Vorgehen im Wesentlichen nur eines nicht generieren: die Service-Operationen. In dem per Modelltransformation erzeugten Code der SessionBeans muss die Implementierung der Service-Operationen manuell ergänzt werden. Dies geschieht per Round Trip Engineering mit Eclipse direkt aus der generierten UML-Darstellung der SessionBeans heraus.

Durch die Modelltransformationen entstehen Beziehungen zwischen fachlichen und technischen Elementen der Anwendung. Sie werden von objectiF konsistent gepflegt und für eine bequeme Navigation zwischen den Modellen genutzt.

Die technische Architektur einer SOA-Anwendung wieder als Konzept ...

...und am Beispiel in objectiF: Der Vergleich mit dem Package-Diagramm der fachlichen Architektur macht den Umfang der Modelltransformationen und damit die Arbeitsersparnis deutlich

Iterativ transformieren

objectiF unterstützt iterative Entwicklungsstrategien: Das fachliche Modell kann immer wieder geändert, erweitert und transformiert werden, ohne manuell implementierte Teile zu beeinträchtigen. Dabei bleiben die Beziehungen zwischen fachlichen und technischen Modellelementen persistent und navigierbar. Die Entwicklung wird für Sie damit dauerhaft nachvollziehbar.

Alle Elemente der fachlichen und technischen Modelle und der Code können immer wieder zusammengeführt werden, sodass jederzeit ein vollständiges, konsistentes Gesamtmodell der Anwendung für die Weiterentwicklung zur Verfügung steht.

Flexibel und anpassbar

Die in objectiF enthaltenen Modelltransformationen können jederzeit modifiziert, erweitert und an andere Zieltechnologien angepasst werden. objectiF bietet Unterstützung bei der Entwicklung benutzereigener Modelltransformationen.

Downloads

Copyright © 2001 - 2012 microTOOL GmbH, Berlin. Alle Rechte vorbehalten.