Diplomarbeit. Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik. im Studiengang Informatik

Transkript

1 Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik Diplomarbeit im Studiengang Informatik Thema: Konzeption und prototypische Realisierung eines Prozessmodellierungstools zur Beschreibung komplexer Nachrichtentransformationen mit WSBPEL, dargestellt am Beispiel von TransConnect eingereicht von: Ralf Winter eingereicht am: Betreuer: Prof. Dr. rer. oec. habil. Uwe Wloka (HTW-Dresden) Dipl.-Wirt.-Inf. (FH) Torsten Uhr (SQL-GmbH)

2 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... I Glossar... III Abbildungsverzeichnis... VI Tabellenverzeichnis... VIII Abkürzungsverzeichnis... IX 1 Einleitung Ausgangssituation und Motivation Zielstellungen Aufbau der Diplomarbeit Grundlegende Technologien Business Process Execution Language (BPEL) Einordnung Sprachbestandteile Bewertung Nachrichtentransformationsmodell Konzeptuelles Nachrichtenmodell Konzeptuelles Prozessmodell Grundlagen der Eclipse-Plugin-Entwicklung Infrastruktur von Eclipse Darstellungselemente Aktionen Weiterführende Themen Analyse und Spezifikation Istzustandsanalyse TransConnect Workflow Process Engine Defizite Untersuchung der Anforderungen an den Sollzustand Funktionale Anforderungen Nicht-Funktionale Anforderungen Untersuchung existierender Modellierungswerkzeuge Bewertungskriterien Produktvergleich Bewertung der Einsetzbarkeit Verwandte Arbeiten I

3 Inhaltsverzeichnis 4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect Architekturentwurf des Prozessmodellierungstools Struktur und Aufbau Anpassung der Aktivitäten Projekt- und Ressourcenverwaltung Remoteverwaltungsansatz über Vermittler Remoteverwaltungsansatz über Direktzugriff Lokalverwaltungsansatz Entwurfsentscheidung und konzeptuelle Architektur Beschreibung der Schnittstelle zu TransConnect Ausgewählte Implementierungsaspekte der prototypischen Realisierung am Beispiel der Translation-Aktivität Allgemeine Vorgehensweise zur Erweiterung des Designers Import von externen Transformationsbeschreibungen Zusammenfassung und Ausblick Ergebnisse und Schlussfolgerungen Ausblick Anhang A Metagrammatik der generierten Prozessbeschreibung B Komplexbeispiel Bestellabwicklung C Inhaltliche Struktur der beiliegenden CD-ROM Literaturverzeichnis Erklärungen II

4 Glossar Glossar Adapter Hier: Entwurfsmuster zur Anpassung einer fest definierten Schnittstelle einer Klasse an eine andere, um die Kommunikation zwischen Klassen mit inkompatiblen Schnittstellen zu ermöglichen. Compiler Computerprogramm, das ein in einer Quellsprache geschriebenes Programm in ein semantisch äquivalentes Programm einer Zielsprache umwandelt. Content Assist Hilfsassistent, der dem Nutzer mehrere Auswahlmöglichkeiten zu einem definierten Kontext zur Verfügung stellt. Delegate Beschreibt eine Schnittstelle zu einem komplexen Untersystem als Form des Entwurfsmusters Fassade, bei der einzelne Funktionalitäten an Unterklassen des Subsystems weitergereicht werden. Impedance Mismatch Integration Interface Komposition Lazy Loading Listener Bezeichnet im Gebiet der Softwaretechnik das Problem der Abbildung mengenorientierter relationaler Datensätze (Tupel) auf Objekte imperativer Programmiersprachen, wobei die Verarbeitung nur zeilenweise (satzorientiert) erfolgen kann. Bezeichnet die Herstellung eines Ganzen. Im übertragenen Sinne ist mit Integration also die globale Zusammenführung lokaler Systeme hinsichtlich bestimmter Integrationsobjekte mit einer festgelegten Integrationsart gemeint. Schnittstelle zur Kommunikation zwischen verschiedenen Komponenten eines Softwaresystems über definierte Routinen. Zusammensetzung eines Dienstes aus mehreren bestehenden Diensten mit einer Prozessbeschreibungssprache. Beschreibt den Prozess des dynamischen Ladens von Ressourcen zur Laufzeit bei erstmaliger Verwendung. Ereignisbehandlungsroutine, die dann ausgeführt wird, wenn ein bestimmtes Ereignis eintritt. III

5 Glossar Message Transformation Model Meta-Informationen Monitoring Nachrichtentransformation Orchestrierung Parser Persistenz Das MTM ist ein konzeptuelles, graphenorientiertes Modell zur Beschreibung von Transformationsprozessen der komplexen Nachrichtentransformation und gliedert sich in ein Nachrichtenmodell und ein Prozessmodell. Bezeichnung für Daten, die Informationen über andere Daten enthalten und diese mit Hilfe ausgewählter Eigenschaften beschreiben. Sammelbegriff für die Überwachung eines Vorgangs oder Prozesses mit technischen Hilfsmitteln über einen bestimmten Zeitraum. Beschreibt die Transformation von Nachrichten als Spezialfall der Datentransformation, wobei zwischen elementarer (syntaktische Transformationen) und komplexer (semantische Transformationen als Folge von Prozessschritten) Nachrichtentransformation unterschieden werden muss. Art der Komposition, wobei die zentrale Interaktion von dezentralen Diensten mit einer direkt oder indirekt ausführbaren Prozessbeschreibungssprache aus einer lokalen Sicht beschrieben wird. Computerprogramm zur Zerlegung eines Eingabedokuments in einzelne Bestandteile, die einem bestimmten gewünschten Format entsprechen. Bezeichnet die Speicherung von Daten oder Objekten in nicht-flüchtigen Speichermedien wie Dateisysteme oder Datenbanken. Plugin Bezeichnet ein weitgehend eigenständiges Computerprogramm, welches die Funktionalität eines anderen Softwareprodukts erweitert und mit diesem über definierte Schnittstellen lose gekoppelt ist. Proxy Entwurfsmuster, bei dem die Kontrolle über ein Objekt auf ein vorgelagertes Stellvertreterobjekt verschoben wird. Prozess Beschreibung des Prozessablaufs mit einer Prozessbeschreibungssprache. Wird synonym auch als Prozesstyp bezeichnet. IV

6 Glossar Prozessbeschreibungssprache Ressource Routing Serialisierung Eine derartige Sprache kann als Metamodell zur Beschreibung von teilweise automatisierten Geschäftsprozessen in Form einer Folge von Prozessschritten verstanden werden. Typische Ausprägungen solcher Sprachen sind grafische Ausdrucksformen oder XML- Schemata. Betriebsmittel, das benötigt wird, um eine bestimmte Aufgabe zu erreichen. Hier: Bestandteil von TransConnect wie Adapter, Warteschlange, Workflow, Zeitgesteuerte Aufgabe oder Nachrichtentyp. Bezeichnet im Allgemeinen das Festlegen von Wegen für Nachrichtenströme über definierte Regeln. Bezeichnet in der Softwaretechnik die Abbildung von Objekten auf externe sequenzielle Darstellungsformen (wie zum Beispiel Datenströme) zur Erreichung von Persistenz. Template Schablonen oder Vorlagen, die eine vom Datentyp unabhängige, generische Programmierung ermöglichen und zur Laufzeit mit Parametern vervollständigt werden. Thread Widget Teil eines Prozesses, der eine bestimmte Aufgabe erledigen soll und meist zur parallelen Abarbeitung eingesetzt wird. Im Rahmen von grafischen Benutzeroberflächen oft verwendet, um das Blockieren der Eingabemaske bei längerer Laufzeit zu vermeiden. Synonym für ein Fensterkontrollelement oder Steuerelement in grafischen Benutzeroberflächen. Workflow Oftmals synonym für den Begriff des Prozesses beziehungsweise des Prozesstyps verwendet. Allerdings wird hierbei ausschließlich auf IT-gestützte Realisierungen abgezielt, weshalb Prozesstyp an dieser Stelle allgemeiner ist. Wrapper Austauschbare Hüllenklasse, welche die Funktionalitäten anderer Klassen kapselt und mit entsprechender Erweiterung auch als Adapter dienen kann. V

7 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Adaptierte 3-Schichten-Architektur Abbildung 2: Logischer Aufbau des konzeptuellen Nachrichtenmodells Abbildung 3: Grundmodell eines gerichteten Graphen Abbildung 4: Knotentypen eines Prozesses Abbildung 5: Architekturaufbau Eclipse Abbildung 6: Architekturaufbau von TransConnect Abbildung 7: 3-Ebenen-Aufbau der Komponenten von TransConnect Abbildung 8: Architektur TransConnect Server Abbildung 9: Gesamtarchitektur TransConnect Abbildung 10: Architektur TransConnect Server Abbildung 11: Logischer Aufbau des WFPE-Core Abbildung 12: Arbeitsschritte des Process Parsers Abbildung 13: Aufbau Migrator Abbildung 14: Aufbau Service Dictionary Abbildung 15: Aufbau des Runtime Environment Abbildung 16: Einschätzung Eclipse BPEL Project Abbildung 17: Screenshot Eclipse BPEL Project Abbildung 18: Bewertung IX Workflow Modeler Abbildung 19: Screenshot IX Workflow Modeler Abbildung 20: Bewertung JOpera Abbildung 21: Screenshot JOpera Abbildung 22: Bewertung Intalio BPMS Designer Abbildung 23: Screenshot Intalio BPMS Designer Abbildung 24: Bewertung ActiveBPEL Designer Abbildung 25: Screenshot ActiveBPEL Designer Abbildung 26: Ergebnis des Produktvergleichs Abbildung 27: Gesamtarchitektur Eclipse BPEL Project Abbildung 28: Untersuchung der Lese- und Schreibperformance Abbildung 29: Aufbau Plugin-Komponente model Abbildung 30: Aufbau Plugin-Komponente ui Abbildung 31: TransConnect Beispielszenarien Abbildung 32: Schema Remoteverwaltungsansatz über Vermittler Abbildung 33: Schema Remoteverwaltungsansatz über Direktzugriff Abbildung 34: Schema Lokalverwaltungsansatz Abbildung 35: Ordnerstruktur Ressourcenverwaltung Abbildung 36: Schnittstellen TransConnect Server Abbildung 37: Schnittstelle Process Designer Abbildung 38: Schnittstelle Ressourcenverwaltung Abbildung 39: Ecore-Model der Translation-Aktivität Abbildung 40: UML-Klassendiagramm der Translation-Aktivität Abbildung 41: Extension für Schaltfläche der Translation-Aktivität Abbildung 42: Extension für Aktion der Translation-Aktivität Abbildung 43: Extension für Eigenschaftenseite der Translation-Aktivität Abbildung 44: Screenshot Eigenschaftenseite der Translation-Aktivität Abbildung 45: UML-Klassendiagramm der Transformation-Schnittstelle VI

8 Abbildungsverzeichnis Abbildung 46: Screenshot Auswahldialog Transformationbeschreibung Abbildung 47: Beispielprozess Bestellabwicklung VII

9 Tabellenverzeichnis Tabellenverzeichnis Tabelle 1: Notation der Metagrammatik... 6 Tabelle 2: Allgemeine Sprachbestandteile von WSBPEL Tabelle 3: Grundlegende Aktivitäten von WSBPEL Tabelle 4: Strukturierte Aktivitäten von WSBPEL Tabelle 5: Transaktionsaktivitäten von WSBPEL Tabelle 6: Aktionen in Eclipse Tabelle 7: Gegenüberstellung der Defizite Tabelle 8: Funktionale Anforderungen an das Prozessmodellierungswerkzeug Tabelle 9: Funktionale Anforderungen an die Ressourcenverwaltung Tabelle 10: Funktionale Anforderungen an die Monitoring-Komponente Tabelle 11: Nicht-Funktionale Anforderungen Tabelle 12: Bewertungskriterien Tabelle 13: Produktvergleich Modellierungswerkzeuge Tabelle 14: Aufgaben der Plugin-Komponenten Tabelle 15: Abbildung der interaktionsorientierten Aktivitäten Tabelle 16: Abbildung der kontrollflussorientierten Aktivitäten Tabelle 17: Abbildung der datenflussorientierten Aktivitäten Tabelle 18: Ressourcen des TransConnect -Servers Tabelle 19: Vergleich TC-Manager mit TC-Developer Studio Tabelle 20: Benötigte Ressourcen der Aktivitäten Tabelle 21: Identifizierte Typen von Transformationsbeschreibungen Tabelle 22: Inhaltliche Struktur der beiliegenden CD-ROM VIII

10 Abkürzungsverzeichnis Abkürzungsverzeichnis API BLOB BPEL BPMN DOM DTD EAI ECA EMF FTP GMF GUI J2EE JDBC JNI JVM MDD MOM MTM OASIS PDE Application Programming Interface Binary Large Object Business Process Execution Language Business Process Modeling Notation Document Object Model Document Type Definition Enterprise Application Integration Event-Condition-Action Eclipse Modeling Framework File Transfer Protocol Graphical Modeling Framework Graphical User Interface Java 2 Enterprise Edition Java Database Connectivity Java Native Interface Java Virtual Machine Model Driven Development Message Orientated Middleware Message Transformation Model Organization for the Advancement of Structured Information Standards Plugin Development Environment IX

11 Abkürzungsverzeichnis RDBMS RFRS SDK STX SWT Relational Database Management System Ready For Rational Software Software Development Kit Streaming Transformation for XML Standard Widget Toolkit TC TransConnect UI UML VM WFPE WSBPEL WSDL WSFL WSIL XLANG XML XPath XSD XSL(T) User Interface Unified Modeling Language Virtual Machine Workflow Process Engine Web Service Business Process Execution Language Web Service Description Language Web Service Flow Language Web Service Inspection Language XML-basierte Erweiterung der WSDL Extensible Markup Language XML Path Language XML Schema Definition Extensible Stylesheet Language (Transformation) X

12 1 Einleitung 1 Einleitung Die Steuerung von Geschäftsprozessen über eine Workflow-Engine ist zusammen mit einem Nachrichtentransportsystem, einer regelbasierten Verteilung von Nachrichten und einem zentralem Repository zur Regel- und Prozessdefinition einer der wichtigsten Bestandteile einer modernen Integrationsplattform im Sinne der Enterprise Application Integration (EAI). Begleitend dazu werden Werkzeuge zur Prozessmodellierung dazu genutzt, eine komfortable grafische Modellierung der Geschäftsprozesse innerhalb einer bestimmten Notation zu ermöglichen. Im Rahmen dieser Diplomarbeit ist zu untersuchen, in wie weit existierende Prozessmodellierungstools zur visuellen Beschreibung komplexer Transformationsprozesse eingesetzt, respektive als Grundlage für eine Eigenentwicklung genutzt werden können. Der Entwurf und die prototypische Realisierung richten sich hierbei nach den Anforderungen der Integrationsplattform TransConnect der Firma SQL GmbH. 1.1 Ausgangssituation und Motivation Mit der Definition eines konzeptuellen Modells zur Beschreibung komplexer Nachrichtentransformationen dem Message Transformation Model (MTM) [BÖHM07] wurde die Grundlage für die Einführung einer Prozesssteuerung in die Integrationsplattform TransConnect gelegt. Unter Nutzung von Transformationssprachen des XML-Standards wie XSLT oder STX wurden Vorschriften festgelegt, um eingehende Nachrichten von Quellsystemen in das interne Nachrichtenformat umzuwandeln beziehungsweise zum Anschluss beliebiger Zielsysteme interne Nachrichten in das Format des Zielsystems zu transformieren. Das Modell wurde auf externer Ebene mit Mitteln der Prozessbeschreibungssprache BPEL abgebildet und erlaubt somit prinzipiell die Nutzung bereits existenter Werkzeuge zur Modellierung von Prozessen. Auf diese Weise können Nutzer zu themengebundenen Szenarien wie zum Beispiel Bestellwesen, Lohnbuchhaltung oder Auftragsplanung Prozesspläne grafisch erstellen. Dies kann ohne Kenntnis von internen Vorgängen im EAI-System erfolgen und erspart daher die textuelle Konfiguration von Routen innerhalb eines komplexen Management-Tools. 1

13 1 Einleitung Im Rahmen der Weiterentwicklung von TransConnect zu Version soll somit ein Prozessmodellierungstool entworfen werden, mit dem es möglich ist, einen Workflow mit den Bestandteilen des MTM zu visualisieren. Da vorhandene Tools zur Prozessmodellierung zwar möglicherweise bereits mit Standards wie BPEL oder BPMN, jedoch nicht mit den Spezifikationen des MTM kompatibel sind, spielt die Art und Weise der formalen Beschreibung des modellierten Prozesses lediglich eine untergeordnete Rolle. Vielmehr muss diese künftig so erfolgen, dass die modellierten Workflows direkt an TransConnect weitergereicht und dort von der Workflow-Engine verarbeitet werden können. 1.2 Zielstellungen Basierend auf der bereits formulierten Ausgangssituation, können nun die Hauptziele für die Diplomarbeit festgelegt und anschließend näher spezifiziert werden. Untersuchung existierender Modellierungswerkzeuge im Hinblick auf die gestellten Anforderungen Bewertung der Einsetzbarkeit als Grundlage für eine Erweiterung Entwurf der Erweiterungen anhand des MTM und deren prototypische Realisierung am Beispiel von TransConnect Grundlegender Entwurf und prototypische Implementierung einer Projekt- und Ressourcenverwaltung In den ersten beiden Zielstellungen ist zunächst zu untersuchen, ob auf dem Markt vorhandene Prozessmodellierungstools den Anforderungen von TransConnect beziehungsweise des MTM genügen und somit wiederverwendet und erweitert werden können, oder ob eine Eigenentwicklung nötig ist. Abhängig von der Bewertung der Einsetzbarkeit steht nun als drittes Ziel der Entwurf der Eigenentwicklung beziehungsweise der Erweiterung und dessen prototypische Realisierung am Beispiel von TransConnect im Mittelpunkt der Diplomarbeit. Im Falle der Erweiterung eines vorhandenen Tools soll insbesondere darauf geachtet werden, dass die zusätzlichen Module möglichst weitgehend lose gekoppelt sind und somit Produktaktualisierungen des Hauptprogramms nur mit geringfügigen Änderungen verbunden sind. Als letzte 2

14 1 Einleitung Zielstellung der Diplomarbeit ist als Vorarbeit zu einem künftigen umfassenden TransConnect Developer Studio die Verwaltung der Projekte und Ressourcen beziehungsweise Metadaten, die der TransConnect -Server benötigt, zu entwerfen und ebenfalls prototypisch zu implementieren. 1.3 Aufbau der Diplomarbeit Die Diplomarbeit orientiert sich generell an den bereits definierten Zielstellungen und gliedert sich dabei in sechs Kapitel, die gleichzeitig die oberste Gliederungsebene darstellen. Als zweite Ebene werden Unterkapitel und als dritte Ebene Abschnitte verwendet. Zusätzlich können an einigen Stellen Teilüberschriften ohne Nummerierung vorkommen, um einzelne Abschnitte inhaltlich nochmals zu ordnen. Nach dieser Einleitung in Kapitel 1 beschäftigt sich Kapitel 2 zunächst mit grundlegenden Technologien wie der Business Process Execution Language (BPEL) sowie dem Message Transformation Model (MTM). Hierbei sei jedoch darauf hingewiesen, dass die Sprache BPEL an sich in dieser Diplomarbeit nur eine untergeordnete Rolle spielt und das MTM in der Diplomarbeit von Matthias Böhm [BÖHM07] ausführlich definiert und beschrieben ist, weshalb an dieser Stelle nur eine kurze Einführung und Übersicht gegeben wird. Abschließend gibt dieses Kapitel einen Einblick in das Plugin Development Environment (PDE) von Eclipse, mit dessen Hilfe sehr komfortabel auf dem Eclipse Framework basierende Tools und Plugins entwickelt werden können. In Kapitel 3 wird zunächst die ausführliche Analyse des Istzustands vorgenommen und anschließend werden die Anforderungen an den Sollzustand definiert. Diese beiden Schritte dienen als Ausgangspunkt für die nun folgende Untersuchung existierender Modellierungswerkzeuge. Dabei geht es neben der Definition von Bewertungskriterien sowie dem eigentlichen umfangreichen Produktvergleich um eine abschließende Bewertung der möglichen Einsetzbarkeit eines vorhandenen Tools als Erweiterungsgrundlage. Während die bisherigen Kapitel lediglich analytische Voraussetzungen schaffen, befasst sich Kapitel 4 mit dem Entwurf der prototypischen Realisierung am Beispiel von TransConnect. Besondere Aspekte der Implementierung an ausgewählten Beispielen 3

15 1 Einleitung werden in Kapitel 5 beschrieben, wobei lediglich Auszüge des Quellcodes vorkommen. Die CD im Anhang beinhaltet hingegen das vollständige Projekt inklusive ausführlicher Dokumentation im JavaDoc-Format. Kapitel 6 fasst die Ergebnisse der Diplomarbeit noch einmal zusammen, weist auf mögliche weiterhin vorhandene Defizite hin und gibt einen Ausblick auf zusätzliche Erweiterungen und Perspektiven, die aber nicht Bestandteil dieser Diplomarbeit sind. An dieser Stelle sei zudem vermerkt, dass aus Gründen der Nachvollziehbarkeit und Zuordnung oftmals englische Originalbegriffe verwendet werden müssen, jedoch an vielen Stellen versucht wird, eine deutsche Entsprechung zu finden. 4

16 2 Grundlegende Technologien und Tools 2 Grundlegende Technologien In diesem Kapitel werden grundlegende Technologien und Tools im Überblick dargestellt, deren Kenntnis für das Verständnis der Diplomarbeit wichtig ist. Dabei wird zunächst kurz auf die Prozessbeschreibungssprache BPEL (Business Process Execution Language) eingegangen, welche zur Einordnung der durch das zu entwickelnde Prozessmodellierungstool entstehenden Diagramme wichtig ist und vom Nachrichtentransformationsmodell verwendet wird. Abschließend werden die Konzepte der Eclipse-Plugin-Entwicklung beschrieben, die die Grundlage für die Entwicklung des Prozessmodellierungstools darstellen. 2.1 Business Process Execution Language (BPEL) Die Business Process Execution Language ist eine XML-basierte Sprache, die zur Orchestrierung von Webservices eingesetzt wird. Das zu Grunde liegende Prozessmodell nutzt dabei Aktivitäten für jeden Prozessschritt, wobei einzelne Aktivitäten mit Web Services kommunizieren können (daher auch Web Service Process Execution Language WSBPEL genannt). Die Spezifikation der derzeit aktuellen Version, vom OASIS WS-BPEL Komitee am 14. September 2004 als WSBPEL 2.0 bezeichnet, wurde am 12. April 2007 als Standard verabschiedet Einordnung Das Ziel der Sprache BPEL ist es, vorhandene Ideen der Sprachen XLANG von Microsoft und WSFL (Web Service Flow Language) von IBM aufzugreifen und somit eine Beschreibung von sowohl abstrakten als auch direkt ausführbaren Geschäftsprozessen zu ermöglichen. Eine grafische Modellierung der Prozesse ist im Standard selbst nicht vorgesehen und richtet sich nach der Implementierung des jeweiligen Tools. Für abstrakte Geschäftsprozesse wird dafür typischerweise die Business Process Modeling Notation (BPMN) von vielen Designern verwendet. Ausführbare Prozesse können auf einer entsprechenden BPEL-Engine gestartet werden, während abstrakte Prozesse interne Vorgänge beschreiben und somit nicht der externen Sicht auf den Geschäftsprozess dienen. 5

17 2 Grundlegende Technologien und Tools Sprachbestandteile Die allgemeine Metagrammatik von WSBPEL 2.0 kann nach [OAWS07] wie folgt dargestellt werden, wobei an dieser Stelle aus Gründen der Übersichtlichkeit auf die Angabe der Attribute verzichtet wird. Dabei werden folgende Konventionen bezüglich der Notation verwendet, die gleichermaßen für die gesamte Diplomarbeit gültig sind. Notation Häufigkeit? einmal oder kein mal * einmal, kein mal oder beliebig oft + einmal oder beliebig oft [ ] Zusammenfassung von Elementen zu einer Gruppe unter Beachtung von?, * und + ( ) Alternativen innerhalb einer Gruppe von Elementen mit ( und ) oder innerhalb von Attributen Tabelle 1: Notation der Metagrammatik <process> <extensions>? <extension>+ </extensions> <import/>* <partnerlinks>? <partnerlink/>+ </partnerlinks> <messageexchanges>? <messageexchange/>+ </messageexchanges> <variables>? <variable/>+ </variables> 6

18 2 Grundlegende Technologien und Tools <correlationsets>? <correlationset/>+ </correlationsets> <faulthandlers>? <catch>* activity </catch> <catchall>? activity </catchall> </faulthandlers> <eventhandlers>? <onevent>* <correlations>? <correlation/>+ </correlations> <fromparts>? <frompart/>+ </fromparts> <scope...>...</scope> </onevent> <onalarm>* (<for>duration-expr</for> <until>deadline-expr</until>)? <repeatevery>duration-expr</repeatevery>? <scope...>...</scope> </onalarm> </eventhandlers> activity </process> Das Wurzelelement <process> kapselt dabei den gesamten Prozess und enthält die einzelnen Sprachbestandteile als Kindelemente, die nachstehend kurz vorgestellt und beschrieben werden. 7

19 2 Grundlegende Technologien und Tools Name extensions import partnerlinks messageexchanges variables correlationsets faulthandlers eventhandlers Tabelle 2: Beschreibung Namensräume von WSBPEL-Erweiterungen Abhängigkeiten zu externen XML-Schemata oder WSDL- Definition Webservices, mit denen der Prozess kommunizieren soll Logische Bezeichner zur Assoziation von zusammengehörigen Receive/Reply-Paaren Variablen eines bestimmten Nachrichtentyps Zuordnungen von Variablen aus der Kommunikation mit Webservices zu einer bestimmten Prozessinstanz Fehlerbehandlungsroutinen Ereignisbehandlungsroutinen Allgemeine Sprachbestandteile von WSBPEL-2.0 Die Abschnitte in der Metagrammatik, die mit activity gekennzeichnet sind, stellen Platzhalter für eine beliebige Anzahl von Aktivitäten dar. Dabei wird zunächst unterschieden zwischen grundlegenden Aktivitäten, die weitestgehend atomar sind, und geschachtelten (strukturierten) Aktivitäten, die wiederum andere Aktivitäten enthalten können und somit zur Komposition von komplexen Prozessen geeignet sind. Grundlegende Aktivitäten Name assign validate invoke receive reply throw Beschreibung Wertzuweisung einer Variablen Gültigkeitsprüfung von Variablenwerten anhand deren Definition Aufruf eines Webservice zum Versenden einer Nachricht, entweder synchron (Request-Response) oder asynchron Blockierendes Warten auf passende eingehende Nachricht Verschicken einer Nachricht als Antwort auf eine eingehende Nachricht Signalisierung eines Fehlers, vergleichbar mit Ausnahmen (Exceptions) in objektorientierten Programmiersprachen 8

20 2 Grundlegende Technologien und Tools Name rethrow exit wait empty Tabelle 3: Beschreibung Verwendung im Rahmen der Fehlerbehandlung zum Weitergeben eines Fehlers Sofortiges Beenden eines Prozesses ohne Fehlerbehandlung Unterbrechung des Prozesses für eine definierte Zeitspanne oder bis zu einem bestimmten Zeitpunkt Leerer Knoten ohne Aktion Grundlegende Aktivitäten von WSBPEL-2.0 Strukturierte Aktivitäten Name sequence if while repeatuntil foreach flow pick Tabelle 4: Beschreibung Abarbeitung der Aktivitäten in der vorgegebenen Reihenfolge Bedingte Abarbeitung genau einer Aktivität entsprechend der gesetzten Bedingung, Erweiterung um beliebig viele elseifbeziehungsweise else-elemente möglich Abarbeitung der Aktivitäten dieser kopfgesteuerten Schleife, solange die Bedingung zutrifft Abarbeitung der Aktivitäten dieser fußgesteuerten Schleife, bis die Bedingung zutrifft Abarbeitung der Aktivitäten dieser kopfgesteuerten Schleife für alle Elemente, entweder seriell (entspricht der sequence- Aktivität) oder parallel (entspricht der flow-aktivität) Parallele Abarbeitung der Aktivitäten, beendet erst wenn jede der Aktivitäten beendet wurde (Synchronisation) Blockierendes Warten auf das Eintreten eines bestimmten Ereignisses und Auslösen einer Reaktion Strukturierte Aktivitäten von WSBPEL-2.0 Die Aktivitäten in der letzten Gruppe können ebenfalls weitere Aktivitäten beinhalten, beziehen sich jedoch auf einen eigenständigen Teilprozess, der auch als Transaktion bezeichnet werden kann. 9

21 2 Grundlegende Technologien und Tools Transaktionsaktivitäten Name scope compensate compensationscope Tabelle 5: Beschreibung Eine Art abgegrenzter Teilprozess mit eigenen Aktivitäten, die nur hier gültig sind Verwendung im Rahmen der Fehlerbehandlung zur Kompensation erfolgreich beendeter scope-aktivitäten Ähnlich wie compensate, jedoch auf einen speziellen scope bezogen Transaktionsaktivitäten von WSBPEL Bewertung Die Sprache WSBPEL wurde mit Verabschiedung der Version 2.0 hinsichtlich ihrer Komplexität stark erweitert und deckt mit den vorhandenen Aktivitäten nahezu sämtliche möglichen Funktionalitäten ab, die mit der Orchestrierung von Webservices in Verbindung stehen. Die flexibel nutzbare Invoke-Aktivität erlaubt die Kommunikation mit beliebigen externen Diensten, weshalb mit BPEL modellierte Prozesse in einer Vielzahl von spezifischen Szenarien einsetzbar sind. Bezüglich der standardisierten Erweiterung können so genannte ExtensionActivities verwendet werden, um die Sprache an eigene Anforderungen anzupassen. Auf Grund der aktuell hohen Akzeptanz in der Wirtschaft ist WSBPEL 2.0 somit sehr gut zur Beschreibung eines umfangreichen Nachrichtentransformationsmodells geeignet, worauf im folgenden Unterkapitel näher eingegangen wird. 10

22 2 Grundlegende Technologien und Tools 2.2 Nachrichtentransformationsmodell Das von Matthias Böhm in einem konzeptuellen Modell [FEKM06] definierte Nachrichtentransformationsmodell das Message Transformation Model (MTM) enthält sowohl ein konzeptuelles Nachrichtenmodell als auch ein konzeptuelles Prozessmodell, welche sich wie folgt in die konzeptuelle Ebene der 3-Ebenen- Architektur nach ANSI/SPARC [ANSI75] einordnen: Abbildung 1: Adaptierte 3-Schichten-Architektur Beide Teilmodelle werden in den nachfolgenden Abschnitten genauer betrachtet Konzeptuelles Nachrichtenmodell Das konzeptuelle Nachrichtenmodell beschreibt ein generisches Nachrichtenmodell, mit dem sämtliche Transformationsprozesse abgebildet werden können. Einzelne Nachrichten bestehen aus einem Kopf- und Datensegment, aus denen sich der in folgender Abbildung dargestellte logische Aufbau einer Nachricht ergibt: 11

23 2 Grundlegende Technologien und Tools Abbildung 2: Logischer Aufbau des konzeptuellen Nachrichtenmodells Während das Kopfsegment einer Nachricht aus einer 1:1-Zuordnung von Attribut und Wert für spezifische Metadaten zur Verwaltung besteht, enthält das Datensegment komplexere Attribute, denen jeweils ein Teil (Part) der Nachricht zugeordnet wird. Diese können entweder atomar sein oder wiederum selbst Binary Large Objects (BLOBs) beziehungsweise XML-Fragmente enthalten. Der Default-Part CONTENT muss dabei jedoch immer vorhanden sein. Mit diesem attributorientierten, feingranularen Ansatz ist es möglich, sämtliche Datenrepräsentation gleichzeitig flexibel und dynamisch, aber auch mit einer definierten Struktur abzubilden Konzeptuelles Prozessmodell Bezüglich des konzeptuellen Prozessmodells wurde ein graphenorientiertes Modell nach dem Konzept des JBoss Graph Oriented Programming [JGOP06] gewählt, um eine effiziente Verarbeitung aller Prozessbeschreibungssprachen zu gewährleisten. Die einzelnen Prozessschritte wurden dabei anforderungsorientiert entworfen, das heißt, bei erweiterten Anforderungen an eine Transformation werden einfach weitere Prozessschritte hinzugefügt ohne sich an eine bestimmte Sprache zu binden. Intern wurde das Modell aus Gründen der Performance als kompilierter und parametrisierter Prozessplan realisiert, der als eine Art Template verstanden werden kann. Aufbauend 12

24 2 Grundlegende Technologien und Tools auf dem Grundmodell eines gerichteten Graphen mit Knoten und Kanten, wurde das konzeptuelle Prozessmodell durch das hierarchische Element eines Prozesses erweitert, wobei die Knotentypen einzelne Prozessschritte darstellen, wie die folgende Abbildung zeigt: Abbildung 3: Grundmodell eines gerichteten Graphen Anhand dieses Modells wurden Muster als Knotentypen, respektive Prozessschritte, definiert, um die Interaktion mit externen Systemen, den Kontroll- und Datenfluss sowie die Transaktionssicherheit von Prozessen abzubilden. Abbildung 4: Knotentypen eines Prozesses Die einzelnen Muster werden in Kapitel 4 noch einmal näher beschrieben, welches sich unter anderem mit dem Entwurf der entsprechenden Darstellungselemente für jedes der genannten Prozessschritte im Prozessplan des Modellierungswerkzeugs beschäftigt. Eine Bewertung des MTM zusammen mit der Workflow Engine unter den aktuellen Gegegebenheiten findet in Abschnitt (Defizite der Istzustandsanalyse) statt. 13

25 2 Grundlegende Technologien und Tools 2.3 Grundlagen der Eclipse-Plugin-Entwicklung Die auf Java basierende Entwicklungsumgebung Eclipse wird derzeit als Quasi- Standard für die Entwicklung von allein lauffähigen Java-Anwendungen, Applikationen im Umfeld von J2EE, aber auch zahlreicher Plugins mit Hilfe eines eigenen Plugin- Development-Environments (PDE) angesehen. Falls Anwendungen mit einer grafischen Benutzeroberfläche (GUI) entwickelt werden sollen, kann dabei auf den Standard Widgets Toolkit (SWT) zurückgegriffen werden, der eine Vielzahl von Darstellungselementen zur Verfügung stellt und sogar die Grundlage für die Oberfläche von Eclipse selbst ist. In diesem Unterkapitel soll zunächst ein Überblick über die Infrastruktur von Eclipse mit ihren Darstellungselementen gegeben und schließlich auf das Aktionskonzept eingegangen werden. Danach werden noch einige weiterführende Themen der Plugin- Entwicklung benannt, die aber an dieser Stelle nur sehr abstrakt betrachtet werden können Infrastruktur von Eclipse Wie in [ECLI06] dargestellt, ist Eclipse kein monolithisches Programm, sondern besteht neben einem kleinen Kern, dem sogenannten Plugin-Loader, aus einer Vielzahl von Plugins. Bereits in der minimalen Auslieferungsversion von Eclipse sind wichtige Plugins wie Core, SWT, JFace, Workbench Core, Workbench UI und Help enthalten, welche die Grundfunktionalität von Eclipse herstellen. Diese Plugins werden je nach Bedarf im Laufe einer Session geladen (Lazy Loading), aber nicht automatisch entladen. Das bedeutet, jeder Programmierer eines Plugins muss sich selbst darum kümmern, dass nicht mehr benötigte Elemente aus dem Speicher entfernt werden, damit es nicht zu Speicherengpässen in der Java Virtual Machine (JVM) kommt. Die folgende Abbildung zeigt den Architekturaufbau von Eclipse nach [ECLIFPP] noch einmal im Überblick. 14

26 2 Grundlegende Technologien und Tools Abbildung 5: Architekturaufbau Eclipse Jedes Eclipse-Plugin besteht dabei aus einem Plugin-Manifest, einer Plugin- Aktivierungsklasse sowie einer beliebigen Anzahl von weiteren Klassen, die die eigentliche Funktionalität enthalten. Diese drei groben Bestandteile sind schließlich in einem Java-Archiv (JAR) gepackt, welches sich im plugins -Verzeichnis von Eclipse befindet. Das Plugin-Manifest jedes einzelnen Plugins, bestehend aus den Dateien MANIFEST.MF und plugin.xml, wird beim Start von Eclipse analysiert und dessen Meta-Informationen in einem internen Datenmodell aufgebaut. Auf diese Weise kennt Eclipse zu jeder Zeit die grobe Beschreibung der einzelnen Plugins und stellt initiale Aktivierungselemente wie Buttons oder Menüs dar. Erst wenn diese ausgelöst, also vom Benutzer im Rahmen einer Interaktion angesprochen werden, wird das eigentliche Plugin mit den entsprechenden Klassen in den Speicher geladen. Die Datei MANIFEST.MF enthält Informationen über das Plugin wie unter anderem Name, Version, Hersteller sowie den absoluten Pfad der Aktivierungsklasse, die erst dann instantiiert wird, wenn das Plugin zum ersten Mal aufgerufen wird. Weiterführende Bestandteile des Plugins sind in der Datei plugin.xml enthalten, wie zum Beispiel: Dependencies Runtime Extensions 15

27 2 Grundlegende Technologien und Tools Extension-Points Build Im Abschnitt Dependencies werden vorhandene Plugins wie beispielsweise Darstellungselemente (siehe Abschnitt 2.3.2) oder Ressourcen angegeben, deren Klassen vom aktuellen Plugin benötigt werden. Unter Runtime sind die Pakete des aktuellen Plugins zu finden, die zur Laufzeit für andere Plugins sichtbar sein sollen. Dies ist vor allem dann sinnvoll, wenn externe Plugins das aktuelle Plugin erweitern oder testen sollen. In der Kategorie Extensions können deklarativ Schnittstellen von anderen APIs, zum Beispiel der Eclipse-API, angegeben und direkt konfiguriert werden. Die einzelnen Extensions sind hierarchisch in Form eines Baumes aufgebaut, sodass die Elemente beliebig geschachtelt werden können. Die meisten Elemente können jedoch auch programmiertechnisch in den jeweiligen Klassen erstellt und eingerichtet werden. Unter Extension-Points können eigene Schnittstellen mit einer bestimmten Funktionalität definiert werden, die dann wiederum von anderen Plugins über Extensions verwendet werden können. Schließlich kann man über Build diverse Einstellungen an den Build-Pfaden vornehmen, das heißt, welche Dateien im fertigen Archiv des Plugins enthalten sein sollen. Die angegebene Plugin-Aktivierungsklasse ist die Klasse, die mittels Überschreibung der Methoden start() und stop() auf das Laden beziehungsweise Entladen eines Plugins Einfluss nehmen und somit bestimmte Eingangskonfigurationen oder Aufräumarbeiten erledigen kann. Hierbei sollte man jedoch darauf achten, dass nur absolut notwendige Aktionen in diesen Methoden enthalten sind, da sonst das Starten oder Beenden von Eclipse und dessen Plugins bezüglich der Performance negativ beeinflusst wird. Des Weiteren wird von [RFRS] empfohlen, dass Plugins die interne Logger-Factory von Eclipse nutzen sollen, um Laufzeitfehler innerhalb des Eclipse-Error-Logs anzuzeigen und in einem festgelegten Format in Textdateien festzuhalten. 16

28 2 Grundlegende Technologien und Tools Bezüglich der Oberfläche besitzt Eclipse zunächst als übergeordnetes Element die Workbench, welche das eigentliche Fenster der Entwicklungsumgebung mit Menü- und Werkzeugleiste (Toolbar) darstellt. Die Workbench ist unterteilt in einzelne sogenannte Perspektiven, wobei die bekannteste sicherlich die Java-Perspektive ist. Jede Perspektive enthält ihre eigene, hinsichtlich des Layouts frei konfigurierbare Zusammenstellung von mehreren Views und einem Editor. Unter einem View ist hier ein entweder links, rechts oder unterhalb des Editors platzierbares Fenster zu verstehen, welches eine bestimmte Sicht auf den aktuellen Kontext zeigt, wie zum Beispiel eine hierarchische Gliederung (Outline), Objekteigenschaften oder einen Navigator, über den man den aktuellen Workspace durchsuchen kann Darstellungselemente Wie bereits einleitend in diesem Unterkapitel beschrieben, bietet der Standard Widgets Toolkit (SWT) die Grundlage für die nativen Oberflächenelemente, im folgenden Widgets genannt, von Eclipse und seinen Plugins. Nativ in diesem Kontext bedeutet, dass versucht wird, auf der aktuellen Plattform (zum Beispiel Windows oder Linux) bereits vorhandene Widgets wieder zu verwenden und nicht vorhandene zu emulieren. Somit ist es möglich, eigene Oberflächen zu entwickeln, die vom Look-and-Feel an die Oberfläche des verwendeten Betriebssystems erinnern. Diese nativen Widgets von SWT können jedoch nur einfache Datentypen wie Zahlen, Zeichenketten oder Binärobjekte (Bilder) beinhalten, was sehr leicht zu einem Impedance Mismatch führen kann, wenn in Listen, Tabellen oder anderen komplexen Widgets benutzerdefinierte objektorientierte Daten verwendet werden. Um dieses Problem zu beheben, bieten sogenannte JFace Viewer entsprechende objektorientierte Wrapper um die zugehörigen SWT-Widgets an. Jeder dieser Viewer besteht aus einem Label Provider und einem Content Provider. Der Label Provider ist für die Zuordnung der Eigenschaften eines Objekts zu den jeweiligen Teilen eines Widgets wie Spalten oder Knoten zuständig, die letztendlich als Zeichenketten oder Bilder dargestellt werden. Der Content Provider dient sozusagen als Adapter zwischen dem internen Datenmodell der Objekte und dem Datenformat, das der jeweilige Viewer erwartet. Zur Kommunikation zwischen den einzelnen Widgets wird ein Event-Listener-Konzept genutzt. Das bedeutet, im Falle einer Nutzeraktion werden Ereignisse ausgelöst, auf die 17

29 2 Grundlegende Technologien und Tools andere Widgets mit speziell implementierten Listenern warten und dementsprechend eine Aktion ausführen Aktionen Aktionen werden in Eclipse für nutzergesteuerte Ereignisse im Bereich von Menüleisten, Werkzeugleisten (Toolbars) und Kontextmenüs verwendet, wobei es umfangreiche Filtermöglichkeiten gibt, um die Sichtbarkeit der Aktionen zu steuern. Eine Aktion besteht dabei aus folgenden Teilen: Deklaration im Plugin-Manifest IAction Proxy IActionDelegate Während das IAction-Objekt von der Eclipse-Oberfläche instantiiert wird um die Aktion als Stellvertreter (Proxy) zu repräsentieren, also an der gewünschten Stelle in der Oberfläche einzubinden, enthält das IActionDelegate-Objekt die eigentlichen Anweisungen der Aktion. Somit entspricht auch das Aktionskonzept dem im Abschnitt erwähnten Lazy Loading, indem Eclipse die entsprechende IActionDelegate- Klasse erst dann lädt, wenn die Aktion wirklich zum ersten Mal ausgeführt wird, während die Aktion selber aber trotzdem schon angezeigt wird und verfügbar ist. Im Folgenden wird ein prinzipieller Überblick über die möglichen Aktionen in Eclipse gegeben, wobei aus Zuordnungsgründen die originale englische Bezeichnung verwendet wird. Name Workbench Window Actions Object Actions View Actions Editor Actions Beschreibung Aktionen in der Menüleiste und Toolbar Aktionen, die im Kontextmenü nur bei bestimmten Objekten erscheinen Aktionen innerhalb einer View (Kontextmenü, Toolbar, Pulldown-Menü) Aktionen innerhalb des Editors (Kontextmenü, Toolbar, Pulldown-Menü) Tabelle 6: Aktionen in Eclipse 18

30 2 Grundlegende Technologien und Tools Für View- und Editor Actions können optional spezielle Tastenbelegungen konfiguriert werden Weiterführende Themen In den vorhergehenden Abschnitten wurde ein Überblick über elementare Bestandteile der Eclipse-API gegeben, welche aber noch weitaus mehr Möglichkeiten bietet. Im Folgenden werden einige dieser weiterführenden Features kurz vorgestellt. Verfolgen von Änderungen in Ressourcen (Resource Change Tracking) Durch bestimmte Event-Listener besteht die Möglichkeit, auf Änderungen in Java Quellcode-Dateien, Textdateien oder anderen beliebigen Ressourcen zu reagieren und somit Statusänderungen, Aktualisierungen oder weitere Ereignisse auszulösen. Dialoge und Assistenten Über entsprechende SWT-/JFace-Klassen können komfortabel vordefinierte Dialoge (zum Beispiel zum Öffnen und Speichern von Dateien), benutzerdefinierte Dialoge, aber auch über mehrere Konfigurationsschritte führende Assistenten erstellt und in die Plugins eingebunden werden. Einstellungsseiten (Preference Pages) Um für ein Plugin bestimmte Voreinstellungen treffen zu können, ist es möglich, eine eigene Kategorie in das globale Einstellungsmenü von Eclipse (Window Preferences) einzubinden und diese über eine Preference-API beliebig zu gestalten. Eigenschaften (Properties) Die Eigenschaften von benutzerdefinierten Objekten können in Form von Attribut/Wert-Paaren im Properties-View angezeigt und auch optional in einem Eclipseeigenen Metaformat persistent über Sessions gehalten werden. Builder, Markers, Natures Um komplexere Editoren, Designer oder sogar Compiler zu entwickeln, gibt es die sogenannten Builder. Diese fragen regelmäßig Änderungen an den Ressourcen ab, führen Aktualisierungen durch und erstellen schließlich den festgelegten Regeln 19

31 2 Grundlegende Technologien und Tools entsprechende abgeleitete Ressourcen. Diese haben die Besonderheit, dass sie jederzeit wieder durch den Builder generiert werden können und somit nicht in einer Versionsverwaltung gehalten oder in ein Backup-Archiv gepackt werden müssen. Marker signalisieren am linken Rand des Editors zum Beispiel Fehler, Hinweise oder Break Points für den Debugger. Natures weisen einem Projekt besondere Eigenschaften oder Verhaltensweisen der Workbench zu. Die bekannteste Nature ist wohl die Java Nature, die man implizit auswählt, wenn ein neues Java-Projekt angelegt wird. Hilfe Eclipse bietet ein spezielles Framework an, um Hilfe-Dialoge aus HTML-, XHTMLoder PDF-Dokumenten zu erstellen und diese dynamisch an Stellen der Workbench einzubinden. Internationalisierung Um sämtliche Zeichenketten in Dialogen, Views, Menüs und anderen Darstellungselementen in mehreren Sprachen anzubieten, besitzt Eclipse die Möglichkeit, für jede Sprache Properties-Dateien anzulegen, welche die Zeichenketten in der jeweiligen Sprache enthalten. Zur Laufzeit wird dann entsprechend der Nutzereinstellungen entschieden, welche Sprachdatei geladen wird. Features, Branding, Updates Um ein beziehungsweise mehrere fertige Eclipse-Plugins zu vermarkten, kann man ein so genanntes Feature erstellen, über das man die Plugins als eine Einheit komfortabel installieren, einrichten, ihnen ein entsprechendes Firmenzeichen (Branding) geben und sogar eine automatische Aktualisierung über den Eclipse Update Manager durchführen kann. Details zu diesen Themen würden die Grenzen dieses Grundlagenkapitels überschreiten, jedoch werden in Kapitel 5 im Rahmen der Implementierung noch einmal bestimmte Bereiche je nach Verwendung genauer beschrieben. 20

32 3 Analyse und Spezifikationen 3 Analyse und Spezifikation Im vorangegangen Kapitel wurden zunächst grundlegende Technologien zur Nachvollziehbarkeit der Diplomarbeit erörtert. In diesem Kapitel geht es hingegen um konkrete Analyseergebnisse des Ist- und Sollzustands sowie einer abschließenden Untersuchung existierender Modellierungswerkzeuge als Ausgangspunkt für den prototypischen Entwurf am Beispiel von TransConnect. 3.1 Istzustandsanalyse Im Rahmen der Istzustandsanalyse sollen Aspekte des aktuellen Systems aufgezeigt werden, die zum Zeitpunkt der Diplomarbeit entweder bereits vorhanden oder verbesserungswürdig sind beziehungsweise noch komplett fehlen, so dass in der Diplomarbeit eine prototypische Problemlösung entworfen werden kann. Es muss jedoch darauf hingewiesen werden, dass aus technologischen Gründen bei der Istzustandsanalyse eine Unterscheidung zwischen den Komponenten des derzeitig entwickelten TransConnect in der Version und der prototypisch entworfenen Workflow Process Engine [FEKA06], gedacht für TransConnect Version 1.3.6, unterschieden wird. Ist eine klare Trennung nicht möglich, wenn zum Beispiel ein bereits vorhandenes Modul prototypisch neu konzipiert wurde, wird dies an entsprechender Stelle vermerkt TransConnect Die Integrationsplattform für Anwendungsintegration TransConnect wird seit 1998 stetig weiterentwickelt und kann mittlerweile als EAI-Server bezeichnet werden. Die Grundlage bildet dabei ein Adapterkonzept mit Kommunikation über XML-basierte Nachrichten, wie die folgende Abbildung verdeutlicht: 21

33 3 Analyse und Spezifikationen Abbildung 6: Architekturaufbau von TransConnect Im Folgenden werden nun die einzelnen Komponenten von TransConnect [TCHB06] näher beschrieben und auf deren Rolle innerhalb des Gesamtsystems eingegangen. Im Groben setzt sich TransConnect aus den Komponenten Manager Server Datastore zusammen, wobei diese in drei Ebenen eingeordnet werden können: Abbildung 7: 3-Ebenen-Aufbau der Komponenten von TransConnect Der TransConnect Manager befindet sich in der Präsentationsebene und stellt ein auf Sybase Central basierendes Tool zur Konfiguration von TransConnect dar. Sybase Central wird im Normalfall zur grafischen Administration von verschiedenen Sybase- Produkten genutzt, ist aber über ein umfangreiches Software Development Kit (SDK) 22

34 3 Analyse und Spezifikationen mit eigenen Plugins erweiterbar. Das in dieser Diplomarbeit zu entwickelnde Werkzeug zur Prozessmodellierung ist ebenfalls in der Ebene der Präsentation anzusiedeln. Es stellt praktisch eine Neuentwicklung dar, da TransConnect 1.3.5, wie bereits erwähnt, eine XML-basierte Nachrichtenkommunikation aufweist und noch keine Prozesssteuerung im Sinne einer Workflow Engine enthält. Da somit keines der bereits vorhandenen Bestandteile die Grundlage für ein Prozessmodellierungstool darstellt, wird der bisherige Server und Datastore nur kurz erläutert und im nächsten Abschnitt auf die neue prototypische Workflow Process Engine eingegangen. Wie die folgende Abbildung zeigt, setzt sich der TransConnect Server wiederum aus mehreren Modulen zusammen. Abbildung 8: Architektur TransConnect Server Basierend auf einem J2EE Application Server, dem JBoss, verwaltet TransConnect sämtliche Konfigurationen in einem zentralen Metadata Repository, welches über den TransConnect Manager einsehbar und veränderbar ist. Über die verschiedenen Client Interfaces, System Listener oder Inbound Adapter eingehenden, beziehungsweise durch die Zeitsteuerung (Scheduler) generierten Nachrichten gelangen entsprechend ihres Inhalts (Content-based Routing) in den Standard-Workflow, der wahlweise eine synchrone oder asynchrone Verarbeitung zulässt. Im Falle der synchronen Verarbeitung werden die Nachrichten direkt weitergeleitet, jedoch kommt es bei Fehlern zum Stillstand der gesamten Warteschlange (Message Queue). Die asynchrone Verarbeitung lässt über eine oder mehrere Warteschlangen eine parallele Verarbeitung inklusive Prioritätssteuerung zu, wobei die Einhaltung der Reihenfolge der Nachrichten nicht garantiert ist. Im Normalfall erfolgt schließlich eine Nachrichtentransformation 23

35 3 Analyse und Spezifikationen (Mapping) mit XSLT oder STX zwischen dem Format des Quellsystems und dem gewünschten Format des Zielsystems, das über einen entsprechenden Outbound- Adapter angesprochen wird. Das zentrale Modul der Transaktionsverwaltung dient der internen Realisierung von folgenden Zielen: Vermeidung von Datenverlust keine Doppelverarbeitung von Nachrichten Rücksetzbarkeit (Rollback) je nach Verfügbarkeit am Zielsystem Der Transport ist für den Fluss der Nachrichten zwischen Inbound- und Outbound- Adapter innerhalb des Systems zuständig. Dabei werden eingehende Nachrichten zunächst in ein internes Nachrichtenformat umgewandelt, welches aus folgenden Elementen besteht: interne Attribute Nutzdaten als XML-Dokument optional Binärdaten als Anhang (Attachment) Das Persistence-Modul hält diese internen Nachrichten während ihrer Verarbeitung persistent im TransConnect Datastore und greift dabei auf ein relationales Datenbankmanagementsystem (RDBMS) zurück. Nachdem nun der Istzustand von TransConnect dargestellt wurde, soll im Folgenden ein Überblick über die geplante Komponentenarchitektur von TransConnect gegeben werden. 24

36 3 Analyse und Spezifikationen Abbildung 9: Gesamtarchitektur TransConnect Wie aus der Abbildung zu entnehmen ist, bleibt das Grundprinzip vorhanden, jedoch sind im Detail einige Veränderungen erkennbar. Innerhalb der Präsentationsebene werden der TransConnect Manager, das Prozessmodellierungstool (Process Designer) und eine entsprechende Ressourcenverwaltung innerhalb von Eclipse im Rahmen des TransConnect Developer Studios integriert. Die Geschäftslogik und Oberfläche der Webanwendung zur Remote-Administration (TransConnect Console) ist ebenfalls auf dem J2EE Application-Server angesiedelt, der bereits den TransConnect Server beinhaltet. Zusätzlich sind noch eine umfangreiche Testumgebung, ein eigenständiges Installationsprogramm sowie ein Lizenzierungstool Bestandteil von TransConnect Im nächsten Abschnitt wird nun der Prototyp der Workflow Process Engine näher betrachtet Workflow Process Engine Die von Matthias Böhm konzipierte Workflow Process Engine [FEKA06], im Folgenden WFPE genannt, integriert sich in den Server von TransConnect 1.3.6, der nun die nachstehende veränderte Architektur aufweist: 25

37 3 Analyse und Spezifikationen Abbildung 10: Architektur TransConnect Server Vergleicht man den Aufbau des Servers in TransConnect (siehe Abschnitt 3.1.1) mit dem in TransConnect 1.3.6, wird deutlich, dass das Adapterkonzept, die Wartschlangen und die Zeitsteuerung weiterhin vorhanden sind, der Standard-Workflow jedoch komplett durch die WFPE ersetzt und mit dem TP-Monitor eine neue Komponente zur Systemüberwachung eingeführt wurde. Bezüglich des Ablaufs im System werden nun die empfangenen, beziehungsweise zeitgesteuert generierten Nachrichten, nachdem sie in das interne Nachrichtenformat in Form des MTM umgewandelt worden, an den Dispatcher weitergeleitet. Dieser verteilt die Nachrichten entweder synchron direkt an die WFPE oder im asynchronen Fall indirekt an eine oder mehrere Warteschlangen. Letzteres bedeutet im praktischen Sinne, dass jeweils ein neuer Prozess parallel gestartet wird. Die WFPE führt diese durch Beschreibungssprachen definierten Prozesse aus und verwaltet deren Verarbeitung. Das genutzte Konzept ermöglicht auch das Nachladen von Informationen bei der Verarbeitung durch Interaktion mit mehreren Outbound-Adaptern, also nicht nur zur Kommunikation mit einem einzigen Zielsystem. Wie in der oben stehenden Abbildung zu sehen, besteht die WFPE selbst wiederum aus mehreren Teilkomponenten: Core Migrator Process Parser 26

38 3 Analyse und Spezifikationen Service Dictionary Runtime Environment Der zentrale Teil Core definiert und realisiert die Schnittstelle IProcessEngine zur gesamten WFPE und greift dabei auf die anderen Teilkomponenten zu. Abbildung 11: Logischer Aufbau des WFPE-Core Die Teilkomponente Process Parser übernimmt dabei die Umwandlung der durch externe XML-Prozessbeschreibungssprachen beschriebenen Prozesse in das interne Format mittels XSL-Transformationen. Damit ist es möglich, unterschiedliche Prozessbeschreibungssprachen zu verwenden und lediglich für jede Sprache ein zugehöriges Transformationsskript zur Verfügung zu stellen. Nach regel- und kostenbasierter Optimierung wird ein interner Java-Prozessplan nach einer Vorlage (Template) erzeugt und mit Parametern entsprechend der Prozessbeschreibung gefüllt. Schließlich kompiliert der Process Parser den Prozessplan und speichert ihn physisch als Klasse ab. Neue Objekte des Prozessplanes können nun zur Laufzeit durch einfache Objektinstantiierung erzeugt und als Thread gestartet werden, wenn diese Klasse einmal in die JVM geladen wurde. Die folgende Abbildung verdeutlicht noch einmal das Prinzip des Parsers. 27

39 3 Analyse und Spezifikationen Abbildung 12: Arbeitsschritte des Process Parsers Die Teilkomponente Migrator ist für die Überführung von Metadaten-Repositories älterer TransConnect -Versionen in die neue Version zuständig. Damit ist es möglich, früher definierte Routing- und Adapterkonfigurationen in der neuen Prozesssteuerung wieder zu verwenden. Abbildung 13: Aufbau Migrator Sämtliche Dienste innerhalb von TransConnect werden im Service Dictionary als eine Art vorkonfiguriertes Objekt mit allen Einstellungen gehalten, um eine flexible und dynamische Nutzung direkt aus dem Workflow heraus zu gewährleisten. Dabei ist 28

40 3 Analyse und Spezifikationen besonders die Funktionalität des WSDL Generators zu beachten, der für alle im Service Dictionary enthaltenen Dienste entsprechende WSDL-Dokumente generieren kann. Dies ist nötig, um Dienste von TransConnect bei der Modellierung von Workflows mit dem angestrebten Prozessmodellierungstool einbinden zu können. In der folgenden Abbildung wird noch einmal der Aufbau des Service Dictionary im Überblick dargestellt. Abbildung 14: Aufbau Service Dictionary Die vierte Komponente der WFPE, das Runtime Environment, stellt letztendlich die Ausführungsumgebung einzelner Prozesspläne dar und implementiert die einzelnen Muster beziehungsweise Operatoren des MTM. Der so genannte Process Manager erstellt für jeden instantiierten Prozessplan, ausgelöst entweder durch Inbound-Adapter oder zeitgesteuerte Ereignisse, einen entsprechenden Process Container und organisiert die Ressourcenverwaltung, Thread- und Prioritätssteuerung. 29

41 3 Analyse und Spezifikationen Abbildung 15: Aufbau des Runtime Environment Ein solcher Process Container enthält, wie in der vorangestellten Abbildung zu sehen, das Objekt des Prozessplans selbst sowie sämtliche Instanzen. Sobald eine bestimmte Aufgabe den jeweiligen Prozessplan benötigt, übergibt der Process Container den Prozessplan an den laufenden Worker-Thread. Dieser Ablauf kann jederzeit wiederholt werden, selbst wenn die vorhergehende Aufgabe noch nicht erledigt ist. Zusammen mit der Prioritätssteuerung ist dieser Aspekt sehr wichtig für die Gesamtperformance von TransConnect Nachdem nun in den bisherigen Abschnitten dieses Unterkapitels der Umfang von TransConnect sowie die Architekturkomponenten von TransConnect untersucht wurden, sollen im folgenden Abschnitt noch einmal gesondert sowohl die Defizite der aktuellen Version als auch fehlende Realisierungsaspekte von TransConnect im Hinblick auf die im Unterkapitel 3.2 aufgeführten Anforderungen an den Sollzustand hervorgehoben werden. 30

42 3 Analyse und Spezifikationen Defizite In diesem Abschnitt werden die Defizite von TransConnect beziehungsweise dem Prototyp von TransConnect noch einmal im Überblick dargestellt, um die Entwicklung eines Prozessmodellierungstools sowie eines Developer Studios zu rechtfertigen. TransConnect Prototyp TransConnect fehlende Visualisierung beziehungsweise grafische Modellierung des Routings von internen Prozessen unzureichende Möglichkeiten des Monitorings am laufenden System keine übersichtliche und komfortable Verwaltung aller benötigten Ressourcen Workflow Engine und konzeptionelles Prozessmodell vorhanden, jedoch Werkzeug zur Modellierung der Prozesspläne noch nicht implementiert Monitoring zwar über Schnittstellen vorgesehen (offene Parser-Architektur), aber bislang nicht realisiert - (keine Veränderung) Tabelle 7: Gegenüberstellung der Defizite Wie der Tabelle zu entnehmen ist, wurde im Prototyp von TransConnect mit dem Entwurf der WFPE und dem MTM zwar die technische Grundlage für die grafische Modellierung von Prozessplänen geschaffen, jedoch fehlt bisher immer noch ein entsprechendes Modellierungswerkzeug. Ein Developer Studio mit Ressourcenverwaltung und Monitoring wäre generell eine Neuentwicklung. Im Rahmen einer abschließenden Bewertung des Istzustands lässt sich sagen, dass die konzeptuellen Modelle des MTM sowie die prototypische Workflow-Engine im aktuellen Stand bereits eine qualitativ hochwertige Implementierung einer Prozesssteuerung von TransConnect darstellen. Jedoch muss die Abweichung vom BPEL-Standard in Bezug auf die einzelnen Muster, respektive Aktivitäten des MTM aus Gründen der Vereinfachung und Erweiterung (siehe Kapitel 4) kritisch hinterfragt werden, obwohl bereits eine WSBPEL-Repräsentation des MTM mit entsprechendem Transformator existiert. Auch wenn ein Prozessmodellierungswerkzeug innerhalb dieser Diplomarbeit an die Spezifikation des MTM angepasst werden kann, sind die damit 31

43 3 Analyse und Spezifikationen erzeugten Prozessbeschreibungen hinsichtlich der erweiterten Aktivitäten nicht kompatibel mit anderen Designern oder Tools, die nur die standardkonformen Elemente kennen. Ein Vorschlag zur Verbesserung dieses Sachverhalts wird im Rahmen des Ausblicks in Kapitel 6 unterbreitet. 3.2 Untersuchung der Anforderungen an den Sollzustand Nachdem im letzten Abschnitt die Defizite des Istzustands benannt wurden und somit sowohl die Entwicklung eines Prozessdesigners als auch einer Ressourcenverwaltung gerechtfertig ist, soll nun auf die konkreten Anforderungen eingegangen werden, wobei zwischen funktionalen und nicht-funktionalen Anforderungen unterschieden wird Funktionale Anforderungen Die in diesem Abschnitt definierten Anforderungen beschreiben die grundsätzlichen Aufgaben und Aktionen, die das Produkt besitzen soll [REQU06]. Dabei wird noch einmal in Muss- und Kann-Anforderungen unterteilt, um den einzelnen Aspekten eine Priorität zuzuordnen. Das bereits erwähnte zukünftige Developer Studio beinhaltet im Allgemeinen vier Hauptkomponenten: Konfiguration der Instanzen vom TransConnect -Server Prozessmodellierung Projekt- und Ressourcenverwaltung Monitoring Die Konfiguration der Server-Instanzen von TransConnect soll außer über die Administrationsoberfläche (TransConnect Console) auch innerhalb des Developer Studios möglich sein, ist jedoch nicht Bestandteil dieser Diplomarbeit. Folgende funktionale Anforderungen beziehen sich auf die Bestandteile des Prozessmodellierungswerkzeugs. 32

44 3 Analyse und Spezifikationen Anforderung Muss Bedingung Grafische Modellierung und Visualisierung von Prozessplänen Beschreibung und Generierung von internen Prozessvorschriften unter Nutzung des Message Transformation Models (MTM) Unabhängigkeit von der Hardware-Plattform und dem verwendeten Betriebssystem Realisierung als Eclipse-Plugin Erweiterbarkeit um zusätzliche Muster beziehungsweise Komponenten Unidirektionale Schnittstelle zur Ressourcenverwaltung Kann Bidirektionale Schnittstelle zur Monitoringkomponente Bidirektionale Schnittstelle zur Transformationskomponente Alternative Beschreibung und Generierung von Prozessplänen unter Nutzung einer standardisierten Prozessbeschreibungssprache (zum Beispiel WSBPEL 2.0) Maßnahmen zur Qualitätssicherung (Tests) Tabelle 8: Funktionale Anforderungen an das Prozessmodellierungswerkzeug Als allgemeine und übergeordnete Aufgabe hat das Prozessmodellierungstool die grafische Modellierung und Visualisierung von Prozessplänen, unabhängig von einer Beschreibungssprache. Diese modellierten Prozesspläne sollen dann intern mit Hilfe des MTM beschrieben und generiert werden, so dass eine Nutzung direkt an der WFPE möglich ist. Um dieses Ziel zu erreichen, muss das Modellierungswerkzeug eine Einwegschnittstelle zur Ressourcenverwaltung besitzen, über die schließlich der Transport zum Server erfolgt. Zur praktischen Integration in eine bereits vorhandene Entwicklungsumgebung ist das Tool als Eclipse-Plugin plattform- und betriebssystemunabhängig zu realisieren. Darüber hinaus sollte die Architektur so gestaltet sein, dass beliebige Muster jederzeit ergänzt beziehungsweise neue Komponenten über definierte Schnittstellen angebunden werden können. Optional kann das Prozessmodellierungstool bidirektionale Schnittstellen zur Monitoringkomponente sowie zur Transformationskomponente der WFPE besitzen, um alternativ auch Prozesspläne mit einer standardisierten Prozessbeschreibungssprache 33

45 3 Analyse und Spezifikationen wie WSBPEL 2.0 zu generieren. Denkbar wären auch automatisierte Testumgebungen, um die fehlerfreie Funktionalität des Plugins bei Anpassungen überprüfen zu können. Die Projektverwaltung und das Ressourcenmanagement im zukünftigen Developer Studio besitzen ebenfalls eigene funktionale Anforderungen, welche wie folgt benannt werden können. Anforderung Muss Bedingung Erstellung eines TransConnect -Szenarios (Projekt) Möglichkeit der Offline-Verwaltung ohne Serververbindung Anlegen und Herstellen von Verbindungen zu TransConnect - Servern Definition von XML-Formaten und Strukturen zur persistenten Abbildung der TransConnect -Ressourcen Bearbeiten der Ressourcen in geeigneten Editoren oder Assistenten Kann Client-Schnittstelle zu einer Versionsverwaltung Maßnahmen zur Transportsicherheit Tabelle 9: Funktionale Anforderungen an die Ressourcenverwaltung Im Rahmen der Ressourcenverwaltung muss der Nutzer die Möglichkeit haben, ein neues TransConnect -Projekt zu erstellen und in diesem in einer vordefinierten Struktur die benötigten Ressourcen anzulegen. Das Bearbeiten dieser Ressourcen in Editoren und Assistenten muss ohne Serververbindung (offline) möglich sein, weshalb sämtliche Ressourcen in XML-Dateien mit definiertem Format persistiert werden. Zum Transport des Projekts zu einem TransConnect -Server oder beim Ausführen spezieller Aktionen muss eine entsprechende Serververbindung aufgebaut werden. Als Kann-Anforderung ist die Integrierung einer Client-Schnittstelle zu einer Versionsverwaltung zu benennen, um die angelegten Projekte zentral zu lagern sowie eventuelle Maßnahmen zur Transportsicherheit der Daten, welche jedoch noch nicht näher definiert wurden. Die nachstehende Tabelle enthält die funktionalen Anforderungen an die Monitoringkomponente. 34

46 3 Analyse und Spezifikationen Anforderung Muss Bedingung Statistische Analyse und Laufzeit-Monitoring des Servers Statistische Analyse einzelner ausgewählter Prozesse Grafische Auswertung der ermittelten Daten Kann Laufzeit-Debugging im Fehlerfall Tabelle 10: Funktionale Anforderungen an die Monitoring-Komponente Die Muss-Anforderungen gliedern sich im Wesentlichen in drei Bereiche. Es muss möglich sein, eine statistische Analyse des Servers im Hinblick auf Hardware- Ressourcen (Speichernutzung, CPU-Auslastung) und Software-Ressourcen (Warteschlangen-Auslastung, Nachrichten im System) vorzunehmen. Weiterhin sollen einzelne Prozesse mit statistischen Daten hinterlegt werden, wie zum Beispiel die Häufigkeit der Prozessverwendung oder der Nutzung eines bestimmten Zweiges in einem Kontrollflusselement. In Zukunft ist optional das Debugging zur Laufzeit denkbar, bei dem im Fehlerfall Schritt für Schritt am betroffenen Prozess nachvollzogen werden kann, an welcher Stelle es zum Abbruch kam. Sämtliche ermittelte Daten müssen entweder direkt in dem betroffenen Prozessplan oder in einer dafür vorgesehenen grafischen Oberfläche visualisiert werden Nicht-Funktionale Anforderungen Im Gegensatz zu den funktionalen Anforderungen beschreiben die nicht-funktionalen Anforderungen bestimmte Eigenschaften des Produkts, die das gewünschte Verhalten der Funktionalitäten näher beschreiben [REQU06]. Im Folgenden werden diese geforderten Eigenschaften für das Prozessmodellierungstool, die Ressourcenverwaltung und das Monitoring genannt und kurz erläutert. Anforderung Ergonomie Kompatibilität Beschreibung Aspekte der Benutzerfreundlichkeit wie Anordnung der Schaltflächen, Menüs und Darstellungselemente Unterstützung des Imports und Exports von Prozessbeschreibungen alternativer Modellierungswerkzeuge 35

47 3 Analyse und Spezifikationen Anforderung Portierbarkeit Robustheit Performance Skalierbarkeit Tabelle 11: Beschreibung Unabhängigkeit vom Betriebssystem und von einem möglicherweise vorhandenen Designer im Falle der Erweiterung Entsprechende Fehlerbehandlung im Falle nicht sachgemäßer Bedienung Einschätzung des Laufzeitverhaltens in Bezug auf Leistungsfähigkeit und Verarbeitungsgeschwindigkeit Einschätzung der Performance bei steigenden Eingabemengen, hier aber auch: Anpassungsaufwand bei Änderung der Anforderungen Nicht-Funktionale Anforderungen 3.3 Untersuchung existierender Modellierungswerkzeuge Zur Entscheidungsfindung, ob ein bereits auf dem Markt vorhandenes Modellierungswerkzeug als Erweiterungsgrundlage genutzt werden kann, wird nun zum Abschluss der Analyse ein Produktvergleich mit definierten Bewertungskriterien durchgeführt und am Ende die Einsetzbarkeit der untersuchten Produkte eingeschätzt Bewertungskriterien Im Folgenden werden vorbereitend für den Produktvergleich einige Bewertungskriterien festgelegt, wobei für die Vorauswahl der hier verglichenen Produkte folgende Gemeinsamkeiten vorhanden sein mussten: Eclipse-Plugin kein kommerzielles, respektive kostenpflichtiges Produkt Durch die Forderung, dass es sich um ein Eclipse-Plugin handeln muss, wird indirekt die nicht-funktionale Anforderung nach der Portierbarkeit erfüllt, da die Entwicklungsumgebung Eclipse für viele unterschiedliche Plattformen zur Verfügung steht und somit die Plugins ebenfalls lauffähig bleiben. Voraussetzung dafür ist, dass das Eclipse-Plugin keine betriebssystemspezifischen Bibliotheken über das Java Native Interface (JNI) anspricht. Wie in den Anforderungen an den Sollzustand im Unterkapitel 36

48 3 Analyse und Spezifikationen 3.2 beschrieben, ist die Veränderung beziehungsweise Erweiterung eines existierenden Modellierungswerkzeugs unumgänglich, um es an die Bedürfnisse von TransConnect und dem MTM anzupassen. Aus diesem Grund wurden in den Produktvergleich generell keine kostenpflichtigen Produkte aufgenommen, da diese die nötigen Anpassungen im Normalfall nicht zulassen. Um eine Bewertung aus möglichst verschiedenen Perspektiven zu gewährleisten, werden die folgenden Kriteriengruppen festgelegt: Oberflächenkriterien Funktionale Kriterien Qualitätskriterien Die Gruppe der Oberflächenkriterien fasst dabei sämtliche Kriterien zusammen, die sich mit der Ergonomie und den Bedienmöglichkeiten der Oberfläche befassen. Funktionale Kriterien können auch als Features verstanden werden und spiegeln die einzelnen Möglichkeiten der Produkte hinsichtlich ihrer Verwendung wieder. Die Qualitätskriterien schließen alle weiteren noch nicht benannten nicht-funktionalen Kriterien ein. Die nachstehende Tabelle gibt einen Überblick über die einzelnen Bewertungskriterien in ihren Gruppen mit einer entsprechenden Beschreibung beziehungsweise den Bewertungsmöglichkeiten. Zusätzlich wurden sowohl eine Gewichtung der einzelnen Kriterien von 1 (unwichtig) bis 10 (sehr wichtig) als auch Bewertungspunkte auf einer Skala von 1 (sehr schlecht) bis 6 (sehr gut) eingeführt, um innerhalb der Auswertung eine objektive Entscheidung treffen zu können. Dabei drückt eine niedrige Gewichtung nicht zwingend die Vernachlässigung des Kriteriums aus, sondern ist in diesem Fall eine Nachbesserung im Rahmen der Erweiterung oft leicht möglich. 37

49 3 Analyse und Spezifikationen Gruppe Kriterium Beschreibung Gewichtung Oberflächenkriterien Ergonomie Benutzerfreundlichkeit der Oberfläche 7 Grafische Darstellung Aufwändigkeit der Präsentation 5 Elementeigenschaften Umfang der Einstellungsmöglichkeiten für jedes Darstellungselement 3 Funktionale Kriterien Notation Art der Notation (BPEL BPMN alternativ) 8 Modellierungsmöglichkeiten Modellierung der Basisaktivitäten wie Invoke, Receive, Switch oder Subworkflows 8 Validierung Überprüfung der syntaktischen Korrektheit der modellierten Prozesspläne 5 Prozessplangenerierung In welcher Form werden die modellierten Prozesspläne generiert? 5 Import/Export Existenz einer Schnittstelle zum Austausch von Prozessbeschreibungen 6 Erweiterbarkeit Ist funktionale Erweiterung oder Anpassung mit akzeptablem Aufwand möglich? 10 Qualitätskriterien Performance Einschätzung des Laufzeitverhaltens in Bezug auf Leistungsfähigkeit und Verarbeitungsgeschwindigkeit 6 Robustheit Einschätzung der Fehlertoleranz bei unsachgemäßer Verwendung 5 Tabelle 12: Bewertungskriterien 38

50 3 Analyse und Spezifikationen Produktvergleich Im Folgenden werden die untersuchten existierenden Modellierungswerkzeuge zunächst einzeln kurz vorgestellt und anschließend tabellarisch zum Vergleich detailliert gegenübergestellt. Dabei muss jedoch noch einmal im Hinblick auf die in Unterkapitel 3.2 definierten Anforderungen an den Sollzustand darauf hingewiesen werden, dass es das Ziel dieses Produktvergleichs ist, ein vorhandenes Modellierungswerkzeug zur Erweiterung beziehungsweise Anpassung zu finden. Keines der auf dem Markt befindlichen Produkte wird die definierten Anforderungen vollständig erfüllen. Es geht also lediglich darum, welches Modellierungstool den Anforderungen am ehesten gerecht wird beziehungsweise sich entsprechend flexibel anpassen lässt. Eclipse BPEL Project Der von der Eclipse Foundation seit Anfang 2006 als Open-Source-Projekt entwickelte BPEL Designer [ECLBP07] stellt ein Plugin für die Entwicklungsumgebung Eclipse dar, welches diese um entsprechende BPEL-Funktionalitäten erweitert. Somit ist es möglich, mit der Designerkomponente grafische Prozesspläne in der WSBPEL-2.0- Notation zu modellieren sowie in Zukunft eine umfangreiche Validierung durchzuführen. Schließlich soll es mit einem Runtime Framework möglich sein, die erstellten Prozesspläne auszuführen und zur Laufzeit auf Fehler zu überprüfen. Zu Beginn der Diplomarbeit befand sich das Projekt noch in einem sehr frühen Stadium (Version vom Dezember 2006), in dem die Komponenten Validierung, Runtime Framework und Debugging noch nicht implementiert waren. Mittlerweile beinhaltet die Version M3 (August 2007) eine Validierung im Rahmen von WSPEL-2.0. Das BPEL Project stellt demnach einen funktionsstarken Designer inklusive Prozessplan- Generierung dar, der grafisch sehr ansprechend und auf Grund des offenen Quellcodes beliebig erweiterbar ist. 39

51 3 Analyse und Spezifikationen Pro WSBPEL-2.0 Notation übersichtliche Oberfläche grafisch anspruchsvoll gut erweiterbar Validierung Contra keine Ausführungsumgebung kein Debugging Abbildung 16: Einschätzung Eclipse BPEL Project Abbildung 17: Screenshot Eclipse BPEL Project IX Workflow Modeler Der IX Workflow Modeler [IXWFM07] der Imixs Software Solutions GmbH ist ein Werkzeug zur grafischen Modellierung von allgemeinen Workflows ohne Festlegung auf eine bestimmte standardisierte Notation. Dabei steht generell eine Modellierung unabhängig von der Anwendungslogik ohne Ausführung und Validierung im Vordergrund. Der Umfang der zur Verfügung stehenden Elemente beschränkt sich auf die Knoten Process und Activity sowie deren Verbindung. Da es sich auch hier um ein 40

52 3 Analyse und Spezifikationen Quellcode-offenes Projekt handelt, ist es hinsichtlich Funktionalität und Darstellung ebenfalls erweiterbar. Jedoch stellt sich die vorhandene Oberfläche im Vergleich zu anderen Tools zwar als übersichtlich, aber nicht sehr komfortabel heraus. Pro übersichtliche Oberfläche gut erweiterbar Contra keine standardisierte Modellierung keine Ausführungsumgebung kein Debugging geringer Funktionsumfang Abbildung 18: Bewertung IX Workflow Modeler Abbildung 19: Screenshot IX Workflow Modeler 41

53 3 Analyse und Spezifikationen JOpera Das Eclipse-Plugin JOpera [JOPER07] wurde von der ETH Zürich entwickelt und stellt ein Tool zur grafischen Komposition von Services dar, das auch zur Modellierung von Workflows genutzt werden kann. Auch hier ist die Modellierung an keinen Standard gebunden, da ein eigenes XML-Format zur formalen Beschreibung der Workflows genutzt wird. Zwar bietet JOpera Laufzeit-Monitoring und Debugging, besitzt aber eine unübersichtliche, wenig intuitive Benutzeroberfläche und weist an einigen Stellen Laufzeitfehler auf. Da der Quellcode von JOpera leider nicht offen verfügbar ist, können die nötigen umfangreichen Änderungen zur Anpassung an TransConnect und Erreichung der gestellten Anforderungen nicht durchgeführt werden. Pro Monitoring- und Debugging Contra keine standardisierte Modellierung unkomfortable Oberfläche Quellcode nicht offen Fehleranfälligkeit Abbildung 20: Bewertung JOpera 42

54 3 Analyse und Spezifikationen Abbildung 21: Screenshot JOpera Intalio BPMS Designer Der von Intalio stammende BPMS Designer ist ein umfangreiches, auf dem Eclipse- Framework basierendes, eigenständiges Tool zur Modellierung von Workflows in der standardisierten Business Process Modeling Notation (BPMN) [BPMN06]. Die Oberfläche ist sehr übersichtlich aufgebaut (Palette, Eigenschaften, Problemanzeige) und ermöglicht somit eine komfortable Bedienung. Bezüglich der formalen Prozessbeschreibung nutzt der Designer ein eigenes Binärformat, weshalb an dieser Stelle umfangreiche Änderungen nötig wären. Intalio nutzt nur Vermarktung seines Designers drei Modelle. Die Open Source Edition [INTOS07] wird im Rahmen der Eclipse Foundation seit Januar 2007 entwickelt und ist demzufolge frei erweiterbar. Weiterhin existieren noch die frei verfügbare Community Edition [INTCE07] zum nichtkommerziellen Einsatz und die Enterprise Edition [INTCE07] mit kommerzieller Unterstützung. 43

55 3 Analyse und Spezifikationen Pro Modellierung mittels BPMN komfortable Bedienung Validierung offener Quellcode (Open Source Edition) Contra eigenes Binärformat Abbildung 22: Bewertung Intalio BPMS Designer Abbildung 23: Screenshot Intalio BPMS Designer 44

56 3 Analyse und Spezifikationen ActiveBPEL Designer Der ActiveBPEL Designer [ACTBP07] von Active Endpoints ist das komplexeste von den getesteten Werkzeugen in diesem Produktvergleich. Es bietet neben der grafisch sehr ansprechenden Modellierungskomponente sogar eine Echtzeitsimulation der erstellten Prozesspläne inklusive Debugging, gut lesbar generierte WSBPEL-2.0- Prozesspläne und ausführliche Statistik-Informationen. Die Oberfläche ist ähnlich wie beim Eclipse BPEL Project sehr intuitiv und grafisch ansprechend gestaltet. Zusammen mit der ebenfalls erhältlichen ActiveBPEL-Engine lassen sich die modellierten Prozesspläne direkt veröffentlichen und ausführen. Leider ist der Quellcode des Designers selbst nicht frei zugänglich und die Generierung beziehungsweise Modellierung somit nicht an die Bedürfnisse von TransConnect anpassbar. Pro WSBPEL-2.0 Notation komfortable Bedienung grafisch anspruchsvoll Validierung, Simulation und Debugging Ausführungsumgebung Contra Quellcode nicht offen Abbildung 24: Bewertung ActiveBPEL Designer 45