Diese Dissertation beschäftigt sich mit der Verbesserung der Modularizierung von Workflow-Spezifikationen, im Besonderen mit der Formulierung querschneidender Belange (engl. crosscutting concerns) und Workflow-Änderungen in heutigen Workflow-Sprachen und Workflow-Systemen. Zu diesem Zweck werden zwei Workflow-Sprachen betrachtet: eine einfache Graph-basierte Sprache und die BPEL-Sprache für Web Service Komposition. In einem Szenario, das typische Abläufe bei einem Reiseveranstalter nachbildet, wurden mehrere querschneidende Belange mit Hilfe der beiden Beispielsprachen implementiert, wie z. B. Datensammlung für Abrechnung, Messung der Ausführungszeit der Aktivitäten, und Sicherheit. Bei der Untersuchung der resultierenden Workflow-Spezifikationen wurden folgende Probleme beobachtet: Zum einen sind die Workflow-Konstrukte, die einen querschneidenden Belang implementieren, auf die Spezifikationen von mehreren Workflow-Prozessen verstreut (engl. scattering). Diese Konstrukte können nicht in einem separaten Modul, das eine eindeutig-definierte Schnittstelle hat, gekapselt werden. Zum anderen vermischen sich (engl. tangling) die Workflow-Konstrukte, die die Geschäftslogik ausdrücken, mit den Konstrukten, die den querschneidenden Belang implementieren. Das führt zu komplexen Workflow-Spezifikationen, die schwer zu verstehen, zu warten und wiederzuverwenden sind. Darüberhinaus wurde die Formulierung von Workflow-Änderungen in heutigen Workflow-Systemen studiert, wie z. B. das Erweitern eines Urlaubspaketprozesses um die Suche nach einem Mietwagen. Dabei wurden folgende Beobachtungen gemacht: In statischen Workflow-Management Systemen, wie beispielsweise heutige BPEL Workflow-Engines, müssen die Workflow-Konstrukte, die eine Workflow-Änderung implementieren, direkt in die Spezifikationen der betroffenen Prozesse eingebettet werden. Es gibt kein Modulkonzept, um diese Konstrukte zu kapseln und die Änderungen als separate Entitäten erster Klasse auszudrücken. In adaptiven Workflow-Management Systemen, die dynamische Änderungen des Workflows unterstützten, treten ähnliche Modularitätsprobleme auf; Auch diese Systeme bieten kein Modul, um Workflow-Änderungen als separate Entitäten erster Klasse auszudrücken. Dies erschwert das Verständnis und die Verwaltung von Workflow-Änderungen. Die Modularitätsprobleme, die bisher besprochen wurden, sind auf den Mangel an geeigneten Dekompositionsmechanismen in heutigen Workflow-Sprachen zurückzuführen. Um diese Probleme zu lösen, wird eine Belang-basierte Dekomposition von den Workflow-Spezifikationen vorgeschlagen. Diese Dekomposition wird in eine neue Klasse von Workflow-Sprachen eingebaut, die aspektorientierte Workflow-Sprachen genannt werden. Diese Sprachen führen Konzepte aus der aspektorientierten Softwareentwicklung in den Bereichen der Workflow-Modellierung und Workflow-Spezifikation ein. Auf der Workflow-Modellierungsebene wird die bereits erwähnte Graph-basierte Workflow-Sprache um neue Konstrukte erweitert, die aspektorientierte Konzepte wie Pointcut und Advice graphisch darstellen. Diese Erweiterung zeigt die Konzepte aspektorientierter Workflow-Sprachen auf eine einfache und generische Art und Weise. Auf der Workflow-Spezifikationsebene wird besonders auf Join Point Modelle, Pointcut-Sprachen, Advice Sprachen, und Kompositionsmechanismen für aspektorientierte Workflow-Sprachen eingegangen. Zusätzlich wird die aspektorientierte Workflow-Sprache AO4BPEL vorgestellt. Diese Sprache und die zugehörige Workflow-Engine demonstrieren die technische Umsetzbarkeit von aspektorientierten Workflow-Sprachen. Es wird durch mehrere Beispiele gezeigt, wie Workflow-Aspekte im Allgemeinen und AO4BPEL Aspekte speziell eine bessere Modularisierung von querschneidenden Belangen und Workflow-Änderungen ermöglichen. Ausserdem macht AO4BPEL BPEL Prozesse flexibler, weil AO4BPEL Aspekte Prozesse zur Laufzeit ändern können. Um die Vorteile und die Nützlichkeit von aspektorientierten Workflow-Sprachen zu zeigen, werden zwei Anwendungen von AO4BPEL vorgestellt. In der ersten Anwendung wird ein Prozess Container Framework vorgestellt, das BPEL Prozessen Middlewareunterstützung anbietet. In diesem Framework spezifiziert man die nicht-funktionalen Anforderungen der Aktivitäten deklarativ, wie z. B. Sicherheit und Transaktionen. Diese Anforderungen werden dann mit Hilfe eines Prozess-Containers durchgesetzt, der ähnlich funktioniert wie Container in Enterprise Komponenten Modellen. Der Prozess-Container wurde als ein leichtgewichtiger und erweiterbarer Container implementiert, unter Zuhilfenahme von AO4BPEL Aspekten, die automatisch aus dem Deployment-Deskriptor generiert werden. Der Container ruft dann Middleware Web Services auf, um nicht-funktionale Anforderungen umzusetzen. Für die Implementierung dieser Web Services wurden Open-Source Implementierungen von Web Service Spezifikationen erweitert. In der zweiten Anwendung wird eine hybride Vorgehensweise zur Komposition von Web Services vorgeschlagen. Diese Vorgehensweise trennt die Implementierung der Geschäftsregeln von dem BPEL-Prozess, den Prinzipien des Business Rules Approaches entsprechend. Auf der Implementierungsebene, werden AO4BPEL-Aspekte benutzt, um die verschiedenen Typen von Geschäftsregeln modular zu implementieren. | German |
Drucken
Impressum