Transformation von annotierten Gesch¤ftsprozessen nach BPEL

Gottfried Wilhelm Leibniz Universität Hannover

Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering

Transformation von annotierten Geschäftsprozessen nach BPEL

Masterarbeit

im Studiengang Informatik

von

Oleg Schmelzle

Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Rainer Parchmann

Betreuer: Dipl.-Wirt.-Inform. Daniel Lübke

Hannover, 11. Mai 2007

Zusammenfassung

Geschäftsprozesse spielen heute eine bedeutende Rolle in der Entwicklung einerbestimmten wirtschaftlichen Leistung. Die zunehmende Marktdynamik und derwachsende Ein�uss des Kunden auf die Produkte erfordert, dass man möglichstschnell auf geänderte Anforderungen reagieren kann. Die fachlichen Anforderungenund Geschäftsabläufe werden häu�g von Business Analysten mit abstrakten Be-schreibungsmitteln wie dem EPK-Diagramm modelliert. Es besteht der Wunsch,die modellierten Abläufe auf eine Ausführungsumgebung auszuführen, um die Ab-läufe der Geschäftsprozesse zu automatisieren. Da es keine ausführbare Umgebungfür die EPK-Modelle gibt, wird vorgeschlagen, auf die Ausführungssprache Busi-ness Process Execution Language for Web Services zurückzugreifen. EPK undBPEL be�nden sich aber auf zwei unterschiedlichen Modellierungsebenen. DieEPK werden für Prozess-Design und BPEL für Prozess-Implementierung verwen-det. Es ist zwingend erforderlich, die entstandene Lücke zwischen den Fachbe-reichen und den IT-Entwicklern zu schlieÿen. Der Beitrag dieser Arbeit ist dieAbbildung von annotierten Geschäftsprozessen, die mit Hilfe von EPK-Notationdargestellt werden, nach BPEL. Dabei sollen konzeptuelle Unterschiede der beidenbetrachteten Modelle und die Grenzen der automatischen Transformation aufge-zeigt werden. Die Abbildung der fachlichen Anforderungen auf die technische Im-plementierungsebene soll, soweit es geht, teil-automatisiert werden. Das Ziel isteine verlustlose Transformation von annotierten Geschäftsprozessen in EPK nachBPEL sicherzustellen.

Danksagung

Mein besonderer Dank gilt Herrn Dipl.-Wirt.-Inform.Daniel Lübke für die vorbildliche und hervorragende

Betreuung dieser Masterarbeit.

Insbesondere gilt mein Dank meinen Eltern, die michwährend meines Studiums immer gefördert haben, ohnezu fordern, und meiner Verlobten Olesja Bauer, die

mich immer emotional unterstützt hat.

III

Inhaltsverzeichnis

Abstract II

Danksagung IV

Inhaltsverzeichnis IV

Abkürzungsverzeichnis V

1 Einleitung 1

1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Beitrag dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Namenskonventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Allgemeine Grundlagen 4

2.1 Geschäftsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Ereignisgesteuerte Prozessketten (EPK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Business Process Execution Language (BPEL) . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Warum braucht man eine Transformation

von EPK nach BPEL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 Verwandte Themen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.2 Ziel der Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Elemente von Ereignisgesteuerten Prozessketten . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Syntax und Semantik von EPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7.1 Graph-orientierte Charakterisierung der EPK . . . . . . . . . . . . . . . . . . . . . . . 162.7.2 De�nition der EPK-Syntax und -Semantik . . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 EPML-Dokumentstruktur 19

3.1 Warum XML als Austauschformat? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.1 XML-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 XML-Transformationsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 EPC Markup Language (EPML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Anforderungen an das EPML-Schema für EPK . . . . . . . . . . . . . . . . . . . . . 223.2.2 EPML-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Erweiterte EPK-Notation um Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Erweiterbarkeit des EPML-Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 WSDL- und BPEL-Grundlagen 31

4.1 WSDL-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 BPEL-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Elementare Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4 Strukturierte Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Notwendige Erweiterungen für ausführbare Prozesse . . . . . . . . . . . . . . . . . . . . . . . 384.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Konzept 42

5.1 Konzept zur Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1.1 Abbilden der EPK über BPMN-Format . . . . . . . . . . . . . . . . . . . . . . . . . . 43

IV

Inhaltsverzeichnis V

5.1.2 Anforderungen an die Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.1 EPK-Modellierung auf der Business-Ebene . . . . . . . . . . . . . . . . . . . . . . . . 485.2.2 Analyse und Import notwendiger Web Services . . . . . . . . . . . . . . . . . . . . . . 495.2.3 Anreicherung des EPK-Diagramms um implementierungsspezi�sche Aspekte . . . . . . 505.2.4 Orchestrierung von Web Services auf technischer Seite . . . . . . . . . . . . . . . . . 505.2.5 Verknüpfen der einzelnen BPEL-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . 525.2.6 Manuelle Nachbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Konzeptuelle Unterschiede zwischen den beiden Modellen . . . . . . . . . . . . . . . . . . . . 545.3.1 Vergleich der High-Level-Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.3.2 De�nition von Work�ow Patterns in EPK und BPEL . . . . . . . . . . . . . . . . . . 565.3.3 Graph-orientierte versus block-orientierte Beschreibungssprache . . . . . . . . . . . . . 58

5.4 Transformation von EPK nach BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4.1 Transformationsstrategien für die Beschreibung des Kontroll�usses . . . . . . . . . . . 615.4.2 Vergleich der EPK- und BPEL-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.5.1 Betriebswirtschaftliche und technische Sicht . . . . . . . . . . . . . . . . . . . . . . . 765.5.2 Bewertung der Grenzen der Konvertierung . . . . . . . . . . . . . . . . . . . . . . . . 78


6 Umsetzung und Beispiel 81

6.1 Technische Konzeption und prototypische Realisierung . . . . . . . . . . . . . . . . . . . . . . 816.2 Beispiel eines Geschäftsprozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.3 Transformationsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3.1 Analysephase der EPML-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.3.2 Entfernen der Ereignisknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.3.3 Übersetzen der EPK-Elemente in BPEL-Elemente . . . . . . . . . . . . . . . . . . . . 906.3.4 Entfernen von Empty-Aktvitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3.5 Erzeugen von Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3.6 Testen des BPEL-Prozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94


7 Schluss 96

7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Literaturverzeichnis 98

A WSDL-Syntax A

B BPEL-Syntax C

C Weitere Abbildungen G

C.1 EPK-Verknüpfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GC.2 SOA-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HC.3 Web Service-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HC.4 BPEL-Diagramme aus dem Transformationsprozess . . . . . . . . . . . . . . . . . . . . . . . I

C.4.1 Nach Phase (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IC.4.2 Nach Phase (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J

D Verschiedenes K

D.1 Voraussetzungen für die technische Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . KD.2 Inhalt der beiliegenden CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K

Abbildungsverzeichnis L

Tabellenverzeichnis M

Index N

Abkürzungsverzeichnis

ARIS Architektur integrierter InformationssystemeBPEL Business Process Execution LanguageBPEL4WS Business Process Execution Language for Web ServicesBPML Business Process Modeling LanguageBPMN Business Process Modeling NotationDTD Document Type De�nitioneFAD erweiterte Semantik Function Allocation DiagramsEPC Event-Driven Process Chains (Englische Bedeutung)EPK Ereignisgesteuerte Prozessketten (Deutsche Bedeutung)EPML EPC Markup LanguageGUI Graphical User InterfaceHTML Hypertext Markup LanguageMDA Model Driven ArchitecturePIM Platform Independent ModelPNML Petri Net Markup LanguagePSM Platform Speci�c ModelSOA Service Oriented ArchitectureSVG Scalable Vector GraphicsSOAP Simple Object Access ProtocolUDDI Universal Description, Discovery and IntegrationUML Uni�ed Modeling LanguageURI Uniform Resource Identi�erURL Uniform Resource LocatorW3C World Wide Web ConsortiumWS-BPEL Web Service Business Process Execution LanguageWSDL Web Services Description LanguageXMI XML Metadata InterchangeXML eXtensible Markup LanguageXPath XML Path LanguageXSL eXtensible Stylesheet LanguageXSLT eXtensible Stylesheet Language Transformation

VI

Kapitel 1

Einleitung

1.1 Problembeschreibung

Es gibt zwei verschiedene Vorgehensweisen, um einen Geschäftsprozess zu modellieren. Dabei tref-fen immer zwei Gruppen aufeinander - die erste stellen die Fachbereiche und die zweite die IT-Entwickler dar. Die Betriebswirte, die häu�g die Fachbereiche vertreten, beschäftigen sich immer mitbetriebswirtschaftlichen Aktivitäten im Unternehmen. Sie modellieren fachliche Anforderungen als be-triebswirtschaftliche Geschäftsprozesse für Dokumentationszwecke, Prozessanalyse, -optimierung und-simulation. Ihr gra�sches Werkzeug stellt die leicht zu erlernende EPK-Notation dar. Diese basiertauf Ereignisgesteuerten Prozessketten (EPK), die von Scheer in [KNS92] verö�entlicht wurde,und stellt das fachliche Modell dar. Die Entwickler jedoch realisieren immer technische Prozessmo-delle. In diesem Zusammenhang wird im Moment immer auf die textbasierte Beschreibungssprache,wie Business Process Execution Language for Web Services (früher BPEL4WS [ACD+03], jetztWS-BPEL [OAS06b] oder kurz BPEL) verwiesen, mit der man technische Prozessmodelle zu kom-plexeren Geschäftsprozessen zusammenfügen kann, um diese anschlieÿend als Work�ow auf einerLaufzeitumgebung ausführen zu können. Daher ist es wichtig zwischen den zwei folgenden Begri�en,den betriebswirtschaftlichen und den ausführbaren, technischen Kompositions-Prozessen, zu unter-scheiden.

EPK und BPEL be�nden sich somit auf zwei unterschiedlichen Modellierungsebenen. Die EPKwerden für Prozess-Design auf der hohen und BPEL für Prozess-Implementierung auf der niedrigenAbstraktionsebene verwendet. Aufgrund der sich stetig ändernden Marktsituation werden Unter-nehmen gezwungen, die betrieblichen Geschäftsprozesse durch Rechnerunterstützung automatischablaufen zu lassen. Damit die Prozesse in einem Unternehmen aus der betriebswirtschaftlichen Sichtauf die Implementierungsebene erfolgreich abgebildet und auf einer Engine ausgeführt werden kön-nen, ist es notwendig die gra�sche EPK-Notation auf die textbasierte Ausführungssprache BPELtransformieren zu können [Sch06a; ZM05]. Die Reihenfolge ist sehr wichtig, da die Prozessmodellezuerst immer von Fachbereichen vorgegeben werden, die in dem nächsten Schritt von den Entwicklerntechnisch umgesetzt werden sollen. Dieser Punkt ist ein wichtiger wirtschaftlicher Aspekt, denn dieunternehmensspezi�schen Geschäftsprozesse müssen die IT-Abteilung leiten und nicht umgekehrt.Daher sollte die Dokumentation, Steuerung, Anpassung und Optimierung der technischen Prozess-modelle und der IT-Architektur mit abstrakten Darstellungsmitteln, wie der EPK-Notation, zuerstimmer aus der betriebswirtschaftlichen Perspektive erfolgen.

Der Abbildungsschritt von der fachlichen Ebene auf die technische Implementierungsebene er-folgt bislang immer manuell, was zu langen Entwicklungszeiten und vielen Risiken in einem Un-ternehmen führt, da die Lücke zwischen den verschiedenen Abstraktionsebenen überbrückt werdenmuss und bei der manuellen Überführung Fehler gemacht werden können. Weiterhin sind an einensolchen Entwicklungs- und Integrationsprozess verschiedene Expertengruppen beteiligt, so gibt eshäu�g Kommunikationsprobleme zwischen diesen Gruppen, die durch die verschiedenen Terminolo-gien und Ausbildungen geprägt sind. Es ist bekannt, dass ein umfassendes, methodisches Wissen zur

1

KAPITEL 1. EINLEITUNG 2

technischen Prozessmodellierung auf der Implementierungsebene in den Fachbereichen nicht voraus-gesetzt werden kann, denn der betriebswirtschaftliche Modellierer hat dafür nicht die notwendigenKenntnisse.

1.2 Beitrag dieser Arbeit

Der Beitrag dieser Masterarbeit ist die Abbildung von annotierten Geschäftsprozessen, die mit Hil-fe von EPK-Notation dargestellt werden, nach BPEL. Es wird erläutert, wie die betrieblichen Ge-schäftsprozesse aufbereitet werden können, um anschlieÿend aus diesen technische, ausführbare Work-�ows ableiten zu können. Dabei sollen konzeptuelle Unterschiede der beiden betrachteten Modelle unddie Grenzen der automatischen Transformation aufgezeigt werden. Die Abbildung der fachlichen An-forderungen auf die technische Implementierungsebene soll, soweit es geht, teil-automatisiert werden.Hierfür ist es notwendig, die vorhandenen Elemente in EPK gründlich zu untersuchen und diese auf dieBPEL-Elemente abzubilden. Da die beiden betrachteten Sprachen sich jedoch auf unterschiedlichenModellierungsebenen be�nden, handelt es sich bei der erwünschten Transformation nicht um eineeinfache Abbildung einer Ausgangssprache auf eine Zielsprache, sondern eher um eine Verfeinerungdes Ausgangsmodells [KTS05; Vis01]. Die Verfeinerung, die häu�g auch durch die Dekompositionbeschrieben wird, ist ein typisches Beispiel für die vertikale Transformation [MCG05; KK06], bei derdas Ausgangs- und das Zielmodell sich auf unterschiedlichen Abstraktionsebenen be�nden. Mittelsder Annotationen in Form von Attributen oder Elementen sollen Zusatzinformationen zu dem be-trachteten Modell hinzugefügt werden. Die Annotationen der Geschäftsprozesse sind nur ein Mittel,um die fachlichen Prozesse durch die technische Anreicherung in einen BPEL-Prozess transformierenzu können. Der Wunsch ist, den exportierten BPEL-Prozess anschlieÿend auf einer BPEL-Engineauszuführen. Systeme wie IBM WebSphere Application Server Enterprise, Oracle BPEL ProcessManager, Microsoft Biztalk Server 2004 oder auch ActiveBPEL Designer unterstützen BPEL undunterstreichen die praktische Relevanz der Sprache für die Web Service-Kompositionen. Daher mussein Konzept entwickelt werden, wie die EPK durch Zuhilfenahme von Annotationsmittel nach BPELtransformiert werden können. Durch eine Transformation auf eine ausführbare Beschreibungsspra-che kann eine vollständige Neumodellierung der Geschäftsprozesse durch die IT-Abteilung vermiedenwerden. Dadurch können Entwicklungskosten gesenkt und die Qualität der E-Business-Anwendungerhöht werden. Das Ziel ist eine verlustlose Transformation von annotierten Geschäftsprozessen inEPK nach BPEL sicherzustellen. Erst die verlustlose Überführung der Geschäftsprozesse ohne jeg-liche Informationsverluste in eine service-orientierte Architektur kann den ständig sich änderndenMarktbedingungen eine optimale Lösung bieten.

Als Grundlage soll die um Web Services erweiterte EPK-Notation von [Int06], die mit SOA-Funktionalität ergänzt wurde, verwendet werden. Zunächst muss jedoch untersucht werden, ob daserweiterte EPK-Schema für die Transformation geeignet ist oder dieses durch weitere Annotationenergänzt werden muss, damit diese Modellierungssprache e�zient transformiert werden kann, oder obdie zur Verfügung gestellte Version des EPK-Schemas sich schon erfolgreich nach BPEL abbildenlässt. Sollte der Fall eintreten, dass sich das vorgegebene Schemas für die Abbildung nicht eignet,so muss ein eigenes, annotiertes Schema entworfen werden. Zuletzt soll ein Prototyp beschriebenund implementiert werden, welcher die Abbildung unter dem Aspekt der Transformation einer XML-basierten Sprache auf eine andere XML-basierte Sprache vollführt. Für die EPK wird auf die XML-basierte Beschreibungssprache EPML von Mendling und Nüttgens [MN03a] zurückgegri�en. Sie stelltdas Eingabeformat und BPEL das Ausgabeformat der durchzuführenden Transformation dar.

KAPITEL 1. EINLEITUNG 3

1.3 Gliederung

Die vorliegende Arbeit gliedert sich in sieben Kapitel auf.

In Kapitel 1 (also in diesem Kapitel) wurden die Aufgaben- und Problemstellungen eingeführt.Sie bilden die Grundlage für den Aufbau der nachfolgenden Kapitel in dieser Masterarbeit.

In Kapitel 2 werden die theoretischen Grundlagen aufgeführt. Ebenso wird der Begri� der Trans-formation näher erläutert. Unter anderem wird hier auf verwandte Arbeiten verwiesen, um zu zeigen,welchen Stand die Forschung in diesem Zusammenhang aufweist und wie eine solche Transformationrealisiert werden kann.

In Kapitel 3 und 4 werden die Formate EPML und BPEL auf ihre Struktur untersucht und dieAnforderungen an EPML und BPEL als XML-Schema erläutert. Die Ergebnisse, die in diesen beidenKapiteln gesammelt werden, werden in dem nächsten Kapitel für die Transformation benötigt.

Nach der Einführung der beiden XML-basierten Sprachen EPML und BPEL befasst sich Kapitel 5mit dem Konzept der Transformation. Es werden zwei Konzepte vorgestellt, wie die Transformationrealisiert werden kann, wobei weiter nur ein Konzept ausführlich behandelt wird. Zum Schluss wirdeine kritische Bewertung des Konzeptes gegeben.

In Kapitel 6 wird anhand des Konzeptes zur Transformation die technische Realisierung erläutert.Hier wird anhand eines vollständig ausgearbeiteten Beispiels die Abbildung vorgestellt und erläu-tert, mit welchen software-technischen Hilfsmitteln die Implementierung durchgeführt worden ist.Als Ergebnis wird ein Konvertierungstool geliefert und erläutert.

In einem abschlieÿenden Kapitel 7 wird eine Zusammenfassung über die gesammelten Ergebnisseund ein Ausblick über mögliche Erweiterungen gegeben und inwieweit diese für die Praxis nützlichsein werden. Die Erweiterungen sollen an einer anderen Stelle ausführlicher behandelt werden.

1.4 Namenskonventionen

In der vorliegenden Masterarbeit werden einige Notations- und Layoutkonventionen verwendet, diedas Lesen erleichtern und die Übersichtlichkeit erhöhen sollen. Die De�nitionen und Zitate werdenin kursiver Schrift dargestellt. Der Quellcode von XML-Beispielen und XML-Elemente werden in derCourier-Schrift notiert und als Listing dargestellt. Für die Syntax von XML-Beispielen werdenweiterhin Diagramme und Syntaxbäume verwendet. XML-Elemente und -Attribute erscheinen imText als <element> und als attribute. Das erste Auftreten von englischen oder deutschen Fachbe-gri�en, wie Business Process Execution Language, wird fett und deren Abkürzung in Klammerngesetzt. Für das weitere Vorkommen dieser Begri�e wird anschlieÿend ausschlieÿlich deren Abkürzungverwendet. Fachspezi�sche Begri�e und deren Abkürzungen tauchen ebenfalls in dem Abkürzungs-verzeichnis und dem Index dieser Masterarbeit auf und können somit sehr schnell wiedergefundenwerden.

Eine ausführliche Behandlung aller in dieser Arbeit genannten Standards, die in den folgendenAbschnitten und Kapiteln eingeführt und erläutert werden, kann hier nicht gegeben werden, da dieseden Rahmen dieser Masterarbeit sprengen würden. Deshalb wird an den entsprechenden Stellen aufdie einschlägige Literatur verwiesen.

Kapitel 2

Allgemeine Grundlagen

In diesem Kapitel werden eingangs die allgemeinen Grundlagen der Geschäftsprozessmodellierung vor-gestellt. Diese werden benötigt, um das Konzept der Transformation von annotierten Geschäftspro-zessen nach BPEL im Kapitel 5 beschreiben zu können. In den nächsten beiden Abschnitten wirdzunächst die allgemeine De�nition zu Geschäftsprozessen und Web Services gegeben. Im Zusammen-hang mit den Web Services wird ebenfalls die service-orientierte Architektur eingeführt. Anschlieÿendfolgt die De�nition der Ereignisgesteuerten Prozessketten, die als Vertreter für die betrieblichen Ge-schäftsprozesse dienen.

2.1 Geschäftsprozesse

Eine gute De�nition zur Beschreibung des Begri�es Geschäftsprozess (Business Process) zu �nden,ist nicht einfach. So wurden in der Vergangenheit viele verschiedene De�ntionen geliefert, die denGeschäftsprozess auch auf unterschiedliche Weise beschreiben. Eine Recherche bei Google liefertmehr als 57 Millionen1 Einträge zu dem oben genannten Begri�. Eine gute Beschreibung, die einenGeschäftsprozess ausführlich beschreibt und deren grundlegenden Aspekte auch in vielen anderenDe�ntionen zu �nden sind, liefert Davenport:

De�nition: �a structured, measured set of activities designed to produce a speci�c output fora particular customer or market. It implies a strong emphasis on how work is done within anorganization, in contrast to a product focus's emphasis on what. A process is thus a speci�cordering of work activities across time and space, with a beginning and an end, and clearlyde�ned inputs and outputs: a structure for action. [...] Taking a process approach impliesadopting the customer's point of view. Processes are the structure by which an organizationdoes what is necessary to produce value for its customers � [Dav93]

Eine weitere De�nition liefert Alonso et al. und bringt ausdrücklich die Anwendungssysteme inseine Beschreibung ein:

De�nition: �We de�ne a business process as a collection of activities performed by humanusers or software applications that together constitute the di�erent steps to be completed toachieve a particular business objective. � [ACKM04]

Es lässt sich festhalten, dass jede funktionierende Organisation nur so gut ist, wie ihre Prozesseund Abläufe es sind [PR05]. Geschäftsprozesse sind eine spezielle Form von Prozessen und setzen sichin einem Unternehmen aus logischen, zeitbegrenzten Funktionen zusammen, die sehr oft nur als HighLevel Prozesse de�niert werden. Eine Funktion wiederum besteht aus Tätigkeiten oder Aktivitäteneinzelner Mitarbeiter. Die individuellen Prozesse sind dann Szenarien eines Geschäftsprozesses. DasErgebnis eines Geschäftsprozesses stellt anschlieÿend eine geforderte Leistung dar, die von Kundenbenutzt werden kann. So kann ein bestimmter Geschäftsprozess als Work�ow von funktionalen,zielgerichteten Aktivitäten betrachtet werden. Vom Work�ow wiederum spricht man dann, wenn

1Stand: 22.01.2007 - �Business Process� als zusammengesetztes Wort4

KAPITEL 2. ALLGEMEINE GRUNDLAGEN 5

der bestimmte Kontroll-, Daten�uss und die Ressourcenverteilung entlang der einzelnen Aktivitätenauf einer Laufzeitumgebung zur Ausführung [ACKM04] gebracht werden kann, d.h. also dass einWork�ow die Implementierung eines Geschäftsprozesses beschreibt. Eine solche Zusammenstellungvon einzelnen Aktivitäten zu Prozessen bzw. ausführbaren Work�ows bleibt nach wie vor eine dergröÿten Herausforderungen der Softwareentwicklung, wenn man die Vielfalt vorhandener Work�ow-Sprachen betrachtet, die die Ausführung der Geschäftsprozesse ermöglichen sollen.

Das groÿe Problem stellt jedoch auch nach wie vor die Gröÿe der Komplexität der Geschäftspro-zesse dar. Beim Beschreiben der Geschäftsprozesse kann sich der Entwickler sehr schnell in der Syntaxder Dokumente verlieren. Um betriebliche Geschäftsprozesse gra�sch darstellen zu können, wurdenin den letzten Jahren diverse Standards, wie EPK, Uni�ed Modeling Language (UML) [OMG05]oder Business Process Modellung Notation (BPMN) [BPM06b] für die gra�sche Darstellung derGeschäftsprozesse entwickelt. Die ersten beiden Standards sind die am meisten anerkannten Metho-den für die Modellierung von Geschäftsprozessen. Der letzte Standard ist auf dem besten Weg, zumNachfolger von EPK zu werden, da diese Sprache die Web Service-basierte Komposition unterstützt.Da die beiden ersten Sprachen keine Web Service-spezi�sche Elemente anbieten, müssen diese des-halb erweitert werden. Obwohl alle das gleiche Ziel verfolgen, die Geschäftsprozesse zu beschreiben,unterscheidet sich deren gra�sche Notation und deren Ausdrucksstärke. Aufgrund der hohen Ak-zeptanz in Europa und der weiten Verbreitung der EPK in der Praxis [VZHA05] werden in dieserArbeit für die Modellierung der Geschäftsprozesse die Ereignisgesteuerten Prozessketten verwendet.Als eine der hierfür unterstützenden Work�ow-Sprachen, die die Ausführung von Geschäftsprozessenermöglichen soll, wird hierfür im Folgenden BPEL näher betrachtet.

Geschäftsprozesse haben eine dynamische Eigenschaft, die sich gemäÿ den Marktbedingungen ver-ändern. Unternehmen müssen ihre Geschäftsprozesse verbessern, ändern und auf ihre Partner optimie-ren. Jede Veränderung der betrieblichen Anforderungen oder Verbesserung in einem Geschäftsprozessre�ektiert sich in ihrer Anwendung, die diese Prozesse ausführt. Solche ständigen Änderungen brin-gen die traditionellen IT-Architekturen an ihre Grenzen. Es können nur die Unternehmen am Marktbestehen, die ihre Anwendung schnell und e�zient gemäÿ den sich veränderten Marktbedingungenanpassen können. Service Oriented Architecture (SOA) ist momentan der populärste Ansatz zumLösen des Problems der ständig ändernden Anwendungsintegration. Beim SOA-Konzept wird das Zielverfolgt, die fachlichen Aktivitäten in Form von lose gekoppelten Web Services bereitzustellen undauf einer Ausführungsumgebung zur Ausfürhung zu bringen. Um schnell auf die geänderten Markt-anforderungen reagieren zu können, muss die grundlegende Fragestellung, wie Business Process

Management (BPM) und SOA zusammengefügt werden können, geklärt werden.

2.2 Web Services

Eine De�nition zu Web Services �ndet man bei Pera und Rintelmann.

De�nition: �Der Begri� Service oder Dienst meint eine Software-Einheit, die in sich abge-schlossen ist und, auf eine Kommunikationsplattform und einen Namensraum bezogen, freiverteilbar und auch wieder lokalisierbar ist. Ein solcher Service ist nur lose mit anderen Ser-vices gekoppelt [deren Schnittstellen über XML-Artefakte de�niert sind]. Web Services sindServices mit der Besonderheit, dass sie sich der Kommunikationsmechanismen des Web bedie-nen�. [PR05]

Web Services sind zurzeit die beste Lösung für die Integration von verschiedenen, autonomen E-Business-Systemen. Diese werden in Unternehmen eingesetzt, um eine �exible Software-Architekturzu gewährleisten. Die immer wiederkehrenden Funktionen im Unternehmen werden nur einmal imple-mentiert und anderen Programmen als Services zur Verfügung gestellt. Diese Vorgehensweise erlaubtes den Unternehmen �exibel den Prozessablauf an die geänderten Anforderungen anzupassen, um auf


die Marktveränderungen schnell reagieren zu können. Dadurch können Redundanzen vermieden undKosten in der Entwicklung gesenkt werden. Die Implementierungsdetails bleiben vor dem Benutzerverborgen, denn die beiden Teilnehmer müssen nur die Schnittstellende�nition kennen. Die Trennungdes Designs und der Entwicklung erlaubt eine fachliche Aufteilung der zu erstellenden Geschäftspro-zesse. Unabhängig voneinander können die Fachbereiche auf ihre Aufgabe abgestimmte Prozessede�nieren und anderen Fachbereichen diese als Service zur Verfügung stellen. Bei Änderungen mussanschlieÿend nur der Service geändert werden, wenn es keine so gravierenden Änderungen gab, diesich bis auf die Schnittstelle auswirken konnten. Nach der durchgeführten Änderung steht der Ser-vice wieder allen anderen Geschäftsprozessen zur Verfügung. Dadurch wird allen Geschäftspartnerneine hohe Qualität der Software bereitgestellt, was sich auch in den niedrigeren Gesamtkosten einesProjektes widerspiegelt.

Ein typisches Beispiel für die Nutzung der Web Services ist das Galileo-Air-System [Gal07], überwelches mehr als 470 Fluggesellschaften inklusive 62.000 Hotels und alle groÿen Mietwagen�rmenverbunden sind. Es können Flüge, Hotels und Mietwagen, wie gewohnt gebucht werden. Das Reser-vierungssystem der neuesten Generation basiert auf der modernen SOA-Systemarchitektur und setztauf die XML-Schnittstellen-basierte Web Service-Technologie.

2.3 Ereignisgesteuerte Prozessketten (EPK)

Ereignisgesteuerte Prozessketten (EPK) ist eine semi-formale und eine graph-orientierte Sprache,die zum Beschreiben von Geschäftsprozessen in Zusammenarbeit mit der SAP-AG entworfen wordenist. Diese wurde 1992 ausführlich in [KNS92] von Prof. Scheer beschrieben. Mit EPK ist es mög-lich, sehr schnell und einfach Geschäftsprozesse gra�sch darzustellen. Diese wird in Unternehmenzur Dokumentation von Geschäftsprozessen verwendet. Dies hängt damit zusammen, weil EPK einewichtige Grundlage des Modellierungsmodells von SAP und des ARIS-Konzepts [Sch01], [Sch02] vonIDS Scheer darstellt. Ein Nachteil existiert aber bei der Modellierung mit EPK. Diese Diagrammartbeschreibt nicht, wie ein Geschäftsprozess arbeitet, sondern es ist nur eine Deklaration von Bezie-hungen, die im Falle eines Geschäftsprozesses auftreten und wer an diesen beteiligt ist. Somit istes fast unmöglich einen Geschäftsvorfall hundertprozentig auf die Funktionsweise eines ausführbarenGeschäftsvorfalls abzubilden. Dieses hängt mit der Einfachheit der Diagrammart zusammen, da mitderen gra�schen Mitteln nicht alle Aspekte eines technischen Geschäftsprozesses dargestellt werdenkönnen. Deshalb wurden die EPK in den letzten Jahren immer wieder durch neue oder annotierteSymbole erweitert.

2.4 Business Process Execution Language (BPEL)

BPEL ist eine XML-basierte, ausführbare Sprache (executable BPEL) zur Modellierung und Be-schreibung der Prozesslogik auf der technischen Ebene. BPEL ist durch die Vereinigung zweier Spra-chenWork�ow Services Flow Language (WSFL) [Ley01] undWeb Services for Business Process

Design (XLANG) [Tha01] entstanden und erlaubt somit, zwei Konzepte bei der Beschreibung einestechnischen Geschäftsprozesses einzusetzen. XLANG wurde von Microsoft entwickelt und setzt aufdie block-orientierte Struktur. WSFL wurde von IBM entworfen und setzt auf das Konzept gerichteterGraphen. An dieser Stelle wird im Kapitel 5.3.3 angesetzt und erläutert, welche Beschreibung für dieDarstellung des Kontroll�usses in dieser Arbeit gewählt wird.

Wie ein betrieblicher Geschäftsprozess in EPK eine zeitlich-logische Abfolge von auszuführendenAktivitäten beschreibt, de�niert BPEL eine logische Reihenfolge, in der die Web Services aufgerufenwerden. Dieses Vorgehen wird auch Orchestrierung von Web Services genannt. BPEL sorgt dafür,dass die richtige Aufrufreihenfolge unterschiedlicher Web Services eingehalten wird, und beschreibt


somit die Integration diverser Web Services immer aus der Sicht eines bestimmten Partners, derinteressiert ist, dass die jeweiligen Aufgaben im Unternehmen von einem bestimmten Web Serviceausgeführt werden. Eine solche Abfolge von Web Service-Interaktionen wird auch als BPEL-Prozessbezeichnet.

BPEL-Prozesse können in abstrakte und ausführbare Prozesse unterteilt werden, wobei die erste-ren zur Beschreibung des Verhaltens des betrachteten Prozesses und die letzteren zur Ausführung aufeiner BPEL-Engine eingesetzt werden. In dieser Arbeit werden im Folgenden ausschlieÿlich die aus-führbaren BPEL-Prozesse näher betrachtet, da das Ziel verfolgt wird, aus EPK-Modellen lau�ähigeBPEL-Prozesse zu erzeugen.

Die Funktionalität der Web Services wird über plattformunabhängige Standards, wie Simple Ob-ject Access Protocol (SOAP) [W3C03], Web Services Description Language (WSDL) [W3Cb],[W3C06], Universal Description, Discovery and Integration (UDDI) [OAS06a] und der Beschrei-bungssprache BPEL2 bereitgestellt. Diese stellen auf SOAP Web Services aufsetzende Standardisie-rungsvorschläge dar und erlauben Anwendungen, mit anderen Systemen auf einer beliebigen Platt-form und unabhängig von der verwendeten Programmiersprache3 zu kommunizieren. BPEL dientdabei zur Beschreibung und der Koordination unterschiedlicher Geschäftsprozesse auf der Basis vonWeb Services, d.h. dass die schon existierenden und die neuen Services dabei mit BPEL zu einemausführenden Geschäftsprozess zusammengefügt werden.

Die Service-Komposition stellt im Vergleich zu der Geschäftsprozessmodellierung eine Low-Level-Entwicklung dar. Erst die festgelegte Reihenfolge von Web Services spiegelt die service-orientierteAnwendung und erlaubt, entlang dieser betriebswirtschaftliche Abläufe zu erkennen. Es ist somitmöglich, in BPEL die Prozesslogik unabhängig von den betrachteten Web Services zu behandeln.

Die mit BPEL erstellten Prozess-Kollaborationen der einzelnen Web Services repräsentieren sichnach auÿen als eigenständige, übergeordnete Web Services. Nach dem SOA-Prinzip lassen sich so-mit schon einmal orchestrierte Geschäftsprozesse zu gröÿeren Geschäftsprozessen zusammenführen.Dadurch ist auch eine Wiederverwendung der einmal erstellten Dienste gegeben und sie erlaubt da-mit, technische Prozesse zu abstrahieren. Die Komplexität der betrachteten Geschäftsprozesse wirddadurch erst beherrschbar.

Ein weiterer Vorteil von BPEL ist, dass die Änderungen der Geschäftslogik nur in der BPEL-Dateidurchgeführt werden müssen, da eine klare Trennung zwischen der Geschäftslogik und der Imple-mentierung besteht. SOAP stellt das Kommunikationsprotokoll zur Verfügung und WSDL beschreibtdie Schnittstellen und die Operationen eines einzusetzenden Web Services. Eine ausführlichere Ein-führung in WSDL und BPEL wird in Kapitel 4 gegeben. Für die De�nition von SOAP wird auf dieoben genannte Spezi�kation verwiesen, da diese im Zusammenhang mit der Komposition eher eineuntergeordnete Rollen spielt.

BPEL ist nur für erfahrene Benutzer geeignet, da die Datenstruktur sehr mächtig und komplex ist.Die Spezi�kation [ACD+03] weist ausdrücklich darauf hin, dass für BPEL keine gra�sche Notationexistiert. Deshalb versuchen viele Unternehmen ihre eigene Notation zu entwickeln, die nicht einheit-lich ist. Wenn man die diversen Darstellungsmöglichkeiten von BPEL-Prozessen genauer betrachtet,so verwenden unterschiedliche BPEL-Entwicklungsumgebungen verschiedene gra�sche Darstellungen.Diese Notationen re�ektieren direkt den BPEL-Code, der sehr nah an die BPEL-Syntax angelehnt ist.Deshalb ist diese Sprache für den Business Analysten eher ungeeignet, da er dazu gezwungen wird,in BPEL-Konstrukten zu denken. Alle einzelnen Regeln machen die Sprache BPEL so komplex, dasshierfür eine Sprache auf höherem Abstraktionslevel notwendig ist, die den BPEL-Code generieren

2Weitere Sprachen, die im Zusammenhang mit der Beschreibung von Work�ows erwähnt werden sollten, sind BPML(Business Process Modelling Language) [BPM06a], XPDL (XML Process De�nition Language) [Coa07]. DieseSprachen werden in dieser Arbeit jedoch nicht näher betrachtet.

3C++, C# oder Java spielen dabei keine Rolle, denn die Web Services basieren auf dem Prinzip des Nachrichtenaus-tausches, der über XML-Sprache durchgeführt wird.


kann. EPK als eine Sprache, die Abstraktionen erlaubt, darf nicht alle diese Implementierungsdetailsbeschreiben, sonst wird die Sprache überladen und den Business Analysten nur überfordern.

2.5 Warum braucht man eine Transformationvon EPK nach BPEL?

Wie im Abschnitt 2.2 eingeführt wurde, haben die EPK schon eine sehr lange Tradition bei derErstellung der Geschäftsprozessmodellierung. Viele Unternehmen haben ihre Strategie und Ziele inEPK-Diagrammen modelliert und haben hierfür viel Geld investiert. Deshalb möchte man bei einerbekannten Modellierungssprache bleiben und folgende Umstrukturierungen, die immer mit einer Um-stellung auf eine andere Beschreibungssprache verbunden sind, vermeiden. Eine neue Beschreibungs-sprache erzwingt immer, dass die Mitarbeiter im Unternehmen darauf geschult werden müssen undeine solche Umstellung nicht von heute auf morgen in groÿen Unternehmen realisiert werden kann.Weiterhin müssen neue Modellierungstools angescha�t werden, was sich eindeutig in Lizenzkosten4

niederschlägt. Diese Aspekte sind mit groÿem Aufwand verbunden und kosten immer viel Geld. Undzuletzt darf nicht vergessen werden, dass die im Unternehmen über mehrere Jahre angesammeltenGeschäftsprozessmodelle von der EPK-Notation in eine andere neue Beschreibungssprache migriert5

werden müssen. Dafür müssen dann auch Migrationstools geschrieben werden, die eine verlustloseTransformation erlauben. Deshalb versucht man bei einer bekannten Modellierungssprache zu bleibenund die neu entwickelten Prinzipien, wie SOA, in diese Sprache zu integrieren.

Da EPK mit der SOA-Erweiterung eine Ausführungsengine benötigen, muss eine Transformationauf eine bekannte BPEL-Engine durchgeführt werden, um die Neuentwicklung einer weiteren Enginezu vermeiden. BPEL wird als Zielsprache verwendet, da sich BPEL in der letzten Zeit von allenanderen Standards absetzen konnte und somit zum Defacto-Standard für Web Service-Kompositionenauf der Implementierungsebene erklärt werden kann. Wenn im Verlauf der Arbeit von Transformationgesprochen wird, dann ist damit die Transformation von annotierten Geschäftsprozessen nach BPELgemeint.

Sehr häu�g wird im Zusammenhang mit der Transformation von den Modelltransformationen

[KK06] gesprochen. So wird in [CH03] eine ausführliche Klassi�kation von Ansätzen zur Umwand-lung von verschiedenen Modellen geliefert. Die Modelltransformationen spielen eine besondere Rollebei der Abbildung fachlicher Geschäftsprozesse auf technische Orchestrierungsmodelle. Diese wer-den für die �Automatisierung von Entwicklungs- und Integrationsprozessen� [KK06] eingesetzt. EineModelltransformation wird deshalb benötigt, da die unterschiedlichen Sprachen, die für die Beschrei-bung der Modelle eingesetzt werden, unterschiedliche Stärken besitzen und häu�g nur auf bestimmteModellierungsaspekte ausgelegt sind. Die hier eingesetzten Modelle, die zur Beschreibung der Struk-tur und des Verhaltens betrieblicher Geschäftsprozesse de�niert werden, werden in dieser Arbeit inder Modellierungssprache EPK beschrieben. Eine solche Modellierungssprache hat üblicherweise ei-ne Syntax und eine Semantik, die bei der Modelltransformation zum Zielmodell BPEL übertragenwerden muss.

Delphi Group hat 2003 eine Studie BPM2003 Market Milestone Report [Del03] verö�entlicht,die eine Liste an vermissten Features bei Geschäftsprozesslösungen enthält. An erster Stelle mit 44Prozent wird bemängelt, dass ein standardisierter Austausch von Geschäftsprozessen das gröÿte Pro-blem in der Geschäftsprozessmodellierung darstellt. Die hohe Anzahl verschiedener Tools in BPM

4Es wird davon ausgegangen, dass eine Neuanscha�ung von neuen Modellierungstools mit höheren Kosten verbundenist, als ein Update eines vorhandenen Systems von demselben Hersteller durchzuführen.

5Vgl. [MCG05] �Migration from a program written in one language to another, but keeping the same level of abstrac-tion.�


wird mittlerweile zu einem groÿen Problem. Diese Vielfalt der Tools führt zu enormen Interopera-bilitätsproblemen. So würde eine eigene EPK-Engine das Interoperabilitätsproblem nicht lösen, daes sehr wichtig ist, dass man auf vorhandene Standards zurückgreift. Die Interoperabilität greiftebenfalls auf die Geschäftsprozesse über, wenn durch Zusammenarbeit die Geschäftsmodelle zusam-mengefügt, ausgetauscht und anschlieÿend ausgeführt werden sollen. Denn in so einem Fall tre�enzwei verschiedene Geschäftsmodelle aufeinander, die ihre eigene Stärken und Schwächen besitzen.

2.5.1 Verwandte Themen

In vergangenen Jahren wurde eine Vielzahl von Transformationskonzepten in der wissenschaftlichenLiteratur diskutiert. Um das Problem des ständigen Wandels der Geschäftsprozessmodellierung unddas Problem der Komplexität und der Produktivität [Man03] zu lösen, wurden diverse Mapping-Tools entwickelt. Es wurden unter anderem verschiedene EPK-Transformationskonzepte vorgestellt.Die Zielsprachen waren UML-Diagramme [NFZ98], Petri-Netze [CS94; LSW97a; LSW97b; Rod97]oder auch SVG6 [MBN04]. Nach wie vor wird aber auch bemängelt, dass kein einheitliches Schemaexistiert, welches erlauben würde, die verschiedenen Beschreibungssprachen in sich zu vereinen. DieExistenz eines solchen Schemas würde den Transformationsprozess erheblich erleichtern.

Bei der Aufgabe, Ereignisgesteuerte Prozessketten nach BPEL umzuwandeln, stellt sich die Fra-ge, ob nicht bereits bekannte Ansätze für die Transformation nach BPEL existieren, die in dieserArbeit herangezogen werden können. So hat die umfangreiche Literaturrecherche sehr viele inter-essante Konzepte geliefert, die in der Vergangenheit ausführlich behandelt worden sind und für dieTransformation von annotierten Geschäftsprozessen nach BPEL ansatzweise übernommen werdenkönnen. Es gab zuletzt sehr viele Versuche, das Verhalten von BPEL mit Hilfe von graph-orientiertenSprachen zu beschreiben. So hat man versucht, die Finite State Machines [FFK04], Petri-Netze[OAB+05; Sta04; VA05], Work�ow Netze [AL05], Abstrakte State Machines [DR05] oder auchProzess-Algebra [Fer04] für die Beschreibung der BPEL-Prozesse zu benutzen. Es wurden eben-falls BPEL-Analysen [WADH02], [WADH03], die auf Work�ow Patterns [AHKB02; Aal] basieren,herangezogen.

Im Rahmen der Abbildung der EPK nach BPEL gibt es zurzeit ebenfalls einige Transformations-ansätze, die in wissenschaftlichen Beiträgen diskutiert werden. Im Folgenden werden diese Trans-formationskonzepte vorgestellt und kurz erläutert. Anschlieÿend wird daraus ein Konzept abgeleitetund gezeigt, wie der Kontroll�uss und der Daten�uss in EPK zusammen mit notwendigen Anno-tationen nach BPEL übertragen werden kann, um einen ausführbaren BPEL-Prozess zu erzeugen,da die bislang bekannten Ansätze sich entweder nur mit dem Kontroll�uss oder nur mit abstraktenBPEL-Prozessen beschäftigt haben.

(1) In [MLZ05] stellen Mendling, Lassen und Zdun vier Transformationsstrategien vor, wie maneine Transformation zwischen einer block-orientierten Sprache BPEL und einer graph-orientiertenGeschäftsprozessmodellierungssprache realisieren kann. Des Weiteren stellen Mendling und Ziemannin [MZ05] ausgehend von fertigen BPEL-Prozessen eine Transformation zu EPK-Diagrammen vor.Hier wird vorgeschlagen für welche BPEL-Elemente man äquivalente EPK-Elemente verwenden soll.Für die in dieser Arbeit umgekehrte Transformation können die vorgeschlagenen Entsprechungenansatzweise übernommen werden.

(2) In [Kop05] wird die Abbildung von EPK, die mittels des Prozessmodellierungstools Nautiluserstellt werden, nach BPEL durchgeführt. Dabei unterscheidet sich die Nautilus-EPK-Syntax von dervon Scheer eingeführten EPK-Notation. Der hier exportierte, abstrakte BPEL-Prozess, welcher imnächsten Schritt vom Entwickler weiter verarbeitet werden soll, soll anschlieÿend als Vorlage für einenausführbaren BPEL-Prozess benutzt werden.

6Scalable Vector Graphics


(3) In [Sch06b] wird ein Konzept vorgestellt, wie eine service-orientierte Architektur in betrieblicheGeschäftsprozesse integriert werden kann. Der Autor stellt bei seiner Untersuchung folgendes fest:

�Aufgrund der unterschiedlichen Abstraktionsgrade der verschiedenen Modelle ist im Momenteine Vollautomatisierung undenkbar. Die Erweiterung der EPKs um die notwendigen tech-nischen Details sowie Laufzeitaspekte, würde ihrer Intention als intuitive Geschäftsprozessbe-schreibungssprache einer fachlichen Sicht nicht gerecht werden. Es ist einem Entscheidungsträ-ger eines Unternehmens nicht zuzumuten, für die Laufzeit wichtige Aspekte bei seiner Modellie-rung von Geschäftsprozessen miteinzubeziehen. Daher ist eine vollautomatische Transformationunrealistisch.� [Sch06b]

(4) Das im Rahmen des Forschungsprojektes OrViA7 eingesetzte Konzept [SKW06; Ste06] verfolgtdas Ziel der teil-automatischen Transformation der EPK nach BPEL. OrViA-Projekt steht für dieOrchestrierung und Validierung integrierter Anwendungssysteme. Das Ziel, welches hier von IDSScheer und vielen weiteren Universitäten verfolgt wird, ist die Abbildung fachlicher Prozessmodelleauf domainspezi�sche Laufzeitumgebungen. Die Aufgaben sind wie folgt aufgeteilt. Fraunhofer IAObeschäftigt sich mit der Anforderungsanalyse, FSU Jena mit der Validierung, Universität Leipzigmit der Transformation und IDS Scheer mit dem Integrierten Vorgehen [TK07]. Daher wurden andas betrachtete Konzept viel mehr Anforderungen gestellt, als sie in dieser Arbeit gemacht werdenkönnen. Weiterhin läuft das Projekt schon seit Ende 2005 und ist auf eine Dauer von drei Jahrenausgelegt. Es sind nur wenige Verö�entlichungen frei verfügbar, die auch nur die Anforderungenvorstellen und keine weitere Einzelheiten.

�Könnte eine zumindest teil-automatische Transformation von EPK nach BPEL gescha�en wer-den, würde dies entscheidend zur Schlieÿung der Lücke zwischen Geschäftsprozessmodellierungund technischer Umsetzung beitragen.� [Ste06]

Das hier vorgestellte Vorgehen basiert selbst auf dem von Kühne et al. vorgestellten Paper[KTS05]. Es werden zuerst in fachlichen Modellen, die in der EPK-Notation vorgegeben sind, dieAblaufkonstrukte, Interaktionsmuster und abstrakte Schnittstellenkonstrukte identi�ziert und durchvorgefertigte Entsprechung auf der Implementierungsebene ersetzt. Die patternbasierte Transforma-tion soll ebenfalls teilautomatisiert erfolgen und manuelle Arbeitsschritte beseitigen, die sehr häu�gzu Fehlern führen können.

Nachfolgend wird in dieser Arbeit nur die Transformation näher betrachtet, da sonst der Rahmender Arbeit gesprengt wird.

(5) Unabhängig von dem oben dargestellten OrViA-Projekt hat IDS Scheer8 in [BK06; Klü06;Klü07] das Konzept zur Transformation von fachlichen Anforderungen in EPK nach BPEL vorge-stellt. Bei diesem Ansatz wird die funktionale Dekomposition über EPK-Diagramme durchgeführtund erlaubt dem Benutzer für die Modellierung der fachlichen Anforderungen verschiedene Sich-ten zu benutzen. Dieser Ansatz geht einen weiteren Schritt und erlaubt ebenfalls die Modellierungvon Web Services, die mit Hilfe des UML-Diagramms durchgeführt wird. Weiterhin wird in [Ste07]ausdrücklich darauf hingewiesen, dass Assign-Aktivitäten im Transformationsprozess nicht erzeugtwerden können.

7Das OrViA-Forschungsprojekt wird durch das Bundesministerium für Bildung und Forschung (BMBF) unter demFörderkennzeichen 01 ISE 10 gefördert und vom Projektträger Deutsches Zentrum für Luft- und Raumfahrt e.V.(DLR) betreut.

8Der neue ARIS SOA Designer in der Version 7.0 von IDS Scheer [IS] unterstützt eine Transformation von EPK,die eine automatische Generierung von ausführbaren BPEL-Prozessen ermöglicht. In [BK06] wird im Allgemeinenbeschrieben, wie eine solche Transformation auszusehen hat. Es existieren aber bislang keine ö�entlichen Spezi�ka-tionen dafür, wie die Transformation in Details durchgeführt wird. Leider war es aus Lizenzgründen nicht möglicheine Evalution der generierten BPEL-Prozesse durchzuführen.


(6) Das in [WGL05] vorgeschlagene Vorgehensmodell erlaubt mit der ARIS-Methode ebenfallseine Übertragung der EPK-Geschäftsprozesse in BPEL-Serviceprozesse durchzuführen. Dieses Kon-zept führt eine eigene gra�sche Darstellung ein, welche erlaubt EPK-Prozesse mit entsprechendenHintergrundmodellen zu entwerfen. Weiterhin weist das Konzept ausdrücklich darauf hin, dass aufeine weitere Sprache, wie BPMN, verzichtet werden kann. Wagner et al. stellt folgendes fest:

�Analysen zur Übertragung eines Geschäftsprozessmodells in einen Serviceprozess9 zeigen auf,dass eine automatische Übersetzung der bestehenden fachlichen Modellobjekte einer EPK ineinen Serviceprozess kaum durchführbar ist. Technisches Verständnis über die Semantik derService-Notation sowie fachliche Kenntnisse sind für einen verlustfreien Transfer erforderlich.[...] die EPK - legen ihren Schwerpunkt auf eine intuitive und �exible Abbildung der fachlichenAnforderungen. Diese aus betriebswirtschaftlicher Sicht vorteilhafte Semi-Formalität machtdie automatische Generierung von XML-Code scheinbar unmöglich. Komplexität, Umfang undMehrdeutigkeiten der Modelle stellen bisherige Transformationsansätze vor geradezu unüber-windbare Hindernisse. Henkel bezeichnet die verlustfreie Überführung als allgemein schwierigesUnterfangen [12]10. Zudem ist der Nutzen einer Transformation auf Knopfdruck im Rahmeneines ganzheitlichen GPM in Frage zu stellen.�

9Mit dem Serviceprozess ist ein Prozess gemeint, der bestimmte Aufgaben durch einzelne Services erledigen lässt.10Vgl. [12] - Henkel, M. Zdravkovic, J.; Johanesson, P: Service Based Processes - Design for Business and Technology,

ACM Press, 2004

(7) In [TF06a] wird der Ontologie-Ansatz über die Sprache Web Ontology Language (OWL)verfolgt. Die einzelnen Elemente eines EPK-Modells werden durch die formale Ontologie beschrieben,die als semantische Annotation betrachtet werden. Dafür werden verschiedene Schichten, die auchLayers genannt werden, eingeführt. Ausgehend von einem EPK-Modell wird entsprechend mit zuneh-mendem Grad die Abstraktion des zugrunde liegenden EPK-Modells zu einer allgemeinen Semantikerhöht. Die oberste Schicht 4 enthält demnach die Business Ontologie, die alle relevanten Konzep-te und Beziehungen eine Geschäftsprozessmodellierung enthält. Diese wird über die OWL-Klassenbeschrieben. Ausgehend von der obersten Schicht 4 zu der darunter liegenden Schicht 3 werdendie spezialisierte Konzepte benutzt, um individuelle Geschäftsprozesselemente zu modellieren. Diesekönnen in Form von eindeutigen Funktionen, wie z.B. Auftragsbestätigung vorliegen. Auf dieser Ebe-ne werden auch die zusätzlichen Informationen hinzugefügt. Diese können entweder weitere Detailsfür die technische Implementierung und Ausführung der betrachteten Prozesse enthalten oder kön-nen auf semantische Art beschränkt werden. Die instantiierten Klassen können anschlieÿend in derdarunter liegenden Schicht 2 benutzt werden, um eine semantische Beschreibung der vorliegendenGeschäftsprozesse zu erzeugen.

(8) Die in [SDTK05] behandelte Transformation weist ausdrücklich darauf hin, dass die gewünsch-ten Aspekte, wie Benutzerinteraktionen oder das Aufrufen von Serviceoperationen direkt nicht zuEPK hinzugefügt werden können. Der Grund hierfür ist, dass die zusätzlichen Informationen dasEPK-Diagramm mit technischen Details überladen werden. Aus diesem Grund wurde hier eine er-weiterte Semantik Function Allocation Diagrams (eFADs) eingeführt. Dadurch ändert sich dasModellierungskonzept grundlegend. Die EPK werden für die Top-Down-Modellierung und für dasAusmodellieren von Unterprozessen verwendet. Die erweiterte Semantik wird zur Beschreibung derAktivitäten und der aufzurufenden Operationen zu jeder EPK-Funktion verwendet. Dabei beschreibtdas eFAD exakt die Sequenz der aufzurufenden Aktivitäten mit den dazu gehörigen Ein- und Ausga-bedaten.

(9) [Wit06] befasst sich mit dem Konzept der Model Driven Architecture (MDA), dem mehr-stu�gen Modelltransformationskonzept, um eine Verschaltung der Web Services entlang von Ge-schäftsprozessen durchzuführen. Geschäftsprozesse werden auf einer hohen Abstraktionsebene (PIM)modelliert. Danach werden erweiterte Modelle, die Metainformationen, zur Ausführung auf einer be-stimmten Plattform (PSM) tragen, hinzugefügt. Hierfür wird die Modellierungssprache UML einge-


setzt, um anschlieÿend eine lau�ähige Geschäftsprozesslogik in BPEL zu erzeugen. Die automatischeGenerierung von Programmcodes soll im Gegensatz zu der manuellen Erstellung der Ablaufprozesseeine geringere Fehleranfälligkeit enthalten.

(10) In [VZHA05] und [KK05] werden die Probleme der semantischen und der syntaktischenInteroperabilität bei der XML-basierten Transformation in der Geschäftsprozessmodellierung ange-sprochen, die bei der Abbildung des einen Formats auf ein anderes Format auftreten können. Derletzte Ansatz geht noch einen Schritt weiter und versucht ein gemeinsames Format zu de�nieren,welches Abbildungen von unterschiedlichen Modellierungssprachen, wie EPK, erlauben soll. Von die-sem Format soll es dann möglich sein, in jede weitere Sprache eine Abbildung durchführen zu können.Die Zielsprache stellt in diesem Fall XML Process De�nition Language (XPDL)9 dar. Eine weitereTransformation von EPK nach XPDL wird in [BDR06] präsentiert.

Die bisher vorgestellten Methoden, ausgenommen Punkt 10, haben sich mit der Abbildung derEPK-Diagramme nach BPEL beschäftigt. Wie man fast allen Beiträgen entnehmen kann, stellt dieTransformation von EPK nach BPEL ein schwieriges Unterfangen dar. Als nächstes werden zweiweitere Methoden kurz vorgestellt und erläutert, die angestrebt haben, von anderen graphischenBeschreibungssprachen eine Generierung des BPEL-Codes zu erzeugen.

(11) In [AL05; LA06] stellen van der Aalst und Lassen ein Verfahren vor, mit dessen Hilfe Work-�ow Nets, die eine Unterklasse von Petri Netze darstellen, nach BPEL transformiert werden können.Diese Sprache fasst den Kontroll�uss in sich zusammen, der in vielen anderen graph-orientiertenSprachen benutzt wird. Des Weiteren weisen die Autoren darauf hin, dass jede zur Zeit bekanntegraph-orientierte Sprache, wie EPK, UML AD, BPMN oder auch Yet Another Work�ow Lan-

guage (YAWL), auf Work�ow-Nets abgebildet werden kann, um diese anschlieÿend nach BPEL zutransformieren. So lassen sich in dem Paper vorgestellte Ideen auf andere graph-orientierte Model-lierungssprachen übertragen. Dieser Beitrag beschäftigt sich ausschlieÿlich mit der Abbildung desKontroll�usses.

(12) In [ODBH05] wird eine Unterklasse von BPMN nach BPEL abgebildet. Das hier vorgestellteKonzept wies bis dahin jedoch noch einige Probleme auf, so wurden anschlieÿend Verbesserungendes Transformationskonzeptes in [OADH06b] und [OADH06a] eingeführt. Dieser Beitrag beschäftigtsich ebenfalls nur mit der Abbildung des Kontroll�usses. In dieser Arbeit wird im Kapitel 5.1.1 kurzangesprochen, wie das EPML-Format auf die Unterklasse von BPMN abgebildet werden kann, umanschlieÿend daraus BPEL-Code generieren zu können. Hier wird zusätzlich zu dem in dieser Arbeiterstellten Prototyp ein einfaches Transformationsprogramm geliefert, welches das EPML-Format aufdie Unterklasse BPMN abbildet, welches anschlieÿend als Eingabeformat für den in [OADH06a]vorgestellten Generator verwendet werden kann.

Die aktuellen Verö�entlichungen zu den Transformationskonzepten nach BPEL verdeutlichennochmals die Wichtigkeit einer solchen Entwicklung. Zur Vollständigkeit wird auf die zugrunde lie-genden Arbeiten verwiesen.

Da die bisher vorgestellten Ansätze sich nur mit dem abstrakten BPEL-Prozess oder nur mitdem Kontroll�uss beschäftigt haben, soll in dieser Arbeit nun gezeigt werden, wie EPK-Modelle an-notiert werden können, um daraus ausführbare BPEL-Prozesse generieren zu können. Aus diesemGrund wird in dieser Arbeit eine Zwischenebene eingeführt, die dem Entwickler erlaubt, notwendigeErweiterungen an dem EPK-Diagramm vorzunehmen, um die Überführung des Kontroll�usses unddes Daten�usses zu teil-automatisieren. Dabei sollen unter anderem die Grenzen einer automati-schen Transformation aufgezeigt werden. Es lässt sich festhalten, dass die Business Analysten mitden notwendigen Annotationen überfordert wären, deshalb ist es erforderlich, Rollen einzuführen,um genau festzulegen, von wem die technischen Annotationen zu dem fachlichen Geschäftsmodell

9XPDL wird von der Work�ow Management Coalition (WfMC) seit 1993 vorangetrieben und standardisiert. Seit Mai2005 liegt diese in der Version 2.0 vor.


hinzugefügt werden sollten. Des Weiteren wird gezeigt, wie die Benutzerinteraktionen von EPK nachBPEL abgebildet werden können.

2.5.2 Ziel der Transformation

Das Ziel der Transformation ist die Codeerzeugung in der Beschreibungssprache BPEL, die zur spä-teren Ausführung auf einer BPEL-Engine eingesetzt werden kann. So soll es möglich sein, die einmalerstellten Geschäftsprozesse in EPK durch die Transformation automatisch durchlaufen zu lassenund daraus Code zu generieren. Die automatische Transformation von Geschäftsprozessen in dieausführbare Beschreibungssprache BPEL würde den Modellierungsprozess enorm erleichtern und dieSynchronisation zwischen Geschäftsanforderungen und deren technischer Ausführung um einiges be-schleunigen. Dafür müssen jedoch die EPK, die die Geschäftsprozesse beschreiben, durch Annotati-on in Form technischer Aspekte oder durch Web Services erweitert werden. So kann der fachlicheGeschäftsprozess in einen technischen BPEL-Prozess umgewandelt werden. Der exportierte BPEL-Prozess kann anschlieÿend auf jeder beliebigen BPEL-Engine wie Oracle Process Server, IBM WebSphere, BEA WebLogic oder SAP XI ausgeführt werden. So können die Kosten bei der Umwandlunggesenkt und dadurch Wettbewerbsvorteile [Jir04] verscha�t werden.

Ein solcher Ablauf würde dann aus folgenden Schritten bestehen:

� Planung von Geschäftsprozessen mittels EPK

� Modellierung und Optimierung der erstellten Prozesse

� Konvertierung der EPK-Notation nach BPEL

� Orchestrierung von Web Services

2.6 Elemente von Ereignisgesteuerten Prozessketten

EPK bestehen hauptsächlich aus drei Basiselementen, den Ereignissen, den Funktionen und denVerknüpfungsoperatoren, die auch Konnektoren genannt werden. Der Kontroll�uss eines bestimm-ten Geschäftsprozesses wird als eine unternehmensspezi�sche Abfolge von Ereignissen (Zuständen),Funktionen (Aktivitäten), Verknüpfungsoperatoren und Prozess-Schnittstellen beschrieben. In derAbbildung 2.1 ist ein einfaches Beispiel eines EPK-Diagramms dargestellt.

Es folgen die Beschreibung der einzelnen Elemente und einige Regeln, die eingehalten werdenmüssen, damit ein EPK-Diagramm syntaktisch korrekt ist.

Ereignisse - sind passive Elemente, die Funktionen auslösen können, d.h. sie beschreiben dieVorbedingungen von Funktionen. Ein Ereignis beschreibt ein Objekt und seinen derzeitigen Zustand,wobei dieser einen betriebswirtschaftlichen Zustand im Unternehmen repräsentiert. Ein Ereignis kanndas Ergebnis einer Funktion sein. Die Ereignisse können den Kontroll�uss eines Prozesses beginnen,unterbrechen oder auch beenden.

Funktionen - sind aktive Elemente, die im Unternehmen etwas durchführen, d.h. diese verbrau-chen immer bestimmte Ressourcen und Zeit. Die Funktion beschreibt ein Objekt und eine bestimmteMethode, die ausgeführt wird. Die Funktionen beschreiben die Aktivitäten, Operationen oder Pro-zeduren [Sch06a], die in einem Geschäftsprozess relevant sind. Diese transformieren die Ein- undAusgabedaten in einem Prozess und verfügen über die Entscheidungskompetenz über den weiterenAblauf von Geschäftsprozessen. Sie sind auch die Erzeuger für Ereignisse.


Abbildung 2.1: EPK-Notation eines Geschäftsprozesses ohne Web Service-Unterstützung

Prozessschnittstelle - Ein nachfolgender oder ein vorhergehender Prozess wird durch eine Pro-zessschnittstelle dargestellt. Über die Prozessschnittstelle können die Prozessketten, die einen be-stimmten Geschäftsvorfall beschreiben, miteinander verbunden werden.

Kontroll�uss - Die aktiven und passiven Elemente und die Konnektoren werden über Kontrol-�usspfeile verbunden.

Ein EPK-Prozess muss eine alternierende Folge von Ereignissen und Funktionen enthalten. Esmuss einem Ereignis eine Funktion und einer Funktion immer ein Ereignis folgen. Es sei denn, eswurden Operatoren dazwischen geschaltet. Die Ereignisse und Funktionen können linear, paralleloder auch als alternative Verzweigungen modelliert werden.

Verzweigungsoperatoren - sind Konnektoren, diese geben die Möglichkeit alternative Verzwei-gungen in einem Geschäftsprozess zu modellieren. Die EPK schreiben exakt vor, wie die Anzahl derVerbindungen zwischen den Funktionen und den Ereignissen auszusehen haben. Jede Funktion undjedes Ereignis darf nur eine ein- und eine ausgehende Kante haben. Ein Konnektor im Vergleich dazukann jedoch mehrere eingehende und eine ausgehende Kante (Join) und eine eingehende und mehrereausgehende Kante (Split) besitzen. In EPK treten folgende Operatoren auf:

� AND - beschreibt eine Konjunktion, d.h. alle Funktionen müssen ausgeführt werden oder alleEreignisse müssen auftreten. AND wird im Zusammenhang mit parallelen Prozessen verwendet.

� OR - beschreibt eine Disjunktion, d.h. es muss mindestens eine Funktion ausgeführt werdenoder mindestens ein Ereignis muss eintre�en - eine oder mehrere Alternativen.

� XOR - beschreibt ein Exklusive-ODER, d.h. es muss genau eine Funktion ausgeführt werdenoder genau ein Ereignis auftreten - genau eine Alternative ausgewählt werden.

Mit Hilfe der drei Operatoren können insgesamt zehn von zwölf zulässigen Verknüpfungen aus-drückt werden. Dies hängt damit zusammen, weil ein Ereignis keine aktive Entscheidungskompetenzbei Geschäftsprozessen besitzt, da ein Ereignis ein passives Element darstellt. Das heiÿt, dass derPfad sich nach einem Ereignis nicht durch einen OR bzw. XOR-Operator splitten darf. Deshalb


sind die beiden Split-Verknüpfungen nicht zulässig. Alle anderen Join- und Split-Verknüpfungen kön-nen problemlos dargestellt werden. Die Verzweigungsmöglichkeiten sind ebenfalls im Anhang C inder Abbildung C.1 dargestellt und werden anschlieÿend bei der Optimierung des EPK-Modells einebedeutende Rolle spielen.

Die letzte wichtige Charakteristik von EPK stellen die Ressourcen, die der EPK-Funktion zuge-ordnet werden können, dar. So wurde nach der Verö�entlichung von EPK eine erweiterte Version(eEPK)10 in [Sch98] vorgestellt, die folgende Ressourceelemente wie Organisationseinheit (processparticipants), Daten- und Informationssysteme (data �eld) oder auch Anwendungskomponente (ap-plication) unterstützt. Diese Zuordnung wird auch Annotation von Funktionen genannt.

Organisationseinheit - wird einer Funktion zugeordnet und beschreibt die Organisation im Un-ternehmen, die die Aufgabe dieser Funktion erledigt. Einer Funktionen können auch mehrere Orga-nisationseinheiten zugeordnet werden.

Informationsobjekt - wird mit Funktionen verbunden, um aus dem Informationsobjekt Daten zuladen oder in das Informationsobjekt die Daten zu speichern. Das heiÿt, dass ein Informationsobjektdie Datenbestände in einem Unternehmen beschreibt. Die Funktionen benötigen und erzeugen dieInformationsobjekte.

Anwendungskomponente - wird einer Funktion zugeordnet und beschreibt eine bestimmte Sys-temkomponente, die im Geschäftsprozess benutzt werden soll. So können zum Beispiel Web Servicesals eine Anwendungskomponente verstanden werden.

2.7 Syntax und Semantik von EPK

Die EPK wurden von Scheer ohne die formale Semantik eingeführt. In [CS94] und [Aal99] schlagenScheer und van der Aalst vor, deshalb eine Umwandlung der Prozessketten auf Petri-Netze durch-zuführen, um eine automatische Verarbeitung der EPK-Notation bei der Veri�kation und Simulationvon Prozessmodellen zu gewährleisten. Um den Umweg über die Petri-Netze zu vermeiden, fordernNüttgens und Rump in [NR02] nach einer korrekten Formalisierung und Implementierung der EPK-Syntax11 und -Semantik.

Diese Forderung konnte von keinem bis dahin bekannten Ansatz �vollständig auf der Grundlage derursprünglichen Syntax und Semantik� [NR02] gelöst werden, da die EPK-Formalisierungen nicht aus-reichend waren oder mit Einschränkungen formalisiert wurden. Deshalb haben Nüttgens und Rumpauf der Grundlage der EPK-Syntax und -Semantik eine mathematische Formalisierung des Kontroll-�usses durchgeführt. Ihr Vorgehen sollte nun eine korrekte Anwendung von Geschäftsprozessmodellenerlauben und zugleich eine Fehlinterpretation eines dokumentierten Modells vermeiden. Der Ansatzerlaubt weiterhin die vorliegende EPK-Syntax und -Semantik, um weitere spezi�sche Aspekte wieMengen-, Ressourcen- und Zeitkonzepte zu erweitern. �Ein weiterer wichtiger Nutzen liegt in derBereitstellung adäquater [...] Transformationsverfahren� [NR02]. So wird gesagt, dass mit der vorge-stellten Formalisierung ein durchgängiges Konzept zur werkzeug-gestützten Steuerung, Kontrolle undPlanung von Geschäftsprozessen existiert12. Leider erweist sich auch diese vorgeschlagene Semantik

10Vgl. [Sch] �Dieser Sprachgebrauch wird hier jedoch nicht empfohlen, da keine einheitliche Meinung darüber existiert,welche Sprachkonstrukte zu einer Grundform und welche zu einer erweiterten Form der EPK gehören. Auch in derModellierungspraxis wird diese Bezeichnung uneinheitlich verwendet.�

11Vgl. [KK06] �[...] bei der Syntax (wird) nochmals zwischen konkreter und abstrakter Syntax unterschieden. Dieabstrakte Syntax beschreibt die Konzepte und die Struktur der Sprache. Die konkrete Syntax (Notation) de�niertdie zur Verfügung stehenden Zeichen der Sprache. Die Semantik der Sprache legt die Bedeutung der in der abstraktenSyntax verwendeten Konzepte fest.�

12Vgl. [GL05] �[...] für eine automatische Verarbeitung von EPK-Modellen (etwa in Werkzeugen zur Simulation oderVeri�kation) muss jedoch eine formale Semantik der Modelle de�niert werden.�


als nicht perfekt. So haben van der Aalst, Desel und Kindler das Problem der Nicht-Lokalität des OR-Join und XOR-Join Operators in [KAD02] aufgezeigt und erläutert, dass für die EPK keine formaleSemantikde�nition13 geben kann, da die EPK erlauben, Geschäftsprozesse mit Deadlocks zu model-lieren, was bei der Ausführung eines Geschäftsprozesses vermieden werden sollte. Daher werden dieEPK als eine semi-formale Sprache und mit einigen Einschränkungen de�niert, um die vielseitigenMöglichkeiten der EPK zu begrenzen. Welche Einschränkungen in Bezug auf die Transformation ander EPK-Semantik in dieser Arbeit durchgeführt werden, wird ausführlich in Kapitel 5 behandelt.

2.7.1 Graph-orientierte Charakterisierung der EPK

Die Graphentheorie de�niert einen Graph aus Knoten V (verteces) und Kanten E (edges). EineKante e ∈ E verbindet genau zwei Knoten. Man spricht von einem gerichteten Graphen, wenn dieKanten zwischen den Knoten im Graphen durch Pfeile dargestellt werden, wobei gilt e ∈ V ×V .Jeder Pfeil zeigt dabei von einem Anfangs- zu einem Endknoten und verbindet somit diese in derdargestellten Richtung. Der Graph ist zusammenhängend , wenn man von jedem Knoten im Graphenzu jedem anderen Knoten gelangt. Gibt es keine Folge von Kanten über die jeder Knoten erreichtwerden kann, so zerfällt der Graph in mehrere Teilgraphen und wird als nicht zusammenhängendbezeichnet.

Die graph-orientierte Charakterisierung lässt sich auf das EPK-Diagramm übertragen. Diese Über-tragung ist im Zusammenhang mit dem Kontroll�uss sehr wichtig. Demnach ist ein EPK-Modell eingerichteter und zusammenhängender Graph. Die Knoten im EPK-Graphen werden durch die Funktio-nen, die Ereignisse, die Menge der Konnektoren und durch die Prozess-Schnittstelle beschrieben. DieKontroll�usskanten zwischen diesen Elementen stellen die gerichteten Kanten des Graphen dar. Wer-den diese Anforderungen an den Kontroll�uss nicht eingehalten, ist die Transformation nach BPELnicht durchführbar. Für die Abbildung der EPK nach BPEL reicht die in dem nächsten Abschnittgemachte De�nition der EPK-Syntax und -Semantik aus.

2.7.2 De�nition der EPK-Syntax und -Semantik

In Verbindung mit der Transformation wird in diesem Abschnitt die De�nition der EPK-Syntax kurzvorgestellt. Eine Syntax beschreibt die Zusammenstellung und Regeln der gra�schen Elemente.

De�nition: (Flache Hierarchie) Flache Hierarchie wird als ein gerichteter, zusammenhängenderGraph dargestellt. Eine �ache EPK ist eine Menge M = (E,F,P,C, l,A), die aus vier paarweise dis-junkten Mengen E, F , P und C besteht. Die Abbildung l : C → and,or,xor ist eine binäre Relationund es gilt A⊆ (E×F)∪ (F×E)∪ (E×C)∪ (F×C)∪ (C×F)∪ (C×E)∪ (C×C):

- | • e| ≤ 1 und |e • | ≤ 1 für jedes e ∈ E. Ein Element von E wird Ereignis (event) genannt.Wobei gilt | • e|= 0 und |e• |= 1 für einen Start-Ereignis und | • e|= 1 und |e• |= 0 für einenEnd-Ereignis.

- | • f |= 1 und | f • |= 1 für jedes f ∈ F . Ein Element von F wird Funktion ( function) genannt.

- | • p| = 1 und |p• | = 0 oder | • p| = 0 und |p• | = 1 für jedes p ∈ P. Ein Element von P wirdProzess-Schnittstelle (process interface) genannt.

- | • c| = 1 und |c • | > 1 oder | • c| > 1 und |c • | = 1 für jedes c ∈C. Ein Element von C wirdKonnektor (connector) genannt.

13Vgl. [GL05] �Der Grund dafür, dass über Jahre hinweg immer wieder neue Vorschläge zur De�nition einer Semantikgemacht wurden, liegt im Wesentlichen in den Problemen begründet [...] : der Nichtlokalität von Verknüpfungskon-nektoren und der fehlenden Unterstützung mehrfacher Instanziierung.�Weitere Bemühungen die EPK-Semantik formal zu beschreiben, werden ausführlich in [GL05] verglichen.


- Die Abbildung l spezi�ziert den Typen eines Konnektors c ∈C, als and, xor oder or.

- Der Kontroll�uss wird als direkter Graph spezi�ziert. Ein Element von A wird als Kante (arc)bezeichnet.

De�nition: (Vorgänger und Nachfolger-Knoten) Sei N eine nicht-leere Menge von Knoten (nodes),wobei N = E ∪F ∪P∪C gilt und A⊆ N×N eine binäre Relation über N, die die Menge der Kanten(arcs) beschreibt. Für jeden Knoten n∈N wird eine Menge von Vorgängerknoten (predecessor nodes)•n = x ∈ N|(x,n) ∈ A und eine Menge von Nachfolgerknoten (successor nodes) n•= x ∈ N|(n,x) ∈ Ade�niert.

De�nition: Hierarchisches EPK-Schema stellt eine Menge von �achen Hierarchien dar. Die Ver-knüpfung zwischen den Hierarchien wird über eine Dekomposition einer Funktion oder über eineProzess-Schnittstelle durchgeführt.

Die EPK de�nieren zwei verschiedene Dekompositionskonzepte. Der erste wird über die hierar-chische Funktion und der zweite über die Prozessschnittstelle beschrieben. Die hierarchische Funk-tionen sind mit einem Unterprozess vergleichbar, wobei hier eine Funktion durch weitere Funktionenauf der nächst tieferen Ebene verfeinert wird. Die verfeinerten Funktionen stellen in ihrer Gesamt-heit eine eigene EPK dar und geben den Kontroll�uss nach dem Abarbeiten aller EPK-Elementedes Unterprozesses wieder an die übergeordnete Funktion zurück. Auf der anderen Seite stehen dieProzess-Schnittstellen, die ebenfalls auf eine weitere EPK verweisen. Der grundlegende Unterschiedist jedoch, dass diese auf der gleichen Ebene anzusiedeln sind. Hier wird der Kontroll�uss nichtzurückgegeben. Dieses Konzept erlaubt das einfache Einandersetzen einzelner EPK zu einander. Indieser Arbeit werden die Prozess-Schnittstellen nicht betrachtet.

Damit die syntaktische Richtigkeit erfüllt wird, müssen folgende Eigenschaften eingehalten wer-den. Diese Regeln lassen sich zu vier Blöcken von Bedingungen [MN03c] zusammenfassen. DieseBlöcke sind aus der genaueren Untersuchung der oberen De�nition der EPK-Syntax und -Semantikentstanden.

Block 1: Hier werden die Eigenschaften eines �achen EPK-Schemas de�niert. Ein solches Sche-ma besteht nur aus folgenden Elementen, wie Ereignis, Funktionen, Konnektoren und Prozess-Schnittstellen und wird als ein gerichteter und zusammenhängender Graph dargestellt. Es darf alsMenge der Kanten nur das kartesische Produkt vorhandener Elemente in einem Graph vorkommen.Der Graph muss einfach sein und darf keine Zyklen enthalten. Wie im Abschnitt 2.6 angesprochenworden ist, muss ein solcher Graph mindestens ein Start- und Endereignis vorweisen.

Block 2: Beschreibt die Kardinalitätsbeziehungen zwischen den Elementen. Die Funktionen undEreignisse dürfen nur genau einen Vorgänger und einen Nachfolger haben, d.h. sie dürfen genau eineeingehende und genau eine ausgehende Kontroll�usskante besitzen. Bestimmte Ereignisse müssenweiteren Einschränkungen unterliegen. Ein Startereignis oder eine Prozess-Schnittstelle darf keinenVorgänger und genau nur einen Nachfolger haben, sei es entweder ein Ereignis oder eine Funktion.Die Join-Konnektoren dürfen viele Vorgänger und nur genau einen Nachfolger besitzen. Die Split-Konnektoren dagegen dürfen nur genau einen Vorgänger und viele Nachfolger besitzen.

Die beiden anderen Blöcke werden der EPK-Semantik zugeordnet. Eine Semantik beschreibt dieBedeutung einer Folge von Elementen. Einige der sehr einfachen Regeln wurden schon oben imZusammenhang mit den EPK-Elementen vorgestellt. Im Folgenden werden noch ausstehende Regelnde�niert.

Block 3: Die Ereignisse können nur den Funktionen und die Funktionen den Ereignissen fol-gen. Das heiÿt, dass die Ereignisse nur mit Funktionen oder mit der Prozess-Schnittstelle verbundenwerden dürfen. Es kann sich eine beliebige Anzahl von Konnektoren zwischen Funktionen und Ereig-nissen be�nden. Wie in der Abbildung C.1 dargestellt ist, dürfen nach Ereignissen keine OR- oder


XOR-Konnektoren verwendet werden. Die verzweigten Pfade, die durch das Einsetzen von Konnek-toren entstanden sind, müssen wieder durch gleichartige Verzweigungsoperatoren zusammengefügtwerden.

Block 4: Ein EPK-Diagramm erlaubt, Hierarchien aufzubauen. Diese können über eine Prozess-Schnittstelle oder über eine hierarchische Funktion realisiert werden. Die hierarchische Funktion oderdie Prozess-Schnittstelle wird über eine Hierarchierelation genau einer weiteren EPK zugeordnet.

Für eine vollständige mathematische Formalisierung der EPK-Syntax und -Semantik wird auf[NR02] verwiesen.

2.8 Zusammenfassung

In diesem Kapitel wurden die allgemeinen Grundlagen für die Transformation von annotierten Ge-schäftsprozessen nach BPEL behandelt. Eingangs wurde eine allgemeine De�nition für die Ge-schäftsprozesse und die Web Services, die nur eine Möglichkeit der SOA-Realisierung darstellen,gegeben. Es wurde der hierfür notwendige Standard, wie EPK, eingeführt und erläutert. Anschlieÿendwurde ausführlich beschrieben, warum man eine solche Transformation benötigt. Die Geschäftspro-zesse in EPK sind eine alternierende Folge von Funktionen und Ereignissen. Da die EPK-Notation nurfür gra�sche Dokumentationen verwendet wird, enthält diese Beschreibungssprache keine technischenAspekte, die für die Transformation nützlich sein können. Die Informationen, die das EPK-Modellliefert, beziehen sich hauptsächlich nur auf die Beschreibung des Kontroll�usses in dem betrachtetenEPK-Diagramm.

In Kapitel 3 und 4 wird im Zusammenhang mit der Untersuchung der BeschreibungsspracheEPML und BPEL das EPML-Schema und das BPEL-Schema auf ihre Dokumentstruktur genaueruntersucht. Die Untersuchung der Syntax ist erforderlich, um die relevanten EPML-Elemente undBPEL-Elemente für die Transformation zu identi�zieren.

Kapitel 3

EPML-Dokumentstruktur

In Kapitel 2 wurden eingangs die Gründe für die Transformation und alle dafür notwendigen Stan-dards, die für das Abbilden von EPK nach BPEL notwendig sind, angesprochen. Es werden Kenntnissein XML [W3Ca] und XML-Schema [W3C01] vorausgesetzt, um das behandelte Thema verstehen zukönnen. Denn es ist nicht die Aufgabe dieser Arbeit die Grundkenntnisse zu erarbeiten. Bevor in Kapi-tel 5 das Konzept für die Transformation von annotierten Geschäftsprozessen nach BPEL vorgestelltwird, muss die Dokumentstruktur von EPML in diesem Kapitel genauer untersucht werden, da diesesdie EPK in sich kapselt. In [Int06] wurde von Intas gezeigt, wie die EPK um Web Services erweitertwerden können. Dieses EPML-Schema muss ebenfalls untersucht und erläutert werden. Denn hiermuss auch geklärt werden, ob die durchgeführten Erweiterungen von Intas für die Transformationnach BPEL ausreichend sind oder ob es notwendig sein wird, die Transformation anhand andererAnnotationen1 durchzuführen.

3.1 Warum XML als Austauschformat?

eXtendable Markup Language (XML) hat sich in den letzten Jahren als intermediäres Austausch-format (interchange format) für diverse Anwendungen, unter anderem für die Geschäftsprozessmo-dellierung und für die Web Services, durchgesetzt. Es ist werkzeug-, plattformunabhängig2 und dazunoch lizenzfrei [Fis01] erhältlich. Da Web Services auf XML basieren, eignet sich XML auch hierhervorragend für den Austausch der Informationen zwischen zwei Partnern. Ein XML-Dokument be-schreibt hauptsächlich die Struktur der Daten, die in dieser Datei abgelegt werden sollen. Damitein XML-Dokument wohl geformt und gültig ist, muss dieses bestimmten Regeln für den Aufbauvon Dokumenten folgen. Zur ausführlichen Einführung in XML wird an dieser Stelle auf [ABKu00]verwiesen.

3.1.1 XML-Schema

Ein XML-Schema3 eignet sich hervorragend, um ein XML-Dokument auf seine syntaktische Richtig-keit zu spezi�zieren und zu überprüfen. Dieses legt die Struktur eines XML-Dokuments eindeutig fest.Da die Document Type De�nitions (DTDs) gewisse Nachteile besitzen und keine Unterstützungfür die Namensräume besitzen, wird für die Transformation auf das XML-Schema zurückgegri�en.Ein XML-Schema ist wiederum selbst ein XML-Dokument und erlaubt komplexere Strukturen durchFestlegen von Regeln zu beschreiben, als dies es mit DTD der Fall wäre. Damit ein XML-Dokumentvalidiert werden kann, muss das XML-Schema bestimmte Anforderungen erfüllen, die in [W3C01]

1Vgl. [PR05] �Über die Standardelemente hinaus können Syntax und Semantik der Modellelemente verfeinert bzw.erweitert werden, um das Maximum an fachlich relevanter Modellinformationen zu hinterlegen.�

2Plattformunabhängigkeit ist eines der wichtigsten Design-Prinzipien in Software Engineering - so können die ein-mal modellierten Geschäftsprozesse auf einer anderen Zielplattform eingesetzt werden, ohne diese modi�zieren zumüssen.

3XML Schema wird im XSD-Format (XML Schema De�nition Language) abgespeichert

19

KAPITEL 3. EPML-DOKUMENTSTRUKTUR 20

nachgelesen werden können. Ein weiterer Vorteil ist, dass durch die XML-Syntax Programmierer denselben Parser für die erstellten Dokumente und Schemata verwendeten können, um die Struktur derMetadaten in dem Schema zu analysieren.

3.1.2 XML-Transformationsformen

Transformationen spielen eine besondere Rolle bei der Arbeit mit XML, denn bestehende XML-Daten können auch in einem anderen Kontext verwendet werden. In [ABKu00] wird zwischen dreiverschiedenen Formen der XML-Transformation unterschieden. Diese wird in folgende Kategorieneingeteilt:

� Strukturelle Transformation - eine XML-basierte Beschreibungssprache in eine andere Be-schreibungssprache transformieren.

� Erzeugung dynamischer Dokumente - Reorganisieren, Filtern und Sortieren der Daten.

� Transformation in eine Sprache zur Darstellung - XML-basierte Sprache in eine Darstel-lungssprache wie HTML oder SVG (Scalable Vector Graphics) umwandeln.

Bei dem in Kapitel 5 vorgestellten Konzept zur Transformation von annotierten Geschäftsprozessennach BPEL wird hauptsächlich die strukturelle Transformation betrachtet. Da EPK sich mit Hilfeder Beschreibungssprache EPML beschreiben lassen und somit die EPK in sich einkapseln, wird imFolgenden eine Transformation von EPML nach BPEL betrachtet.

3.2 EPC Markup Language (EPML)

Die rasante Entwicklung der Geschäftsprozessmodellierung hat dazu geführt, dass auf der Basis vonXML diverse Austauschformate entwickelt worden sind, die man auch als XML-Dialekte bezeich-net. Eines solcher XML-Dialekte stellt die Beschreibungssprache EPC Markup Language (EPML)dar, die im Rahmen der Forschungsarbeiten [MN03c], [MN03b] von Mendling und Nüttgens ent-wickelt worden ist. Eine XML-basierte Transformation von Geschäftsprozessmodellen fördert denAustausch und die Integration von Geschäftsprozesswissen. Das Ziel, welches verfolgt wurde, ist dieStandardisierung eines einheitlichen Austauschformates für die ereignisgesteuerten Prozessketten. In[MN03c] wird ausführlich beschrieben, nach welchen Kriterien der Vergleich der Konvertierungsstra-tegien durchgeführt worden ist. Bei vielen Formaten erweist sich jedoch das intermediäre Formatals die beste Lösung. EPML ist für Ereignisgesteuerten Prozessketten ein solches intermediäres,werkzeug-unabhängiges und XML-basiertes Austauschformat.

Vergleichbare Austauschformate, die in dieser Untersuchung nicht betrachtet werden, die aber diegleiche Funktion erfüllen sollen, stellen folgende Standards dar:

� XMI - XML Metadata Interchange4

� PNML - Petri Net Markup Language5

Alle oben genannten XML-Dialekte hatten das Ziel verfolgt, die Integrationsfähigkeit von Werk-zeugen und Methoden [MN03c] bei der Modellierung von Geschäftsprozessen zu verbessern, und umdie gra�sch modellierten Prozesse auf einem Rechner ausführen zu können.

4XMI stellt ein Mappingformat für UML (Uni�ed Modeling Language) dar, welches von OMG (Object ManagementGroup) entwickelt und zum Standard erklärt wurde.

5PNML ist ein Austauschformat für Petri-Netze, welches sich durch Flexibilität und durch Strukturierungsmöglichkei-ten auszeichnet.


Viele Unternehmen verwenden bei der Modellierung ihrer EPK-Geschäftsprozesse die ARIS-Methode.Dadurch werden EPK-Diagramme in ARIS Markup Language (AML) abgespeichert. AML ist eineigenes Format der Firma IDS Scheer und wird für die EPK-Notation verwendet. AML ist jedochein proprietäres Format und hat im Vergleich zu EPML gewisse Nachteile, sowohl in dem Aufbaudes Format als auch in der Menge der notwendigen Elemente, die benötigt werden, um ein EPK-Modell überhaupt beschreiben zu können. Des Weiteren gibt es keine frei verfügbare Tools, die dieModellierung von EPK-Diagrammen in AML erlauben können. Eine manuelle Erstellung von EPK-Modellen ist im AML-Format aufgrund der oben genannten Nachteile nicht möglich. Aufgrund dieserAspekte wurde für die Beschreibung der EPK für das EPML-Schema6 in der Version 1.2 entschie-den. EPML ist ein werkzeugunabhängiges Format stellt eine formale Beschreibung für die Syntaxund die Semantik der EPK dar. Mit dieser EPML-Version ist es möglich alle EPK-Elemente darzu-stellen, und sowohl �ache EPK-Schema als auch hierarchische EPK-Schema zu beschreiben. SolltenEPK-Modelle im AML-Format, dem internen ARIS-Toolset-Format, vorliegen, so kann mit Hilfe ei-nes XSLT-Transformationsskriptes [MN04] eine Umwandlung von AML nach EPML durchgeführtwerden.

Die Konvertierung der EPK-Notation nach BPEL soll, wie in der Abbildung 3.1 dargestellt, ausge-führt werden. Das Ziel ist, eine teil-automatische Gesamt-Transformation herzustellen. In [KK05] wirdausdrücklich darauf hingewiesen, dass, wenn die auf der Business-Ebene verwendete Sprache keineeindeutige Formalisierung besitzt, eine Transformation der Modelle von der Business-Ebene zu dertechnischen Ebene in der Regel nur teil-automatisiert und nur mit manueller Unterstützung erfolgenkann, wohingegen die Transformation von Modellen der technischen Ebene auf die Ausführungsebenevollautomatisch vollzogen werden kann.

Der erste Punkt muss an dieser Stelle ebenfalls bestätigt werden. Zwar existiert für die EPK dasEPML-Austauschformat, welches eindeutig die EPK-Elemente beschreiben kann, allerdings bleibt dieBeschreibungssprache EPK nach wie vor eine semi-formale Sprache, wie es in Abschnitt 2.7 erläutertwurde. Aufgrund dieses Sachverhalts kann die Abbildung von der Business-Ebene auf die technischenur teil-automatisiert erfolgen, da das EPML-Schema für die Beschreibung der EPK ohne EPK-Regeln keine gültige EPK-Diagramme liefern kann. Zur Vereinfachung der Gesamt-Transformationwird davon ausgegangen, dass ein korrektes EPK-Diagramm im EPML-Format vorliegt, welches nurnoch um Zusatzinformationen ergänzt werden muss.

Dagegen kann der zweite Schritt nicht vollautomatisiert durchgeführt werden, da im EPML-Format, obwohl dieses auf der technischen Ebene anzusiedeln ist, die notwendigen Informationen fürdie Ausführung auf der Ausführungsebene fehlen. Weiterhin ist bislang keine EPK-Engine zur Ausfüh-rung von EPK-Modellen bekannt, auÿer der Simulationskomponente im ARIS [IS] und dem von Intasvorgeschlagenen Prototyp [Int06]. Um den Umweg nicht über eine weitere Engine zu gehen, muss eineTransformation zu einer bekannten Ausführungsumgebung BPEL durchgeführt werden. Zur Konver-tierung nach BPEL muss man eine BPEL-Dokumentstruktur erzeugen, die der Validität genügen soll.Es bleibt also zu klären, ob der Schritt von der technischen Ebene auf die Ausführungsebene sichebenfalls automatisieren lässt, damit die Gesamt-Transformation ebenfalls automatisiert durchgeführtwerden kann. Die Annotationen7 in dem EPK-Diagramm sind für den Transformationsprozess vongroÿer Bedeutung. Diese sind dafür erforderlich, um ein EPK-Modell auf einer Ausführungsumgebungzur Ausführung zu bringen. Da ohne solche Annotationen die Ausführung eines Geschäftsprozes-ses nicht gewährleistet werden kann, müssen implementierungsspezi�sche Eigenschaften hinzugefügtwerden. Deshalb muss geprüft werden, wie für die Ausführung der Transformation die notwendigenInformationen hinzugefügt werden können. Wenn die Transformation erfolgreich durchgeführt werdenkann, dann ist die problemlose Integration von EPK-Modellen in BPEL möglich.

6http://wi.wu-wien.ac.at/home/mendling/EPML/EPML_12.xsd7Vgl. [TF06b] semantische Annotationen = Verknüpfung von EPK-Modellelementen mit Ontologieinstanzen


Abbildung 3.1: Ablauf der Transformation über EPML und des Mappings auf BPMN

In Anbetracht verschiedener Technologien und deren Beschreibungssprachen werden die betrieb-lichen Geschäftsprozesse in der Praxis über Platform Independent Model (PIM) beschrieben unddaraus abgeleitete Methoden zur Transformation auf Platform Speci�c Model (PSM) zu übertra-gen. Dieses Konzept wird im Zusammenhang mit der Model Driven Architecture (MDA)8 ver-wendet. Die ereignisgesteuerten Prozessketten, die in PIM anzusiedeln sind, sollen dabei nach BPEL(PSM) transformiert werden. Hierfür ist es notwendig die Metamodelle in UML von EPK und BPELzu vergleichen und daraus Transformationsregeln abzuleiten. In dieser Arbeit wird nicht angestrebtnoch ein weiteres UML-Metamodell für die beiden Sprachen EPML und BPEL zu entwerfen. DerVergleich wird jeweils an den XML-Schemata der beiden Sprachen durchgeführt, da diese ebenfallsMetamodelle darstellen.

Eine Transformation zwischen zwei verschiedenen Modellen erlaubt weiterhin einen Vergleich derAusdrucksstärke zwischen den betrachteten Beschreibungssprachen - in unserem Fall zwischen EPMLund BPEL oder zwischen der gra�schen Notation EPK und BPMN - herzustellen.

Bevor das EPML-Schema im übernächsten Abschnitt näher auf ihre Syntax untersucht wird,müssen die Anforderungen an ein solches Schema vorgestellt werden.

3.2.1 Anforderungen an das EPML-Schema für EPK

In [Men03] forderte Mendling die Notwendigkeit eines XML-Schemas für die EPK. Ein einheitli-ches XML-Schema löst die Probleme, die beim Austausch von Modellen zwischen verschiedenenWerkzeugen entstehen. Der EPML-Austauschformat wurde unter der Betrachtung folgender Design-Prinzipien [MN03a], wie Lesbarkeit, Erweiterbarkeit, Tool-Orientierung und syntaktische Richtigkeitder EPK entworfen. Diese EPML-Gestaltungsprinzipien waren der grundlegende Aspekt beim Entwurfdes Austauschformates, deren Vorteile in [MN05] nachgelesen werden können.

8Vgl. [Wit06] - MDA verfolgt das Ziel einer klaren Trennung zwischen der Funktionalität einer Anwendung undder verwendeten Technik. Mittels der Generatoren soll dabei aus formalen Modellen Codeerzeugung durchgeführtwerden.


Im Zusammenhang mit der Transformation spielt der Aspekt der Erweiterbarkeit und die syn-taktische Richtigkeit eine wichtige Rolle. Beim Ersteren handelt es sich um implementierungsori-entierte Anforderungen. Hierfür muss es möglich sein, zusätzliche Informationen zu den einzelnenEPK-Objekten hinzufügen zu können. Bezugnehmend auf [MN02] ist es anschlieÿend �möglich, dasKontroll�ussmodell sukzessive zu erweitern, bis eine Konvertierung in ein Work�ow-Modell oderBPML möglich ist� . Da zu dem Zeitpunkt, an dem diese Aussage gemacht wurde, BPEL sich noch inder Entwicklungsphase befunden hat, wurde die Ausführungssprache BPML genannt. Es macht aberkeinen so groÿen Unterschied, da die beiden Sprachen im Vergleich zu einander groÿe Ähnlichkeitenlaut [MNN04] aufweisen.

Der letzte Aspekt - die syntaktische Richtigkeit der einzelnen EPK - beschreibt die veri�kations-orientierten Anforderungen und lässt sich laut [MN03c] mit der Struktur von XML-Schemas alleinenicht beschreiben. Hierfür ist es notwendig, die EPK-Syntax und die EPK-Semantik, die in Kapitel 2vorgestellt wurden, genauer zu betrachten. Diese Anforderungen müssen deshalb aus den EPK-Regelnentnommen werden. Sie werden eine besondere Rolle bei der Transformation nach BPEL spielen.

3.2.2 EPML-Struktur

In diesem Abschnitt wird das EPML-Schema näher beschrieben. Dieses unterstützt alle EPK-Elemente,die in Kapitel 2 eingeführt worden sind. Für die Transformation werden nur die notwendigen Elementebetrachtet und näher erläutert. Wenn eine genauere De�nition der einzelnen Elemente gewünscht ist,dann wird auf [MN05] verwiesen. Das EPML-Format soll als Eingabeformat in die Transformationeingehen. Die nachfolgend eingeführten Beschreibungen sollten zum Verständnis der Transformationausreichen.

In Anlehnung an die De�nition von Grammatiken werden XML-Grammatiken durch eine informaleSyntax mit Hilfe folgender Symbole *,? und + in der XML-Instanz beschrieben. Diese Symbole werdenbenutzt, um das Vorkommen der Attribute und Elemente beschreiben zu können. Das Zeichen ?bedeutet, dass das Element oder das Attribut optional ist, d.h. also 0 oder 1 vorkommen darf. DasPlus-Zeichen + bedeutet, dass das Element oder das Attribut mindestens einmal vorkommen muss,d.h. 1 oder mehr. Das Stern-Zeichen * beschreibt, dass das Element oder das Attribut kein einzigesMal oder beliebig oft vorkommen kann, d.h. 0 oder mehr.

Für die Transformation nach BPEL werden nicht alle EPML-Elemente des EPML-Schemas be-nötigt und es werden nicht alle ein äquivalentes Gegenstück in BPEL haben. Zu den irrelevantenElementen gehören hauptsächlich die Elemente, die in dem Listing 3.1 mit dem Fragezeichen alsoptionale Elemente gekennzeichnet sind, obwohl das Fragezeichen hier eine andere Bedeutung hat.Dazu zählen unter anderem die gra�schen Elemente; da für BPEL diese Informationen irrelevantsind, werden diese im Folgenden nicht mehr betrachtet. Weitere relevante und irrelevante Elementemüssen deshalb in diesem Abschnitt zunächst identi�ziert und erläutert werden.

Listing 3.1: EPML-Elemente dargestellt als Syntaxbaum[MN05]1 epml2 documentation?3 toolInfo?4 graphicsDefault?5 fill? (color, image, gradient-color, gradient-rotation)6 line? (shape, width, color, style)7 font? (family, style, weight, size, decoration,8 color, verticalAlign, horizontalAlign, rotation)9 coordinates (xOrigin, yOrigin)

10 definitions?11 definition* (defId)12 name13 attributeTypes?14 attributeType* (typeId)15 directory (name)


16 directory* (name) ...17 epc* (epcId, name)18 attribute* (typeRef, value)19 event* (id, defRef) ...20 function* (id, defRef)21 name22 graphics23 position? (x,y, width, height)24 fill? (color, image, gradient-color, gradient-rotation)25 line? (shape, width, color, style)26 font? (family, style, weight, size, decoration, color,27 verticalAlign, horizontalAlign, rotation)28 syntaxInfo? (implizitType)29 toProcess? (linkToEpcId)30 configurableFuction*31 attribute* (typeRef, value)32 processInterface* (id, defRef) ...33 and* ...34 or* ...35 xor* ...36 application* ...37 participant* ...38 dataField* ...39 relation* ...

Das Wurzelelement aller EPML-Dateien stellt <epml> vom Typ typeEPML dar, welches folgendesieben Kindelemente, wie <documentation>, <toolInfo>, <graphicsDefault>, <coordina-tes>, <definitions>, <attributeTypes> und <directory> de�niert.

Das Element <attributeTypes> stellt eine De�nition für zusätzliche strukturierte Informationenzur Verfügung. So können über das Kindelement <attribute> in allen EPK-Elementen mit Hilfevon typeRef und value statistische oder kon�gurierbare Annotationen hinzugefügt werden. <at-tributeTypes> wird in der EPML-Datei oben de�niert und die einzelnen Elemente, die das <at-tribute>-Element tragen und den dazu gehörigen Wert festhalten, haben eine Referenz auf dieseDe�nition. Somit ermöglicht dieses Element, beliebige Zusatzinformationen zu allen EPK-Elementenhinzuzufügen. An dieser Stelle wird in Abschnitt 3.4 fortgesetzt, da sich dieses Element ideal für dieAnnotationen eignet.

Eine wichtige Rolle in dem EPML-Format spielt das Element <directory>. Hier werden allenotwendigen Elemente zur Beschreibung des Kontroll�usses in einem EPK-Diagramm de�niert. Daskomplexe Element <typeEPCElement>, welches das Kindelement von <directory> ist, wird für dieDe�nition aller EPK-Elemente verwendet. Es enthält die Menge aller expliziten Objekt-Typen, die inEPK erlaubt sind und auf die im Kapitel 2 genauer eingegangen worden ist. Weiterhin enthält diesesElement ein weiteres Element <directory>, welches im Zusammenhang mit den hierarchischenEPK-Diagrammen von groÿer Bedeutung ist. Es ist somit möglich, in einer EPML-Datei mehrereEPK-Modelle abzulegen.

Jeder Prozess, welcher durch das Element <epc> beschrieben wird, trägt ein Attribut namens@epcId. Dadurch können einzelne EPK, hierarchische Funktionen und Prozess-Schnittstellen schnellidenti�ziert werden. Dieses Element darf in einer EPML-Datei beliebig oft vorkommen, um die einzel-nen EPK beschreiben zu können. In der Abbildung 3.2 ist die Struktur des Syntaxbaumes zu sehen, diesich in allen EPK-Elementen, den expliziten Objekt-Typen, wiederholt. Für die Transformation nachBPEL eignen sich aus dieser Baumstruktur nur wenige Attribute eines bestimmten EPK-Elements.Dies sind unter anderem nur das Element <name> und das Attribut id, welches in der Abbildungunter attributes abgelegt ist.

Alle Kindelemente von <epc>, wie <event>, <function>, <and>, <or>, <xor> und weitere,die in dem oben darstellten Listing 3.1 abgebildet und vom Typ <typeEPCElement> sind, habenimmer die gleiche Struktur des Syntaxbaumes. Ihre Bedeutung kann man aus ihrem Namen ableiten,deshalb werden diese nicht näher erläutert.


Abbildung 3.2: Struktur von typeEpcElement

In der EPK-Notation wird zwischen den expliziten und den impliziten Objekttypen der EPK-Elemente unterschieden. Die expliziten Typen stellen die einzelnen Elemente der EPK-Notation darund die impliziten Typen werden durch die Kombination der Hauptelemente beschrieben. Die ex-pliziten Typen sind durch die Struktur der EPML-Datei gegeben, wobei die impliziten Typen erstdurch Algorithmen bestimmt werden können. Aus expliziten Elementen wird der Kontroll�uss einesGeschäftsprozesses zusammengesetzt, die über das <epc>-Kindelement <arc> verbunden werden.Es wird notwendig sein, die in einem EPK-Geschäftsprozess möglichen Work�ow Patterns9 zu un-tersuchen. Eine ausführlichere Beschreibung zu den Work�ow Patterns wird in Kapitel 5 gegeben.Weiterhin ist es erforderlich, dass Annotationen zu diesen Elementen hinzugefügt werden, um eineTransformation nach BPEL zu ermöglichen.

Das nächste Listing 3.2 zeigt die Struktur eines EPK-Elementes <function>, die transformiertwerden muss, nachdem die nicht relevanten Elemente in dem Austauschformat berücksichtigt wordensind.

Listing 3.2: Abzubildende Elemente für das Element <function> als Syntaxbaum1 epml2 ...3 directory (name)4 directory* (name) ...5 epc* (epcId, name)6 ...7 function* (id, defRef)8 name9 ...

10 toProcess? (linkToEpcId)11 attribute* (typeRef, value)12 ...

Wie man erkennt, bleiben nur sehr wenige Elemente und Attribute übrig, die erlauben, Elementein BPEL zu erzeugen. Wenn gewünscht ist, dass eine verlustlose Transformation nach BPEL möglichsein soll, so reicht die vorhandene Struktur nicht aus, um eine teil-automatische Transformationnach BPEL durchführen zu können. Deshalb ist es zwingend erforderlich, dass Zusatzinformationeneingefügt werden, die die notwendigen Attribute in BPEL ausfüllen können. In Abschnitt 3.4 wirderläutert, wie das EPML-Schema erweitert werden kann.

9Vgl. [MNN05] Hier werden Work�ow Patterns in EPK für die Kontroll�uss-Semantik identi�ziert.


3.3 Erweiterte EPK-Notation um Web Services

Im folgenden Abschnitt wird auf die durchgeführten Erweiterungen, die im Rahmen einer Masterarbeit[Int06] von Intas am Institut der praktischen Informatik an der Leibniz Universität Hannover imSommer 2006 entstanden sind, näher eingegangen. Die Aufgabe bestand darin, ein Konzept fürdie Einbindung von Web Services in Ereignisgesteuerte Prozessketten zu entwerfen. Intas stellt beiseiner Ausarbeitung fest, dass sich das Durchführen eines automatischen Mappings von EPML nachBPEL als �äuÿerst komplex� erweist und somit das Einbinden der Web Services in EPK über BPELvermieden werden soll. Weiterhin weist der Autor darauf hin, dass in diesem Zusammenhang dasAustauschformat EPML erweitert werden muss, um erst eine Transformation durchführen zu können.Es folgt ein Zitat aus [Int06]:

�Da die Information für Webservice-Aufrufe dann folglich schon in einem EPML-Dokumententhalten sind, kann dieses auch von einer dafür quali�zierten EPK-Engine ausgeführt werden,ohne einen Umweg über WS-BPEL zu gehen. Somit kann ein Konvertierungsvorgang vermiedenwerden.�

Die Aufgabe dieser Arbeit ist die Überprüfung der Erweiterungen von EPK umWeb Services (EPK-WS) und anschlieÿend die Durchführung der Transformation nach BPEL. Da für die Erweiterung dereinfachen EPK durch Web Services das EPML-Schema zu EPK-WS erweitert werden musste, mussdieses EPML-Schema ebenfalls untersucht werden, ob die durchgeführten Arbeiten für die benötigteTransformation genügend Informationen liefern.

Der Argumentation von Intas kann hier nicht entsprochen werden. Der Autor weist ausdrücklichdaraufhin, dass Erweiterungen für die Transformation nach BPEL erforderlich sind, jedoch führt derAutor selbst viele Erweiterungen in das EPML-Schema ein, um eine eigene EPK-Engine zu entwi-ckeln. Sich nur darauf zu beziehen, dass die erforderlichen Informationen für Web Service-Aufrufedann folglich im EPML-Format enthalten sind, stellen noch keinen wichtigen Grund dar, um eineweitere Beschreibungssprache für Work�ows zu entwickeln. Um den Umweg über die vorgeschlageneEPK-Engine nicht zu gehen, wird deshalb an dieser Stelle eine Konvertierung nach BPEL vorge-schlagen. Das genauere Überprüfen der Erweiterungen führt zu dem Entschluss, dass diese für dieTransformation nach BPEL nicht geeignet sind. Es können zwar wenige Ideen übernommen werden,im Ganzen wird jedoch das betrachtete EPML-Schema nicht wie vorgegeben verwendet und deshalbnicht mehr weiter erläutert.

Die Begründung zu solchem Entschluss lässt sich aus den folgenden Punkten ableiten:

(1) - Die Erweiterungen des EPML-Schemas wurden nicht im Hinblick auf die Transformati-on auf BPEL entworfen, da der Autor sich ausdrücklich von BPEL distanziert hat. Des Weiterensind keine weiteren ausführbaren EPK-Engines bekannt, die die Web Service-Funktionalität unter-stützen können. Das Schema wurde entworfen, um eine eigene EPK-Engine zu entwickeln, die dieOrchestrierung von Web Services erlauben sollte. Das heiÿt, es wurde versucht das Rad neu zu er-�nden10, obwohl die BPEL-Engine alle geforderten Aufgaben erledigen kann. Weiterhin haben ander Entwicklung von BPEL namhafte Firmen wie Microsoft, IBM und BEA mitgewirkt, die schonviel Erfahrung in diesem Bereich gesammelt haben. Auÿerdem müsste die gleiche vollständige Funk-tionalität der BPEL-Engine, die in den letzten Jahren erprobt wurde, in die neue EPK-Engine vonIntas eingefügt werden. Beim Entwurf der EPK-Engine wurden sogar Ideen aus WS-Transaction undWS-Coordination übernommen. Wenn man die Entwicklung von BPEL anschaut, dann hat dieseAusführungssprache mehrere Jahre benötigt, um in der Praxis überhaupt akzeptiert zu werden. Die-sen Prozess müsste dann die EPK-Engine ebenfalls durchlaufen. Weiterhin können Entwickler auf

10Vgl. [Aal03] �the world is confronted with too many standards which are mainly driven by concrete products ... . Theonly way to stop this is to ignore standardization proposals that are not using well-estabilished process modelingtechniques. This will force vendors to address the real problems rather than creating new ones.�


über 20 verschiedene BPEL-Engines zurückgreifen, die BPEL 1.1 vollständig unterstützen. Die For-derung nach einer EPK-Engine würde das Problem der Interoperabilität nicht beheben. Denn für dieAkzeptanz einer integrierten BPM-Lösung ist die Nutzung bereits bestehender Standards von groÿerBedeutung. Und die Behauptung, dass die Transformation von EPK nach BPEL zu komplex sei,wurde nicht belegt.

Die gewählte technische Implementierung hat laut [IS05] immer einen �starken Ein�uss auf dieVerbindung von Prozess- und Service-Modellierung �. Daraus kann man schlieÿen, dass das gewählteZielmodell auch die Struktur der Annotationen im Ausgangsmodell vorgibt. Da BPEL bewusst um-gangen wurde, obwohl BPEL sich in den letzten Jahren in der Praxis zum Defacto Standard bei derOrchestrierung von Web Services etabliert hat, eignet sich das annotierte Format von Intas nicht fürdie Umwandlung von EPK nach BPEL.

(2) - Es wird nicht zwischen den verschiedenen Ebenen wie der Geschäftsprozessebene und derAusführungsebene unterschieden. Es wird die Geschäftsprozessebene mit der Ausführungsebene ver-mischt, da die WS-Transaktionen nicht nur auf der Geschäftsprozessebene anzusiedeln sind. DesWeiteren müssten hierfür transaktionsspezi�sche De�nitionen in WSDL-Beschreibungen der ange-bundenen Web Services vorhanden sein, was aber bei der vorliegenden Arbeit nicht der Fall war.Die WS-Transaktionen zählen im Web Services-Stack zu Quality of Services. Häu�g werden diese imStack zwischen der BPEL- und der WSDL-Ebene eingefügt. Diese Darstellung entspricht eher nichtdem eigentlichen Sinn der Quality of Service. Die eigentliche Funktion der Quality of Services reichtüber alle Ebenen des SOA-Stacks. Deshalb wird eine andere Darstellung des Web Service-Stacks,der eine Spezialisierung des SOA-Stacks darstellt, bevorzugt, die im Anhang in der Abbildung C.3 zusehen ist. Diese Darstellung der Quality of Services deckt den Web Service-Stack von SOAP bis BPELvollständig ab. Dies würde zur Folge haben, dass aus EPK-Elementen noch WSDL-Beschreibungenerzeugt werden müssen. Da in dieser Arbeit nur BPEL-Kompositionen generiert werden und WSDL-Beschreibungen für Web Services vorgegeben werden, werden die Transaktionen hier weiter nichtmehr betrachtet. Das Thema der Transaktionen ist so komplex, dass der Umfang eigene Master-arbeiten füllen kann. In diesem Zusammenhang wird auf [Mie06] verwiesen, wo die Transaktionenausführlich behandelt werden.

Aufgrund der oben dargestellten Gründe ist das im Kapitel 5 vorgestellte Konzept der Trans-formation von annotierten Geschäftsprozessen nach BPEL dem vorgeschlagenen Konzept von Intasvorzuziehen. Es ist daran zwar nicht auszusetzen, dass EPML erweitert werden muss, aber nach einerquali�zierten EPK-Engine zu fordern, ist nicht notwendig, wenn EPML ein intermediäres Austausch-format darstellt. Die möglichen Erweiterungen der EPML-Struktur würden die Transformation sogarerheblich erleichtern und einen gewissen Vorteil verscha�en, wenn sich die einzelnen Elemente besserabbilden lassen. Zwar wird die Erweiterung der EPML-Struktur, wie von Intas richtig festgestellt, Red-undanzen11 mit sich bringen. Da aber diese Redundanzen im Austauschformat de�niert sind, welchesnur für die Konvertierung des proprietären Modells benutzt wird, kann man diese verkraften.

Schaut man sich andere gra�sche Formate, wie z.B. .vbpel an, welches von ActiveBPEL12 fürdie Darstellung der BPEL-Prozesse verwendet wird, so enthält dieses Format ebenfalls die gleichenInformationen wie ein BPEL-Prozess. Der Unterschied liegt nur darin, dass .vbpel Zusatzinformatio-nen für die Positionierung und die gra�sche Notation enthält. Weiterhin sind diese Eigenschaften imVergleich zu einer BPEL-Datei anders strukturiert und in Form von Attributen, die einen bestimmtenNamen name und den Wert value enthalten, angeordnet. Die Entwickler von ActiveBPEL haben sichfür diese Redundanzen entschieden, da das .vbpel-Format die Obermenge von .bpel-Format darstellt.Der Grund hierfür ist, dass aus .vbpel-Format in ActiveBPEL Designer eine .bpel-Datei generiertwerden kann. Wenn ein .vbpel-Dokument die notwendigen Informationen für BPEL enthält, so kannmittels einer einfachen Transformation die Codeerzeugung durchgeführt werden.

11Widerspruch zum Software-Engineering-Prinzip, wohingegen gefordert wird, dass man Redundanzen vermeiden soll.12ActiveBPEL ist ein gra�sches Modellierungswerkzeug für BPEL inkl. einer BPEL-Engine auf der Eclipse-RPM-Basis


Deshalb wurde im Folgenden entschieden, für die Transformation von annotierten Geschäftspro-zessen nach BPEL nicht das erweiterte EPML-Schema von Intas zu benutzen. Es bleibt nur nochdie Frage o�en, wie die Zusatzinformationen in einem EPK-Diagramm zur Verfügung gestellt werdenkönnen.

Bevor im nächsten Abschnitt beschrieben wird, wie die Annotationen hinzugefügt werden kön-nen, wird noch eine weitere Argumentation eingeführt, um zu verdeutlichen, warum die Entwicklungeiner eigenen EPK-Engine vermieden werden sollte. Es ist einfacher, nach einer neuen gra�schenNotation zu fordern, die BPEL unterstützt als nach einer neuen ausführbaren Umgebung, wie derEPK-Engine, die das vorgegebene EPK-Schema unterstützen soll. Denn alle bekannten Ausführungs-sprachen sind viel komplexer als deren gra�sche Notation. Man muss sich vielleicht fragen, ob mandie EPK nicht durch eine neuere gra�sche Beschreibungssprache wie BPMN ersetzt und EPK nachknapp 15 Jahren seit der Einführung als proprietäre Modellierungssprache betrachtet. Viele weitereGründe sprechen auch dafür, da diese Sprache zuletzt durch viele Erweiterungen auf sich aufmerksamgemacht hat. BPMN wird zur Darstellung13 von technischen Prozessen in BPEL verwendet, obwohlBPEL keine eigene gra�sche Notation laut Spezi�kation besitzt. Die Sprache BPMN ist relativ neu,soll aber in sich alle Sprachen der gra�schen Geschäftsprozessmodellierung vereinheitlichen und dasProblem der Interoperabilität lösen, wie es UML vor einigen Jahren gescha�t hat. Die Notation sollfolgende Standards wie UML AD, EPK, Activity-Decision-Flow und andere in sich vereinen. DasZiel ist, das Auseinanderdriften von Business-orientierten Notation und IT-orientierten Ausführun-gen wiederzusammenzuführen. Obwohl ARIS Process Plattform laut Gartner Inc. zu den führendenHerstellern der Werkzeuge für die Modellierung betriebswirtschaftlicher Geschäftsprozessmodelle aufBasis von Ereignisgesteuerten Prozessketten gilt, wurde die BPMN-Notation mit der Funktion desBPMN-Imports und Exports in den ARIS SOA Designer [IS] aufgenommen. So kann man davonausgehen, dass in der Zukunft die EPK-Notation eher eine untergeordnete Rolle spielen wird unddurch eine neue gra�sche Modellierungssprache ersetzt wird, die SOA-Funktionalität anbietet. Dieshängt einerseits damit zusammen, dass namhafte Firmen BPMN zum neuen Standard in der Ge-schäftsprozessmodellierung erklären wollen. Zwar wird der Standard BPMN einige Zeit benötigen,um in der Praxis eine hohe Akzeptanz zu �nden, ist aber schon heute für viele Kunden sehr wichtig,dass BPMN von den Modellierungstools unterstützt [IS] wird.

3.4 Erweiterbarkeit des EPML-Schemas

Aufgrund der im letzten Abschnitt gesammelten Ergebnisse muss zunächst betrachtet werden, wiedas vorliegende EPML-Schema erweitert werden kann. In Abschnitt 3.2.2 bei der Untersuchung desEPML-Formates wurde darauf hingewiesen, dass das EPML-Schema schon selbst einige Möglichkeitenmit sich bringt, um Annotationen hinzufügen zu können. Trotzdem wird in diesem Abschnitt gezeigt,wie ein XML-Schema erweitert werden kann, falls noch andere Erweiterungen benötigt werden.

In diesem Zusammenhang wird in [SLH] beschrieben, wie die Anreicherung von XML-Schemasallgemein erfolgen kann. Bevor die Erweiterung durchgeführt werden kann, muss das Ausgangssche-ma schon so gestaltet worden sein, dass man dieses sich überhaupt erweitern lässt. In Abschnitt3.2.1 wurde im Zusammenhang mit den Anforderungen an ein XML-Schema angesprochen, dass dasEPML-Schema nach dem Grundsatz der Erweiterbarkeit entwickelt worden ist. Dieser Sachverhaltliefert ein erweiterbares Ausgangsschema, sodass die Erweiterung problemlos durchgeführt werdenkann.

Die Erweiterungen können auf vier unterschiedliche Arten vollzogen werden. Erstens können zu-sätzliche Informationen mittels des durch XML-Sprache zur Verfügung gestellten Sprachkonstruktes

13Vgl. [Whi05] Dieses Paper behandelt die Abbildung von BPMN nach BPEL


annotation durchgeführt werden. Zweitens kann man vorhandene Elemente um zusätzliche XML-Attribute des gleichen oder eines neuen Namensraumes erweitern. Drittens kann die Erweiterungdurch neue Elemente erfolgen, die ebenfalls in vorhandene Namespaces integriert oder durch neueNamespaces de�niert werden. Die vierte Möglichkeit stellt die EPML-Schema-spezi�sche Erweiterungdar, die mit Hilfe der <attributeTypes> und <attribute>-Elemente durchgeführt werden kann.Nachfolgend werden die Vor- und Nachteile möglicher Erweiterungen unterschieden.

(1) Annotation: Dieses Feld wird explizit für Dokumentations- und Applikationsinformationeneingesetzt und eignet sich für die Erweiterung vorhandener XML-Schemas. Dieses wird aber immer nurim Zusammenhang mit der Spezi�kation von Toolbeschreibungen, d.h. für Dokumentationszwecke,verwendet.

(2) Attribute: Neue Attribute zu vorhandenen Elementen hinzuzufügen, ist die einfachste Formder Erweiterung. Zusätzliche Attribute verändern die Baumstruktur nicht und erscheinen nur alszusätzliche Knoten. Eine solche Erweiterung sollte nur dann durchgeführt werden, wenn die Eigen-schaften, die über Attribute ausgedrückt werden sollen, nicht weiter strukturiert werden sollen. Denndie anschlieÿenden Erweiterungen können nur mit einfachen Datentypen durchgeführt werden, weildiese sich nicht mehr erweitern lassen. Deshalb sollten bei der Erweiterung des XML-Schemas dieAttribute nur dann verwendet werden, wenn diese in der Zukunft nicht mehr erweitert werden sol-len.

(3) Elemente: Neu hinzugefügten Elemente verändern immer die Struktur eines XML-Dokuments.Der Vorteil bei dieser Methode ist, dass neu eingefügte Elemente sich beliebig weiter strukturierenlassen. Weiterhin können neue Elemente entweder vom Typ element oder complexType sein, sodass dadurch beliebige neue komplexe Strukturen entstehen können. Werden bei der Erweiterung desXML-Schemas neue Attribute oder Elemente durch neue Namespaces de�niert, so erleichtert diesesVorgehen die Lesbarkeit der erweiterten XML-Schema.

(4) <attributeType>: In Abschnitt 3.2.2 wurde darauf hingewiesen, dass über das Element<attributeType> in dem übergeordneten Element <attributeTypes> beliebige strukturelle Zu-satzinformationen hinzugefügt werden können. Gemäÿ dem EPML-Schema können <attribute>-Elemente in allen Elementen vom Typ <typeEpcElement> vorkommen und dürfen eine beliebigeAnzahl solcher De�nitionen enthalten. Hierfür wird nun in jedes zu annotierende EPML-Elementein <attribute>-Element hinzugefügt, das auf die allgemeine De�nition des <attributeType>-Elementes referenziert. Das folgende Listing zeigt eine solche Situation.

1 <epml>2 <attributeTypes>3 <attributeType typeId="X">4 </attributeTypes>5 ...6 <epc>7 <function id="positiveInteger">8 <attribute typeRef="X" value="Y"9 </function>

10 </epc>11 </epml>

Der Vorteil bei diesem Vorgehen ist, dass das EPML-Schema nicht zwangsweise durch Rede�niti-on erweitert werden muss, und dass man nicht nur auf die EPML-spezi�schen Attribute beschränktist. Diese Möglichkeit der Annotation stellt die einfachste Form der Erweiterung dar. Es können so-mit im Transformationsprozess beliebige implementierungsspezi�sche Informationen als Attribute zujedem EPK-Element hinzugefügt werden. Daher wurde entschieden, die Annotationen in Form des<attribute>-Elementes durchzuführen. Die Erweiterungen des untersuchten EPML-Formats vonIntas wurden mit Hilfe der Rede�nition des Original-Schemas durchgeführt, obwohl für die erforderli-chen Informationen diese auch durch das Element <attribute typeRef="..." value="..."/>

möglich gewesen wäre. Die Erweiterung durch Rede�nition hat eine unnötige Abhängigkeit zu dem


verwendeten Schema hergestellt. Wird das rede�nierte Schema geändert, so müssen die Erweiterun-gen in der Rede�nition ebenfalls angepasst werden. Dies ist eines der weiteren Gründe, warum aufdas annotierte EPML-Schema von Intas nicht zurückgegri�en wird.

Zuletzt muss also noch entschieden werden, welche Annotationsattribute einer EPML-Instanzhinzugefügt werden sollen. Eine ausführliche Beschreibung wird in Kapitel 5.4 nach der ausführlichenEinführung des BPEL-Schemas in Kapitel 4 gegeben.

3.5 Zusammenfassung

In diesem Kapitel wurde eingangs die Sprache XML und das XML-Schema eingeführt und kurz erläu-tert. Anschlieÿend wurden die Transformationsformen, die für die Transformation in Frage kommen,eingeführt. Die Forderung von Mendling und Nüttgens, eine formale De�nition der EPK mit Hilfe ei-ner XML-basierten Sprache EPML vorzunehmen, wurde weitgehend in [MN05] gelöst. Deshalb wurdeentschieden, für die Beschreibung der EPK-Diagramme das EPML-Schema zu verwenden. Daraufhinwurde das EPML-Schema vorgestellt und deren Elemente kurz erläutert. Es wurde gezeigt, welcherelevanten und irrelevanten Elemente das EPML-Schema für die benötigte Transformation enthält.Die relevanten Elemente spielen in weiteren Kapiteln eine besondere Rolle bei der Abbildung nachBPEL. Anschlieÿend wurden die Gründe aufgezeigt, warum das erweiterte EPML-Schema von Intasnicht für den Transformationsprozess verwendet werden kann. Zuletzt wurde darauf eingegangen, inwelcher Form die Annotationen benutzt werden können, um die Transformation erfolgreich durchfüh-ren zu können. Das EPML-Format bietet die Möglichkeit an, zu jedem EPK-Element eine beliebigeAnzahl anwendungsspezi�scher, in diesem Fall service-orientierter, Annotationen hinzuzufügen. Dieausgewählte Form der Annotation benötigt keine Rede�nition des EPML-Schemas. Dadurch kannman ebenfalls auf das frei verfügbare EPML-Schema zurückgreifen. Diese Form kann auch im Zu-sammenhang mit neueren Versionen des EPML-Schemas problemlos benutzt werden, solange dasWurzelelement vom Typ EpcElement nicht verändert wird.

Kapitel 4

WSDL- und BPEL-Grundlagen

Im diesem Kapitel wird die Dokumentstruktur von BPEL näher behandelt. Dieser Schritt ist zumVerständnis der Abbildung erforderlich, da BPEL das Zielformat der Transformation darstellt. Hierfürmüssen zunächst die BPEL-Elemente mit ihren notwendigen Attributen identi�ziert werden, um an-schlieÿend EPK-Elemente auf diese Elemente abbilden zu können. Die Web Service-Kompositionsspra-che BPEL setzt direkt auf WSDL auf, daher muss im nächsten Abschnitt zunächst die De�nitionvon WSDL eingeführt werden. Anschlieÿend wird auf die Dokumentstruktur von BPEL eingegangen.Aufgrund des groÿen Umfangs der in Verbindung mit Web Services benutzten Standards werdenweitere Standards, wie SOAP und UDDI als bekannt vorausgesetzt. Zu einer vollständigen Beschrei-bung der beiden Sprachen WSDL und BPEL wird auf deren Spezi�kationen [W3Cb] und [ACD+03]verwiesen.

4.1 WSDL-Syntax

Web Services De�nition Language (WSDL)1 ist eine funktionale, XML-basierte Beschreibungs-sprache für die Schnittstellen eines Web Services. Ein Web Service repräsentiert sich nach auÿenüber seine WSDL-Dokumentstruktur, die zunächst jedem Web Service vorgegeben werden muss. Ei-ne WSDL-Datei beschreibt nichts anderes als die abstrakten Eigenschaften eines Web Services. Siestellt die Grundlage für die spätere De�nition des Geschäftsprozesses dar, da diese die Informationensowohl zu Messagetypen als auch zu Schnittstellende�nitionen der beteiligten Prozesse enthält. Esbeschreibt eine Sicht auf ein Web Service und aller darin beteiligten Rollen. In den Ports werden alleaufrufbaren Operationen de�niert.

Die WSDL-Dokumentstruktur ist eine Menge von De�nitionen, die folgende Elemente beinhaltet.Das Wurzelelement eines WSDL-Dokumentes bildet das <definitions>-Element. Es enthält denNamen des Services, Namespaces für den Service und verwendete Standards. Jedes WSDL-Dokumentbesteht immer aus zwei folgenden Teilen, dem mehrfach verwendeten abstrakten und dem konkretenTeil. Im abstrakten Teil werden die <types>-, <message>- und <portType>-Elemente und in demkonkreten Teil die <binding>- und <service>-Elemente de�niert. Im konkreten Teil wird alsobeschrieben, wie und wo auf einen Web Service zugegri�en werden soll, und im abstrakten Teil,welche Typen und Nachrichten daran beteiligt sind.

Das nächst folgende Listing zeigt die Grundstruktur eines WSDL-Dokumentes. Die Web Serviceswerden hauptsächlich über folgende Elemente beschrieben.

4

1Obwohl WSDL 2.0 zu Beginn dieser Arbeit schon ö�entlich verfügbar war, baut sich diese Arbeit auf WSDL 1.1auf. Der Grund hierfür ist, dass der Nachfolger von BPEL 1.1 in der Version 2.0 zu Beginn dieser Arbeit sichnoch im Status des Public Review Draft befunden hat. Weiterhin weist die BPEL-Spezi�kation 2.0 (Public ReviewDraft, 23rd August, 2006) ausdrücklich darauf hin, dass BPEL noch keine vollständige Unterstützung für WSDL2.0 anbietet. Da BPEL 1.1 auf WSDL 1.1 aufsetzt, wird im Folgenden diese Version verwendet. Die vollständigeGrammatik zu der betrachteten WSDL-Dokumentstruktur kann im Anhang dieser Masterarbeit eingesehen werden.

31

KAPITEL 4. WSDL- UND BPEL-GRUNDLAGEN 32

1 <wsdl:definitions name="NMToken"? targetNamespace="uri"?>2 3 <wsdl:documentation/>?5 <wsdl:types>  </wsdl:types>?6 <wsdl:message>  </wsdl:message>*7 <wsdl:portType>  </wsdl:portType>*8

9 10 <wsdl:binding>  </wsdl:binding>*11 <wsdl:service>  </wsdl:wsdl:service>*12

13 <-- extensibility element -->*14 </wsdl:definitions>

Im Folgenden werden die Elemente eines WSDL-Dokumentes einzeln beschrieben und näher er-läutert. Die dazu entsprechende WSDL-Instanz kann im Anhang A nachgeschlagen werden.

<types> - Dieses Element kapselt die De�nition von Datentypen eines Web Services ein, die fürdie auszutauschenden Nachrichten benötigt werden. Zur De�nition der Datentypen greift WSDL aufdas XML-Schema zurück. Die De�nition der Typen wird in Verbindung mit Ein- und Ausgabedatenin EPK eine besondere Rolle spielen.

<message> - Dieses Element de�niert Nachrichten, die zwischen den Partnern verschickt wer-den. Die Parameter werden durch das Kind-Element <part> beschrieben. Jede Nachricht kann auseinem oder mehreren <part>-Elementen bestehen. Das Element <part> ist vergleichbar mit demParameter eines Funktionsaufrufs und wird durch den Namen und seinen Datentypen eindeutig fest-gelegt. Das <message>-Element legt somit eindeutig fest, welche Eingaben ein Web Service benötigtund welche Ausgaben dieser erzeugt.

<portTypes> - ist eines der wichtigsten Elemente in einem WSDL-Dokument. Ein BPEL-Prozesskommuniziert mit anderen Web Services über dieses Element. Es beschreibt ein Web Service mitseinen Operationen, die an einem Port ausgeführt werden. Dieses darf eine beliebige Anzahl diean diesem Port unterstützenden Operationen de�nieren. Es bündelt alle Operationen mit seinenbeteiligten Nachrichten und stellt somit die abstrakte Schnittstelle eines Web Services dar. Es könnenentweder eingehende oder ausgehende Operationen verwendet werden.

<operation> - Dieses Element wird in <portTypes> und in <binding> verwendet und kapseltin sich die Funktionalität eines Web Services. Eine Operation kann folgende Eigenschaften haben. DieNamen, die in der Spezi�kation verwendet werden, lauten<wsdl:one-way-operation>,<wsdl:request-response-operation>, <wsdl:solicit-response-operation> oder auch<wsdl:noti�cation-operation>. Die beiden Typen <wsdl:one-way-operation> und <wsdl:request-response-operation> werden als inbound operations de�niert, weil diese von Web Services angebo-ten werden, in dem diese von den eingehenden Nachrichten getriggert werden. Die letzten beidenOperationenarten werden outbound operations genannt.

<binding> - ist die De�nition des Kommunikationsprotokolls für jeden Port und des Nachrich-tenformats. Die abstrakte <portType>-Schnittstelle wird über das Binding-Element an konkreteProtokolle angebunden.

<port> - Ein konkreter Web-Service-Endpunkt wird über das <port>-Element eindeutig identi-�ziert.

<service> - Dieses Element enthält alle <port>-Elemente und beschreibt somit die Menge derPorts zu jedem einzelnen Service. Es fasst alle Endpunkte eines Web Services zusammen.

<ExtensibilityElements> - werden im Zusammenhang mit BPEL-Prozessen verwendet. Es wer-den hier BPEL-Elemente wie <partnerLinkTypes> de�niert. Die <partnerLinkTypes> werdenüber ihre <role> und ihre <portTypes> identi�ziert. Das heiÿt, dass die Charakterisierung über<partnerLinkType> erfolgt, indem jedem Web Service eine bestimmte Rolle zugeordnet wird. Eine

Rolle repräsentiert eine Ressource und kapselt eine Berechtigung in sich ein. Die bereitgestellten Portsvon beiden Partnern legen eindeutig die Endpunkte für die benutzten <partnerLinks> fest. Diesesind für Basis-Aktivitäten relevant, die Web-Service-Requests auslösen können und charakterisiertdamit zugleich eine Beziehung zwischen zwei oder mehreren Web Services.

4.2 BPEL-Syntax

Die Sprache BPEL setzt direkt auf WSDL-De�nition auf und stellt in ihrer derzeitigen De�nitionein Modell und eine reiche Grammatik zur Verfügung, um das Verhalten und den Ablauf eines Ge-schäftsprozesses [ACD+03], dessen Aktivitäten durch Web Services realisiert werden, zu beschreiben.Ein BPEL-Geschäftsprozess repräsentiert sich nach auÿen durch seine WSDL-Schnittstelle und seineStruktur wird durch ein XML-Schema beschrieben. Die nächst folgende Abbildung 4.1 beschreibt dieAbhängigkeiten zwischen der WSDL- und der BPEL-Spezi�kation, wobei die fettgedruckten Nameneinem XML-Element und die anderen dem XML-Attribut entsprechen.

Abbildung 4.1: Abhängigkeiten zwischen WSDL und BPEL

Im folgenden Listing ist der Grundaufbau eines BPEL-Prozesses <process> zu sehen. Aus Grün-den der Übersichtlichkeit wurden hier nur die wichtigsten Elemente angegeben. Des Weiteren wurdeauf die De�nition der Namensräume verzichtet.

1 <process name="ProcessName">2 <partnerLinks>...</partnerLinks>3 <partners>...</partners>4 <variables>...</variables>5 <correlationSets>...</correlationSets>6 <faultHandlers>...</faultHandlers>7 <compensationHandlers>...</compensationHandlers>8 <eventHandlers>...</eventHandlers>9 

10 <activity/>11 </process>

Die Wurzel eines BPEL-Dokuments bildet das Element <process>, welches die Struktur und denKontroll�uss eines Geschäftsprozesses in sich kapselt. Die Struktur wird über folgende Hauptelementewie PartnerLinks, Partners und Variables beschrieben. Diese De�nitionen stellen die passivenElemente eines Geschäftsprozesses dar. Die aktiven Elemente <activity> stellen die elementarenund die strukturierten Aktivitäten dar. So wird der Kontroll�uss mittels der Kontrollstrukturen überdie strukturierten Aktivitäten eindeutig beschrieben. Die BPEL-Instanzen werden eine wesentlicheRolle bei der Erzeugung des BPEL-Prozesses spielen. Denn es ist erforderlich, dass die EPK-Elementebei der Codeerzeugung wirklich alle notwendigen Elemente und Attribute erzeugen, die für die Laufzeiteines BPEL-Prozesses benötigt werden. Dies sind hauptsächlich Elemente in dem BPEL-Schema, die


mit required gekennzeichnet sind. Ebenso können Fehlerbehandlungen verwendet werden, um dieAusführung des Web Services auch im Fehlerfall zu gewährleisten.

Nachfolgend wird der strukturelle Aufbau des BPEL-Dokumentes näher beleuchtet und eine aus-führlichere Beschreibung zu den einzelnen Elementen gegeben, die zum Verständnis der Abbildungausreichen sollte.

� <partnerLinks> - De�nition der Kommunikationspartner

� <partners> - Zusammenfassung mehrerer partnerLinks zu einem Partner

� <variables> - De�nition von Variablen zur Repräsentation eines bestimmten Zustandes

� <correlationSets> - Speicherung der Daten, die einen bestimmten Zustand beschreiben

� <faultHandlers> - Fehlerbehandlung im Fehlerfall

� <compensationHandler> - Fehler-Recovery, Aktionen rückgängig machen

� <eventHandlers> - Ereignisbehandlung beim Auftreten eines Ereignisses

� <activity> - Das Schlüsselwort activity stellt symbolisch die erlaubte Menge einzelnerAktivitäten in einem Geschäftsprozess dar. Es wird nachfolgend im Zusammenhang mit ele-mentaren und strukturierten Aktivitäten verwendet. Es beschreibt, was ein Prozess macht.Für die Transformation spielt das Element <activity/> eine besondere Rolle. Hier werdenelementare Aktivitäten, die in dem EPK-Diagramm der Funktion entsprechen sollen, und struk-turierte Aktivitäten, die aus dem Kontroll�uss eines EPK-Diagramms abgeleitet werden sollen,de�niert.

Im Folgenden werden die wichtigsten Elemente des BPEL-Schemas näher untersucht. Die dazuentsprechenden Listings, die die De�nition von BPEL-Instanzen näher beschreiben, können in AnhangB nachgelesen werden. Zur vollständigen De�nition der BPEL-Elemente wird auf die Spezi�kation[ACD+03] verwiesen.

PartnerLink - identi�ziert einen Partner-Web Service, der mit dem betrachteten Business-ProzessNachrichten austauscht. Über die Rollen myRole und partnerRole wird der Nachrichtenaustauschspezi�ziert. Es ist ein bilateraler Nachrichtenaustausch zwischen den betrachteten Partnern, wennbeide Attribute myRole und partnerRole de�niert sind. Wird dagegen nur eine Rolle de�niert, sohandelt es sich dabei um eine asynchrone Nachricht. Die partnerLinks spielen mit den elementarenAktivitäten Receive, Reply und Invoke eine bedeutende Rolle, die Web Services auslösen können.

Partner - In dem Element <partners> werden die einzelnen Partner mit ihren dazu gehörigen<partnerLinks> gekapselt. In diesem Fall bedeutet es, dass einzelne oder mehrere Web Services,die über die <partnerLinks> verbunden werden, hier zusammengefasst werden können.

Variables - Wenn Web Services ausgeführt und zwischen diesen Nachrichten oder Daten aus-getauscht werden, dann müssen diese in Variablen gehalten werden. Eine Variable in einem BPEL-Prozess ist an ihrem Namen und dem verwendeten Datentyp aus dem XML-Schema eindeutig iden-ti�zierbar.

4.3 Elementare Aktivitäten

Die Schlüsselrolle von BPEL stellt die Aktivität dar. Ein BPEL-Prozess ist genau eine Aktivität, diebeliebig viele weitere Aktivitäten enthalten darf. So wird das interne Verhalten eines Geschäftsprozes-ses auf zwei verschiedene Arten von Aktivitäten de�niert. Dazu zählen elementare (basic activities)und strukturierte Aktivitäten (structured activities). Die elementaren Aktivitäten dürfen keine wei-teren Aktivitäten beinhalten und sind somit atomar. Sie stellen Operationen, die in einem Prozess


ausgeführt werden können, dar. Diese werden entweder für den Aufruf von Diensten oder für dieManipulation der Daten benutzt. Die strukturierten Aktivitäten können wiederum aus weiteren ele-mentaren Aktivitäten oder strukturierten Aktivitäten bestehen. Diese werden zum Beschreiben desKontroll�usses benötigt. Sie beschreiben den eigentlichen Ablauf eines Prozesses.

Zu den elementaren Aktivitäten gehören folgende Aktivitäten:

� <invoke> - Abfragen eines Partners mittels einer request/response- (synchroner Aufruf) odereiner request-Operation (asynchroner Aufruf); im synchronen Fall entspricht einer Vereinbarung

� <receive> - Erhalten einer Nachricht vom Partner

� <reply> - Senden einer Antwort an den aufgerufenen Partner

� <empty> - Nichts machen, dient zur Synchronisation von nebenläu�gen Aktivitäten

� <assign> - Manipulation von Variablenwerten

� <wait> - Abwarten einer bestimmten Zeit

� <throw>- Signalisieren eines Fehlers und Behandlung des Fehlers

� <terminate> - Beenden einer Prozessinstanz

Alle Aktivitäten in BPEL enthalten drei optionale Attribute name, joinCondition und suppress-JoinFailure. Die beiden letzten Attribute werden im Zusammenhang mit der Synchronisation vonkonkurrierenden Pfaden benutzt. Des Weiteren besitzt jede Aktivität zwei optionale Elemente <sour-ce> und <target>, die im Zusammenhang mit den Links verwendet werden, die in Abschnitt 4.4behandelt werden.

In BPEL werden folgende Web Service-Aktivitäten: Receive, Reply und Invoke unterschieden. Die-se Elemente repräsentieren Anfragen (requests), Antworten (responses) und Vereinbarungen (agree-ments) zwischen den einzelnen Prozessen und ihren Partner-Services. Diese drei Aktivitäten werdenzu einer Menge von Aktivitäten zusammengefasst, die Web Services über einen Port ansprechenkönnen. Alle anderen BPEL-Aktivitäten können keinen Web Service ansprechen und werden zumBeschreiben der Funktionsweise des Prozesses verwendet. Bei der Abbildung von EPK nach BPELwerden diese drei Aktivitäten am häu�gsten erzeugt. Wie die einzelnen EPK- auf BPEL-Elementeabgebildet werden, wird in Abschnitt 5.4.2 ausführlich behandelt.

Invoke - Mit <invoke> wird ein Geschäftsprozess des Partners aktiviert, indem eine Nachrichtzum Partner-Web Service gesendet wird. Ein Invoke kann eine Operation in nur eine (request) oderbidirektionale Richtung (request-response) auf dem <portType> eines Partners auslösen. Bei einerrequest-Operation handelt es sich um einen asynchronen und bei der request/response-Operationum einen synchronen Aufruf. Die entsprechende Operation wird in der WSDL-Datei des Partnersde�niert. Beim asynchronen Auslösen des Prozesses wird nur die inputVariable benutzt. Beimsynchronen Auslösen wird zusätzlich die outputVariable verwendet.

Receive - veranlasst den Prozess zu warten, bis eine passende Nachricht vom Partner-Serviceankommt. In einem solchen Fall kann der Prozess nicht fortfahren oder sich beenden, bis die Nachrichteintri�t. <receive> führt beim <partnerLink> an einem <portType> eine <operation> ausund bindet die erwartete Nachricht an die entsprechende <variable>.

Reply - veranlasst den Prozess, eine Beantwortung auf die Partner-Nachricht zu senden. DerProzess sendet an dem entsprechenden <partnerLink> über den dazu gehörigen <portType> einebestimmte <operation>. In dem Fall, dass der Partner nicht empfangen kann, wird ein <fault-

Name> zur Fehlerbehandlung de�niert.

Empty - Das <empty>-Element führt keine Aktivität durch. Diese Aktivität kann aufgrund ihrerEigenschaft in beliebigen Kontexten verwendet werden. Diese kann sowohl bei der Abbildung vonEPK nach BPEL für die Join- und Split-Konnektoren als auch für Validierungszwecke verwendet


werden. Weiterhin können die <empty>-Aktivitäten als Platzhalter für andere Aktivitäten benutztwerden, die später vom Entwickler durch andere ersetzt werden können.

Assign - Beim Nachrichtenaustausch ist es erforderlich, dass zwischen den verschiedenen Akti-vitäten Manipulationen an Variablen vorgenommen werden. Eine solche Manipulation der Variablenin BPEL erfolgt über die <assign>-Aktivität. Diese kopiert Daten von der Quelle (from) zum Ziel(to). Eine Ausführliche Behandlung dieser Aktivität wird in Abschnitt 4.5 und 5.4.2 gegeben.

4.4 Strukturierte Aktivitäten

Eine strukturierte Aktivität de�niert eine kausale Ordnung auf elementaren Aktivitäten und legt denAblauf eines Work�ows eindeutig fest. Diese können beliebig verschachtelt und miteinander kombi-niert werden. Die Ablaufsteuerung spielt eine wichtige Rolle bei der Beschreibung des Kontroll�usseseines betrachteten Geschäftsprozesses. Im Kapitel 5 werden die möglichen Kontrollmuster im Zusam-menhang mit den Work�ow Patterns untersucht.

Die Ordnung kann über folgende strukturierte Aktivitäten festgelegt werden:

� <sequence> - Eine sequentielle Ausführung von Aktivitäten; alle elementaren Aktivitäten,die in dem <sequence>-Element enthalten sind, werden sequentiell ausgeführt.

� <while> - Eine while-Schleife; iterative Ausführung von Aktivitäten, bis die Bedingung erfülltist. Es ist die einzige Möglichkeit, Schleifen in BPEL 1.1 darzustellen.

� <switch> - Auswahl eines Kontrollpfades; die Auswahl erfolgt dabei über die angegebenenBedingungen.

� <pick> - Ausführen einer Aktivität, die von einem Ereignis abhängig ist. Das <pick>-Elementführt eine Aktivität abhängig von einen Ereignis oder einer bestimmten Zeit aus. Es wird solangegewartet, bis eine Nachricht oder ein Alarm eintri�t, und anschlieÿend werden die enthaltendenAktivitäten ausgeführt.

� <scope> - erlaubt die De�nition eines Programmblocks mit eigenen Variablen. Mit Hilfe des<scope>-Elements können einzelne Aktivitäten zusammengefügt werden. Die zusammenge-fügten Aktivitäten werden dann als eine transaktionelle Einheit betrachtet.

� <�ow> - Eine serielle, parallele, synchronisierende oder beliebige Abfolge von Aktivitäten

� <link> - De�nition einer Verbindung zwischen Source- und Target-Aktivität; diese werden inVerbindung mit dem <flow>-Element benutzt

Die letzten beiden BPEL-Elemente <flow> und <link> werden an dieser Stelle ausführlicherbehandelt, da diese das graph-ähnliche Verhalten des Kontroll�usses beschreiben können.

Flow - Die strukturierte <flow>-Aktivität wird für die parallele Au�ührung elementarer Aktivitä-ten benutzt. Des Weiteren kann dieses Element auch für die Synchronisation verschiedener Zweige ineinem BPEL-Prozess verwendet werden. Wichtig dabei ist, dass alle die zu konkurrierenden und zusynchronisierenden Aktivitäten in einem <flow>-Element de�niert werden. Die Reihenfolge der Aus-führung der enthaltenen elementaren und der strukturierten Aktivitäten wird durch Links eindeutigfestgelegt.

Link - Die oben vorgestellten Kontrollstrukturen erlauben, viele typische Arbeitsabläufe zu mo-dellieren. Es ist jedoch nicht möglich, noch weitere Sequenzen zu de�nieren, wenn die Aktivitä-ten innerhalb dieser Sequenzen einer bestimmten Reihenfolge unterliegen. Die verwendete XML-Datenstruktur, die nur hierarchische Modellierung erlaubt, bringt das auf XML-basierte Konzept


schnell an seine Grenzen. Um dieses Problem zu umgehen, wurden hierfür die Links in dem <flow>-Block eingeführt. Die Links erlauben bei der Modellierung Verknüpfungen zwischen einzelnen Ak-tivitäten herzustellen. Somit stellt ein <flow>-Element mit den dazugehörigen <links> graphen-theoretisch nichts anderes als eine Kante zwischen zwei Aktivitäten dar. Die Abbildung 4.2 zeigt dierichtige Verwendung von Links.

Abbildung 4.2: Erläuterungen zur Verwendung von �ow und link

Jeder Link wird über seinen Namen in der <links>-De�nition eindeutig identi�ziert. Um dieLinks benutzen zu können, müssen hierfür in jeder Aktivität, die mit den Links verbunden werdensoll, zwei weitere optionale Elemente <source> und <target> de�niert werden. Der Kontroll�ussverläuft von der Aktivität mit dem <source>-Element zu der Aktivität mit dem <target>-Element.Anhand der De�nition der linkNames wird die auszuführende Reihenfolge identi�ziert. Somit könnendie Aktivitäten beliebig viele <source>- oder <target>-Einträge2 enthalten, wobei man beachtensollte, dass die De�nitionen eindeutig sind und nicht doppelt vorkommen dürfen.

Beim Synchronisieren der Links an der Target-Aktivität muss das Attribut joinCondition, welchesals optionale Attribut in allen Aktivitäten belegt werden kann, gesetzt werden. Wenn das AttributjoinCondition nicht gesetzt ist, so ist der Default-Wert vom Linkstatus aller eingehender Links derbetrachteten Aktivität eine logische Disjunktion (logical or). Der Status des Links kann mit get-LinkStatus('linkName') abgefragt werden. Für die richtige Verwendung der Links sorgt die in BPELeingeführte Dead-Path-Elemination (DPE). Auf die ausführlichere De�nition der Link-Semantik undder DPE wird in diesem Zusammenhang auf die BPEL-Spezi�kation [ACD+03] verwiesen.

Die Links ermöglichen, die hierarchische Struktur der XML-Struktur zu sprengen und erlaubensomit zwei Aktivitäten auszuführen, die sich in unterschiedlichen Verschachtelungsebenen der XML-Datenstruktur be�nden. Dieser Zusammenhang ist in der nächsten Abbildung zu erkennen. Ein solcherFall wäre mit anderen strukturierten Aktivitäten ohne die Links in BPEL nicht modellierbar.

2Im Vergleich dazu kann in EPK an der Funktion nur eine einzelne eingehende und eine ausgehende Kante de�niertwerden.


Listing 4.1: BPEL-Quellcode1 <flow>2 <links>3 <link name="Seq-X-to-Seq-Y"/>4 <link name="C-to-E"/>5 </links>6

7 <sequence name="Seq-X">8 <source linkName="Seq-X-to-Seq-Y"/>9

10 <invoke name="A" ... />11

12 <invoke name="B" ... />13 </sequence>14

15 <sequence name="Seq-Y">16 <target linkName="Seq-X-to-Seq-Y"/>17

18 <receive name="C" ... >19 <source linkName="C-to-E"/>20 </receive>21

22 <invoke name="D" ... />23 </sequence>24

25 <invoke name="E" ... >26 <target linkName="C-to-E"/>27 </invoke>28 </flow>

4.5 Notwendige Erweiterungen für ausführbare Prozesse

Die Orchestrierung von Web Services zu einem ausführbaren BPEL-Prozess umfasst folgende wich-tigen technischen Anforderungen, die an dieser Stelle etwas genauer betrachtet werden sollten. ImFolgenden werden die noch notwendigen Erweiterungen näher beleuchtet und erklärt, warum diesefür die Ausführung des BPEL-Prozesses erforderlich sind. Die generierte BPEL-Prozessdatei mussfolgende De�nitionen enthalten:

Variables - BPEL greift zur Prozessbeschreibung auf die WSDL-Schnittstelle und das XML-Schema zurück. Jeder BPEL-Prozess muss alle in diesem Prozess zu verwendenden Variablen dekla-rieren. Diese werden im Kopfbereich eines jeden BPEL-Prozesses de�niert. Die Variablen <varia-

ble> werden in einem BPEL-Prozess mit einem eindeutigen Namen name und einem bestimmtenTyp de�niert. Die Variablen werden zum Halten von Daten, die beim Nachrichtenaustausch empfan-gen oder gesendet werden, verwendet. Eine Input- oder eine Output-Variable einer Operation, dieüber einen PortType de�niert wird, muss in BPEL ausschlieÿlich einem MessageType entsprechen.Dieses wiederum kann aus einem oder mehreren Parts bestehen. Die Part selbst können auf verschie-dene Weise de�niert werden. In diesem Fall bedeutet es für BPEL, dass eine Variable einen der dreifolgenden Typen wie WSDL-Nachrichten, XML-Schema-Elemente oder einfache XML-Schema-Typehaben kann. Um den Typ festzulegen, muss eines der drei folgenden Attribute bei einer Variablengesetzt werden:

� messageType: Eine Variable, die eine WSDL-Nachricht hält

� element: Eine Variable, die ein XML-Schema-Element hält

� type: Eine Variable, die einfache XML-Schema-Typ hält


Das folgende Beispiel zeigt die typischen drei Deklarationsformen, wobei die De�nition der gleich-namigen Variablennamen hier nur zu Erläuterungszwecken verwendet wird. In BPEL sollten die Va-riablen keine doppelten Bezeichnungen besitzen.

1 <variables>2 <variable name="AnfrageFluege" messageType="air:getFlightRequestInputMessage">3 <variable name="AnfrageFluege" element="air:getFlightsRequestType">4 <variable name="AnfrageFluege" type="air:FlightOrderType"/>5 </variable>

Die letzten beiden Deklarationen setzen voraus, dass die entsprechenden element- oder type-De�nitionen in der WSDL-Beschreibung in der <types>-De�nition oder in dem importierten XML-Schema deklariert worden sind. Die erste De�nition der MessageTypes erfordert eine entsprechendeMessage-De�nition in der WSDL-Beschreibung. Das nächste Listing zeigt eine solche Deklarationder korrespondierenden MessageType-De�nition in der WSDL-Beschreibung.

1 <wsdl:definition ...>2 <wsdl:message name="getFlightRequestInputMessage">3 <wsdl:part name="getFlightRequestPart" element="air:getFlightsRequestType"/>4 </wsdl:message>5 </wsdl:definition ...>

Eine WSDL-Nachricht kann dabei aus einem oder mehreren <part>-Elementen, die wiederum demkomplexen XML-Schema-Type entsprechen, bestehen. Hier ist nur eine <part>-De�nition vorhanden,obwohl es beliebig viele sein können. Des Weiteren kann direkt auf die De�nition des Element-Typenin dem XML-Schema zugegri�en werden, wie es im nächsten Listing zu sehen ist.

1 <element name="getFlightsRequestType">2 <complexType>3 <sequence>4 <element name="FlightOrder" type="air:FlightOrderType"/>5 </sequence>6 </complexType>7 </element>

Wie man an diesem Listing erkennt, ist dieses Element durch die weitere einfache Type-De�nitionbeschrieben. Und zuletzt kann direkt, wie bei der dritten Variable auf die De�nition der einfachenTypen zugegri�en werden. Die hierfür zuständige De�nition ist dem nächsten Listing zu entnehmen.

1 <complexType name="FlightOrderType">2 <sequence>3 <element name="arrivalAirport" type="string"/>4 <element name="departureAirport" type="string"/>5 <element name="departureTime" type="dateTime"/>6 <element name="duration" type="int"/>7 <element name="tickets" type="int"/>8 <element name="class" type="air:TravelClassType"/>9 </sequence>

10 </complexType>

Um eine Variable anschlieÿend benutzen zu können, muss diese vorher instantiiert worden sein,ansonsten wird eine Fehlermeldung bpws:uninitializedVariable geworfen. Die Initialisierung der Va-riablen kann entweder durch die vom Client empfangenden Daten oder durch explizites Setzen durchdie Assign-Aktivität realisiert werden. Die hier vorgestellten De�nitionen der element- und type-De�nition werden in Abschnitt 5.4.2.8 beim Mappen der Variablen auf die MessageType-Variableverwendet.

Expressions - In Transitionsbedingungen und in der Copy-Anweisung können Ausdrücke verwen-det werden, die den eindeutigen Zugri� auf eine bestimmte Variable beschreiben. Diese Ausdrückekönnen mit Hilfe der XPath [W3C07] oder XQuery-Funktionen [W3C07] de�niert werden. Eine solcheFunktion extrahiert notwendige Werte aus den benutzten Variablen und kann diese bei Transitionenauf eine bestimmte Eigenschaft prüfen. Bei Transitionsbedingungen liefert die Prüfung anschlieÿendeinen booleschen Wert true oder false, der bei Verzweigungen ausgewertet wird. Im Folgenden wer-den in dieser Arbeit nur XPath-Ausdrücke verwendet, da XQuery erst Ende Januar dieses Jahres


endgültig standardisiert worden ist und von vielen Engines noch nicht vollständig unterstützt wird.Eine der Möglichkeiten XPath-Ausdrücke zu de�nieren, ist im nächsten Listing zu sehen.

1 bpws:getVariableData(’variableName’, ’partName’?, ’locationPath’?)=’...’

Das erste Argument bestimmt die Quellvariable für die auszuwählenden Werte. Der zweite und derdritte Wert sind optional und können im Zusammenhang mit der genaueren Auswahl der benötigtenWerte verwendet werden. Der partName gibt an, welcher Part ausgewählt wird. Wird beim Zugri�auf die Variable nur das erste Argument angegeben, so kann der zu extrahierende Wert der Variablevom beliebigen Typ sein. Wenn die Variable eine WSDL-Nachricht hält, was allgemein benutzt wird,so kann die Anfrage weiter verfeinert werden, indem hierfür auf die <part>-Elemente zurückgegri�enwird. Der Zugri� auf die Variable erfolgt hierbei über den folgenden XPath-Ausdruck:

1 bpws:getVariableData(’AnfrageFluege’, ’getFlightRequestPart’, ’.’)

Über locationPath kann der genauere XPath-Ausdruck zum Bestimmen eines Wurzel-, Knoten-elementes oder auch nur eines einzelnen Wertes benutzt werden. Für die De�nition des Pfadesmuss eine Anfrage query eingefügt werden, die gemäÿ des Attributes queryLanguage in dem <pro-

cess>-Element deklariert ist. Dabei muss ein absoluter Path angeben werden. Es ist ganz wichtighier zu erwähnen, dass XPath-Ausdrücke nicht nur auf die einfachen XPath-Funktionen beschränktsein können. Es kann jeder beliebiger XPath-Ausdruck benutzt werden, solange dieser gültig ist undder dazu entsprechende queryLanguage-Parameter gesetzt wurde. Da in dieser Arbeit grundsätzlichXPath benutzt wird, ist die zu verwendende Ausdruckssprache im Generator festgelegt. Es ist je-doch vorstellbar, eine GUI zu entwerfen, die erlaubt, den Typ der Sprache festzulegen. Dabei mussdann beachtet werden, dass die Ausdrücke, die als Annotationen verwendet werden, der festgelegtenSprache entsprechen.

Assignments - Bei einfachen BPEL-Prozessen müssen keine Assign-Aktivitäten zwischen denWeb Service-Aktivitäten eingefügt werden, da die Übergabe der Variablen über die gleichnamigenVariablen realisiert werden kann, solange der Datentyp gleich ist. Für die Ausführung komplexe-rer BPEL-Prozesse sind jedoch Wertzuweisungen erforderlich. Sobald in einem Prozess verschiedeneNachrichten ausgetauscht werden, müssen fast immer bestimmte Parts aus einer Nachricht, die voneiner Variablen kommen, einer anderen Variablen zugeordnet werden. Ein wichtiger Aspekt, der beider Zuweisung betrachtet werden soll, ist, dass BPEL eine streng typisierte Sprache ist. Statt dereinfachen Zuweisungen können über die <assign>-Aktivität auch komplexe Berechnungen durchge-führt werden, solange die Typ-Kompabilität beibehalten wird. Solange die Typen der Zuweisungenübereinstimmen oder eine Teilmenge von einem bestimmten komplexen Typen darstellen, wird beider Zuweisung kein Fehler auftreten.

Im Folgenden wird gezeigt, wie die <assign>-Aktivität für die Daten-Manipulation innerhalbdes Geschäftsprozesses eingesetzt werden kann. Diese erlaubt das Zuweisen und Kopieren von Pro-zessvariablen auf andere Prozessvariablen. Um Werte zwischen einer Variablen auf eine andere zukopieren, müssen Variablenwerte in <from>- und <to>-Elementen de�niert werden. Es gibt mehrereMöglichkeiten, wie die <from>und die <to>-Klausel im <copy>-Element gefüllt werden können. Sokönnen z.B. einer Variablen neue Werte von einer anderen Variablen, einem Ausdruck (expression)oder einer Konstante hinzugefügt werden. Es ist erlaubt, in einer <assign>-Aktivität gleichzeitigmehrere <copy>-Operationen zu de�nieren. In dieser Arbeit wird angestrebt, gleichzeitig mehrere<copy>-Klausel in einer <assign>-Aktivität zu de�nieren. Die <copy>-Klausel kann aber nur miteinigen Einschränkungen benutzt werden, wenn beide Variablen vom selben Typ sind oder wenn dieAusgangsvariable einen Untertypen des Zieltypen darstellt.

Im nächsten Listing ist ein einfaches Beispiel einer Wertzuweisung in <assign> de�niert. Dabeisoll die Variable X auf die Variable Y kopiert werden, wobei die optionalen Attribute part und querynicht gesetzt wurden.


1 <assign>2 <copy>3 <from variable="X" />4 <to variable="Y" />5 </copy>6 </assign>

Es ist ebenfalls, möglich bestimmte Ausdrücke zu Variablen hinzuzufügen. Im folgenden Beispielwird ein Ausdruck <expression> in der <from>-Klausel de�niert. Dieses Beispiel zeigt, wie einkonstanter String-Wert zu einer Variablen hinzugefügt werden kann:

1 <assign>2 <copy>3 <from expression="string(’Deutsche Lufthansa AG’)" />4 <to variable="airline" />5 </copy>6 </assign>

Zuletzt wird eine weitere Möglichkeit gezeigt, wie komplette, komplexe XML-Elemente einer Va-riablen hinzugefügt werden können. Für diesen Fall wird die benötigte XML-Datei direkt spezi�ziertund in die <from>-Klausel der <assign>-Aktivität eingefügt. Die vollständige Datenstruktur ent-spricht in diesem Fall einem Literal. Anschlieÿend führt BPEL die <copy>-Klausel aus und kopiertdie einzelnen Werte zu der <to>-Klausel. In diesem Fall wird die Instantiierung der Variablen explizitdurchgeführt. Wichtig dabei ist, dass die in der <to>-Klausel de�nierte Variable dem Datentyp deseinzufügenden Literals entspricht.

1 <assign>2 <copy>3 <from>4 <getFlightRequestType xmlns="http://airlineWS.de/>5 <airline>Deutsche Lufthansa AG</airline>6 <flightNumber>LH123</flightNumber>7 <code>FLH984</code>8 <price>300</price>9 <departureAirport>HAJ</departureAirport>

10 <departureTime>2006-10-10T07:15:00.000Z</departureTime>11 <arrivalAirport>HAM</arrivalAirport>12 <arrivalTime>2006-10-10T08:17:00.000Z</arrivalTime>13 </getFlightListRequestType>14 </from>15 <to variable="AnfrageFluege" />16 </copy>17 </assign>

Die in diesem Abschnitt eingeführten notwendigen Erweiterungen werden in Kapitel 5.4.2.8 imZusammenhang mit der automatischen Erzeugung von Assign-Aktivitäten eine wesentliche Rollespielen. Deshalb war es erforderlich, diese Möglichkeiten hier noch einmal zusammenzufassen.

4.6 Zusammenfassung

In diesem Kapitel wurde die WSDL- und die BPEL-Dokumentstruktur kurz vorgestellt. Die Listingszu den eingeführten WSDL- und BPEL-Elementen können ebenfalls im Anhang A und B nachgelesenwerden. Diese BPEL-Instanzen spielen bei der Erzeugung des BPEL-Codes eine besondere Rolle. DieWSDL-Instanzen werden zum Anfertigen von WSDL-Beschreibungen für die anzubindenden WebServices benutzt. Die eingeführten De�nitionen sollten zum Verständnis der Transformation ausrei-chend sein. Wenn eine ausführlichere De�nition zu den einzelnen BPEL-Elementen gewünscht ist,dann wird auf die BPEL-Spezi�kation [ACD+03] verwiesen.

Kapitel 5

Konzept

�Mache die Dinge so einfach wie möglich - aber nicht einfacher.�Albert Einstein (1879-1955)

Bezugnehmend auf die gesammelten Ergebnisse in den früheren vier Kapiteln wird nun das Kon-zept vorgestellt, mit deren Hilfe man die Transformation von annotierten Geschäftsprozessen nachBPEL durchführen kann. Im Folgenden soll über EPK die Code-Generierung in BPEL unterstütztwerden. In solchem Fall würden die annotierten EPK die Brücke zwischen der Modellierung vonGeschäftsprozessen, die aus den fachlichen Anforderungen entstanden sind, und deren technischenRealisierung in BPEL darstellen. In diesem Kapitel wird zunächst das Konzept für die Transformation,das Vorgehensmodell und anschlieÿend die konzeptuellen Unterschiede der beiden Sprachen erläutert.Im Zusammenhang mit den konzeptuellen Unterschieden werden ebenfalls die Grenzen der automa-tisierten Transformation aufgezeigt und erläutert, welche Konstrukte sinnvoll aus EPK generiert undwelche grundsätzlich in der BPEL-Entwicklungsumgebung erstellt werden sollten. Zum Schluss wirddas vorgestellte Konzept kritisch bewertet.

Es muss konzeptuell geprüft werden, wie die folgenden Fragen beantwortet werden können:

� Welches Vorgehensmodell wird gewählt?

� Welche Mechanismen werden für die Transformation benötigt?

� Wie müssen die EPK-Elemente zu BPEL-Elementen transformiert werden?

� Welche Annotationen sind erforderlich, um die Transformation nach BPEL erfolgreich durch-führen zu können?

� Welche Rollen werden de�niert und von wem werden welche Aufgaben durchgeführt?

5.1 Konzept zur Transformation

In [MZ05] stellen Mendling und Ziemann ein Konzept für die Transformation von BPEL-Prozessennach EPK vor. Der Ausgangspunkt für dieses Konzept ist, dass BPEL keine gra�sche Notationenthält. Jedoch ist es immer wieder erforderlich, dass im Laufe der Geschäftsprozessoptimierung dieFachabteilungen die Prozesse gra�sch vorliegen haben. Deshalb wurde nach einer automatischenTransformation von BPEL nach EPK gefordert, die dem Business Analysten erlauben sollte, BPEL-Prozesse gra�sch zu modellieren.

Jedoch erweist sich die Vorgehensweise von [MZ05] für die Fachbereiche eher als ungeeignet, dadas Konzept strikt der BPEL-Syntax folgt. Bei diesem Vorgehen ist es anzuzweifeln, ob es sinnvollist, zum Beispiel das Exception Handling bei der Transformation von BPEL nach EPK mit EPK-Elementen zu erzeugen. Der Business Analyst oder der IT-Entwickler würden ein Exception Handlingnie in einem EPK-Diagramm modellieren. Denn Exception Handling sollte von einem erfahrenen

42

KAPITEL 5. KONZEPT 43

Entwickler in einer Entwicklungsumgebung durchgeführt werden. In diesem Zusammenhang wird aufAbschnitt 5.3.1 verwiesen. Dort wird ausführlich behandelt, welche Konstrukte während der Trans-formation generiert werden sollten. Deshalb sollte diese Information für den Business Analysten eherirrelevant sein. Eine solche Transformation eines BPEL-Prozesses nach EPK würde immer ein EPK-Diagramm liefern, welches bei der Geschäftsprozessmodellierung von dem Business Analysten mitSicherheit nie so vollständig erstellt werden kann. Somit erweist sich die Abbildung von BPEL nachEPK und EPK nach BPEL nach dem vorgestellten Konzept nicht als eindeutig umkehrbar. Denn derBusiness Analyst muss sich strikt an die BPEL-Syntax halten, um das gleiche Modell modellieren zukönnen. Da BPEL sehr komplex ist, bedarf es einer intensiven Einarbeitung in diese Beschreibungs-sprache. Dieser Ansatz fordert von den Fachabteilungen die Kenntnis der technischen Ablaufstruk-turen, das Denken in BPEL-Konstrukten und erzwingt somit eine vorgeschriebene Vorgehensweise.Wenn die Fachbereiche mit einer sehr stark technisch orientierten Geschäftsprozessnotation arbeitenmüssen und sehr viele Bedingungen gestellt werden, wie die Prozesse im EPK-Diagramm erstellt wer-den sollen, dann führt dies zu Inakzeptanz und Frust in den Fachbereichen. Die Folge wäre, dass dieProjekte zum Scheitern verurteilt wären. Daher sollte die Modellierung der fachlichen Anforderungen,soweit es geht, mit abstrakten Darstellungsmitteln erfolgen. Erst der Entwickler kann im nächstenSchritt entscheiden, wo die notwendigen service-relevanten Annotationen benötigt werden, um dieTransformation von EPK nach BPEL zu ermöglichen.

In Anlehnung an diese Ausarbeitung wird nun das Konzept für die umgekehrte Transformationvon EPK nach BPEL durchgeführt. Denn es ist ganz wichtig, dass die Fachabteilung ihre Prozessein EPK von Anfang an in ihrer abstrakten Sprache modellieren; anschlieÿend diese durch den IT-Entwickler mit Web Services angereichert werden, um zuletzt nach BPEL transformieren zu können.Die Transformation1 sollte nach Möglichkeit in einem Schritt ablaufen, sodass zwischendurch keinemanuelle Eingri�e erforderlich sind. Der Sinn und Zweck einer solchen Abbildung würde damit nichterreicht, wenn dies nicht gewährleistet werden kann. Die Vorteile einer solchen Transformation wurdenim Kapitel 2 schon ausführlich behandelt.

5.1.1 Abbilden der EPK über BPMN-Format

Zurzeit wird in der Literatur sehr häu�g von einer anderen Notation, BPMN, die für die Darstellungvon BPEL-Prozessen geeignet ist, gesprochen. Die neue Beschreibungssprache BPMN bietet demModellierer viel mehr Möglichkeiten an, als dies die EPK erlauben. In Kapitel 5.3.1 wird diese Spracheim Zusammenhang mit dem Vergleich der High-Level-Konzepte zwischen EPML und BPEL ebenfallseingeführt.

An dieser Stelle soll nun kurz erläutert werden, wie die Abbildung nach BPEL über das BPMN-Format realisiert werden kann. Im Verlauf dieser Arbeit wurde zunächst recherchiert, wie der Kon-troll�uss von EPK nach BPEL abgebildet werden kann. Es kam die Frage auf, ob man den Weg vonEPK nach BPEL nicht über das BPMN-Format gehen kann, wie dieser Zusammenhang in der Ab-bildung 3.1 gezeigt wurde. White präsentiert in [Whi05] den ersten möglichen Weg von BPMN nachBPEL. Daraufhin haben Chun Ouyang, Wil M.P. van der Aalst, Marlon Dumas und Arthur H.M terHofstede in [OADH06b] einen BPMN2BPEL-Generator vorgestellt. Da der Generator als Open Sour-ce zur Verfügung steht, kam eine Frage auf, ob man den Generator nicht weiter verwenden könnteund somit den Weg bei der Abbildung über BPMN zu gehen. Um diesen Weg beschreiten zu kön-nen, musste also zunächst das EPML-Format auf das Eingabeformat des BPMN2BPEL-Generatorsgemappt werden. Bei der Evaluierung des Generators wurde hierfür eine Mapper-Klasse in Java im-plementiert, die die notwendigen EPK-Elemente auf die Elemente des Eingabeformats des Generatorsabgebildet hat. Anschlieÿend wurde die Mapper-Klasse vor den Generator geschaltet und mit dem

1Vgl. [WGL05] �Wie zuvor erläutert ist eine automatische Transformation nicht realisierbar und nicht gewollt.�Diese Aussage bezieht sich auf die Abbildung von EPK nach BPEL.


Generator verknüpft, so dass die XML-Datei, die von der Mapper-Klasse kommt, sofort von demGenerator als Eingabedatei übernommen werden konnte. So konnte der Generator gestartet werden,um aus dem EPML-Format den BPEL-Code über BPMN zu erzeugen. Der Generator selbst wurdenicht verändert.

Im Verlauf der Evaluation musste man feststellen, dass der Generator das entworfenen EPK-Diagramm, welches in Kapitel 6 als Beispiel vorgestellt wird, nach BPEL nicht abbilden konnte,obwohl die Abbildung vom EPML- auf BPMN-Format richtig erfolgt ist. Da in die Transformation einEPK-Modell mit mehreren End-Ereignissen eingeht, bricht der Abbildungsprozess bei mehreren End-Ereignissen ab. Bei einfacheren EPK-Modellen konnte die Abbildung jedoch problemlos durchgeführtwerden. Da aber EPK-Modelle sehr häu�g mit vielen End-Ereignissen modelliert werden, führt eineso starke Einschränkung zu keinem gewünschten Ergebnis.

Letztendlich wurde entschieden, sowohl die Abbildung des Kontroll�usses und des Daten�usses alsauch das Hinzufügen der Annotationen über den eigenen Generator, der in diesem und im nächstenKapitel ausführlich vorgestellt wird, durchzuführen. Folgende weitere Gründe haben dazu beigetragen,einen eigenen Generator zu entwerfen. Erstens der Generator generiert bislang nur den Kontroll�ussund liefert einen BPEL-Code, der nur mit Dummy-Werten versehen ist. Die für die Laufzeit not-wendigen Parameter werden durch den Transformationsprozess somit nicht ausgefüllt. Zweitens umin den Transformationsprozess selbst eingreifen zu können und notwendige Erweiterungen einfügenzu können, wurde zunächst der Quellcode studiert. So wurde versucht, nach dem später in diesemKapitel erarbeiteten Konzept Erweiterungen einzufügen. Diese konnten so nicht problemlos einge-fügt werden. Man hätte zwar nach der Erzeugung des Kontroll�usses noch weitere Schritte einfügenkönnen, um in den Generator nicht einzugreifen. Um einen lau�ähigen Prozess erzeugen zu kön-nen, müsste die EPML-Datei noch einmal anschlieÿend eingelesen werden. Anhand der Namen derEPK-Elemente und der erzeugten BPEL-Aktivitäten müsste dann der Abgleich durchgeführt werden,um die Annotationen aus dem EPML-Format auszulesen. Dieses Vorgehen wäre dann aus mehrerenTeilschritten zusammengesetzt, wobei in jedem Schritt man immer mit Fehlern rechnen könnte. DesWeiteren konnte die Fehlerfreiheit des Generators nicht bestätigt werden, da dieser sich ebenfallsin der Entwicklung be�ndet. Der erzeugte BPEL-Code vom Generator wurde aus Strings erzeugt,so dass dieser Code zum Schluss noch validiert werden müsste. Der eigene Generator verfolgt denWeg der Transformation ausschlieÿlich über das annotierte EPML-Format und erzeugt sofort einevalidierte BPEL-Datei, daher wird im Folgenden der eigene Generator ausführlich beschrieben.

Im nächsten Abschnitt werden zunächst die Anforderungen an die Transformation vorgestellt undnäher erläutert.

5.1.2 Anforderungen an die Transformation

Wie in Kapitel 3 in der Abbildung 3.1 gezeigt wurde, besteht die zu realisierende Architektur aus vierEbenen, die durchlaufen werden muss, um von einem Geschäftsprozess zu einem ausführbaren oderäquivalenten BPEL-Code zu gelangen. Die Hauptaufgabe dieser Architektur liegt auf den zwei oberenEbenen, der Modellierungsebene (Business Ebene) und der technischen Ebene. Für die Realisierungdes Konzeptes werden deshalb nur diese zwei Ebenen ausführlicher betrachtet. Die Business-Ebenemuss die meisten Aufgaben erfüllen, um die Transformation realisierbar zu machen. Auf dieser Ebenewird das Geschäftsprozessmodell in einem EPK-Diagramm erstellt, welches im nächsten Schritt aufdas implementierungstechnische Modell abgebildet werden muss. Auf dieser Ebene müssen vielefolgende Aufgaben, wie die Prüfung der Syntax und die Semantik der Modelle, das Testen deserstellten EPK-Modells und schlieÿlich die Anbindung der Web Services durchgeführt werden.

Auf der zweiten Ebene, der technischen Ebene, müssen die Zusatzinformationen angeboten wer-den, die die Abbildung erleichtern sollen. Da für die Annotationen keine Benutzerschnittstelle erstelltwerden sollte, sondern nur ein Konzept vorgestellt werden soll, wie die Transformation durchgeführt


werden kann, werden die Annotationen in XML von Hand durchgeführt. Es ist jedoch vorstellbarhierfür ein Annotationswerkzeug zu entwerfen, welches man dann der technischen Ebene zuordnet.Dieses würde zur Schlieÿung der Lücke zwischen den betrieblichen und implementierungsspezi�schenModellen beitragen.

Zuletzt wird der erzeugte BPEL-Code, der sich auf der dritten Ebene be�ndet, auf der Aus-führungsengine zur Ausführung gebracht. Die Ausführungsengine stellt die vierte Ebene dar. Dieerfolgreiche Ausführung des erzeugten BPEL-Prozesses wird anschlieÿend im ActiveBPEL Designer3.0 mit Hilfe des integrierten Simulators2 getestet. Somit wird ActiveBPEL für das Testen und fürdie Verwirklichung des Konzeptes verwendet.

Es lassen sich aus den vorgestellten Aufgaben folgende Anforderungen an die Transformationableiten, damit die fachlichen Geschäftsprozesse auf die technischen Orchestrierungsmodelle, wieBPEL, abgebildet werden können. Diese werden wie folgt zusammengefasst:

1. Zuerst muss die fachliche Anforderungsmodellierung im EPK-Diagramm abgeschlossen wordensein und das EPK-Modell muss der Validität genügen

2. Der Kontroll�uss und der Daten�uss in EPK muss dem Kontroll�uss und dem Daten�uss inBPEL entsprechen

3. Existenz von Web Services in Form von WSDL-Beschreibungen

4. Auswahl des richtigen Services und die erfolgreiche Anbindung im EPK-Diagramm

5. Annotiertes EPML-Format als Eingabeformat muss validiert vorliegen

6. Sicherstellen einer korrekten Transformation und deren Wiederverwendung

7. Automatisierte Abbildung von fachlichen Modellen

Der erste Anforderungspunkt setzt voraus, dass die Anforderungsmodellierung gemäÿ der gesam-melten Anforderungen in der Analysephase zu dem betrachteten Geschäftsvorfall im EPK-Diagrammabgeschlossen worden ist. Bezugnehmend auf [Ste06] wurden viele Prozessmodelle, die in EPK mo-delliert sind, untersucht. So hat man festgestellt, dass nur die wenigen Modelle der Wohlgeformtheitder EPK genügen3. Der häu�gste Mangel sind das Fehlen von Startereignissen, obwohl die EPK-Syntax dies streng vorschreibt. Bevor die Transformation ausgeführt werden kann, muss das erstellteModell frei von syntaktischen Fehlern sein. Eine Transformation kann erst dann ihren Zweck erfüllen,wenn das EPK-Diagramm korrekt gezeichnet worden ist, d.h. dass das vorliegende Modell auch syn-taktisch korrekt sind. Hierfür sind Validierungsmechanismen zwingend erforderlich, um den BusinessAnalysten oder den IT-Entwickler darauf hinzuweisen. Die Validierung des EPK-Modells stellt sicher,dass die gesammelten Anforderungen in der Analysephase korrekt im EPK-Diagramm abgebildet wor-den sind. Diese Anforderung kann in dieser Arbeit nicht näher betrachtet werden, da dies nicht dasZiel der Aufgabe war. Deshalb wird vorausgesetzt, dass die modellierten Geschäftsprozesse validiertvorliegen müssen. Jedoch gibt es einige ö�entlich verfügbare Papers, die eine solche Validierungerlauben. An dieser Stelle wird das Verfahren von [GL06] erwähnt, welches eine Überprüfung dersyntaktischen Richtigkeit erlaubt. So kann schnell erkannt werden, ob die vorliegenden EPK-Modellesyntaktisch korrekt sind. Die Validierung erfolgt anhand fest vorde�nierter Regeln, die problemloserweitert werden können, da diese in PROLOG de�niert sind. So können für die Transformation nachBPEL spezielle Regeln de�niert werden, die die EPK-Semantik weiter einschränken. Auf der BPEL-Seite kann dagegen auf die Validierung des BPEL-Codes verzichtet werden, da die erstellten Modellein BPEL-Entwicklungsumgebungen weiter verwendet werden können und sollen. Denn aus diesen

2Vgl. [Inf07] Tutorial Part 8: Simulating the Process - Gebrauchsanweisung des Simulators3Vgl. [GL05] �Viele in der Praxis modellierte EPKs sind nach diesen restriktiven Regeln nicht wohlgeformt und könnendemnach nicht übersetzt werden, selbst wenn Praktiker die EPKs problemlos verstehen und einsetzen können.�In diesem Beitrag werden wohl strukturierte EPK-Diagramme vorgestellt, die der Wohlgeformtheit genügen, dadiese den meisten Stilregeln entsprechen.


Entwicklungsumgebungen wird ein plattform-spezi�scher Deployment erzeugt. Solche Umgebungenselbst bieten schon ausgereifte Validierungsmechanismen, die auch gleichzeitig den erstellten Codevalidieren können und auf die kleine noch zu verbleibende Änderung hinweisen können. So wurde imVerlauf der Implementierung der generierte BPEL-Code im ActiveBPEL Designer 3.0 geladen und zu-nächst auf die Fehlerfreiheit geprüft. Jedoch erweist sich nach einer Transformation eine Validierungder entstandenen Orchestrierungsmodelle gegenüber der Ausgangsgeschäftsmodelle für sinnvoll, dagefordert wurde, dass die Transformation den Kontroll�uss auch richtig abbilden soll. Hierfür könnenin weiteren Arbeiten Lösungsvorschläge unterbreitet werden, wie eine solche Validierung aussehenkann. In dieser Arbeit wird die Validierung durch einfaches Vergleichen des Ausgangsmodells mitdem Zielmodell durchgeführt.

Der zweite Punkt, der Kontroll�uss, kann zum Beispiel durch die eingeführten Transformations-konzepte im Abschnitt 2.5.1 behandelt werden. Des Weiteren spielt die in Kapitel 2.7 eingeführteEPK-Semantik für die Erzeugung des Kontroll�usses eine wichtige Rolle. Diese stellt die Anforderun-gen an den Kontroll�uss dar. Die eingeführten Regel müssen beim Modellieren in EPK eingehaltenwerden, damit der Erfolg einer Transformation gewährleistet werden kann. Eine solcher Regeln istzum Beispiel, dass jede EPK ein zusammenhängender Graph sein muss. In Abschnitt 5.3.3 wirdanschlieÿend entschieden, welche Methode für die Abbildung des Kontroll�usses benutzt wird. DesWeiteren muss der Daten�uss von EPK nach BPEL richtig übertragen werden. Hierfür muss einKonzept erarbeitet werden, wie die Übertragung verwirklicht werden kann.

Der dritte Punkt setzt voraus, dass für die Modellierung von SOA-basierten EPK-Modellen WebServices in Form von WSDL-Beschreibungen existieren. Dadurch soll die automatische Abbildungvon annotierten Geschäftsprozessen nach BPEL ermöglicht werden. Denn hier müssen die Web Ser-vices nur an die entsprechende EPK-Elemente angebunden werden, um das Problem der Integritätder Web Services im EPK-Diagramm zu lösen. Daher setzt dieser Anforderungspunkt voraus, dassfür die Anbindung von Web Services, WSDL-Beschreibungen mit internen Typ-De�nitionen oder mitexternen XML-Schema-De�nitionen vorliegen. Es wurde entschieden, WSDL-Beschreibungen mit ex-ternen XML-Schema-De�nitionen zu den verwendeten Typen vorzugeben, da die Hauptaufgabe dieserArbeit in der Transformation von annotierten Geschäftsprozessen nach BPEL besteht und nicht inder Erstellung von Schnittstellenbeschreibungen besteht. Weiterhin sind die bislang bekannten An-sätze, die erzeugte WSDL-Dateien liefern, nur generisch4. Im Transformationsprozess werden diereferenzierten Web Services automatisch aufgerufen und die hierfür notwendigen Informationen5 fürdie Generierung des BPEL-Prozesses heraus gelesen.

Der vierte Aspekt, die Auswahl der richtigen Web Services, erscheint in diesem Fall ebenfalls nichttrivial. Es ist vorstellbar, dass man im realen Einsatz mit mehreren Hundert oder Tausend Servicesmodellieren muss. Einen geeigneten Web Service dabei zu �nden erfordert eine e�ektive Identi�ka-tion der Dienste. Somit scheitert schon die automatische Überführung der betriebswirtschaftlichenGeschäftsprozesse auf die technischen Kompositionsprozesse, wenn der Business Analyst oder derIT-Entwickler nach seinen Wunschvorstellungen den geeigneten Web Service nicht �nden kann. Somuss zum Beispiel zunächst ein neuer Web Service erstellt werden, wenn kein geeigneter Web Ser-vice dafür existiert. Aufgrund dieser Tatsachen wird in dieser Arbeit gefordert, dass geeignete WebServices vorhanden sind, die nur noch angebunden werden müssen.

Der fünfte Punkt fordert, dass ein syntaktisch korrektes, annotiertes EPML-Format vorliegt unddie Validitätsprüfung abgeschlossen hat. Die Validitätsprüfung, die hier gemeint ist, bedeutet, dass

4Vgl. [Wit06] �d.h. es werden noch keine konkreten Web Services referenziert, sondern lediglich das Format vonausgetauschten Nachrichten sowie die aufgerufenen Operationen und deren Schnittstellen de�niert.� Die Bindingszu konkreten Web Services müssen dann manuell festgelegt werden. �Dies bedeutet unter anderem einen Bruch inder automatisierbaren Abfolge des Transformationsprozesses, da die manuelle Referenzierung von Web Services mitjeder weiteren Transformation nach einer Änderung des Ausgangsmodells erneut durchgeführt werden muss.�

5Viele der Informationen, wie die Datentypen, Nachrichten, Operationen, Protokolle und Rollen be�nden sich bereitsin den WSDL-Beschreibungen der referenzierten Web Services.


das EPML-Format wohl geformt ist und der Validität des EPML-Schemas genügen soll.

Ob die sechste Anforderung, also das Sicherstellen einer korrekten Transformation, und die siebteAnforderung, die automatisierte Abbildung, erfüllt werden können oder nicht, kann erst nach derdurchgeführten Transformation gesagt werden. Weiterhin darf gefordert werden, dass bei der Trans-formation die erzeugten BPEL-Prozesse anschlieÿend ausgeführt werden sollen. Die Antwort auf dieseForderung kann ebenfalls erst am Ende dieser Arbeit beantwortet werden.

Zusammenfassend bedeutet es, um mit der Transformation anfangen zu können, wird vorausge-setzt, dass folgende Aufgaben, wie die Prüfung der Semantik und der Syntax, das Testen und dieOptimierung der Geschäftsprozesse abgeschlossen worden sind. Wie die korrekte Anbindung der WebServices realisiert wird, wird in den nächsten Kapiteln gezeigt. Folgende Dokumente werden für dieTransformation als Eingabeparameter benötigt:

� Validiertes, annotiertes EPML-Modell mit allen erforderlichen Annotationen

� WSDL-Beschreibungen zu den gewünschten Web Services

Als Ergebnis der Transformation werden folgende Dokumente erwartet:

� Validierter BPEL-Prozess, der das interne Verhalten eines Geschäftsprozesses beschreibt undallen oben genannten Anforderungen genügen soll

� WSDL-Beschreibungen für die De�nition der PartnerLinkTypes zu den angebundenen WebServices, damit die PartnerLinks der Web Services eindeutig identi�zierbar sind

� WSDL-Beschreibungen für BPEL-Prozesse

In den nächsten Abschnitten wird jede einzelne Anforderung genauer untersucht und beschrieben,wie man gewährleisten kann, dass diese erfüllt werden kann.

5.2 Vorgehensmodell

Bezugnehmend auf die im Abschnitt 2.5.1 vorgestellten Arbeiten, wird im Folgenden ein Konzeptfür die Transformation von annotierten Geschäftsprozessen nach BPEL vorgestellt. Die Abbildung5.1 stellt den detaillierten Ablauf der Transformation dar. Beim Abbilden der in EPK vorliegendenGeschäftsprozesse auf BPEL muss die Transformation mehrere Schritte durchlaufen. Es wird bei die-sem Verfahren auf der Business-Ebene (EPK) die Top-Down- und auf der Implementierungsebene(BPEL) die Bottom-Up-Modellierung eingesetzt. Die notwendigen Einzelschritte des Transformati-onsprozesses werden dabei ausführlich beschrieben.

Das Vorgehensmodell gliedert sich in mehrere Schritte wie folgt auf:

1. EPK-Modellierung auf der Business-Ebene

2. Analyse und Import notwendiger Web Services

3. Anreicherung des EPK-Diagramms um implementierungs-spezi�sche Aspekte

4. Ausführung der Transformation; die Transformation baut selbstständig BPEL-Prozesse auf,daher wird dieser Schritt auch als �Orchestrierung von Web Services auf technischer Seite�de�niert

5. Verknüpfen der einzelnen BPEL-Prozesse

6. Gegebenenfalls manuelles Nachbearbeiten von generierten BPEL-Prozessen durch Hinzufügenvon plattform-spezi�schen Erweiterungen


Abbildung 5.1: Übergang vom der Geschäftsprozessebene auf die Service-Prozessebene

5.2.1 EPK-Modellierung auf der Business-Ebene

Ein Geschäftsprozess kann nach Gehring zit. v. Gadatsch et al. [Gad03] formal auf unterschiedli-chen Detaillierungsebenen und aus mehreren Sichten beschrieben werden. Im ersten Schritt wird dasEPK-Diagramm vom Business Analysten in einem Modellierungstool erstellt. Der zu beschreibendeGeschäftsprozess wird zuerst immer auf einem sehr hohen Abstraktionslevel de�niert. Ein EPK-Diagramm auf Ebene 1 erlaubt wiederum andere Geschäftsprozesse als Unterprozess einzubinden.Anschlieÿend verfeinert man das Geschäftsprozessmodell bis zur niedrigsten Stufe, bis die einzelnenauszuführenden Funktionen atomar sind. Diese atomaren, elementaren Geschäftsprozessschritte be-schreiben dabei normalerweise in welcher Reihenfolge die jeweiligen Tätigkeiten im Unternehmenausgeführt werden müssen. Jedoch anstatt, dass diese Tätigkeiten durch Personen, die einen Bear-beiter darstellen, ausgeführt werden, sollen diese zunächst durch einen Web Service ersetzt werden. Indiesem Fall entspricht eine atomare Funktion einer Funktion mit Web Service-Anbindung, d.h. einerWSDL-Operation, die die Unterstützung zum Senden und Empfangen von Nachrichten anbietet. Esgibt dabei keine Grenzen bei der De�nition der Systemebenen, die ineinander verschachtelt werdenkönnen. So entsteht ein hierarchisches Dekompositionsmodell6, welches dem geforderten SOA-Prinzipentspricht. Wo eine Anwendung in kleinere Funktionseinheiten aufgeteilt wird, die eine bestimmteAufgabe erledigen sollen, wobei jede einzelne Aktivität dann durch einen Web Service beschriebenwerden soll. Die Kollaboration der einzelnen Aktivitäten soll zum Schluss einen vollständigen BPEL-Prozess beschreiben, der auf einer BPEL-Engine ausgeführt werden soll.

Man kann laut [TSKM04] eine solche Verfeinerung über drei bis fünf Ebenen durchführen, wobeidie niedrigste Ebene (1) den höchsten und die höchste Ebene (5) den niedrigsten Abstraktionsgrad7

6Vgl. [LLSG05] �EPCs are well-suited for this task because many views are just hierarchical re�nements of traditionalbusiness functions.�

7Vgl. [BDR06] �Funktionen einer EPK in einer Schicht sind mit kompletten EPKs der nächsthöheren Schicht hinterlegt.Der Vorteil einer derartigen Modellierung liegt in der einfachen Austauschbarkeit und der Möglichkeit der externen


darstellt. Eine groÿe Herausforderung stellt die einzusetzende Granularität der Geschäftsprozessedar. Die durch die hierarchische Dekomposition beschriebene Detaillierungsgrad darf in diesem Fallweder zu niedrig noch zu hoch sein. Beim zu hohem Detaillierungsgrad wird die Komplexität derGeschäftsprozesse zu hoch und bei zu niedrigem ist die Deutungsmöglichkeit zu hoch, die einenhohen Handlungsbedarf erlaubt. An dieser Stelle wird in Abschnitt 5.4.2.5 fortgesetzt.

Die Prozessmodellierung mit EPK kann zur Gestaltung von Anwendungssystemen oder Organisa-tionszwecken verwendet werden. Bei der Modellierung muss man klar festlegen, welchen Zweck dieBeschreibung der Geschäftsprozesse erfüllen soll. Ist der Zweck eines Geschäftsprozesses eher allge-meiner, so muss man auf dem mittleren Detaillierungsgrad bleiben. Das heiÿt, dass das Modell fürOrganisationszwecke verwendet wird, so spielt hierbei die Übersichtlichkeit der Abläufe eine beson-dere Rolle und die Anzahl der Ebenen ist klein. Wird dagegen eine Beschreibung für eine Softwareerstellt, so gibt die Applikation den Detaillierungsgrad vor. Bei Anwendungssystemen be�ndet sichdas betrachtete Modell sehr nah an der Implementierungsebene.

Für die Dekomposition muss das EPK-Diagramm zunächst in Ebenen zerlegt werden, wobei dieKorrektheit [Bac80] des betrachteten Modells unbedingt eingehalten werden muss. So ist zum Beispielein Prozess an einem eindeutigen Anfang und Ende feststellbar. So muss jede hierarchische Funktionvon zwei Ereignissen umschlossen sein, um eine Verfeinerung überhaupt durchführen zu können. DerAnfang und das Ende einer untergeordneten EPK wird also anhand von Ereignissen identi�ziert.Diese Voraussetzung muss unbedingt erfüllt werden, sonst kann die verfeinerte EPK auf der Ebene2 in die Ebene 1 nicht problemlos eingefügt werden. Diese Voraussetzung gilt ebenfalls für das�Flachklopfen�8 der EPK auf eine einzige Ebene. Wurden zum Beispiel die Ereignisse vergessen,so stellt das betrachtete EPK-Diagramm kein syntaktisch korrektes Modell mehr da. Dies ist dieerste häu�g vorkommende Fehlerquelle bei der Modellierung der EPK. Deshalb müssen diese korrektausmodelliert vorliegen.

5.2.2 Analyse und Import notwendiger Web Services

In [LLSG05] wird zu einer Funktion9 in einem EPK-Diagramm vorgeschlagen, einen Web Servicezuzuordnen. Nach der Geschäftsprozessmodellierung müssen nun diejenigen Funktionen identi�ziertwerden, zu welchen ein Web Service zugeordnet werden kann. Wann eine solche Zuordnung jedocherfolgen soll, wird aber nicht gesagt. Denn es erscheint aber ganz wichtig zu sein, auf welcher Gra-nularitätsebene die Zuordnung durchgeführt werden soll. Wird auf einer zu hohen Abstraktionsebenedie Zuordnung durchgeführt, so entspricht der zugeordnete Web Service in diesem Fall einem BPEL-Prozess. Handelt es sich in einem EPK-Diagramm um eine fachliche Funktion, die eine bestimmteBPEL-Aktivität beschreibt, so wird angestrebt, diese Funktion durch ein Web Service darzustellen,wenn sich diese überhaupt durch ein Web Service beschreiben lässt.

Die Geschäftsprozessmodellierung folgt dabei dem Top-Down-Prinzip, wobei jede zusammenhän-gende Funktion in kleinere fachliche Funktionen heruntergebrochen wird, um diese anschlieÿendmit einem Web Service zu verbinden. Die Anbindung kann dabei durch das Setzen der expliziten

Abarbeitung von Teilprozessen.�8Vgl. [NR02] Nüttgens und Rump sprechen in diesem Zusammenhang vom �Flachklopfen� eines hierarchisches EPK-Schemas in ein �aches EPK-Schema und führen hierfür notwendige Forderungen auf, um �aus einem syntaktischkorrekten, hierarchischen EPK-Schema ein �aches EPK-Schema zu erzeugen. ... Aufgrund dieser Möglichkeit werdenzur Semantikde�nition nur �ache Schemata ohne Prozesswegweiser betrachtet, was entsprechend dieser Ausfüh-rungen keine Einschränkung darstellt.�.Das in Kapitel 6 vorgestellte Beispiel wird alle diese Forderungen erfüllen, um die syntaktische Korrektheit sicher-zustellen.

9Die Funktionen können auch manuelle Funktionen mit Benutzerinteraktionen oder im Falle eines Web Servicesautomatisierte Funktionen ohne Benutzerinteraktionen sein.


Aktivitätentyps des BPEL-spezi�schen Namen der Web Service-Aktivitäten, wie <invoke>, <re-

ceive> oder <reply> im EPML-Format als Annotation erfolgen. Es wird hier das Setzen desexpliziten Typs bevorzugt, da dieser fest vorgeschrieben ist und der Business Analyst dafür nur nochdie Funktion auswählen muss und entscheiden, welche Art der Aktivität es sein muss. Da dafür dasOriginal-EPML-Format um weitere explizite Typen wie <invoke>, <receive> und <reply> imSyntax-Element erweitert werden müsste, wird das Setzen des expliziten Typen durch <attribute

typeRef=’functionType’ value=’invoke’ bevorzugt. Die Gründe hierfür wurden in Kapitel3 ausführlich behandelt. Dabei erweist sich diese Möglichkeit für den Business Analysten oder denIT-Entwickler als benutzerfreundlicher.

5.2.3 Anreicherung des EPK-Diagramms um implementierungsspezi�scheAspekte

Es stellt sich die Frage, wie die unter Punkt 3 angesprochene Anreicherung um Web Services e�zientdurchgeführt werden kann. Dieser Schritt soll mit möglichst wenigen Schritten und wenigen Anno-tationen verbunden sein. Eine Anreicherung der Funktionen kann über die EPK-Elemente, wie demInformationsobjekt, der Organisationseinheit oder der Anwendungskomponente durchgeführt werden.Diese werden als Annotationshilfsmittel betrachtet, um den Web Service näher zu spezi�zieren. Wirdzum Beispiel im EPK-Diagramm die Anwendungskomponente oder die Ein- und Ausgabeparameter(im EPML-Format <application> und <dataField>) benutzt, so können zunächst in einemTransformationsschritt die <partnerLinks>- und die <variables>-Elemente in BPEL generiertwerden. Hierfür müssen ebenfalls zu den erstellten EPML-Dateien implementierungsspezi�sche In-formationen in Form von Annotationen hinzugefügt werden, die die notwendigen Angaben für dieAnbindung einer WSDL-Datei enthalten. Wie solche Annotationen an der Funktion benutzt und wel-che BPEL-Elemente daraus erzeugt werden sollen, wird ausführlich im Abschnitt 5.4 behandelt. Biszu diesem Schritt wurde der Top-Down-Ansatz verfolgt.

5.2.4 Orchestrierung von Web Services auf technischer Seite

Auf der technischen Seite ist für die Orchestrierung BPEL zuständig. Bei der Modellierung derBPEL-Prozesse können unabhängig von dem hier vorgestellten Vorgehensmodell drei verschiedeneMethoden benutzt werden. Man kann den Top-Down-, den Bottom-Up-Ansatz oder eine Kombinationvon beiden verwenden [Inf07]. Bei der ersten Methode wird der BPEL-Prozess skizziert, wobei dieeinzelnen Tätigkeiten in Aktivität heruntergebrochen werden und dazwischen Links zwischen denAktivitäten erstellt werden. Anschlieÿend werden alle notwendigen Informationen hinzugefügt, umden Prozess lau�ähig zu machen. Dafür müssen die notwendigen Web Services identi�ziert undaufgerufen werden.

Bei der Bottom-Up-Methode werden die De�nitionen von WSDL-Beschreibungen benutzt. DieseDateien liegen validiert vor dem Erstellen des Geschäftsprozesses vorgefertigt vor. Darauf aufbauendwird jeder einzelne Serviceaufruf identi�ziert und zu einer BPEL-Aktivität hinzugefügt. Anschlieÿendwerden die Aktivitäten zu einem vollständigen Geschäftsprozess orchestriert. Für die nähere De�nitionder WSDL-Dateien wird auf Kapitel 4 verwiesen.

In der letzten Methode, der Kombination von Top-Down- und Bottom-Up-Technik kann der Pro-zess mit vorgegebenen WSDL-Dateien begonnen werden. Ausgehend von den vorgegebenen WSDL-Dateien kann der Kontroll�uss in BPEL aufgebaut werden. Wenn zusätzliche Elemente benötigtwerden, so können die vorliegenden Dateien editiert oder es können neue WSDL-Dateien hinzu-gefügt werden. Der Unterschied zu der Bottom-Up-Methode besteht nur darin, dass die WSDL-Beschreibungen dem geforderten Anforderungen noch angepasst werden können.


Auf der technischen Seite können nun die einzelnen Aktivitäten, die auf der linken Seite ei-ne Entsprechung zu einer fachlichen Funktion haben und durch die hierarchische Dekompositionentstanden sind, nach dem SOA-Prinzip zu gröÿeren Geschäftsprozessen zusammengefasst werden.[Klü06] schlägt deshalb auch vor, bei der Dekomposition von fachlichen Anforderungen auf der linkenSeite technische Services auf der rechten Seite aufzubauen. Der Aufbau von BPEL-Prozessen erfolgtdabei in umgekehrter Richtung. Die einzelnen Web Services werden nach dem Bottom-Up-Prinzipzu technischen Prozessen in BPEL orchestriert. Wenn eine fachliche Funktion auf der linken Seitemit einem Web Service identi�ziert wird, so benötigt diese Funktion eine technische Anreicherung,um die benötigten Parameter für BPEL sicherzustellen. Im nächsten Schritt wird eine vorgefertigte,gültige WSDL-Datei zu den einzelnen, fachlichen Funktionen, die in BPEL den Aktivitäten entspre-chen, hinzugefügt. Das Hinzufügen der WSDL-Dateien erfolgt durch Annotation. Zuletzt soll aus derannotierten EPML-Datei der BPEL-Code generiert werden.

In Kapitel 2 wurde in diesem Zusammenhang erwähnt, dass sich einmal orchestrierte Web Ser-vices im BPEL-Prozess nach auÿen als eigenständige Web Services repräsentieren. Es gibt in BPELebenfalls keine Grenzen, wie viele Prozessebenen es geben kann, deshalb sind bei diesem Vorge-hen keine Grenzen gesetzt. Bezugnehmend auf das Beispiel in der Abbildung 2.1 kann die fachlicheFunktion AirlineReservieren durch einen entsprechenden Orchestrierungsprozess in BPEL10 ersetztwerden. Ein Web Service beschreibt eine Aufgabe, die eine beliebige Gröÿe aufweisen kann. DasWeb Service-Konzept schreibt dabei nicht vor, wie groÿ Web Services sein müssen. So kann einWeb Service entweder aus einem Receive, einer internen Berechnung durch eine Assign-Aktivitätund einer anschlieÿenden Reply-Aktivität dargestellt werden. Oder wie schon oben erwähnt wird einWeb Service durch einen komplexen BPEL-Prozess beschrieben. Daher können Geschäftsprozesse,die mit Hilfe der Beschreibungssprache BPEL erstellt wurden, auf zwei getrennten Ebenen betrachtetwerden. Die obere Ebene (top-layer) des Geschäftsprozesses repräsentiert die Kontrollstrukturlogikder Anwendung. Die untere Ebene beschreibt dagegen die Web Services, die die Funktionenlogikbeinhalten.

BPEL erlaubt eine rekursive Komposition, indem ein BPEL-Prozess wiederum als ein Web Servicebetrachtet wird, der über eine WSDL-Schnittstelle beschrieben werden muss. Dabei können folgendeSituationen auftreten. Erstens kann ein Web Service ein BPEL-Prozess aufrufen, der wiederum ausmehreren kleinen Web Services besteht. Zweitens kann ein Web Service über einen BPEL-Prozessaufgerufen werden. Und drittens kann die Situationen vorkommen, die eigentlich schon im erstenFall beschrieben worden ist. Dabei ruft der aufgerufene BPEL-Prozess den aufrufenden Web Servicewieder auf. Im letzten Fall ist ein Zyklus zwischen den Aufrufen entstanden, der nach Möglichkeitvermieden werden sollte, um die Komplexität nicht unnötig zu steigern. Solche Fälle dürfen in EPKnach der folgenden EPK-Syntax [NR02] nicht modelliert werden, da die EPK-Syntax bei Hierarchieneine solche Modellierung verbietet.

Ein Geschäftsprozess auf der höchsten Abstraktionsebenen auf der linken Seite entspricht einemzusammengesetzten BPEL-Prozess auf der rechten Seite, der als eigenständiger Web Service auf-tritt und beliebig komplex sein kann. Der auf der nächst tieferen Ebene dargestellte Kontroll�uss imEPK-Diagramm muss demnach den Kontroll�uss des BPEL-Prozesses näher beschreiben. Zusammen-gefasst bedeutet es, dass auf der höchsten Abstraktionsebene die automatischen EPK-Funktionendem Aufruf eines BPEL-Prozesses, wenn es sich dabei um eine hierarchische Funktion handelt, undauf der niedrigsten Abstraktionsebene dem Aufruf eines Web Services, wenn es sich um eine einfachefachliche Funktion handelt, entsprechen.

10Vgl. [HSSH06] �Problematisch bei einer einstu�gen Orchestrierung ist die Bestimmung der Granularität der Services:wird sie zu fein gewählt, müssen Teilabläufe, die in unterschiedlichen Prozessen gleich sind, immer wieder aufsNeue zusammengestellt werden. Ist die Granularität zu grob, ist der Vorteil der Flexibilität und Agilität nicht mehrgegeben. Daher ist es unerlässlich, Services über mehrere Aggregationsstufen hinweg orchestrieren zu können. ...ein aus Services orchestrierte Prozess wiederverwendet und wiederum selbst als Service in einer Komposition aufhöherer Ebene eingebunden werden kann. Nach diesem Verständnis ist nicht nur eine atomare Funktion ein Service,sondern auch ein Prozess bestehend aus mehreren Sub-Services.�


5.2.5 Verknüpfen der einzelnen BPEL-Prozesse

In den oben beschriebenen Abschnitten wurde gezeigt, wie die Transformation durchgeführt werdenkann. Beim Übergang von der betrieblichen Geschäftsprozessebene auf die service-orientierte Ebeneunterscheidet [WGL05] vier verschiedene Modellierungsansätze:

1. Von der Prozesslandkarte direkt zur Service-Orchestrierung

2. Service-Orchestrierung als unterste Ebene der Geschäftsprozesshierarchie

3. Jeder Ebene der Geschäftsprozesshierarchie Service-Prozesse zuordnen

4. Nur end-to-end Prozesse auf unterster Ebene in Serviceprozesse übertragen

Des Weiteren wird ausdrücklich darauf hingewiesen, dass Änderungen auf der einen Seite in denmeisten Fällen eine Überarbeitung der Prozesse auf der anderen Seite erfordert. Daher wird bevor-zugt, dass die BPEL-Prozesse auf der untersten Modellierungsebene der Geschäftsprozesshierarchieabgeleitet werden sollen, um die Synchronisationsnotwendigkeit so niedrig wie möglich zu halten.Eines der weiteren Gründe ist, dass die betrieblichen Geschäftsprozesse erst auf der untersten Ebeneden Prozess gesamt abbilden. Denn erst auf dieser Ebene enthalten die Prozesse alle notwendigenInformationen. Da auf den höheren Ebenen die Ein- und Ausgabedaten nicht modelliert werden, ent-halten solche Beschreibungen nicht die notwendigen fachlichen Anforderungen, die eine Abbildungnach Punkt (3) erlauben könnten.

Für die Vorführung des Konzeptes werden daher einige Einschränkungen gemacht. Die Implemen-tierung, die im Kapitel 6 ausführlich erläutert wird, ermöglicht zwar für jede EPK, die über ein <epc>-Element in einer EPML-Datei beschrieben wird, einzelne BPEL-Prozesse im Transformationsprozesszu generieren. Jedoch um eine hierarchische Abbildung von EPK nach BPEL ermöglichen zu können,muss es zunächst möglich sein, die �achen EPK auf BPEL-Kompositionen abzubilden. Hierfür musszunächst der Kontroll�uss und der Daten�uss in einer �achen EPK analysiert und anschlieÿend nachBPEL abgebildet werden. Erst anschlieÿend können daraus hierarchische Abbildungen implementiertwerden. Als Implementierung ist hier das automatische Verknüpfen von generierten BPEL-Prozessengemeint, wie man diesen Zusammenhang der Abbildung 5.1 auf der rechten Seite entnehmen kann.Des Weiteren muss man sich die Frage stellen, ob die Verknüpfung der einzelnen generierten BPEL-Prozesse manuell nicht schneller durchgeführt werden kann, wenn man sich die Anzahl der hierfürnotwendigen Annotationen in Vergleich setzt, die erforderlich sind, um die notwendige Verknüpfungzu realisieren.

Die erzeugten BPEL-Prozesse in einem Hierarchie-Modell müssen nach dem vorstellten Konzeptmiteinander über die <receive>- oder <reply>- und der aufrufenden <invoke>-Aktivität im über-geordneten BPEL-Prozess verbunden werden. Die Start- und End-Ereignisse stellen in diesem Falldie Schnittstellen zu dem übergeordneten Prozess oder anders ausgedrückt, dem Client, her. Hierfürmüsste aber zunächst für den erzeugten BPEL-Prozess eine WSDL-Beschreibung mit einer neuenPortType-De�nition und den hierfür notwendigen Bindings erzeugt werden, da für den Prozess nochgar keine WSDL-Beschreibung vorliegt. Die erforderlichen Annotationen im EPML-Format, die inden nächsten Abschnitten erläutert werden, beziehen sich ausschlieÿlich auf die abstrakte De�nitionder WSDL-Beschreibung. Das heiÿt in diesem Fall, dass für die Erstellung des BPEL-Prozesses alsAnnotation bislang nur die abstrakte De�nition der angebundenen Web Services benötigt werden.Zwar können folgende Informationen, wie die URL der importierten Web Services, die MessageTypesund der PortType zusammen mit der benötigten Operation, die den abstrakten Teil der WSDL-Beschreibung ausmachen, automatisch erzeugt werden, so muss für die Laufzeit des Prozesses dieDe�nition des konkreten Bindings in die WSDL-Beschreibung ein�ieÿen. Es muss also nach der Er-zeugung des BPEL-Prozesses ebenfalls der konkrete Teil der WSDL-Beschreibung generiert werden,der für die Ausführung erforderliche Informationen festhält. Dies sind unter anderem die eindeutige


Festlegung des Kommunikations- und Transportprotokolls als auch die eindeutige URL des verwende-ten Web Services. Jedoch wurde aber in Abschnitt 5.1.2 eingeführt, dass die automatische Erzeugungvon Bindings nur generisch durchgeführt werden kann, daher wurden auch die WSDL-Beschreibungenvollständig für die Anbindung an die EPK-Funktion vorgegeben. Bezugnehmend auf [Wit06] kommtes in diesem Schritt zu �einen Bruch in der automatisierbaren Abfolge des Transformationsprozesses�.Aus diesem Grund wird für die Start- und End-Ereignisse die WSDL-Beschreibung des Clients vorge-geben, der ebenfalls aus der Sicht des Partners als ein eigenständiger Web Service auftritt. Die Start-und End-Ereignisse erhalten Annotationen, die vergleichbar mit denen einer Funktion sein werden.

Abbildung 5.2: Flache Hierarchie eines EPK-Diagramms

Ein weiterer wichtiger Grund ist, dass jede EPK einzeln transformiert wird und für die nächsteübergeordnete EPK viele Parameter gemerkt werden müssen. Denn vorher muss zunächst die überge-ordnete EPK zu einem neuen BPEL-Prozess abgebildet werden. Erst anschlieÿend dürfen die vorhergemerkten Parameter der übergeordneten Invoke-Aktivität zugeordnet werden. Um dies gewährleistenzu können, müssten hierfür viele Annotationen de�niert werden, um daraus anschlieÿend automati-siert eine vollständige WSDL-Beschreibung erzeugen zu können. Dadurch dass hierarchische EPK inein einzelnes, �aches EPK-Schema transformiert oder gleichzeitig auf der untersten Ebene modelliertwerden können, bleibt durch das �ache EPK-Schema trotzdem der gleiche Zusammenhang eines be-trieblichen Geschäftsprozesses erhalten. Dieses Vorgehen entspricht dem vierten oben vorgestelltenAnsatz von [WGL05] .

Aus den oben genannten Gründen werden in dieser Arbeit deshalb nur die �achen EPK als Bei-spiel vorgeführt. Das heiÿt in diesem Fall, dass das EPK-Modell zunächst auf die unterste Ebene�ach geklopft werden muss und im EPML-Format sich in einem <epc>-Element be�nden wird. An-schlieÿend wird daraus nur ein einziger BPEL-Prozess generiert, welcher ebenfalls �ach ist, jedochin sich den untergeordneten BPEL-Prozess enthält. Die Abbildung 5.2 stellt diesen Zusammenhangausführlich dar. Trotz dieser Einschränkung wurde theoretisch ein Konzept erarbeitet, welches so-wohl für die �achen als auch für die hierarchische EPK gilt und die Möglichkeiten des Vorgehensnicht einschränkt. Hierfür wurden die einzelnen Schritte des Vorgehensmodells betrachtet und erläu-tert, wie eine solche Realisierung aussehen kann. Ebenso wurden die Grenzen einer automatischenTransformation aufgezeigt. Wird dagegen eine hierarchische Prozessmodellierung als Eingabeformatgeliefert, so werden zwar daraus einzelne BPEL-Prozesse erzeugt, diese müssen aber im nächstenSchritt manuell miteinander verknüpft werden.

5.2.6 Manuelle Nachbearbeitung

Zur Zeit de�nieren die vorhandenen BPEL-Engines eine Vielzahl von eigenen Extensions, die nur aufder spezi�schen Engine ausgeführt werden können. An dieser Stelle beschränkt man sich nur auf zweiinteressante Erweiterungen von der Oracle BPEL Process Manager11. Zu solchen Erweiterungen zäh-len der Oracle TaskManager Service und die Möglichkeit XSLT-Funktionen für Datenmanipulationen

11http://www.oracle.com/technology/products/ias/bpel/index.html


in BPEL zu verwenden. Diese Extensions werden in den darauf folgenden Abschnitten noch einmalin ihrem zu verwendenden Zusammenhang angesprochen. So ist es vorstellbar, dass der exportierteBPEL-Prozess im nächsten Schritt, um plattform-spezi�sche Eigenschaften vom Entwickler ergänztwerden kann. Daher ist es vorstellbar, in das Vorgehensmodell einen zusätzlichen manuellen Schritteinzufügen, der dem Entwickler ermöglicht die erzeugten BPEL-Prozesse nachzubearbeiten. SolcheBPEL-Prozesse können dann nur ausschlieÿlich auf der betrachteten Engine zur Ausführung gebrachtwerden.

5.3 Konzeptuelle Unterschiede zwischen den beiden Modellen

Ein EPK-Diagramm enthält viel weniger Elemente als die Ausführungssprache BPEL. Es können zwardie meisten EPK-Grundelemente auf BPEL-Elemente abgebildet werden, so fehlen aber trotzdemdie notwendigen Informationen, die für eine korrekte Abbildung nach BPEL erforderlich sind. Mitder korrekten Abbildung ist hier das Setzen der erforderlichen Parameter für die Ausführung desProzesses gemeint, da ohne solcher Zusatzinformationen der Kontroll�uss von EPK nach BPELtrotzdem problemlos abgebildet werden kann.

5.3.1 Vergleich der High-Level-Konzepte

In [MNN04] wurde ein groÿer Vergleich der 15 bekanntesten XML-Formate durchgeführt und anhandder folgenden Aspekte eine Klassi�kation der High-Level-Konzepte abgeleitet. Wie man der Tabelle5.1 entnehmen kann, unterstützt EPML nicht so viele der dargestellten Aspekte einer ausführbarenBeschreibungssprache wie BPEL. Wenn eine hundertprozentige Abbildung von EPML nach BPELgewünscht ist, dann müssen die EPK in Bereich der Datenbehandlung, Exceptions, Transaktion undanderen notwendigen Punkten erweitert werden12. Des Weiteren muss man sich fragen, ob eine solcheErweiterung überhaupt gewünscht ist. Denn würde man viele weitere Aspekte, die BPEL unterstütztin EPML-Format integrieren, dann führt solches Vorgehen zu einer weiteren Work�ow-Sprache, diedas Problem der Interoperabilität nur verstärken würde. Natürlich kann man in jede Sprache beliebigviele Aspekte13 einfügen, ob dieses Vorgehen dann Sinn macht, ist eine andere Frage und kann zueiner langen Diskussion führen, auf die hier weiter nicht näher eingegangen werden soll. Denn genausogut kann man eine neue Sprache, wie BPMN, einführen, die solche Aspekte schon unterstützt, alseine proprietäre Sprache immer wieder zu erweitern. Zur Vollständigkeit wird hier das BPMN-Formatebenfalls betrachtet, da in Abschnitt 5.1.1 darauf kurz eingegangen worden ist.

Da das EPML-Austauschformat nur drei von dreizehn vorgestellten Punkte unterstützt, wird indiesem Zusammenhang schon deutlich, wie mächtig die Kompositionssprache BPEL ist. Im Folgendenwerden kurz die unterstützenden Aspekte im EPML-Format näher beschrieben.

Der Kontroll�uss (control �ow) wird im EPML mit Hilfe der Kanten und in BPEL über die struktu-rierte Aktivitäten dargestellt. Das Abbilden der Kanten auf die strukturierten Aktivitäten stellt in dergesamten Transformation die gröÿte Schwierigkeit dar, da BPEL nicht nur eine strukturierte Aktivitätkennt. Die einzelnen Funktionen in EPK können nicht so einfach auf die entsprechenden, strukturier-ten BPEL-Elemente abgebildet werden, da hierfür die Reihenfolge der aufzurufenden Aktivitäten einebesondere Rolle spielt. Deshalb muss in diesem Zusammenhang der Kontroll�uss genauer untersuchtund anschlieÿend auf die BPEL-Kompositionen abgebildet werden. In diesem Zusammenhang werdenim nächsten Abschnitt die Work�ow Patterns betrachtet.

12Vgl. [MNN04] �Further aspects can be de�ned via extensions�13Vgl. [LA06] �Since the early nineties work�ow technology has matured ... . During this period many languages for

modeling work�ows have been proposed ... . The Work�ow Management Coalition (WfMC) has tried to standardizework�ow languages since 1994 but failed to do so ... . In a way BPEL ... succeeded in doing what the WfMC wasaiming at�.


EPML BPEL4WS BPMNControl Flow + + +Data Handling - + +Instance Identi�cation - + -Roles - + +Events + + +Exceptions - + +Transactions - + +Task I/O - + +Task Adress/URI - + +Quality Attributes - - -Task Protocol - + +Graphic Position + - +Static Data - - -

Tabelle 5.1: Unterstützung der High-Level-Konzepte in BPM, Auszug aus [MNN04]

Die Ereignisse werden von allen drei Sprachen unterstützt. Jedoch führt das genauere Betrach-ten dazu, dass die Ereignisse im EPK-Modell eine mehrdeutige Funktion haben und eher für denKontroll�uss und in BPEL zum Empfangen einer bestimmten Nachricht benutzt werden. Aus diesemGrund werden die Ereignisse in Kapitel 5 und 6 näher betrachtet.

Der letzte Punkt, den das EPML-Format vollständig unterstützt, ist die gra�sche Positionie-rung von EPK-Elementen, die für die Transformation nach BPEL irrelevant ist. Dieser Punkt wurdeschon im Kapitel 3 im Zusammenhang mit der Identi�kation von relevanten und irrelevanten EPML-Elementen angesprochen. Es verbleibt also nur der Kontroll�uss, der nach BPEL abgebildet werdenmuss. Jedoch reicht die Abbildung des Kontroll�usses nicht aus, um einen lau�ähigen BPEL-Prozesszu erstellen. Aus diesem Grund müssen noch weitere Aspekte in die Transformation aufgenommenwerden. Die in Kapitel 4.5 aufgeführten, notwendigen Erweiterungen müssen deshalb für die Erstel-lung eines lau�ähigen BPEL-Prozess durch den Transformationsprozess abgedeckt werden.

Da EPK-Modelle keine explizite Datenbehandlung anbieten, unterstützt das EPML-Format auchkeine Daten-Manipulationen (data handling). Zwar ist es möglich für jede Informationsdienstleistungeine Variable in BPEL zu generieren, so wird die Sache bei den Correlation Sets und Properties schonetwas schwieriger, da BPEL in Vergleich zu EPK in diesem Zusammenhang viel mächtiger ist. ImAbschnitt 5.4.2.8 wird gezeigt, wie das Data Handling betrieben werden kann, um mit den in EPMLzur Verfügung stehenden Mitteln zusammen mit nur wenigen Annotationen die Daten-Manipulationenin BPEL zu erlauben.

Weiterhin spielen die verschiedenen Handler und die Transaktionen eine wichtige Rolle in einemBPEL-Prozess. Die explizite Modellierung von Exception Handler, Correlation Sets, Properties undTransaktionen im EPK-Diagramm sollte nicht vollständig auf die betrieblichen Geschäftsprozesseverlagert werden. Die Gründe warum die Transaktionen hier weiter nicht behandelt werden, wurdenschon in Kapitel 3.3 erläutert. Die diversen BPEL-Handler haben in EPK keine Entsprechung undwerden deshalb ebenfalls nicht näher betrachtet. Denn hier ist der Zweck einer Nachmodellierung derHandler mit EPK-Konstrukten im EPK-Diagramm anzuzweifeln und wurde schon eingangs im diesemKapitel angesprochen. Hierfür müsste sich der Modellierer in der BPEL-Syntax sehr gut auskennen,um diese mit den in EPK zur Verfügung stehenden Mitteln nachbilden zu können. Da der BusinessAnalyst die einzuhaltenden Reihenfolge der Aktivitäten in BPEL nicht kennt und dafür keine geeigneteAusbildung besitzt und der IT-Entwickler ein Exception Handling nie im EPK-Diagramm modellierenwürde, werden diese Punkte in dem Transformationskonzept nicht näher betrachtet. Dadurch dassfür BPEL ebenfalls Tools entwickelt werden, können diese Punkte an dieser Stelle e�zienter mit


den spezi�schen Tools14 erstellt werden. Weiterhin können die erzeugten BPEL-Prozesse zunächstim BPM-Zyklus optimiert werden und erst zu Schluss kann der Entwickler an den entsprechendenStellen die notwendigen Handler einfügen. Dadurch wird das erstellte EPK-Diagramm einfacher undkompakter.

Ein weiterer wichtiger Aspekt, der bei der Transformation beachtet werden soll, ist, dass dieserSchritt fast immer mit Informationsverlusten einhergeht, wenn die betrachteten Beschreibungsspra-chen eine unterschiedliche Menge von Elementen und Attributen enthalten. Die Informationsverlustetreten bei der betrachteten Transformation von EPML nach BPEL hauptsächlich in der gra�schenNotation auf, da BPEL nach der Spezi�kation keine gra�sche Notation kennt. Hier �ndet aber grund-sätzlich eine Anreicherung des betrachteten EPML-Austauschformates statt, da das EPML-Formatviel weniger Elemente als BPEL enthält. Auÿerdem muss beachtet werden, dass man nicht immereine geeignete Abbildung durchführen kann.

Im Folgenden wird eine De�nition zum Begri� �vollautomatische Transformation� gegeben. Untereiner vollautomatischen Transformation versteht man hier, dass alle in BPEL möglichen Elementeund Attribute erzeugt werden können. Dem zur Folge bedeutet eine teil-automatische Transformati-on, dass zwar viele BPEL-Elemente und -Attribute automatisch generiert werden können, diese aberim Vergleich zu der in BPEL erlaubten Menge an Elementen nur eine Teilmenge darstellen. Das heiÿtalso, dass wenn zum Beispiel aus EPK keine Handler erzeugt werden können, die Gesamttransfor-mation dann nicht mehr als vollautomatisch betrachtet werden kann. Nach dieser De�nition wird imFolgenden die Transformation nach BPEL durchgeführt.

5.3.2 De�nition von Work�ow Patterns in EPK und BPEL

BPEL-Prozesse verfolgen das Ziel verschiedene Web Service in einer Komposition zusammenzufassen.Die Komposition von Web Services bedeutet die Erstellung eines bestimmten Work�ows, der einegenau Abfolge der aufzurufenden Web Services, in der diese aufgerufen und wie die Eingabe- undAusgabedaten verarbeitet werden, beschreibt. Um die Transformation erfolgreich durchführen zukönnen, muss zunächst der Kontroll�uss untersucht werden. Beide Beschreibungssprachen EPML undBPEL können zuerst auf eine gemeinsame Darstellungsform des Kontroll�usses abgebildet werden,um die Gemeinsamkeiten und die Unterschiede feststellen zu können.

In Anlehnung an [AHKB02] und [Kie03] eignen sich für die Beschreibung des Kontroll�usses die 20Work�ow Patterns15, die van der Aalst, ter Hofstede, Kiepuszewski und Barros in ihren Untersuchun-gen erarbeitet haben. Die Work�ow Patterns beschreiben den Kontroll�uss in der Geschäftsprozess-modellierung eindeutig und werden häu�g zum Vergleich unterschiedlicher Sprachen herangezogen.Darauf aufbauend haben Wohed, van der Aalst, Dumas und ter Hofstede [WADH02] diese Work�owim Zusammenhang mit BPEL untersucht und vorgeschlagen, wie die einzelnen Work�ow Patternsauf die BPEL-Elemente abgebildet werden können. In diesem fachlichen Beitrag hat man festgestellt,dass nur 14 von 20 Work�ow Patterns von BPEL unterstützt werden. In [ADH03] wird eine ausführ-liche, kritische Evaluierung aller bis dahin bekannten Web Service-basierten Kompositionssprachen,wie WSFL, XLANG, BPEL usw. durchgeführt, aus der auch die Tabelle 5.2, die auf der nächsten Seitedargestellt ist, entnommen worden ist. Diese stellt eine ausführliche Gegenüberstellung der unterstüt-zenden Work�ow Patterns dar. Hier wird ebenfalls die Menge der in [AHKB02; Aal] verö�entlichen

14Vgl. [IS05] �Jeder Hersteller behauptet, dass es möglich wäre, alle erforderlichen Tätigkeiten im Rahmen einer SOA-Umgebung nur mit einem Werkzeug durchzuführen. Die Erfahrung zeigt aber, dass eine deutlich höhere E�zienzerzielt wird, wenn man für die fachliche und technische Tätigkeiten die am besten dafür geeigneten Werkzeugekombiniert.�

15Unter einem Pattern versteht man ein Muster, welches durch eine bestimmte Konstellation von EPK- oder BPEL-Symbolen beschrieben werden kann. Das Zusammenführen der einzelnen Work�ow Patterns beschreibt den mögli-chen Kontroll�uss in einem BPM-Diagramm.


Work�ow Patterns zum Vergleich herangezogen. Ausgehend von diesen Arbeiten wurden anschlie-ÿend die EPK-Work�ow-Patterns [MNN05] von Mendling, Neumann und Nüttgens angeschaut undder Übersicht der Tabelle zum Vergleich hinzugefügt.

Die Evaluierung liefert folgende wichtige Ergebnisse. Erstens der Vergleich erlaubt die Ausdrucks-stärke zwischen den verschiedenen Sprachen herzustellen und zweitens die betrachteten Sprachenunterstützen eine unterschiedliche Menge von Patterns. Keine der betrachteten Sprachen unterstütztalle Work�ow Patterns vollständig. Das Ergebnis von [MNN05] führt zu dem Entschluss, dass dasEPK-Diagramm nur neun Work�ow Patterns unterstützt. Jedoch können nur acht von diesen neunEPK-Work�ow Patterns in BPEL erzeugt werden. Auf die genauere De�nition der Work�ow Patternsin BPEL wird auf [WADH02] verwiesen, wo eine ausführliche Beschreibung gegeben wird.

Basic Control Patterns EPK BPEL XLANG WSFL

WP1 - Sequence + + + +WP2 - Parallel Split + + + +WP3 - Synchronization + + + +WP4 - Exclusive Choice + + + +WP5 - Simple Merge + + + +Advanced Branching and Sync. Patterns

WP6 - Multi Choice (+) + - +WP7 - Synchronizing Merge (+) + - +WP8 - Multi-Merge - - - -WP9 - Discriminator - - - -Structural Patterns

WP10 - Arbitrary Cycles + - - -WP11 - Implicit Termination + + - +Involving Multiple Instances (MI)

WP12 - MI Without Synchronisation - + + +WP13 - MI With a Priori Design Time - + + +WP14 - MI With a Priori Runtime - - - -WP15 - MI Without a Priori Runtime - - - -State-based Patterns

WP16 - Deferred Choice - + + -WP17 - Interleaved Parallel Routing - (+) - -WP18 - Milestone - - - -Cancellation Patterns

WP19 - Cancel Activity - + + +WP20 - Cancel Case - + + +

Tabelle 5.2: Work�ow Patterns in untersuchten Sprachen, Auszug aus [ADH03]

Es wird in dieser Arbeit keine vollständige Beschreibung aller Work�ow Patterns angestrebt.Man beschränkt sich nur auf die Tabelle 5.2, die alle unterstützenden Work�ow Patterns darstellt.Zur Vollständigkeit werden in der Tabelle ebenfalls die Work�ow Patterns für die beiden SprachenXLANG und WSFL betrachtet. Die direkte Unterstützung des Work�ows Patterns wird mit einem+ gekennzeichnet und bedeutet, dass ein bestimmtes Work�ow Pattern in der Sprache unterstütztwird. Wenn das gewünschte Pattern nicht dargestellt werden kann, so bedeutet es, dass hierfür keinedirekte Unterstützung vorliegt. Dies wird in der Tabelle mit - gekennzeichnet.

Die Work�ow Patterns werden zunächst in folgende Kategorien, wie Basic Control Flow Pattern,Advanced Branching and Synchronisation Patterns, Structural Patterns, Involving Multiple Instances(MI), State-based Patterns und Cancellation Patterns eingeteilt. Folgende Patterns, wie Sequence,Parallel Split, Synchronisation, Exclusive Choice, Simple Merge, Multiple Choice oder auch Syn-chronisation Merge, werden auch sehr häu�g beim Modellieren in EPK-Diagrammen benutzt. Wieman der Tabelle 5.2 entnehmen kann, so korrespondieren die ersten fünf Work�ow Patterns mitelementaren Kontrollstrukturen. Diese werden auch von allen Sprachen unterstützt.


Ein groÿes Problem in BPEL stellt die Mehrdeutigkeit der Spezi�kation dar. So ist es möglicheinen BPEL-Prozess auf unterschiedliche Weisen darzustellen. In Kapitel 2.4 wurde eingeführt, dassdie BPEL-Spezi�kation auf IBM's WSFL und Microsoft's XLANG aufbaut. Sowohl die �XLANG-style�- und die �WSFL-style�-basierte Beschreibungsweise der BPEL-Prozesse16 erlaubt den EPK-Kontroll�uss in BPEL vollständig zu beschreiben. Des Weiteren erweist sich WSFL gegenüber XLANGals die mächtigere Beschreibungssprache17, die mehr Work�ow Patterns unterstützt. Sowohl in EPKals auch in WSFL ist möglich konkurrierende und alternative Zweige darzustellen. Die gemeinsameSchnittmenge von acht Work�ow Patterns der beiden Sprachen erlaubt den elementaren Kontroll�ussvon EPK nach BPEL abzubilden. Aus diesem Grund wird im nächsten Abschnitt ein Vergleich zwi-schen der graph-orientierten und der block-orientierten Darstellungsweise eingeführt und anschlieÿendentschieden, welche Darstellung für den Kontroll�uss für die in dieser Arbeit vorgestellte Abbildungbenutzt wird.

5.3.3 Graph-orientierte versus block-orientierte Beschreibungssprache

BPEL vereint in sich die Eigenschaften von zwei völlig verschiedenen Standards für die Beschreibungvon Web Service Kompositionen18. Zwar schlägt die BPEL-Spezi�kation vor, für die Darstellung desKontroll�usses strukturierte Aktivitäten19 zu verwenden, so erlaubt die Vereinigung dem Modelliererein Mix aus block-orientierten und graph-orientierten Beschreibungsweise zu benutzen. XLANG ist ei-ne block-orientierte Sprache mit Kontrollstrukturen, wie <sequence> (für sequentielle Ausführung),<switch> (für bedingte Ausführung), <while> (für Schleifen), <all> (für parallele Au�ührung)20

und <pick> (zum Aufruf von Aktivitäten, die durch Zeit oder einen Trigger ausgelöst werden). DerKontroll�uss wird über das Verschachteln der primitiven Aktivitäten in den strukturierten Aktivitä-ten, wie <sequence>, <flow>, <while> oder <pick>, die im Kapitel 4.4 eingeführt worden sind,durchgeführt. Zusätzlich benutzt BPEL für die Synchronisation von block-orientierten Konstruktendie Links, die aus WSFL kommen. Hier wird deutlich, dass für die Darstellung des Kontroll�usses dieblock-orientierte Beschreibungsweise nicht ausreichend ist.

WSFL21 ist dagegen eine graph-orientierte Sprache und basiert ausschlieÿlich auf dem Konzeptder Kontrolllinks, über die ein direkter azyklischer Graph (directed acyclic graph, DAG ) de�niertwerden kann. Der Kontroll�uss wird über Pfeile de�niert, die eine Verbindung zwischen zwei Knotendarstellen. Die Knoten können dabei vom beliebigen Typ sein. Deshalb können diese in BPEL sowohlan strukturierten als auch an elementaren Aktivitäten verwendet werden. Die Links können nur in derstrukturierten <flow>-Aktivität benutzt werden. Wenn alle weiteren elementaren und strukturierteAktivitäten in dieser <flow>-Aktivität benutzt werden, dann müssen die Links an allen Aktivitätengesetzt werden. Mit deren Hilfe können die enthaltenen Aktivitäten gemäÿ einer vorgeschriebenenOrdnung miteinander verbunden werden. Die <flow>-Aktivität kann eine beliebige Anzahl weitererAktivitäten beinhalten, die parallel ausgeführt und anschlieÿend synchronisiert werden können. Die<flow>-Aktivität wurde zusammen mit den Links im Kapitel 4 eingeführt und ausführlich erläutert.

Des Weiteren müssen bei der Realisierung der Links einige Restriktionen eingehalten werden, umdie syntaktische Korrektheit einzuhalten. In BPEL dürfen die Grenzen eines <while>-, <scopes>-,<eventhandler>- oder <compensationhandler>-Konstruktes von einem Link gleichbedeutend inwelche Richtung nicht überschritten werden. Die Links dürfen letztendlich keine Zyklen erzeugen,

16Vgl. [WADH02] Wohed et al. spricht in diesem Zusammenhang von XLANG- und WSFL-style17Vgl. [WGL05] �Nur sie ermöglicht die korrekte, vollständige Übertragung aller EPK-Ereignisse in Übergangsbedin-

gungen in BPEL sowie die Darstellung der OR-Verknüpfung �18Vgl. [Aal03] �BPEL4WS joins viewpoints from both WSFL and XLANG thus making the language very complex�19In der Literatur wird BPEL häu�g als die block-orientierte Beschreibungssprache de�niert.20In BPEL durch <flow>-Element ersetzt21BPEL, WSFL und XLANG schreiben in ihrer Spezi�kation nicht vor, wie die XML-basierte Sprachen dargestellt

werden sollen.


so dass die über die Links de�nierten Graphen azyklisch sein müssen, d.h. eine Aktivität darf nichtwieder auf ihren Vorgänger zeigen. Das bedeutet in diesem Fall für die EPK, dass diese ebenfalls alsgerichtete azyklische Graphen de�niert werden müssen. Die EPK kennen jedoch keine Einschränkun-gen bezüglich solcher De�nitionen, da keine explizite EPK-Semantik für die Schleifen existiert. Soerlauben zum Beispiel EPK Schleifen und Sprünge zu modellieren, die über mehrere EPK-Elementegehen. Ein solches Vorgehen ist vergleichbar mit dem goto-Konzept. Es ist ebenfalls möglich ausSchleifen Ausgänge zu modellieren, die in BPEL nicht erlaubt sind. Dies hat zur Folge, dass nichtalle Zyklen von EPK nach BPEL abgebildet werden können. In BPEL sind die Zyklen nur über dieSchleifen erlaubt, die über die strukturierte <while>-Aktivität modelliert werden. Aufgrund solcherEinschränkungen ist die Abbildung der Zyklen eine komplexe Angelegenheit. Die Schleifen wurden infolgenden beiden Arbeiten [Kop05; Sch06b] weitgehend behandelt, dabei beschränkt man sich auchnur auf sehr einfache Zyklen. Aus diesem Grund werden die Schleifen hier nicht mehr betrachtetund vorausgesetzt, dass die EPK-Modelle azyklisch sein müssen. Um eine erfolgreiche Transformati-on zu gewährleisten, muss zunächst das EPK-Modell auf Zyklen untersucht werden, um die Zyklenauszuschlieÿen. Für die Erkennung von Zyklen wird auf die als Open Source frei verfügbaren Java-Algorithmen für DAGs von [Mac04] zurückgegri�en. Wird ein Zyklus gefunden, so wird dem Benutzermitgeteilt, dass im vorliegenden EPK-Diagramm ein Zyklus vorliegt.

In BPEL können die elementaren Kontroll�üsse, die für das gleiche Verhalten stehen, auf zwei völligverschiedene Arten dargestellt und implementiert werden. In diesem Zusammenhang spricht van derAalst et al. von lacking orthogonality [ADH03]. Eine Sequenz (WP1) im EPK-Diagramm kann, durchein <sequence>- oder ein <flow>-Konstrukt erzeugt werden. Ebenso können die Verzweigungenmit Hilfe des <switch> oder des <flow>-Elementes realisiert werden. Das heiÿt, dass einfacheWork�ow Patterns (WP1-WP5) über strukturierte Aktivitäten <sequence>, <switch> usw. oderebenfalls über die Kontrolllinks, oder nach belieben über eine Kombination von beiden Möglichkeitenbeschrieben werden können. Deshalb wird dann auch von XLANG- oder WSFL-basierten Darstellungder BPEL-Prozesse gesprochen.

Die nächsten zwei Abbildungen 5.3 und 5.4 verdeutlichen noch einmal die Mehrdeutigkeit vonBPEL, d.h. die Unterschiede zwischen der graph-orientierte WSFL-Beschreibung und der block-orientierten XLANG-Darstellung. In der ersten Abbildung 5.3 wird zuerst der Kontroll�uss einesParallel-Splits (WP2) mit der darauf folgenden Synchronisation (WP3) gra�sch dargestellt. In EPKwird ein Parallel Split durch einen AND-Split und die Synchronisation durch anschlieÿenden AND-Joinerreicht.

Abbildung 5.3: Vergleich der XLANG- und WSFL-basierten Darstellung eines Parallel Split- und einesSynchronisation-Work�ow Patterns


In der zweiten Abbildung 5.4 wird ein Exclusive Choice (WP4) mit dem anschlieÿenden SimpleMerge (WP5) gra�sch erläutert. Ein Exclusive Choice in EPK wird durch einen XOR-Split und derSimple Merge durch einen XOR-Join beschrieben. Durch die beiden Darstellungen wird die Mehr-deutigkeit von BPEL sehr gut deutlich. So ist bei der XLANG-basierten Darstellung die expliziteModellierung der Synchronisation (WP3) und des Simple Merge (WP5) nicht notwendig, da diesedurch die Verwendung der Blockstruktur erreicht wird.

Abbildung 5.4: Vergleich der XLANG- und WSFL-basierten Darstellung eines Exclusive Choice- und einesSimple Merge-Work�ow Patterns

Eine Abbildung zwischen einer graph-orientierten wie EPK und einer block-orientierten Beschrei-bungssprache wie BPEL ist eine schwierige Aufgabe. In der Vergangenheit haben viele versucht, dieAbbildung von einer graph-orientierten zu einer block-orientierten Beschreibung herzustellen. Die inAbschnitt 2.5.1 vorgestellten Ansätze (11) und (12) beschäftigen sich ausschlieÿlich mit der Abbil-dung des Kontroll�usses von Work�ow Nets und BPMN nach BPEL. Dabei wird das Ziel verfolgt,bei der Transformation gut lesbaren BPEL-Code herzustellen. Bezugnehmend auf [Kie03] ist dieAusdrucksstärke von block-orientierten Sprachen nur auf gut strukturierte (well-structured) Prozessebeschränkt. Das heiÿt sobald die XML-Restriktionen gebrochen werden, wie es in Kapitel 4.4 imZusammenhang mit Links erläutert wurde, wird ebenfalls auf die <flow>-Darstellung zurückgegrif-fen. Das Problem der block-orientierten Diagramme liegt in der Eins-zu-Eins-Beziehung zwischen denSplit- und Join-Konnektoren. Diese werden nur durch einen Block dargestellt. Daraus resultieren kom-plexe Algorithmen, die benötigt werden, um eine graph-orientierte Struktur auf eine block-orientierteStruktur abbilden zu können. Wenn man aber algorithmisch nach bestimmten Kontrollstrukturensucht, so müssen die beiden zusammen mit den enthaltenen Aktivitäten gleichzeitig erkannt werden.Algorithmisch ist es sehr schwer bei unstrukturierten EPK festzustellen, ob ein Split-Konnektor über-haupt durch einen Join-Konnektor wieder geschlossen worden ist, oder wann es noch geschlossenwird. Aus diesem Grund wird die block-orientierte Repräsentation üblicherweise nur dort verwendet,wo die Abbildung leicht durchgeführt werden kann.

Es wird zwar von der Verwendung des <links>-Elements in [DJM05] abgeraten, da bei vielen<link>-De�nitionen die Übersicht verloren geht und der Aufwand für die Änderungen im Prozesssteigt. Weiterhin wird sehr oft erwähnt, dass die Darstellung mit strukturierten Aktivitäten viel besserlesbar ist. Hier muss an dieser Stelle gesagt werden, dass dieser Aspekt eher von dem betrachtetenGeschäftsprozess abhängig gemacht werden sollte. Bei groÿen Geschäftsprozessen, wenn die Ver-schachtelung über mehrere strukturierte Aktivitäten durchgeführt wird, so wird diese Darstellungebenfalls schnell unübersichtlich. Die block-orientierte Darstellungsweise ist an die in Programmier-sprachen verwendete Beschreibungsmöglichkeit angelehnt. Wenn viele elementare und strukturierte


Aktivitäten in einander verschachtelt werden, wie es die block-orientierte Struktur erlaubt, so wächstdie Darstellungs�äche sehr schnell, und daher kann man nicht sagen, dass diese Darstellungsformdann viel besser lesbar ist. Diesen Zusammenhang kennt man sehr gut aus allen bekannten Pro-grammiersprachen, wie Java oder C++. Wenn die Verschachtelungstiefe von For-Schleifen und If-Ausdrücken sehr groÿ wird, kann man ebenfalls schwer nachvollziehen, was in diesen Konstruktennoch durchgeführt wird. Daher kann hier der Aussage, dass durch eine groÿe Anzahl von Links dieÜbersicht verloren geht, nicht entsprochen werden. Denn solange die Links aussagekräftige Namentragen, kann eine Identi�kation sehr schnell und einfach erfolgen. Des Weiteren mögen einige lieberdie block-orientierte, die anderen wiederum die graph-orientierte Darstellung.

Folgende Punkte haben zu der Entscheidung bei der Wahl der WSFL-basierten Darstellung beige-tragen. Der transformierte Kontroll�uss des EPK-Diagramms ist im BPEL-Kontroll�uss sofort erkenn-bar. So können schnell Rückschlüsse auf das EPK-Modell geschlossen werden und ggf. Änderungendurchgeführt werden. Der zweite Aspekt für diese Entscheidung ist, dass sich eine graph-orientierteBeschreibungssprache EPK dadurch einfacher auf die graph-theoretischen BPEL-Konstrukte abbildenlässt. Der dritte Punkt liegt darin begründet, dass EPK-Modelle sehr häu�g unstrukturiert modelliertwerden. So müsste vorher eine Überprüfung des EPK-Diagramms erfolgen und eine Restrukturierungdurchgeführt werden, um die Abbildung auf strukturierte Aktivitäten zu ermöglichen. Hinzu kommtnoch, dass mit Hilfe der Links die XML-Restriktionen bezüglich der Verschachtelung e�zient um-gangen werden können. Daher wird an dieser Stelle die WSFL-Darstellung bevorzugt. Eine solcheRestriktion wurde in 4.4 vorgestellt und wurde in das später behandelte Beispiel aufgenommen. Imgenerierten BPEL-Code werden alle Aktivitäten im <flow>-Konstrukt verpackt und anschlieÿendmit Links verknüpft. Und der letzte wichtige Grund ist, dass BPEL-Prozesse für die Ausführung derGeschäftsprozesse entworfen worden sind. Deshalb ist die gewählte Form zunächst irrelevant, solangedie modellierten Geschäftsprozesse in ihrer zeitlich logischen Abfolge richtig ausgeführt werden.

5.4 Transformation von EPK nach BPEL

Die Überführung von EPK nach BPEL lässt sich vollständig durch die Zuordnung der EPK-Elementezu den BPEL-Elementen und durch die eindeutige Beschreibung des Kontroll�usses und des Da-ten�usses realisieren. Eine weitere wichtige Rolle bei der Abbildung spielen die Funktionen und dieDaten, die diese Funktionen verarbeiten.

5.4.1 Transformationsstrategien für die Beschreibung des Kontroll�usses

Für die Abbildung einer graph-orientierten Sprache auf eine block-orientierte Darstellung wurden in[MLZ05] und [MLZ06] vier Strategien vorgeschlagen, die man der nächsten Tabelle 5.3 entnehmenkann. Wie man erkennt, beschränkt sich jede Strategie jeweils auf eine bestimmte Eigenschaft desGraphen. Entweder sind die Graphen gut strukturiert oder diese dürfen keine Zyklen enthalten. Keineder hier vorgestellten Strategien kann alle Graphen transformieren. Kommen beide Aspekte in einemwirklich groÿen Diagramm vor, so ist es nach wie vor ein ungelöstes Problem, wie man eine solcheAbbildung e�zient durchführen soll, da hierfür komplexe Algorithmen benötigt werden.

Transformation Strategie from Graph to BPEL Structured Graph Acyclic Graph All Graphs

Element-Preservation - + -Element-Minimization - + -Structure-Identi�cation + - -Structure-Maximization + + -

Tabelle 5.3: Transformationsstrategien, Auszug aus [MLZ05]


Wie oben erläutert, stellt die Abbildung einer graph-orientierten Sprache auf eine block-orientierteStruktur ein groÿes Problem dar. Im Folgenden werden die Kontroll�ussstrategien kurz erläutert,die in dem oben genannten Paper eingeführt worden sind, um das Problem der Beschreibung desKontroll�usses während der Transformation von einer graph-orientierten Sprache, in diesem Fall EPK,nach BPEL zu lösen. Dieser Schritt ist zum Verständnis des im Kapitel 6 vorgestellten Algorithmusvon groÿer Bedeutung.

Die Transformationsstrategien können grob in zwei Kategorien eingeteilt werden. Erste Kategoriebilden die Element-Preservation und die Element-Minimization-Strategie, die dem graph-orientiertenAnsatz folgen. Die beiden anderen, die Structure-Identi�cation und Structure-Maximization-Strategieverfolgen das Ziel, beim Abbilden soweit es möglich ist, den Kontroll�uss auf strukturierte Aktivitä-ten, also nach dem block-orientierten Ansatz, abzubilden. Aufgrund der Wahl des WSFL-basiertenDarstellungsweise der BPEL-Prozesse wird die zweite Kategorie weiter nicht mehr betrachtet. Daherwird im Folgenden die erste Kategorie näher erläutert.

Die Element-Preservation-Strategie folgt dem Ansatz, alle Elemente in ein <flow>-Konstrukt unddie Kanten (arcs) auf die BPEL-Links abzubilden. Dieses Vorgehen setzt jedoch voraus, dass der be-trachtete Geschäftsprozess azyklisch ist. Der Grund liegt hier in der BPEL-Spezi�kation, die es nichterlaubt Zyklen über die Links zu de�nieren. Alle Operatoren, wie Verzweigungen und Synchronisation,werden auf eine <empty>-Aktivität mit allen Join- und Split-Bedingungen in BPEL abgebildet. DerVorteil dieser Strategie ist, dass diese Transformation einfacher zu implementieren ist. Dabei wird je-des EPK-Element auf ein BPEL-Element abgebildet. Der korrespondierende technische BPEL-Prozesssieht von der Struktur dem betrieblichen Geschäftsprozess in EPK am ähnlichsten. Der Nachteil die-ser Strategie ist, dass der generierte BPEL-Prozess viel mehr Elemente für die Ausführung enthält,als dies überhaupt notwendig ist. Das kommt daher, weil BPEL in allen Aktivitäten die De�nitionvon Join-/Split-Bedingungen anhand der Synchronisations- (join conditions) und den Transitions-bedingungen (transition conditions) erlaubt. Somit erweist sich der generierte BPEL-Prozess als einwenig überladen.

An dieser Stelle setzt anschlieÿend die Element-Minimization-Strategie an und vereinfacht dengenerierten BPEL-Code der Element-Preservation-Strategie. Die zentrale Idee, die dabei verfolgtwird, ist das Entfernen von <empty>-Aktivitäten, die aus Join- und Split-Konnektoren generiertworden sind. Der Vorteil einer solchen Optimierung liegt darin, dass die generierten BPEL-Prozessenäher der BPEL-Semantik des <flow>-Konstruktes entsprechen. Dabei müssen beim Entfernen der<empty>-Elemente die Verzweigungen, die mittels Transitionsbedinungen an den Links und Join-Verhalten über Synchronisationsbedingungen auf die Vorgänger- und Nachfolger-Knoten übertragen,alte Links entfernt und neue Links eingefügt werden. Des Weiteren müssen die Link-Namen in denJoinCondition-Bedingungen ebenfalls aktualisiert werden.

In dieser Arbeit wurden die beiden Transformationsstrategien nach dem hier vorgestellten Verfah-ren implementiert und werden an einem Beispiel in Kapitel 6 evaluiert.

5.4.2 Vergleich der EPK- und BPEL-Elemente

In diesem Abschnitt wird nun ausführlich die Transformation nach BPEL behandelt. Es werdendie Abbildungen aller EPK-Elemente einzeln näher beschrieben und ausführlich erläutert, welcheElemente Annotationen benötigen, um lau�ähige BPEL-Prozesse erzeugen zu können. Die Tabelle5.4 zeigt zunächst eine Gegenüberstellung der wichtigsten Elemente der beiden betrachteten SprachenEPML und BPEL. Diese Übersicht verdeutlicht, wie hier die einzelnen Elemente von EPK nach BPELabgebildet werden sollen.

An den Entwickler werden lediglich einige wenige Anforderungen gestellt, die beim Vervollständi-gen des EPK-Diagramms erfüllt werden müssen. Es wird vorausgesetzt, dass Annotationen im Editor,


EPML-Elemente BPEL-Elemente Beschreibung<epc> <process> De�nition des übergeordneten Elementes

<and>, <xor>, <or> <empty>-Aktivität Beschreibung verschiedener Joins u. Splits<arcs> <links> Kontroll�uss, zum Verbinden einzelner Elemente

<function> <activity> Beschreibt eine auszuführende Tätigkeit<events-function> <transitions> Vorbedingungen von Funktionen werden zu Transitionsbedingungen

<dataField> <variables> Beschreibt Datenelemente<application> <partnerLinks> De�nition der PartnerLink für den Service<events> Ereignisse, die einer Funktion folgen, werden entfernt

<startEvent> <receive>-Aktivität Start eines Geschäftsprozesses<endEvent> <reply>-Aktivität Ende eines Geschäftsprozesses

Tabelle 5.4: Äquivalente Elemente in beiden Sprachen

die in den nächsten Abschnitten näher beschrieben werden, gesetzt werden. Denn ohne der zusätz-lichen Annotationen kann die Transformation zwar den Kontroll�uss nach BPEL abbilden, jedochkönnen die benötigten Werte, die in BPEL mit <required> gekennzeichnet sind, nicht vollständigausgefüllt werden und müssten dann deshalb mit DUMMY-Werten erzeugt werden. Zum Beispielmüssen die Angaben für die <portType>- oder <operation>-De�nition angegeben werden, umauf einen Web Service zugreifen zu können. Des Weiteren dürfen im EPK-Diagramm keine zweigleichnamige Elemente vorkommen, da die Generierung der Links sonst nicht eindeutig sein wird.Dies gilt ebenfalls für die Konnektoren.

5.4.2.1 Abbildung des <epc>-Elementes auf <process>-BPEL-Element

In einem EPK-Diagramm und einem BPEL-Prozess werden übergeordnete Elemente, wie <epc> und<process> de�niert, die alle weiteren Elemente in dem betrachteten Geschäftsprozess tragen. Das<epc>-Element im EPML-Format wird grundsätzlich auf ein <process>-Element abgebildet. Dasheiÿt in diesem Fall, dass für jede EPK immer ein neues BPEL-Prozess erzeugt wird. Werden in einerEPML-Datei gleichzeitig mehrere EPK modelliert, so werden aus dieser Datei gleichzeitig mehrereBPEL-Prozesse generiert. In Kapitel 6.3.1 wird gezeigt, wie der erzeugte Rumpf nach der Erzeugungaussehen wird.

5.4.2.2 Abbildung der Konnektoren

Wie man der Tabelle 5.4 entnehmen kann und im Abschnitt 5.4.1 erläutert wurde, werden dieKonnektoren auf eine <empty>-Aktivität abgebildet, da die EPK-Konnektoren in BPEL keine expliziteEntsprechung besitzen. Die damit verbundenen Verzweigungen und Synchronisationen werden in demnächsten Abschnitt zusammen mit den Kanten ausführlich behandelt.

5.4.2.3 Abbildung der Kanten

In Abschnitt 2.7.1 wurde die graphen-theoretische Charakterisierung der EPK und in Abschnitt 5.3.3die gleiche Charakteristik für BPEL eingeführt. Für die Realisierung der graph-ähnlichen Struktur wirddie <flow>-Aktivität verwendet. Dieses Vorgehen erfordert, dass alle weiteren BPEL-Elemente in ein<flow>-Element platziert werden müssen. Die eingehenden und die ausgehenden EPK-Kanten, dieim EPML-Format über die arcs beschrieben werden, werden auf die Links abgebildet. Jedoch werdendie Namen der EPK-Kanten selbst nicht direkt auf die Link-De�nitionen abgebildet, da diese keineNamen de�nieren, sondern nur ihre ID tragen. Diese werden intern für die Bestimmung der Knotenam sourceund am target-Attribut benutzt, um die Namen der Elemente mit der dazu gehörigen


ID zu bestimmen. Aus den Namen dieser Elemente, die diese Kante verbindet, wird anschlieÿend einLink namens Source-EPK-Element_TO_Target-EPK-Element erzeugt.

In BPEL werden die Links zwischen zwei elementaren oder strukturierten Aktivitäten de�niert, umdie Reihenfolge der Ausführung festzulegen. Dieser Link muss gleichzeitig der Source-Aktivität als<source>-Link und als <target>-Link der Target-Aktivität hinzugefügt werden, wie es im Kapitel4 gezeigt wurde. Des Weiteren muss eine De�nition des erzeugten Links in der Links-De�nition im<flow>-Aktivität hinzugefügt werden. Die Übergangsbedingungen (transition conditions) werden beiden ausgehenden Links bei Verzweigungen dem <source>-Link zugeordnet. Die Bedingung an denLinks werden als XPath-Ausdruck de�niert. Nach der Ausführung einer Aktivität wird jede Bedingungvon ausgehenden Links geprüft. Wenn keine Bedingung de�niert ist, und die Aktivität normal beendetworden ist, so wird die nächste Aktivität ausgeführt.

Während der Kontroll�uss in BPEL über die Links gesteuert wird, wird dieser in EPK über dieinneren Ereignisse realisiert. Um das gleiche Verhalten in BPEL beim Übergang von EPK nachBPEL nachzubilden, muss der XPath-Ausdruck als Annotation dem inneren Ereignis-Element, wiees im nächsten Listing zu sehen ist, zugeordnet werden. Bei Verzweigungen in EPK müssen dieAnnotationen an den Ereignissen nur bei OR- und XOR-Splits der Form FuntionOREvents undFuntionXOREvents gesetzt werden, wie es in der Abbildung 5.4 gezeigt wurde. Für die AND-Splitsder Form (FunktionANDEvents) müssen an den Ereignissen keine Annotationen gesetzt werden (sieheAbbildung 5.3), da ein AND-Split hier einen Parallel-Split beschreibt, wo grundsätzlich alle Zweigeausgeführt werden. An dieser Stelle wurde auf die inneren Ereignisse schon vorgegri�en. Eine genauereUntersuchung der Ereignisse folgt im nächsten Abschnitt.

1 <event id="17">2 <name>KreditkartenZahlungGewaehlt</name>3 <description>KreditkartenZahlungGewaehlt</description>4 <attribute typeRef="xpathExpression"5 value="bpws:getVariableData(6 ’selectPaymentResponse’,7 ’selectPaymentResponsePart’,8 ’/pay:selectPaymentResponseType/pay:selectPaymentReturn’)=’Kreditkarte’"/>9 </event>

Beim Synchronisieren von eingehenden EPK-Kanten müssen Synchronisationsbedingungen an denAktivitäten eingehender Links in BPEL gesetzt werden. Der Parameter joinCondition, der in jederBPEL-Aktivität vorkommen kann, muss aus allen eingehenden Link-Namen zu einem booleschenAusdruck zusammengesetzt werden. Es wird der Name der eingehenden Links bestimmt und derBPEL-Funktion getLinkStatus als Parameter übergeben. Diese Funktion liefert einen booleschenWert true zurück, wenn der Status des Link aktiviert ist, ansonsten false. Da in BPEL standardmäÿigdie Join-Condition auf OR gesetzt ist, müssen nur die XOR-Joins und AND-Joins implementiertwerden. Zu beachten ist, dass BPEL kein XOR-Join direkt unterstützt. Das nächste Beispiel stelltvor, wie die eingehenden Kanten im EPK-Diagramm an einem XOR-Joins im joinCondition-Ausdruckaussehen können.

1 ((bpws:getLinkStatus(’linkName1’)) xor (bpws:getLinkStatus(’linkName2’)))

Dieser Ausdruck würde in einer BPEL-Engine einen Fehler melden, deshalb muss dieser Ausdruckin AND und OR transformiert werden. Der dazu äquivalente boolesche Ausdruck für zwei eingehendeLinks ist im nächsten Listing zu sehen. Für mehr eingehende Links muss die Umformung entsprechenddurchgeführt werden.

1 ((bpws:getLinkStatus(’linkName1’)) and not (bpws:getLinkStatus(’linkName2’)))2 or3 (not (bpws:getLinkStatus(’linkName1’)) and (bpws:getLinkStatus(’linkName2’)))

Zwar wächst die De�nition der joinCodition-Bedingung mit der Anzahl der Links zu. Da dieseaber algorithmisch erzeugt werden, kann dieses problemlos vernachlässigt werden.


5.4.2.4 Abbildung der Ereignisse

In Abschnitt 5.2.4 wurde darauf hingewiesen, dass ein BPEL-Prozess wiederum als ein Web Servicezum Beispiel in einem übergeordneten BPEL-Prozess, also dem Client, zur Verfügung gestellt werdenkann. Um dies zu gewährleisten, muss der untergeordnete BPEL-Prozess, der als Web Service auf-tritt, mit einer <receive>-Aktivität beginnen. Dabei schreibt die BPEL-Spezi�kation22 vor, dass esnur diesen einzigen Weg gibt, einen Geschäftsprozess in BPEL zu instantiieren, indem das AttributcreateInstance auf den booleschen Wert yes gesetzt wird. Die <receive>-Aktivität enthält nur eineeinzige Input-Variable, die von dem übergeordneten BPEL-Prozess durch eine <invoke>-Aktivitätbelegt wird. Wenn ein Prozess durch eine Receive-Aktivität instantiiert wird, werden die erhaltenenDaten in einer Variable, die den MessageType des Variable trägt de�niert. In EPK kann solcher Fallauf zwei verschiedene Arten modelliert werden. Man verwendet hierfür entweder einen Start-Ereignis,der implizit auf eine <receive>-Aktivität abgebildet wird oder man modelliert hierfür explizit eineEPK-Funktion, die die Aufgabe einer <receive>-Aktivität ausführen soll. Da EPK-Diagramme aufder betrieblichen Seite in der Vergangenheit nicht im Hinblick auf eine SOA-Architektur entworfenworden sind, d.h. dass in fachlichen Modellen keine explizite De�nition für eine Receive-Aktivitätde�niert worden ist, muss auf der BPEL-Seite ein <receive>-Element aus dem Start-Ereignis er-zeugt werden. Aus diesem Grund wird bevorzugt, dass ein Start-Ereignis grundsätzlich immer aufeine <receive>-Aktivität abgebildet wird.

Wie in der Abbildung 5.1 dargestellt, so beginnt das durch funktionale Dekomposition entstan-dene EPK-Diagramm mit einem Start-Ereignis und endet mit einem End-Ereignis. Diese Ereignissemüssen bei der Dekomposition vom übergeordneten EPK übernommen werden und tragen deshalbderen Namen. Da diese Ereignisse sowohl in der übergeordneten EPK als auch in der durch diefunktionale Verfeinerung entstandene EPK vorkommen, müssen diese in beiden <epc>-Elementende�niert werden. Jedoch dürfen diese keine gleiche Annotationen tragen. Ein End-Ereignis in EPKwird dementsprechend auf eine <reply>-Aktivität in BPEL abgebildet, um den synchronen Aufrufder <invoke>-Aktivität vom Client beantworten zu können. Das heiÿt in diesem Fall, dass nur syn-chrone Web Services betrachtet worden sind. Da hier als Beispiel nur �ache Hierarchien betrachtetwerden, wird die Variable vom Client, der als Web Service auftritt, belegt.

Sollte der Fall eintreten, dass eine <receive> oder eine <reply>-Aktivität innerhalb eines BPEL-Prozesses explizit benötigt wird, so kann diese Aktivität durch das Setzen des <functionType>-Attributes explizit erzeugt werden, wie es im Unterabschnitt 5.4.2.5 erläutert wird. Es ist jedochauch möglich eine Reply-Aktivität durch eine <invoke>-Aktivität nachzubilden. Hier weist [DJM05]ausdrücklich darauf hin, dass wenn die Output-Variable in der <invoke>-Aktivität ausgelassen wird,somit ein asynchroner Aufruf des Web Service nachgebildet werden kann. Ein asynchroner Aufruferwartet dabei keine Antwort vom Web Service. Für synchrone Aufrufe wird dagegen eine Output-Variable benötigt, die den Aufruf abschlieÿt und das gelieferte Ergebnis dem Rückgabewert zuweist.

5.4.2.5 Abbildung der EPK-Funktionen auf BPEL-Aktivitäten

Die Granularität der betrachteten Geschäftsprozesse ist für die Anbindung der Web Services vongroÿer Bedeutung. Der Detaillierungsgrad der Geschäftsprozesse wird häu�g anhand der zu verarbei-tenden Geschäftsobjekte durchgeführt. So soll einer fachlichen EPK-Funktion ein Web Service, dereine bestimmte Aufgabe ausführt, zugeordnet werden und hinsichtlich der technischen Unterstützungaus der importierten WSDL-Beschreibung annotiert werden. Deshalb sollte der Detaillierungsgradvon den zu verschickenden Nachrichten abgeleitet werden. Das heiÿt, dass der Detaillierungsgrad der

22Vgl. [ACD+03] Die allererste Aktivität eines BPEL4WS-Prozesses muss eine receive-Aktivität sein. Die Aktivitätreceive ist eine blockierende Aktivität, das heiÿt, sie wartet, bis sie als Web Service über ein ankommendeSOAP-Nachricht aufgerufen wird.


zu verarbeitenden Geschäftsobjekte also von den Part-De�nitionen der Message-De�nition abhän-gig gemacht werden soll. Die Transformation betrachtet zunächst die Funktionen als automatischeFunktionen23. Der Grund hierfür ist, dass BPEL nur vollautomatische Operationen unterstützt, dievon einem Web Service ausgeführt werden sollen.

Aufgrund der vorhandenen 1-zu-M-Beziehung zwischen der EPK-Funktion und der BPEL-Aktivitätsollen die Funktionen in BPEL durch elementare Aktivitäten dargestellt werden. Das bedeutet, dassfür die elementaren BPEL-Aktivitäten in EPK keine explizite Entsprechung existiert, daher wird hierfürebenfalls die EPK-Funktion verwendet. Hauptsächlich wird die Abbildung von EPK-Funktionen zu<receive>-, <invoke>- und <reply>-Aktivitäten betrachtet, da diese den meisten Aufwand in derImplementierung verursachen. In [MZ05] wird vorgeschlagen den Funktionstyp der BPEL-Aktivitätenanhand der Labels in EPK-Funktionen zu schreiben und bei Aktivitäten, die mit dem Web Servicein Verbindung stehen noch anschlieÿend eine Operation anzugeben. An dieser Stelle wird jedoch einanderer Ansatz verfolgt, der im Folgenden näher erläutert wird.

Es wurde entschieden, dass der Business Analyst wie gewohnt EPK-Diagramme modellieren soll.Kommt er zu dem Punkt, an dem entschieden werden muss, welchen Typ die jeweilige Funktion tragensoll, so kann der Modellierer oder der Entwickler die EPK-Funktion auswählen und den gewünschtenFunktionstyp zum Beispiel in einer GUI festlegen. Um die benötigte Menge der BPEL-Aktivitätstypenunterstützen und erkennen zu können, um welche BPEL-Aktivität es sich handeln soll, wird hierfürin einer EPML-Instanz eine Annotation in Form des expliziten Typen der BPEL-Aktivität, wie imnächsten Listing zu sehen, benötigt.

1 <function id="positiveInteger">2 <name>AirlineReservieren</name>3 ...4 <toProcess linkToEpcId="positiveInteger">5 <attribute typeRef="functionType"6 value="invoke |receive | reply | wait | terminate | assign | user"7 </function>

So wird für jede elementare BPEL-Aktivität ein expliziter Typ in <functionType> gesetzt, umdaraus anschlieÿend eine entsprechende Aktivität zu erzeugen. Durch das Setzen des Attributes wirdder Typ der zu generierenden BPEL-Aktivität eindeutig festgelegt. In [GL06] wird zwar gesagt, dassfür die Validierung des EPK-Diagramms ein solches Attribut nicht notwendig ist und darauf verzichtetwerden kann, für die Bestimmung des verwendeten EPK-Funktionstypen bei einer 1-zu-N-Beziehungzu BPEL-Aktivitäten im Transformationsprozess ist diese Abfragemöglichkeit unbedingt erforderlich,da sonst die Eigenschaft der EPK-Funktion an deren Namen nicht eindeutig bestimmt werden kann.

Wurde zum Beispiel eines der folgenden drei Attribute <invoke>, <receive> und <reply>

zugeordnet, so ist das Ziel diesen EPK-Funktionen jeweils eine WSDL-Operation mit einem Inputund einem Output-Parametern zuzuordnen. In diesem Fall bedeutet es, dass hierfür die drei WebService-Aktivitäten verwendet werden sollen. In Abschnitt 4.3 wurde darauf hingewiesen, das diesedrei Aktivitäten zum Aufruf eines Web Services verwendet werden. Diese de�nieren die gleichen vierAttribute name, partnerLink, portType und operation und unterscheiden sich nur an der Eigenschaftder verwendeten Variablen. Es werden entweder ein oder zwei Attribute für die De�nition der Variablenverwendet, die abhängig von der Aktivität de�niert werden; z.B.: inputVariable und outputVariablefür <invoke>, variable für <receive>, die eine Input-Variable darstellt und variable für <reply>,die eine Output-Variable darstellt.

Für die Unterstützung der Web Services und der Identi�kation der benötigten Operation müssenhierfür der verwendete PortType und die aufzurufende Operation angegeben werden. Die Zuordnung

23Vgl. [Ste06] �Da z. B. BPEL kein Konstrukt für manuelle Tätigkeiten enthält, können nur solche EPKs nach BPELtransformiert werden, die nur noch automatisierte Prozessschritte enthalten.�


dieser beiden Attribute erfolgt dabei über eine Relationsbeziehung mit einer Anwendungskomponen-te24, die einer EPK-Funktion als Annotation hinzugefügt werden muss. Im EPML-Format wird hierfürdas <application>-Element25 verwendet, auf welches im Folgenden näher eingegangen wird. Dervorhandene Kantentyp �unterstützt�, der in EPML über die <relation>-Beziehung beschriebenwird, kann somit zwischen der EPK-Funktion und der Anwendungskomponente weiter benutzt wer-den, um die fachliche Funktion durch ein Web Service automatisiert ablaufen zu lassen. Die gra�scheDarstellung des Symboltyps der Anwendungskomponente ist ein Rechteck mit dreifachen, vertikalenSeitenlinien.

Die Annotationen am <application>-Element werden, wie in dem nächsten Listing dargestellt,vorgenommen. Hierfür ist es erforderlich, dass folgende drei <attribute>-Elemente hinzugefügtwerden.

1 <epml>2 <attributeTypes>3 <attributeType typeId="wsdl">4 <attributeType typeId="portName">5 <attributeType typeId="operationName">6 </attributeTypes>7 ...8 <epc>9 <function/>

10 <arcs/>11 <application id="positiveInteger">12 <name> ... </name>13 <description> ... </description>14 <attribute typeRef="wsdl" value="URL"15 <attribute typeRef="portName" value="AirlineWS"16 <attribute typeRef="operationName" value="getFlights"17 </application>18 <relation id="..." from="..." to="...">19 </epc>20 </epml>

Da der an die Funktion angeschlossene Web Service eine 1-zu-1 Beziehung zwischen der Service-De�nition und die Service-De�nition wiederum eine 1-zu-N-Beziehung zu der PortTypes-De�nition inder dazu gehörigen WSDL-Beschreibung aufweist, wird angestrebt jedem <application>-Elementeine auszuführende Operation an einem festgelegten PortType zu spezi�zieren. Das heiÿt in diesemFall, dass jedem <application>-Element der Name von genau einem PortType und genau einerOperation zugeordnet werden muss.

Daher gibt das erste hinzugefügte <attribute>-Element die URL der WSDL-Datei an. Überdie angegebene URL wird die dazu entsprechende WSDL-Datei aufgerufen und die notwendigenInformationen werden heraus gelesen und zum erzeugenden BPEL-Prozess hinzugefügt. Die zweiteAnnotation stellt der Name des verwendeten PortTypes und die dritte der Name der aufzurufen-den Operation dar. So wird die eindeutige Identi�kation des Web Service-Aufrufs anhand der zweiAttributen portName und operationName realisiert.

Der Vorteil bei diesem Vorgehen liegt hier darin, dass bei vorhandenen EPK-Modellen die Zuord-nung der Services einfacher durchgeführt werden kann, und eine eindeutige Trennung zwischen denfachlichen Modellen und der Anbindung an die Web Services bestehen bleibt. So ist es vorstellbarSichten zu de�nieren, die die Anbindung an die Web Services auszublenden. Ein weiterer Grund fürdiese Entscheidung ist, dass der entsprechende Aufruf des WSDL-Pfades, des PortTypes und der

24Vgl. [WGL05] Für die Unterstützung der Web Service-Funktionalität wird der Typ der Anwendungskomponentevorgeschlagen, der schon dem EPK-Modelltyp zugeordnet ist.

25Vgl. [Sem] Das EPK-Modellierungstool SemTalk2 von Semtation GmbH verwendet hierfür das neu erstellte <ser-vice>-Element, um die Anbindung an die Web Services zu beschreiben. Zwar setzt SemTalk2 ebenfalls das EPML-Austauschformat in der Version 1.11 ein, so enthält die ö�entlich zur Verfügung gestellte Version auf www.epml.denicht das oben genannte Element. Somit wurde von der Semtation GmbH das EPML-Format um dieses Elementerweitert, obwohl es eigentlich nicht notwendig war.


Operationen in der besseren Austauschbarkeit der Web Services begründet ist. So kann das <appli-cation>-Element leichter durch eine andere Anwendungskomponente ausgetauscht werden. WeitereÄnderungen sind hierfür nicht mehr erforderlich. Würde man die Zuordnung der erforderlichen Pa-rameter, wie es in [Int06] vorgeschlagen wurde, dem Funktion-Element annotieren, so hat solchesVorgehen folgende Nachteile. Jede Änderung eines Web Services, führt immer dazu, dass die Para-meter im <function>-Element aktualisiert werden müssen. Des Weiteren kann die gleiche Funktionnicht mehr im selben EPK-Modell weiter verwendet werden, da hierfür eine eindeutige Zuordnungzu einem Web Service erfolgt ist. Bei dem hier vorgestellten Ansatz ist dieses nicht zu befürchten.Denn es muss nur die Relation auf einen anderen Web Service geändert werden.

Die Angabe des verwendeten MessageTypes ist als Annotation nicht erforderlich, da diese De�ni-tionen, algorithmisch aus der importierten WSDL-Beschreibung anhand der angegebenen Parameterbestimmt werden können. Dadurch, dass jede WSDL-Operation nur eine Input- und ggf. eine Output-MessageType-De�nition enthält, kann die Identi�kation leicht durchgeführt werden. Hier wird nurvorausgesetzt, dass der Name der Input- und Output-Nachricht in der der WSDL-MessageType-Beschreibung gesetzt wird, da dieses sehr häu�g ausgelassen wird. An dieser Stelle wird im Abschnitt5.4.2.8 fortgesetzt. Die Angabe der Annotationen für den partnerLink ist ebenfalls nicht erforderlich,da die <partnerLinks> und die Erzeugung der De�nitionen der <partnerLinksType> aus demNamen des PortTypes aus dem neu hinzugefügten <application>-Element abgeleitet wird. Hierfürwird der PortType-Name bestimmt und die De�nitionen erzeugt. (Näheres im Abschnitt 5.4.2.7).

Mit den hier vorgestellten Annotationen ist es möglich die folgenden Attribute der Web Service-Aktivitäten eindeutig festzulegen. Des Weiteren müssen nur noch die EPK-Datenobjekte den hier fest-gelegten MessageType-Variablen richtig zugeordnet werden. Für die Receive und die Reply-Aktivitätmüssen dementsprechend nur eine Variable gesetzt werden. Die Zuordnung der Informationsobjektewird in dem Unterabschnitt 5.4.2.8 ausführlich behandelt.

1 <bpws:invoke2 name="PruefeHotels"3 operation="getHotel"4 portType="hot:HotelWS"5 partnerLink="Hotel-WS-PL"6 inputVariable="getHotelRequest"7 outputVariable="getHotelResponse"8 >9 <bpws:target linkName="..."/>

10 <bpws:source linkName="..."/>11 </bpws:invoke>

Wird eine <receive>- oder eine <reply>-Aktivität innerhalb eines Geschäftsprozesses explizitbenötigt, so kann der Typ der gewünschten Aktivität gesetzt werden. Wurde vom Modellierer für func-tionType der Wert <assign> de�niert, so wird daraus explizit eine <assign>-Aktivität generiert.Diese kann zum Beispiel für zusätzliche Manipulationen verwendet werden. Die <assign>-Aktivitätwird im Zusammenhang mit den Variablen speziell in dem Unterabschnitt 5.4.2.8 behandelt. Jedochwird in dieser Arbeit ein Konzept vorgestellt, welches erlaubt, auf das explizite Setzen des <assign>-functionType zu verzichten. Wurden zum Beispiel im EPK-Modell Funktionen verwendet, die in BPELkeine Entsprechung haben, so können diese zunächst auf eine <empty>-Aktivität abgebildet werden,um den fortlaufenden Kontroll�uss in BPEL nicht zu unterbrechen. Diese können anschlieÿend vomEntwickler durch andere Aktivitäten ersetzt werden. Weiterhin können zwei weitere elementare Ak-tivitäten, wie <wait> und <terminate> erzeugt werden, indem ihr functionType-Attribut gesetztwird.

Zusammenfassend kann die Anbindung an den Web Service schon durch das Setzen der Re-lationsbeziehung realisiert werden. Eine Zuordnung der EPK-Funktionen an die Operation erlaubtwiederum bei der Wiederverwendung dieser Funktion in anderen EPK-Prozessen, eine sofortige ein-deutige Identi�kation der verwendeten Operation, die von der BPEL-Aktivität ausgeführt werdensoll. Bezüglich der Annotationen der Funktionen wird davon ausgegangen, dass der Modellierer allen


EPK-Funktionen den expliziten Typ der BPEL-Aktivität an der EPK-Funktion über das AttributefunctionType gesetzt hat.

5.4.2.6 Integration von Benutzer-Interaktionen in den Transformationsprozess

BPEL ist eine Kompositionssprache, die für die Integration mehrerer Web Services benutzt wird,wobei im Zusammenhang mit BPEL immer mit den automatisierten Aktivitäten gesprochen wird.Bei den betrieblichen Geschäftsprozessen spielen jedoch sehr oft die Menschen und die manuelleAusführung26 von Aufgaben eine besondere Rolle. Aus diesem Grund ist es erforderlich, dass inBPEL Benutzerinteraktionen unterstützt werden.

Um Benutzeraktionen in BPEL integrieren zu können, wurde von IBM eine Erweiterung BPEL4-People [KKL+05] vorgestellt. Das hier vorgestellte Konzept erweist sich jedoch noch nicht vollständigausgereift. Des Weiteren hat Oracle in [Ora06] erläutert, wie ein TaskManager Service in einen BPEL-Prozess integriert werden kann. Da eine solche Integration in BPEL mit der Erzeugung der hierfürnotwendigen Benutzer-Schnittstellen verbunden ist, kann dieser Punkt in der vorliegenden Arbeitnicht ausführlich behandelt werden, da diese den Rahmen der Arbeit sprengen würde. Parallel zudieser Arbeit ist am Institut für Praktische Informatik an der Leibniz Universität Hannover eine Mas-terarbeit zum Thema Konzept und Implementierung von Benutzer-Schnittstellen in BPEL-Prozessen[Gut07] entstanden, dadurch konnte leider im Verlauf dieser Ausarbeitung nicht auf das vorgeschla-gene Konzept zurückgegri�en werden.

Abbildung 5.5: Anbindung an manuelle Tasks mittels des Oracle TaskManager Services, nach [Ora06]

Es wird aber im Folgenden das allgemeine Konzept der Integration von Benutzer-Interaktionen er-läutert und gezeigt, welche BPEL-Aktivitäten erzeugt werden müssen, um eine manuelle Ausführungvon Tätigkeiten durch Menschen in BPEL zu erlauben. Daher basiert das hier vorgestellte Konzeptder Einbindung auf dem von Oracle verö�entlichten Tutorial. Der TaskManager ist ein asynchronerWeb Service, der den Lebenszyklus einer manuellen Tätigkeit verwaltet. Des Weiteren bietet dieserWeb Service eine Vielzahl weiterer nützlicher Operationen an, um den betrachteten Task zu behan-deln. Die Operation initiateTask, die den TaskManager aufruft, muss an den TaskManager-Service

26Vgl. [Ste06] Hier wird ausdrücklich darauf hingewiesen, dass nur automatisierte Prozessschritte von EPK nach BPELtransformiert werden können.


sowohl spezi�sche Parameter als auch die zu verarbeitenden Daten übertragen. Sollten weitere Eigen-schaften, wie die Art der auszuführenden Aufgabe an den Web Service geschickt werden, so könnenhierfür zusätzliche Parts hinzugefügt werden, die die erforderlichen Parameter abdecken. Eine derAufgaben kann zum Beispiel die Auswahl eines bestimmten Elementes sein. Für die Erzeugung vonGUIs bietet Oracle eine Java Worklist API an, die dem Entwickler erlauben Benutzer-Schnittstellenzu erzeugen. Oder man greift auf das von Gutbier vorgestellte Konzept zurück. Auf die Einzelheitendes TaskManagers wird an dieser Stelle nicht mehr eingegangen und auf [Ora06] verwiesen.

Eine mit <user> annotierte EPK-Funktion wird zunächst auf eine <invoke>-Aktivität, die einenasynchronen Aufruf durchführt, abgebildet. Wird der initialisierte Task vom Menschen erfolgreich be-endet, so wird an den BPEL-Prozess eine Antwort über eine Operation gesendet, die die notwendigenParameter von dem Benutzer enthält. Daher muss nach der <invoke>-Aktivität automatisch eineweitere <receive>-Aktivität hinzugefügt werden, die die Antwort vom TaskManager Service erhält.Dieser Zusammenhang ist in der Abbildung 5.5 gra�sch dargestellt.

Um von dem Oracle-Task-Manager nicht abhängig zu sein, wird in das betrachtete EPK-Diagrammnicht der TaskManager von Oracle eingebunden, obwohl es möglich gewesen wäre. Es wird für dieIntegration von Benutzerinteraktionen nur gezeigt, welche Abfolge von BPEL-Aktivität erforderlichist, um überhaupt einen Aufruf eines Task-Managers zu erlauben. Da hier nicht der TaskMana-ger eingebunden wird, wird anstelle von der Funktion initiateTask für Vorführungszwecke und zurVereinfachung des Beispieles eine andere Funktion namens selectFlight, selectHotel oder auch select-Payment benutzt, die im jeweiligen angebundenen Web Service AirlineWs, HotelWS und PaymentWSde�niert wird. Diese Funktionen sollen die manuelle Auswahl eines Benutzers nachbilden. Dazu wirdin Kapitel 6 ein Geschäftsprozess als Beispiel ausführlich vorgeführt. Da es sich um einen asynchro-nen Aufruf eines Web Services handelt, müssen für die vollständige Funktionsweise zwei weitereAttribute callbackPortName und callbackOperationName de�niert werden, um festlegen zu können,an welchem Port welche Operation als Antwort erwartet wird. In diesem Fall bedeutet es, dass dieOperation, die durch den Attributen operationName beschrieben ist, der Operation initiateTask imTaskManager entspricht. Die Operation callbackOperationName entspricht dann der antwortendenOperation OnTaskResult.

1 <application id="34">2 <name>Payment-WS</name>3 <attribute typeRef="wsdl" value="PaymentWS.wsdl"/>4 <attribute typeRef="portName" value="PaymentWS"/>5 <attribute typeRef="operationName" value="selectPayment"/>6 <attribute typeRef="callbackPortName" value="PaymentWS"/>7 <attribute typeRef="callbackOperationName" value="selectPaymentResponse"/>8 </application>

Zusammenfassend bedeutet es, dass aus einer einzigen EPK-Funktion, die als benutzer-de�nierteFunktion durch das Setzen des <user>-functionTypes deklariert worden ist, eine asynchrone Invoke-Aktivität mit der nachfolgenden Receive-Aktivität erzeugt werden muss.

5.4.2.7 Erzeugung von PartnerLinks und PartnerLinkTypes-De�nitionen

Es existieren Web Service-Beschreibungen, die keine De�nitionen zu PartnerLinkTypes anbieten. Ausdiesem Grund muss anhand der angebundenen WSDL-Beschreibung die PartnerLinkTypes-De�nitionselbst erzeugt werden. Es ist sehr wichtig zu verstehen, dass der PartnerLinkType kein Teil einesBPEL-Prozesses darstellt. Der Grund liegt darin, dass diese zu der Service-Spezi�kation und nicht zuder Prozess-Spezi�kation gehören. Daher müssen die PartnerLinkTypes-De�nitionen in dem WSDL-Dokument des betrachteten Web Service oder in einem neuen WSDL-Dokument platziert werden.Des Weiteren gibt es WSDL-Beschreibungen, die schon PartnerLinkTypes de�nieren. Da für dieErzeugung der PartnerLinks in BPEL die beiden Attribute myRole und partnerRole gesetzt werdenmüssen, müssen entweder die vorhandenen De�nitionen eingelesen oder neu erzeugt werden. Um

nicht den doppelten Weg in der Implementierung zu gehen, wurde entschieden grundsätzlich neuePartnerLinkTypes zu de�nieren und diese in der neu erstellten WSDL-Beschreibung, abzulegen. Dasimportierte WSDL-Dokument wird dafür in ein neues WSDL-Dokument importiert und anschlieÿendwird im Transformationsprozess die De�nition der PartnerLinkTypes erzeugt. So wird für jeden WebService eine eigene WSDL-Beschreibung erzeugt, die diese De�nition enthält und die alte WSDL-Datei in die neue importiert.

Die Erzeugung der PartnerLinks mit allen dazugehörigen Attributen, wie der Name des partner-Links, der Rollen (myRole und partnerRole) und der De�nition des partnerLinkType, wird über dasneu eingefügte EPML-Element <application> realisiert, d.h. diese De�nitionen werden aus demNamen des PortTypes aus der Annotation der Anwendungskomponente abgeleitet. Die De�nition derPartnerLinks wird nach dem folgenden Beispiel realisiert und in Kapitel 6.3.3 im Beispiel gezeigt.

1 <portTypeName>-PL 2 <portTypeName>-PLT 3 <portTypeName>-Requester 4 <portTypeName>-Provider 

5.4.2.8 Abbildung der Informationsobjekte

Nachdem die Zuordnung der Web Services zu den einzelnen Funktionen erfolgt ist, muss anschlieÿendder Daten�uss innerhalb der EPK-Informationsobjekten betrachtet werden. An dieser Stelle muss ei-ne entscheidende Frage bezüglich des Datentransfers beantwortet werden. Wie werden die einzelnenDaten von einem Web Service zu einem anderen Web Service weitergeleitet? Um entscheiden zukönnen, wie auf die Daten zugegri�en werden soll, müssen zunächst die De�nitionen der Daten undder beiden Datenzugri�smodelle, die in [ACKM04] im Zusammenhang mit Web Services eingeführtwerden, vorgestellt werden. An dieser Stelle wird explizit noch von Daten gesprochen, die noch kei-nem bestimmten Typen zugeordnet worden sind. Die in einem Geschäftsprozess verwendeten Datenwerden in zwei Kategorien, in anwendungsspezi�sche und den Kontroll�uss betre�ende Daten un-terschieden. Die anwendungsspezi�schen Daten sind Parameter, die zwischen zwei Partnern in Formeines Parts einer Nachricht ausgetauscht werden können. Die kontroll�uss-basierten Daten werdenfür die Verzweigungen benötigt. Diese werden als Transitionsbedingungen an die Kanten angehängtund ausgewertet. Die Engine entscheidet dann anhand dieser Transitionen, wie das betrachtete Ge-schäftsprozess ausgeführt werden soll, und welcher Zweig bei der Abarbeitung gewählt werden soll.Die anwendungspezi�schen Daten sind häu�g komplex und schlieÿen in sich mehrere Datentypen ein.Die kontroll�uss-basierten Daten sind dagegen nur auf einfache Datentypen wie String, Integer usw.beschränkt.

Der Austausch von Daten, der durch eine Operation ausgelöst und zu der anderen weiterge-leitet wird, beschreibt in diesem Fall das Datentransfermodell. Hier wird zwischen dem expliziten

Daten�uss und dem Blackboard-Ansatz unterschieden.

Beim ersteren Ansatz wird zusätzlich zu dem Kontroll�uss noch explizit der Daten�uss zwischenden Aktivitäten mit Hilfe der Daten�usskanten de�niert. Das heiÿt, dass der Daten�uss explizit aneine bestimmte Aktivität als Input von der davor ausgeführten Aktivität weitergegeben wird. Die-sen Zusammenhang stellt die Abbildung 5.6 ausführlich dar. WSFL als Kompositionssprache hatunabhängig von Kontroll�usskanten <controlLink> für den Daten�uss die Daten�usskanten <da-

taLinks> benutzt. Eine Daten�usskante de�nierte eine Source- und eine Target-Variable zusammenmit den WSDL-Nachrichten <sourceMessage> und <targetMessage>. Obwohl in dieser Arbeitfür die Darstellung von BPEL-Prozessen die WSFL-basierte Darstellung benutzt wird, so wurdendurch die Vereinigung von XLANG und WSFL aus BPEL die explizite De�nition der Daten�uss-kanten entfernt, d. h., dass BPEL diese Möglichkeit nicht mehr unterstützt. Dieser Ansatz ist zwar�exibler als der Blackboard-Ansatz, birgt aber auch einige Nachteile, die der Modellierer unbedingt


einhalten muss. So muss bei diesem Ansatz folgendes beachtet werden. Die Aktivitäten, die Ausga-ben liefern sollen, müssen vorher im Kontroll�uss beendet worden sein, um die benötigten Ausgabenals Eingabe-Parameter der nächst folgenden Aktivität zu übergeben. Daher muss an dieser Stelle derzweite Ansatz des Daten�usses genauer untersucht werden.

Abbildung 5.6: De�nition des expliziten Daten�usses

Beim zweiten Ansatz wird der Daten�uss über die gleichnamigen Variablennamen weiter gereicht.BPEL verwendet den Blackboard-Ansatz und wird deshalb an dieser Stelle näher erläutert. Manverwendet das so genannte schwarze Brett, auf welches alle Variablen, die in den BPEL-Prozessinvolviert sind, abgelegt werden. Benötigt ein Web Service eine bestimmte Input-Variable, so beziehtdieser die benötigten Daten vom schwarten Brett. In BPEL werden die drei Aktivitäten <invoke>,

<receive> und <reply> in Zusammenhang mit Variablen verwendet; sie lesen aus Eingabevariablenund schreiben die verarbeitenden Daten in Ausgabevariablen. Zwei Invoke-Aktivitäten werden durchdie Verwendung des gleichnamigen Variablennamen miteinander verbunden. Die Output-Variable ei-ner im BPEL-Prozess vorher ausgeführten Invoke-Aktivität wird als Input-Variable von einer anderenInvoke-Aktivität aufgerufen. Eine einzige Voraussetzung dafür ist, dass die nächste Invoke-Aktivitätweiter unten im BPEL-Prozess de�niert werden muss, da der Daten�uss von oben nach oben abge-arbeitet wird. Wenn die Variablen nicht ausgetauscht werden können, da die beiden Variablen andereNamen tragen oder verschiedene Inhalte benötigen, so muss eine Assign-Aktivität erzeugt werden,die den Inhalt von der Source-Variable zu der Target-Variable kopiert. Zu Beginn der BPEL-Instanzsind die Variablen nicht instantiiert und müssen durch Assignments mit Hilfe von XPath instantiiertwerden. Bei diesem Ansatz handelt es sich um ein Verfahren, welches man von Programmiersprachenher kennt. Der Nachteil vom Blackboard-Ansatz ist, dass die Anzahl der spezi�schen Daten sehrgross und komplex sein kann, da hierfür eine groÿe Menge an Datentypen de�niert werden muss.

Daten�uss in EPK - Die EPK-Diagramme geben den Daten�uss ebenfalls nicht explizit an,da die Kanten sowohl für den Kontroll�uss als auch für den Daten�uss zugleich verwendet werden.Deshalb werden hier die Eingabe- und Ausgabevariablen anhand der gleichnamigen De�nitionen anden Informationsobjekten erkannt. Viele Modellierer benutzen in diesem Zusammenhang ebenfallsdie Links, um zu verdeutlichen von wo und wohin die Ausgabe-Variablen kopiert werden sollen.Diese Vorgehensweise entspricht jedoch nicht der EPK-Semantik. Liefert zum Beispiel eine Ausgabe-Informationseinheit ein bestimmtes Ergebnis, so kann dieses Ergebnis im EPK-Diagramm weiterunten dadurch, dass es den gleichen Namen trägt, als Eingabeparameter benutzt werden. In EPKsind die Eingabe- und Ausgabeparameter mit der Funktion ebenfalls über gerichtete Relationskantenverbunden. Der Pfeil zeigt auf die Funktion, wenn die Eingabeparameter gelesen werden und aufAusgabeparameter, wenn die Daten geschrieben werden.

Die doppelte Beziehung zwischen den EPK-Elementen und den WSDL-De�nitionen sowie denBPEL-Elementen, wie in der Abbildung 5.7 dargestellt, macht die Handhabung der Variablen in demTransformationsprozess zu einer schwierigen Aufgabe. Es wird in [WGL05] darauf hingewiesen, dass�ein Datenobjekt in der EPK ... hinsichtlich Struktur und Semantik im Idealfall einem MessageTypeder bestehenden Service-Infrastruktur (entspricht)�. Dieser Aussage kann in dieser Arbeit aber nichtvollständig entsprochen werden. Der Grund hierfür liegt zunächst darin, dass eine EPK-Funktion


Abbildung 5.7: Zuordnung von Informationsobjekten zu MessageType, nach [WGL05]

nach dieser De�nition einer WSDL-Operation und ein EPK-Datenobjekt einem MessageType dieserOperation entspricht. In diesem Fall würde es bedeuten, dass mit dieser Aussage vorausgesetzt wird,dass einer EPK-Funktion immer nur ein Ein- und Ausgabe-Datenobjekt zugeordnet werden darf, daeine WSDL-Operation ebenfalls nur ein Input- und ein Output-MessageType haben darf. Daher mussan dieser Stelle die Zuordnung auf eine andere Weise durchgeführt werden, da beim Modellieren inEPK-Diagrammen häu�g auch mehrere Datenobjekte einer Funktion zugeordnet werden. Alle EPK-Datenobjekte entsprechen in diesem Fall nicht einem MessageType, sondern einem Part von diesemMessageType, wie es in der Abbildung 5.7 abgewandelt, verdeutlicht ist. Dies hat zur Folge, dass einPart nach dieser De�nition entweder den Typ complexType, element oder simpleType haben kann.Nach Möglichkeit sollten die Ein- und Ausgabedaten im EPK-Modell über den komplexen Typenbeschrieben werden. Der Grund hierfür liegt darin, dass wenn die Informationsobjekte nur einfacheDatentypen tragen werden, die Übersicht im EPK-Diagramm dadurch schnell verloren gehen kann, daviele Ein- und Ausgabedaten gra�sch modelliert werden müssen. Um die Komplexität des Beispielesin Kapitel 6 nicht unnötig zu steigern, werden die Eingabedaten an einigen Funktionen jedoch alseinfache Typen de�niert. Nur die wenigen Daten werden als komplexe Datentypen de�niert.

Des Weiteren wird in dieser Arbeit angestrebt eine Assign-Aktivität algorithmisch zwischen WebService-Aktivitäten hinzuzufügen. Wird einer EPK-Funktion eine WSDL-Operation, die als Inputund Output eine MessageType-De�nition trägt, zugeordnet, so wird algorithmisch bestimmt, welcherMessageType für die Input-/Output-Variable in der WSDL-Datei de�niert ist. Diese wird als eineeigene Variable der <variables>-De�nition hinzugefügt.

Als nächstes müssen die Datenobjekte an den EPK-Funktionen betrachtet, die in EPML über<dataFields> gekapselt sind, und der vorher erstellten MessageType-Variable zugeordnet werden.Die Namen der Input- und Output-Informationsobjekte im EPK-Diagramm werden in BPEL zusätz-lich für die Erzeugung weiterer Variablen verwendet. Daher wird die Funktion mit den über <re-lation> angebundenen <dataField>-Elementen betrachtet und die Variablennamen zusammenmit dem verwendeten Typ algorithmisch bestimmt und ebenfalls der <variables>-De�nition hin-zugefügt. Es wird angestrebt für jedes <dataField>-Element eine weitere BPEL-Variable mit demdazu gehörigen Typ in Form <complexType> oder <element> zu erzeugen. Hierfür muss daherin dem <dataField>-Element eine <complexType> oder <elementType>-spezi�sche Annotationerfolgen, die den notwendigen Datentyp eindeutig festlegt.

Zum Schluss müssen die Variablen, die aus den Informationsobjekten erzeugt wurden, den Varia-blen, die aus dem MessageType entstanden sind, mit Hilfe einer Assign-Aktivität zugeordnet werden.

Sind einer EPK-Funktionen gleichzeitig mehrere Ein- und Ausgabedaten zugeordnet, so muss man si-cherstellen, dass der verwendete Input- oder Output-MessageType alle Datentypen der angebundenenEPK-Ein- und Ausgabedaten in sich vereint.

Die Informationsobjekte erhalten in der Annotation den richtigen Datentyp und die Angaben zudem verwendeten Part und der Query. Zusätzlich kann noch die Variable explizit angegeben werden,zu der die EPK-Eingabedaten hinzugefügt werden soll, ist aber nicht zwingend notwendig. Wie imnächsten Listing gezeigt ist, müssen alle eingehenden Informationsobjekte, die einer Funktion alsEingabedaten zugeordnet sind, nach diesem Muster annotiert werden.

1 <dataField id="150">2 <name>AnfrageFluege</name>3 <description>Input von PruefeFluege</description>4 <attribute typeRef="complexType" value="FlightOrderType"/>5 <attribute typeRef="toPart" value="getFlightRequestPart"/>6 <attribute typeRef="toQuery" value="/air:getFlightsRequestType/air:FlightOrder"/>7 12 <attribute typeRef="toVariable" value="getFlightRequest"/>13 </dataField>

Der verwendete Typ in der Annotation hilft im Transformationskonzept das eindeutige Identi�zie-ren des verwendeten Typs der jeweiligen Variable, wobei wie schon oben erwähnt wurde, der Typ imjeweiligen MessageType vorkommen muss. Diese Bezeichnungen entsprechen den von BPEL verwen-deten Typ-Namen. Der Namespace für die angeschlossenen Web Services wird aus den ersten dreiBuchstaben vom portType-Namen im Transformationsprozess erzeugt und muss daher dem Namess-pace in der Query-Klausel entsprechen. Anschlieÿend müssen zwei weitere Parameter, wie <toPart>und <toQuery> zugeordnet werden. Dieser Schritt ist erforderlich, um festlegen zu können zu wel-chem Part und mit welcher Anfrage die EPK-Inputvariable zu der verwendeten Input-MessageType-Variable der WSDL-Operation zugeordnet werden soll.

Alle ausgehenden Informationsobjekte müssen demnach nach dem nächst folgenden Listing ange-reichert werden. Hier wird aus dem MessageType die Information explizit wieder einer EPK-Variablezugeordnet, die auf dem Blackboard für weitere Operationen als Eingabeparameter bereit gehal-ten wird. Wurde die Variable im BPEL-Prozess zur Laufzeit belegt, so kann nach dem schon obenvorgestellten Vorgehen, diese Variable einer anderen MessageType-Variable zugeordnet werden. DieBelegung wird nicht überschrieben, da hier als Annotation bislang nur die Zuordnungen betrachtetworden sind.

1 <dataField id="151">2 <name>Flugliste</name>3 <attribute typeRef="complexType" value="AirlineWSBean"/>4 <attribute typeRef="fromPart" value="getFlightResponsePart"/>5 <attribute typeRef="fromQuery" value="/air:getFlightsResponseType/air:getFlightReturn"/>6 </dataField>

Wird zum Beispiel die Variable Flugliste aus dem oben dargestellten Listing weiter unten im EPK-Diagramm noch einmal verwendet, so können die Annotationen mit den Attributen <toPart> und<toQuery> gleichzeitig dem gleichen Informationsobjekt zugeordnet werden. Vorausgesetzt, dassdie Kante vom Informationsobjekt zu der nächsten EPK-Funktion existiert. Dabei müssen für die<toPart> und <toQuery> die Werte der auf die zu mappende MessageType-Variable zugeordnetwerden.

Wird dagegen ein explizites Setzen einer Variablen gewünscht, kann dieses dadurch erreicht wer-den, dass ein Literal dem MessageType zugeordnet wird, wie es im nächsten Listing gezeigt wird.Hier müssen die kleiner oder gröÿer gleich Zeichen durch ihre Entsprechungen &lt oder &gt und dieAusführungszeichen durch &quot ersetzt werden, da die De�nition von XML-Code im XML-Code

nicht erlaubt ist. Durch eine solche Ersetzung wird der Code zunächst als String behandelt und imTransformationsprozess durch das Parsen anschlieÿend in den richtigen XML-Code umgewandelt.

1 <dataField id="190">2 <name>AuswahlZahlung</name>3 4 <attribute typeRef="literal"5 value="<selectPaymentType xmlns="http://ipWS.de"6 xmlns:con="http://contactSchema.de" >7 <code>’Kreditkarte’</code></selectPaymentType>"/>8

9 <attribute typeRef="toPart" value="selectPaymentRequestPart"/>10 <attribute typeRef="toQuery" value="/pay:selectPaymentRequestType/pay:code"/>11 </dataField>

Zusammengefasst bedeutet es, dass die Eingabedaten der EPK-Funktion bei einem Operationsauf-ruf zunächst den eindeutigen Typ der zusendenden Nachricht festlegen. Diese Eingabevariable wirdvom Blackboard eingelesen und der Variable der Inputnachricht zugeordnet. Analog funktioniert esbei den Ausgabedaten. Wird eine Nachricht vom Partner empfangen, so werden die belegten Parame-ter ausgelesen und den Ausgabevariablen der EPK-Funktionen zugeordnet. Sollten in beiden Fällendie Informationen manipuliert werden, so können diese gemäÿ des festgelegten XPath-Ausdrucksvorgenommen werden. Die Abbildung 5.8 verdeutlicht noch einmal gra�sch die zu implementierendeZuordnung der EPK-Eingabe- und Ausgabedaten zu den MessageType-Variablen.

Abbildung 5.8: Variablenzuordnung

Bei der automatischen Zuordnung von Assign-Variablen wird bei Eingabedaten zunächst immergeschaut, welche MessageType-De�nition einer Operation zugeordnet worden ist. Für den Message-Type wird explizit eine neue Variable de�niert, die den Name der Input- oder Output-Variable derWSDL-Operation-De�nition trägt. Anschlieÿend wird die Variable aus der Annotation vom Daten-objekt zu dieser MessageType-Variable zugeordnet. Bei Ausgabedaten werden die Daten aus einerMessageType-Variable wieder den Variablen aus einem Ausgabe-Datenobjekt zugeordnet.


Der groÿe Vorteil bei diesem Vorgehen ist, dass die Variablen, die in EPK verwendet werdenextra rausgeschrieben werden und in dem Blackboard abgelegt werden, um diese später im anderenKontext wieder verwenden zu können, so dass hierfür keine De�nition des expliziten Daten�usses inEPK erforderlich ist.

Der Nachteil bei der automatischen Erzeugung von <assign>Aktivitäten liegt in der Vielzahlder möglichen Anfragen in XPath, die de�niert werden können. Der Business Analyst kann solcheAnnotationen selbst nicht durchführen, und muss deshalb diese Aufgabe an den Entwickler übergeben.Des Weiteren können Fälle auftreten, wo die zugeordnete WSDL-Operation in der MessageType-De�nition nicht alle Datentypen der angebundenen EPK-Ein- und Ausgabedaten vereint. So muss indiesem Fall entweder der MessageType erweitert werden oder die WSDL-Operation eignet sich nichtfür die an die EPK-Funktion angebundenen Informationsobjekte.

Sollten zusätzliche Berechnungen an Datenobjekten vorgenommen werden, so kann zusätzlichexplizit durch das Setzen des value-Wertes durch �assign� aus einer EPK-Funktion eine <assign>-Aktivität erzeugt werden. Hierfür müsste man eine EPK-Funktion extra einfügen und entsprechendannotieren. An den angebundenen Ein- und Ausgabedaten müssen in diesem Fall jeweils gemäÿdem nächst folgenden Listing die Annotationen hinzugefügt werden, um festzulegen, von welchemPart <partName> und mit welcher Query <queryName> von einer zu der anderen Variable die Wertekopiert werden sollen, wobei als Variable dann der Name des jeweiligen Datenobjekts gewählt wird.

1 <dataField id="151">2 <name>Flugliste</name>3 ...4 <attribute typeRef="partName" value="getFlightResponsePart"/>5 <attribute typeRef="queryName" value="/air:getFlightsResponseType/air:getFlightReturn"/>6 </dataField>

Mögliche Erweiterungen - Die bislang vorgestellten Transformationen beschränken sich jedochauf einfache Manipulationen. In echten Szenarien müssen jedoch komplexere Transformationen durch-geführt werden. Schaut man ich die unterstützenden Funktionen, die XPath 1.0 mit sich bringt, an, soreichen diese nicht aus, um alle möglichen Fälle in BPEL abdecken zu können. BPEL in der Standard-Spezi�kation bietet hierfür keine weitere Möglichkeiten an, zum Beispiel XSLT für die Transformationzu verwenden. Aus diesem Grund hat Oracle BPEL Process Manager zusätzliche Funktionen als Ex-tension von BPEL bereitgestellt und erlaubt die XSLT-Verarbeitung in BPEL-Prozessen zu benutzen.Für Zuweisungen wird ebenfalls die <assign>-Aktivität verwendet. Jedoch muss folgendes beachtetwerden. Werden die Oracle-spezi�schen Funktionen in einem BPEL-Prozess benutzt, so schränkendiese die Portabilität eines BPEL-Prozesses erheblich ein, da der erzeugte BPEL-Prozess von anderenBPEL-Engines nicht unterstützt wird.

5.5 Bewertung

Im diesem Abschnitt wird zunächst die betriebswirtschaftliche und die technische Sicht erläutert undanschlieÿend die Grenzen der Konvertierung kritisch bewertet.

5.5.1 Betriebswirtschaftliche und technische Sicht

Die fachliche Prozessmodellierung hat die Aufgabe, �die Abläufe eines Geschäftsprozesses aus derbetriebswirtschaftlichen Sicht� [Stä06] darzustellen. Die fachlichen Anforderungen, die im Rahmeneines Projektes von einem Business Analysten de�niert werden müssen, müssen exakt auf die infor-mationstechnische SOA-Prozessmodelle abgebildet werden. Daher muss bei der Prozessmodellierung


zwischen den verschiedenen Sichten unterschieden werden. Hierfür wird für das oben vorgestellte Vor-gehensmodell eine De�nition der Sicht auf die Modellierungsebenen eingeführt, da dieses Vorgehendie De�nition verschiedener Rollen erlaubt.

In der betrieblichen Geschäftsprozesssicht liegt der Fokus auf der Modellierung von kooperieren-den Partnern eines Geschäftsprozesses und den damit assoziierenden Schnittstellen zwischen denbeteiligten Abteilungen. Der Business Analyst sammelt die Anforderungen und stellt diese in einemEPK-Diagramm gra�sch dar. Die EPK-Notation stellt ein konzeptuelles Modell für betriebliche Ge-schäftsprozesse dar. Die Geschäftsprozesslogik wird auf einer hohen Abstraktionsebene modelliert.Diese Vorgehensweise entspricht auch den aktuellen Software-Entwicklungsmethoden. Die Fachberei-che können die fachlichen Anforderungen, wie gewohnt auf der abstrakten Ebene für die gewünschtenGeschäftsprozesse modellieren, und diese anschlieÿend detaillierter verfeinern. Die hierarchische Ver-feinerung erlaubt eine �exible Anpassung und Erweiterung der Geschäftsprozessmodelle und bringtwesentliche Vorteile bei der Modellierung. Die hierarchischen Funktionen können durch andere besseroptimierte Teilprozesse problemlos ausgetauscht werden. Bei der Modellierung von Hierarchien aufder linken Seite sollte folgendes beachtet werden. Die zu erstellenden Geschäftsprozesse sollten nachMöglichkeit mit dem Ziel der Wiederverwendung der BPEL-Prozesse entworfen werden.

Eines der groÿen Probleme bleibt nach wie vor die Granularität der Verfeinerung. Die Verfeine-rung muss solange durchgeführt werden, bis die Granularitätsebene erreicht ist, wo gesagt werdenkann, dass für die betrachtete Funktion eine WSDL-Operation benutzt werden kann. Die fachlicheEPK-Prozessbeschreibung bestimmt immer zuerst die Granularität der zu verwendeten Web Services.Gemäÿ dem SOA-Konzept kann so eine an die EPK-Funktion angebundene Anwendungskomponentedurch eine andere ersetzt werden, ohne das hier vorgestellte Konzept seine Gültigkeit verliert. Wirddas betrachtete fachliche Modell im EPK-Diagramm zu abstrakt modelliert, so muss der Entwick-ler in den Transformationsprozess eingreifen, um seine Entscheidung abzugeben. Zudem muss derBusiness Analyst bestimmten Funktionen auf der untersten Ebene Ein- und Ausgabedaten oder auchServices vorgeben. Erst durch das Hinzufügen solcher Informationen auf der untersten Ebene ist dieBeschreibung der Geschäftsprozesse vollständig.

Leider lässt sich die Transformation aus der Rollende�nition des Business Analysten nicht voll-ständig automatisieren, da von den Fachbereichen nicht verlangt werden kann, dass diese technischesWissen vorweisen müssen, um alle notwendigen Annotationen durchführen zu können. Der BusinessAnalyst kann zwar die Zuordnung von Ein- und Ausgabedaten und eines Web Services zu einer Funk-tion anhand von Beschreibungen durchführen, sobald es aber zu dem Punkt der Daten-Manipulationund der hierfür notwendigen Annotationen kommt, muss die Anbindung von einem IT-Entwicklerdurchgeführt werden. Schon scheitert der Business Analyst daran, den richtigen komplexen Typenfür die Informationsobjekte hinzuzufügen, da er hierfür die XML-Struktur der WSDL-Types-De�nitionoder XML-Schematas lesen muss. Weiterhin bestimmt die fachliche Prozessbeschreibung die Gra-nularität der zu verwendeten MessageTypes. Wird die Verfeinerung zu detailreich durchgeführt, somüssen die angebundenen Ein- und Ausgabedaten in dem MessageType enthalten sein. Hierfür müs-sen vorhandene WSDL-Beschreibungen mit textbasierten Erläuterungen oder Kommentaren erweitertwerden, damit die Fachbereiche diese verstehen können, um eine EPK-Funktion zu einer WSDL-Operation in Relation setzen zu können.

Es bleibt das Problem bestehen, den für die EPK-Funktion passenden Web Services zu �nden, dadieser den Anforderungen der Fachbereiche genügen muss. Falls der Business Analyst bei der An-bindung keinen geeigneten Web Service �nden sollte, muss dieser sein erstelltes Modell anschlieÿendan den IT-Entwickler, der sein Modell anschlieÿend vervollständigen muss, übergeben. Liegt keinpassender Web Service vor, so muss dieser zuerst modelliert werden, um eine WSDL-Beschreibungfür die EPK-Funktion anbieten zu können.

An dieser Stelle muss das EPK-Diagramm an die IT-Abteilung übergeben werden, um dieses nachdem hier vorgestellten Konzept zu vervollständigen. Eine solche Vervollständigung wird demzufolge


dann aus der Sicht des Entwicklers auf der Zwischenebene statt�nden. Aus diesem Grund wurde indas hier vorgestellte Konzept eine Zwischenebene eingefügt, in der die Zusatzinformationen beimÜbergang von der betriebswirtschaftlichen auf die implementierungstechnische Ebene hinzugefügtwerden können.

Auch wenn es nicht möglich ist eine vollautomatische Transformation nach der in diesem Kapiteleingeführten De�nition durchzuführen, so bewirkt das hier beschriebene Konzept, dass die manu-ellen Arbeitsschritte wie das Nachmodellieren der EPK-Diagramme in BPEL durch die Entwicklernicht erforderlich ist. Das Konzept ermöglicht eine schnellere Überführung der betrieblichen Ge-schäftsprozesse auf die technische Implementierungsebene. Dies führt wiederum zu Qualitäts- undE�zienzsteigerungen. Man spart Zeit und Anzahl der Fehler einer manuellen Transformation könnenerheblich minimiert werden. Die Lücke zwischen den fachlichen Anforderungen und der IT kann soüberbrückt werden.

Die Aufgaben des IT-Entwicklers sind das Überprüfen der generierten BPEL-Prozesse auf dasDesign, die Durchführung ggf. kleiner Überarbeitungen, die Vervollständigung der EPK-Diagramme,das Hinzufügen von verschiedenen Handlern, die Implementierung von fehlenden Web Services unddas Deployment von fertigen BPEL-Prozessen.

5.5.2 Bewertung der Grenzen der Konvertierung

Die eingeführten, konzeptuellen Unterschiede der beiden Sprachen EPK und BPEL sind so groÿ,dass man mit EPK nicht alle Möglichkeiten, die BPEL anbietet, realisieren kann. Es wurde gezeigt,dass der Transformationsprozess mit enormen Schwierigkeiten verbunden ist, wenn sich die Men-ge der Elemente der betrachteten Sprachen stark unterscheidet. Die EPK-Elemente bilden nur einekleine Teilmenge von BPEL-Elementen. Dadurch ist es nur bedingt möglich, eine direkte Transfor-mation durchzuführen. Zwar ist es möglich den Kontroll�uss von EPK nach BPEL abzubilden, sosind für ausführbare BPEL-Prozesse eindeutige Werte erforderlich. Es erweist sich als sehr schwerdieses Modell ohne Annotationen auf die Implementierungsebene zu transformieren, da die Funktioneine 1-zu-N-Beziehung zu der BPEL-Aktivität aufweist. Hierfür mussten Zusatzinformationen einge-fügt werden, um die benötigten Daten in dem BPEL-Dokument abzulegen. Die service-orientiertenZusatzinformationen sollen zunächst vor dem Transformationsprozess dem EPML-Austauschformathinzugefügt werden. Dadurch soll es möglich sein, aus den annotierten Geschäftsprozessen sofortausführbare BPEL-Prozesse zu erzeugen. An welchen Stellen die Annotationen durchgeführt werdenmüssen, kann man den jeweiligen XML-Schematas für die betrachteten Sprachen erkennen. DieserAspekt wurde ausführlich in diesem Kapitel behandelt. Es ist ebenfalls vorstellbar noch beliebigeweitere Annotationen hinzuzufügen, jedoch sollte vorher der Sinn und Zweck solcher Zusatzinfor-mationen genau abgewogen werden. Denn es macht keinen Sinn alles auf die Zwischenebene zuverlagern, um daraus brauchbaren BPEL-Code zu erzeugen.

Die bisher vorgestellten Ansätze in Abschnitt 2.5.1 beschäftigen sich bislang nur ausschlieÿlichmit dem Kontroll�uss [AL05; LA06; ODBH05] oder mit abstrakten BPEL-Prozessen [Kop05]. Imerzeugten Code werden noch keine konkreten Werte gesetzt, die die Ausführbarkeit erlauben würden,da nur eine Skelettstruktur eines BPEL-Prozesses erzeugt wird. Die WSDL-Beschreibungen, die imTransformationsprozess bislang erzeugt werden, werden mit Dummy-Werten27 belegt, die in weiterenSchritten vom Entwickler manuell nachbearbeitet werden sollen. Die Variablenbehandlung mit Hilfeder Assign-Aktivität wurde im Transformationsprozess bislang ebenfalls noch nicht behandelt. Einigeder hier betrachteten Beiträge weisen nochmal ausdrücklich darauf hin, dass folgende Aspekte wieAssignments, Datenstrukturen mit Variablen und Typen-De�nitionen nicht in die Transformation

27Solches Vorgehen erweist sich als wenig brauchbar, denn genauso gut können Ausschnitte aus anderen WSDL-Beschreibungen genommen werden und dies Vorgehen würde zu einem schnelleren Erfolg führen, als alle Dummy-Werte zu ändern. Daher wurde entschieden, in dieser Arbeit fertige WSDL-Beschreibungen vorzugeben.


übernehmen werden sollten. Der Grund hierfür ist, dass das EPK-Diagramm dadurch nur überladenwird, und den Business Analysten nur überfordern würde. Jedoch konnte in diesem Kapitel gezeigtwerden, dass nur mit wenigen Annotationen möglich ist, ebenfalls den Daten�uss nach BPEL richtigzu übertragen. Um den Business Analysten nicht zu überfordern, wurde hier eine Zwischenebeneeingefügt, die dem Entwickler erlaubt, das EPK-Modell vor der Transformation aufzubereiten.

Weiterhin wird in der Literatur vorgeschlagen, mit EPK-Konstrukten BPEL-Syntax nachzubilden,diese Ansätze müssen jedoch als nicht ausreichend bewertet werden. Da die EPK-Modelle in derVergangenheit nicht nach der BPEL-Syntax modelliert wurden, müssten diese demzufolge zunächstvor dem Transformationsprozess grundlegend geändert werden. Folgende Punkte wie diverse Hand-ler oder CorrelationSets sollten in EPK grundsätzlich nicht modelliert werden, und sollten in dieTransformation nicht übernommen werden, da der Business Analyst hierfür keine BPEL-Kenntnissebesitzt und der Entwickler solche Konzepte niemals mit EPK-Elementen modellieren wird. Wirdversucht, mit Hilfe von EPK-Konstrukten BPEL-Elemente nachzumodellieren, so führt solches Vor-gehen zu komplexen Algorithmen, die benötigt werden, um die Strukturen zunächst erkennen zukönnen. Ein weiterer Grund hierfür ist, dass man sich strikt an die BPEL-Syntax halten muss, al-lerdings kann dann der Prozess gleich genauso gut in vorhandenen BPEL-Entwicklungsumgebungenmodelliert werden. Letztendlich erlaubt die vorhandene Anzahl an BPEL-Tools dem IT-Entwicklerdas schnellere Nachbearbeiten von erzeugten BPEL-Prozessen als man es versucht, die implementie-rungsspezi�sche Aspekte in EPK-Diagrammen nachzumodellieren. Daher sollte nicht das Ziel einersolchen Transformation sein, die ganze Arbeit auf die Geschäftsabteilungen zu verlagern.

Das Zurückgreifen auf vorhandene Standards wie EPK und EPML erlaubt den Modellierern beider ihnen bekannten Modellierungsmethode zu bleiben. Die weiteren o�enen Standards wie WSDL,XML-Schema und BPEL, die für die Ausführung der Geschäftsprozesse verwendet werden, erlaubenzukunftsweisend neue Technologien einzusetzen. Daher muss nicht zwangsweise eine weitere EPK-Engine entwickelt werden, die die SOA-Unterstützung anbietet. Das hier vorgestellte Konzept kannso zur Lösung des Problems der Interoperabilität eingesetzt werden.

Im nächsten Abschnitt wird zusammengefasst, welche Ergebnisse durch das in diesem Kapitelvorgestellte Konzept erreicht worden sind, und welche Methoden hierfür eingesetzt worden sind.

5.6 Zusammenfassung

Den Ausgangspunkt der Geschäftsprozessmodellierung bilden die fachlichen EPK-Modelle, die nichtfür die Ausführung auf einer Engine bestimmt sind. Um solche Prozesse als Work�ow ausführenzu können, wurde in diesem Kapitel ein Konzept entwickelt, welches erlaubt, die fachlichen Ge-schäftsprozessmodelle auf die Implementierungsebene zu überführen. Im Zuge der Transformationwurden folgende Punkte erfolgreich gelöst.

Das in dieser Masterarbeit erarbeitete Konzept greift auf die graph-orientierte Repräsentation derEPK zurück. Es ist aber ebenfalls möglich, z.B. Template- oder Semantik-basierte Ansätze [MCG05]zu verwenden, um das gewünschte Ergebnis zu erreichen. Die grundlegenden EPK-Elemente wurdenerfolgreich auf die BPEL-Elemente transformiert. Für die Transformation zu einem vollständigenausführbaren BPEL-Prozess muss die EPK erweitert werden, weil die EPK-Elemente hierfür nichtausreichen. Die hier vorgestellten Zusatzinformationen im EPML-Format sollen in der Transformationbenutzt werden, um die Transformation zu einem ausführbaren BPEL-Prozess zu ermöglichen, undderen Erfolg sicherzustellen.

Des Weiteren wurde gezeigt, dass für die Transformation nach BPEL das EPML-Schema nicht ver-ändert werden muss, wie es Intas vorgeschlagen hat. Es wurde jedem einzelnen EPK-Element ein äqui-valentes BPEL-Element zugeordnet und gleichzeitig gezeigt, welche WSDL- und BPEL-spezi�sche


Details in Form von Annotationen man hinterlegen muss, um dieses Element hinsichtlich der WebService-Anbindung zu spezi�zieren, und um daraus einen lau�ähigen BPEL-Prozess herzustellen.

Wird im EPK-Diagramm eine automatische Funktion gekennzeichnet, die durch einen Web Serviceausgeführt wird, so wird hierfür in BPEL eine <invoke>-Aktivität verwendet. Es war erforderlich dieaufzurufende Operation und den dazu gehörigen PortType dem <application>-Element zuzuord-nen. Für die Annotation des <function>-Elementes reicht das Setzen des functionType-Wertes aus,um sowohl die Anbindung des Web Services über invoke, receive und reply sicherzustellen, als auch,um die Funktion auf die andere elementare BPEL-Aktivitäten abzubilden. Die <receive>- und <re-ply>-Aktivitäten werden zunächst grundsätzlich dagegen aus den Start- und End-Ereignissen einesEPK-Diagramms erzeugt.

Die Überführung behandelt in dieser Arbeit nicht nur den Kontroll�uss, sondern auch den Da-ten�uss. Des Weiteren wurde gezeigt, wie Benutzerinteraktionen in die Transformation integriertwerden können. Im Zusammenhang mit dem Kontroll�uss wurden die Work�ow Patterns analysiert,um die beiden Sprachen EPK und BPEL zu vergleichen. BPEL vereint in sich die Features einerblock-orientierten Sprache XLANG und einer graph-orientierten Sprache WSFL. Die untersuchtenWork�ow Patterns in EPK unterstützen fast alle Work�ow Patterns in BPEL. So kann der richtigeAblauf der aufzurufenden EPK-Funktionen sichergestellt werden. Für die Beschreibung des Kontroll-�usses wurde entschieden, die WSFL-basierte Darstellung von BPEL-Prozessen zu verwenden, dahermussten Einschränkungen gemacht werden und es wurde angenommen, dass EPK-Prozesse azyklischsein müssen. Sollten Zyklen in EPK-Modell verwendet werden, so lassen sich nicht alle EPK-Modelleproblemlos nach BPEL abbilden. Des Weiteren lässt sich durch die WSFL-basierte Beschreibung derbetrieblichen Geschäftsprozesse die Struktur der EPK in BPEL sofort erkennen. Die graphen-ähnlicheStruktur wird durch die <flow>-Aktivität beschrieben. Alle weiteren EPK-Elemente werden dieser<flow>-Aktivität hinzugefügt.

In diesem Kapitel konnte auch gezeigt werden, dass es mit nur wenigen Annotationen möglich ist,Data Handling in EPK-Diagramme zu integrieren und den Daten�uss korrekt von EPK nach BPELabzubilden. Es ist ebenfalls möglich in den Transformationsprozess Assign-Aktivitäten zwischen deneinzelnen Aktivitäten automatisiert hinzuzufügen, um den Daten�uss von EPK nach BPEL richtigzu übertragen.

Im Transformationsprozess müssen die erzeugten BPEL-Instanzen, die eine groÿe Menge von At-tributen vorweisen, zunächst nicht mit Null- oder Dummy-Werten belegt werden, und können sofortmit erforderlichen Werten erzeugt werden, wenn eine Anbindung an die WSDL-Beschreibung statt-gefunden hat. In dem Fall, falls alle notwendigen Annotationen gesetzt wurden, wird der Transforma-tionsprozess durchlaufen und alle erforderlichen Parameter werden gesetzt. Sollte der Fall eintreten,dass nicht alle Werte gesetzt worden sind, so werden die nicht gesetzten Attribute zunächst mitDummy-Werten versehen, die vom Entwickler später durch richtige Werte ersetzt werden müssen.Im BPEL-Code wurde angestrebt, ein Kommentar an dieser Stelle einzufügen, wo die Werte nichtgesetzt worden sind. So kann der erzeugte BPEL-Prozess im nachfolgenden Schritt manuell nachbe-arbeitet werden.

Zusammenfassend können mit dem vorgestellten Konzept die vorhandenen Geschäftsprozessbe-schreibungen, um technische Zusatzinformationen angereichert und anschlieÿend nach BPEL trans-formiert werden. Das Ziel nach der Codeerzeugung ein BPEL-Prozess zu erhalten, der Aufrufe derAktivitäten gemäÿ dem vorgegeben Kontroll�uss im EPK-Diagramm, die De�nition der Variablenund alle PartnerLink-De�nitionen enthält, wurde erreicht. Zwar konnte auch die Forderung, dass dieErgebnisse des Transformationsprozesses auf einer BPEL-Engine ausgeführt werden können, erreichtwerden, so muss nach der Transformation der Entwickler den erzeugten BPEL-Code anschlieÿendnoch manuell nachbearbeiten. Solche Nachbearbeitungen beziehen sich nur auf die diversen Hand-lern in BPEL. Somit konnte gezeigt werden, dass es möglich ist, aus EPK-Diagrammen ausführbareBPEL-Prozesse zu generieren, ohne den Weg über BPMN zu gehen.

Kapitel 6

Umsetzung und Beispiel

�Das Ganze ist mehr als die Summe seiner Teile.�zugeschrieben Aristoteles (384-322 vor Chr.)

Nachdem das Konzept zur Transformation in Kapitel 5 vorgestellt worden ist, wird in diesemKapitel die technische Umsetzung erläutert. Es wurde davon ausgegangen, dass das EPK-Diagrammeine SOA-getriebene Geschäftsprozessmodellierung erlaubt, indem service-orientierte Annotationendem betrieblichen Geschäftsprozess hinzugefügt werden können. Im nächsten Abschnitt wird zunächsterläutert auf welche Standards man für die technische Realisierung zurückgegri�en hat. Anschlieÿendwird ein Beispiel vorgestellt, welches ausführlich beschreibt, wie ein EPK-Diagramm annotiert werdenmuss, um daraus anschlieÿend einen ausführbaren BPEL-Prozess generieren zu können. Anschlieÿendwird der Transformationsprozess an dem implementierten Prototyp ausführlich beschrieben und derbetrachtete Geschäftsprozess an einen Beispiel über alle Transformationsphasen evaluiert.

6.1 Technische Konzeption und prototypische Realisierung

Wie in Kapitel 2 erwähnt wurde, bauen die Web Services vollständig auf dem XML-Format auf undstellen hiermit die erste Anforderung an den Implementierungsprozess dar. Die starke Verbreitungvon XML als Austauschformat für Informationen hat dazu geführt, dass die Verarbeitung von sol-chen Dokumenten plattformunabhängig gestaltet werden sollte. Es gibt mehrere Möglichkeiten wiedie Transformation von XML-Dokumenten realisiert werden kann. So wurden im Verlauf der Arbeitzuerst folgende Technologien wie eXtendable Style Language Transformations (XSLT) [W3C99]und Java SE 61 evaluiert. Für die Implementierung des vorgestellten Konzeptes wurde letztendlichJava ausgewählt. Der Grund für diese Auswahl liegt in der schnelleren Entwicklung von komplexenAlgorithmen begründet, da die Abbildung vom annotierten EPML-Format nach BPEL keine einfa-che Restrukturierung des XML-Formates ist und XSLT hier im Vergleich zu Java gewisse Nachteilevorweist. Einer der weiteren wichtigen Aspekte, der während der Transformation berücksichtigt wer-den musste, ist die Beschreibung des Kontroll�usses, des Daten�usses und das einfachere Einbindenweiterer XML-Dateien. Letztendlich bietet Java noch folgende Vorteile:

� Existenz zahlreicher Bibliotheken, auf die zurückgegri�en werden kann

� Plattformunabhängigkeit

� Vorteile einer objekt-orientierten Programmiersprache

Die Realisierung des Programms wurde auf Eclipse Web Tools Platform (Eclipse-WTP)2 in derVersion 1.5 durchgeführt. Für die Logging-Funktionalität der durchgeführten Transformationsschritte

1http://java.sun.com/2http://www.eclipse.org/webtools/

81

KAPITEL 6. UMSETZUNG UND BEISPIEL 82

wird auf die Log4J-Bibliothek [Fou06a] zurückgegri�en. Im Folgenden wird beschrieben, wie XMLim Hinblick auf die technische Realisierung in Java eingebunden wurde.

Integration von XML in Java - Für die Integration von XML-Dokumenten, wie der EPML-Beschreibung, in Java gibt es ebenfalls mehrere Möglichkeiten. So wurden an dieser Stelle vorhande-ne Lösungen, Simple API for XML (SAX) [Meg], Document Object Model (DOM) [HHW+04],JDOM [Hun04] und XML-Beans [Fou06b] evaluiert. Die Evaluierung der oben genannten Möglich-keiten XML-Dokumente zu bearbeiten, führte zu dem Entschluss XML-Beans einzusetzen. An dieserStelle werden die einzelnen Standards weiter nicht mehr beschrieben, sondern es wird nachfolgendXML-Beans vorgestellt und erläutert, warum man sich für XML-Beans entschieden hat. Für einegenauere De�nition der anderen Standards wird hier auf die oben genannte Quellen verwiesen.

XML-Beans wird von Apache Software Fondation entwickelt und erlaubt aus dem vorgegebenenXML-Schema eine objekt-orientierte Datenstruktur zu erzeugen, die erlaubt, XML-Dokumente ausder objekt-orientierten Perspektive zu betrachten. XML-Beans liefert hierfür XML-Beans-Klassen,die zuerst aus dem XML-Schema erstellt werden, und leistungsfähige Methoden, um den Zugri� aufdas XML-Schema zu erlauben. Die generierten XML-Beans-Klassen erlauben jede beliebige XML-Instanz, die dem unterliegenden XML-Schema konform ist, zu parsen und nach belieben zu verändern.Es ist ebenfalls möglich, generierte Java-Objekte um eigene Klassen zu erweitern. Des Weiterenerlaubt die XmlCursor-Schnittstelle, zusätzliche Veränderungen an der XML-Instanz durchzuführen,die über die gelieferten Methoden hinausgehen. Der erzeugte Cursor vom Typ XmlCursor ermöglichtso das Einfügen, Entfernen und das Kopieren von XML-Fragmenten. Eines der groÿen Vorteile beimEinsatz von XML-Beans ist, dass die Dokumente im Transformationsprozess validiert erzeugt werden,sodass man sich um die Validierung der Ergebnisdokumente nicht mehr kümmern muss. DieserZusammenhang ist in der nächsten Abbildung 6.1 dargestellt.

Abbildung 6.1: Marshaling und Unmarshaling in XML-Beans

Die vorgegebenen XML-Schemas (EPML und BPEL) sind so komplex, dass man die manuelleErzeugung der Dokument-Elemente durch Strings vermeiden wollte. Die Validität3 der erzeugtenDokumente spielte somit eine wesentliche Rolle bei der Auswahl von XML-Beans. Für die Transfor-mation ist es erforderlich, das EPML-Schema4 und das BPEL-Schema (inkl. WSDL-Schema) durchden XML-Beans-Generator scomp durchlaufen zu lassen, um aus den Schemas Java-Objekte zu ge-nerieren. Bei der Verarbeitung von XML-Dokumenten mit XML-Beans bleibt das Quelldokumenterhalten. Aus diesem wird nach dem Parsen intern eine Struktur aufgebaut, die beliebig verarbei-tet werden kann. Bei der Transformation können auch bestimmte Informationen ausgelassen oderhinzugefügt werden, um das gewünschte Ziel zu erreichen. Zusatzinformationen aus Berechnungen

3Vgl. [MCG05] �Ability to guarantee correctness of the transformations. The simplest notion of correctness is syntacticcorrectness: given a well-formed source-model, can we guarantee that the target model produced by the transfor-mation is well-formed? �Die semantische Korrektheit sicherzustellen ist im Vergleich zu der syntaktischen Korrektheit mit viel mehr Aufwandverbunden und wird durch die richtige Abbildung des Kontroll�usses erreicht.

4Dadurch, dass die Annotationen, wie in Kapitel 3 eingeführt, durch <attributeType>-Element durchgeführtwerden, kann hier auf das Original-EPML-Schema von www.epml.de zurückgegri�en werden und muss hierfür nichterweitert werden.


von mehreren Quelldokumenten sind ebenfalls erlaubt. Die Struktur des Ergebnisdokuments in BPELerhält man aus den Informationen des XML-Quelldokuments in EPML, weiteren zusätzlichen Quellenund aus den Anweisungen im Generator.

6.2 Beispiel eines Geschäftsprozesses

Im Kapitel 2 wurde in der Abbildung 2.1 das Szenario einer ReiseReservierung im EPK-Diagramm alsder erste Schritt der Top-Down-Modellierung eingeführt. Im Folgenden wird ein Beispiel vorgestellt,welches einen Reservierungsprozess einer Reise beschreibt. Es wird an einem Beispiel zusammenfas-send gezeigt, wie man das EPML-Format annotieren muss, um einen ausführbaren BPEL-Prozessgenerieren zu können. Die Transformation als Ganzes im XML-Format kann nicht auf einmal darge-stellt werden, da die Beschreibungen der jeweiligen betrachteten Sprachen relativ umfangreich sind.Deshalb wird an dieser Stelle zunächst der Geschäftsvorfall im EPK-Diagramm vollständig, wie inder Abbildung 6.2 gezeigt, dargestellt. Anschlieÿend wird das EPK-Diagramm durch Web Service-Anbindung ergänzt. Dann werden Ausschnitte einer bestimmten Aufgabenbeschreibung dargestellt,um die Transformation einzelner Attribute oder Elemente zu verdeutlichen. Zum Schluss wird dasvollständige BPEL-Diagramm erläutert.

Ein Prozess beschreibt immer einen Zweck, der damit verfolgt wird. Deshalb ist die Ausgabeeines Prozesses schon vorher de�niert und auf den Kunden genau abgestimmt. Der Benutzer in-itialisiert selbst oder über ein Reisebüro die Reisereservierung. Die Reisereservierung wird durch einStart-Ereignis StarteReiseReservierung5 begonnen. Die Leistung, die vom Kunden genutzt werdensoll, sind die erfolgreiche Reservierung der Reise und die Tickets. Nach dem Beginnen des Prozes-ses wird anschlieÿend ein paralleler Aufruf von zwei hierarchischen Funktionen HotelReservieren undAirlineReservieren durchgeführt, der über AND-Split-Konnektor realisiert wird. Sowohl die FunktionHotelReservieren als auch die Funktion AirlineReservieren benötigen für die Reservierung bestimmteEingabedaten und Ausgabedaten und eine bestimmte Organisationseinheit, wie Hotel und Airline,mit der die Kommunikation statt�nden soll. Die Ein- und Ausgabedaten sind auf der oberen Ebeneaus den Gründen der Mehrdeutigkeit, die in Kapitel 5.2.1 beschrieben worden sind, in der Abbildungnicht dargestellt. Die hierarchischen Funktionen werden im nächsten Schritt durch die funktionale De-komposition von Business Analysten weiter verfeinert. Dabei ist es sehr wichtig, dass die syntaktischeRichtigkeit des EPK-Diagramms eingehalten wird.

Im verfeinerten EPK-Diagramm wird zunächst geprüft, ob freie Flüge verfügbar sind. Sind Flügeverfügbar, so wird im nächsten Schritt eine Auswahl des Fluges durchgeführt. Nach der Auswahlwird der Flug gebucht. Wurde der Flug erfolgreich gebucht, ist die AirlineReservierung erfolgreichabschlossen worden. Waren keine Flüge verfügbar oder konnte der Flug nicht gebucht werden, dainzwischen diese ausgebucht worden sind, wird an den Kunden eine Mitteilung über die FunktionSendeKeineFluegeVerfuegbar gesendet.

Wird im übergeordneten EPK-Diagramm die Reservierung des Hotels und der Airline erfolgreichabgeschlossen, so wird die Ausführung durch die anschlieÿend folgenden Ereignisse bestätigt, undder parallele Aufruf durch einen AND-Join zusammengeführt, ansonsten wird durch einen Ereignismitgeteilt, dass die Reservierung nicht erfolgreich abgeschlossen werden konnte. Nach der Synchroni-sation wird eine weitere manuelle Funktion ZahlungWählen ausgeführt. Der Kunde kann die Zahlungentweder mit einer Kreditkarte oder mit einer Rechnung ausführen. Hat der Kunde eine Zahlungs-methode ausgewählt, so folgt anschlieÿend ein XOR-Split, der den Kontroll�uss gemäÿ der Auswahlsplittet. In dem Fall, dass die Zahlung per Kreditkarte erfolgen soll, wird der linke Zweig gewählt,

5Im EPML-Format des betrachteten Prozesses werden die Namen alle zusammengeschrieben, da das erzeugte BPEL-Dokument sonst aufgrund des verwendeten Typen NCName der Validität nicht genügt.


Abbildung 6.2: Geschäftsvorfall ohne Web Service-Anbindung

andererseits der rechte. Zum Schluss wird die Verzweigung wieder durch einen XOR-Join zusammen-geführt und die Funktion SendeBenachrichtigung ausgeführt. Nach dem Ausführen dieser Funktionwird der Prozess mit einem End-Ereignis EndeReisereservierung beendet.

Das hier vorgestellte Beispiel enthält natürlich nicht alle vorstellbaren EPK-Elemente in dembetrachteten Geschäftsprozess. Aus Darstellungsgründen hat man sich auf die wenigen dargestelltenElemente beschränkt, da diese zum Verständnis des Geschäftsvorfalls völlig ausreichend sind. DesWeiteren wurde entschieden, nur die beiden ersten hierarchischen Funktionen HotelReservieren undAirlineReservieren näher zu betrachten, um den Kontroll- und den Daten�uss zu verdeutlichen. Umden Geschäftsprozess nicht unnötig zu überladen, werden die anderen hierarchischen Funktionen nichtverfeinert und nur als einfache Funktionen betrachtet, die im Folgenden nur einem Web Service-Aufruf entsprechen sollen. Denn dies kann nach dem gleichen Prinzip realisiert werden. Weiterhinwird aufgrund der in Abschnitt 5.2.5 gemachten Einschränkung nun das EPK-Diagramm im nächstenSchritt �ach geklopft, damit es sich auf der letzten EPK-Ebene be�ndet.

In der Abbildung 6.3 werden die modi�zierten EPK, welche durch das Flachklopfen und durch dierichtige Anbindung der Web Services, entstanden worden sind, dargestellt. Da die Funktionen durchautomatisierte Funktionen ausgeführt werden sollen, werden manuelle Aufgaben, die im Unternehmenbislang durch Sachbearbeiter aufgeführt worden sind, zunächst durch die Anwendungskomponentenersetzt, die den Web Service darstellen sollen. In der Abbildung werden zur Verdeutlichung desDaten�usses ebenfalls Daten�usskanten benutzt, um zu zeigen, wie die Daten weitergegeben werden,obwohl in EPK der Daten�uss zusammen mit dem Kontroll�uss weitergeleitet wird.


Um eine SOA-getriebene Modellierung zu ermöglichen, wurden zunächst einfache Web Service-Beschreibungen in WSDL6 entworfen. Dabei erfolgt die Integration verschiedener Anwendungssyste-me aus der Sicht des Geschäftspartners. Ein an die EPK-Funktion angebundener Web Service kannaufgerufen werden und als eine Art Black-Box ausgeführt werden. Der Modellierer braucht nichtzu wissen, wie das Programm arbeitet. Es reicht aus, die Eingaben, die benötigt werden, und dieAusgaben, die erwartet werden, zu de�nieren. An dieser Stelle muss die Modellierung der Ein- undAusgabedaten im EPK-Diagramm erfolgen. Die Anbindung solcher Web Services, die durch eine An-wendungskomponente beschrieben werden, erfolgt dabei über eine Relation und durch das Setzen des<functionType>-Attributes an der EPK-Funktion. Hierfür ist es vorstellbar, dann ein Symbol mit derKennzeichnung WS zu verwenden, die deutlich macht, dass es sich hierbei um eine automatisierteFunktion, die von einem Web Service ausgeführt wird, handelt.

Zu jeder Anwendungskomponente müssen, wie im Kapitel 5.4.2.5 die Annotationen hinzugefügtwerden, um für den Aufruf eines benötigten Dienstes alle notwendigen Informationen zu liefern. Diesetragen die URL der WSDL-Beschreibung, den Portnamen und den Namen der auszuführenden Ope-ration. Die von den Operationen verwendeten MessageType-De�nitionen sind von groÿer Bedeutungfür die richtige Auswahl der Operation. Diese müssen die EPK-Ein- und Ausgabedaten als einzelneParts in sich vereinen. Im Transformationsprozess wird dann bestimmt mit welchem Web Service diebetrachtete Funktion in Relation steht, und welche MessageTypes für die Inputs und Outputs derbetrachteten Operation verwendet werden sollen.

Der EPK-Geschäftsprozess in der Abbildung 6.2 enthält zunächst fünf Organisationseinheiten wieHotel, Airline, Buchhaltung, Kunde und Sachbearbeiter, die durch die Web Services wie AirlineWS,HotelWS, PaymentWS für die Kreditkartenzahlung und für die Zahlung mit Rechnung und denBenachrichtigungsdienst MailWS ersetzt werden sollen. Wie man erkennt, werden nur die beidenhierarchischen Funktionen AirlineReservieren und HotelReservieren näher betrachtet, die anderenwerden als einfache Funktionen, die einem einzigen Aufruf einer WSDL-Operation entsprechen sollen,betrachtet. Des Weiteren wurde zur Vereinfachung angenommen, dass die durch die hierarchischeFunktion beschriebene Dekomposition jeweils durch eine WSDL-Beschreibung näher beschriebenwird, obwohl es nicht zwingend notwendig ist. Auf der Ebene 1 steht die hierarchische FunktionAirlineReservieren für die Komposition von fünf unten genannten Operationen. Deshalb musste imnächsten Schritt eine hierarchische Verfeinerung im EPK-Diagramm durchgeführt werden, um dieeinzelnen WSDL-Operationen den Funktionen zuordnen zu können. Der Entwickler muss nur noch dieWSDL-Operationen aus diesen WSDL-Beschreibungen den untergeordneten, atomaren Funktionenannotieren. Die beiden Web Services bieten jeweils fünf Funktionen an:

� Airline: getFlight, selectFlight, returnFlightNumber, bookFlight, sendNoti�cationFlight

� Hotel : getHotel, selectHotel, returnHotelNumber, bookHotel, sendNoti�cationHotel

Die Funktion der jeweiligen Operationen ist an ihrem Namen erkennbar. Die beiden Operatio-nen getFlight und bookFlight werden für die mit <invoke>-annotierte Funktionen, selectFlightund returnFlightNumber für die mit <user>-annotierte Funktion und sendNoti�cationFlight für diemit <reply>-annotierte Funktion verwendet. Der Web Service MailWS enthält nur eine OperationsendMail, der Web Service PaymentWS enthält vier Operationen wie doInternalPayment, payWith-CreditCard, selectPayment und selectPaymentResponse.

6Beim Entwurf der jeweiligen WSDL-Beschreibungen kann man auf zwei Arten vorgehen. Wenn zum Beispiel die WebServices schon in Java implementiert vorliegen, so kann man im nächsten Schritt mithilfe des Apache FrameworksAxis [Fou07] aus den Java-Klassen WSDL-Beschreibungen generieren. Der andere Weg ist die manuelle Erzeugungvon WSDL-Beschreibungen in einem XML-Editor, wie dem Altova XMLSpy [Alt06]


Abbildung 6.3: Geschäftsvorfall mit Web Service-Anbindung


Im nächsten Schritt müssen vor dem Ausführen der Transformation die Annotationen für dieEreignisse und die Ein- und Ausgabedaten, wie in Abschnitten 5.4.2.3 und 5.4.2.4 erläutert wurde,gesetzt werden. Diese Annotationen erfolgen vor dem Transformationsprozess manuell. Anschlieÿendkann die annotierte EPML-Datei als Eingabeformat an den Generator übergeben werden.

6.3 Transformationsprozess

In diesem Abschnitt werden nun die einzelnen Phasen des implementierten Prototyps an dem vor-her eingeführten Beispiel ausführlich erläutert. Wichtig dabei ist, dass alle Transformationsschrittezunächst für jede EPK durchlaufen werden. Jede EPK wird im Transformationsprozess immer im<epc>-Objekt gehalten, welches zunächst intern verändert wird. Gleichzeitig wird parallel für jedeEPK ein BPEL-Prozess erzeugt, dem äquivalente BPEL-Elemente hinzugefügt werden. Dieses Vorge-hen erlaubt einfachere Manipulation und erfordert nicht, dass die zu verarbeitende Struktur zwangs-weise in eine Zwischendatei raus geschrieben werden muss, um diese anschlieÿend wieder einzulesenund weiter zu verarbeiten. So wird das <epc>-Element durch alle Phasen des Transformationspro-zesses als Parameter durchgereicht. Wurde eine EPK transformiert, wird der Transformationsprozessvon vorne für jede weitere EPK ausgeführt. Zwar erlaubt der programmierte Prototyp auch hierar-chische EPK-Schemas nach BPEL zu transformieren, aber aus den in Abschnitt 5.2.5 beschriebenenGründen wurde jedoch entschieden eine Vereinfachung an dem Transformationsprozess vorzunehmen.Zur Vereinfachung des Transformationsprozesses werden im Eingabeformat nur �ache EPK-Schemasbetrachtet. Werden keine �achen EPK in den Transformationsprozess geliefert, so werden zwar fürjede EPK einzelne BPEL-Prozesse generiert, diese müssen dann aber manuell verknüpft werden. DerTransformationsprozess gliedert sich in folgende Schritte auf:

(1) Analysephase der EPML-Struktur, Verknüpfen von Knoten anhand der Kanten zu einer internenGraphstruktur

(2) Entfernen der Ereignis-Knoten und Übertragen der Annotationen auf die Kanten

(3) Übersetzen der EPK-Elemente in BPEL-Elemente; für alle Funktionen werden gemäÿ demannotierten Attribut die jeweilige BPEL-Aktivität erzeugt und miteinander verbunden

(4) Entfernen von Empty-Aktivitäten

(5) Erzeugung der Variablen aus <dataFields>-De�nitionen und der Assign-Aktivitäten

6.3.1 Analysephase der EPML-Struktur

(1) - Als erstes muss das zu transformierende EPK-Diagramm im EPML-Austauschformat vorlie-gen. Da vorausgesetzt wurde, dass die EPK-Modellierung abgeschlossen sein muss, müssen allefür den Transformationsprozess notwendigen Informationen sich im EPML-Format be�nden. Be-vor man mit der Transformation einer EPML-Instanz nach BPEL beginnen kann, muss die EPML-Eingabedatei auf ihre Wohlgeformtheit und Gültigkeit gegen das EPML-Schema überprüft werden.Die EPML-Datei wird beim Einlesen zunächst gegen das EPML-Schema validiert, um zu prüfen,ob die Anforderungen des XML-Schemas erfüllt sind. Dieser Schritt ist sehr wichtig, denn in dieXML-Beans dürfen nur solche Dokumente eingehen, die wohl geformt und gültig sind. Anschlieÿendwird die EPML-Datenstruktur für die betrachtete EPK eingelesen und geparsed. Das Einlesen der inXML-vorliegenden Daten erfolgt dabei über die von XML-Beans erzeugte Factory-Klasse EpmlDocu-ment.Factory.parse(epmlFile), wobei epmlFile den Dateinamen trägt. Beim Parsen wird internein Wurzelelement epml, welches alle im EPK-Diagramm enthaltenden Elemente trägt, erzeugt, sodass man über alle im EPML-Format enthaltenen EPK-Elemente navigieren kann.

Zunächst muss der im EPK-Modell erstellte Kontroll�uss nach BPEL abgebildet werden. Hierfürwird gleichzeitig beim Einlesen der EPML-Datei eines betrachteten Geschäftsprozesses ein EPK-Graph zu jeder einzelnen EPK aufgebaut, der durch die Klasse EPCGraph beschrieben ist. Dabei istjeder einzelne Knoten in diesem Graphen durch die Klasse Node beschrieben. Die Klassen zu den imEPK-Diagramm verwendeten Elementen, wie die Funktion (FunctionNode), der Ereignis (EventNo-de), die Konnektoren (ConnectorNode), die sich weiter in XOR- (XORNode), AND- (ANDNode) undOR-Knoten (ORNode) aufteilen lassen, bilden die abgeleiteten Unterklassen von Node. Im EPML-Format werden die Kanten, wie im nächsten Listing zu sehen ist, de�niert.

1 <epc>2 <arc id="...">3 <flow source="..." target="...">4 </arc>5 </epc>

Über die eingelesenen EPK-Kanten, die alle Ids von zusammenhängenden Elementen tragen, wirdder Graph gefüllt, um einen zusammenhängenden Graphen zu erzeugen. Aus den enthaltenen sourceund target-Attributen werden zusätzlich, wie im Kapitel 2.7.1 gefordert, die Mengen der Vorgängerund Nachfolger-Knoten zu jeden Knoten berechnet und intern abgespeichert. Jede der Vor- undNachbedingungsmengen wird mit einen EPK-Element assoziiert und beschreibt somit die möglichenWege von diesem EPK-Element aus. Zwar erlaubt die EPML-Struktur für alle EPK-Elemente dieimpliziten Typen in Form von Stringangaben, wie startEvent, endEvent oder auch function zu de�-nieren, jedoch sind solche Angaben für die Transformation nicht explizit erforderlich. Es wurde vorhinerwähnt, dass beim Einlesen des <epc>-Elementes die Vorgänger und Nachfolgerknoten erzeugt wer-den. Der Typ der Konnektoren, ob der betrachtete Konnektor den Kontroll�uss aufteilt (split) oderzusammenführt (join), und der Typ der Ereignisse wird implizit anhand der Anzahl der ein- und aus-gehenden Kanten bestimmt. Da für jedes Element in XML-Beans eindeutige Klassen erzeugt wordensind, kann anhand dieser Klassen die Identi�kation der EPK-Elemente durchgeführt werden, indemdiese Klassen als Parameter vom Typ TypeElement den oben genannten Klassen übergeben wer-den. Die Art des Konnektors, also ob es ein AND, OR oder ein XOR-Konnektor ist, wird über dieoben eingeführten Klassen eindeutig festgelegt. Daher wird keine explizite Annotation der jeweiligenEPK-Elemente erfordert.

Für jede EPK wird beim Einlesen ein leeres BPEL-Dokument mit dem notwendigen Header, deralle für den BPEL-Prozess notwendigen Namespaces trägt, erzeugt. Das nächst folgende Listing zeigteine solche De�nition des BPEL-Headers.

1 2 3 4 <process name="TravelReservation" targetNamespace="http://epk-WS.de"5 expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"6 queryLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"7 suppressJoinFailure="yes"8 xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"9 xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

10 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"11 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"12 xmlns:xsd="http://www.w3.org/2001/XMLSchema"13

14 15 16 17 <partnerLinks>18 ...19 20 ...21 </partnerLinks>22

23 24 25 26

27 <variables>28 ...29 30 ...31 </variables>32

33 <flow>34 ...35 36 ...37 </flow>38 </process>

Der Name einer EPK wird für den Namen des BPEL-Prozesses verwendet. Die Namespaces zujedem angebundenen Web Service werden im Verlauf der Transformation beim Aufruf jedes einzelnenWeb Services extrahiert und müssen als Namespace dem BPEL-Prozess hinzugefügt werden. Zu demoben dargestellten BPEL-Header sollen im Verlauf weiterer Transformationsschritte weitere BPEL-Elemente hinzugefügt werden.

Nach der Analysephase wurde eine interne Graph-Struktur aus den Funktionen, Ereignissen undden Konnektoren aufgebaut. Diese Phase liefert einen gerichteten Graphen, der anschlieÿend imSchritt (3) nach BPEL transformiert werden soll. Das Ziel ist, für jeden in <epc>-Element enthaltenenKnoten eine dazu entsprechende Aktivität in BPEL zu erzeugen.

6.3.2 Entfernen der Ereignisknoten

(2) - Im nächsten Schritt werden aus dem vorher erzeugten Graphen die Ereignisse entfernt, eineNeuverknüpfung der Knoten durchgeführt und die Annotationen, die die Ereignisse getragen haben,den Kanten als Transitionsbedingung hinzugefügt. In EPK können die Ereignisse in drei folgendeKategorien, wie Start-Ereignisse, innere Ereignisse und End-Ereignisse eingeteilt werden. Die Trans-formation erfordert, dass die inneren Ereignisse aus dem EPK-Diagramm entfernt7 werden, da diesekeine Entsprechung als Knoten in BPEL haben. Die inneren Ereignisse in EPK legen den Kontroll�ussnur bei XOR- und OR-Splits eindeutig fest, deshalb können diese mit den Transitionsbedingungenan den Links verglichen werden. Aus diesem Grund wird angestrebt die Struktur von BPEL nach-zubauen, indem die inneren Ereignisse zusammen mit der eingehenden und der ausgehenden Kanteaus dem <epc>-Element entfernt werden. Zwischen dem Vorgänger- und dem Nachfolger-Elementwird eine neue Kante erzeugt, die als Annotation den XPath-Ausdruck, wie es in Abschnitt 5.4.2.3gezeigt wurde, tragen soll.

Der Start- und der Endereignis werden für den Transformationsprozess beibehalten, um in Schritt(3) aus diesen eine <receive>- und eine <reply>-Aktivität zu erzeugen, wie es im Abschnitt5.4.2.4 erläutert wurde. Die Start- und End-Ereignisse können im Transformationsprozess anhandihrer Vorgänger und Nachfolger eindeutig bestimmt werden. Der Start-Ereignis wird auf ein Recei-ve im BPEL-Prozess abgebildet, wenn es keinen Vorgänger im EPK gibt, und der End-Ereignis aufeine Reply-Aktivität, wenn es keine Nachfolger zu dem betrachteten Knoten existieren. Des Wei-teren können Situationen vorkommen, wie es auch im zu evaluierenden Beispiel gezeigt wird, dass

7Da BPEL ebenfalls explizit keine Konnektoren kennt, ist es vorstellbar die Konnektoren ebenfalls zu entfernen, umden Kontroll�uss eines BPEL-Prozesses nachzubauen und den Typ des entfernten Konnektors dem Vorgänger- oderdem Nachfolger-Knoten als Annotation hinzuzufügen. Die eingehenden und die ausgehenden Kanten aller Split- undJoin-Konnektoren müssen zuerst zusammen mit den Konnektoren entfernt werden. Zwischen dem Vorgänger unddem Nachfolger des zu entfernenden Konnektors muss dann eine neue Kante erzeugt werden und dem Vorgänger beieinem Split oder dem Nachfolger bei einem Join der Typ des entfernten Konnektors annotiert werden. So wurde dieseMöglichkeit ebenfalls implementiert und evaluiert, jedoch funktioniert diese Vorgehensweise nur bei einfachen EPK,wo es eine Einschränkung gibt, dass ein Konnektor als Vorgänger oder als Nachfolger keinen anderen Konnektorhaben darf. Die Konnektoren, die so entfernt werden können, dürfen als Vorgängerknoten entweder eine Funktionoder einen Ereignis haben.


Funktionen vor dem End-Ereignis den <reply>-functionType erhalten haben, wie es bei der Funk-tion SendeKeineHotelsVerfuegbar in der Abbildung 6.3 der Fall ist. Wenn vor dem End-Ereignis dieFunktion den functionType einer <reply>-Aktivität erhält, so würden nach dem im Kapitel 5 vorge-stellten Konzept zwei <reply>-Aktivitäten erzeugt. Aus diesem Grund wird der oben beschriebeneFall geprüft. Falls dieser zutri�t, so wird der End-Ereignis einfach entfernt, um daraus nicht noch einezweite Reply-Aktivität zu erzeugen. In diesem Fall darf dieses End-Ereignis keine service-relevantenAnnotationen enthalten. Die eigentliche Abbildung der Ereignisse zu BPEL-Elementen wird in (3)durchgeführt.

Nach dem Entfernen der inneren Ereignisse erhält man ein intern modi�ziertes EPK-Diagramm,welches nur noch folgende EPK-Elemente wie <function>, <arc>, <relation>, <dataField>,<application>und die Start- und End-Ereignisse enthält. Aus den im <epc>-Element übrig geblie-benen Knoten muss eine Neuverknüpfung durchgeführt werden, um einen modi�zierten Graphen ausdem <epc>-Element auszubauen. Dazu wird das <epc>-Element nach dem Entfernen der Ereignissenoch einmal als Parameter einer Methode übergeben, die aus dem modi�zierten <epc>-Konstruktanhand der Ids eine aktualisierte, interne Repräsentation in Form eines gerichteten Graphen herstelltund eine neue Berechnung der Vorgänger- und Nachfolger-Knoten durchführt. Nach dieser Phase wur-de den Kanten im Transformationsprozess die Annotationen der Ereignisse, die den XPath-Ausdrucktragen hinzugefügt. Aus diesen Annotationen werden in einem der nächsten Transformationsschrittedie Transitionsbedingungen in BPEL erzeugt.

6.3.3 Übersetzen der EPK-Elemente in BPEL-Elemente

(3) - Nachdem das EPK-Diagramm von den inneren Ereignissen bereinigt worden ist, werden in die-sem dritten Schritt gemäÿ dem aufgebauten EPK-Graphen alle EPK-Elemente analysiert und auf ihreEntsprechung in BPEL abgebildet. Die Analyse der Graphstruktur wird mit Tiefensuche durchgeführt.Dafür wird intern zusätzlich eine Liste erzeugt, die die Ids der Durchlaufordnung festhält. Anschlie-ÿend werden alle Elemente gemäÿ der in der Liste de�nierten Id abgearbeitet und in entsprechendeBPEL-Elemente übersetzt. Die Abarbeitung aller EPK-Elemente wird in einer for-Schleife über dieDurchlau�iste durchgeführt. Wird ein EPK-Element gefunden, der im Zielmodell seine Entsprechunghat, so wird entsprechend in BPEL die dazu äquivalente Entsprechung erstellt, welche gleichzeitig,dem in der Phase (1) erstellten <flow>-Element hinzugefügt wird.

Beim Abarbeiten der Liste werden für alle mit <invoke>-annotierten Funktionen eine <invoke>-Aktivität erzeugt und für alle mit <user>-annotierten Funktionen eine Abfolge von einer asynchronen<invoke>- mit der anschlieÿenden <receive>-Aktivität und für alle Start-Ereignisse eine <recei-ve>- und für alle End-Ereignisse eine <reply>-Aktivität erzeugt. Für alle Konnektoren wird eine<empty>-Aktivität generiert und für alle anderen EPK-Funktionen gemäÿ der Annotation des impli-ziten Typen entsprechende BPEL-Aktivität erzeugt. Dabei wird zwischen der im Graphen abgelegtenId und der Id im <epc>-Element enthaltenen Elementen ein Abgleich durchgeführt, um aus jedemEPK-Element die Annotationen auslesen zu können. Bei den drei Web Service-Aktivitäten müssengleichzeitig im Transformationsprozess die Annotationen der angebundenen Anwendungskomponen-te ausgelesen werden, um die Attribute in den BPEL-Aktivitäten setzen zu können. Für die mit<invoke>-annotierte Funktion wird, wie im Abschnitt 5.4.2.5 beschrieben ist, der an die Funkti-on angebundene Web Service über die Anwendungskomponente bestimmt, und die Annotationenausgelesen. Über die annotierte Operation wird der Name der empfangenen und zu sendenden Nach-richt (Input- und Output-Messagetypes) bestimmt und als eine eigene Variable der <variables>-De�nition hinzugefügt. Jede Variable muss vor ihrem Benutzen deklariert und initialisiert wordensein. Die Deklaration der Variablen erfolgt über den Namen und den Typen und wird in <varia-

bles>-Element durchgeführt. Die MessageType-Variablen sind für das Mapping von EPK-Eingabe-und -Ausgabedaten erforderlich, wie es in Kapitel 5.4.2.8 erläutert worden ist. Des Weiteren werden

für alle Ein- und Ausgabedaten, die einer EPK-Funktion zugeordnet worden sind, eigene Variablen inder <variables>-De�nition de�niert. An dieser Stelle wird im Schritt (5) fortgesetzt.

Die <flow>-Aktivität, die im Kapitel 4 näher beschrieben worden ist, stellt nichts anderes alseinen gerichteten Graphen dar. Die einzelnen Aktivitäten in der <flow>-Aktivität stellen die Knotenund die Links dazwischen die Kanten dar, die die Aktivitäten verbinden. Für jedes betrachtete EPK-Element, aus dem eine äquivalente BPEL-Aktivität erzeugt wird, werden nach dem im Abschnitt5.4.2.3 vorgestellten Vorgehen die Links hinzugefügt. Hierbei werden auch die Kantenbedingungenaus Annotationen der EPK-Kanten den jeweiligen Links hinzugefügt. Das Problem der Nicht-Lokalitätvon OR- und XOR-Joins8 wird in BPEL durch den Einsatz von Dead-Path-Elimination, die im Zu-sammenhang mit der Link-Semantik in Kapitel 4 angesprochen worden ist, gelöst.

Der Name der BPEL-Aktivität wird aus dem Namen der EPK-Funktion bestimmt. Dabei mussman darauf achten, dass keine Namen der verwendeten EPK-Elemente doppelt vorkommen, da dieLinks in BPEL anschlieÿend aus den Namen der EPK-Elemente generiert werden und gegebenenfallsbei gleichen Linknamen die Links nicht den richtigen BPEL-Aktivitäten zugeordnet werden.

Gleichzeitig werden zu der <partnerLinks>-De�nition <partnerLink>s und für jeden angebun-denen Web Service nach dem folgenden Listing die De�nitionen für die PartnerLinkTypes erzeugt.

1 <wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"2 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"3 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"4 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"5 xmlns:xsd="http://www.w3.org/2001/XMLSchema"6 xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"7 xmlns:air="http://airlineWS.de"8 targetNamespace="http://airlineWS.de">9 <wsdl:import namespace="http://airlineWS.de" location="AirlineWS.wsdl"/>

10 <plnk:partnerLinkType name="Airline-WS-PLT">11 12 <plnk:role name="Airline-WS-Requestor">13 <plnk:portType name="air:AirlineWS"/>14 </plnk:role>15 16 <plnk:role name="Airline-WS-Provider">17 <plnk:portType name="air:AirlineWS"/>18 </plnk:role>19 </plnk:partnerLinkType>20 </wsdl:definitions>

Die hier erzeugten De�nitionen für myRole und partnerRole werden gleichzeitig der jeweiligenWeb Service-Aktivität hinzugefügt.

Die in dieser Phase durchgeführte Transformation wird nach dem in der Abbildung 6.4 vorgestelltenVerfahren BPEL-Code generieren. Diese Abbildung stellt anhand der Pfeile ausführlich dar, wie dieeinzelnen Elemente erzeugt werden. Daher wird im Folgenden auf diese Darstellung nicht mehr nähereingegangen. Aus Darstellungsgründen wurde nur die Abbildung für eine Invoke-Aktivität abgebildet.Des Weiteren wurde ebenfalls im Zusammenhang mit der Invoke-Aktivität das Mappen der Variablendargestellt. Dieser Schritt wird jedoch erst in (5) ausführlich beschrieben. Das nach dieser Phaseerzeugte BPEL-Diagramm ist in der Abbildung C.4 im Anhang C dargestellt.

Der Zwischencode in BPEL wird jeweils nach jeder Phase in eine temporäre Datei rausgeschriebenund kann zur Kontrolle der Abbildung verwendet werden. Die bisher vorgestellten Ansätze habenimmer einen BPEL-Code geliefert, der mit dem erzeugten Code nach dieser Phase nur teilweisevergleichbar ist. Hier werden die für Ausführbarkeit notwendigen Parameter schon richtig gesetzt.Der hier erzeugte BPEL-Code ist jedoch noch nicht ausführbar, da die Eingabe- und Ausgabedatenüber die Assign-Aktivität noch nicht übergeben werden.

8Werden nach dem im Kapitel 5.4.2.3 vorgestellten Verfahren in OR und AND umgewandelt.


Abbildung 6.4: Abbildung der mit <invoke>-annotierten EPK-Funktion zu Invoke-Aktivität


6.3.4 Entfernen von Empty-Aktvitäten

(4) - Nach dem Abbilden der einzelnen EPK-Elemente auf ihre BPEL-Äquivalente enthält jede BPEL-Datei noch <empty>-Aktivitäten, die aus den Konnektoren entstanden worden sind. Der nächsteSchritt ist das Entfernen aller Empty-Aktivitäten aus dem <process>-Element. Hierfür wird überalle Empty-Aktivitäten iteriert, um diese zu entfernen. Über die in der Empty-Aktivität eindeutigfestgelegten Links können die Vorgänger und die Nachfolger der Empty-Aktivität bestimmt werden.So wird im nächsten Schritt die Empty-Aktivität zusammen mit den Links und der Link-De�nitionin <links>entfernt. Zwischen dem Vorgänger und dem Nachfolger wird ein neuer Link mit demNamen des Vorgänger_TO_Nachfolger erzeugt und als <source>-Link dem Vorgänger und als<target>-Link dem Nachfolger und der <links>-De�nition hinzugefügt. Nach dem Entfernen derLinks müssen die Transitionsbedingungen von alten Links, die vorher extrahiert werden müssen, andie neu erzeugten Links übergeben werden. Das nach dieser Phase erzeugte BPEL-Diagramm ist inder Abbildung C.5 im Anhang C dargestellt. Wie man dieser Abbildung entnehmen kann, so enthältdas Diagramm keine <empty>-Aktivitäten mehr.

6.3.5 Erzeugen von Variablen

(5) - In dieser letzten Phase des Transformationsprozesses werden die Input- und Outputvariablenvon EPK-Funktionen betrachtet und den erzeugten MessageType-Variablen zugeordnet. Hierfür wirdnun nicht über das <epc>-Element iteriert, sondern es wird in dieser Phase das <process>-Elementnäher untersucht. Es wird zunächst über alle Invoke-Aktivitäten iteriert und anhand des Aktivi-tätsnamen die dazu entsprechende EPK-Funktion im <epc>-Element noch einmal bestimmt, ausder jede einzelne BPEL-Aktivität entstanden worden ist. Nun werden zu dieser Funktion wieder dieEingabe- und Ausgabedaten näher betrachtet, da diese Annotationen in Form eines XPath-Ausdruckstragen. Das Ziel ist jetzt die aus den EPK-Eingabe- und Ausgabedaten erzeugte Variablen denMessageType-Variablen automatisch zuzuordnen. Eine explizite Zuordnung kann jedoch nur über ei-ne Assign-Aktivität durchgeführt werden. Deshalb ist es erforderlich, dass jede in einem BPEL-Prozessvorkommende Invoke-Aktivität durch zwei Assign-Aktivität eingekapselt wird. Im nächsten Schrittwird jeder Invoke-Aktivität als Vorgänger und als Nachfolger eine Assign-Aktivität hinzugefügt. DiesesVorgehen erfordern ebenfalls, dass die Links zwischen den vorhandenen BPEL-Elementen aktualisiertwerden müssen. Daher wird in diesem Schritt über alle Invoke-Aktivitäten iteriert, um über die Linksdie Vorgänger und die Nachfolger zu bestimmen. Nun müssen über die vorher eindeutig bestimmtenVorgänger und Nachfolger neue Links in der Form VorgängerActivityName_TO_AssignName undAssignName_TO_NachfolgerActivityName zu den Assign-Aktivitäten erzeugt werden. Des Weiterenmüssen die Assign-Aktvitäten selbst mit der Invoke-Aktivität über folgende Links der Form AssignNa-me_TO_InvokeName und InvokeName_TO_AssignName verbunden werden, um den Kontroll�usswieder richtig herzustellen. Die Anzahl der Copy-Anweisungen in der Assign-Aktivität hängt von derAnzahl der der EPK-Funktion zugeordneten EPK-Eingabe- und Ausgabedaten. Des Weiteren wurdeversucht, wenn als unmittelbarer Vorgänger eine Web Service-Aktivität vorkommt, die Ausgabewerteder dazu gehörigen EPK-Funktion zu der gleichen <assign>-Klausel hinzuzufügen, um die Anzahlder Assign-Aktivitäten so klein wie möglich zu halten. Das gleiche gilt natürlich für die unmittelbareNachfolger-Aktivitäten. Hier müssen dann dementsprechend die Eingabedaten der dazu äquivalenten,nachfolgenden EPK-Funktionen betrachtet werden. Bei Verzweigungen und Vereinigungen wurdendie <assign>-Klauseln entsprechend erzeugt.

In den Copy-Klauseln werden nun gemäÿ der vorgegebenen Annotationen die EPK-Variablen denMessageType-Variablen zugeordnet. Da die MessageType-Variable dem Typ des MessageType ent-spricht und die aus den EPK-Eingabe- und Ausgabedaten erzeugten Variablen vom Typ <complex-

Type>, <element> oder auch <literal> sein können, wird eine solche Zuordnung richtig durch-geführt, solange dazu entsprechende <part>-De�nitionen der betrachteten MessageType-De�nition


in der WSDL-Beschreibung entsprechen. Über das <part>-Element wird die zu verwendende Daten-struktur der Nachricht eindeutig festgelegt. Anders ausgedrückt, bedeutet es, dass das Mappen nurdann richtig funktioniert, wenn der MessageType die zu mappenden Datentypen als Part enthält. AlsVorgänger und Nachfolger einer Invoke-Aktivität wurden bislang nur die drei Web Service-Aktivitätenbetrachtet und implementiert. Da in BPEL jedoch noch andere elementaren BPEL-Aktivitäten auf-treten können, müsste dies auch für die anderen implementiert werden, damit die Assigns und Linksrichtig gesetzt werden können.

Der erzeugte BPEL-Prozess nach allen Phasen des Transformationsprozesses ist in der Abbildung6.5 auf der nächsten Seite dargestellt.

Abbildung 6.5: Erzeugte BPEL-Prozess durch den Generator

6.3.6 Testen des BPEL-Prozesses

Das Testen des generierten BPEL-Codes wird in ActiveBPEL Designer durchgeführt. Hierfür muss dieBPEL-Datei in den ActiveBPEL Designer zusammen mit den WSDL-Beschreibungen der verwendetenWeb Services importiert werden. Meldet der ActiveBPEL Designer Fehler nach dem Import, so ist


zunächst die zu suchende Fehlerquelle die durchgeführten Annotationen im EPML-Format aus demdie BPEL-Datei generiert wird, oder die nicht fehlenden WSDL-Beschreibungen. Dadurch, dass derKontroll�uss der erzeugten BPEL-Prozesse dem EPK-Modell entspricht, lassen sich die Fehlerquellenschnell identi�zieren. Das Importieren der BPEL-Datei stellt schon den ersten Test des Prozessesdar. Wurden nach dem Import durch den Designer keine Fehler mehr geliefert, so kann anschlieÿendder zweite Test durchgeführt werden. Hierfür wird der interne Simulator gestartet und geprüft, oballe Input- und Output-Variablen während des Nachrichtenaustausches beim Durchlauf des Prozessesrichtig übergeben worden sind. Ist dies der Fall, so wurde der Test erfolgreich abgeschlossen.

Bezugnehmend auf [JMS06] ist der Deployment Process Descriptor eines BPEL-Prozesses aufdie Plattform, auf der dieser auch ausgeführt werden soll, abgestimmt. Es wird ausdrücklich daraufhingewiesen, dass der Deskriptor neu erzeugt werden muss, falls dieser auf einem anderen BPEL-Server ausgeführt werden soll. Aus diesem Grund wurde entschieden die Generierung des Deskriptorsder jeweiligen BPEL-Engine zu überlassen und in den Transformationsprozess nicht mit einzubeziehen.Die Generierung des Deskriptors erfolgt wie folgt. Der auszuführende BPEL-Prozess wird zum Beispielin ActiveBPEL geö�net. Anschlieÿend wird mit der im Tool zur Verfügung gestellten Funktion derDeskriptor erzeugt.

Des Weiteren hat ActiveBPEL Designer noch eine weitere Funktion zu erfüllen. Der dargestellteAblauf des EPK-Geschäftsprozesses aus der Abbildung 6.3 wurde nach dem in diesem Abschnitt be-schriebenen Transformationsprozess nach BPEL abgebildet. Für die Darstellung aller BPEL-Prozessein dieser Arbeit wird die BPEL-Notation des ActiveBPEL Designers, die in der Abbildung 6.5 gezeigtwurde, verwendet.

6.4 Zusammenfassung

In diesem Kapitel wurde ausführlich erläutert, wie das in Kapitel 5 vorgestellte Konzept technischumgesetzt worden ist. Zunächst wurde ein Geschäftsprozess der Reisereservierung im EPK-Diagrammvorgestellt. Anschlieÿend wurden alle Phasen des Transformationsprozesses an diesem Beispiel aus-führlich beschrieben und erläutert. Für die Implementierung des Prototyps wurde auf Java mit XML-Beans-Anbindung zurückgegri�en. Ein wesentlicher Vorteil von XML-Beans ist, dass der erzeug-te BPEL-Prozess validiert erzeugt wird. Der erzeugte BPEL-Code wurde in ActiveBPEL Designerauf die syntaktische Richtigkeit überprüft, getestet und simuliert. Anschlieÿend wurden die in denZwischenphasen erzeugten BPEL-Prozesse in ActiveBPEL importiert, und wurden als Screenshotsim Anhang dieser Arbeit hinterlegt. Der nach allen Phasen des Transformationsprozesses erzeugteBPEL-Prozess wurde in der Abbildung 6.5 dargestellt, und ist mit dem ausgehenden EPK-Diagrammaus der Abbildung 6.3 vergleichbar.

Kapitel 7

Schluss

7.1 Zusammenfassung

Das Ziel der vorliegenden Masterarbeit war der Entwurf eines Konzeptes für die Transformation vonannotierten Geschäftsprozessen nach BPEL und deren Implementierung. In den vorangegangenenKapiteln wurden grundlegende Aspekte und Probleme, die bei der Transformation auftreten können,angesprochen. Es wurden Lösungsvorschläge unterbreitet und gezeigt, wie das Konzept technischrealisiert werden kann.

Eingangs in Kapitel 2 wurden die allgemeinen, theoretischen Grundlagen zu EPK vorgestellt, diedie Grundlage der Masterarbeit bilden. Es wurde erläutert, warum eine Transformation von EPK nachBPEL erforderlich ist.

Anschlieÿend wurden in Kapitel 3 die EPML-Syntax und in Kapitel 4 die Dokumentstruktur vonWSDL und BPEL näher betrachtet. Dieser Schritt war erforderlich, um die Menge relevanter Elementeidenti�zieren zu können.

In Kapitel 5 wurde ein Konzept zur Transformation von annotierten Geschäftsprozessen nachBPEL präsentiert. Es wurde ebenfalls das für die Transformation geeignete Vorgehensmodell einge-führt und erläutert, wie man bei der Überführung der fachlichen Geschäftsprozesse vorgehen soll.Bei dem hier vorgestellten Konzept wird nicht nur der Kontroll�uss eines EPK-Modells nach BPEL,sondern auch der Daten�uss untersucht und zusammen mit den service-relevanten Informationen indem Transformationsprozess übertragen. Für die Transformation des Kontroll�usses nach BPEL spie-len die Work�ows nach van der Aalst et al. eine besondere Rolle. Zwar werden nicht alle Work�owPatterns in beiden Sprachen unterstützt, so erlaubt die übereinstimmende Menge der Work�ow Pat-terns, die Überführung des Kontroll�usses nach BPEL sicherzustellen. Die Transformation folgt dabeider Element-Minimization-Strategie [MLZ05]. Des Weiteren wurde auf die konzeptuellen Unterschie-de der beiden Beschreibungssprachen hingewiesen und die Grenzen einer Konvertierung aufgezeigt.Das erarbeitete Konzept zeigt, dass ein teil-automatisierter Übergang von den betrieblichen Ge-schäftsmodellen, die in EPK-Modellen vorliegen, auf die Implementierungsebene BPEL möglich ist.Dadurch werden die Fehlerquellen, die bei manuellen Nachzeichnen der EPK-Modelle entstehen kön-nen, vermieden und die Übergangszeit erheblich verkürzt. Eine De�nition zu einer vollautomatischenTransformation wurde in Kapitel 5.3.1 gegeben und erläutert, warum es von EPK nach BPEL keinevollautomatische Transformation geben kann. Denn dies würde erfordern, dass man aus EPK allezur Verfügung stehende Elemente und Attribute in BPEL generieren kann. Dies ist leider mit EPKnicht möglich und auch nicht erforderlich. Daher sollte man dringend vermeiden, BPEL-Konstruktemit EPK-Elementen nachzumodellieren. Das Ziel eine möglichst verlustlose Überführung der fachli-chen Geschäftsprozesse in technische SOA-basierte Prozesse zu gewährleisten, konnte mit dem hiervorgestellten Vorgehen realisiert werden. Zwar müssen für die teil-automatische Transformation dieEPK-Diagramme annotiert werden, um einen ausführbaren BPEL-Prozess generieren zu können, al-lerdings erleichtert dieses Vorgehen den Übergang von Business-Ebene auf die Ausführungsebene.Daher muss für die Ausführung der EPK keine eigene EPK-Engine, wie diese von Intas gefordert

96

KAPITEL 7. SCHLUSS 97

wurde, entwickelt werden. Zu guter Letzt wurde das vorgeschlagene Konzept und die Transformationkritisch bewertet.

Aufbauend auf dem in Kapitel 5 vorgestellten Konzept wurde in Kapitel 6 die technische Kon-zeption und Realisierung beschrieben. Für die Implementierung der Transformation wurde Java mitXML-Beans-Anbindung eingesetzt. Für die Datenstruktur der EPK-Diagramme wurde als Eingabefor-mat das EPML-Format verwendet. Die Implementierung hat folgende Punkte, wie die Überführungder EPK-Elemente auf BPEL-Aktivitäten, die Abbildung des Kontroll�usses und des Daten�usseserfolgreich gelöst. Zum Schluss wurde in Kapitel 6 an einem einfachen Beispiel der Ablauf der Trans-formation ausführlich evaluiert. Die in dieser Arbeit durchgeführte Transformation setzt auf keinespezielle Ausführungsumgebung. Der erzeugte BPEL-Code kann auf mehreren Plattformen einge-setzt werden und ist nicht nur auf eine BPEL-Engine beschränkt. Sollten im SOA-basierten Projektplattform-spezi�sche Extensions wie XSLT-Unterstützung oder auch Oracle-TaskManager eingesetztwerden, so ist es möglich, die dafür notwendigen Schritte in den Transformationsprozess einzubau-en.

Im anschlieÿenden Abschnitt wird ein Ausblick gegeben und darauf hingewiesen, wie der in dieserMasterarbeit vorgestellte Transformationsprozess erweitert werden kann.

7.2 Ausblick

Das in dieser Arbeit vorgestellte Konzept und der Wunsch aus betrieblichen Geschäftsprozessenservice-orientierte Prozessbeschreibungen herzustellen, erfordert in folgenden Punkten noch zusätz-liche Forschungsbemühungen. In diesem Abschnitt werden Anregungen für mögliche Erweiterungender vorgestellten Ergebnisse näher beleuchtet.

� Der derzeit entwickelte Generator hat noch Charakter einer Batchverarbeitung. Die Annotatio-nen im EPML-Format wurden hier von Hand durchgeführt. Daher ist wünschenswert, dass einvollständiges Annotationswerkzeug, mit dem es möglich sein soll, EPK-Modelle, um service-orientierte Zusatzinformationen zu erweitern, entworfen wird. Dafür müsste die ohne Annota-tionen erstellte EPML-Datei eines EPK-Geschäftsprozesses in die gra�sche Benutzerober�ächegeladen werden, und die GUI müsste für die zu annotierenden Elemente Eingabemasken liefern.

� Für die Unterstützung der service-orientierten Architektur in betrieblichen Geschäftsprozessenkönnen sowohl eine gra�sche Darstellung der Service-Annotation in Form von zusätzlichenSymbolen als auch ein Assistent für das Mapping der Daten und für die De�nition der XPath-Ausdrücke erstellt werden.

� Ein Konzept entwickeln, wie Web Services gemäÿ vorhandener fachlicher Anforderungen in derVielzahl existierender Web Services e�zient gefunden werden können. WSDL-Beschreibungenalleine liefern nicht genügend Informationen, um eine e�ziente Identi�kation von notwendi-gen Parameter durchzuführen. Als erster Anhaltspunkt können die Ein- und Ausgaben einerEPK-Funktion für die Identi�kation dienen. Um automatisiert bestimmen zu können, ob dieSchnittstellen oder die Operationen von mehreren Web Services identisch sind, können hierfürsemantische Annotationen benutzt werden. Diese können die Identi�kation der erforderlichenParameter erleichtern, und die passenden Ein- und Ausgaben zu den EPK-Funktionen liefern.

� Es ist vorstellbar eine Semantik-Prüfung in das vorgestellte Konzept zu integrierten, welchedie EPK-Modelle vor jeder Transformation überprüfen soll, und dem Benutzer mitteilen, ob dieTransformation durchführbar ist oder nicht. Im Fehlerfall sollten Lösungsvorschläge unterbreitetwerden, die den Transformationsprozess mit geeigneten Fehlermeldungen unterstützen.

Die hier vorgestellten Anregungen sollten in weiteren Arbeiten untersucht und gelöst werden.

Literaturverzeichnis

[Aal] van der Aalst, W.M.P.: Work�ow Patterns Home Page. http://www.tm.tue.nl/it/research/patterns/.� Zuletzt besucht am: 22.2.2007

[Aal99] van der Aalst, Wil M. P.: Formalization and veri�cation of event-driven process chains. In: Information& Software Technology, 41(10), 1999, S. 639�650

[Aal03] van der Aalst, W.M.P. Don't go with the �ow: Web Services composition standards exposed. Trends& Controversies issue of IEEE Intelligent Systems. Jan/Feb 2003

[ABKu00] Anderson, Richard ; Birbeck, Mark ; Kay, Michael ; u.a.: XML Professional. Bonn : MITP-Verlag,2000. � ISBN: 3-8266-0633-7

[ACD+03] Andrews, T. ; Curbera, F. ; Dholakia, H. ; Goland, Y. ; Klein, J. ; Leymann, F. ; Liu, K. ;Roller, D. ; Smith, D. ; Thatte, S. ; Trickovic, I. ; Weerawarana, S. IBM: Business ProcessExecution Language for Web Services Version 1.1 Speci�cation. BEA Systems, IBM Corp., MicrosoftCorp., SAP AG, Siebel Systems. 05.05.2003

[ACKM04] Alonso, Gustavo ; Casati, Fabio ; Kuno, Harumi ; Machiraju, Vijay: Web Services - Concepts,Architectures and Applications. Springer-Verlag Berlin Heidelberg, 2004

[ADH03] van der Aalst, Wil M. ; Dumas, Marlon ; ter Hofstede, Arthur H. Web Service CompositionLanguages: Old Wine in New Bottles? euromicro, p. 298, 29th Euromicro Conference (EUROMICRO'03).2003

[AHKB02] van der Aalst, W.M.P. ; ter Hofstede, A.H.M. ; Kiepuszewski, B. ; Barros, A.P.: Work�owPatterns / Queensland University of Technology. Brisbane, 2002. � QUT Technical report. FIT-TR-2002-02

[AL05] van der Aalst, Wil. M. P. ; Lassen, K. B. Translating Work�ow Nets to BPEL. In BETA WorkingPaper Series, WP 145. August 2005

[Alt06] Altova. Altova XMLSpy 2006. http://www.altova.com/. 2006

[Bac80] Back, R.J. Correctness preserving program re�nements. Technical Report Mathematical Centre Tracs#131, Mathematisch Centrum Amsterdam. 1980

[BDR06] Beer, D. ; Dümmler, J. ; Rünger, G.: Transformation ereignisgesteuerter Prozeÿketten in Work�ow-beschreibungen im XPDL-Format., Oktober 2006

[BK06] Brabänder, Eric ; Klückmann, Jörg: Geschäftsprozessmanagement als Grundlage für SOA. In: JavaSpektrum 05 (2006), S. 32�38

[BPM06a] BPML.org: Business Process Modeling Language (BPML) / BPML.org. 2006. � Forschungsbericht

[BPM06b] BPML.org: Business Process Modeling Notation (BPMN) / BPML.org. 2006. � Forschungsbericht

[CH03] Czarnecki, Krzysztof ; Helsen, Simon: Classi�cation of Model Transformation Approaches. In: OOPS-LA'03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003

[Coa07] Coalition, Work�ow M. http://www.wfmc.org/. Zuletzt besucht am: 30.04.2007. 2007

[CS94] Chen, R. ; Scheer, A.W.: Modellierung von Prozessketten mittels Petri-Netz-Theorie. In: Verö�entli-chungen des Instituts für Wirtschaftsinformatik, (107), 1994

[Dav93] Davenport, Thomas. Process Innovation: Reengineering work through information technology. HarvardBusiness School Press, Boston. 1993

[Del03] DelphiGroup. BPM2003 Market Milestone Report. 2003

[DJM05] Dostal, Wolfgang ; Jeckle, Mario ;Melzer, Ingo: Service-orientierte Architekturen mit Web Services.Konzepte - Standards - Praxis. Spektrum Akademischer Verlag, 2005. � ISBN 3827414571

[DR05] D.Fahland ; Reisig, W. ASM-based semantics for BPEL: The negative Control Flow. Department ofComputer Science, Humboldt-UniversitÄat zu Berlin. March 2005

[Fer04] Ferrara, A. Web services: a process algebra approach. In Proceedings of. ICSOC, pages 242-251. ACM.2004

98


[FFK04] Fisteus, Jesús A. ; Fernández, Luis S. ; Kloos, Calos D. Formal Veri�cation of BPEL4WS BusinessCollaborations. Proceedings of the 5th International Conference on Electronic Commerce and Web Tech-nologies (EC-Web '04), Zaragoza, Spain. To be published in Lecture Notes in Computer Science. August2004

[Fis01] Fischer, Henning: XML in 10 Punkten. 2001. � German W3C O�ce http://www.w3c.de/Misc/XML-in-10-Punkten.html Zuletzt besucht: 12.1.2007

[Fou06a] Foundation, The Apache S. The Log4j Project. http://logging.apache.org/log4j/. 2006

[Fou06b] Foundation, The Apache S. The XMLBeans Project. http://xmlbeans.apache.org/ - Version 2.2.0. 23Juni 2006

[Fou07] Foundation, The Apache S. Apache Web Services Axis. http://ws.apache.org/axis/. 2007

[Gad03] Gadatsch, A. Grundkurs Geschäftsprozess - Management. Methoden und Werkzeuge für die IT-Praxis:Eine Einführung für Studenten und Praktiker. Wiesbaden. 2003

[Gal07] Galileo Air Reisebuchungssystem. http://www.galileo.de/air_vorteile.php. Zuletzt besucht am:22.02.2007

[GL05] Gruhn, V. ; Laue, R.: Einfache EPK-Semantik durch praxixtaugliche Stilregeln. In: Markus Nütt-

gens, Frank J. R. (Hrsg.): EPK2005 - Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessket-ten, CEUR-WS, 2005, S. 176�189

[GL06] Gruhn, Volker ; Laue, Ralf. Validierung syntaktischer und anderer EPK-Eigenschaften mit PROLOG.EPK2006. 2006

[Gut07] Gutbier, Michael. Concept und Implementation for Integrating User Interface Descriptions into BPELProcesses. Masterarbeit. April 2007

[HHW+04] Hors, Arnaud L. ; Hégaret, Philippe L. ; Wood, Lauren ; Nicol, Gavin ; Robie, Jonathan ; Cham-pion, Mike ; Byrne, Steve. Document Object Model. http://www.w3.org/TR/DOM-Level-3-Core/.2004

[HSSH06] Hubacher, J. ; Schneider, G. ; Steffen, T. ; Huth, C.: Geschäftsprozesse im Rahmen einer SOA.In: www.sigs-datacom.de 4 (2006), S. 1�4

[Hun04] Hunter, Jason. http://www.jdom.org/. 9. September 2004

[Inf07] InfoCenter, ActiveBPEL. ActiveBPEL Designer 3.0 Online Help. http://www.activebpel.org/. 2007

[Int06] Intas, Sebastian. Konzept für die Einbindung von Webservices in Ereignisgesteuerte Prozessketten.Masterarbeit. Juli 20.07.2006

[IS] IDS-Scheer: www.aris.com. � Zuletzt besucht am: 13.02.2007

[IS05] Ivanov, Konstantin ; Stähler, Dirk. Prozessmanagement als Voraussetzung für SOA. Fachartikel. 2005

[Jir04] Jiracek, Michael: Ein�uss neuer Technologien auf die Prozesse der Physical- und Financial Supply-Chain.In: Lehrstuhl für Betriebswirtschaftslehre, Wirtschaftsinformatik und Informationsmanagement, 2004

[JMS06] Juric, Matjaz B. ; Mathew, Benny ; Sarang, Poornachandra ; Birmingham (Hrsg.): BusinessExecution Language for Web Services - Second Edition. PACKT Publishing, 2006

[KAD02] Kindler, E. ; van der Aalst, W. ; Desel, J.: On the semantics of EPCs: A vicious circle*. In:Nüttgens, M. Rump, F.J. (Hrsg.): Proceedings of the German Workshop - Geschäftsprozessmanagementmit Ereignisgesteuerten Prozessketten, EPK 2002. Trier, Germany, November 2002

[Kie03] Kiepuszewski, Bartosz: Expressiveness and Suitability of Languages for Control Flow Modelling inWork�ows, A dissertation presented to the Faculty of Information Technology, Queensland University ofTechnology, in ful�lment of the requirements for the degree of Doctor of Philosophy, Diss., 2003

[KK05] Kahl, Timo ; Kupsch, Florian: Transformation und Mapping von Prozessmodellen in verteilten Umge-bungen mit der ereignisgesteuerten Prozesskette. In: Markus Nüttgens, Frank J. Rump (Hrsg.) EPK 2005- Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten - 4. Workshop der Gesellschaft fürInformatik e.V. (GI) - und Tre�en ihres Arbeitkreises - Geschäftsprozessmanagement mit Ereignisgesteu-erten Prozessketten (WI-EPK), 2005

[KK06] Kern, Heiko ; Kühne, Stefan: Merkmale und Werkzeugunterstützung für Modelltransformationen imKontext modellgetriebener Softwareentwicklung. In: Klaus-Peter Fähnrich; Stefan Kühne; Andreas Speck;Julia Wagner (Hrsg.): Integration betrieblicher Informationssysteme: Problemanalysen und Lösungsansätzedes Model-Driven Integration Engineering. Eigenverlag Leiptziger Informatik-Verbund (LIV), September2006

[KKL+05] Kloppmann, Matthias ; Koenig, Dieter ; Leymann, Frank ; Pfau, Gerhard ; Rickayzen, Alan ; vonRiegen, Claus ; Schmidt, Patrick ; Trickovic, Ivana: WS-BPEL Extension for People - BPEL4People.In: A Joint White Paper by IBM and SAP, Juli 2005

http://www.w3c.de/Misc/XML-in-10-Punkten.html

http://www.w3c.de/Misc/XML-in-10-Punkten.html


[Klü06] Klückmann, Jörg. Auf dem Weg zur SOA - Geschäftsprozesse als Voraussetzung. ARIS Expert Paper.September 2006

[Klü07] Klückmann, Jörg. In 10 Schritten zur Business-Driven SOA. ARIS Expert Paper. Januar 2007

[KNS92] Keller, G. ; Nüttgens, M. ; Scheer, A.-W.: Semantische Prozessmodellierung auf der GrundlageEreignisgesteuerter Prozessketten (EPK). In: Scheer, A.-W. (Hrsg.): Verö�entlichung des Instituts fürWirtschaftsinformatik, Heft 89, 1992

[Kop05] Kopp, O.: Abbildung von EPKs nach BPEL anhand des Prozessmodellierungswerkzeugs Nautilus, Uni-versität Stuttgart, Diplomarbeit, 2005

[KTS05] Kühne, Stefan ; Thränert, Maik ; Speck, Andreas: Toward a methodology for orchestration andvalidation of cooperative e-business components. In: Rutherford, Matthew J. (ed.): 7th GPCE YRW 2005Proceedings. Tallinn, Estonia: Institute of Cybernetics at Tallinn Technical University, 2005, S. 29�34

[LA06] Lassen, Kristian B. ; van der Aalst, Wil M. P.: Work�owNet2BPEL4WS: A Tool for TranslatingUnstructured Work�ow Processes to Readable BPEL. In: R. Meersman and Z.Tari, editors: CoopIS/-DOA/ODBASE 2006, Agia Napa, Cyprus, Volume XXXX of Lecture Notes in Computer Science, pagesXX-XX.© Springer-Verlag Berlin Heidelberg 2005. Presented at Cooperative Information Systems, 14thInternational Conference (CoopIS'06) Montpellier, France,, November 1th - 3th, 2006

[Ley01] Leymann, F. Web Services Flow Language. Version 1.0. 2001

[LLSG05] Lübke, Daniel ; Lüecke, Tim ; Schneider, Kurt ; Gómez, Jorge M. Using Event-Driven ProcessChains for Model-Driven Development of Business Applications. 2005

[LSW97a] Langner, P. ; Schneider, C. ; Wehler: Prozeÿmodellierung mit ereignisgesteuerten Prozeÿketten(EPKs) und Petri-Netzen,. In: Wirtschaftsinformatik 39(1997)5, 1997, S. 479�489

[LSW97b] Langner, P. ; Schneider, C. ; Wehler, J.:: Ereignisgesteuerte Prozeÿketten und Petri-Netze. In:Valk, R.; Jantzen, M. (Hrsg.): Bericht Nr. 196, Fachbereich Informatik der Univ. Hamburg, 1997

[Mac04] Maczka, Michal: Java-Algorithmen für DAGs, http://svn.plexus.codehaus.org/browse/plexus/trunk/plexus-containers/plexus-container-new.old/src/main/java/org/codehaus/plexus/internal/util/dag, 2004

[Man03] Mantell, Keith. From UML to BPEL. 2003

[MBN04] Mendling, J. ; Brabenetz, A. ; Neumann, G.: EPML2SVG - Generating Websites from EPMLProcesses. In: M. Nüttgens, F.J. Rump, (Hrsg.): Proc. of the 3rd GI Workshop on Event-Driven ProcessChains (EPK 2004). Luxembourg, Luxembourg, October 2004, S. 55�64

[MCG05] Mens, Tom ; Czarnecki, Krzysztof ; Grop, Pieter V.: A Taxonomy of Model Transformations. In:Bezivin, Jean: Heckel, Reiko (Hrsg.) Language Engineering for Model Driven Software Development.Dagstuhl, Germany, 2005

[Meg] Megginson, David. Simple API for XML. http://www.saxproject.org/

[Men03] Mendling, Jan: Event-Driven-Process-Chain-Markup-Language (EPML): Anforderungen, Konzeptionund Anwendung eines XML-Schemas für Ereignisgesteuerte Prozessketten (EPK). In: BTW Studierenden-Programm, 2003, S. 48�50

[Mie06] Mierzwa, Christof. Transaktionen zwischen Web Services als Basis der Modellierung verschiedenerAnwendungsfälle mit BPEL. Studienarbeit Nr. 2041. Mai 2006

[MLZ05] Mendling, Jan ; Lassen, Kristian B. ; Zdun, Uwe: Transformation Strategies between Block-Orientedand Graph-Oriented Process Modelling Languages / Vienna University of Economics and Business Admi-nistration. 2005 ( Technical Report JM-2005-10-10). � Forschungsbericht

[MLZ06] Mendling, Jan ; Lassen, Kristian B. ; Zdun, Uwe: Experiences in enhancing existing BPM Tools withBPEL Import and Export. In: Fourth International Conference on Business Process Management (BPM),2006

[MN02] Mendling, J. ; Nüttgens, M.: Event-Driven-Process-Chain-Markup-Language (EPML): Anforderungenzur De�nition eines XML-Schemas für Ereignisgesteuerte Prozessketten (EPK) (in German). In: M.Nüttgens, F.J. Rump, eds.: Proc. of the 1st GI Workshop on Event-Driven Process Chains (EPK 2002).Trier Germany, November 2002, S. 87�93

[MN03a] Mendling, J. ; Nüttgens, M.: Konzeption eines XML-basierten Austauschformates für Ereignisgesteu-erte Prozessketten (EPK) (in German). In: Gesellschaft für Informatik (GI) e.V., ed.: Informationssystem-Architekturen: Modellierung betrieblicher Informationssysteme (MoBIS), Rundbrief der GI-FG 5.10 GI-Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, 2003, S. 89�103

[MN03b] Mendling, Jan ; Nüttgens, Markus: EPC Syntax Validation with XML Schema Languages. In:Nüttgens, M. Rump, F.J. (Hrsg.): EPK 2003 - Geschäftsprozessmanagement mit EreignisgesteuertenProzessketten, Proceedings des 2. GI-Workshop EPK 2003, 2003, S. 19�30


[MN03c] Mendling, Jan ;Nüttgens, Markus: XML-basierte Geschäftsprozessmodellierung. In: Uhr, W., Esswein,W.; Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003 / Band II, 2003, S. 161�180

[MN04] Mendling, J. ; Nüttgens, M.: Transformation of ARIS Markup Language to EPML. In: M. Nütt-gens, F.J. Rump, (Hrsg.): Proc. of the 3rd GI Workshop on Event-Driven Process Chains (EPK 2004).Luxembourg, Luxembourg, October 2004, S. 27�38

[MN05] Mendling, J. ; Nüttgens, M.: EPC Markup Language (EPML) - An XML-Based Interchange Formatfor Event-Driven Process Chains (EPC) / Vienna University of Economics and Business Administration.2005. � Forschungsbericht

[MNN04] Mendling, J. ; Neumann, G. ; Nüttgens, M.: A Comparison of XML Interchange Formats for BusinessProcess Modelling. In: F. Feltz, A. Oberweis, B. Otjacques, eds.: Proc. of EMISA 2004 Informationssystemeim E-Business und E-Government� Bd. Vol. 56 of Lecture Notes in Informatics (LNI). Luxembourg,Luxembourg� October 2004, S. 129�140

[MNN05] Mendling, J. ; Neumann, G. ; Nüttgens, M.: Towards Work�ow Pattern Support of Event-DrivenProcess Chains (EPC). In: M. Nüttgens, J. Mendling, eds.: Proc. of the 2nd GI Workshop XML4BPM -XML for Business Process Managementät BTW 2005 Bd. Volume 145. Karlsruhe, Germany, March 2005,S. 23�38

[MZ05] Mendling, J. ; Ziemann, J.: Transformation of BPEL Processes to EPCs. In: M. Nüttgens, F.J. Rump,eds.: Proc. of the 4th GI Workshop on Event-Driven Process Chains (EPK 2005) Bd. CEUR WorkshopProceedings Volume 167. Hamburg, Germany, December 2005, S. 41�53

[NFZ98] Nüttgens, M. ; Feld, T. ; Zimmermann, V.: Business Process Modeling with EPC and UML: Transfor-mation or Integration? In: Schader, M.; Korthaus, A. (Hrsg.): The Uni�ed Modeling Language - TechnicalAspects and Applications, Proceedings (Mannheim, Oktober 1997). Heidelberg, 1998, S. 250�261

[NR02] Nüttgens, M. ; Rump, J.F.: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). In: Desel,J.; Weske, M. (Hrsg.): Promise 2002 - Prozessorientierte Methoden und Werkzeuge für die Entwicklungvon Informationssystemen, Proceedings GI-Workshop und Fachgruppentre�en (Potsdam, Oktober 2002),,2002, S. 64�77

[OAB+05] Ouyang, C. ; van der Aalst, W.M.P. ; Breutel, S. ; Dumas, M. ; ter Hofstede, A.H.M. ;Verbeek, H.M.W.: Formal Semantics and Analysis of Control Flow in WS-BPEL (Revised version). In:BPM Center Report BPM-05-15, BPMcenter.org, 2005

[OADH06a] Ouyang, Chun ; van der Aalst, Wil M. ; Dumas, Marlon ; ter Hofstede, Arthur H. From BusinessProcess Models to Process-oriented Software Systems: The BPMN to BPEL Way. October 2006

[OADH06b] Ouyang, Chun ; van der Aalst, Wil M. ; Dumas, Marlon ; ter Hofstede, Arthur H. TranslatingBPMN to BPEL. Juli 2006

[OAS06a] OASIS: Universal Description, Discovery and Integration / UDDI.org. 2006. � Forschungsbericht.http://www.uddi.org/

[OAS06b] OASIS: Web Services Business Process Execution Language Version 2.0, Public Review Draft. 23rdAugust, 2006. � http://docs.oasis-open.org/wsbpel/2.0/wsbpel-speci�cation-draft.pdf

[ODBH05] Ouyang, Chun ;Dumas, Marlon ; Breutel, Stephan ; ter Hofstede, Arthur H. Translating StandardProcess Models to BPEL. 2005

[OMG05] OMG.org: UML Superstructure Speci�cation, v2.0 (UML 2.0). 2005. �http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf

[Ora06] Oracle: BPEL Tutorial 6: Working with the TaskManager Service. In: Tutorial 6: BPEL and User Tasks(PDF), 2006

[PR05] Pera, O. ; Rintelmann, B.: Von betrieblichen Geschäftsprozessen zu einer SOA. 9. November 2005.� 18. Deutsche ORACLE-Anwenderkonferenz

[Rod97] Rodenhagen, J.: Darstellung ereignisgesteuerter Prozeÿketten (EPK) mit Hilfe von Petrinetzen. Ham-burg, Diplomarbeit Universität Hamburg Fachbereich Informatik (Prof. Valk), Diplomarbeit, 1997

[Sch] Scheer, August-Wilhelm. Geschäftsprozessmodellierung mit der Ereignisgesteuerten Prozesskette

[Sch98] Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. SpringerVerlag, 1998

[Sch01] Scheer, A.-W.: ARIS - Modellierungsmethoden, Metamodelle, Anwendungen. 4. Au�age. SpringerVerlag, 2001

[Sch02] Scheer, A.-W.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. 4. Au�age. Springer Verlag,2002

http://www.uddi.org/

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.pdf

http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf

http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf


[Sch06a] Schluchter, S.: BPMN or EPC? 14.07.2006. �https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3974Zuletzt besucht am: 12.11.2006

[Sch06b] Schneider, Patrick M.: Realisierung von verteilten Anwendungsszenarien anhand einer Service-orientierten Architektur, Universität Stuttgart, Diplomarbeit, 2006

[SDTK05] Specht, Thomas ;Drawehn, Jens ; Thränert, Maik ;Kühne, Stefan: Modeling Cooperative BusinessProcesses and Transformation to a Servce Oriented Architecture. In: Proceedings of the Seventh IEEEInternational Conference on E-Commerce Technology (CEC 2005), 2005

[Sem] Semtalk. http://www.semtalk.com/

[SKW06] Stein, Sebastian ; Kühne, Stefan ; Wagner, Julia: Das Forschungsprojekt OrVia - Orchestrierung undValidierung integrierter Anwendungssysteme. In: Klaus-Peter Fähnrich, Stefan Kühne, Andreas Speck,Julia Wagner (Hrsg.): Integration betrieblicher Informationssysteme: Problemanalysen und Lösungsansätzedes Model-Driven Integration Engineering., Eigenverlag Leipziger Informatik Verbund (LIV), 2006, S. 3�12

[SLH] Schmitz, Volker ; Leukel, Jörg ; Hepp, Martin. Integrierte Spezi�kation und Dokumentation vonE-Business-Standards mit XML-Schema-Annotationen

[Stä06] Stähler, Dirk. ORACLE Business Process Analysis Suite - Entwurf zur methodischen Integration. 2006

[Sta04] Stahl, C.: Transformation von BPEL4WS in Petrinetze (In German), Master's thesis, Humboldt Univer-sity, Berlin, Germany, Diplomarbeit, 2004

[Ste06] Stein, Sebastian: Umsetzung des OrVia-Frameworks mit ARIS. In: Klaus-Peter Fähnrich, Stefan Kühne,Andreas Speck, Julia Wagner (Hrsg.): Integration betrieblicher Informationssysteme: Problemanalysenund Lösungsansätze des Model-Driven Integration Engineering., Eigenverlag Leipziger Informatik Verbund(LIV), 2006, S. 3�12

[Ste07] Stein, Sebastian: Von EPK nach BPEL - Technische Einblicke in ARIS SOA Architect. In: ARIS SOAOnline Seminar vom 17.1.2007, 2007

[TF06a] Thomas, Oliver ; Fellmann, Michael. Semantic Event-driven Process Chains. 2006

[TF06b] Thomas, Oliver ; Fellmann, Michael: Semantische Integration von Ontologien und Ereignisgesteuer-ten Prozessketten. In: EPK 2006 / Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten.Hrsg.:Markus Nüttgens, Frank J. Rump., Jan Mendling - Wien 2006, 2006

[Tha01] Thatte, S. XLANG Web Services for Business Process Design. 2001

[TK07] Thränert, Maik ;Kühne, Stefan. Model-Driven Integration Engineering � Konzept und Einsatzbeispieleaus dem Projekt OrViA. Vortrag. im Dagstuhl-Workshop "Transformation of Legacy Software"(07073),Schloss Dagstuhl. Februar 2007

[TSKM04] Thomas, O. ; Seel, C. ; Kaffai, B. ; Martin:, G. Referenzarchitektur für E-Government (RAfEG):Konstruktion von Verwaltungsverfahrungsmodellen am Beispiel der Planfeststellung. Verö�entlichung desInstituts für Wirtschaftsinformatiok, Heft 179. Dezember 2004

[VA05] Verbeek, H.M.W. ; van der Aalst., W.M.P.: Analyzing BPEL Processes using Petri Nets. In: D.Marinescu, editor, Proceedings of the Second International Workshop on Applications of Petri Nets toCoordination, Work�ow and Business Process Management,. Florida International University, Miami,Florida, USA, 2005, S. 59�78

[Vis01] Visser, E.: A survey of rewriting strategies in program transformation systems. In: Electronic Notes inTheoretical Computer Science 57, 2001

[VZHA05] Vanderhaeghen, D. ; Zang, S. ; Hofer, A. ; Adam, O. XML-based Transformation of BusinessProcess Models - Enabler for Collaborative Business Process Management. 2005

[W3Ca] W3C: Extensible Markup Language (XML). � W3C O�ce http://www.w3.org/XML/

[W3Cb] W3C: Web Services Description Language (WSDL) 1.1. � W3C O�ce http://www.w3.org/TR/wsdl

[W3C99] W3C: XSL Transformations (XSLT) 1.0. 1999. � W3C O�ce http://www.w3.org/TR/xslt

[W3C01] W3C. XML Schema Teil 0: Einführung & Teil 1: Strukturen & Teil 3: Datentypen (Deutsche Überset-zung). http://www.edition-w3c.de/. Mai 2001

[W3C03] W3C: SOAP Version 1.2 Part 1: Messaging Framework. 24.7.2003. � W3C O�cehttp://www.w3.org/TR/soap/

[W3C06] W3C: Web Services Description Language (WSDL) Version 2.0. 2006. � W3C O�cehttp://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/

[W3C07] W3C: XQuery 1.0: An XML Query Language. W3C Recommendation 23 January 2007. Januar 2007. �W3C O�ce www.w3.org/TR/xquery/

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3974

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3974

http://www.w3.org/XML/

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/xslt

http://www.w3.org/TR/soap/

http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/


[WADH02] Wohed, P. ; van der Aalst, W.M.P. ; Dumas, M. ; ter Hofstede, A.H.M.: Pattern-Based Analysisof BPEL4WS / Queensland University of Technology. Brisbane, 2002. � QUT Technical report, FIT-TR-2002-04

[WADH03] Wohed, Petia ; van der Aalst, Wil M. ; Dumas, Marlon ; ter Hofstede, Arthur H.: Analysis ofWeb Services Composition Languages: The Case of BPEL4WS, 2003

[WGL05] Wagner, Julia ; Greca, Calogero L. ; Leyking, Katrina: Serviceorientierte Architekturen als Basis für�exibles Geschäftsprozessmanagement, 2005

[Whi05] White, Stephen A.: Using BPMN to Model a BPEL Process. In: IBM Corp., United States, 2005

[Wit06] Wittmer, Jan. Modellgetriebene Ablaufspezi�kation. Seminar Spezi�kations- und Selektionsmethodenfür Daten und Dienste. Wintersemester 2005/2006

[ZM05] Ziemann, J. ; Mendling, J.: EPC-Based Modelling of BPEL Processes: a Pragmatic TransformationApproach. In: In Proceedings of the 7th International Conference "Modern Information Technology in theInnovation Processes of the Industrial Enterprises MITIP 2005. Genova, Italy, September 2005

Anhang A

WSDL-Syntax

Die vollständige WSDL-Syntax entspricht der Version 1.1.[W3Cb]

De�nitions

1 <wsdl:definitions name="NMToken"? targetNamespace="uri"?>2 3 <wsdl:documentation/>?4 <wsdl:types>  </wsdl:types>?5 <wsdl:message>  </wsdl:message>*6 <wsdl:portType>  </wsdl:portType>*7 8 <wsdl:binding>  </wsdl:binding>*9 <wsdl:service>  </wsdl:wsdl:service>*

10 <-- extensibility element -->*11 </wsdl:definitions>

Types

1 <wsdl:types> ?2 <wsdl:documentation .... />?3 <xsd:schema .... />*4 <-- extensibility element --> *5 </wsdl:types>

Message

1 <wsdl:message name="nmtoken"> *2 <wsdl:documentation .... />?3 <part name="NMToken" element="QName"? type="QName"?/> *4 </wsdl:message>

PortType

1 <wsdl:portType name="NMToken">*2 <wsdl:documentation .... />?3 <wsdl:operation name="NMToken">*4 <wsdl:documentation .... /> ?5 <wsdl:input name="NMToken"? message="QName">?6 <wsdl:documentation .... /> ?7 </wsdl:input>8 <wsdl:output name="NMToken"? message="QName">?9 <wsdl:documentation .... /> ?

10 </wsdl:output>11 <wsdl:fault name="NMToken" message="QName"> *12 <wsdl:documentation .... /> ?13 </wsdl:fault>14 </wsdl:operation>15 </wsdl:portType>

A

ANHANG A. WSDL-SYNTAX B

Operation

1 <wsdl:portType name="NMToken">*2 <-- one-way-operation -->3 <wsdl:operation name="NMToken">*4 <wsdl:input name="NMToken"? message="QName"/>?5 </wsdl:operation>6 <-- request-response-operation -->7 <wsdl:operation name="NMToken">*8 <wsdl:input name="NMToken"? message="QName"/>?9 <wsdl:output name="NMToken"? message="QName"/>?

10 </wsdl:operation>11 <-- solicit-response-operation -->12 <wsdl:operation name="NMToken">*13 <wsdl:output name="NMToken"? message="QName"/>?14 <wsdl:input name="NMToken"? message="QName"/>?15 </wsdl:operation>16 <-- notification-operation -->17 <wsdl:operation name="NMToken">*18 <wsdl:output name="NMToken"? message="QName"/>?19 </wsdl:operation>20 </wsdl:portType>

Binding

1 <wsdl:binding name="NMToken" type="QName">*2 <-- extensibility element -->*3 <wsdl:operation name="NMToken">*4 <-- extensibility element -->*5 <wsdl:input>?6 <-- extensibility element --> </wsdl:input>7 <wsdl:output>?8 <-- extensibility element -->* </wsdl:output>9 <wsdl:fault name="NMToken">*

10 <-- extensibility element -->* </wsdl:fault>11 </wsdl:operation>12 </wsdl:binding>

Service

1 <wsdl:service name="NMToken">*2 <wsdl:port name="NMToken" binding="QName">*3 <-- extensibility element -->4 </wsdl:port>5 <-- extensibility element -->6 </wsdl:service>

ExtensibilityElements

1 <definitions> ...2 <plnk:partnerLinkType name="NCName">3 4 <plnk:role name="NCName">5 <plnk:portType name="NCName"/>6 </plnk:role>7 8 <plnk:role name="NCName">9 <plnk:portType name="NCName"/>

10 </plnk:role>11 </partnerLinkType>12 </definitions>

Anhang B

BPEL-Syntax

Process

1 <process name="ProcessName">2 <partnerLinks>...</partnerLinks>3 <partners>...</partners>4 <variables>...</variables>5 <correlationSets>...</correlationSets>6 <faultHandlers>...</faultHandlers>7 <compensationHandlers>...</compensationHandlers>8 <eventHandlers>...</eventHandlers>9 

10 <activity/>11 </process>

PartnerLinks

1 <partnerLinks>?2 <partnerLink name="NCName"3 <partnerLinkType="QName" myRole="NCName"? partnerRole="NCName"?>+4 </partnerLink>5 </partnerLinks>

Partners

1 <partners>?2 <partner name="NCName">+3 <partnerLink name="NCName"/>+4 </partner>5 </partners>

Variables

1 <variables>2 <variable name="NCName" messageType="QName"? type="QName"? element="QName"?/>+3 </variables>

C

ANHANG B. BPEL-SYNTAX D

Elementare Aktivitäten

Invoke

1 <invoke partnerLink="NCName" portType="QName" operation="NCName"2 inputVariable="NCName" outputVariable="NCName"?3 name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>4 <target linkName="NCName"/>*5 <source linkName="NCName" transitionCondition="bool-expr"?/>*6 <correlations>?7 <correlation set="NCName" initiate="yes|no"? pattern = "in|out|out-in" />+8 </correlations>9 <catch faultName="QName" faultVariable="NCName"?>* <activity/> </catch>

10 <catchAll>? <activity/> </catchAll>11 <compensationHandler>? <activity/> </compensationHandler>12 </invoke>

Receive

1 <receive partnerLink="NCName" portType="QName"2 operation="NCName" variable="NCName"? createInstance="yes|no"?3 name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>4 <target linkName="NCName"/>*5 <source linkName="NCName" transitionCondition="bool-expr"?/>*6 <correlations>?7 <correlation set="NCName" initiate="yes|no"?>+8 </correlations>9 </receive>

Reply

1 <reply partnerLink="NCName" portType="QName" operation="NCName"2 variable="NCName"? faultName="QName"?3 name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>4 <target linkName="NCName"/>*5 <source linkName="NCName" transitionCondition="bool-expr"?/>*6 <correlations>?7 <correlation set="NCName" initiate="yes|no"?>+8 </correlations>9 </reply>

Assign

1 <assign name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 <copy>+5 from-spec6 to-spec7 </copy> </assign>

Wait

1 <wait (for="duration-expr" | until="deadline-expr")2 name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>3 <target linkName="NCName"/>*4 <source linkName="NCName" transitionCondition="bool-expr"?/>*5 </wait>

ANHANG B. BPEL-SYNTAX E

Throw

1 <throw faultName="QName" faultVariable="NCName"? name="NCName"?2 joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>3 <target linkName="NCName"/>*4 <source linkName="NCName" transitionCondition="bool-expr"?/>*5 </throw>

Terminate

1 <terminate name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 </terminate>

Empty

1 <empty name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 </empty>

Strukturierte Aktivitäten

Sequence

1 <sequence name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 <activity/>+5 </sequence>

While

1 <while condition="bool-expr" name="NCName"?2 joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>3 <target linkName="NCName"/>*4 <source linkName="NCName" transitionCondition="bool-expr"?/>*5 <activity/>6 </while>

Switch

1 <switch name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 <case condition="bool-expr">+5 <activity/>6 </case>7 <otherwise>?8 <activity/>9 </otherwise>

10 </switch>

ANHANG B. BPEL-SYNTAX F

Pick

1 <pick createInstance="yes|no"? name="NCName"?2 joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>3 <target linkName="NCName"/>*4 <source linkName="NCName" transitionCondition="bool-expr"?/>*5 <onMessage partnerLink="NCName"6 portType="QName" operation="NCName" variable="NCName"?>+7 <correlations>?8 <correlation set="NCName" initiate="yes|no"?>+9 </correlations>

10 <activity/>11 </onMessage>12 <onAlarm (for="duration-expr" | until="deadline-expr")>*13 <activity>14 </onAlarm>15 </pick>

Flow

1 <flow name="NCName"? joinCondition="bool-expr"? suppressJoinFailure="yes|no"?>2 <target linkName="NCName"/>*3 <source linkName="NCName" transitionCondition="bool-expr"?/>*4 <links>?5 <link name="NCName">+6 </links>7 <activity/>+8 </flow>

Anhang C

Weitere Abbildungen

C.1 EPK-Verknüpfungen

Abbildung C.1: Zulässige Verknüpfungen mit den Operatoren

G

ANHANG C. WEITERE ABBILDUNGEN H

C.2 SOA-Stack

Die nächste Abbildung stellt den SOA-Stack allgemein dar.

Abbildung C.2: SOA-Stack, nach [JMS06]

C.3 Web Service-Stack

Die nächste Abbildung stellt den Web Service-Stack dar, der eine Spezialisierung des SOA-Stacksdarstellt, da dieses durch bestimmte Technologien ausgefüllt ist, die benötigt werden, um das SOA-Konzept verwirklichen zu können.

Abbildung C.3: Web Services Technology Stack, nach [JMS06]

ANHANG C. WEITERE ABBILDUNGEN I

C.4 BPEL-Diagramme aus dem Transformationsprozess

C.4.1 Nach Phase (3)

Abbildung C.4: BPEL-Diagramm nach der ausgeführten Phase (3)

ANHANG C. WEITERE ABBILDUNGEN J

C.4.2 Nach Phase (4)

Abbildung C.5: BPEL-Diagramm nach der ausgeführten Phase (4)

Anhang D

Verschiedenes

D.1 Voraussetzungen für die technische Realisierung

Voraussetzungen für die Bibliotheken, die für die Lau�ähigkeit des Generators erforderlich sind:Java SE 6.0, Log4J, XML-Beans-Jar, generierte EPMLTypes.jar und BPEL-WSDL-Types.jar.

Für die Implementierung mussten zunächst aus den EPML-, BPEL- und WSDL-Schemas XML-Beans erzeugt werden. Der Java-Aufruf für die Generierung der EPML-Beans ist:

1 scomp -javasource 1.5 -src src EPML_12.xsd

Für die Generierung der BPEL- und WSDL-Beans lautet der Aufruf wie folgt:

1 scomp -javasource 1.5 -src src bpel.xsd wsdl.xsd

Wobei zu beachten ist, dass das für BPEL und für WSDL vorliegende Schema in der Version 1.1verwendet wurde. Die erzeugten Source-Files und die Jars mussten anschlieÿend in Eclipse integriertwerden.

D.2 Inhalt der beiliegenden CD-ROM

Die beiliegende CD-ROM enthält folgenden Inhalt:

1. - Masterarbeit im PDF-Format

2. - Masterarbeit im TEX-Format (Erstellt mit LATEX auf MikTex-Basis)

3. - Implementierung

a - Source-Code des Generators

b - Binary-Code des Generators (inkl. JAR-File)

c - Javadoc zum Generator

4. - Verwendete Tools und Bibliotheken

a - Java SE 6.0, Log4J, XML-Beans 2.2.0-r413705

b - EPML, WSDL, BPEL-Schemas

c - Java-Algorithmen für DAGs [Mac04]

Diese Arbeit wurde mit Hilfe von LATEX auf MikTex-Basis und Microsoft Visio 2007 erstellt.

K

Abbildungsverzeichnis

2.1 EPK-Notation eines Geschäftsprozesses ohne Web Service-Unterstützung . . . . . . . . . . . 14

3.1 Ablauf der Transformation über EPML und des Mappings auf BPMN . . . . . . . . . . . . . 223.2 Struktur von typeEpcElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Abhängigkeiten zwischen WSDL und BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Erläuterungen zur Verwendung von �ow und link . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Übergang vom der Geschäftsprozessebene auf die Service-Prozessebene . . . . . . . . . . . . 485.2 Flache Hierarchie eines EPK-Diagramms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 Vergleich der XLANG- und WSFL-basierten Darstellung eines Parallel Split- und eines Synchronisation-

Work�ow Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.4 Vergleich der XLANG- und WSFL-basierten Darstellung eines Exclusive Choice- und eines Sim-

ple Merge-Work�ow Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.5 Anbindung an manuelle Tasks mittels des Oracle TaskManager Services, nach [Ora06] . . . . 695.6 De�nition des expliziten Daten�usses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.7 Zuordnung von Informationsobjekten zu MessageType, nach [WGL05] . . . . . . . . . . . . . 735.8 Variablenzuordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.1 Marshaling und Unmarshaling in XML-Beans . . . . . . . . . . . . . . . . . . . . . . . . . . 826.2 Geschäftsvorfall ohne Web Service-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . . 846.3 Geschäftsvorfall mit Web Service-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.4 Abbildung der mit <invoke>-annotierten EPK-Funktion zu Invoke-Aktivität . . . . . . . . . . 926.5 Erzeugte BPEL-Prozess durch den Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 94

C.1 Zulässige Verknüpfungen mit den Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . GC.2 SOA-Stack, nach [JMS06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HC.3 Web Services Technology Stack, nach [JMS06] . . . . . . . . . . . . . . . . . . . . . . . . . HC.4 BPEL-Diagramm nach der ausgeführten Phase (3) . . . . . . . . . . . . . . . . . . . . . . . IC.5 BPEL-Diagramm nach der ausgeführten Phase (4) . . . . . . . . . . . . . . . . . . . . . . . J

L

Tabellenverzeichnis

5.1 Unterstützung der High-Level-Konzepte in BPM, Auszug aus [MNN04] . . . . . . . . . . . . 555.2 Work�ow Patterns in untersuchten Sprachen, Auszug aus [ADH03] . . . . . . . . . . . . . . . 575.3 Transformationsstrategien, Auszug aus [MLZ05] . . . . . . . . . . . . . . . . . . . . . . . . . 615.4 Äquivalente Elemente in beiden Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

M

Index

<ExtensibilityElements/>, 32<activity/>, 34<assign/>, 36<attributeTypes>, 24<binding/>, 32<directory>, 24<empty/>, 35<epc>, 24<�ow/>, 36<invoke/>, 35<link/>, 36<message/>, 32<operation/>, 32<partnerLink/>, 34<partners/>, 34<pick/>, 36<port/>, 32<portTypes/>, 32<receive/>, 35<reply/>, 35<scope/>, 36<sequence/>, 36<service/>, 32<switch/>, 36<types/>, 32<variables/>, 34<while/>, 36

Abstrakte State Machines, 9Abstraktionsebene, 2, 49, 51, 77AML, 21AND, 14, 59, 64, 88Anforderungen an EPML-Schema, 22Annotationswerkzeug, 45Anwendungskomponente, 15ARIS-Konzept, 6ARIS-Methode, 11Assignments, 40automatisierte Funktion, 85

Bewertung der Grenzen, 76Black-Box, 85Blackboard-Ansatz, 71Bottom-Up-Modellierung, 47

BPEL, 1, 6, 33, 71, 82BPEL-Engine, 13BPEL-Prozess, 7BPEL-Syntax, 31, 33BPM, 5, 8BPML, 7BPMN, 5, 43, 80, 95Business Process, 4

DAGs, 59Daten�uss, 5, 45, 55, 72Dekomposition, 2, 49, 51, 65Deployment Process Descriptor, 95Dokumentstruktur, 19DOM, 82

Eclipse Web Tools Plattform, 81eFADs, 11Elementare Aktivitäten, 34Elemente von EPK, 13EPK, 1, 5, 6EPK-Modell, 12, 88EPK-Semantik, 15EPK-Syntax, 15, 16, 23, 45, 51EPML, 20, 82EPML-Format, 97EPML-Struktur, 23, 88EPML-Syntax, 96Ereignisse, 13Exception Handler, 55explizite Daten�uss, 71Expressions, 39

fachlichen Anforderungen, 2, 10, 42, 51, 77, 78Flache Hierarchie, 16funktionale Dekomposition, 10Funktionen, 13

Galileo-Air-System, 6Geschäftsprozesse, 4, 11, 16, 18, 65, 77, 79Geschäftsprozessmodellierung, 9Gründe für die Transformation, 8Grammatik, 23Graph-orientierte Charakterisierung der EPK,

16

N

Index O

Grundlagen, 4

hierachische EPK, 17High-Level-Konzepte, 54HTML, 20

Informationsobjekt, 15Integrationsprozess, 1Interaktionsmuster, 10

Java SE 6, 81

Kontroll�uss, 5, 14, 45, 54, 59Konzept, 42

Log4J, 82

MDA, 11, 22Metamodell, 22Migration, 8Modelltransformation, 8

Nachfolger-Def., 17Nautilus-EPK-Syntax, 9nicht zusammenhängend, 16

Ontologie-Ansatz, 11OR, 14, 64, 88Orchestrierung, 6Organisationseinheit, 15OrViA, 10OWL, 11

Petri Netze, 12PIM, 11, 22plattformunabhängig, 19, 81PNML, 20Prototyp, 12, 81prototypische Realisierung, 81Prozess-Algebra, 9Prozess-Kollaboration, 7Prozessanalyse, 1Prozessoptimierung, -simulation, 1Prozessschnittstelle, 14PSM, 11, 22

SAX, 82Semantik, 8Semantik-Prüfung, 97semantische Annotation, 11, 97semi-formale Sprache, 16Service-Komposition, 7Simulationskomponente, 21SOA, 5, 7, 65

SOAP, 7Strukturierte Aktivitäten, 36SVG, 20syntaktische Richtigkeit, 23Syntax, 8

Technische Konzeption, 81Testen des BPEL-Prozesses, 94Tiefensuche, 90Top-Down-Modellierung, 11, 47, 83Transformationskonzept, 9, 74Transformationsphasen, 81Transformationsprozess, 44

UML, 5UML AD, 12

Verfeinerung, 2, 48, 49, 65verlustlose Transformation, 2, 8vertikale Transformation, 2Verwandte Themen, 9Verzweigungsoperatoren, 14vollautomatische Transformation, 56Vorgänger-Def., 17Vorgehensmodell, 42, 47

Web Services, 5Work�ow, 4Work�ow Nets, 12Work�ow Netze, 9Work�ow Patterns, 9, 56, 58, 96WSDL, 7, 31, 45, 46, 50, 52, 95WSDL-Syntax, 31WSFL, 6, 61, 71

XLANG, 6, 60, 71XMI, 20XML, 19XML-Beans, 82, 88XML-Cursor, 82XML-Dialekte, 20XML-Schema, 19XML-Transformationsformen, 20XOR, 14, 88XPath-Ausdrücke, 97XPDL, 7, 12XSLT, 81, 97

YAWL, 12

Ziel der Transformation, 13Zusammenfassung, 18, 30, 41, 79, 95, 96zusammenhängend, 16Zyklen, 17, 59, 61, 62, 80

Eidesstattliche Erklärung

Hiermit erkläre ich, dass ich diese Arbeit selbstständig verfasst und keine ande-ren als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Stellen, diewörtlich oder sinngemäss aus verö�entlichen und nicht verö�entlichen Schriftenentnommen wurden, sind als solche kenntlich gemacht.

Hannover, 10. Mai 2007. . . . . . . . . . . . . . . . . . . . . . . . . . .

Oleg Schmelzle

P

Transformation von annotierten Gesch¤ftsprozessen nach BPEL

Documents

Transcript of Transformation von annotierten Gesch¤ftsprozessen nach BPEL