Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.04.2007

Vom Modell zu SOA-Anwendungen

Bernd Nawrot 
Wie sich Geschäftsprozesse modellieren und für die Business Process Execution Language sowie in Javabeans weitgehend automatisiert technisch umsetzen lassen.
Mit vier Modelltransformationen können die Elemente des fachlichen Modells einer Service-orientierten Anwendung auf maschinellem Weg in entsprechende Elemente des technischen Modells umgesetzt werden.
Mit vier Modelltransformationen können die Elemente des fachlichen Modells einer Service-orientierten Anwendung auf maschinellem Weg in entsprechende Elemente des technischen Modells umgesetzt werden.

Unternehmen, die heute mit der Entwicklung Service-orientierter Anwendungen beginnen, stehen vor der Aufgabe, ein Vorgehen zu finden, das das Versprechen von SOA, nämlich hohe Business-Agilität, auf Seiten der IT einlöst. Dabei kann es sich auszahlen, neue Wege zu gehen. Bevor man sich aber auf eine Vorgehensweise festlegt, müssen die einzusetzenden Modellierungsstandards und die angestrebte technische Systemarchitektur feststehen. Für ihre Auswahl ist ein grundlegendes Verständnis der Geschäftsprozesse notwendig, die durch Service-orientierte Anwendungen automatisiert werden können.

Fazit

Hohe Business-Agilität - das ist das Versprechen von SOA. Gemeint ist die Fähigkeit zur flexiblen und effektiven Unterstützung sich immer schneller ändernder geschäftlicher Ziele und Anforderungen. Dazu werden aus Business-Sicht die Geschäftsregeln von der Prozesslogik getrennt und in Services gekapselt.

Mit Services können Geschäftsprozesse flexibel und änderungsfreundlich orchestriert werden. Das hier beschriebene modellgetriebene Vorgehen bei der Entwicklung Service-orientierter Anwendungen erlaubt es, neue Geschäftsprozesse und Services, aber auch Änderungen an bestehenden Services, an vorhandenen Prozessen oder ihrer Orchestrierung schnell - nämlich durch grafische Spezifikation mit anschließender automatischer Modelltransformation - umzusetzen.

Damit ist IT-seitig ein großer Schritt zur Einlösung des Agilitätsversprechens getan.

Die Standards

BPMN:

• Grafische Notation für die Modellierung von Geschäftsprozessen;

• entwickelt von der Business Process Management Initiative (BPMI), einem Non-Profit-Konsortium;

• seit 2005 erfolgt die Pflege und Weiterentwicklung durch die OMG;

• seit 2006 OMG-Standard.

WS-BPEL:

• XML-basierende, ausführbare Sprache für die Beschreibung von Geschäftsprozessen, deren Aktivitäten durch Web-Services implementiert sind;

• 2002 eingeführt von IBM, Bea und Microsoft;

• 2003 zur Standardisierung Oasis vorgelegt;

• 2004 Änderung des Namens von BPEL4WS in WS-BPEL;

• März 2007 WS-BPEL Version 2.0 als Oasis-Standard eingereicht.

Mehr zum Thema

www.computerwoche.de/

1218224: SOA-Tools von IBM und SAP im Vergleich;

588420: UML auch für Komplettsysteme geeignet;

586158: OMG behebt Modellierungsdefizite;

572838: Profile helfen bei der Arbeit mit UML.

Hier lesen Sie ...

• wie ein fachliches und daraus abgeleitet ein technisches Modell für eine Service-orientierte Anwendung entstehen;

• in welchen Standards man sich für die beiden Modelle bewegen sollte;

• wie sich die Ableitung der beiden Modelle voneinander automatisieren lässt;

• was noch per Hand programmiert werden muss.

Modellierungsstandards

Ein automatisierter Geschäftsprozess steuert die zeitliche und beliebig komplexe Abfolge fachlicher Aktivitäten. Diese sind dadurch gekennzeichnet, dass sie selbst keine Verarbeitung beinhalten, also nichts speichern, erfassen oder anzeigen. Für diese Aufgaben nehmen sie Services in Anspruch. Betrachtet werden hier ausschließlich Services, die als Web-Services implementiert werden. Eine Aktivität benutzt einen Service, indem sie ihm eine Nachricht sendet. Die Nachricht wird von einer Operation des Service verarbeitet.

Typisch für Service-orientierte Prozesse ist, dass es nach dem Aufruf einer Serviceoperation durchaus Stunden oder Tage dauern kann, bis eine Antwortnachricht eintrifft. Man wird den Geschäftsprozess in solchen Fällen so gestalten, dass er nicht auf die Antwort wartet, sondern mit der Geschäftslogik fortfährt. Das bedeutet, statt einer synchronen wird eine asynchrone Kommunikation zwischen dem Geschäftsprozess und dem Service modelliert.

Aber was passiert, wenn die Antwort so ausfällt, dass zwischenzeitliche Aktivitäten rückgängig gemacht werden müssen? Für diesen Fall muss ein Projektteam bereits bei der Modellierung des Geschäftsprozesses entscheiden, welche Seiteneffekte zu bereinigen sind. Im Geschäftsprozess sind dafür spezielle Aktivitäten vorzusehen, die die Wirkung von vorherigen Aktivitäten aufheben oder kompensieren.

Neuer Standard BPMN

Ein Modellierungsstandard für Geschäftsprozesse mit den genannten Merkmalen muss sequenzielle, parallele, konditionale und iterative Abläufe beliebiger Komplexität darstellen können. Er muss auf die Verwendung von Web-Services zugeschnitten sein, den Nachrichtenaustausch zwischen parallelen Prozessen kennen und Kompensationsmechanismen unterstützen. Genau für diese Anforderungen ist der neue OMG-Standard, die Business Process Modeling Notation (BPMN), entwickelt worden. BPMN ist damit älteren, allgemein gültigeren grafischen Konzepten wie den erweiterten ereignisgesteuerten Prozessketten (eEPK) oder den Aktivitätsdiagrammen der UML bei der Modellierung Service-orientierter Anwendungen überlegen. Und BPMN hat eine weitere Eigenschaft, die auf eine einfache Implementierung der modellierten Geschäftsprozesse zielt: Der Standard legt fest, wie die grafischen Elemente eines Geschäftsprozessdiagramms auf ausführbare, XML-basierende Sprachen abgebildet werden.

UML beschreibt Fachlichkeit

Für die fachliche Spezifikation eines Service mit seinen Operationen und Nachrichten eignet sich die Unified Modeling Language (UML). Allerdings empfiehlt es sich, deren Sprachumfang um einige Stereotypen zu erweitern. Damit lässt sich die Aussagekraft der fachlichen Spezifikation erhöhen und die technische Voraussetzung für eine Automatisierung nachfolgender Entwicklungsschritte schaffen.

Services kann man als UML-Klassen modellieren, indem die Spezialisten zum Beispiel einen Stereotyp "Business Service" definieren. Die Methoden der Klasse bilden die Serviceoperationen ab. Letztere können beispielsweise durch einen Stereotyp "Business Operation" kenntlich gemacht werden. Eine Nachricht wird dann entsprechend als eine UML-Klasse vom Stereotyp "Business Message" modelliert, die nur elementare Attribute oder feinere Business Messages enthalten kann. Business Operations verwenden ausschließlich Business Messages als Parameter.

Services - genauer ihre Operationen - übernehmen die Verarbeitung innerhalb eines Geschäftsprozesses. Das kann bedeuten, dass sie auf Unternehmensdaten zugreifen, sie ändern und speichern müssen. Das heißt, mit dem fachlichen Entwurf neuer Services kann die Entwicklung oder Erweiterung von Geschäftsklassen einhergehen. Sie wären beispielsweise als UML-Klassen vom Stereotyp "Business Entity" beschreibbar.

Das fachliche Modell

Der erste Schritt bei der Entwicklung einer Service-orientierten Anwendung ist die Gestaltung eines fachlichen Modells. Unter Einsatz der beschriebenen Standards und Stereotypen kann die fachliche Leistung einer Service-orientierten Anwendung mit vier aufeinander abgestimmten Modelltypen vollständig spezifiziert werden.

Präsentationsmodell

Der erste ist das Präsentationsmodell. In einen Geschäftsprozess sind in der Regel Menschen eingebunden. Das Präsentationsmodell beschreibt die Interaktion mit dem Anwender. In einer Web-Oberfläche würde dieses Modell den Seitenfluss an der Benutzerschnittstelle festlegen. Ein geeignetes Gestaltungsmittel für das Präsentationsmodell sind die Zustandsdiagramme der UML. Ihre Zustände repräsentieren die angezeigten Seiten. Die Zustandsübergänge bedeuten von Anwenderereignissen ausgelöste Seitenwechsel. Bei einem Zustandsübergang werden Aktivitäten eines Geschäftsprozesses aufgerufen.

Prozessmodell

Der Geschäftsprozess wird in einem Geschäftsprozessdiagramm (Prozessmodell) modelliert, dem einzigen Diagrammtyp, den BPMN kennt. Wenn man Services und ihre Nachrichten durch Klassen vom Stereotyp Business Service und Business Message beschreibt, bietet es sich an, den Zusammenhang dieser Klassen in UML-Klassendiagrammen abzubilden. Letztere werden hier als Servicemodelle bezeichnet. Benutzt man die oben eingeführten Stereotypen, dann stellt ein Servicemodell sowohl den Kontext eines Service als auch die grafische Komposition komplexer Nachrichten übersichtlich dar.

Servicemodell

Servicemodelle bieten ferner die Möglichkeit, Aktivitäten eines Geschäftsprozesses schon auf grafischem Niveau mit Serviceoperationen zu orchestrieren. Das bedeutet: Einer Aktivität im Geschäftsprozessdiagramm können eine Business Operation und Business Messages als Ein- und Ausgabe direkt aus dem Servicemodell zugewiesen werden. Ist ein Service bereits vorhanden und liegt für ihn eine Beschreibung in der Web Service Description Language (WSDL) vor, muss niemand mehr das Servicemodell "per Hand" entwickeln. Vielmehr lässt es sich durch Reverse Engineering maschinell erzeugen.

Benötigt eine Serviceoperation persistente Geschäftsklassen, die es noch nicht gibt, kommt der vierte Diagrammtyp zum Zuge: das Entity-Modell. Es zeigt - wieder in Form eines UML-Klassendiagramms - die Geschäftsklassen vom Stereotyp Business Entity mit ihren Beziehungen.

Die technische Architektur

Nach der Auswahl der Modellierungsstandards und der Entwicklung des fachlichen Modells stellt sich die Frage nach den passenden Techniken, um einen Geschäftsprozess und die Services zu implementieren und zu steuern. Unter den ausführbaren, XML-basierenden Sprachen, auf die ein in BPMN modellierter Geschäftsprozess direkt abgebildet werden kann, zeichnet sich die Web-Service Business Process Execution Language (WS-BPEL) als der kommende Standard ab. WS-BPEL ist eine hoch spezialisierte Orchestrierungs- und Integrationssprache. Mehrere führende Hersteller haben Engines entwickelt, die WS-BPEL ausführen können.

Bei der Implementierung der Services ist der komplexeste Fall technisch am wenigsten kritisch: Besteht ein Service nicht aus elementaren Operationen, sondern steht dahinter wieder ein unternehmenseigener Geschäftsprozess, kann man WS-BPEL zur Implementierung verwenden und damit in der Welt eines Standards bleiben. Häufiger entsteht ein Service jedoch, indem ein Softwareexperte einen Adapter für eine bereits implementierte, wiederzuverwendende Funktion einer bestehenden Anwendung erstellt oder den Service als elementaren Web-Service neu entwickelt. Im Java-Umfeld wird er einen Adapter ebenso wie einen neu zu entwickelnden Web-Service als eine zustandslose EJB 3.0 Session Bean mit Web Service Annotations realisieren.

Die beiden Standards - WS-BPEL für ausführbare Geschäftsprozesse und EJB 3.0 für zustandslose Services - sind unabhängig voneinander entstanden. Das blieb nicht ohne Folgen: Die Web Service Annotations der EJB 3.0 Session Beans reichen nicht aus, um die Kommunikation mit ausführbaren WS-BPEL-Prozessen zu beschreiben. Für das erfolgreiche Zusammenwirken beider Standards ist ein dritter nötig: die Web Service Description Language. Sie definiert, was für Nachrichten mit einem Web-Service auszutauschen und welche seiner Operationen auszuführen sind. Außerdem beschreibt WSDL, wie die fachlichen Nachrichten als technische Soap-Messages aufgebaut sind und wo im Internet ein Server zur Nutzung des Service bereitgestellt ist.

Standard erlaubt Kombination

Der WS-BPEL-Code eines Geschäftsprozesses wird von einer BPEL-Engine ausgeführt, eine Session Bean läuft in einem EJB-Container. Applikations-Server mit integrierter BPEL-Engine sind bereits verfügbar. Es lassen sich aber auch BPEL-Engines und Applikations-Server für EJB von unterschiedlichen Herstellern kombinieren. Wer neue Projekte aufsetzt, sollte WS-BPEL 2.0 verwenden, denn es weist essenzielle Verbesserungen gegenüber der Vorgängerversion auf.

Das technische Modell

Sind die Technikkomponenten festgelegt, kann im nächsten Entwicklungsschritt das fachliche Modell einer Service-orientierten Anwendung in ein technisches Modell umgesetzt werden. Das technische Modell lässt sich, wie das fachliche, durch vier Modelltypen beschreiben - ergänzt um eine Reihe von Implementierungsartefakten.

Soll die Interaktion zwischen Anwender und Geschäftsprozess auf Java Server Faces aufsetzen, wird auf der Basis des fachlichen Präsentationsmodells im technischen Modell ein JSF-Controller entworfen und implementiert. Er besteht aus Backing Beans, beschrieben als UML-Klassen, sowie JSP- und Konfigurationsdateien. Aus dem Geschäftsprozessdiagramm des fachlichen Modells wird ein ausführbarer Prozess in Form von WS-BPEL- und WSDL-Dateien abgeleitet. Auf der Basis der fachlichen Servicemodelle werden im technischen Modell EJB 3.0 Session Beans als UML-Klassendiagramme entworfen und in Java mit dazu passender WSDL implementiert. Gehören zur fachlichen Beschreibung einer Service-orientierten Anwendung Entity-Modelle, so werden daraus im technischen Modell EJB 3.0 Entity Beans als UML-Klassendiagramme mit Java-Code.

Automatisierte Transformation

Bei konventionellem Vorgehen dient das fachliche Modell dem Entwickler als Vorgabe. Er entwirft daraus das technische Modell und implementiert es. Zu dieser Vorgehensweise gibt es bei der Entwicklung Service-orientierter Anwendungen eine wirtschaftlich interessante Alternative: Die Service-orientierten Anwendungen eines Unternehmens stellen zwar jeweils individuelle Softwarelösungen dar, besitzen aber fachliche und technische Gemeinsamkeiten, die sie zu einer Anwendungsfamilie machen. Steht eine Firma vor der Aufgabe, eine Anwendungsfamilie zu erstellen, liegt der Gedanke nahe, die Entwicklung der Gemeinsamkeiten nach den Konzepten von Model-driven Development (MDD) zu automatisieren, so dass nur die variierenden Anwendungsteile individuell spezifiziert und implementiert werden müssen.

Bessere Softwarequalität

Auf diese Weise kann man zum einen die Entwicklung beschleunigen, zum anderen verbessert sich die Softwarequalität durch den erheblichen Anteil an generierten Ergebnissen. MDD bedeutet für die Entwicklung Service-orientierter Anwendungen konkret: Das fachliche Modell wird von Analytikern erstellt und anschließend durch maschinelle Modelltransformationen in ein technisches Modell umgesetzt. Dabei werden große Teile des Codes generiert.

Die hier vorgestellten Elemente des fachlichen und technischen Modells sind so konzipiert, dass sie sich durch Modelltransformationen maschinell voneinander ableiten lassen. Für den automatisierten Weg vom fachlichen zum technischen Modell benötigt man vier Modelltransformationen: je eine zur maschinellen Umsetzung des Geschäftsprozessdiagramms in WS-BPEL- und WSDL-Code, des Präsentationsmodells in Java-Server-Faces-Artefakte, der Servicemodelle in EJB 3.0 Session Beans und des Entity-Modells in Entity Beans mit Annotations für die persistente Speicherung nach EJB 3.0.

Eingriffe erforderlich

Neben dem Layout der Java Server Pages lässt sich bei diesem Vorgehen im Wesentlichen nur eines nicht generieren: die Operationen der Services. In dem per Modelltransformation erzeugten Code der Session Beans muss die Implementierung der Service-Operationen manuell ergänzt werden. Dies kann zum Beispiel per Round Trip Engineering mit einem UML-Werkzeug und Eclipse direkt aus der generierten UML-Darstellung der Session Beans heraus geschehen.

Bei der Auswahl von MDD-Tools und der Entwicklung von Modelltransformationen sind mehrere Kriterien zu beachten: Eine praxistaugliche MDD-Lösung muss iterative Entwicklungsstrategien unterstützen. Damit sind Entwickler in der Lage, über den gesamten Softwarelebenszyklus hinweg das fachliche Modell zu ändern, zu erweitern und erneut zu transformieren, ohne die manuell implementierten Teile zu beeinträchtigen. Dabei sollten die Beziehungen zwischen fachlichen und technischen Modellelementen persistent und navigierbar bleiben, um die Entwicklung dauerhaft nachvollziehbar zu machen. Und schließlich ist es wünschenswert, wenn alle Elemente des fachlichen und technischen Modells und der Code immer wieder zusammengeführt werden können, so dass jederzeit ein konsistentes Gesamtmodell der Service-orientierten Anwendung für die Weiterentwicklung bei Geschäftsprozessveränderungen zur Verfügung steht. (ue)