Seminararbeit Einbindung von Webservices über BPEL

Transkript

1 Seminararbeit Einbindung von Webservices über BPEL Julian Harrer IBB4B Hochschule München Sommersemester 2008 Seminar: Integration von Geschäftsprozessen Prof. Dr. Zimmer Torsten München

2 I. Inhaltsverzeichnis 1. Einführung und Zielsetzung Orchestration Business Process Execution Language Entwicklungsgeschichte Konzepte Einordnung Allgemeine Einordnung Einordnung im Schichtenmodell Servicebeschreibung Abstrakte Beschreibung Konkrete Beschreibung Prozessbeschreibung Konstrukte der Prozessbeschreibung Strukturierte Aktivitäten Primitive Aktivitäten Compensation Handler BPEL und SOA Fazit... 25

3 II. Abbildungsverzeichnis: Abbildung 1: Prozessmodellierung ohne Kapselung... 5 Abbildung 2: Prozessmodellierung mit Kapselung... 6 Abbildung 3: Geschichte von WS-BPEL... 6 Abbildung 4: Entstehung von BPEL... 7 Abbildung 5: Einordnung von WS-BPEL im Schichtenmodell... 9 Abbildung 6: WS-BPEL Prozesses Abbildung 7: Compensation Handler Abbildung 8: SOA Schichtenmodell mit eigener Orchestrationsschicht III. Tabellenverzeichnis: Tabelle 1: Elemente der abstrakten Servicebeschreibung Tabelle 2: Elemente der konkreten Beschreibung Tabelle 3: Konstrukte der Prozessbeschreibung Tabelle 4: Strukturierte Aktivitäten Tabelle 5: Primitive Aktivitäten IV. Abkürzungsverzeichnis: B2B...Business to Business B2C...Business to Customer BPEL.Business Process Execution Language BPEL4WS.Business Process Execution Language for Webservices CORBA.Common Object Request Broker Architecture EAI... Enterprise Application Integration FTP...File Transfer Protocol HTTP.Hypertext Transport Protocol SMTP.Simple Mail Transfer Protocol SOA Serviceorientierte Architekturen SOAP.früher: Simple Object Access Protocol WS-BPEL..Webservice Business Process Execution Language WSDL Webservice Description Language WSFL.Webservice Flow Language XML...Extensible Markup Language XLANG...XML Language

4 1. Einleitung und Zielsetzung Das Konzept der Webservices entwickelte sich in den letzten Jahren rasant schnell und etablierte sich in der Welt der verteilten Anwendungen sowohl im B2B als auch im B2C Bereich zum De-facto-Standard. Die Aufgabe solcher Services ist die Bereitstellung einzelner Dienste innerhalb eines Unternehmens oder über Unternehmensgrenzen hinweg. Sie agieren hierbei offtmals als Schnittstelle unterschiedlicher Programmiersprachen und ermöglichen somit eine plattformunabhängige Kommunikation zwischen verschiedenen Softwarekomponenten. In der Praxis können komplexe Aufgaben jedoch kaum über einzelne Services sondern eher über die Komposition mehrerer unabhängiger Webservices gelöst werden. Dabei verschmelzen unterschiedliche Dienste verschiedener Unternehmen oder Serviceanbietern zu einem einheitlichen Geschäftsprozess. Ohne die Einschaltung einer zentralen Workflowlogik müssen diese Prozesse innerhalb der Anwendungsschicht bzw. Geschäftslogik implementiert werden. Die Trennung dieser beiden Ebenen ermöglicht unter anderem eine unabhängige Entwicklung und Wartung der jeweiligen Schicht und erleichtert die Modellierung eines Geschäftsprozesses über eine zentrale Stelle. Kompositionssprachen wie z.b. WS-BPEL oder WSFL übernehmen in komplexen Systemen die Aufgabe der Orchestration (siehe Punkt 2. Orchestration) und repräsentieren innerhalb der Systemarchitektur eine eigene Orchestrationsschicht (vgl. [Erl05], S. 586). Die Kompositionssprache Webservice Business Process Execution Language kurz WS- BPEL wird im laufe dieser Seminararbeit näher betrachtet. Dabei wird kurz auf den geschichtlichen Hintergrund sowie auf die Grundkonzepte dieser Sprache eingegangen. Nach einer Einordung von BPEL folgt eine Beschreibung der wichtigsten Sprachbestandteile. In dem darauf folgenden Kapitel BPEL und SOA wird die Rolle von WS-BPEL innerhalb einer Serviceorientierten Anwendung dargestellt, bevor ein Fazit diese Arbeit abschließt. Ziel dieser Seminararbeit ist nicht die detaillierte Beschreibung aller Sprachbestandteile oder Möglichkeiten von BPEL sondern eher eine Einführung in die grundlegenden Konzepte die sich hinter dieser Sprache verbergen.

5 2.0 Orchestration Der Begriff der Orchestration wird in IT-Systemen verwendet, in denen eine zentrale Steuerungseinheit die Verantwortlichkeit über die Prozesssteuerung übernimmt. Enterprise Application Integration kurz EAI-Middleware-Systeme verwenden dieses Konzept beispielsweise zur Automatisierung von Geschäftsprozessen oder für die Integration von Altsystemen (engl. legacy systemen) (vgl. [Erl05], S. 200). Mithilfe der Webservice-Erweiterungen wie WS-BPEL kann die Orchestration eines Systems über festgelegte Standards integriert werden. Die zugrunde liegende Plattform muss lediglich über eine entsprechende Orchestrationsengine verfügen um bestimmte Prozesse ausführen zu können. Innerhalb der Orchestrationsschicht können unbegrenzt viele Regeln, Konditionen und Ereignisse mithilfe der Prozessbeschreibung (siehe Punkt 3.5 Prozessbeschreibung) festegelegt werden (vgl. [Erl05], S. 200). Es wurde bereits erwähnt, dass über die Einführung einer Orchestrationsschicht die Wartbarkeit von Systemen erleichtert wird, da ein Prozess unabhängig von anderen Systemkomponenten erweitert oder ausgetauscht werden kann. Ein weiterer Vorteil gegenüber der Implementierung in der Anwendungsschicht ist die gesteigerte Übersichtlichkeit der gesamten Systemarchitektur. Jeder Prozess wird über eine einheitliche Schnittstelle von den anderen Schichten getrennt, was zur Folge hat, dass einzelne Webservices nicht mehr über mehrere Schnittstellen angesprochen werden müssen. Diese Aufgabe übernimmt die Orchestrationsschicht. Die folgenden zwei Abbildungen veranschaulichen die beiden unterschiedlichen Konzepte mithilfe einer vereinfachten Darstellung. Abbildung 1: Prozessmodellierung ohne Kapselung (Selbst erstellt)

6 Abbildung 2: Prozessmodellierung mit Kapselung (Selbst erstellt) 3. Business Process Execution Language 3.1 Entwicklungsgeschichte Abbildung 3: Geschichte von WS-BPEL (Selbst erstellt) Die Business Process Execution Language for Web Services (BPEL4WS) wurde mit der Veröffentlichung der Spezifikation BPEL4WS 1.0 im Juli 2002 erstmals der Öffentlichkeit vorgestellt. Zu diesem Zeitpunkt arbeiteten die Unternehmen IBM, Microsoft und BEA Systems zusammen an der Entwicklung dieser Sprache. BPEL übernahm dabei viele Aspekte der beiden Vorgängersprachen WSFL (IBM) und XLANG (Microsoft) auf die weiter unten noch einmal eingegangen wird.

7 Um es Herstellern zu ermöglichen sich an einem offenen Standard und nicht an unterschielichen Spezifikationen zu orientieren übergab man BPEL4WS im April 2003 zur Standardisierung an die OASIS. Mithilfe der Unternehmen SAP und Siebel Systems wurde weniger als ein Jahr nach der ersten Veröffentlichung im Mai 2003 die Erweiterung BPEL4WS 1.1 herausgegeben. Dieser Version wurde von Herstellerseite mehr Aufmerksamkeit gewidmet, was die Entwicklung mehrerer BPEL-kompatibler Orchestrationsengines zur Folge hatte. (vgl. [Erl05], Seite 567) Am 14. September 2004 wurde die Spezifikation aufgrund der Anpassung an andere WS*-Standards wie WSDL oder WS-Addressing in WS-BPEL 2.0 (Webservice Business Process Execution Language) umbenannt. Schließlich endete der Standardisierungsprozess am 11. April (vgl. [Wiki], Stand der Entwicklung ) Bemerkung: Im Folgenden werden die beiden Akronyme BPEL und WS-BPEL synonym verwendet. Abbildung 4 Entstehung von BPEL BPEL XLANG Microsoft WSFL IBM (Selbst erstellt) XLANG: Microsoft veröffentlichte XLANG im Jahr 2001 als Geschäftsprozess-Sprache für das BizTalk ecommerce suite. XLANG ist eine relativ simple XML-basierte Sprache für die Modellierung von Prozessen. Die Servicebeschreibung eines XLANG-Prozesses wird ähnlich wie bei BPEL über ein WSDL-Dokument geregelt. WSFL: Die Web Service Flow Language wurde im Jahr 2001 von IBM aus dem Bedarf nach einem allgemein akzeptieren Standard zur Definition von Geschäftsprozessen herausgegeben. Obwohl sich WSFL in der Industrie kaum durchsetzen konnte gingen einige Grundideen dieser Sprache, wie z.b. das flow-konzept zur Ausführung paralleler Aktivitäten, später in die BPEL Spezifikation ein. (vgl. [Harvey05], S240)

8 3.2 Konzepte WS-BPEL unterstützt zwei unterschiedliche Konzepte. Das Konzept der Beschreibung abstrakter Prozesse: Abstrakte Prozesse dienen ausschließlich der Beschreibung von abstrakten Prozessmodellen. Solche Prozesse müssen als abstrakt gekennzeichnet werden und sind im Gegensatz zu ausführbaren Geschäftsprozessen nicht ablauffähig. Der Prozessesablauf wird hierbei meist nur teilweise festgelegt, wobei konkrete Details vernachlässigt werden können. Abstrakte Prozesse dienen häufig als Vorlage für ausführbare Geschäftsprozesse. (vgl. [SPEZ] ) Das Konzept der Implementierung ausführbarer Geschäftsprozesse: Ausführbare Geschäftsprozesse stellen Dienste zur Erfüllung einer bestimmten Aufgabe zur Verfügung. Dieses Konzept wird im laufe dieser Arbeit noch ausführlicher behandelt. 3.3 Einordnung Allgemeine Einordnung WS-BPEL ist eine XML-basierte Kompositionssprache zur Modellierung von Geschäftsprozessen. Sie ermöglicht eine lang andauernde Kommunikation zwischen mehreren Partnern, wobei der Prozess selbst als eine Art Vermittler zwischen den einzelnen Teilnehmern fungiert. Der BPEL-Prozess stellt dem Client bestimmte Dienste zur Verfügung und nutzt für die Diensterfüllung die Funktionen anderer Services, dies können einzelne Webservices oder wiederum eigenständige Prozesse sein. Nach außen hin tritt der Prozess als einheitlicher Service auf, wobei die eigentliche Umsetztung, also der interne Ablauf des Prozesses verschleiert wird. Eine direkte Interaktion mit einem Menschen ist bei der Kommunikation nicht möglich, da mindestens ein Partner z.b. ein Webservice zwischen Benutzer und Prozess geschaltet wird. Der Benutzer hat also keinen direkten Einfluss auf den Prozessablauf (vgl. [IBM-BPEL4P]). Mithilfe von WS-BPEL wird keine detaillierte Geschäftslogik implementiert sondern ausschließlich der Workflow der beteiligten Komponenten geregelt. In diesem Zusammenhang wird auch oft der Begriff Programmieren im Großen verwendet, da Sprachen wie BPEL eine Ebene über anderen Programmiersprachen wie Java oder C# zum Einsatz kommen. (vgl. [Wiki] )

9 3.3.2 Einordnung in das Schichtenmodell Abbildung 5 Einordung von WS-BPEL im Schichtenmodell (vgl. [Aalst]) Wie in Abbildung 5 zu erkennen ist setzt die Webservice-Kompositionsschicht direkt auf der Webserviceschicht auf. Im Folgenden werden die einzelnen Schichten kurz erläutert. Die Transportschicht stellt die erforderlichen Transportprotokolle für die Kommunikation zwischen den einzelnen Partnern zur verfügung. Neben dem Simple Mail Transfer Protocol (SMTP), das häufig für die -Kommunikation verwendet wird, und das File Transfer Protocol (FTP) ist hier das Hyper Text Transport Protocol (HTTP) zu nennen, das am häufigsten für den Informationsaustausch zwischen Webservices zum Einsatz kommt. Das darüber liegende SOAP Protokoll ist jedoch an kein bestimmtes Transportprotokoll gebunden weshalb auch andere Standards verwendet werden könnten. Die ausgetauschten Nachrichten werden in Form einer SOAP-Message übermittelt. Das SOAP (ursprünglich Simple Object Access Protocol) Protokoll dient der Beschreibung eines XML-Nachrichtformats. Hiermit können entweder ganze XML-Formate übermittelt oder Methoden mithilfe von Remote Procedure Calls aufgerufen werden. (vgl. [Erl05] S. 146) Die Servicebeschreibung wird in Form eines WSDL-Dokuments hinterlegt. WSDL dient als Schnittstelle zwischen dem Prozess und den beteiligten Partnern. (siehe Punk 3.4 Servicebeschreibung) Direkt über dieser Webserviceschicht angesiedelt, übernehmen Kompositionssprachen wie WS-BPEL die Aufgabe der Webservice-Komposition bzw. Orchestration. (siehe Punkt 3.5 Prozessbeschreibung)

10 Die Publication and Discoveryschicht stellt ein Webservice-Repository zur Verfügung, dass zur Auffindung von Webservices verwendet werden kann. Die folgende Darstellung verdeutlicht die Rolle von SOAP und WSDL bei der Kommunikation mit einem WS-BPEL Prozess. In Abbildung 6 ist ein Client zu sehen, der eine SOAP-Nachricht an den Prozess sendet um eine Prozessinstanz zu erschaffen. Dies geschieht über die in der WSDL-Datei festgelegten Regeln. Als nächstes arbeitet der Prozess die einzelnen internen Schritte ab, die dem Client verborgen bleiben. Während des Ablaufs sendet der Prozess eigene SOAP-Anfragen an die einzelnen Partnerdienste und erhält von diesen ggf. eine Antwortnachricht zurück. Hierbei dient WSDL ebenfalls als Schnittstelle zwischen dem Prozess und den beteiligten Partnern. Schließlich wird dem Client eine Antwort in Form einer SOAP-Nachricht übermittelt. Abbildung 6 WS-BPEL Prozesses (vgl. [PELZ03])

11 3.4 Servicebeschreibung Jedem WS-BPEL Prozess wird eine Servicebeschreibung in Form eines WSDL-Dokuments zur Verfügung gestellt, dass alle benötigten Schnittstelleninformation enthält. Die Servicebeschreibung eines WS-BPEL Prozesses ähnelt der Beschreibung eines Webservices. Das WSDL-Dokument beinhaltet alle nötigen Informationen über angebotene und zu verwendende Dienste sowie die Beschreibung der abstrakten Beziehungen zwischen den einzelnen Partnern. Die Servicebeschreibung kann in die Teilbereiche abstrakte und konkrete Beschreibung unterteilt werden die im Folgenden erläutert werden. (vgl. [Erl05], S. 134) Abstrakte Beschreibung: Die abstrakte Beschreibung enthält ausschließlich Informationen, die in keiner Weise an bestimmte Technologien oder Protokolle gebunden sind. Hier werden sämtliche Schnittstelleninformationen in Form von type, porttype-, operation- und message-elementen hinterlegt. Diese Elemente werden in Tabelle 1 kurz beschrieben. Bemerkung: Die folgenden Beispiele sind der Einfachheit halber an manchen Stellen gekürzt worden. Außerdem wurden Namespace Zuordnungen in den meisten Fällen außer Acht gelassen. Tabelle 1 Elemente der abstrakten Servicebeschreibung <type> Mithilfe dieses Elements können Schema-Typen definiert werden, die z.b. als Teil einer Nachricht in einem message-element Verwendung finden. In diesem einfachen Beispiel wird ein Nachrichtentyp zur Abbildung eines Benutzers mit einer ID und einem Namen definiert. <type> <schema xmlns= targetnamespace=... > <complextype name= UserType > <sequence> <element name= ID type= xsd:integer /> <element name= Name type= xsd:string /> </sequence> <complextype> </schema> </type>

12 <message> Dieses Element beschreibt eine Nachricht, die bei der Kommunikation zwischen den einzelnen Partnern ausgetauscht wird. Eine message kann sich aus einem oder mehreren part-elementen zusammensetzen. In diesem Beispielt wird eine Requestnachricht beschrieben, die aus nur einem <part> Element besteht. <message name= getuserstaterequestmessage > <part name= UserParameter type= UserType > </message> <porttype> Dieses Element Beschreibt eine abstrakte Serviceschnittstelle und enthält eine Sammlung von angebotenen Operationen. Hier wird eine Serviceschnittstelle mit dem Namen UserPT beschrieben, die eine Methode GetUserState anbietet. <porttype name= UserPT > <operation name= GetUserState >... </operation>... </porttype> <operation> Diese Elemente werden innerhalb eines porttypes angegeben und enthalten nähere Informationen über die vom porttype angebotenen Operationen. Hier wird die Operation aus dem vorherigen Beispiel mit einem Input und Output Element versehen.... <operation name= GetUserState > <input message= getuserstaterequestmessage /> <output message= getuserstateresponsemessage /> </operation>

13 <partnerlinktype> Partnerlinktypes werden dazu verwendet die Kommunikationsbeziehungen aller teilnehmenden Services zu beschreiben. Über dieses Element wird einem Service (identifiziert über den porttype) ein role-element für jede Rolle, die er bei der Kommunikation annehmen kann, zugewiesen. In diesem Beispiel wird dem porttype aus dem vorherigem Beispiel die Rolle des UserServiceProvider zugewiesen. <partnerlinktype name= UserServiceType xmlns=... > <role name= UserServiceProvider > <porttype name= UserPT /> </role> </partnerlinktype Konkrete Beschreibung: Um eine Kommunikation mit den einzelnen Partnern zu ermöglichen muss die abstrakte Servicebeschreibung an konkrete physikalische Transportprotokolle gebunden werden. Innerhalb der konkreten Servicebeschreibung wird die eigentliche Verbindung zu den einzelnen Partnerservices festgelegt. Die hierzu benötigten Elemente sind in Tabelle 2 aufgelistet. Tabelle 2: Elemente der konkreten Beschreibung <binding> Mithilfe dieses Elements werden die, in der abstrakten Beschreibung definierten porttypes referenziert. Hierbei werden Protokoll- und Nachrichtendetails festgelegt. In diesem Beispiel wird der porttype aus dem vorherigen Beispiel an das SOAP Protokoll gebunden. Außerdem wird über das style Attribut festgelegt ob die Request-Nachricht im RPC-Style (rpc) oder Message-Style (document) verfasst werden muss. <binding name= UserBinding type= UserPT > <soap:binding style= rpc transport= /> <operation name= GetUserState > <soap:operation soapaction= /> <input> <soap:body use= literal > </input> <output> <soap:body use= literal > </output> </operation> </binding>

14 <service> Dieses Element wird dazu verwendet die physikalische Adresse des Services mithilfe eines port-elements festzulegen. In diesem Beispiel wird das UserBinding an eine reale Adresse gebunden. <service name= UserService > <port binding= UserBinding name= UserPort > <soap:address location= /> </port> </service> Bemerkung: Der BPEL-Prozess referenziert in der Prozessbeschreibung nur die abstrakten porttypes und keine konkreten bindings, dadurch kann sich die physikalische Bindung an die Partner ständig ändern, ohne den Prozess selbst zu beeinflussen. (vgl. [SPEZ]) 3.5 Prozessbeschreibung Jeder Prozess folgt einem bestimmten Ablauf und festgelegten Regeln, welche zusammengefasst als Prozessprotokoll bezeichnet werden. Im Falle von WS-BPEL wird dieses Protokoll innerhalb eines BPEL-Dokument, der Prozessbeschreibung festgelegt. Hier findet also die eigentliche Modellierung des Prozesses über verschiedene Konstrukte und Aktivitäten statt. Die wichtigsten Elemente der Prozessbeschreibung werden in den folgenden Abschnitten kurz erläutert. Bemerkung: In der Praxis helfen verschiedene Tools wie der JDeveloper BPEL Designer der Firma Oracle oder der IBM Websphere Integration Developer bei der Modellierung von BPEL- Prozessen, sodass Entwickler kaum noch in Kontakt mit echtem BPEL-Code gelangen Konstrukte der Prozessbeschreibung Die wichtigsten Elemente der Prozessbeschreibung werden standardmäßig am Anfang des BPEL-Dokumentes definiert. Hierzu gehören unter anderem Konstrukte für die Variablendeklaration oder der Festlegung der Beziehung zwischen dem Prozess und den einzelnen Partnern. Die folgende Tabelle gibt eine Übersicht über die wichtigsten Konstrukte der Prozessbeschreibung.

15 Tabelle 3: Konstrukte der Prozessbeschreibung <partnerlink> Über partnerlinks werden die Rollen der Partner bei der Kommunikation mit dem Prozess festgelegt. Mithilfe des Attributs myrole kann die Rolle des Prozesses festgelegt werden. Die Rolle des Partners wird über das partnerrole Attribut geregelt. Hierzu werden die möglichen Rollen der zuvor definierten partnerlinktypes verwendet. In diesem Beispiel wird ein partnerlink definiert, in dem der Prozess die Rolle des userrequester und der beteiligte Partner die Rolle des userservice übernimmt. <partnerlink name="userinforming" partnerlinktype="userservicetype" myrole="userrequester" partnerrole="userservice" /> <variable> Dieses Element dient der Deklaration einer Variablen eines bestimmten Typs. Der Wert einer Variablen kann beispielsweise bei dem Empfangen einer Nachricht zugewiesen und später beliebig manipuliert oder kopiert werden. Im folgenden Beispiel wird eine Variable User deklariert. <variables> <variable name="user" messagetype="getusermessage" />... </variables> <faulthandlers> Dieses Element wird dazu verwendet um Fehler abzufangen und entsprechend darauf zu reagieren. Im folgenden Beispiel wird ein Faulthandler definiert, der im Falle eines Bestellfehlers eine Fehlernachricht an den Client weiterleitet. <faulthandlers> <catch faultname="cannotcompleteorder" faultvariable="pofault" faultmessagetype="orderfaulttype"> <reply partnerlink="purchasing" porttype="lns:purchaseorderpt" operation="sendpurchaseorder" variable="pofault" faultname="cannotcompleteorder" /> </catch> </faulthandlers>

16 <compensation Hanlder> (Siehe Punkt Compensation Handler) Strukturierte Aktivitäten Strukturierte Aktivitäten werden verwendet um den Prozessfluß zu regeln. Mithilfe dieser Elemente können die einzelnen Bestandteile des Prozesses strukturiert und der Ablauf beeinflusst werden. In Tabelle 4 sind die hierfür wichtigsten Elemente aufgelistet. Tabelle 4: Strukturierte Aktivitäten <sequence> Über das sequence-element können mehrere Aktivitäten in einer bestimmten Reihenfolge abgearbeitet werden. In diesem Beispiel werden zwei Serviceanfragen nacheinander gesendet. <sequence> <invoke... >...</invoke> <invoke... >...</invoke> </sequence> <flow> Das flow-element ermöglicht es mehrere Aktivitäten parallel auszuführen, ohne auf das ende der vorherigen Aktivität warten zu müssen. Im folgenden Beispiel werden zwei Services parallel aufgerufen. <flow> <invoke... >...</invoke> <invoke... >...</invoke> </flow>

17 <if> Mithilfe dieses Elementes können Verzweigungen innerhalb des Prozesses formuliert werden. Im folgenden Beispiel wird eine bestimmte Aktivität nur ausgeführt falls die Variable userrole den wert admin besitzt. <if...> <condition> $userrole!= admin </condition> <throw... >...</throw> <else> <invoke...>...</invoke> </else> </if> <while> Dieses Element ermöglicht die wiederholte Ausführung bestimmter Aktivitäten, bis eine vorgegebene Bedingung erfüllt ist. In diesem Beispiel wird so lange eine Serviceanfrage gesendet bis die Eigenschaft auth der Uservariable true ergibt. <while standard-attributes> <condition>user.auth = false</condition> <invoke...>...</invoke> </while> <pick> Über dieses Element kann auf bestimmte Ereignisse, wie das Empfangen einer Nachricht gewartet und entsprechend reagiert werden. Im folgenden Beispiel wird auf das eintreffen einer Nachricht gewartet. Falls eine solche Nachricht empfangen wird sendet der Prozess eine Serviceanfrage an einen Partnerservice. <pick> <onmessage partnerlink="buyer" porttype="..." operation="..." variable="..."> <invoke...>...</invoke> </onmessage> </pick>

18 <scope> Mithilfe des scope-elements können mehrere Aktivitäten zu einem Bereich gebündelt werden. Diesem Bereich kann dann beispielsweise eine einheitliche Fehlerbehandlung zugewiesen werden. In diesem Beispiel wird ein bestimmter Bereicht mit einem Faulthandler und einer Sequenz von Aktivitäten versehen. <scope> <faulthandlers> <catch faultname=... > </catch> </faulthandlers> <sequence>...</sequence> </scope> Primitive Aktivitäten Primitive Aktivitäten übernehmen die grundsätzlichen Aufgaben des Prozesses wie das Austauschen von Nachrichten oder Aktionen zur Datenmanipulation. Tabelle 5: Primitive Aktivitäten <invoke> Hiermit können Funktionen anderer Services aufgerufen werden. In diesem Beispiel wird die Operation GetUserState des porttypes UserPT aufgerufen und die output- und input-variable festgelegt. <invoke partnerlink="userpl" porttype="userpt" operation="getuserstate" inputvariable="shippingrequest" outputvariable="shippinginfo"> </invoke>

19 <receive> Über dieses Element werden Clientanfragen entgegengenommen. Das folgende Beispiel zeigt, wie auf die Anfrage eines Client gewartet wird. Hierbei ist der porttype die Serviceschnittstelle des angebotenen Dienstes. Die empfangene Nachricht wird in die Variable userrequest geschrieben. <receive partnerlink="informing" porttype="processpt" operation="getuserinfo" variable="userrequest" createinstance="yes"> </receive> <reply> Dieses Element dient dem Senden einer Antwortnachricht an den Client. In diesem Beispiel wird eine Antwortnachricht an den Anfragenden Client gesendet, dies geschieht meist am ende des Prozesses. <reply partnerlink="informing" porttype="processpt" operation="getuserinfo" variable="userresponse"> </reply> <assign > Hiermit können ganze Nachrichten oder Teile von Nachrichten kopiert werden. Im folgenden Beispiel werden die Kundeninformationen einer empfangenen Nachricht in die Nachricht einer Bestellanfrage kopiert. <assign> <copy> <from>$userrequest.customerinfo</from> <to>$orderrequest.customerinfo</to> </copy> </assign> <throw> Dieses Element wird dazu verwendet auf Fehler im Prozessablauf aufmerksam zu machen. In diesem Beispiel wird ein Fehler bei der Userauthentifikation geworfen. <throw faultname="userauthfault"/>

20 <wait> Dieses Element ermöglicht das Warten bis zu einem bestimmten Zeitpunkt. In diesem Beispiel wird bis zu einer bestimmten Uhrzeit an einem bestimmten Tag gewartet um eine Aktivität auszuführen. <sequence> <wait> <until>' t18:00+01:00'</until> </wait> <invoke... /> </sequence> <exit> Dieses Element Terminiert den Prozess Compensation Handler WS-BPEL bietet die Möglichkeit bestimmte Aktivitäten wieder rückgängig zu machen. Um dies zu implementieren werden Compensation Handler verwendet, die im Fehlerfall von einem Faulthandler aufgerufen werden. Das folgende Beispiel zeigt eine <invoke> Aktivität, für die ein inline Compensation Handler definiert wurde. Das <invoke> Element ruft einen Bestellservice auf. Im Falle einer Kompenstation wird der Bestellvorgang abgebrochen. <invoke partnerlink="seller" porttype="sp:purchasing" operation="purchase" inputvariable="sendpo" outputvariable="getresponse"> <compensationhandler> <invoke partnerlink="seller" porttype="sp:purchasing" operation="cancelpurchase" inputvariable="getresponse" outputvariable="getconfirmation"> </invoke> </compensationhandler> </invoke> Kompensation von verschachtelten Bereichen (Scopes): In Abbildung 6 wird das Zusammenspiel von Fehlerbehandlung und Compensation-Handler verdeutlicht. Dem Prozess P wird eine Fehlerbehandlung FH(P) zugewiesen. Innerhalb des Prozesses wurden zwei verschachtelte Scopes S2 und S3 definiert und mit eigenen Compensation-Handlern versehen. Fängt der Prozess über eine Catch-Aktivität einen Fehler auf, wird zuerst der Compensation Handler CH(S2) und danach der Compensation Handler CH(S1) aufgerufen. Die Handler haben dabei unter anderem Zugriff auf zuvor definierte Variablen und können diese gemeinsam verwenden.

21 Abbildung 7 Compensation Handler (Quelle: [SPEZ]) 4.0 BPEL und SOA Serviceorientierte Architekturen kurz SOA sind ein auf Webservice basierendes Architekturmodell, dass anfangs aufgrund der Komplexität bei vielen Entwicklern für Verwirrung sorgte. In SOA Anwendungen zerlegt man ein gegebenes Problem so weit wie möglich in untergeordnete Teilprobleme um die Softwarelösung auf mehrere plattformunabhängige Services verteilen zu können. Die Idee der Kapselung einzelner Dienste war jedoch kein revolutionärer Gedanke in der IT-Welt. Spezifikationen wie beispielsweise CORBA verfolgten dieses Konzept bereits vor der Einführung des Begriffes SOA. Nichtsdestotrotz ist SOA ein sehr mächtiges Modell mithilfe dessen einzelne Komponenten einer Anwendung ohne Probleme ausgetauscht oder für andere Problemlösungen eingesetzt werden können. Der Aufbau einer SOA lässt erkennen, dass Kompositionssprachen und vor allem WS-BPEL eine wichtige Rolle innerhalb solcher Lösungen spielt. BPEL-Prozesse werden dabei nicht nur dafür verwendet Services anderer Unternehmen miteinander zu verbinden, sonder sind außerdem für die Verknüpfung Unternehmensinterner Abläufe zuständig. Einem BPEL- Prozess wird dabei eine bestimmte Verantwortlichkeit über die zugrunde liegenden

22 Webservices übertragen. Der Prozess ist also für die Ausführung der Services in den darunter liegenden Schichten verantwortlich. In Abbildung 7 ist das Schichtenmodell einer SOA-Anwendung dargestellt. Hier übernimmt ein WS-BPEL Prozess die Aufgabe der Orchestration der untergeordneten Webservices, die wiederum die Funktionalität der Anwendungsschicht verwenden. Abbildung 7 SOA Schichtenmodell mit eigener Orchestrationsschicht (Quelle: [Erl05])

23 5.0 Fazit: Obwohl WS-BPEL eine relativ junge Sprache ist, genießt sie schon jetzt eine hohe Akzeptanz von Seitens vieler Unternehmen und zeichnet sich vor allem durch eine breite Funktionalität aus. Auch das stetig wachsende Interesse an Serviceorientierten Architekturen trägt zu der bedeutenden Rolle dieser Sprache in jetzigen aber insbesondere auch in zukünftigen Systemen bei. Leider ist BPEL durch die hohe Anzahl an Möglichkeiten und Funktionen eine ziemlich komplexe Sprache und bereitet vor allem Neueinsteigern erhebliche Probleme. Zwar gibt es eine Vielzahl von hilfreichen Modellierungstools, die das automatisierte erstellen von BPEL-Prozessen ermöglichen, doch sind diese meist mit einem hohen Preis verbunden. So müssen Unternehmen für eine IBM WebSphere Integration Developer Lizens US Dollar bezahlen, was insbesondere für kleinere Unternehmen, neben Ausgaben für andere Middlewareprodukte, relativ viel ist. Nichtsdestotrotz ist BPEL eine vielversprechende Kompositionssprache, die sich ständig weiterentwickelt und sich dadurch wohl noch weiter von anderen Workflowsprachen absetzen wird.

24 Literatur und Quellverzeichnis Bücher: [Erl05] [Harvey05] Thomas Erl - Service-Oriented Architecture Concepts, Technology, and Design Prentice Hall International - September 2005 ISBN Michael Harvey Essential Business Process Modeling O'Reilly Media; Auflage: August 2005 ISBN Web: [Aalst] Van der Aalst, W. Don t go with the flow: Web services composition standards exposed: letzter Zugriff: [IBM01] IBM developerworks - Business Process with BPEL4WS: search_by=bpel4ws: [IBM- BPEL4P] [IBM-WS] [PELZ03] [SPEZ] [Wiki] letzter Zugriff: BPEL for Poeple letzter Zugriff: Standards and Web services letzter Zugriff: Chris Peltz Web Service Orchestration and Choreography letzter Zugriff: WS-BPEL 2.0 Spezifikation letzter Zugriff: Business Process Execution Language letzter Zugriff: