Servicesuche in ARIS
Tags: aris, ids scheer, paper, service, soa
Kategorie Promotion | Keine Kommentare »
Im November war ich auf der European Conference on Web Services (ECOWS) in Halle und habe dort im Rahmen des Workshops on Emerging Web Services Technology (WEWST) mein Paper über die Servicesuche in ARIS präsentiert. Heute will ich mal noch kurz zusammenfassen, was ich da erzählt habe. Das eigentliche Paper findet man im Bereich Publikationen auf dieser Seite…
Ich erzähle ja immer in diesem Blog, dass man mit Services Geschäftsprozesse automatisieren. Man modelliert dazu ein Geschäftsprozessmodell zum Beispiel mit der EPK Notation und hängt an jeden Teilschritt im Modell einen Service. Wenn alles klappt, kann man dann das Model ausführen. Eine wichtige Frage ist allerdings, wie man den richtigen Service auswählt bzw. findet. Es ist natürlich relativ trivial, wenn man nur wenige Services hat und diese genau kennt. Kennt man aber gar nicht alle Services oder gibt es einfach sehr viele Services, dann wird die Auswahl ziemlich schwierig. Von einem Hersteller eines Modellierungswerkzeugs wie der IDS Scheer erwartet man natürlich, dass das Modellierungswerkzeug Unterstützung bei der Serviceauswahl bietet. Seit der ARIS Version 7.02 gibt es solch eine Unterstützung im Produkt ARIS SOA Architect und bei der Konferenz habe ich dargelegt, wie diese Funktionalität prinzipiell funktioniert.
In der Wissenschaft gibt es viele Ansätze, wie man Services finden kann. Man bezeichnet dies gewöhnlich als Service Discovery, also das Entdecken von Services. Prinzipiell muss man erst mal unterscheiden, wann die Suche stattfinden soll. So kann man zum Beispiel eine Suche schon während der Modellierung anstoßen, es ist aber auch denkbar, erst bei der Ausführung des Prozess einen Service zu suchen und dynamisch zu binden. Für die IDS als Hersteller eines Modellierungswerkzeugs ist natürlich die Servicesuche während der Modellierung wesentlich interessanter. Das Paper handelt über solch eine Suche.
Man kann den Suchprozess in 3 Phasen unterteilen. In Phase 1 (Service Matching oder Matchmaking) werden die vorhandenen Services mit dem Suchkriterium verglichen. Bei Google würde dies also der Eingabe des Suchwortes und die interne Verarbeitung der Suchanfrage sein. In Phase 2 (Service Assessment) werden die Suchergebnisse präsentiert und bewertet. Die Bewertung kann manuell oder ebenfalls automatisiert erfolgen. Bei Google bekommt man die Seiten mit den Suchergebnissen und man stöbert dann in diesen solange, bis man einen brauchbaren Link gefunden hat. In Phase 3 (Service Selection) erfolgt dann die eigentliche Auswahl. Dies würde bei einer Google Suchanfrage also dem Klick auf das Suchergebnis entsprechen.
Bei der Entwicklung der Suchfunktionalität haben wir entschieden Phase 1 zu automatisieren, aber Phase 2 und 3 manuell zu belassen und dem Nutzer lediglich genügend Informationen zu bieten, damit er informiert die Suchergebnisse bewerten und seine Auswahl treffen kann.
Für das Service Matching, also Phase 1, muss man zunächst das Suchkriterium definieren. Da gibt es nun eine Unmenge von Ansätzen, von ganz informell durch Eingabe eines Suchwortes (wie bei Google) bis hin zu sehr formalen Ansätzen wie der Nutzung von Ontologien oder anderen logischen Ausdrücken. Entsprechend gibt es auch sehr unterschiedliche Suchalgorithmen. Abstrahiert man aber mal ein wenig, dann kann man im Prinzip 3 prinzipielle Ansätze für das Service Matching identifizieren, nämlich:
- Lexikalische Ansätze vergleichen ein Suchwort zum Beispiel gegen eine textuelle Beschreibung des Service, gegen seinen Namen, usw. Dabei setzt man manchmal auch Wörterbücher ein, um zum Beispiel Synonyme zu erkennen oder Füllwörter rauszufiltern. Der lexikalische Ansatz ist natürlich jedem bekannt, der schon mal eine Suchmaschine genutzt hat.
- Strukturelle Ansätze vergleichen die Struktur des Service, seine Operationen und verarbeiteten Nachrichten mit der Suchanfrage. Würde zum Beispiel im Prozess ein bestimmter Eingabewert für eine Funktion erwartet, dann sucht man natürlich auch nur nach Services, die diesen Eingabewert auch verarbeiten können.
- Semantische Ansätze vergleichen die semantische Beschreibung des Service gegen die semantische Suchanfrage. Die semantische Definition erfolgt dabei meist mit Ontologien und logischen Ausdrücken.
Während man als Nutzer die lexikalischen Verfahren noch halbwegs durchschauen kann, sind strukturelle und speziell semantische Ansätze nur schwer verständlich. Gerade für die semantischen Ansätze gibt es so ausgefeilte Verfahren, die theoretisch eine sehr effiziente Suche zulassen würden, dummerweise gibt es aber nicht immer Algorithmen oder Programme, die die Anfragen auch wirklich berechnen können.
Bei der Entwicklung der Servicesuchfunktionalität für ARIS stand im Vordergrund, möglichst ein einfach zu bedienendes Verfahren zu entwickeln. Wenn es zum Beispiel sehr schwierig ist eine Suchanfrage richtig zu formulieren, dann wird es kaum jemand nutzen und lieber die Services von Hand auswählen. Deshalb haben wir entschieden, dass der Nutzer überhaupt keine Eingaben machen soll, um die Suchanfrage zu formulieren. Schaut man sich ein übliches Prozessmodell an, sieht man auch schnell, dass dies nicht wirklich notwendig ist, da solch ein Modell bereits sehr vielfältige Informationen enthält, die darauf warten, genutzt zu werden. So werden in einem EPK Prozessmodell zum Beispiel für jede n Prozesschritt angegeben, welche Ein- und Ausgabedaten verarbeitet werden und welche Eigenschaften von einem unterstützenden IT System erwartet werden.
Der Nutzer startet die Suche, indem er lediglich den Prozessschritt markiert, für den ein Service gesucht werden soll. Der Suchalgorithmus nutzt die Informationen im Prozessmodell und führt dann sowohl ein strukturelles Suchverfahren anhand der modellierten Daten als auch ein sehr einfaches (aber deshalb nicht weniger effizientes) semantisches Suchverfahren anhand der erwarteten Systemeigenschaften durch. Beide Suchverfahren werden unabhängig voneinander ausgeführt und liefern jeweils eine Menge von möglichen Services. Aus beiden Ergebnislisten wird eine einheitliche Liste gebildet, die alle Services aus den beiden ursprünglichen Listen enthält (Vereinigungsmenge).
Anschließend werden dem Nutzer die gefundenen Services in einer speziellen Oberfläche angezeigt. Der Nutzer kann die Services dann zum Beispiel noch lexikalisch durchsuchen und zu jedem Service weitere Informationen, wie seine Beschreibung, abrufen. Wenn der Nutzer dann hoffentlich einen passenden Service gefunden hat, wählt er diesen aus und der Service wird dann automatisch an die Funktion im Prozessmodell gehängt.
Vergleicht man dieses Suchverfahren mit anderen wissenschaftlichen Ansätzen fällt auf, dass es natürlich wesentlich primitiver von den Algorithmen her ist, als was sonst in der Wissenschaft so diskutiert wird. Zu Gute muss man meinen Mitautoren und mir aber halten, dass es ein realistischer Ansatz ist, der den Nutzer nicht völlig überfordert. So schrieb dann auch ein Reviewer von dem Paper, dass unsere Lösung ein längst überfälliger Realitätscheck für die Wissenschaftsgemeinde ist, die sich lieber mit theoretischen Ansätzen beschäftigt, als echte Probleme zu lösen. Dem kann ich natürlich nicht mehr viel hinzusetzen…