Semantisches ARIS Teil 3
Tags: epc2bpel, semantic, semanticaris, sisi, super
Kategorie Promotion | Keine Kommentare »
Und weiter gehts in der Serie über die empirische Evaluierung von Semantic BPM… Im ersten Teil gab es den Überblick, was ich damit überhaupt erreichen will. Im zweiten Teil habe ich dann die prototypischen Erweiterungen von ARIS beschrieben, damit semantische Geschäftsprozessmodellierung möglich wird. Hier im dritten Teil soll es darum gehen, wie man semantisch angereicherte Geschäftsprozessmodelle auf einer herkömmlichen BPEL Engine ausführen kann.
Im letzten Teil dieser Serie habe ich eine prototypische Erweiterung von ARIS vorgestellt, mit der man semantische Geschäftsprozesse modellieren kann. In einem semantischen Geschäftsprozessmodel ist jede Funktion mit einer formalen Beschreibung verknüpft. Die Beschreibung, ein so genanntes WSMO Goal, definiert, welche Fähigkeiten jemand besitzen muss, um diese Funktion auszuführen. Im allgemeinen (sich momentan abschwächenden) SOA Wahn ist es natürlich naheliegend, die Funktionen mit Web Services zu automatisieren. Es müsste also für jede formale Beschreibung ein passender Web Service gefunden werden. Damit dies alles irgendwie geht, müsste man den Geschäftsprozess zunächst in eine ausführbare Beschreibung wie BPEL transformieren. Allerdings können heutige BPEL Prozessdrehscheiben :-) mit den semantischen Beschreibungen relativ wenig anfangen. Es gibt inzwischen zwar erste Prototypen von solchen erweiterten BPEL Engines, aber das ist natürlich keine Lösung für eine reale Umgebung. Da das Ziel ja die empirische Evaluierung von semantischen BPM in einer möglichst realistischen Umgebung ist, sollte man natürlich so viele reale Komponenten verwenden, wie irgendwie möglich.
Deshalb haben wir uns eine Lösung überlegt, wie man auf einer heutigen unmodifizierten BPEL Engine trotzdem die Vorteile von semantischen Web Services nutzen kann. Dazu mussten wir zunächst eine Möglichkeit finden, wie man semantische Beschreibungen (d.h. WSMO Goals) in einem BPEL Dokument unterbringt, ohne den Standard zu verletzen. Christian hat die existierende EPK nach BPEL Transformation von ARIS so erweitert, dass der Inhalt eines WSMO Goals als Message Part gespeichert wird. Jedesmal wenn ein semantischer Web Service gefunden werden soll, wird ein spezieller Proxy Service aufgerufen. Dieser „Semantic Invocation Service“ (SISi) erhält eine Message, die aus 2 Message Parts besteht:
- Eingabedaten, die vom gefundenen Web Service verarbeitet werden sollen
- WSMO Goal, das den Web Service beschreibt, der genutzt werden soll
SISi verarbeitet diese Information wie in der folgenden Grafik illustriert (musst du klicken für groß):
In Schritt 1 erhält SISi von der BPEL Engine die oben beschriebene Eingabenachricht. SISi leitet die semantische Beschreibung (d.h. das WSMO Goal) an eine semantische Komponente weiter, um einen passenden semantischen Web Service zu finden. Diese semantische Komponente gibt dann den Endpunkt dieses gefundenen Web Service zurück an SISi. SISi ruft anschließend in Schritt 4 den gefundenen Web Service auf. Dabei übergibt SISi an diesen Web Service die ursprünglich von der BPEL Engine erhaltenen Daten. Nachdem der Web Service ausgeführt wurde, gibt er in Schritt 5 sein Ergebnis zurück an SISi, welches SISi im finalen Schritt 6 an die BPEL Engine zurück gibt.
Der „Semantic Invocation Service“ (SISi) steht als OpenSource Implementierung auf Google Code jedem zur Verfügung. SISi wurde so gestaltet, dass er (oder müsste man SIE sagen???) möglichst unabhängig von der genutzten semantischen Komponente ist. So können andere semantische Umgebungen über einen Plugin Mechanismus unterstützt werden. In der momentanen Implementierung gibt es lediglich eine Unterstützung für WSMX. Da WSMX nicht nur das Suchen von semantischen Web Services unterstützt (Schritt 2 + 3), sondern diese auch aufrufen kann (Schritt 4 + 5), verschmelzen die Schritte 2-5 bei der Nutzung von WSMX zu einem einzigen Schritt.
In der Fallstudie nutzen wir für die BPEL Ausführung den Oracle BPEL Process Manager, der Teil der Oracle SOA Suite ist. SISi selbst ist ein Java Servlet, dessen Web Service Schnittstelle mit AXIS2 implementiert wurde. SISi läuft in der Fallstudie nicht auf Oracle, sondern auf einem Apache Tomcat. WSMX bringt seinen eigenen Server mit.
Im abschließenden Teil dieser Serie werde ich dann die Ergebnisse der Fallstudie vorstellen und kurz erläutern, wie wir die Studie durchgeführt haben.