Web Services Integration mit Oracle BPEL Process Manager

Transkript

1 Donnerstag, 11. November h00, Variohalle 1 Web Services Integration mit Oracle BPEL Process Manager Michael Stapf ORACLE Deutschland GmbH, Frankfurt Schlüsselworte: Business Process Execution Language (BPEL), Prozessintegration, Web Services Orchestration, Service-orientierte Architektur (SOA), Geschäftsprozessmanagement Zusammenfassung Eine effiziente Umsetzung der in den Fachbereichen benötigten Geschäftsprozesse gehört zu den Kernzielen jeder IT-Abteilung. Gelingt es uns diese zu verbessern, haben wir viel erreicht. Neue Standards und Architekturkonzepte können dabei helfen. Web Services Technologien werden im Zeitalter von Service Architekturen (SOA) immer wichtiger. Oracle setzt auch hier auf offene Standards wie der Business Process Execution Language (BPEL). Mit dem Oracle BPEL Process Manager ist Oracle hier Vorreiter am Markt. Der Vortrag stellt die Möglichkeiten dar, die sich mit diesem brandneuen Produkt eröffnen. BPEL gilt als das "SQL" für das Thema "Business Process Management". Anwendungen und Dienste lassen sich damit orchestrieren und zu automatisierten End-zu-End Geschäftsprozessen integrieren. Der Beitrag zeigt die zugrundeliegenden Konzepte von BPEL zur Beschreibung von Prozessen zur Integration einzelner Dienste und stellt den Umgang auf Basis der BPEL-Plattform von Oracle an einem Beispiel detailliert dar. Damit soll ein schneller Einstieg in diese spannende Thematik besser gelingen. Einleitung IT-Architekturen die wir in der heutigen Zeit brauchen, bauen auf eine konsolidierte Software-Plattform, die offene Standards unterstützt, auf. Hier hinein spielen Trends wie "Real-time Enterprise", eine neue Orientierung auf die Geschäftsprozesse eines Unternehmens und der Trend bei der Softwareentwicklung alles aus einem Service-Blickwinkel zu betrachten. Oracle beschreibt mit

2 KONFERENZ seiner Oracle Information Architecture einen Architekturrahmen der auch den Geschäftsprozessteil mit berücksichtigt (siehe Abb. 1). Hier setzt BPEL als offener Standard für die Beschreibung von Geschäftsprozessen im Kontext von Web Services an. Hier verbirgt sich ein enormes Potenzial für eine bessere Umsetzung der Geschäftsanforderungen und damit eine für das Unternehmen wertvollere IT-Infrastruktur. Abb. 1: Oracle Information Architecture Service Architekturen Dieser schon länger bekannte Architekturansatz wird durch die Verfügbarkeit von "neuen" offenen Standards wie Internetprotokolle, XML und Web Services mit neuem Leben erfüllt. Es ist eine Architektur mit entsprechenden Richtlinien und Regeln für den Software-Entwurf. Das wichtigste Konzept dabei ist ein Dienst (Service). Ein Dienst ist eine Leistung den ein Dienstleister erbringt. Ein Dienst wird von einem Dienstnutzer genutzt. Allgemeine Beispiele für Dienstleistungen: Eine Fluggesellschaft fliegt Passagiere von Ort A nach Ort B. Sie ist also ein Dienstleister für Flugreisen. Wir telefonieren mit unserem Handy über ein Mobilfunknetz. Der Anbieter dafür ist daher ein Dienstleister für mobile Telekommunikationsdienste. Wir sind die Nutzer dieses Dienstes. Der Dienst lässt sich durch eine Abfolge von Aktivitäten beschreiben. Ein Dienst kann für seine Umsetzung auch weitere andere Dienste nutzen. Die Dienste müssen dafür miteinander interagieren. Alles was an Aktivitäten notwendig ist, um solch einen Dienst zu erbringen bezeichnen wir als einen Geschäftsprozess. Ein Geschäftsprozess kann sich auch aus vielen Geschäftsprozessen zusammensetzen. Ein Prozess kann wiederum einen Dienst erbringen. Diese Wechselwirkung zwischen Dienst und Geschäftsprozess macht das

3 Ganze interessant. Ein Geschäftsprozess oder auch ein Teil davon wird durch Software unterstützt. Generelles Ziel ist es, solche Prozesse schneller, flexibler, effizienter und kostengünstiger zu machen. Dahinter stecken Geschäftsziele wie die Erhöhung der Kundenzufriedenheit, Verkürzung der Lieferzeiten, Verbesserung der Timeto-market, Nutzung eines Window-of-Opportunity, Senkung der Kosten etc. Dies wird erreicht durch Automatisierung. Manuelle Aktionen werden aus den Prozessen herausgenommen. Das Unternehmen will Wettbewerbsvorteile gegenüber der Konkurrenz erzeugen und nutzt Informationstechnolgie und insbesondere Software um dies zu erreichen. Das zweite wichtige Konzept ist eine definierte Schnittstelle für den Dienst. Definiert heißt, es ist genau beschrieben, was ein Dienst leisten kann. Beispiel Airline: Ein Flug von Flughafen A nach Flughafen B zu einem bestimmten Zeitpunkt mit Abflug- und Ankunftzeit. Schnittstelle ist die Stelle wie und wo wir den Dienst nutzen können. Wir gehen zum Schalter und bekommen das Flugticket, gehen rechtzeitig zum Abflug-Gate und steigen in das Flugzeug ein. Wie die Fluggesellschaft dies alles intern organisiert (implementiert) hat, ist für uns als Nutzer nicht relevant. Generell hat ein Unternehmen viele solche Dienstleister um effizient zu funktionieren. Dienstleister sollen auch flexibel ausgewechselt werden können. Klassisch wurde Software als monolithischer grosser Block entwickelt. Dies hat Nachteile wie ein eng begrenztes Einsatzgebiet. Ein service-orientierter Ansatz bietet Vorteile für die Realisierung und den Betrieb von Software. Funktionalitäten werden nicht mehr in einer grossen Einheit sondern, als klar geschnittene separate Dienste realisiert und erst im Anschluss durch eine dynamische gemeinsame Nutzung zu einem neuen Dienst, der einen bestimmten Geschäftsprozess realisiert, zusammengefügt. Dies erreichen wir durch die Integration der Dienste. Wir wollen das aber nicht fest sondern flexibel gestalten. Daher brauchen wir hier eine Softwareinfrastruktur die uns erlaubt, genau dieses zu tun. Dies wird im Web Services Kontext auch "Orchestration genannt. Genau wie ein Dirigent die Musiker eines Orchesters dirigiert, sorgt diese Softwarekomponente für ein harmonisches Zusammenspiel unserer softwarebasierten Dienste um damit einem Geschäftsprozess Kontinuität und Transparenz zu verleihen.

4 KONFERENZ Abb. 2: Monolithischer Ansatz vs. Service-orientierte Architektur BPEL kompakt Die Business Process Execution Language (BPEL) wurde 2003 bei OASIS [1] (Organization for the Advancement of Structured Information Standards) zur weiteren Standardisierung eingereicht. Mit BPEL lässt sich ein Prozess beschreiben, der in der Lage ist verschiedene Dienste zu einer Gesamtanwendung zu verknüpfen. Dies wird auch Orchestration genannt. Es gibt also im Kern verschiedene Dienste, die mit Hilfe einer BPEL-basierten Prozessbeschreibung zu einer neuen Softwareanwendung zusammengesetzt werden. Die Dienste sind lose gekoppelt und interagieren über die BPEL-Ablaufumgebung miteinander. Abb. 3: Web Service Orchestration BPEL basiert auf XML. Ein Prozesstemplate ist also ein XML-Dokument das Elemente enthält, die dem BPEL-Standard genügen. Jedes BPEL-Dokument besteht aus einem Definitionsteil und einem Teil, der den Prozessverlauf beschreibt. Der Definitionsteil enthält die Variablen <variables> und die Endpunkte sogenannte "partnerlinks". Variablen dienen dem Austausch von Nach-

5 richten zwischen den Aktivitäten und Diensten. Der Typ einer Variablen ist immer ein WSDL-Nachrichtentyp. <partnerlink>s sind Dienste mit denen der Prozess interagiert. Der Ablaufteil beschreibt die Abfolge der Aktivitäten (Activities) also quasi die Prozesslogik. Es sind verschiedene aufeinanderfolgende oder parallele Aktivitäten, die einen Prozessfluss bzw. die Ablaufsequenz abbilden. Es lassen sich auch Fehlerbehandlungen und Kompensationen für einen Prozess definieren. Die Grundstruktur eines Prozesses ist in Abb. 4 aufgezeigt. Der gesamte Beispielprozess ist in Abb. 8 vollständig dargestellt. <process name="hallodoag" <!-- Prozess --> <partnerlinks> <!-- Dienste --> </partnerlinks> <variables> <!-- Daten --> </variables> <sequence name="main"> <!-- Ablaufsequenz --> <receive> <assign> <!--Aktivitäten --> <reply> </sequence> </process> Abb. 4: Grundstruktur eines BPEL-Dokuments Die wichtigsten Konstrukte sind "Basic Activities" etwa für den Aufruf von Diensten und "Structured Activities" welche die Reihenfolge der Aktivitäten beschreiben, die den Ablauf eines Prozesses bestimmen. <assign> zum Kopieren von Daten von einer Variable zur nächsten, auch unter Verwendung von Ausdrücken. <invoke> Aufruf einer Operation eines Dienstes. Kann synchron oder asynchron sein. <receive> spezifziert den Dienst von dem der Empfang einer Variablen erwartet. Kann auch zum Aktivieren einer Prozessinstanz genutzt werden. <reply> wird zum Verschicken einer Antwort auf eine vorherige <receive> Aktivität. Bezieht sich immer genau auf einen bestimmten <partnerlink> porttype und Operation innerhalb einer synchronen Interaktion. <throw> zur Beschreibung von anwendungsspezifischen Fehlerfällen. <terminate> dient zum expliziten Beenden eines Prozesses. <wait> wartet eine definierte Zeitspanne oder bis ein bestimmter Zeitpunkt überschritten ist. <empty> eine Aktivität die "nichts" tut. Dient etwa zur Synchronisierung von nebenläufigen Aktivitäten.

6 KONFERENZ <sequence> beinhaltet Aktivitäten, die in einer definierten Reihenfolge abgearbeitet werden. <scope> ist ein Ausführungskontext für Aktivitäten mit der Möglichkeit eigene "Fault Handler" zu definieren. <scope>s lassen sich ineinander verschachteln. <pick> wartet auf ein bestimmtes Ereignis, wie etwa eine Nachricht von einem <partnerlink> oder einen Alarm, um mit dem Prozessfluss fortzufahren. <flow> für die parallele Ausführung von Aktivitäten. <switch> für fallbasierte Verzweigungen. <while> zur wiederholten Ausführung bis eine Bedingung nicht mehr erfüllt ist. <compensate> zum Definition einer Kompensation für Aktivitäten innerhalb eines <scope>. Daneben gibt es weitere Kontrollkonstrukte im Rahmen der BPEL, die im Zusammenhang mit bestimmten Aktivitäten zum Tragen kommen können: <case>, <otherwise>, <catch>, <onmessage>, <onalarm> z.b. mit <switch> und <pick>, <copy>, <from>, <to> innerhalb von Zuweisungen <assign>, <correlationsets> und <correlation> zur inhaltsbasierten Korrelation von Nachrichten, <eventhandlers> innerhalb eines <scope> für das Empfangen von Events ausserhalb des normalen Ablaufs. Neben der Beschreibungssprache für den Prozess spielen weitere offene Standards in Kontext von BPEL eine wichtige Rolle. Im Kern sind dies die W3C Standards für Web Services, insbesondere die Web Services Beschreibungssprache WSDL [2] und XML-Standards wie XPath [3], XSL und XQuery. Oracle BPEL Process Manager Um effizient mit dem BPEL-Standard arbeiten zu können sind entsprechende Werkzeuge, eine performante Abblaufumgebung sowie eine Konsole für die Verwaltung und das Monitoring der Prozess-Instanzen vonnöten. Das ist analog, wie bei SQL: Ohne die richtige Implementierung der Datenbank kann der Standard nicht richtig in einer produktiven Umgebung genutzt werden. Der Oracle BPEL Process Manager [4] enthält all diese Elemente: BPEL Designer für die grafische Modellierung der BPEL-Prozesse, BPEL Console als Verwaltungsoberfläche, BPEL Engine als native Ablaufumgebung, sowie eine Datenbank für die Persistierung von langlaufenden Prozessen.

7 Abb. 5: BPEL Designer Es gibt einen Navigator mit den notwendigen Dateien für ein BPEL-Projekt. Für die grafische Darstellung gibt es eine Überblickssicht (Overview) und eine Prozessdarstellung (Process Map). Es lässt sich dynamisch zwischen der grafischen und der Kodierungssicht hin und her schalten. Auf der rechten Seite gibt es eine BPEL Palette, als Einstiegspunkt um alle Aktivitäten per Drag & Drop in den Prozessfluss einzufügen. Hier können auch vordefinierte Teilprozesse oder Prozessfragmente als wiederverwendbare Makros nutzen. Es gibt solche Makros für User Tasks, für synchrone und asynchrone Dienstaufrufe. Jede Aktivität kann mit dem BPEL Inspector weiter beschrieben werden. Es gibt auch einige Erweiterungen, wie die Aktivität FlowN, die Möglichkeit Makros mit häufig benötigten Abläufen wiederzuverwenden oder die Möglichkeit Java-Code direkt in das BPEL-Dokument einzubetten. Für den Aufruf von nicht SOAP-basierten Web Services wird das Web Services Invocation Framework (WSIF) [5] mit entsprechenden Bindings verwendet. Damit können Dienste auch mittels anderer APIs oder Protokolle wie etwa JCA-Adapter, JMS oder genutzt werden. Modellierung synchroner Prozesse Am einfachen Beispiel eines klassischen "Hello World" auf Basis von BPEL, will ich nun die Vorgehensweise und die Nutzung der BPEL-Umgebung näher erläutern.

8 KONFERENZ Abb. 6: Beispielszenario für einen synchronen Prozess Zunächst wird im BPEL Designer ein neues Projekt mit dem Namen "Hallo- DOAG" angelegt. Dies erzeugt die dazu notwendige Struktur. Die Struktur eines BPEL-Projekts besteht aus:.projects Projektfile bpel.xml Deployment Deskriptor für den Prozess build.xml Ant-Skript für die Kompilierung und das Deployment HalloDOAG.bpel für dir Prozessbeschreibung HalloDOAG.wsdl für die Beschreibung des Client Interface bzw. des Services. <?xml version="1.0" encoding="utf-8"?> <BPELSuitcase> <BPELProcess id="hallodoag" src="hallodoag.bpel"> <partnerlinkbindings> <partnerlinkbinding name="client"> <property name="wsdllocation">hallodoag.wsdl </property> </partnerlinkbinding> </partnerlinkbindings> </BPELProcess> </BPELSuitcase> Abb. 7: Deployment Deskriptor: bpel.xml

9 <!-- HalloDOAG BPEL Process [Generated by the Oracle BPEL Designer] --> <process name="hallodoag" targetnamespace=" suppressjoinfailure="yes" xmlns:tns=" xmlns=" xmlns:bpelx=" xmlns:ora=" <!-- ================================================================= --> <!-- PARTNERLINKS --> <!-- List of services participating in this BPEL process --> <!-- ================================================================= --> <partnerlinks> <!-- The 'client' role represents the requester of this service. --> <partnerlink name="client" partnerlinktype="tns:hallodoag" myrole="hallodoagprovider"/> </partnerlinks> <!-- ================================================================= --> <!-- VARIABLES --> <!-- List of messages and XML documents used within this BPEL process --> <!-- ================================================================= --> <variables> <!-- Reference to the message passed as input during initiation --> <variable name="input" messagetype="tns:hallodoagrequestmessage"/> <!-- Reference to the message that will be returned to the requester --> <variable name="output" messagetype="tns:hallodoagresponsemessage"/> </variables> <!-- ================================================================= --> <!-- ORCHESTRATION LOGIC --> <!-- Set of activities coordinating the flow of messages across the --> <!-- services integrated within this business process --> <!--================================================================== --> <sequence name="main"> <!-- Receive input from requester. Note: This maps to operation defined in HalloDOAG.wsdl --> <receive name="receiveinput" partnerlink="client" porttype="tns:hallodoag" operation="process" variable="input" createinstance="yes"/> <!-- Generate reply to synchronous request --> <assign name="verknuepfung"> <copy> <from expression="concat("hallo ",bpws:getvariabledata("input","payload","/tns:hallodoagrequest/tns: input"))"> </from> <to variable="output" part="payload" query="/tns:hallodoagresponse/tns:result"/> </copy> </assign> <reply name="replyoutput" partnerlink="client" porttype="tns:hallodoag" operation="process" variable="output"/> </sequence> </process> Abb. 8: Prozessbeschreibung "HalloDOAG.bpel"

10 KONFERENZ?xml version="1.0"?> <definitions name="hallodoag" targetnamespace=" xmlns:tns=" xmlns:plnk=" xmlns=" > <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TYPE DEFINITION - List of types participating in this BPEL process The BPEL Designer will generate default request and response types but you can define or import any XML Schema type and use them as part of the message types. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <types> <schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace=" xmlns=" <element name="hallodoagrequest"> <complextype> <sequence> <element name="input" type="string"/> </sequence> </complextype> </element> <element name="hallodoagresponse"> <complextype> <sequence> <element name="result" type="string"/> </sequence> </complextype> </element> </schema> </types> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type definitions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <message name="hallodoagrequestmessage"> <part name="payload" element="tns:hallodoagrequest"/> </message> <message name="hallodoagresponsemessage"> <part name="payload" element="tns:hallodoagresponse"/> </message> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- porttype implemented by the HalloDOAG BPEL process --> <porttype name="hallodoag"> <operation name="process"> <input message="tns:hallodoagrequestmessage" /> <output message="tns:hallodoagresponsemessage"/> </operation> </porttype> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PARTNER LINK TYPE DEFINITION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <plnk:partnerlinktype name="hallodoag"> <plnk:role name="hallodoagprovider"> <plnk:porttype name="tns:hallodoag"/> </plnk:role> </plnk:partnerlinktype> </definitions> Abb. 9: WSDL-Datei für den Prozess "HalloDOAG.wsdl"

11 Für die Modellierung synchroner Prozesse, wird das Konstrukt <receive> und <reply> genutzt. Das generierte BPEL-Datei enthält bereits die komplette Grundstruktur dafür. Es ist nur noch die Aktivität für die Datenmanipulation zu ergänzen. Mit <assign> kann eine Input-Variable mit Hilfe von XPath-Funktionen mit einer vorhandenen - in unserem Fall dem String "HALLO " - verknüpft und an eine Output-Variable übergeben werden. Mit dem "Copy Rule"- Editor lassen sich entsprechende Regeln definieren. Abb. 10: <assign> Aktivität Copy Rule Editor Deployment und Test Nachdem der Prozess modelliert und beschrieben ist, wird das BPEL-Projekt kompiliert und in die BPEL Ablaufumgebung übertragen. Es wird eine Datei "bpel_hallodoag_1.0.jar" erzeugt und im Verzeichnis "BPEL_HOME/domains/ default/deploy" abgelegt. Es lassen sich Domänen als logische Unterteilung zur Gruppierung von Prozessen definieren. Da die BPEL Engine in jeden standardkonformen J2EE Container läuft kommt hierfür neben den Oracle Containers for J2EE (OC4J) auch weitere wie BEA Weblogic, IBM Websphere oder JBoss in Frage. Für den Test steht die BPEL Console für das Management der Umgebung zur Verfügung, um die Prozessinstanzen zu testen, zu debuggen und zu überwachen (siehe Abb. 11).

12 KONFERENZ Abb. 11: BPEL Console Modellierung asynchroner Prozesse Asynchrone Prozesse sind wichtig, um lose gekoppelte Interaktionen abzubilden. Ist ein Dienst etwa nicht in der Lage sofort (synchron) zu antworten, weil etwa ein Sachbearbeiter manuell eine Prüfung dazu vornehmen muss, so ist es wichtig, dass die Prozess-Ablaufumgebung in der Lage ist, damit umzugehen. Hier kommt das Konstrukt <invoke> und <receive> zum Einsatz. Auch hierzu wird im Vortrag ein Beispiel erläutert. Zusammenfassung BPEL ist ein Kernelement um eine effektive, flexible und damit kostensparende Realisierung einer modernen IT-Architektur zu erreichen. Zum ersten Mal steht eine standardisierte Beschreibungssprache für Prozesse zur Verfügung. Dies allein lässt einen neuen Produktivitäts- und Innovationsschub in der IT analog zu SQL erwarten. Erste Erfahrungen mit dem neuen Produkt zeigen eine schnelle und einfache Einarbeitung. Voraussetzung sind Grundkenntnisse in XML, Java und den Web Services Standards. Oracle stellt hier in bewährter Manier eine einfach nutzbare Lösung für die Modellierung, das Monitorung und den Ablauf von mit BPEL beschriebenen Prozessen zur Verfügung. Dies ist eine wesentliche Kernkomponente für eine effiziente Implementierung nach SOA Prinzipienn mit dem Oracle 10g. Damit lässt sich die Komplexität von Prozessintegrationsprojekten besser beherrschen und dadurch können die Umsetzungs- und Betriebskosten dramatisch reduziert werden.

13 Literatur [1] [2] [3] [4] [5] Kontaktadresse: Michael Stapf ORACLE Deutschland GmbH Geschäftsstelle Frankfurt Solution House Development Framework & Integration Services Competence Center Integration Robert-Bosch-Straße 5 D Dreieich Telefon: +49(0) Fax: +49(0) michael.stapf@oracle.com Internet: