I

Inhaltsverzeichnis

Abbildungsverzeichnis.   III

Listingverzeichnis   IV

Tabellenverzeichnis   V

Abk  ürzungsverzeichnis  VI

1  Einleitung  1

2  Methodische Grundlagen zu WS-CDL und SOM  2

2.1  Das Choreographiekonzept im Kontext verteilter Systeme  2

2.2  Die Web Service Choreography Description Language  3

2.2.1  Ziele von WS-CDL  4

2.2.2  Der statische Teil von WS-CDL - Typdefinitionen  5

2.2.3  Der dynamische Teil von WS-CDL - Choreographies und Activities  6

2.3  Workflowmodellierung mit Hilfe des Semantischen Objektmodells  7

2.3.1  Architekturrahmen und Vorgehensmodell des SOM  8

2.3.2  Das Vorgangsereignisschema  8

2.3.3  Das Vorgangsobjektschema  9

3  Einführung in die Fallstudie  9

3.1  Merkmale eines Medizinischen Versorgungszentrums  10

3.2  Geschäftsprozessmodell des MVZ Care  10

4  Modellbasierte Ableitung der WS-CDL-Spezifikationen aus dem  

Vorgangsobjektschema   14

4.1  Anforderungen an das VOS  15

4.2  Typspezifikationen des WS-CDL-Dokuments  16

4.2.1  Spezifikation von RoleTypes und ParticipantTypes  16

4.2.2  Spezifikation der RelationshipTypes  18

4.2.3  Spezifikation der InformationTypes  19

4.2.4  Spezifikation von Tokens und TokenLocators  20

4.2.5  Spezifikation von ChannelTypes  21

4.3  Spezifikation der Choreographies des WS-CDL-Dokuments  23

4.3.1  Abgrenzen von Subchoreographien  24

4.3.2  Spezifikation der Variables und Relationships in einer Choreography  25

4.3.3  Spezifikation von Interactions  26

4.3.4  Spezifikation der Ablaufstruktur in WS-CDL  29

5  Open-Source Tool-Unterstützung für WS-CDL  32

5.1  Pi4SOA  32

5.1.1  Choreography Description Designer  32

5.1.2  Szenario-Editor  33

5.1.3  Bewertung  33

5.2  WS-CDL Eclipse  34

II

5.2.1  Einführung in WS-CDL Eclipse  34

5.2.2  Bewertung  35

5.3  WS-CDL Execution  35

5.3.1  Choreographien mit Hilfe der Ausführungsengine simulieren  36

5.3.2  Bewertung  36

5.4  Fazit und Auswahl eines Editors zur Durchführung der Fallstudie  37

6  Validierung der Ergebnisse anhand der Fallstudie MVZ Care  37

6.1  Das VOS des MVZ Care  37

6.1.1  Rollenzuweisungen und Beziehungen  40

6.1.2  Spezifikation weiterer Basisdatentypen  41

6.1.3  Spezifikation des Nachrichtenflusses  42

6.2  Bewertung der Fallstudienergebnisse  45

7  Kritik und Alternativen zu WS-CDL  45

7.1  Kritik an WS-CDL  45

7.2  BPEL4Chor: Choreographiebeschreibungen auf Grundlage von WS-BPEL  46

7.3  Bewertung von BPEL4Chor im Vergleich zu WS-CDL  49

8  Fazit und Ausblick  51

9  Literaturverzeichnis  52

III

Abbildungsverzeichnis   

Abb.  1 Choreographie versus Orchestrierung (Peltz 2003, S. 47)  

Abb.  2 UML Sequenzdiagramm: Radiologische Untersuchung  

Abb.  3 WS-CDL Activities (Barros et al. 2005, S. 8)  

Abb.  4 SOM Unternehmensarchitektur (Ferstl und Sinz 2008, S.193)  

Abb.  5 SOM Vorgehensmodell (Ferstl und Sinz 2008, S.195)  

Abb.  6 VEZ Medizinische Behandlung  

Abb.  7 Generisches Leistungsnetz aus dem Bereich der medizinischen  

Versorgung  (Pütz et al. 2009, S. 6)  

Abb.  8 IAS des Fallbeispiels MVZ Care  

Abb.  9 VES des Fallbeispiels MVZ Care  

Abb.  10 Metamodell VOS (Ferstl und Sinz 2008, S. 228)  

Abb.  11 VOS Radiologische Untersuchung  

Abb.  12 Relationships und VariableDefinitions für das Orthopädie-Radiologie-  

Beispiel   

Abb.  13 Ablaufstruktur des Orthopädie-Radiologie-Beispiels  

Abb.  14 VOS des MVZ Care  

Abb.  15 Rollen und Beziehungen MVZCare.  

Abb.  16 ChannelTypes des MVZ Care  

Abb.  17 InformationTypes des MVZ Care  

Abb  18 ChoreographyFlow des MVZ  

Abstrakte Syntax für RoleTypes und ParticipantTypes (Kavantzas et al. Listing 1

2005) ................................................................................................................. 16

Listing 2 RoleTyps und ParticipantTypes des Orthopädie-Radiologie-Beispiels ............ 18

Listing 3 Abstrakte Syntax für RelationshipTypes (Kavantzas et al. 2005) .................... 18

Listing 4 RelationshipType des Orthopädie-Radiologie-Beispiels .................................. 18

Listing 5 Abstrakte Syntax für InformationTypes (Kavantzas et al. 2005) ..................... 19

InformationTypes für das Orthopädie-Radiologie-Beispiel .............................. 20 Listing 6

Listing 7 Abstrakte Syntax für Token und TokenLocators (Kavantzas et al. 2005) ........ 20

Token und TokenLocators für das Choreographie-Radiologie-Beispiel ........... 21 Listing 8

Listing 9 Abstrakte Syntax für ChannelTypes (Kavantzas et al. 2005) ........................... 21

Listing 10 ChannelTypes für das Orthopädie-Radiologie-Beispiel ................................... 23

Listing 11 Abstrakte Syntax für ein choreography-Element ....................................... 24

Abstrakte Syntax für eine Interaction ............................................................... 26 Listing 12

Tabelle 1 Vergleich WS-CDL und BPEL4Chor (Decker und Overdick 2006, S. 32

und Decker et al. 2007, 302) ............................................................................. 50

1

1 Einleitung

Hochflexible Geschäftsprozesse stellen erhöhte Anforderungen an die Flexibilität der sie unterstützenden Anwendungssysteme. Ihre Charakterisierung wird anhand von drei Kriterien vorgenommen: Planbarkeit des Prozesses, zeitliche Überlappung von Run-Time und Build-Time sowie dem Grad der Kontextintensivität (Pütz et al. 2009, S. 1).

Für eine adäquate IT-Unterstützung dieser Geschäftsprozesse bietet sich eine serviceorientierte Anwendungslandschaft an, in der das Zusammenspiel einzelner Services zur Unterstützung verschiedener Geschäftsprozesse flexibel gestaltbar ist.

Das Semantische Objektmodel (SOM) kann zur Modellierung eines solchen hochflexiblen Geschäftsprozesses benutzt werden. Konkrete Ablaufstrukturen auf Anwendungssystemebene werden dabei in einem Vorgangsobjektschema (VOS) erfasst. Auf oberster Ebene der Serviceimplementierung ist WS-CDL als XMLbasierte Beschreibungssprache für das Zusammenspiel und die Choreographie autonomer Services als Standard zu nennen.

Ziel dieser Arbeit ist es, eine Brücke zwischen einem Anwendungssystemmodell nach SOM-Methodik und einem WS-CDL-Dokument zu schlagen. Dazu sollen die semantischen Gemeinsamkeiten beider Modelle ausgearbeitet werden und anschließend in eine Methodik zur Ableitung von WS-CDL-Spezifikationen aus einem VOS einfließen.

Die Methodik selbst soll mit Hilfe einer Fallstudie aus dem Bereich der Medizinischen Versorgung validiert werden. Dazu werden zunächst zur Auswahl stehende Werkzeuge zur Unterstützung von WS-CDL vorgestellt, namentlich die Pi4soa Tool-Suite, WS-CDL Eclipse und WS-CDL+ Execution. Hiervon wird eines zur Verwendung empfohlen werden, das auch zur Durchführung der Fallstudie verwendet werden soll.

Im letzten Teil der Arbeit werden noch Kritikpunkte an WS-CDL angeführt und mit BPEL4Chor eine alternative Choreographiesprache vorgestellt.

2

2 Methodische Grundlagen zu WS-CDL und SOM

Dieses Kapitel soll einige methodische Grundlagen zu WS-CDL (Kavatzas et al. 2005) und dem Semantischen Objektmodell (SOM) (Ferstl und Sinz 2008 S. 192 -229) vermitteln.

2.1 Das Choreographiekonzept im Kontext verteilter Systeme

Die Beschreibung der Komposition von Webservices kann aus zwei sich überlappenden Betrachtungswinkeln erfolgen, dem Choreographie- und dem Orchestrierungskonzept (Peltz 2003, S. 46). Der Begriff Choreographie kann daher am besten in Abgrenzung zu Orchestrierung erläutert werden.

„Die Service-Orchestrierung steht für die Veröffentlichung eines technischen Prozesses, der über verschiedene andere Services läuft, die in der Regel bei demselben Service-Mediator registriert sind“ (Mathas 2008, S. 211). Das Zusammenwirken der verschiedenen Services wird also hierarchisch von einer zentralen Instanz gesteuert (Ferstl und Sinz 2008, S. 430). Dabei werden sowohl der Nachrichtenaustausch als auch interne Vorgänge der Services beschrieben (Barros et al 2005, S. 5), wobei sich diese Beschreibung auf die Sicht des Service-Anbieters beschränkt. Als wichtigster Standard zur Service-Orchestrierung ist in diesem Zusammenhang WS-BPEL zu nennen (Hohpe 2007, S. 444).

Eine Choreographie in verteilten Systemen beschreibt hingegen das aus Außensicht beobachtbare Verhalten verschiedener kollaborierender Parteien zur Erreichung eines gemeinsamen Ziels aus einem globalen Betrachtungswinkel. Alle beteiligten Services agieren dabei als gleichberechtigte autonome Teilkomponenten; es gibt also keinen Service, der die Kontrolle über den Ablauf des Prozesses hat (Barros et al. 2005, S. 2f.). Hauptaugenmerk bei dieser Art der Systembeschreibung liegt auf den jeweiligen Serviceschnittstellen und den auszutauschenden Nachrichten (Mathas 2008, S 205). Serviceinterne Aktivitäten werden nicht berücksichtigt. Der Zustand einer Choreographie ergibt sich daher aus den bisher gesendeten Nachrichten der beteiligten Teilnehmer (Holpe 2007, S. 443f.). Ferner umfasst eine Service-Choreographie dabei auch einzuhaltende Bedingungen und vorkommende Abhängigkeiten für die erfolgreiche Durchführung des Prozesses (Barros et al. S. 2). Der derzeitige Favorit für die Spezifikation von Webservice-Choreographien ist WS- CDL (Holpe 2007, S. 444).

3

Folgendes Beispiel in Anlehnung an die Fallstudie dieser Arbeit, die in Kapitel 3 eingeführt wird, soll das Konzept hinter dem Begriff Choreographie erläutern. In einem Medizinischen Versorgungszentrum gibt es sowohl eine Fachabteilung Orthopädie als auch eine Fachabteilung Radiologie. Die Kooperation zwischen diesen Abteilungen erfolgt über das Verhandlungsprinzip, die internen Vorgänge sind für den jeweils anderen also transparent. Für das gemeinsame Ziel eines radiologischen Ergebnisses muss zunächst die Orthopädie eine solche Anfrage an die Radiologie schicken. Die Choreographie befindet sich nun in einem Zustand „Warte auf Radiologieantwort“. Wie die Radiologie intern die Anfrage verarbeitet und die Untersuchung durchführt, ist aus Sicht einer Choreographie nicht relevant. Die nächste nach außen sichtbare und damit relevante Aktivität ist die Übermittlung des radiologischen Ergebnisses an die Orthopädie.

2.2 Die Web Service Choreography Description Language

Die Web Service Choreography Description Language (WS-CDL) ist eine XML- basierte Sprache, die von der Web Services Choreography Working Group des W3C

4

entwickelt wurde und seit 2004 in der Version 1.0 vorliegt (Kavantzas et al. 2005). WS-CDL basiert formal auf der algebraischen Sprache pi-Kalkül (Bichler und Setzer 2008) und geht unter anderem aus der Modellierungssprache Web Service Choreography Interface (WSCI) hervor (Austin et al. 2004).

Ein WS-CDL-Dokument kann als Vertrag zwischen beliebig vielen kollaborierenden Webservices verstanden werden, in dem die Austauschabfolge von Nachrichten und möglichen Ausnahmebehandlungen festgehalten wird (Kavantzas et al. 2005).

2.2.1 Ziele von WS-CDL

Bei der Entwicklung von WS-CDL wurden folgenden Ziele verfolgt (Kavantzas et al. 2005):

• Wiederverwendbarkeit: Choreographien sollten in verschiedenen Kontexten mit unterschiedlichen Teilnehmern wiederverwendet werden können.

• Kooperation: Choreographien sollten die Kooperation unabhängiger Teilnehmer mit Hilfe von Nachrichtenaustauschbeziehungen beschreiben.

• Kooperation mehrerer Teilnehmer: An einer Choreographie sollten beliebig viele Services teilnehmen können.

• Semantik: Eine WS-CDL-Dokument sollte in seiner semantischen Bedeutung für einen Menschen durch Dokumentationen verständlich sein.

• Kombinierbarkeit: Choreographien sollten in beliebiger Form zu neuen Choreographien kombinierbar sein.

• Modularität: Choreographien sollten so modular gestaltet werden, dass sie als Teilkomponenten in andere Choreographien eingebunden werden können.

• Informationsgetriebene Kollaborationen: Der Status der Choreographie und das Verhalten der Teilnehmer sollte durch die bereits ausgetauschten Nachrichten beeinflusst werden.

• Informationsabgleich: Teilnehmer einer Choreographie sollten die Möglichkeit haben, globale Informationen und Variablen miteinander auszutauschen und abzugleichen.

• Ausnahmebehandlung: In einer Choreographie sollte auf Ausnahmen und Fehler im Ablauf angemessen reagiert werden können.

5

• Transaktionalität: Beteiligte Services sollten die Koordination des Ergebnisses der gemeinsamen Choreographie durch eigene Regeln und Ziele gewährleisten können.

• Kompatibilität zu anderen Standards: Die Kompatibilität zu komplementären Spezifikationen wie WS-CAF, WSS, WS-BPEL und weiteren sollte gewährleistet werden.

2.2.2 Der statische Teil von WS-CDL - Typdefinitionen

Das Wurzelelement eines WS-CDL-Dokumentes ist das Package. RoleTypes, ParticipantTypes, RelationshipTypes, ChannelTypes und InformationTypes, Tokens und TokenLocators dienen der Spezifikation der beteiligten Entitäten und Rollen der Kollaboration. Sie können damit dem statischen Teil eines WS-CDL-Dokuments zugeschrieben werden (Fredlung 2006, S. 108).

InformationType: InformationTypes definieren die Arten von Informationen, die zwischen RoleTypes ausgetauscht werden können (Kavantzas et al. 2005). Im Eingangsbeispiel bräuchte man zwei InformationTypes, ein RadRequestType und ein RadResponseType. Möglich wäre auch ein RadResponseFaultType für einen auftretenden Fehlerfall bei der Untersuchung in der Radiologie.

Token und TokenLocator: Ein Token kann als Alias für spezielle Informationen innerhalb eines InformationTypes verwendet werden. Ein TokenLocator spezifiziert mittels einer XPath-Angabe den möglichen Zugriff auf diese Information innerhalb eines InformationTypes (Kavantzas et al. 2005).

RoleType: Services können in eine oder mehrere „Rollen“ schlüpfen, die ein oder mehrere Verhaltensweisen repräsentieren (Kavantzas et al. 2005). Im Eingangsbeispiel gibt es zwei RoleTypes, eine RadRequestorRole (Orthopädie) und eine RadSupplierRole (Radiologie).

ParticipantType: Ein ParticipantType gruppiert alle RoleTypes, die zwingend zusammen durch einen Service realisiert werden müssen (Kavantzas et al. 2005). Im Beispiel könnten zwei Webservices Orthopädie (RadRequestorRole) und Radiologie (RadSupllierRole) als Participants auftreten.

RelationshipType: Die Zuordnung zwischen zwei interagierenden RoleTypes wird in einem RelationshipType erfasst (Kavantzas et al. 2005).