(WS09-04) Monitoring von Workflows in einer BPEL-Engine

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen

Aufgabe

Die Projektbeschreibung ist hier in Form einer PDF-Datei zu finden.

Grundlagen

Zum allgemeinen Verständnis der BPEL-Grundlagen möchte ich auf die von mir im Rahmen eines Fachseminars erstellte Arbeit [1] verweisen. Die Studienarbeit [2] basiert zwar auf der älteren BPEL4WS-Spezifikation, gibt aber trotzdem einen guten Überblick über die in BPEL vorhandenen Modellierungsmöglichkeiten zur Realisierung von Geschäftsprozessszenarien. Erweiterte Grundlagen zum Monitoren und Managen von BPEL-Prozessen mit Hilfe eines einheitlich festgelegten BPEL-Eventmodells sind in [3] und [4] zu finden.

Eigenschaften von BPEL 2.0

Mit BPEL 2.0 können über Web Services angebotene Dienste im Rahmen eines Geschäftsprozesses orchestriert werden. BPEL ist eine XML-basierte Sprache zur Beschreibung fachlicher Abläufe aus der technischen Sicht eines zentralen Steuerungsprozesses. Für die Modellierung von automatisierten Geschäftsprozessen benutzt BPEL standardisierte und semantisch festgelegte Sprachelemente. Dazu kapselt BPEL einen Geschäftsprozess beliebiger Komplexität innerhalb eines XML-Dokumentes (BPEL-Dokument). Die Sprachelemente, die innerhalb eines BPEL-Prozesses verwendet werden dürfen, sind über ein festgelegtes XML-Schema definiert. BPEL nutzt für die Interaktion mit verteilten Diensten die im Rahmen von Web Services bekannte WSDL-Spezifikation in der Version 1.1. BPEL ist dabei eng mit der WSDL-Spezifikation verwoben, so kann jeder in BPEL erstellte Geschäftsprozess selbst wieder über einen in WSDL beschriebenen Web Service zugänglich gemacht und in weiteren Geschäftsprozessen verwendet werden. BPEL ist zudem in der Lage die innerhalb eines Geschäftsprozesses ausgetauschten Service-Informationen zu verarbeiten. Aus diesem Grund kann BPEL auch als imperative Programmiersprache verstanden werden, in der es Variablen, Funktionen, Kontrollstrukturen sowie Mechanismen zur Fehlerbehandlung gibt. [1]

Monitoring und Management von BPEL-Prozessen

Ein BPEL-Prozess beinhaltet verschiedene Ausführungsknoten (Aktivitäten), die über unterschiedliche Pfade entsprechend der hinterlegten Geschäftslogik verarbeitet werden können. Die aktive Überwachung (Monitoring) von BPEL-Prozessen gibt Aufschluss über den aktuellen Zustand des Prozesses. Die Überwachung kann seitens des Managements genutzt werden, um mögliche Fehlerquellen zu finden und um den Prozess selbst zu optimieren. Folgende Management-Funktionen könnten beispielsweise über ein Monitoring realisiert werden:

  • Zeitmessung: Die Zeitmessung eines BPEL-Prozesses erlaubt es, mehrere Rückschlüsse über den Prozessverlauf zu ziehen. Dabei gibt die durchschnittliche Gesamtzeit eines Prozesses z.B. Hinweise darauf, ob in einen Prozess eingegriffen werden sollte oder nicht. Des Weiteren kann eine Zeitmessung zwischen mehreren einzelnen Aktionen eines Prozesses darüber Aufschluss geben, wo potentielle Engpässe bzw. Flaschenhälse innerhalb des Prozesses liegen.
  • Prozesspfad: Die Verfolgung des Prozesspfades, also der Weg auf dem die einzelnen Aktionen abgearbeitet werden, ist aus Sicht des Managements ebenfalls hilfreich. Die Verfolgung des Pfades kann Aufschluss darüber geben, welche Verzweigung durchschnittlich gewählt wurde und welche Ressourcen entsprechend einer Pfadwahl im Vorfeld bereitgestellt werden müssen.

Des Weiteren bietet Monitoring die Grundlage, um Prozesss aktiv zu steuern. Es ist beispielsweise möglich, dass ein Prozess innerhalb einer Aktivität solange verharrt, bis die zur Ausführung benötigte Nachricht eintrifft. Ein Problem besteht darin, dass die zu erwartende Nachricht durch einen beliebigen Fehler verloren gehen kann. Der BPEL-Prozess ist dann nicht in der Lage zu erkennen, ob die verlorengegangene Nachricht noch eintrifft oder nicht. Seitens eines Managements wäre es darum von Vorteil, wenn auf die Zustandsinformationen des laufenden BPEL-Prozesses zugegriffen und diese zur Laufzeit verändert werden könnten.

Problemanalyse

Ziel dieses Projektes ist es, die interne Prozessausführung einer BPEL-Umgebung (Engine) zu überwachen. Diese Überwachung soll dabei sowohl für die Engine als auch für die Prozesse auf Grundlage eines generellen Event-Modells [4] erfolgen. Dieses Event-Modell wurde aus der BPEL-Spezifikation abgeleitet und definiert die jeweiligen Ereigniszustände, die in Form von Ereignisnachrichten (Events) außerhalb der BPEL-Umgebung abgefangen werden können. Der Vorteil des Event-Modells ist das der Prozess nicht verändert werden muss, um an interne Zustandsinformationen zu kommen. Um die Prozessausführung anhand des Event-Modells zu demonstrieren, müssen zuvor verschiedene BPEL-Umgebungen auf entsprechende Event-Schnittstellen untersucht werden.

Untersuchung von BPEL-Umgebungen auf Monitoring-Schnittstellen

Um Workflows bezüglich ihrer Ausführung analysieren zu können, muss vorab die Auswahl einer geeigneten BPEL-Umgebung erfolgen. Dazu werden die zwei in [4] erwähnten Umgebungen "Apache - ODE" und "Active Endpoints - ActiveBPEL/VOS", sowie "JBoss - jBPM" und "Sun - OpenESB - BPELSE" auf mögliche Monitoring-Schnittstellen untersucht.

Im Folgenden ist der zum Projektbeginn bekannte Versionsstand der zu untersuchenden BPEL-Umgebungen vermerkt.

BPEL-Engine Version Link
Apache ODE 1.3.2 http://ode.apache.org
ActiveEnpoints - ActiveBPEL 5.0.2 http://sourceforge.net/projects/activebpel502/
ActiveEnpoints - ActiveVOS 7.0 http://activevos.com
JBoss jBPM BPEL 1.1.1 http://jboss.org/jbossjbpm/bpel
Sun OpenESB BPELSE 2.1 http://open-esb.dev.java.net

Apache - ODE

ApacheODE verfügt über ein Event-Framework, dass auf der Basis von registrierten Listenern arbeitet. Eine Liste möglicher Ereignisse für die eine Registrierung erfolgen kann ist der unten aufgeführten Dokumentation zu entnehmen. Das Event-Framework ist in der Lage alle auftretenden Ereignisse bezüglich eines Prozesses in einer Datenbank zu speichern. ApacheODE verfügt zudem über eine Management-API, die genutzt werden kann, um auf die in der Datenbank abgelegten Ereignisse zuzugreifen. Die Management-API bietet zudem die Möglichkeit auf BPEL-Prozesse und Instanzen der aktuellen Laufzeitumgebung zuzugreifen. Dazu werden zwei Interfaces "Process Definition Manager" und "Process Instance Manager" bereitgestellt, die auch über einen Web Service angesprochen werden können. Weitere Informationen zum Event-Framework sind im User-Guide hier zu finden. Informationen bezüglich Management-API sind in einer gesonderten Dokumentation hier zu finden.

Active Endpoints - ActiveBPEL/ActiveVOS

ActiveBPEL/VOS verfügt über ein mächtiges Event-Framework, dass ebenfalls auf der Basis von registrierten Listenern arbeitet. Mit diesem Framework ist es möglich, sich an allen bekannten BPEL-Ereignissen zu registrieren, um so den genauen Zustand des Prozesses zu erfahren. Dieses Event-Framework bietet neben normalen Listenern auch die Möglichkeit sogenannte "Breakpoint-Listener" (Haltepunkte) innerhalb einer Prozessinstanz zu registrieren. Durch diese Haltepunkte ist es möglich, registrierte Aktivitäten vor ihrer Ausführung zu stoppen. Der Prozess wird dadurch ebenfalls gestoppt. Die weitere Ausführung des Prozesses erfolgt durch explizite Freigabe seitens eines Prozessmonitors. Mit dem Administration SDK (ActiveVOS) ist es möglich, die Zustände und Eigenschaften der instanzierten Prozesse zu verändern und so aktiv in das Prozessgeschehen einzugreifen. ActiveBPEL und ActiveVOS nutzen für die Registrierung spezielle Interfaces, die auch über Web Services genutzt werden können. In ActiveVOS wurde zusätzlich noch ESPER integriert, ein Framework zur Verarbeitung von komplexen Ereignissen, auch Complex Event Processing (CEP) genannt. ESPER kann genutzt werden, um BPEL-Prozesse zur Laufzeit anhand auftretender Events zu analysieren. Eine Dokumentation zu ESPER ist hier zu finden.

Hinweis:

Die Entwicklung der Open Source Engine "ActiveBPEL" ist durch Active Endpoints eingestellt worden und wird seitens des Herstellers nicht mehr unterstützt. Die letzte freie Version von ActiveBPEL kann in der Version 5.0.2, bei SourceForge.net hier heruntergeladen werden. Auf der aktuellen Homepage von Active Endpoints wird ActiveBPEL nur in der Version 2.1.1 angeboten. Eine gut strukturierte Online-Dokumentation zu dem derzeit aktuellen Produkt ActiveVOS kann bei dem Hersteller Active Endpoints hier bezogen werden.

JBoss - jBPM - BPEL

Die BPEL-Umgebung, die im Rahmen von JBoss jBPM angeboten wird, ist für ein BPEL-Monitoring ungeeignet. Dies liegt daran, dass es sich hierbei um keine reine BPEL-Umgebung handelt. Die in jBPM vorgestellte BPEL-Umgebung basiert auf einem Mapping zwischen der BPEL-Spezifikation und der von JBoss entwickelten, graphen-basierten Workflow-Sprache jPDL. Die jPDL wird zur Ausführung auf der Process Virtual Machine (PVM) benötigt, welche ebenfalls von JBoss entwickelt wurde. Die dort verwendete BPEL-Umgebung verfügt über keine eigenen Event- oder Monitoring-Schnittstellen. Ein Eventhandling oder Monitoring auf jPDL-Ebene ist für dieses Projekt nicht geeignet. Informationen zu JBoss jBPM können von hier bezogen werden. Weiter Informationen zu dem dort verwendeten BPEL-Mapping ist hier zu finden.

Sun - OpenESB - BPELSE

Der OpenESB von Sun beinhaltet die BPEL-Service-Engine "BPELSE" als eigene Komponente. BPELSE verfügt auch über ein einfaches Event-Framework, welches jedoch unzureichend dokumentiert erscheint. Aus diesem Grund können keine weiteren Aussagen hierzu getroffen werden. Für das BPELSE wird eine Monitor-API angeboten, die es erlaubt, Informationen bezüglich der aktuellen Prozessinstanzen zu erhalten. Die Monitor-API erlaubt es einen aktiven Prozess in den Suspend-Modus zu versetzen, um so Änderungen an den Zustandsinformationen durchzuführen. Nach Abschluss der Zustandsänderungen kann der Prozess wieder aktiviert und weiter ausgeführt werden. An dieser Stelle bleibt die Frage festzuhalten, mit welchen Mitteln man den optimalen Zeitpunkt für einen Suspend erkennt. Information bezüglich der BPELSE können hier bezogen werden. Die Monitor-API und deren Dokumentation kann hier bezogen werden.

Auswahl und Einarbeitung in geeigneten BPEL-Umgebung

Bei der Auswahl der BPEL-Umgebung fiel die Entscheidung aus folgenden Gründen auf ActiveBPEL/VOS:

  • ActiveBPEL/VOS unterstützen im Gegensatz zu allen anderen BPEL-Umgebungen das in [4] beschriebene Event-Modell fast vollständig.
  • Die von ActiveBPEL/VOS angebotene Managment-API bietet den größten Funktionsumfang.
  • Das CEP-Framework ESPER erlaubt die direkte Verarbeitung von Ereignissen zur Laufzeit.

Im Rahmen dieses Projektes fiel die Entscheidung auf die kommerzielle Version ActiveVOS 7.0. Diese hat im Gegensatz zur reinen ActiveBPEL-Engine den Vorteil, dass man schon eine komplett aufeinander abgestimmte Umgebung mit vielen Extras bekommt, die die Arbeit mit BPEL extrem vereinfacht. Ein direkter Vergleich zwischen ActiveBPEL und ActiveVOS ist hier zu finden.

Wie bereits erwähnt, handelt es sich bei ActiveVOS um ein kommerzielles Produkt. Dieses kann seitens des Herstellers bezogen werden. Der Hersteller bietet die Möglichkeit, nach einer Registrierung einen Test-Lizenzschlüssel für 30-Tage zu erhalten. Da die Dauer des Projektes diese 30 Tage überschreitet, hat der Hersteller eine dreimalige Zuteilung von Test-Schlüsseln gestattet, womit die Testversion 90 Tage genutzt werden kann.

BPEL-Engines Event-Modell.png

Untersuchung der BPEL-Engines auf Unterstützung des BPEL-Event-Modells

Administration-SDK

Das Administration SDK bietet verschiedene Funktionen zur Steuerung und Überwachung von BPEL-Prozessen. Das Administration-SDK ist über ein Web Service zugänglich. Innerhalb des Web Services werden Funktionen zur Registrierung von verschiedenen Listener-Typen angegeben, diese können jedoch nicht direkt über den Web Service genutzt werden. Wie man diese API auf Engine-Ebene nutzt ist leider nicht dokumentiert.

Im Folgenden ist der Funktionsumfang des Administration SDK beschrieben, die in ROT eingefärbten Funktionen stehen, wie bereits erwähnt, nicht direkt über den Web Service zur Verfügung.

Operation Beschreibung
AddAttachment Adds an attachment to the variable specified by the given variable path in the given process with the given data.
AddBreakpointListener Add a listener for engine breakpoint notification events.
AddEngineListener Add a listener for engine notification events.
AddProcessListener Add a listener to those notified of process events for the given process ID.
CompleteActivity Step resume the process and mark the activity associated with passed location path as complete.
DeployBPR Deploys a BPR file.
GetAPIVersion Returns the API version for the BPEL administration service.
GetConfiguration Gets the current engine configuration as xml.
GetProcessCount Returns a count of processes currently running on the BPEL engine.
GetProcessDef Returns the process definition (BPEL xml) for the given process.
GetProcessDetail Returns the process detail for the given process id or null if the process does not exist on the server.
GetProcessDigest Returns the message digest code of the deployed BPEL file for the given process.
GetProcessList Returns a list of processes currently running on the BPEL engine.
GetProcessLog Returns the process log for the given process, if logging is enabled on the server.
GetProcessState Returns the state of the process specified by the given process ID.
GetServerLogList Returns the list of logs.
GetVariable Returns the data for the variable being referenced by the variable path.
IsInternalWorkManager Returns True if using the native ActiveBPEL WorkManager and False if using a server provided WorkManager.
RemoveAttachments Removes one or more attachments for the variable specified by the given variable path in the given process.
RemoveBreakpointListener Remove a listener for engine breakpoint notification events.
RemoveEngineListener Remove the given listener from receiving engine notification events.
RemoveProcessListener Removes the passed listener from list of those notified of process events for the given process ID.
RestartProcess Restarts the business process identified by the passed pid.
ResumeProcess Resumes the business process identified by the passed pid.
ResumeProcessContainer Resumes the business process identified by the passed pid for the passed suspended location container.
ResumeProcessObject Resumes the business process identified by the passed pid for the passed suspended location.
RetryActivity Retry the activity associated with the passed location path or its enclosing scope.
SetConfiguration Sets properties for the engine config.
SetCorrelationSetData Sets the correlation set data for the given process id and location path.
SetPartnerLinkData Sets the partner link data for the given process id and location path.
SetVariable Sets the variable specified by the given variable path in the given process with the given data.
SuspendProcess Suspends the business process identified by the passed pid.
TerminateProcess Terminates the business process identified by the passed pid.
UpdateBreakpointList Update the list of breakpoints defined by the user for remote debug.

ESPER

ESPER ist ein Framework zur komplexen Ereignisverarbeitung - Complex Event Processing (CEP). Das Framework erlaubt die Erkennung, Analyse, Gruppierung und Verarbeitung von Ereignissen die innerhalb der Ausführungszeit auftreten. Um einen definierten Zustand anhand von unterschiedlichen Ereignissen beschreiben zu können, aggregiert ESPER die in verschiedenen Datenströmen (Real-Time-Data-Streams) enthaltenen Ereignisdaten. Für die Datenerfassung können entsprechende Zeitfenster (Sliding Windows) definiert werden, die die Datenerfassung reduzieren und einen zu überwachenden Zustand konkretisieren.

ESPER - Complex Event Processing (CEP)

ESPER - Complex Event Processing (CEP)

Die Architektur von ESPER erlaubt bei der Definition der Zeitfenster auch Daten von vergangenen Ereignissen (Historical Data) miteinzubeziehen. Dadurch ist es möglich, komplexe Abfragen über die in dem definierten Zeitfenster aufgetretenen Ereignisse durchzuführen. Um Ereignismengen auszuwählen oder zu aggregieren wird innerhalb von ESPER eine SQL ähnliche Query Language benutzt. Innerhalb des Frameworks können definierte Ereigniszustände mit Funktionen in Form von POJOs verknüpft werden, die dann bei Eintreten des entsprechenden Ereigniszustands ausgeführt werden. Damit ist es möglich, gezielt auf die jeweiligen Ereigniszustände zu reagieren.

ESPER - Architektur

ESPER - Architektur


Modellierung eines BPEL-Prozesses

Um die Anforderungen zu demonstrieren, wird ein einfaches Beispiel-Szenario erstellt. Im Folgenden wird dieses kurz erläutert:

Ein Aufrufer (Consumer) hat die Möglichkeit, dem BPEL-Prozess eine Zahl (Int32) zu übermitteln. Diese Zahl wird anhand ihrer Eigenschaft (gerade/ungerade) überprüft und an den Anrufer zurückübertragen. Innerhalb des Prozesses befinden sich vor und nach der Eingabeprüfung noch Wait-Aktivitäten, die weitere Aktionen simulieren sollen. Der Prozess wird pro Wait-Aktivität um 3 Sekunden verzögert, was eine Gesamtverzögerung von 6 Sekunden bedeutet.

Visuelle Notation

Modellierter Prozess in BPEL-Designer-Notation

Modellierter Prozess in BPEL-Designer-Notation

Modellierter Prozess in BPMN-Notation

Modellierter Prozess in BPMN-Notation

BPEL-Prozessbeschreibung

<?xml version="1.0" encoding="UTF-8"?>
<bpel:process 
xmlns:aei="http://www.activebpel.org/2009/02/bpel/extension/ignorable"
xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:ext="http://www.activebpel.org/2006/09/bpel/extension/query_handling"
xmlns:ext1="http://www.activebpel.org/2009/06/bpel/extension/links"
xmlns:ns="http://www.example.org/SimpleProcess/public"
xmlns:ns1="http://www.example.org"
xmlns:types1="http://www.example.org/SimpleSchema"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/SimpleProcess"
ext1:linksAreTransitions="yes" ext:createTargetXPath="yes" ext:disableSelectionFailure="yes" name="SimpleProcess" suppressJoinFailure="yes">

   <bpel:extensions>
      <bpel:extension mustUnderstand="yes" namespace="http://www.activebpel.org/2006/09/bpel/extension/query_handling"/>
      <bpel:extension mustUnderstand="yes" namespace="http://www.activebpel.org/2009/06/bpel/extension/links"/>
      <bpel:extension mustUnderstand="no" namespace="http://www.activebpel.org/2009/02/bpel/extension/ignorable"/>
   </bpel:extensions>

   <bpel:import importType="http://schemas.xmlsoap.org/wsdl/" location="../wsdl/SimpleOperation.wsdl" namespace="http://www.example.org"/>
   <bpel:import aei:implicit="true" importType="http://schemas.xmlsoap.org/wsdl/" location="../wsdl/bpel/SimpleProcess.public.wsdl" namespace="http://www.example.org/SimpleProcess/public"/>
   <bpel:import importType="http://www.w3.org/2001/XMLSchema" location="../schema/SimpleSchema.xsd" namespace="http://www.example.org/SimpleSchema"/>

   <bpel:partnerLinks>
      <bpel:partnerLink aei:interface="ns1:SimplePort" myRole="Provider" name="Simple_Consumer" partnerLinkType="ns:SimplePortPLT"/>
   </bpel:partnerLinks>

   <bpel:variables>
      <bpel:variable element="types1:Data" name="Data"/>
   </bpel:variables>

   <bpel:sequence>
      <bpel:receive createInstance="yes" name="SimpleOperation-Request" operation="SimpleOperation" partnerLink="Simple_Consumer" variable="Data"/>
      <bpel:wait name="Simulate_work_for_3_sec">
         <bpel:for>'PT3S'</bpel:for>
      </bpel:wait>
      <bpel:if>
         <bpel:condition>$Data mod 2 = 0</bpel:condition>
         <bpel:sequence>
            <bpel:wait name="Simulate_work_for_3_sec">
               <bpel:for>'PT3S'</bpel:for>
            </bpel:wait>
            <bpel:reply name="SimpleOperation-Reply" operation="SimpleOperation" partnerLink="Simple_Consumer" variable="Data"/>
         </bpel:sequence>
         <bpel:else>
            <bpel:sequence>
               <bpel:wait name="Simulate_work_for_3_sec">
                  <bpel:for>'PT3S'</bpel:for>
               </bpel:wait>
               <bpel:reply name="SimpleOperation-Reply" operation="SimpleOperation" partnerLink="Simple_Consumer" variable="Data"/>
            </bpel:sequence>
         </bpel:else>
      </bpel:if>
   </bpel:sequence>

</bpel:process>

Strukturierte Knotenmenge

Aus dem erstellten BPEL-Prozess lässt sich mit Hilfe von XPath eine strukturierte Knotenmenge bestimmen. Für das Beispiel-Szenario ergibt sich eine Menge von 10 Knoten die im Folgenden strukturiert dargestellt werden.

Node_0:	"/process/sequence"
Node_1:	"/process/sequence/receive[@name='SimpleOperation-Request']"
Node_2:	"/process/sequence/wait[@name='Simulate_work_for_3_sec']"
Node_3:	"/process/sequence/if"
Node_4:	"/process/sequence/if/if-condition/sequence"
Node_5:	"/process/sequence/if/if-condition/sequence/wait[@name='Simulate_work_for_3_sec']"
Node_6:	"/process/sequence/if/if-condition/sequence/reply[@name='SimpleOperation-Reply']"
Node_7:	"/process/sequence/if/else/sequence"
Node_8:	"/process/sequence/if/else/sequence/wait[@name='Simulate_work_for_3_sec']"
Node_9: "/process/sequence/if/else/sequence/reply[@name='SimpleOperation-Reply']"

Logging-Daten

Innerhalb von ActiveVOS gibt es die Möglichkeit, das Logging für einen Prozess zu aktivieren. Dabei wird zwischen vier Log-Levels unterschieden (NONE, EXECUTION, EXECUTION WITH DATA und FULL). Das Logging gibt Aufschluss über die Events, die bei einer Prozessausführung auftreten. Mit Hilfe der Logging-Informationen kann man festgelegte Anforderungen wie Prozesslaufzeit oder Prozesspfadlauf auswerten. Die Daten könnten beispielsweise mit BIRT (Business Intelligence and Reporting Tools) ausgewertet werden, nähere Informationen zu BIRT sind hier zu finden.

Activevos process log.png
Logging-Daten des BPEL-Prozesses in ActiveVOS 7.0

Monitoring der Event-Informationen

Damit es möglich ist abgesetzte Events zu verarbeiten, muss der BPEL-Engine mittgeteilt werden welche Events überhaupt gesendet werden sollen und welche nicht. Dazu müssen die zu überwachenden Aktivitäten mit möglichen Events verbunden bzw. registriert werden. Die BPEL-Engine liefert generell immer sogenannte Engine-Events, die jedoch nicht registriert werden müssen. Eine Liste mit solchen Events ist hier zu finden.

Die möglichen Ereignisse, die innerhalb eines Prozesses registriert werden können, sind im Folgenden beschrieben:

Event State Beschreibung
READY_TO_ EXECUTE The activity is now ready to execute
EXECUTING The activity has begun executing
EXECUTE_COMPLETE The activity has completed normally
EXECUTE_FAULT The activity has faulted
LINK_STATUS A link has been evaluated
DEAD_PATH_STATUS The activity has gone dead path (will not execute)
TERMINATED The activity was terminated due to an Exit activity executing or an ancestor container faulting
SUSPENDED The activity has been suspended
FAULTING The activity is faulting
INACTIVE The activity is inactive


In ActiveVOS können die Event-Listener direkt innerhalb des Runtime-Debuggings und der Prozesssimulation an den jeweiligen Aktionen registriert werden. Um Events innerhalb des Live-Betriebs verarbeiten zu können, müssen diese vorab über das jeweilige Deployment-Skript (*.bprd) registriert werden. Weiterhin muss das Event-Processing innerhalb der Active VOS Console aktiviert bzw. unter Umständen zurückgesetzt werden.

   <pdd:eventing>

      <pdd:event locationPath="/process/sequence" name="NODE_0_EVENTS">
         <pdd:processStates>
            <pdd:state>INACTIVE</pdd:state>
            <pdd:state>READY_TO_EXECUTE</pdd:state>
            <pdd:state>EXECUTING</pdd:state>
            <pdd:state>EXECUTE_COMPLETE</pdd:state>
            <pdd:state>EXECUTE_FAULT</pdd:state>
            <pdd:state>LINK_STATUS</pdd:state>
            <pdd:state>DEAD_PATH_STATUS</pdd:state>
            <pdd:state>TERMINATED</pdd:state>
            <pdd:state>SUSPENDED</pdd:state>
            <pdd:state>FAULTING</pdd:state>
         </pdd:processStates>
      </pdd:event>

   <pdd:eventing>

ActivVOS 7.0 - Eventing Service
ActivVOS 7.0 - Eventing Service

Implementierung

Das bereits erwähnte Beispielszenario wird nun um vier verschiedene Events erweitert. Der START- und STOP-Event hat die Funktion zu messen wann ein Prozess gestartet bzw. beendet wird. Dazu werden diese Events jeweils an dem Knoten (Node_0) registriert. Für die Verfolgung des Ausführungspfades werden noch die zwei zusätzlichen Events (even and odd) an den Knoten 4 (Node_4) und 7 (Node_7) registriert. Innerhalb des Beispiel-Scenarios werden nur die beiden Events EXECUTING und EXECUTING_COMPLETE verwendet.

BPEL-Event Beispiel-Szenario.png
Beispiel-Szenario für das BPEL-Event-Monitoring

Die Implementierung des Beispiel-Szenarios besteht aus folgenden drei Komponenten:

  • Client: Der Client hat die Aufgabe in entsprechenden Intervallen Integer Zahlen an die vom Geschäftsprozess angebotene Web-Service-Schnittstelle (Einstiegspunkt) zu senden. Nach der Verarbeitung durch den BPEL Prozess erhält der Client als Antwort auf seine Anfrage die gesendete Integer Zahl zurück.
  • BPEL-Engine: Die BPEL-Engine führt den beispielhaften Geschäftsprozess aus, der mit den oben genannten Events versehen wurde. Dabei werden die auftretenden Events durch das Event-Framework zum Einen in der Datenbank in Form des Loggings gespeichert, zum Anderen in die Event-Queue von dem CEP-Framework ESPER übergeben, welche im Hauptspeicher realisiert ist. Des Weiteren sind in der BPEL-Engine sogenannte Action-Prozesse hinterlegt, die mit entsprechenden Event-Patterns aus ESPER verknüpft sind und bei einem Pattern-Match aufgerufen werden. Diese Action-Prozesse teilen dem Monitor entsprechende Zustandsinformationen mit.
  • Monitor: Der Monitor stellt über Web Services verschiedene Methoden bereit, über die die BPEL-Engine ihren jeweiligen Zustand übermitteln kann.

BPEL-Event-Monitoring Implementierung.png
Architektur der zu Entwickelnden BPEL-Event-Monitoring-Application

Performance Analyse

Im Folgenden wird eine Performance-Analyse beschrieben, die den Zusammenhang zwischen der Nutzung von Events und Patterns beschreibt. Dabei wurde die durchschnittliche Antwortzeit am Client für unterschiedliche Konfigurationen gemessen. In den ersten Konfigurationen (E:* P:0) der Analyse ist ein fast lineares Verhalten bei zunehmenden Events zu erkennen. In dem Abschnitt (E:4, P:1) in dem zum erstenmal ein Pattern-Match erfolgt, kann man deutlich die Verzögerung durch die auszuführende Aktion im Vergleich zur Konfiguration (E:4, P:0) erkennen. Bei den Konfigurationen (E:*, P:1) ist zu erkennen, dass mit steigenden Events die Ausführungszeit ebenfalls enorm steigt, dies ist dadurch zu begründen, dass jeder Event auf einen Match geprüft werden muss. So haben die Konfigurationen (E:100, P:1) und (E:4, P:4) eine fast gleiche Ausführungszeit.

Durchschnittliche Antwortzeit.png
Durchschnittliche Antwortzeit am Client (ms)

Fazit

Das in [4] vorgestellte Event-Modell deckt alle möglichen Zustände der aktuellen BPEL-Spezifikation ab. Schon bei der Untersuchung der verschiedenen BPEL-Engines zeigte sich, dass es Unterschiede bei den jeweiligen Event-Frameworks sowie bei der Unterstützung des BPEL-Event-Modells gibt. Da die zwei BPEL-Engines JBoss - jBPM und Sun - OpenESB - BPELSE in den getesteten Versionen derzeit das BPEL-Event-Modells nicht unterstützen, wird eine Verwendung zum jetzigen Zeitpunkt im Rahmen des Projektes nicht empfohlen. Die beiden anderen BPEL-Engines, Apache - ODE und ActiveEndpoints - ActiveBPEL/VOS unterstützen das Event-Modell nicht komplett, nur ActiveBPEL unterstützt es fast vollständig.

Bei der Benutzung von ActiveVOS zeigte sich, dass es nur innerhalb des Debugging bzw. Simulationsmodus möglich war über die Management-API, die als Web Service zur Verfügung steht, Event-Listener zu registrieren. Dies ist jedoch aus Gründen der Performance nicht für einen Live-Betrieb geeignet. Für die Verarbeitung von Events in ActiveVOS eignet sich das integrierte CEP-Framework ESPER, da damit besonders komplexe Event-Verarbeitungen zeitnah umgesetzt werden können.

Im Rahmen der Beispielimplementierung wurde ESPER eingesetzt, um aktives Monitoring zu betreiben. Dabei hat sich gezeigt, dass die Integration von ESPER in ActiveVOS besonders gut umgesetzt wurde und die gewünschten Ziele damit erreicht werden konnten, wobei jedoch längst nicht das komplette Funktionsspektrum von ESPER ausgeschöpft wurde. Zusammenfassend kann festgehalten werden, dass der Einsatz von CEP ideal für das aktive Monitoring (BAM) geeignet ist und auch in Zukunft noch eine bedeutende Rolle in diesem Bereich spielen wird.

Download

Hier sind neben den in ActiveVOS entwickelten BPEL-Prozessen auch die Quellcodes für den Client und Monitor zufinden, eben so alle im Rahmen einer Performance-Analyse durchgeführten Messergebnisse.

Projektvortrag: Download
+ Abschlusspräsentation PDF
Projektdaten: Download
+ BPEL Orchestration Project Project: ActiveVOS 7
+ Client Anwendung Project: Java
+ Monitor Anwendung Project: Java
+ Messung durchschnittliche Antwortzeit Excel
+ Messung unterschiedliche Log-Level Excel


Hinweis: Der Zugriff auf die Projektdaten ist nur über einen internen Hochschul-Account möglich.

Literatur

  1. 1,0 1,1 Stefan Berntheisel: Geschäftsprozessmodellierung mit BPEL, Hochschule Rheinmain, Dezember 2009
  2. Volker Kramberg: Pattern-based Evaluation of IBM WebSphere BPEL, Universität Stuttgart, November 2006
  3. Karastoyanova, Khalaf, Schroth, Paluszek, Leymann: BPEL Event Model, Universität Stuttgart, November 2006
  4. 4,0 4,1 4,2 4,3 4,4 Thomas Steinmetz: Ein Event-Modell für WS-BPEL 2.0 und dessen Realisierung in Apache ODE, Universität Stuttgart, Februar 2008