Fakultät Informatik, Institut für Systemarchitektur, Professur für Rechnernetze GROSSER BELEG

Transkript

1 Fakultät Informatik, Institut für Systemarchitektur, Professur für Rechnernetze GROSSER BELEG Synchronisation von WSDL und BPEL Beschreibung in Web Services Kompositionen Bearbeiter: Hongming Liu Betreuer: Dipl.-Inf. Anja Strunk Verantwortlicher Hochschullehrer: Prof. Dr. rer. Nat. habil. Dr. h. c. A. Schill Eingereicht am:

2 Synchronisation von WSDL und BPEL Beschreibung in Web Service Kompositionen - 2 -

3 Synchronisation von WSDL und BPEL Beschreibung in Web Service Kompositionen - 3 -

4 Synchronisation von WSDL und BPEL Beschreibung in Web Service Kompositionen Selbständigkeitserklärung Hiermit erkläre ich, Hongming Liu, die vorliegende Belegarbeit selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben. Dresden, den Hongming Liu

5 Synchronisation von WSDL und BPEL Beschreibung in Web Service Kompositionen Inhaltverzeichnis 1 Einführung Ziel Aufbau Grundlagen Web Service Architektur Protokolle Übersicht WSDL Abstrakte Schnittstelle Konkrete Implementierung BPEL Geschäftsprozess mit BPEL Terminologie Aktivitäten Basis Aktivitäten Strukturierte Aktivitäten EMF EMF Modell Notifikation und Adapter Zusammenfassung Analyse Modell Analyse Elemente mit direkter Beziehung Elemente mit indirekter Beziehung Anforderung State-of-the-Art Zusammenfassung Entwurf System Architektur Funktionsweise Zusammenfassung Implementierung Model Listener BPEL Listener WSDL Listener Synchronisation Reference BPEL ResourceSet Locater Zusammenfassung Validierung Allgemeine Validierung Statistik Performance Zusammenfassung Zusammenfassung Anhang Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis...82

6 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen - 6 -

7 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Einführung SOA (Service-oriented Architecture) ist eine sehr begehrte Forschungsrichtung im Hochschulen und Unternehmen. Sie bietet eine flexiblere und effizientere Systemarchitektur als die Traditionelle. Durch die zunehmende Popularität des Internets, spielen Web Services als einer Implementierung der SOA eine immer wichtigere Rolle. Dabei werden WSDL (Web Service Description Language) und BPEL (Business Process Execution Language) jeweils für einzelne Dienst und Dienstkompositionen benutzt. 1.1 Ziel WSDL und BPEL sind beide XML-basierte Beschreibungssprachen. Sie arbeiten im Geschäftsprozess zusammen. Deswegen gibt es immer einige Beziehungen zwischen den Elementen, die in den unterschiedlichen Sprachen liegen. Während der Bearbeitung der WSDL- oder BPEL-Datei wird ein Synchronisationsverhalten durchgeführt, um bestimmte Elemente, die Referenzierungsbeziehungen enthalten, miteinander zu verbinden. Die Synchronisation wird in der Entwicklungsplattform Eclipse realisiert die schon Editoren für beide Sprachen bereitstellt. 1.2 Aufbau Diese Arbeit ist wie folgt aufgebaut. Das nächste Kapitel beschäftigt sich mit einigen Grundlagen, auf denen diese Arbeit basiert, wie z. B. Web Services, BPEL und WSDL Sprache. Dazu gehört außerdem das EMF Model, welches das Ziel der Synchronisation realisiert. In Kapitel 3 werden zuerst alle Fälle der Synchronisation analysiert. Danach folgt im Kapitel 4 der Entwurf. Kapitel 5 behandelt die konkrete Implementierung dieser Arbeit. In Kapitel 6 wird die Implementierung validiert und zum Schluss folgt in Kapitel 7 eine Zusammenfassung dieser Arbeit.

8 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen - 8 -

9 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Grundlagen In der Einführung werden unter anderem Begriffe wie Web Services, WSDL, BPEL und EMF verwendet. Die Bedeutung der Begriffe wird dort jedoch eher exemplarisch gebraucht. Für die Fundierung der im Anschluss vorgestellten Beziehungskonzepte ist allerdings ein tieferes Verständnis erforderlich. In diesem Kapitel werden daher die notwendigen theoretischen Grundlagen beschrieben. 2.1 Web Service Das World Wide Web (WWW) wird mehr und mehr für die Anwendung-zu-Anwendung Kommunikation benutzt. Jede Anwendung wird dabei als Schnittstelle abstrahiert, mit XML-basierten Standards beschrieben, bei einem Repository registriert und unter einen eindeutigen URI 1 (Uniform Resource Identifier) zur Verfügung gestellt. Diese spezielle Anwendung nennt man Web Service oder Webdienst. Wegen der Besonderheiten (z. B. self-contained-eigenschaft) hat sich die Web Service Technologie schnell entwickelt und verbreitet. Ein Web Service Client benötigt nur XML 2 als Nachrichtenprotokoll und HTTP 3 als Transportprotokoll um mit einem Server zu kommunizieren. Serverseitig ist nur ein Web Server und ein SOAP 4 Server erforderlich. Außerdem ist ein Web Service self-described. Client und Server interessiert nur Format und Inhalt der Nachrichten. Die Implementierung bleibt für sie unwichtig. Die Definition des Nachrichtenformates wird zusammen mit den Nachrichten übertragen. Deswegen ist kein explizites Werkzeug zur Übersetzung der Nachrichten nötig und aus diesem Grund ist die Web Service Technologie internetübergreifend. Zuletzt ist die Web Service Technologie implementierungsunabhängig, d.h. interoperable. Client und Server können durch verschiedene Sprachen und Plattformen realisiert werden. Der vorhandene Code braucht keine weiteren Änderungen, um Web

10 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Service zu unterstützen. Das Fundament der Web Service Technologie sind hauptsächlich offene Standards wie z.b. XML und HTTP. Diese Technologie wird meistens von Open-Source Projekten bereitgestellt. Deswegen ist es einfach zum Benutzen und Entwickeln. Web Service sind auch sehr flexibel. Die Nutzung des dynamischen elektronischen Geschäftsprozesses wird realisierbar, indem die Beschreibung und das Auffinden des Web Services durch WSDL und UDDI automatisch erfolgt. Web Services sind kombinierbar. Dabei nutzt man die Technologie des Arbeitsflusses und den Aufruf des untergeordneten Web Services. Durch die Verbindung einzelner Web Services, können fortgeschrittene Geschäftsprozess durchgeführt werden. Deshalb sind auch komplexe Anforderungen der Kunden realisierbar. Gleichzeitig wird der Entwicklungszyklus verkürzt. Web Services basieren auf Technologien, die reif und auf hohen Qualitäten sind. Deswegen wird die Fehler, die möglicherweise in der Web Service System auftreten wird, minimiert, sowie die System ist robuster und stabiler. Aus diesem Grund ist es besser als andere verteilte Systemarchitektur. Web Services sind loosely-coupled. Im Vergleich mit dem traditionellen Anwendungsentwurf ermöglichen Web Services die erneute Konfiguration von problematischen Service Integrationen. Web Services erfüllen die Integrität. Der Servicenutzer kennt nur die Schnittstelle des Web Services. Die Umsetzung des Web Services bleibt für ihn verborgen. Mit den eben genannten Vorteilen können existierende Anwendungen einfach als Web Services gekapselt werden und in eine SOA 5 -Architektur (Service Oriented Architecture) integriert werden. Die im Web Service verwendete Schnittstelle kann durch standardisierten XML-Nachrichtenaustausch auf das Internet zugreifen. Diese Schnittstelle wird durch WSDL (Web Service Description Language) beschrieben. Diese Beschreibung beinhaltet alle Einzelheiten zur Interaktion mit dem Web Service. z.b. Nachrichtenformat, Übertragungsprotokoll und Standort Architektur In der Web Service Technologie gibt es hauptsächlich drei Rollen: Service-Anbieter, Service-Nutzer und Service-Vermittler. 5

11 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Der Service-Anbieter ist der Besitzer des Services. Er stellt die Funktionalität des Services zur Verfügung und wartet bis der Service genutzt wird. Der Service-Nutzer nutzt einen Service, der vom Service-Anbieter bereitgestellt wird. Dazu schickt er seine Anfragen in Form von SOAP-Nachrichten zum Service-Anbieter. Der Service-Vermittler verbindet einen Service-Nutzer mit einem passenden Service-Anbieter und spielt die Rolle des Verwalters. Normalerweise wird hier UDDI 6 (Universal Description, Discovery, and Integration) als Directory Service benutzt. (Siehe Abbildung 1.) UDDI Registry Auffinden WSDL Service Vermittler Publizieren WSDL Service Nutzer Binden SOAP Service Anbieter Abbildung 1 Web Service Architektur (nach Lit.3) Zwischen diesen drei Rollen stehen drei Operationen zur Verfügung. Publizieren: Service-Anbieter registriert die Funktionalität und Zugriffsschnittstelle seines Web Services mithilfe einer WSDL-Beschreibung beim UDDI Registry; Auffinden: Service-Nutzer sucht bestimmte Services durch WSDL-Beschreibungen beim UDDI Registry, dadurch bekommt er die konkrete physische Adresse des Anbieters; Binden: Service-Nutzer kommuniziert mit einem konkreten Service Anbieter und benutzt den tatsächlich Service. 6

12 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Protokolle Übersicht Um Web Services besser zu verstehen wird als nächstes Überblick von Web Service Standards gegeben. (siehe Abbildung 2.) WS-BPEL Service Komposition Security Reliability Transaction Service Qualität XSD, WSDL, UDDI, Policy, Metadata Exchange XML, SOAP, WS-Addressing HTTP/HTTPS, SMTP, MQ Service Beschreibung Nachrichten Übertragung Transport Protokolle Abbildung 2 Protokoll-Übersicht des Web Services (aus Lit.4) Für die Transportsprotokolle benutzt man hier HTTP/HTTPS, SMTP 7 oder MQ 8. Natürlich werden auch andere Protokolle unterstützt, aber standardisierte Protokolle sind zur Vereinheitlichung und Vereinfachung der Realisierung empfehlenswert. XML, SOAP und WS-Adressing 9 sind für die Nachrichtenübertragung definiert. Sie sind jeweils für das Nachrichtenformat, die Nachrichtenübertragung und die Netzwerkadressierung verantwortlich. Sie beschreiben, wie man das Nachrichtenformat richtig strukturieren kann. XML-Schema liefert die abstrakte Beschreibung der Nachrichtenstruktur. SOAP definiert die Methode, wie man XML-Nachrichten codieren kann. WS-Addressing zeigt, woher die Nachrichten kommen und wohin die Nachrichten gesendet werden. Es besitzt einen einfachen aber mächtigen Mechanismus, die sogenannte Endpoint Reference (EPR). Eine eindeutige Identifizierung und eventuell Referenzen auf vorangegangene Nachrichten werden mittransportiert, um einen Konversationskontext zu schaffen. EPR besteht immer aus einem XML-Element

13 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen WSDL ist der grundlegende Standard für die Service-Beschreibung. Mit XML-Schema kann der Entwickler und Service Anbieter die Typen der Datenstruktur und Nachrichten definieren. WS-Policy 10 ermöglicht dem Serviceanbieter, die Richtlinien bezüglich Sicherheit, Qualität und Version seines Services in Form von maschinenlesbaren XML-Daten für den Service-Nutzer bereitzustellen. Umgekehrt kann der Service-Nutzer seine Anforderungen ebenfalls in Form von XML-Daten spezifizieren. Mit WS-Metadata 11 Exchange kann man durch die Schnittstelle des Web Services mit dem anderen Service Metadaten austauchen. Es ist wünschenswert, Web Services mithilfe von Metadaten zu beschreiben, um eine transparente Sicht zu erreichen. Diese Metadaten werden in einem Repository zusammengefasst. UDDI definiert solche Metadata-Aggregationen. Ein Web Service muss eine bestimmte Qualität liefern, um eine gewisse Dienststufe zu erreichen. Die Qualität besteht aus vielen Faktoren, wie z. B. Sicherheit, Verlässigkeit und Transaktionsmechanismus. Mit Service-Komposition kann man viele einzelne Services kombinieren, um einen neuen komplexeren Web Service aufzubauen. WS-BPEL ist die Sprache, die für eine solche ServiceKomposition zur Verfügung steht. Es gibt drei Aspekte bei der Service- Komposition: Struktur, Information und Verhalten. Dies hat den unterschiedlichen Typen der Service Komposition sichern. 2.2 WSDL 12 Web Service Description Language (WSDL) ist eine XML-basierte Beschreibungssprache für Web Services. Sie ist plattformunabhängig sowie unabhängig von Programmiersprache und Protokoll. Im Jahre 2000 hat IBM, Microsoft und Ariba WSDL 1.0 zur Beschreibung von Web Services entwickelt. Danach wurde es ständig erweitert und im Juni 2007 kam es zur Veröffentlichung von WSDL 2.0, welches auch vom W3C 13 (World Wide Web Consortium) empfohlen wird. WSDL ist eine Metasprache, um die angebotenen Funktionen, Daten, Datentypen und Austauschprotokolle eines Web Services zu beschreiben. WSDL definiert die Operationen, die von außen zugänglich sind, sowie die Parameter und Rückgabewerte der

14 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Operation. Ein WSDL-Dokument beinhaltet die notwendigen Informationen, die zur Beschreibung der Schnittstelle, Zugangsprotokoll, Dienstzugriff und QoS (Quality of Service) nötig sind. WSDL beschreibt drei grundlegende Merkmale des Web Services. Man kann diese Merkmale zur drei Fragen zusammenfassen. Was macht der Web Service? Die Operationen, die der Web Service bereitstellt. Wie kann man den Web Service zugreifen? Die Details des Datenformates und das benötigte Protokoll zum Dienstzugriff. Wo liegt der Web Service? Die vom speziellen Protokoll abhängige Netzwerkadresse. z.b. URL(Uniform Resource Locater) Das WSDL-Modell trennt die abstrakte Definition und die konkrete Realisierung. Anders gesagt, die Dienstschnittstelle und die Dienstimplementierung. (siehe Abbildung 3.) Types Messages Port Types Operations Abstract Services Ports Bindings Concrete Abbildung 3 WSDL Konzept-Modell (nach Lit.2) Abstrakte Schnittstelle

15 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Die abstrakte Schnittstelle wird in WSDL 1.0 als <PortType> repräsentiert. <PortType> ist eine abstrakte Menge von unterstützten Operationen. Sie definieren ausführlich das Schema und Format der Eingabe/Ausgabe-Nachrichten. Innerhalb eines <PortType> kann es einige <Operation>-Elemente beinhalten. Sie sind die abstrakte Beschreibung der Operationen, die von dem Web Service unterstützt werden. Jede einzelne <Operation> besitzt ein Paar Request-Response-Nachrichten, nämlich ein Eingabe/Ausgabe Pattern. z.b.. Folgende Typen von Anfragen sind möglich: einzelne Anfrage, einzelne Antwort, Anfrage/Antwort und Antwort/Anfrage. Das <Operation>-Element wird von einer Gruppe <Messages> definiert. Sie definieren die Datenstruktur der Nachrichten bei der konkreten Kommunikation. <Messages> beinhaltet eine Gruppe von <Port>-Elementen. Jedes <Port>-Element ist ein Teil der finalen Nachrichten. Hier werden geschachtelte Elemente nicht unterstützt. <Messages> benutzen die Datentypen, die innerhalb der <Types>-Elemente definiert werden. Sie definieren die Menge von Datentypen, die der Web Service benutzt. Sie können von <Port> referenzieren. Sie benutzen eine bestimmte Typsystem wie z.b. XML Schema. Die Definition des <PortTypes> kann eine oder mehre Nachrichtentypen referenzieren, weil ein <PortType> verschiedene Nachrichtentypen betreffen kann. In WSDL 2.0 wird <PortType> umbenannt in <Interface> Konkrete Implementierung <Bindings> ist ein Mapping von <PortTypes> und Zugriffsprotokoll und Datenformat. Es verbindet <PortTypes> mit einem spezifischen Protokoll. z. B. mit SOAP/HTTP oder mit MIME/SMTP. <Service> beschreibt die Deployment-Details aller Zugriffseingänge, die von einem Web Service zugestellt werden. Ein <Service> beinhaltet meistens mehre Dienstzugriffseingänge, die jeweils mit einem <Port> beschrieben werden. <Ports> definieren die Dienst-Endpunkte durch die Zuweisung einer Adresse für das Binden. Es beschreibt, unter welcher Adresse oder mit welchem Schema des Nachrichtenaufrufs auf einen Service zugriffen werden kann. In WSDL 2.0 werden <Ports> als <Endpoint> bezeichnet.

16 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen BPEL 14 Business Process Execution Language (BPEL) ist eine XML-basierte Prozessbeschreibungssprache. Sie ist eine Menge von Aktivitäten, die durch Web Services implementiert sind. Die einzelne Aktivität ist ein Prozessschritt innerhalb des Gesamtprozesses. BPEL beschreibt die Reihenfolge und Randbedingungen der Aktivitäten, sowie die Behandlung bei einer Fehlersituation. Im Jahr 2002 wurde BPEL4WS von IBM, BEA Systems und Microsoft eingeführt, um Web Service-Orchestrierungen zu beschreiben. Die Sprache kombiniert die kalkülbasierte Sprache XLANG 15 von Microsoft und die Graph-basierte Sprache WSFL 16 (Web Service Flow Language) von IBM. Später treten SAP und Siebel Systems ein und reichen Sie BPEL4WS 1.1 beim OASIS (Organization for the Advancement of Structured Information Standards) zur Standardisierung ein. Im Jahr 2004 beschloss OASIS die Spezifikation WS-BPEL 2.0 zu nennen. Normalerweise wird BPEL als Abkürzung benutzt. WS-BPEL benutzt einige XML-Spezifikationen: WSDL 1.1, XML Schema 1.0, XPath 1.0 und XSLT 1.0. WSDL Nachrichten und XML Schema Typ-Definitionen stellen das Datenmodell, das von WS-BPEL Prozessen benutzt wird, bereit. XPath und XSLT bieten die Unterstützung für Daten-Manipulation an. Alle äußeren Ressourcen und Partner werden als WSDL Services repräsentiert. WS-BPEL liefert die Flexibilität zur Aufnahme weiterer Standards, besonders XPath und die, in XML-Computation, benutzten Standards. BPEL Engine ermöglicht die Ausführung einer BPEL-Prozessinstanz. Es ist die Laufzeitumgebung zur Interpretation des BPEL-Dokumentes. Es gibt freie BPEL Engines, Oper Source BPEL Engines sowie kommerzielle BPEL Engines Geschäftsprozess mit BPEL Geschäftsprozesse können in zwei Arten eingeteilt werden. Ein ausführbarer Geschäftsprozess modelliert das tatsächliche Verhalten des Teilnehmers in eine geschäft

17 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen liche Interaktion. Ein abstrakter Geschäftsprozess besteht aus teilweise spezifizierten Prozessen, ist aber als Gesamtes nicht zur Ausführung definiert. Ein solcher Prozess kann Details für die konkrete Operation verstecken. Ein abstrakter Prozess spielt eine deskriptive Rolle. Somit kann er in mehreren Fällen eingesetzt werden darf. WS-BPEL definiert ein Modell und eine Grammatik zur Beschreibung des Geschäftsprozesses. Dieser Prozesse basiert auf den Interaktionen zwischen dem Prozess und seinen Partnern. Diese Interaktionen mit jedem Partner passieren durch die Web Service Schnittstelle. Diese Beziehung ist in der Schnittstelle gekapselt und als <Partner- Link> benannt. Der WS-BPEL Prozess definiert, wie mehrere Service Interaktionen mit diesen Partnern koordiniert sind, um ein bestimmtes Geschäftsziel zu erreichen. WS-BPEL stellt auch systematischen Mechanismen bereit, um geschäftliche Ausnahmen und Prozessfehler zu behandeln. Darüber hinaus führt WS-BPEL ein Mechanismus ein, um einzelne oder kombinierte Aktivitäten innerhalb des Prozessablaufs zurückzusetzen, für den Fall, das Ausnahmen auftreten oder eine Partner-Anforderung nicht mehr vorhanden ist Terminologie Abbildung 4 zeigt das BPEL-Modell. Es dient dazu, um die Anwendung der Geschäftsprozess-Beschreibung besser zu verstehen.

18 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 4 BPEL Modell (aus Lit.4) In BPEL kann eine Prozessinstanz einerseits andere Web Services aufrufen, jedoch auch andererseits selbst Web Services anbieten und somit Anforderungen eines Clients beantworten. Andere Services, der mit diesem Prozess interagieren, werden <Partner> genannt. In der asynchronen Kommunikation könnte die Konversation zwischen Prozess und Partner bidirektional verlaufen. Der Prozess wird von einer Serie von Aktivitäten zusammengesetzt und benutzt einen <PartnerLink>, um andere Dienste, die mit dem Prozess interagieren können, zu definieren. Er beschreibt die Beziehungen der Zusammenarbeit. Um die Interaktivitäten mit einem Partner in dem Prozess zu bezeichnen, braucht man nur den entsprechenden Namen des <PartnerLinks> angeben. Darüber hinaus muss man keine konkreten Dienst-Endpunkte bezeichnen. Damit wird der Zeitpunkt des Bindens zwischen Prozess und konkretem Dienst verschoben. z. B. bis zur Komposition- oder Ausführungszeit. Durch diese dynamische Beziehung wird eine große Flexibilität erreicht, gleichzeitig wird die Wiederverwendbarkeit verstärkt. Innerhalb des <PartnerLink> wird die Rolle des Prozesses und des Partners durch <myrole> und <partnerrole> definiert. Gemäß der unterschiedlichen Rolle, die der Prozess spielt, wird eine entsprechende Rolle ausgewählt. Die Kommunikationsschnittstelle zwischen Prozess und Partner werden durch <PartnerLinkType> definiert. <PartnerLinkType> ist der <PortType> im WSDL-Dokument. <PartnerLinkType> enthält die Beziehungen zwischen zwei oder mehren Diensten. Er definiert eine Rolle, die einen <PortType> referenziert, was die Dienstschnittstelle ist. <PartnerLinkType> wird im WSDL-Dokument definiert und vom BPEL-Prozess aufgerufen. Im BPEL kann man <Variables> nutzen, um die Zustandsinformationen des Prozesses zu speichern und weiterzuleiten. Der Datentyp von <Variables> wird mithilfe von WSDL definiert. Es können entweder die von XML-Schema vordefinierte einfachen Datentypen oder eigene komplexe Datentypen verwendet werden. Weiterhin werden einige interne Funktionen mitgeliefert, um den Inhalt der <Variables> festzulegen. BPEL stellt einen deklaratorischen Mechanismus bereit, um korrelative Operationsgruppen innerhalb einer Prozessinstanz zu spezifizieren. Die Gruppe der korrelativen Variante wird als die Gruppe von Properties definiert, die von allen Nachrichten in der korrelativen Gruppe genutzt werden können. Derartige Gruppe von Properties

19 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen nennt man a <Correlation Set>. Normalerweise wird <Correlation Set> in der Nachrichten Aktivitäten benutzt Aktivitäten Ein BPEL-Prozess besteht aus verschiedenen Aktivitäten. BPEL hat dazu Typen von Aktivitäten definiert. Normalerweise können diese Aktivitäten in zwei Kategorien unterteilt werden: Basisaktivität und strukturierte Aktivität. Basisaktivität beschreibt einen konkreten Schritt innerhalb des Prozesses. z. B. den Empfang der Anforderung, den Aufruf des Partnerdienstes, usw. Strukturierte Aktivitäten beschreiben, wie der Kontrollfluss des Prozesses organisiert und verwaltet wird Basis Aktivitäten Im folgenden Abschnitt werden die Basisaktivitäten des BPEL-Prozesses erläutert. <Receive>/<Reply>:Eine <Receive>Aktivität bekommt Daten vom Partner des äußeren Prozesses und speichert diese Daten in einer ProzessVariable. Gewöhnlich ist eine <Receive>-Aktivität der Startpunkt eines Prozesses. Er ist in der Lage, einen Prozess zu instanziieren. Eine <Reply>-Aktivität sendet dem Partner die Nachrichten, um die von der <Receive>-Aktivität empfangene Anfrage zu beantworten. Die Kombination der <Receive>- und <Reply>-Aktivität entspricht einer Anfrage-Antwort-Operation innerhalb des <PortType>-Elements in dem WSDL- Dokument. Falls <Receive> eine Einweg-Aktivität beschreibt, wird die <Reply>-Aktivität nicht benötigt. <Invoke>: Diese Aktivität erlaubt, dass der Geschäftsprozess synchrone oder asynchrone vom Partner zugestellte Services aufruft. Der Service kann in eine Richtung oder bidirektional realisiert sein. <Invoke> benutzt <PartnerLink>, um Partner Dienst zu referenzieren. <PortType> und <Operation> wird zur Bezeichnung der Schnittstelle und Operationen benutzt. <Assign>: Die Funktionalität dieser Aktivität ist es den Wert einer Variable mit neuen Daten zu ersetzen. Eine <Assign>-Aktivität kann beliebigen Inhalt besitzen. Sie kann auch Endpunkt-Referenz zu PartnerLink oder PartnerLink zu Endpunkt-Referenz ko-

20 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen pieren, um dynamisches Binden zu realisieren. <Wait>: Diese Aktivität kann den Prozess sperren. Das geschieht entwederin einem vorgegebenen Zeitabschnitt oder bis zu einem bestimmten Zeitpunkt nach dem die Ausführung des Prozesses wieder fortgeführt wird Strukturierte Aktivitäten BPEL besitzt zahlreiche strukturierte Aktivitäten, um Geschäftsprozess- Logik flexibel zu realisieren. <Sequence>: Definiert die Reihenfolge der auszuführenden Aktivitäten. Die Sequenz der Ausführung ist die lexikalische Reihenfolge, wie sie innerhalb des <Sequence>-Elements erscheint. <Flow>: Mithilfe dieses Elements lässt sich die Reihenfolge der komplexen Aktivitäten beschreiben. Es ermöglicht die vollständige Parallelität und die Abhängigkeit der Synchronisation zwischen Aktivitäten. <Link> wird zum Ausdrücken dieser Abhängigkeit benutzt. Innerhalb des <Link>-Elements gibt es nur eine Quell- und ein Ziel-Aktivität, somit kann ein gerichteter Graph erzeugt werden. <Switch>: Diese Aktivität ist ähnlich wie in traditionell strukturierten Sprachen. Innerhalb ein Gruppe wird von verschiedenen Möglichkeiten eine bestimmte Zweig ausgewählt und durchgeführt. <While>: Diese Aktivität hat den Gedanken der traditionellen Programmierung übernommen. Die <While>-Aktivität wird ausführt, bis die Bedingung nicht mehr erfüllt ist. <Pick>: Durch die <Pick>-Aktivität wird ein Prozess solange gesperrt, bis ein bestimmtes Ereignis eingetreten ist, welches die Sperre aufhebt. 2.4 EMF Eclipse Modeling Framework (EMF) ist ein mächtiges Framework, welches es dem Entwickler ermöglicht, schnell eine robuste Java-Anwendung aufzubauen, die auf einfachen Modeldefinitionen basiert.. EMF vereinheitlicht drei Technologien: Java, XML und UML. Modelle können mit einem UML-Modellierungswerkzeug,

21 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen XML-Schema oder einfachen Java Annotationen der Schnittstelle definiert werden. EMF bietet ein runtime-framework, das eine beliebige modellierte Datei mithilfe einer Benutzerschnittstelle validieren und bearbeiten kann. Die Mitteilung der Modelländerung wird automatisch unterstützt. Bei der Verarbeitung beliebiger Dateien werden einheitliche und reflektive APIs benutzt EMF Modell In Abbildung 5 sind die drei Technologien abgebildet, die von EMF verwendet werden. Das EMF-Modell ist die allgemeine Repräsentation, die alles zusammenfasst. Mithilfe des EMF-Modells können Transformationen zwischen z. B. einem XML-Schema und einem UML-Klassendiagramm einfach vorgenommen werden. Abbildung 5 EMF vereinheitlicht Java, XML und UML (aus Lit.8) EMF ist ein effizientes Programmierungswerkzeug, weil es eine Zwischenlösung von Modellierung und Programmierung gefunden hat. Mit EMF können sowohl Modellierung als auch Programmierung durchgeführt werden. EMF integriert diese beiden Aspekte sehr gut. Im Vergleich mit der Model Driven Architecture (MDA) ist EMF leichter verstehbar. EMF bewegt sich in die Richtung von MDA, aber akzeptierbarer als MDA. Man benötigt viel Zeit, um MDA zu lernen. Mit EMF hingegen kann man sofort anfangen. Das Modell in EMF wird als Ecore bezeichnet. Ecore ist ein EMF-Modell und das

22 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Metamodell von Ecore ist auch ein EMF-Modell. Die Abbildung 6 zeigt ein Subset des Ecore Metamodells. Eclass bezeichnet eine modellierte Klasse. Die Klasse besitzt einen Namen und optional Attribute sowie Referenzen. EAttribute repräsentiert ein modelliertes Attribut, das durch einen Namen und ein Typ beschrieben wird. EReference beschreibt die Assoziation zwischen Klassen. Es hat einen Name und referenzierenden Typ. EDataType ist der Attributtyp. Abbildung 6 Subset des Ecore Metamodells Notifikation und Adapter EMF bietet die Möglichkeit, dass verschiedene EMF-basierte Werkzeuge und Anwendungen miteinander kommunizieren und so zusammenarbeiten können. Jede generierte EMF-Klasse ist gleichzeitig auch ein Notifier. Das bedeutet, dass Mitteilungen gesendet werden können, wenn sich Attribute oder Referenzen geändert haben. Dies ermöglicht eine Überwachung von EMF-Objekten. Beobachter werden als A- dapter bezeichnet, weil es möglicherweise zur Ausbreitung des Objektsverhaltens benutzt wird. Ein Adapter kann an ein beliebiges EObjekt gebunden sein. Bei jeder Notifikation wird das EObjekt benachrichtigt. Diese Notifikationen werden anhand von Event-Type und FeatureId unterschieden. 2.5 Zusammenfassung In diesem Kapitel wurden Web Services und dessen Beschreibungssprachen WSDL

23 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen vorgestellt. Danach wurde BPEL betrachtet, die für Kompositionen von Web Services genutzt wird. Um die Synchronisation von WSDL und BPEL zu realisieren, wird EMF als Transformationssprache erläutert. Dies sind die grundlegenden Technologien, die in dieser Arbeit verwendet werden. Im Folgenden wird die interne Beziehung zwischen WSDL und BPEL analysiert.

24 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen

25 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Analyse Wie in der Einführung erläutert, ist das Ziel dieser Arbeit die Synchronisation von WSDL- und BPEL-Beschreibungen in Kompositionen von Web Service. Deswegen sind die folgenden zwei Fragen zu beantworten: Welche Elemente und Attribute müssen synchronisiert werden? Wie kann man diese Elemente oder Attribute synchronisieren? Die erste Frage bedeutet, dass die notwendigen Elemente, die synchronisiert werden müssen, in der WSDL und BEPL Sprache herauszufinden sind, sowie die interne Beziehung dieser Elemente. Zum zweiten muss man das konkrete Verfahren zur Synchronisation definieren. Das heißt, jeweils eine Abbildung und die Anforderung an diese definieren. Bevor die Synchronisationsbeziehungen untersucht werden, findet eine ausführliche Analyse der WSDL- und BPEL-Modelle statt. Im weiteren Verlauf dieses Kapitels werden die Beziehungen dieser Modelle beschrieben. Danach werden existierende Abbildungen bzw. Synchronisationsverfahren von WSDL und BPEL recherchiert und existierende Ansätze bezüglich vordefinierte Anforderungen verglichen. 3.1 Modell Analyse WSDL beschreibt konkret jeden Web Service und BPEL ist für Web Service Kompositionen verantwortlich. Deswegen ist BPEL strukturell auf einem hohen Niveau (high-level) im Gegensatz zu WSDL, was in diesem Fall ein niedriges Niveau der Beschreibung abbildet (low-level). Wenn man die Elemente in eine andere Sprache extrahieren möchte, die bestimmte Beziehungen mit der Zielsprache haben, ist es besser zunächst die high-level Sprache zu betrachten. Das bedeutet, dass man zunächst das BPEL-Modell untersucht. Auf diese Weise können die internen Beziehun-

26 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen gen von BPEL und WSDL schneller gefunden werden. Die Elemente, die mit WSDL etwas zu tun haben, können in BPEL auf zwei Gruppen eingeteilt werden. Eine Gruppe beinhaltet die Elemente, die direkt aus der WSDL-Beschreibung kommen. Das bedeutet, die WSDL Elemente werden gerade von BPEL zitiert. Anderer sind die Elemente, die durch die innen Referenz in der BPEL Sprache mit WSDL korrelativ sind. Dies bezeichnet eine indirekte Beziehung zwischen BPEL und WSDL. Jedoch muss man diesen Sachverhalt bei der Synchronisation der beiden Sprachen ebenfalls betrachten Elemente mit direkter Beziehung Partner Links Die Abbildung 7 zeigt das Infoset von BPEL. Das erste Element, das eine direkte Beziehung mit WSDL hat, ist <partnerlinks>. BPEL beschreibt Geschäftsinteraktionen. Die unterschiedlichen Geschäftsprozesse werden durch das Verhalten auf der Schnittstelle aufeinander wirken. BPEL kann Beziehungen zwischen Partnerprozessen modellieren. Dabei handelt es sich typischerweise um Punkt-zu-Punkt-Beziehungen und bezeichnet eine bidirektionale Abhängigkeit auf Service-Niveau. Ein Partner repräsentiert sowohlservice-nutzer als auch Service-Anbieter. <partnerlinks> modelliert kommunikative Punkt-zu-Punkt-Beziehungen und definiert die Partnerbeziehung durch die Definition der Interaktionsschnittstelle auf beiden Seiten.

27 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 7 BPEL 2.0 Infoset Diagramm (Nach Lit.1) <partnerlinks> kann einen oder meherere <partnerlink>-elemente beinhalten. Das bedeutet, dass der Geschäftsprozess im verschiedenen Szenario unterschiedliche Rolle spielen kann. Jede <partnerlink> wird von ein <partnerlinktype> charakterisiert. Mehrere <partnerlink>-elemente können den gleichen <partnerlinktype> besitzen. In Abbildung 8 ist die Syntax von <partnerlinks> eines BPEL-Dokuments dargestellt. Die Attribute partnerlinktype, myrole und partnerrole kommen aus dem entsprechenden Prozess-WSDL-Dokument. Das Prozess-WSDL-Dokument definiert die Beziehungen zwischen Geschäftspartnern.

28 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 8 Syntax eines <PartnerLink> (aus Lit.1) Ein <partnerlinktype> in einem Prozess-WSDL-Dokument charakterisiert die kommunikativen Beziehungen zwischen zwei Services durch die Definition der Rollen, die jeder Service in der Konversation einnimmt. Abbildung 9 zeigt die Syntax von <partnerlinktype>. Abbildung 9 Syntax eines <partnerlinktype> (aus Lit.1) Es spezifiziert auch die Schnittstelle, die von jedem Service bereitgestellt wird, um die Nachrichten innerhalb des Konversationskontexts zu empfangen. Jede <role> spezifiziert genau eine Schnittstelle, nämlich <porttype> im Partner-WSDL-Dokument. Das Partner-WSDL-Dokument definiert jeweils die bereitgestellten Services. In Abbildung 10 ist die Syntax von <porttype> dargestellt. Das Unterelement <operation> kann in der Zukunft von der BPEL-Aktivitäten genutzt werden. Abbildung 10 Syntax eines <porttype> (aus Lit.2) <porttype> und <partnerlinktype> können im gleichen WSDL-Dokument oder in unterschiedlichen WSDL-Dokument (Partner- und Prozess-WSDL) liegen. Dies hängt von der Komplexität des Prozesses ab. In beiden Fällen muss man diese zwei Elemente synchronisieren. Zusammen mit dem <partnerlinks>-element im BPEL-Dokument wird eine Dreiecks-Beziehung aufgebaut, siehe Abbildung 11. Diese

29 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen drei Elemente müssen unbedingt miteinander synchronisiert werden. Partner WSDL <porttype name= > <operation Name= /> </porttype> BPEL <partnerlinks> <partnerlink partnerlinktype= myrole= partnerrole= /> </partnerlinks> <activity porttype= operation= > </activity> Links zitiert Rechts. Process WSDL <partnerlinktype name= > <role name= porttype= /> </partnerlinktype> Abbildung 11 Beziehung zwischen den drei Elementen Variables Das zweite Element, das eine direkte Beziehung mit WSDL hat, ist <variables>. Der Geschäftsprozess spezifiziert die statusbehafteten Interaktionen, durch den der Nachrichtenaustausch zwischen Partnern ermöglicht wird. Der Zustand des Geschäftsprozesses beinhaltet die auszutauschenden Nachrichten, die Zwischendatei in der Geschäftslogik und in der Teile der zusendenden Nachrichten. Um den Zustand des Geschäftsprozesses zu erhalten ist die Nutzung des <variables>-elements notwendig. <variables> ermöglicht das Besitzen der Nachrichten, die den Zustand des Geschäftsprozesses präsentiert. Diese Nachrichten sind oftmals aus Partner oder zum Partner. <variables> können auch die Informationen beinhalten, die den Prozesszustand charakterisieren. Diese Informationen werden jedoch nie mit Partnern ausgetauscht. Es gibt drei Arten, um ein <variable>-element in BPEL zu deklarieren: WSDL Nachrichten Type, XML Schema Type (einfach oder komplex) und XML Schema Element. In Abbildung 12 zeigt dir die syntaktische Definition des <variableselements.

30 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 12 Syntax eines <variables>-elements (aus Lit.1) Die Attribute messagetype, type und element werden benutzt, um den Typ einer Variablen zu spezifizieren. Nur eine dieser Attribute wird definiert. messagetype verweist auf die Nachrichtendefinition im WSDL Dokument. type und element entsprechen jeweils XML-Schema-Type und XML-Schema-Element. Wenn das Attribut message- Type benutzt wird, ist es sinnvoll, mit dem Element <message> in WSDL Dokument zu synchronisieren. Wenn das Attribut type benutzt wird und die entsprechende Definition im WSDL-Dokument liegt, müssen beide Definitionenidentisch sein. In Abbildung 13 und 14 sind die Syntax der <types> und <message>-elemente des WSDL-Dokuments dargestellt. Abbildung 13 Syntax eines <type> (aus Lit.2) Abbildung 14 Syntax eines <message> (aus Lit.2) Die Abbildung 15 zeigt die Beziehung zwischen diese Elementen.

31 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen BPEL <variables> <variable name= messagetype= type= element= >+ </variable> </variables> WSDL <types> <xsd:schema />* </types> <message name= > <part name= > </message> Links zitiert Rechts Abbildung 15 Beziehung zwischen <variable> und <type>/<message> CorrelationSets Während des Nachrichtenaustauschs im BPEL-Prozess muss jede Nachricht zum richtigen Port, der von einer Prozessinstanz definiert wird, übertragen werden. Darüberhinaus muss die Nachricht nicht nur zum richtigen Port sondern auch zum richtigen Prozessinstanz ausgeliefert werden, um Fehler zu vermeiden. In der objekt-orientierten Welt wird dieses Problem druch die Einführung der Objekt-Referenz gelöst. Aber im Fall der loose-coupled Web Services ist diese Lösung nicht mehr gültig. Hier wird der Token-Mechanismus für instanz routing eignesetzt. Das bedeutet, dass jede Nachricht ein instanz-spezifisches Token tragen muss, um die richtige Instanz zu finden. Der Tokenwert ist abhängig von der Prozessinstanz. Die Deklaration des <correlationsets> bezieht sich auf die deklarative Property der Nachricht. Ein Property ist einfach ein Feld innerhalb einer Nachricht, das von einemquery identifiziert word. In Abbildung 16 ist die syntaktische Definition des <correlationsets> abgebildet. Abbildung 16 Syntax eines <correlationsets> (aus Lit.1) Das Attribut properties muss mit dem entsprechenden <vprop:property>-element des

32 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen WSDL-Dokuments identisch sein. Normalerweise wird die Definition des Properties in einem separaten WSDL-Dokument abgelegt. Es kann jedoch auch im Partner-WSDL-Dokument liegen. In beiden Fällen müssen sie miteinander synchronisiert werden. Die Syntax des <vprop:property>-elements zeigt Abbildung 17 Abbildung 17 Syntax eines <vprop:property>-elements (aus Lit.1) Die Abbildung 18 zeigt die Beziehung zwischen diesen Elementen. BPEL <correlationsets> <correlationset name= properties= /> </correlationsets> WSDL <vprop:property name= type= element= /> Links zitiert Rechts Abbildung 18 Beziehung zwischen <correlationsets> und <property> Tabelle 1 zeigt die Elemente, welche die direkten Beziehungen zur Synchronisation enthalten. BPEL Prozess WSDL Partner WSDL Property WSDL <PartnerLink> <PartnerLinkType> <ProtType> <Variables> <types>, <message> <correlationsets> <vprop:property> Tabelle 1 Elemente und Beziehung zur Synchronisation

33 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Elemente mit indirekter Beziehung Als nächstes werden Elemente, die eine indirekte Beziehung mit WSDL besitzen, untersucht. Diese Elemente haben äußerlich nichts mit WSDL-Element gemeinsam, jedoch besitzen deren Unterelemente oder Attribute eine bestimmte Beziehung mit den WSDL-Elementen. BPEL-Aktivitäten führen die Prozesslogik aus. Basis-Aktivitäten und strukturierte Aktivitäten gruppieren BPEL-Aktivitäten zusammen. Basis-Aktivitäten beschreiben das Prozessverhalten der elementaren Schritte. Dazwischen haben einige Nachrichten-Aktivitäten (invoke, receive, reply und pick) eine enge Beziehung mit der WSDL-Beschreibung. Invoke Die <invoke>-aktivität wird zum Aufruf eines Web Service genutzt, der von einem Service-Anbieter bereitgestellt wird. <invoke> ruft die Operation eines Services auf, die als eine Basis-Aktivität betrachtet wird. Diese Aktion kann in andere Aktivitäten, wie z. B. <faulthandlers> und <eventhandlers> eingeschlossen sein. Die Operationen können bidirektional oder unidirektional ausgeführt werden. Dies hängt von der WSDL-Definition ab. Abbildung 19 zeigt ist die Syntax der <invoke>aktivität. Abbildung 19 Syntax einer <invoke>-aktivität (aus Lit.1)

34 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Die Attribute porttype und operation müssen mit den, von partnerlink referenzierten, Definitionen im WSDL-Dokument identisch sein. Wenn inputvariable und outputvariable benutzt werden, müssen sie mit <message> im WSDL-Dokument übereinstimmen. Wenn <topart> und <frompart> benutzt werden, müssen sie gleiche Regeln befolgen. Im Fall des Anforderung-Antwort-Aufrufs können die Operationen eine Fehler zurückgeben. <catch> ist verantwortlich für das Verhalten. Deswegen muss das Attribut faultmessagetype des <catch>-elements mit dem <message>-element mn WSDL-Dokument identisch sein. Assign Die Aktivität <assign> wird für Variablenzuweisungen benutzt. Zusätzlich können damit neue Daten erstellt oder hinzugefügt werden. Darüber hinaus kann <assign> Endpoint Reference aus und zu <partnerlinks> kopieren. Es ist auch möglich, erweiterbare Operationen zur Datenmanipulation zu integrieren. Diese Operationen werden dann als erweiterte Elemente unter anderem Namespace definiert. In Abbildung 20 ist die Syntax von <assign> dargestellt. Abbildung 20 Syntax eines <assign> (aus Lit.1) Die <assign>-aktivität kopiert einen typ-kompatiblen Wert von einer Quelle ( from-spec ) zum Ziel ( to-spec ) mithilfe des <copy>-elements. From-spce und to-spec müssen eine der folgenden Formen annehmen, die in Abbildung 21 und 22 zu sehen sind.

35 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 21 Form von from-spec (aus Lit.1) Abbildung 22 Form von to-spec (aus Lit.1) Jeder der gezeigten Formen muss es mit einem entsprechenden WSDL-Element identisch sein. Receive Durch inbound message activities (IMA - <receive>, <pick> und <onevent>) und entsprechende <reply>-aktivitäten stellt ein Geschäftsprozess seinen Services Partnern zur Verfügung. Die <receive>-aktivität wird zum Empfang der gewünschten Nachrichten benutzt. Sie spezifiziert das Attribut partnerlink mit myrole, porttype und Operation, damit der Partner einen Service nutzen kann. Das Unterelemente <frompart> ist ähnlich wie das in der <invoke>-aktivität. Die vorstehenden Attribute müssen mit entsprechenden Elementen des WSDL-Dokuments identisch sein. Zusätzlich wird die Nachricht, die vom Partner empfangen wurde, in Variable gespeichert. Deswegen muss die Type der Nachrichten miteinander kompatibel sein. Abbildung 23 zeigt die Syntax von <receive>.

36 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 23 Syntax eines <receive>-elements (aus Lit.1) Reply Die <reply>-aktivität sendet eine Antwort zum Ziel, das vom vorherigen IMA spezifiziert wird. Es ist sinnvoll, wenn das Anfrage-Antwort-Pattern benutzt wird. Die <reply>-aktivität spezifiziert auch das VariableAttribut, das die zusendende Nachrichten beinhaltet, welches mit dem Nachrichtentyp im WSDL-Dokument identisch sein muss. Ebenfalls wie bei der <receive>-aktivität müssen die Attribute partnerlink, porttype und Operation synchronisiert werden. Abbildung 24 zeigt die Syntax von <reply>. Abbildung 24 Syntax eines <reply> (aus Lit.1) Die <reply>-aktivität hat zwei Formen. Im normalen Fall wird die Antwortnachricht in Variable gespeichert. In fehlerhaftem Fall wird die Fehlernachricht in Variable gespeichert. Dabei muss beachtet werden, dass Nachrichten dann nicht synchronisiert werden. ExtensionActivity Ein BPEL-Prozess kann neue Aktivitätn beinhalten. <extensionactivity> wird benutzt,

37 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen um diese Aktivitäten zu definieren. Die Attribute, die eine <extension>-aktivität besitzt, müssen auch mit dem WSDL-Dokument synchronisiert werden. Pick Die <pick>-aktivität wartet auf ein mögliches Event und führt die entsprechende Aktivität durch. Das Event wird von Unterelement <onmessage> und <onalarm> spezifiziert. Das <onmessage>-element besitzt neben Attributen partnerlink, porttype und operation auch noch das Unterelement <fromparts>. Diese Attribute müssen ebenfalls h synchronisiert werden. Abbildung 25 zeigt die Syntax von <pick>. Abbildung 25 Syntax eine <pick>-aktivität (aus Lit.1) Die bisher vorgestellten Aktivitäten können auch als Unterelemente in andere Elementen liegen. Dann müssen solche Elemente auch zur Synchronisation betrachtet werden. CompensationHandler Syntaktisch ist ein <compensationhandler> einfach eine Verpackung für eine Aktivität, die Kompensationsverhalten kapselt. Irgendwelche Aktivität liegt in <compensationhandler>, muss man die mit entsprechende Elemente in WSDL synchronisiert. In

38 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Abbildung 26 ist die Syntax von <compensationhandler> dargestellt. Abbildung 26 Syntax eines <compensationhandler> (aus Lit.1) Die Abbildung 27 zeigt einen Überblick der zusynchronisierenden Elemente imwsdl- und BPEL-Dokument. Abbildung 27 Überblick der Elemente zur Synchronisation 3.2 Anforderung Die Elemente, die zur Synchronisation von WSDL und BPEL dienen, wurden bereits gefunden. Als nächstes muss man Anforderungen und Regeln an diese Elemente gestellt werden, um die Synchronisation vollständig und strikt durchführen zu können. Um bestimmten Anforderungen und Regeln zu erstellen, muss man zunächst die

39 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen Wichtigkeit jedes Elements analysieren. Der BPEL-Prozess ist verantwortlich für die Koordinationskontrolle der einzelnen Web Services. Er referenziert die nötigen WSDL-Definitionen. Anders ausgedrückt, sind die Elemente im WSDL-Dokument die Quelle und die Elemente im BPEL-Dokument das Ziel. Deswegen sind normalerweise die Elemente in WSDL-Dokument mächtiger als die im BPEL-Dokument. Das Prozess-BPEL-Dokument definiert die Beziehungen jedes Partners. Jeder Partner wird in einem separaten Partner-WSDL-Dokument definiert. Dabei sind die Elemente im Partner-WSDL-Dokument die Quelle und die Elemente im Prozess-WSDL-Dokument das Ziel. Die Quellelemente sind mächtiger als die Zielelemente. Abbildung 28 zeigt die Beziehung des Dokumentes. Partner WSDL Rechts wichtiger/mächtiger als Links BPEL Prozess WSDL Abbildung 28 Beziehung des Dokuments Vorher wird die Wichtigkeit der Elemente in der unterschiedlichen Domäne (Dokument) analysiert. Man kann nun die unsynchronisierte Situation, die auftreten kann, zusammenfassen. Die Unsynchronisation bedeutet, die Elemente und dazugehörte Attribute, die eine Koordnationsbeziehung enthalten sollen, miteinander zu verbinden. Beispielsweise wurde ein Element oder Attribut im BPEL-Dokument gelöscht, so existiert jedoch noch das Spiegelelement noch im entsprechenden WSDL-Dokument, was zu einem Fehler führt. Die Unsynchronisation muss auch verhaltensbasiert unterscheiden. z. B. gibt es einen Unteschied zwischen dem Löschen eines Elementes, dem Löschen des Elementinhaltes und dem Umbenennen des Elementes. Welches Kompensationsverhalten ist nun beim Auftreten solcher Situationen am besten geeignet? Die entsprechenden Mechanismen zur Unsynchronisationsbehandlung

40 Synchronization von WSDL und BPEL Beschreibung in Web Services Kompositionen muss man vorher definieren. Z. B. müssen bei der Löschung eines Elements im BPEL-Dokument alle Spiegelelemente in anderem Dokument ebenfalls gelöscht werden. Die Kompensationsmechanismen können vollständig vom Computer (automatisch) oder manuell (Rückfrage) durchgeführt werden. Dies muss beim Definitieren der Regeln festgelegt werden. Darüber hinaus müssen die Elemente, die synchronisiert werden sollen, verschiedene Eigenschaften und Bedeutungen einhalten. Deswegen muss man diese Elemente differenziert betrachten und jeweils mit der passenden Methode behandeln. Weil die Synchronisationsarbeit auf der Entwicklungsumgebung Eclipse basiert, werden die mögliche Abläufe zuerst in Eclipse durchgeführt. Abbildung 29 zeigt das Use-Case-Diagramm dieses Systems. Abbildung 29 Use-Case-Diagram Der Benutzer kann die BPEL-Datei oder WSDL-Datei mit Text- oder Graphik-Editor ändern. Die BPEL- und WSDL-Dateien basieren auf XML, deswegen können Änderungen der Datei in zwei Fälle zusammengefasst werden, dem Löschen des Elementes und dem Umbenennen des Elementes. Man versucht mithilfe des Editors diese Änderung durchzuführen. Wenn dies möglich ist, wird es im nächsten Kapital praktisch umgesetzt. In den nachfolgenden Tabellen werden diese Fälle differenziert betrachtet. GE: graphischer Editor in Eclipse QE: Quellcode Editor in Eclipse : unmöglich +: möglich