BPEL: Servicezusammensetzung für SOA

BPEL (Business Process Execution Language) hat sich zu einer der wichtigsten Technologien der SOA (serviceorientierte Architektur) entwickelt und ermöglicht die einfache und flexible Zusammenstellung von Services in Geschäftsprozessen. BPEL ist besonders wichtig, weil es ein neues Konzept in die Anwendungsentwicklung einführt - das Programmieren im Großen. Dieses Konzept ermöglicht es uns, Prozesse schnell zu entwickeln, indem wir die Reihenfolge definieren, in der Services aufgerufen werden. Auf diese Weise werden Anwendungen (und Informationssysteme) flexibler und können sich besser an die Änderungen in Geschäftsprozessen anpassen.

Geschäftsprozesse sind in der Regel dynamischer Natur. Unternehmen müssen sich verbessern und modifizieren, agil handeln, Prozesse optimieren und anpassen, um die Reaktionsfähigkeit des gesamten Unternehmens zu verbessern. Jede Änderung und Verbesserung eines Geschäftsprozesses muss sich in Anwendungen widerspiegeln, die sie unterstützen. Obwohl diese Anforderung möglicherweise nicht sehr schwer zu erfüllen ist, zeigt uns die reale Situation ein anderes Bild. Das Ändern und Ändern von Anwendungen ist oft eine schwierige Aufgabe, die Zeit erfordert. Daher können Anwendungen nicht sofort auf Änderungen in Geschäftsprozessen reagieren, sondern benötigen einige Zeit, um die Änderungen zu implementieren, zu testen und bereitzustellen.

Das Hauptversprechen von SOA besteht darin, Informationssysteme flexibler und anpassungsfähiger an Veränderungen anzupassen und besser auf Geschäftsprozesse abzustimmen. In diesem Artikel zeige ich, warum BPEL so wichtig ist und wie man einen BPEL-Prozess entwickelt.

Serviceorientierter Ansatz

Der SOA-Ansatz zur effizienten Automatisierung von Geschäftsprozessen erfordert:

  • Standardisierte Möglichkeit, die Funktionalität von Anwendungen als Dienste verfügbar zu machen und darauf zuzugreifen
  • Enterprise-Bus-Infrastruktur für die Kommunikation und Verwaltung von Diensten, einschließlich Abfangen von Nachrichten, Routing, Transformation usw.
  • Spezialsprache für die Zusammenstellung exponierter Funktionen von Anwendungen in Geschäftsprozessen

Die erste Anforderung wird von der neuesten verteilten Architektur erfüllt - Webdiensten. Die zweite Anforderung wird vom ESB (Enterprise Service Bus) erfüllt, der die zentrale, deklarative und gut koordinierte Verwaltung von Diensten und deren Kommunikation unterstützt. Die dritte Anforderung, die Zusammenstellung von Diensten zu Prozessen, wird von BPEL erfüllt, der allgemein anerkannten Fachsprache für die Definition und Ausführung von Geschäftsprozessen.

Ein Geschäftsprozess ist aus Sicht von BPEL eine Sammlung koordinierter Serviceaufrufe und zugehöriger Aktivitäten, die entweder innerhalb einer Organisation oder über mehrere hinweg zu einem Ergebnis führen. Ein Geschäftsprozess zum Planen von Geschäftsreisen ruft beispielsweise mehrere Dienste auf. In einem stark vereinfachten Szenario müssen wir für den Geschäftsprozess den Namen des Mitarbeiters, das Ziel, die Daten und andere Reisedetails angeben. Anschließend ruft der Prozess einen Webdienst auf, um den Mitarbeiterstatus zu überprüfen. Basierend auf dem Mitarbeiterstatus wird die entsprechende Reiseklasse ausgewählt. Anschließend werden Webdienste mehrerer Fluggesellschaften (wie American Airlines, Delta Airlines usw.) aufgerufen, um den Flugpreis zu überprüfen und den Preis mit dem niedrigsten Preis zu kaufen.

Für die Clients stellt der BPEL-Prozess seine Funktionalität auf dieselbe Weise wie jeder andere Webdienst bereit. Aus Client-Sicht sieht es genauso aus wie jeder andere Webdienst. Dies ist wichtig und nützlich, da wir damit Services zu einfachen Prozessen, einfache Prozesse zu komplexeren Prozessen usw. zusammensetzen können. Dies bedeutet auch, dass jeder BPEL-Prozess mit einer WSDL-Beschreibung (Web Services Description Language) beschrieben wird.

Kernkonzepte

BPEL ist eine XML-basierte Sprache. Ein BPEL-Prozess besteht aus Schritten. Jeder Schritt wird als Aktivität bezeichnet. BPEL unterstützt primitive und strukturelle Aktivitäten. Primitive Aktivitäten stellen grundlegende Konstrukte dar und werden für allgemeine Aufgaben verwendet, wie die unten aufgeführten:

  • Aufrufen von Webdiensten mit
  • Warten auf die Anfrage mit
  • Bearbeiten von Datenvariablen mit
  • Anzeigen von Fehlern und Ausnahmen, Verwenden usw.

Wir können diese Aktivitäten dann zu komplexeren Algorithmen kombinieren, die die Schritte eines Geschäftsprozesses festlegen. Um primitive Aktivitäten zu kombinieren, unterstützt BPEL mehrere Strukturaktivitäten. Die wichtigsten sind:

  • Sequence ( ) zum Definieren einer Reihe von Aktivitäten, die in einer geordneten Sequenz aufgerufen werden
  • Flow ( ) zum Definieren einer Reihe von Aktivitäten, die parallel aufgerufen werden
  • Case-Switch-Konstrukt ( ) zum Implementieren von Zweigen
  • While ( ) zum Definieren von Schleifen usw.

Wie wir sehen werden, unterscheidet sich BPEL nicht wesentlich von Programmiersprachen wie Java. Wir werden jedoch feststellen, dass sich BPEL von Java unterscheidet und die Merkmale von Geschäftsprozessen unterstützt. BPEL bietet auch Fehler- und Kompensationshandler, Ereignishandler und Korrelationssätze. Es bietet Mittel, um komplexe parallele Flüsse auszudrücken. Es macht es auch relativ einfach, asynchrone Operationen aufzurufen und auf Rückrufe zu warten.

BPEL-Prozesse erfordern eine Laufzeitumgebung - einen BPEL-Server, der uns eine gute Kontrolle über ihre Ausführung gibt. In der Regel bieten BPEL-Server die Kontrolle über ausgeführte und abgeschlossene Prozessinstanzen. Sie unterstützen lang laufende Prozesse und können den Prozessstatus dehydrieren, um Ressourcen zu sparen. Einige Server bieten Kontrolle über Prozessaktivitäten und ermöglichen deren Überwachung. Schließlich werden mithilfe eines BPEL-Servers alle unsere Prozesse zentral bereitgestellt, was die Wartung vereinfacht. All dies macht den BPEL-Server zur bevorzugten Umgebung für die Ausführung und Verwaltung von Prozessen.

Die Auswahl des richtigen BPEL-Servers kann jedoch recht schwierig sein, da es mehrere Möglichkeiten gibt. Zu den beliebtesten BPEL-Servern, die auf Java EE (dem neuen Namen von Sun für J2EE) basieren, gehören Oracle BPEL Process Manager, die IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration und AquaLogic. Es stehen außerdem mindestens vier Open Source-BPEL-Server zur Verfügung: ActiveBPEL Engine, FiveSight PXE, bexee und Apache Agila.

Beispielprozess

Betrachten wir nun ein Beispiel für einen BPEL-Prozess für Geschäftsreisen, den wir oben beschrieben haben. Wir werden einen asynchronen Prozess entwickeln, der einen synchronen Anruf verwendet, um den Reisestatus des Mitarbeiters zu überprüfen, und zwei asynchrone Anrufe, um die Flugticketpreise zu erhalten. Die folgende Abbildung zeigt die Gesamtstruktur unseres Prozesses. Links sehen wir den Client, der den Prozess aufruft. Der Prozess ruft zuerst den Webdienst für den Reisestatus des Mitarbeiters auf. Anschließend werden die Webdienste beider Fluggesellschaften gleichzeitig und asynchron aufgerufen. Dies bedeutet, dass der Prozess den Rückrufvorgang (und einen Hafentyp) implementieren muss, über den die Fluggesellschaften die Bestätigung des Flugtickets zurücksenden. Schließlich gibt der Prozess dem Kunden das beste Flugticketangebot zurück. In diesem Beispiel wird der Einfachheit halber keine Fehlerbehandlung implementiert.Das ist in realen Szenarien von entscheidender Bedeutung.

Schreiben wir nun den BPEL-Code. Wir beginnen mit der Prozessdeklaration - dem Stammelement, in dem wir den Prozessnamen und die Namespaces definieren:

Als nächstes müssen wir die Partnerlinks definieren. Partnerlinks definieren verschiedene Parteien, die mit dem BPEL-Prozess interagieren. Dies umfasst alle Webdienste, die aufgerufen werden, und den Client des Prozesses. Jeder Partnerlink gibt bis zu zwei Attribute an: myRoledas gibt die Rolle des Geschäftsprozesses selbst an und partnerRoledas gibt die Rolle des Partners an. In unserem Beispiel definieren wir vier Partnerlinks:

Um Nachrichten zu speichern und neu zu formatieren und zu transformieren, benötigen wir Variablen. Normalerweise verwenden wir eine Variable für jede Nachricht, die an die Webdienste gesendet und von diesen empfangen wird. In unserem Beispiel benötigen wir einige Variablen. Für jede Variable müssen wir den Typ angeben. Wir können einen WSDL-Nachrichtentyp, einen einfachen XML-Schema-Typ oder ein XML-Schema-Element verwenden. In unserem Beispiel verwenden wir WSDL-Nachrichtentypen für alle Variablen:

Jetzt sind wir bereit, den Hauptprozesskörper zu schreiben. Es enthält nur eine Aktivität der obersten Ebene. In der Regel können wir auf diese Weise mehrere Aktivitäten definieren, die nacheinander ausgeführt werden. Innerhalb der Sequenz geben wir zunächst die Eingabenachricht an, mit der der Geschäftsprozess gestartet wird. Wir machen das mit dem Konstrukt, das auf die passende Nachricht wartet. In unserem Fall ist dies die TravelRequestNachricht. Innerhalb des Konstrukts geben wir die Nachricht nicht direkt an. Vielmehr geben wir den Partnerlink, den Porttyp, den Operationsnamen und optional die Variable an, die die empfangene Nachricht für nachfolgende Operationen enthält. Wir verknüpfen den Nachrichtenempfang mit dem Client-Partner und warten, bis die TravelApprovalOperation für den Porttyp aufgerufen wird TravelApprovalPT. Wir speichern die empfangene Nachricht in derTravelRequest Variable:

Als Nächstes müssen wir den Webdienst "Employee Travel Status" aufrufen. Vorher müssen wir die Eingabe für diesen Webdienst vorbereiten. Wir können eine solche Nachricht erstellen, indem wir den Mitarbeiterteil der vom Kunden gesendeten Nachricht kopieren. Jetzt können wir den Webdienst "Employee Travel Status" aufrufen. Wir führen einen synchronen Aufruf durch, für den wir die Aktivität verwenden. Wir verwenden den employeeTravelStatusPartnerlink und rufen die EmployeeTravelStatusOperation für den EmployeeTravelStatusPTPorttyp auf. Wir haben die Eingabenachricht in der EmployeeTravelStatusRequestVariablen vorbereitet . Da es sich um einen synchronen Aufruf handelt, wartet der Aufruf auf die Antwort und speichert sie in der EmployeeTravelStatusResponseVariablen:

Der nächste Schritt besteht darin, beide Webdienste der Fluggesellschaft aufzurufen. Wieder bereiten wir zuerst die erforderliche Eingabenachricht vor (die für beide Webdienste gleich ist). Wir werden gleichzeitig asynchrone Aufrufe durchführen. Um die Parallelität auszudrücken, stellt BPEL die Aktivität bereit . Der Aufruf jedes Webdienstes besteht aus zwei Schritten:

  1. Die Aktivität wird für den asynchronen Aufruf verwendet
  2. Die Aktivität wird verwendet, um auf den Rückruf zu warten

Wir verwenden , um beide Aktivitäten zu gruppieren. Die beiden Aufrufe unterscheiden sich nur im Partnerlinknamen. Wir verwenden AmericanAirlinesfür das eine und DeltaAirlinesfür das andere:

...