fachbereich informatik/mathematik - htw-dresden.dewloka/pubs/da_winter.pdfhochschule für technik...
TRANSCRIPT
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: 15.10.2007
Betreuer: Prof. Dr. rer. oec. habil. Uwe Wloka (HTW-Dresden)
Dipl.-Wirt.-Inf. (FH) Torsten Uhr (SQL-GmbH)
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Inhaltsverzeichnis ............................................................................................................ I
Glossar ........................................................................................................................... III
Abbildungsverzeichnis ................................................................................................. VI
Tabellenverzeichnis ................................................................................................... VIII
Abkürzungsverzeichnis ............................................................................................... IX
1 Einleitung ................................................................................................................. 1
1.1 Ausgangssituation und Motivation ................................................................ 1
1.2 Zielstellungen ................................................................................................ 2
1.3 Aufbau der Diplomarbeit .............................................................................. 3
2 Grundlegende Technologien ................................................................................... 5
2.1 Business Process Execution Language (BPEL) ............................................ 5
2.1.1 Einordnung ........................................................................................ 5 2.1.2 Sprachbestandteile............................................................................. 6
2.1.3 Bewertung ....................................................................................... 10
2.2 Nachrichtentransformationsmodell ............................................................. 11
2.2.1 Konzeptuelles Nachrichtenmodell .................................................. 11 2.2.2 Konzeptuelles Prozessmodell.......................................................... 12
2.3 Grundlagen der Eclipse-Plugin-Entwicklung .............................................. 14
2.3.1 Infrastruktur von Eclipse ................................................................. 14
2.3.2 Darstellungselemente ...................................................................... 17 2.3.3 Aktionen .......................................................................................... 18 2.3.4 Weiterführende Themen.................................................................. 19
3 Analyse und Spezifikation .................................................................................... 21
3.1 Istzustandsanalyse ....................................................................................... 21
3.1.1 TransConnect®
................................................................................ 21 3.1.2 Workflow Process Engine ............................................................... 25 3.1.3 Defizite ............................................................................................ 31
3.2 Untersuchung der Anforderungen an den Sollzustand ................................ 32
3.2.1 Funktionale Anforderungen ............................................................ 32 3.2.2 Nicht-Funktionale Anforderungen .................................................. 35
3.3 Untersuchung existierender Modellierungswerkzeuge ............................... 36
3.3.1 Bewertungskriterien ........................................................................ 36 3.3.2 Produktvergleich ............................................................................. 39 3.3.3 Bewertung der Einsetzbarkeit ......................................................... 46
3.4 Verwandte Arbeiten .................................................................................... 49
Inhaltsverzeichnis
II
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect®
... 52
4.1 Architekturentwurf des Prozessmodellierungstools .................................... 52
4.1.1 Struktur und Aufbau ........................................................................ 53 4.1.2 Anpassung der Aktivitäten .............................................................. 58
4.2 Projekt- und Ressourcenverwaltung ............................................................ 62
4.2.1 Remoteverwaltungsansatz über Vermittler ..................................... 64
4.2.2 Remoteverwaltungsansatz über Direktzugriff................................. 66 4.2.3 Lokalverwaltungsansatz .................................................................. 67 4.2.4 Entwurfsentscheidung und konzeptuelle Architektur ..................... 68
4.3 Beschreibung der Schnittstelle zu TransConnect®
...................................... 70
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung am
Beispiel der Translation-Aktivität ....................................................................... 74
5.1 Allgemeine Vorgehensweise zur Erweiterung des Designers ..................... 74
5.2 Import von externen Transformationsbeschreibungen ................................ 77
6 Zusammenfassung und Ausblick ......................................................................... 81
6.1 Ergebnisse und Schlussfolgerungen ............................................................ 81
6.2 Ausblick ...................................................................................................... 83
Anhang ........................................................................................................................... 84
A Metagrammatik der generierten Prozessbeschreibung ................................ 84
B Komplexbeispiel „Bestellabwicklung“ ....................................................... 87
C Inhaltliche Struktur der beiliegenden CD-ROM ......................................... 96
Literaturverzeichnis ...................................................................................................... 97
Erklärungen ................................................................................................................. 100
Glossar
III
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 Auswahl-
mö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
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.
Integration
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.
Interface Schnittstelle zur Kommunikation zwischen verschiedenen
Komponenten eines Softwaresystems über definierte
Routinen.
Komposition Zusammensetzung eines Dienstes aus mehreren bestehenden
Diensten mit einer Prozessbeschreibungssprache.
Lazy Loading Beschreibt den Prozess des dynamischen Ladens von
Ressourcen zur Laufzeit bei erstmaliger Verwendung.
Listener Ereignisbehandlungsroutine, die dann ausgeführt wird, wenn
ein bestimmtes Ereignis eintritt.
Glossar
IV
Message
Transformation
Model
Das MTM ist ein konzeptuelles, graphenorientiertes Modell
zur Beschreibung von Transformationsprozessen der
komplexen Nachrichtentransformation und gliedert sich in
ein Nachrichtenmodell und ein Prozessmodell.
Meta-Informationen Bezeichnung für Daten, die Informationen über andere Daten
enthalten und diese mit Hilfe ausgewählter Eigenschaften
beschreiben.
Monitoring Sammelbegriff für die Überwachung eines Vorgangs oder
Prozesses mit technischen Hilfsmitteln über einen
bestimmten Zeitraum.
Nachrichten-
transformation
Beschreibt die Transformation von Nachrichten als
Spezialfall der Datentransformation, wobei zwischen
elementarer (syntaktische Transformationen) und komplexer
(semantische Transformationen als Folge von Prozess-
schritten) Nachrichtentransformation unterschieden werden
muss.
Orchestrierung Art der Komposition, wobei die zentrale Interaktion von
dezentralen Diensten mit einer direkt oder indirekt
ausführbaren Prozessbeschreibungssprache aus einer lokalen
Sicht beschrieben wird.
Parser Computerprogramm zur Zerlegung eines Eingabedokuments
in einzelne Bestandteile, die einem bestimmten gewünschten
Format entsprechen.
Persistenz Bezeichnet die Speicherung von Daten oder Objekten in
nicht-flüchtigen Speichermedien wie Dateisysteme oder
Datenbanken.
Plugin Bezeichnet ein weitgehend eigenständiges Computer-
programm, 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.
Glossar
V
Prozessbeschrei-
bungssprache
Eine derartige Sprache kann als Metamodell zur
Beschreibung von teilweise automatisierten Geschäfts-
prozessen in Form einer Folge von Prozessschritten
verstanden werden. Typische Ausprägungen solcher
Sprachen sind grafische Ausdrucksformen oder XML-
Schemata.
Ressource Betriebsmittel, das benötigt wird, um eine bestimmte
Aufgabe zu erreichen.
Hier: Bestandteil von TransConnect® wie Adapter,
Warteschlange, Workflow, Zeitgesteuerte Aufgabe oder
Nachrichtentyp.
Routing Bezeichnet im Allgemeinen das Festlegen von Wegen für
Nachrichtenströme über definierte Regeln.
Serialisierung 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 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.
Widget 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.
Abbildungsverzeichnis
VI
Abbildungsverzeichnis
Abbildung 1: Adaptierte 3-Schichten-Architektur .................................................... 11 Abbildung 2: Logischer Aufbau des konzeptuellen Nachrichtenmodells ................. 12 Abbildung 3: Grundmodell eines gerichteten Graphen ............................................. 13
Abbildung 4: Knotentypen eines Prozesses .............................................................. 13 Abbildung 5: Architekturaufbau Eclipse ................................................................... 15 Abbildung 6: Architekturaufbau von TransConnect
® ............................................... 22
Abbildung 7: 3-Ebenen-Aufbau der Komponenten von TransConnect®
.................. 22 Abbildung 8: Architektur TransConnect
® 1.3.5 Server ........................................... 23
Abbildung 9: Gesamtarchitektur TransConnect® 1.3.6 ............................................. 25
Abbildung 10: Architektur TransConnect® 1.3.6 Server ............................................ 26
Abbildung 11: Logischer Aufbau des WFPE-Core ..................................................... 27
Abbildung 12: Arbeitsschritte des Process Parsers ..................................................... 28 Abbildung 13: Aufbau Migrator.................................................................................. 28 Abbildung 14: Aufbau Service Dictionary .................................................................. 29
Abbildung 15: Aufbau des Runtime Environment ...................................................... 30 Abbildung 16: Einschätzung Eclipse BPEL Project ................................................... 40 Abbildung 17: Screenshot Eclipse BPEL Project ....................................................... 40
Abbildung 18: Bewertung IX Workflow Modeler ...................................................... 41 Abbildung 19: Screenshot IX Workflow Modeler ...................................................... 41
Abbildung 20: Bewertung JOpera ............................................................................... 42 Abbildung 21: Screenshot JOpera ............................................................................... 43 Abbildung 22: Bewertung Intalio BPMS Designer ..................................................... 44
Abbildung 23: Screenshot Intalio BPMS Designer ..................................................... 44 Abbildung 24: Bewertung ActiveBPEL Designer ...................................................... 45
Abbildung 25: Screenshot ActiveBPEL Designer ...................................................... 46 Abbildung 26: Ergebnis des Produktvergleichs .......................................................... 48
Abbildung 27: Gesamtarchitektur Eclipse BPEL Project ........................................... 54
Abbildung 28: Untersuchung der Lese- und Schreibperformance .............................. 56 Abbildung 29: Aufbau Plugin-Komponente „model“ ................................................. 57 Abbildung 30: Aufbau Plugin-Komponente „ui“ ........................................................ 58 Abbildung 31: TransConnect
® Beispielszenarien ....................................................... 62
Abbildung 32: Schema Remoteverwaltungsansatz über Vermittler ........................... 65
Abbildung 33: Schema Remoteverwaltungsansatz über Direktzugriff ....................... 66 Abbildung 34: Schema Lokalverwaltungsansatz ........................................................ 67 Abbildung 35: Ordnerstruktur Ressourcenverwaltung................................................ 69 Abbildung 36: Schnittstellen TransConnect
® 1.3.6 Server ......................................... 71
Abbildung 37: Schnittstelle Process Designer ........................................................... 72
Abbildung 38: Schnittstelle Ressourcenverwaltung.................................................... 73
Abbildung 39: Ecore-Model der Translation-Aktivität ............................................... 74
Abbildung 40: UML-Klassendiagramm der Translation-Aktivität ............................. 75 Abbildung 41: Extension für Schaltfläche der Translation-Aktivität ......................... 75 Abbildung 42: Extension für Aktion der Translation-Aktivität .................................. 76 Abbildung 43: Extension für Eigenschaftenseite der Translation-Aktivität ............... 77 Abbildung 44: Screenshot Eigenschaftenseite der Translation-Aktivität ................... 77 Abbildung 45: UML-Klassendiagramm der Transformation-Schnittstelle................. 79
Abbildungsverzeichnis
VII
Abbildung 46: Screenshot Auswahldialog Transformationbeschreibung ................... 80
Abbildung 47: Beispielprozess „Bestellabwicklung“ ................................................. 87
Tabellenverzeichnis
VIII
Tabellenverzeichnis
Tabelle 1: Notation der Metagrammatik .................................................................... 6 Tabelle 2: Allgemeine Sprachbestandteile von WSBPEL-2.0 ................................... 8 Tabelle 3: Grundlegende Aktivitäten von WSBPEL-2.0 ........................................... 9
Tabelle 4: Strukturierte Aktivitäten von WSBPEL-2.0 ............................................. 9 Tabelle 5: Transaktionsaktivitäten von WSBPEL-2.0 ............................................. 10 Tabelle 6: Aktionen in Eclipse ................................................................................. 18 Tabelle 7: Gegenüberstellung der Defizite............................................................... 31 Tabelle 8: Funktionale Anforderungen an das Prozessmodellierungswerkzeug ..... 33
Tabelle 9: Funktionale Anforderungen an die Ressourcenverwaltung .................... 34 Tabelle 10: Funktionale Anforderungen an die Monitoring-Komponente ................ 35 Tabelle 11: Nicht-Funktionale Anforderungen .......................................................... 36
Tabelle 12: Bewertungskriterien ................................................................................ 38 Tabelle 13: Produktvergleich Modellierungswerkzeuge............................................ 47 Tabelle 14: Aufgaben der Plugin-Komponenten ....................................................... 55
Tabelle 15: Abbildung der interaktionsorientierten Aktivitäten ................................ 59 Tabelle 16: Abbildung der kontrollflussorientierten Aktivitäten ............................... 60 Tabelle 17: Abbildung der datenflussorientierten Aktivitäten ................................... 61
Tabelle 18: Ressourcen des TransConnect®
-Servers ................................................. 63 Tabelle 19: Vergleich TC-Manager mit TC-Developer Studio ................................. 64
Tabelle 20: Benötigte Ressourcen der Aktivitäten ..................................................... 70 Tabelle 21: Identifizierte Typen von Transformationsbeschreibungen ..................... 79 Tabelle 22: Inhaltliche Struktur der beiliegenden CD-ROM ..................................... 96
Abkürzungsverzeichnis
IX
Abkürzungsverzeichnis
API Application Programming Interface
BLOB Binary Large Object
BPEL Business Process Execution Language
BPMN Business Process Modeling Notation
DOM Document Object Model
DTD Document Type Definition
EAI Enterprise Application Integration
ECA Event-Condition-Action
EMF Eclipse Modeling Framework
FTP File Transfer Protocol
GMF Graphical Modeling Framework
GUI Graphical User Interface
J2EE Java 2 Enterprise Edition
JDBC Java Database Connectivity
JNI Java Native Interface
JVM Java Virtual Machine
MDD Model Driven Development
MOM Message Orientated Middleware
MTM Message Transformation Model
OASIS Organization for the Advancement of
Structured Information Standards
PDE Plugin Development Environment
Abkürzungsverzeichnis
X
RDBMS Relational Database Management System
RFRS Ready For Rational Software
SDK Software Development Kit
STX Streaming Transformation for XML
SWT Standard Widget Toolkit
TC TransConnect®
UI User Interface
UML Unified Modeling Language
VM Virtual Machine
WFPE Workflow Process Engine
WSBPEL Web Service Business Process Execution
Language
WSDL Web Service Description Language
WSFL Web Service Flow Language
WSIL Web Service Inspection Language
XLANG XML-basierte Erweiterung der WSDL
XML Extensible Markup Language
XPath XML Path Language
XSD XML Schema Definition
XSL(T) Extensible Stylesheet Language
(Transformation)
1 Einleitung
1
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 Transformations-
prozesse 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 Einleitung
2
Im Rahmen der Weiterentwicklung von TransConnect® zu Version 1.3.6 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
1 Einleitung
3
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
1 Einleitung
4
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.
2 Grundlegende Technologien und Tools
5
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.
2.1.1 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.
2 Grundlegende Technologien und Tools
6
2.1.2 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>
2 Grundlegende Technologien und Tools
7
<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.
2 Grundlegende Technologien und Tools
8
Name Beschreibung
extensions Namensräume von WSBPEL-Erweiterungen
import Abhängigkeiten zu externen XML-Schemata oder WSDL-
Definition
partnerLinks Webservices, mit denen der Prozess kommunizieren soll
messageExchanges Logische Bezeichner zur Assoziation von
zusammengehörigen Receive/Reply-Paaren
variables Variablen eines bestimmten Nachrichtentyps
correlationSets Zuordnungen von Variablen aus der Kommunikation mit
Webservices zu einer bestimmten Prozessinstanz
faultHandlers Fehlerbehandlungsroutinen
eventHandlers Ereignisbehandlungsroutinen
Tabelle 2: 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 Beschreibung
assign Wertzuweisung einer Variablen
validate Gültigkeitsprüfung von Variablenwerten anhand deren
Definition
invoke Aufruf eines Webservice zum Versenden einer Nachricht,
entweder synchron (Request-Response) oder asynchron
receive Blockierendes Warten auf passende eingehende Nachricht
reply Verschicken einer Nachricht als Antwort auf eine eingehende
Nachricht
throw Signalisierung eines Fehlers, vergleichbar mit Ausnahmen
(Exceptions) in objektorientierten Programmiersprachen
2 Grundlegende Technologien und Tools
9
Name Beschreibung
rethrow Verwendung im Rahmen der Fehlerbehandlung zum
Weitergeben eines Fehlers
exit Sofortiges Beenden eines Prozesses ohne Fehlerbehandlung
wait Unterbrechung des Prozesses für eine definierte Zeitspanne
oder bis zu einem bestimmten Zeitpunkt
empty Leerer Knoten ohne Aktion
Tabelle 3: Grundlegende Aktivitäten von WSBPEL-2.0
Strukturierte Aktivitäten
Name Beschreibung
sequence Abarbeitung der Aktivitäten in der vorgegebenen Reihenfolge
if Bedingte Abarbeitung genau einer Aktivität entsprechend der
gesetzten Bedingung, Erweiterung um beliebig viele elseif-
beziehungsweise else-Elemente möglich
while Abarbeitung der Aktivitäten dieser kopfgesteuerten Schleife,
solange die Bedingung zutrifft
repeatUntil Abarbeitung der Aktivitäten dieser fußgesteuerten Schleife,
bis die Bedingung zutrifft
forEach 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)
flow Parallele Abarbeitung der Aktivitäten, beendet erst wenn jede
der Aktivitäten beendet wurde (Synchronisation)
pick Blockierendes Warten auf das Eintreten eines bestimmten
Ereignisses und Auslösen einer Reaktion
Tabelle 4: 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.
2 Grundlegende Technologien und Tools
10
Transaktionsaktivitäten
Name Beschreibung
scope Eine Art abgegrenzter Teilprozess mit eigenen Aktivitäten,
die nur hier gültig sind
compensate Verwendung im Rahmen der Fehlerbehandlung zur
Kompensation erfolgreich beendeter scope-Aktivitäten
compensationScope Ähnlich wie compensate, jedoch auf einen speziellen scope
bezogen
Tabelle 5: Transaktionsaktivitäten von WSBPEL-2.0
2.1.3 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.
2 Grundlegende Technologien und Tools
11
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.
2.2.1 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:
2 Grundlegende Technologien und Tools
12
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.
2.2.2 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
2 Grundlegende Technologien und Tools
13
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 3.1.3 (Defizite der Istzustandsanalyse) statt.
2 Grundlegende Technologien und Tools
14
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.
2.3.1 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.
2 Grundlegende Technologien und Tools
15
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
2 Grundlegende Technologien und Tools
16
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.
2 Grundlegende Technologien und Tools
17
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.
2.3.2 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
2 Grundlegende Technologien und Tools
18
andere Widgets mit speziell implementierten Listenern warten und dementsprechend
eine Aktion ausführen.
2.3.3 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
2.3.1 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 Beschreibung
Workbench Window Actions Aktionen in der Menüleiste und Toolbar
Object Actions Aktionen, die im Kontextmenü nur bei bestimmten
Objekten erscheinen
View Actions Aktionen innerhalb einer View
(Kontextmenü, Toolbar, Pulldown-Menü)
Editor Actions Aktionen innerhalb des Editors
(Kontextmenü, Toolbar, Pulldown-Menü)
Tabelle 6: Aktionen in Eclipse
2 Grundlegende Technologien und Tools
19
Für View- und Editor Actions können optional spezielle Tastenbelegungen konfiguriert
werden.
2.3.4 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 Eclipse-
eigenen 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
2 Grundlegende Technologien und Tools
20
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-, XHTML-
oder 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.
3 Analyse und Spezifikationen
21
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 1.3.5 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.
3.1.1 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:
3 Analyse und Spezifikationen
22
Abbildung 6: Architekturaufbau von TransConnect®
Im Folgenden werden nun die einzelnen Komponenten von TransConnect® 1.3.5
[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)
3 Analyse und Spezifikationen
23
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 Prozess-
steuerung 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® 1.3.5 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
3 Analyse und Spezifikationen
24
(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® 1.3.5 dargestellt wurde, soll im
Folgenden ein Überblick über die geplante Komponentenarchitektur von
TransConnect® 1.3.6 gegeben werden.
3 Analyse und Spezifikationen
25
Abbildung 9: Gesamtarchitektur TransConnect® 1.3.6
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®
1.3.6. Im nächsten Abschnitt wird nun der Prototyp der Workflow Process Engine näher
betrachtet.
3.1.2 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:
3 Analyse und Spezifikationen
26
Abbildung 10: Architektur TransConnect® 1.3.6 Server
Vergleicht man den Aufbau des Servers in TransConnect® 1.3.5 (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 Beschreibungs-
sprachen 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
3 Analyse und Spezifikationen
27
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.
3 Analyse und Spezifikationen
28
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
3 Analyse und Spezifikationen
29
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.
3 Analyse und Spezifikationen
30
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® 1.3.6.
Nachdem nun in den bisherigen Abschnitten dieses Unterkapitels der Umfang von
TransConnect® 1.3.5 sowie die Architekturkomponenten von TransConnect
® 1.3.6
untersucht wurden, sollen im folgenden Abschnitt noch einmal gesondert sowohl die
Defizite der aktuellen Version als auch fehlende Realisierungsaspekte von
TransConnect® 1.3.6 im Hinblick auf die im Unterkapitel 3.2 aufgeführten
Anforderungen an den Sollzustand hervorgehoben werden.
3 Analyse und Spezifikationen
31
3.1.3 Defizite
In diesem Abschnitt werden die Defizite von TransConnect® 1.3.5 beziehungsweise
dem Prototyp von TransConnect® 1.3.6 noch einmal im Überblick dargestellt, um die
Entwicklung eines Prozessmodellierungstools sowie eines Developer Studios zu
rechtfertigen.
TransConnect® 1.3.5 Prototyp TransConnect
® 1.3.6
fehlende Visualisierung beziehungsweise
grafische Modellierung des Routings von
internen Prozessen
Workflow Engine und konzeptionelles
Prozessmodell vorhanden, jedoch
Werkzeug zur Modellierung der
Prozesspläne noch nicht implementiert
unzureichende Möglichkeiten des
Monitorings am laufenden System
Monitoring zwar über Schnittstellen
vorgesehen (offene Parser-Architektur),
aber bislang nicht realisiert
keine übersichtliche und komfortable
Verwaltung aller benötigten Ressourcen
- (keine Veränderung)
Tabelle 7: Gegenüberstellung der Defizite
Wie der Tabelle zu entnehmen ist, wurde im Prototyp von TransConnect®
1.3.6 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
3 Analyse und Spezifikationen
32
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.
3.2.1 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 Prozess-
modellierungswerkzeugs.
3 Analyse und Spezifikationen
33
Anforderung Bedingung
Muss 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 Prozessbeschreibungs-
sprache (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
3 Analyse und Spezifikationen
34
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 Bedingung
Muss 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.
3 Analyse und Spezifikationen
35
Anforderung Bedingung
Muss 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.
3.2.2 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 Beschreibung
Ergonomie Aspekte der Benutzerfreundlichkeit wie Anordnung der
Schaltflächen, Menüs und Darstellungselemente
Kompatibilität Unterstützung des Imports und Exports von Prozess-
beschreibungen alternativer Modellierungswerkzeuge
3 Analyse und Spezifikationen
36
Anforderung Beschreibung
Portierbarkeit Unabhängigkeit vom Betriebssystem und von einem
möglicherweise vorhandenen Designer im Falle der Erweiterung
Robustheit Entsprechende Fehlerbehandlung im Falle nicht sachgemäßer
Bedienung
Performance Einschätzung des Laufzeitverhaltens in Bezug auf Leistungs-
fähigkeit und Verarbeitungsgeschwindigkeit
Skalierbarkeit Einschätzung der Performance bei steigenden Eingabemengen,
hier aber auch: Anpassungsaufwand bei Änderung der
Anforderungen
Tabelle 11: 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.
3.3.1 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
3 Analyse und Spezifikationen
37
3.2 beschrieben, ist die Veränderung beziehungsweise Erweiterung eines existierenden
Modellierungswerkzeugs unumgänglich, um es an die Bedürfnisse von TransConnect®
1.3.6 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.
3 Analyse und Spezifikationen
38
Gruppe Kriterium Beschreibung Gewichtung
Oberflächen-
kriterien
Ergonomie Benutzerfreundlichkeit der
Oberfläche
7
Grafische
Darstellung
Aufwändigkeit der
Präsentation
5
Element-
eigenschaften
Umfang der Einstellungs-
möglichkeiten für jedes
Darstellungselement
3
Funktionale
Kriterien
Notation Art der Notation
(BPEL | BPMN | alternativ)
8
Modellierungs-
möglichkeiten
Modellierung der Basis-
aktivitäten wie Invoke,
Receive, Switch oder
Subworkflows
8
Validierung Überprüfung der syntaktischen
Korrektheit der modellierten
Prozesspläne
5
Prozessplan-
generierung
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äts-
kriterien
Performance Einschätzung des Laufzeit-
verhaltens in Bezug auf
Leistungsfähigkeit und
Verarbeitungsgeschwindigkeit
6
Robustheit Einschätzung der Fehler-
toleranz bei unsachgemäßer
Verwendung
5
Tabelle 12: Bewertungskriterien
3 Analyse und Spezifikationen
39
3.3.2 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 0.2.0 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.
3 Analyse und Spezifikationen
40
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
Pro
• WSBPEL-2.0 Notation
• übersichtliche Oberfläche
• grafisch anspruchsvoll
• gut erweiterbar
• Validierung
Contra
• keine Ausführungsumgebung
• kein Debugging
3 Analyse und Spezifikationen
41
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.
Abbildung 18: Bewertung IX Workflow Modeler
Abbildung 19: Screenshot IX Workflow Modeler
Pro
• übersichtliche Oberfläche
• gut erweiterbar
Contra
• keine standardisierte Modellierung
• keine Ausführungsumgebung
• kein Debugging
• geringer Funktionsumfang
3 Analyse und Spezifikationen
42
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.
Abbildung 20: Bewertung JOpera
Pro
• Monitoring- und Debugging
Contra
• keine standardisierte Modellierung
• unkomfortable Oberfläche
• Quellcode nicht offen
• Fehleranfälligkeit
3 Analyse und Spezifikationen
43
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.
3 Analyse und Spezifikationen
44
Abbildung 22: Bewertung Intalio BPMS Designer
Abbildung 23: Screenshot Intalio BPMS Designer
Pro
• Modellierung mittels BPMN
• komfortable Bedienung
• Validierung
• offener Quellcode (Open Source Edition)
Contra
• eigenes Binärformat
3 Analyse und Spezifikationen
45
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.
Abbildung 24: Bewertung ActiveBPEL Designer
Pro
• WSBPEL-2.0 Notation
• komfortable Bedienung
• grafisch anspruchsvoll
• Validierung, Simulation und Debugging
• Ausführungsumgebung
Contra
• Quellcode nicht offen
3 Analyse und Spezifikationen
46
Abbildung 25: Screenshot ActiveBPEL Designer
3.3.3 Bewertung der Einsetzbarkeit
Nachdem im letzten Abschnitt die Produkte einzeln vorgestellt worden, folgt nun eine
Gegenüberstellung der Produkte hinsichtlich der definierten Bewertungskriterien mit
abschließender Entscheidung über die Einsetzbarkeit. Die folgende Tabelle enthält
dabei kurze Einschätzungen zu den jeweiligen Kriterien für jedes Produkt sowie die
entsprechende Bewertung. Diese Bewertung entspricht der Eignung der Kriterien in
Bezug auf die Anforderungen an den Sollzustand.
3 Analyse und Spezifikationen
47
Produkt Oberflächenkriterien Funktionale Kriterien Qualitätskriterien
Ergonomie der
Bedienelemente
(G7)
Grafische
Darstellung
(G5)
Umfang der
Element-
eigenschaften
(G3)
Notation
(G8)
Modellierungs-
möglichkeiten
(G8)
Validierung
(G5)
Prozessplan-
Generierung
(G5)
Import/
Export
(G7)
Erwei-
terbar-
keit
(G10)
Perfor-
mance
(G6)
Robustheit
(G5)
Eclipse
BPEL
Project
übersichtlich,
sehr gutes
Layout (6)
schlicht, aber
optisch
ansprechend
(5)
umfangreich (5) WSBPEL
2.0 (6)
Invoke, Receive,
Switch,
Subworkflows
u.v.m. (6)
teilweise
unterstützt (in
Entwicklung)
(3)
WSBPEL 2.0
(6)
ja, über
BPEL
(5)
ja, sehr
gutes
Konzept
(6)
sehr
schnell
(5)
sehr gut (6)
IX
Workflow
Modeler
übersichtlich,
jedoch wenige
Elemente (3)
schlicht (3) ausreichend,
aber nicht für
Anwendungs-
zweck
verwendbar (3)
Prozess-
Aktivitäts-
Diagramm
(3)
Prozesse,
Aktivitäten (3)
nicht
unterstützt (1)
eigenes XML-
Modell (2)
nur
eigenes
Format
(1)
ja (4) schnell
(4)
gut (5)
JOpera unübersichtlich,
nicht intuitiv (1)
sehr simpel
(2)
unvollständig
(2)
Allgemeines
Workflow-
Diagramm
(1)
Allgemeine
Prozesse (2)
nicht
unterstützt (1)
eigenes XML-
Modell (2)
nur
eigenes
Format
(1)
nein (1) aus-
reichend
(3)
unregel-
mäßig
interne
Fehler (2)
Intalio
BPMS
Designer
sehr über-
sichtlich,
schlichtes
Layout (4)
schlicht (3) umfangreich,
aber nicht für
Anwendungs-
zweck
verwendbar (3)
BPMN (3) Aufgaben,
Subprozesse,
Nachrichten,
Regeln (3)
ja, aber nicht
für Anwen-
dungszweck
verwendbar
(3)
eigenes
binäres Format
und BPEL (3)
nur
eigens
Format
(1)
ja, in
Open
Source
Edition
(6)
schnell
(4)
gut (5)
Active-
BPEL
Designer
übersichtlich,
sehr gutes
Layout (6)
grafisch sehr
anspruchsvoll
(6)
sehr
umfangreich
(6)
WSBPEL
2.0 (6)
Invoke, Receive,
Switch,
Subworkflows,
u.v.m. (6)
ja, sogar
Simulation
möglich (6)
WSBPEL 2.0
(6)
BPEL-
Export
möglich
(3)
nein (1) sehr
schnell
(5)
sehr gut (6)
Tabelle 13: Produktvergleich Modellierungswerkzeuge
3 Analyse und Spezifikationen
48
Um die Entscheidung zur Einsetzbarkeit der untersuchten Modellierungstools wie
angekündigt objektiv treffen zu können, müssen nun die Einschätzungen quantifiziert,
also die Summen der gewichteten Punkte verglichen werden. Die gewichtete Summe
errechnet sich für jedes Produkt nach der Formel
wobei
gilt.
Damit ergibt sich die im folgenden Diagramm dargestellte Platzierung der untersuchten
Produkte, wobei die höchste gewichtete Summe als bestes Ergebnis gilt. Weiterhin sind
im Diagramm die Zwischensummen der einzelnen Kriteriengruppen hervorgehoben, um
diese unabhängig vom Gesamtergebnis vergleichen zu können.
Abbildung 26: Ergebnis des Produktvergleichs
3 Analyse und Spezifikationen
49
Der wichtigste Aspekt für die Einsetzbarkeit eines vorhandenen Modellierungstools ist
die Erweiterbarkeit (Gewichtung 10), da nur auf diese Weise die definierten
Anforderungen erfüllt werden können. Daher ist der ActiveBPEL Designer, der auf den
ersten Blick als bestes Produkt wirkte, leider nicht als Grundlage für eine
Weiterentwicklung zu verwenden und erreicht lediglich den zweiten Platz (337 Punkte).
Der Intalio BPMS Designer (246 Punkte) erreicht zwar hinsichtlich der Benutzer-
freundlichkeit und Oberfläche auch gute Noten, jedoch ist bezüglich der Darstellungs-
elemente und Prozessplangenerierung noch erheblicher Änderungsaufwand nötig. Die
Produkte IX Workflow Modeler (204 Punkte) und JOpera (107 Punkte) sind zwar auf
Grund der Offenheit des Quellcodes erweiterbar, aber die Möglichkeiten der
Prozessmodellierung sind zu allgemein gehalten und die Oberfläche wirkt teilweise sehr
unübersichtlich beziehungsweise grafisch nicht ansprechend. Das Eclipse BPEL Project
(368 Punkte) bietet insgesamt eine sehr gute Grundlage für die Einsetzbarkeit als
Prozessmodellierungstool, da wichtige Aspekte wie die Vielfalt der
Modellierungsmöglichkeiten, die Ergonomie der Benutzeroberfläche und Kompatibilität
auf Grund der Unterstützung des BPEL-Standards herausragend sind und sich das
Produkt gleichzeitig komfortabel um zusätzliche Muster, Bedienelemente, Monitoring-
und Administrationskomponenten erweitern und hinsichtlich der Prozessplan-
generierung anpassen lässt.
Somit wird im Rahmen dieser Diplomarbeit entschieden, dass das Eclipse BPEL Project
zur Realisierung der definierten Anforderungen sehr gut geeignet ist und fortan als
Grundlage der prototypischen Realisierung am Beispiel von TransConnect® genutzt
wird.
3.4 Verwandte Arbeiten
Nahezu jedes Unternehmen, welches eigene Produkte im EAI-Bereich vermarktet, nutzt
oder unterstützt BPEL als Beschreibungssprache für interne Geschäftsprozesse. Zum
Abschluss des Analysekapitels sollen nun zum Vergleich des zur Erweiterung
ausgewählten Eclipse BPEL Projects drei Vertreter kommerzieller Produkte näher
3 Analyse und Spezifikationen
50
betrachtet werden, wobei hier der Fokus auf der Art und Weise liegt, wie die
Prozessmodellierung jeweils realisiert wurde.
Microsoft BizTalk Server
Der BizTalk Server 2006 [MSBTS06] von Microsoft lässt sich als EAI-Server zur
Systemintegration beschreiben und nutzt dabei ähnlich wie TransConnect®
Adapter und
Webservices zur Definition von Schnittstellen zu anderen heterogenen Systemen.
Bezüglich der Modellierung von Prozessen wird das ebenfalls von Microsoft
entwickelte Visual Studio 2005 verwendet, welches nicht nur einen Process Designer
beinhaltet, sondern ebenfalls Mappings zwischen Quell- und Zielsystemen grafisch
erstellen kann. Zusätzlich unterstützt der BizTalk Server die Interoperabilität mit
externen Prozessmodellierungswerkzeugen auf Basis von Microsoft Visio, der ARIS
Platform von IDS Scheer sowie den Import und Export von standardkonformen
Prozessbeschreibungen im Format BPEL 1.1.
IBM WebSphere MQ
Die International Business Machines Corporation (IBM) entwickelte mit WebSphere
[IBMWS07] ein Softwarepaket zur Anwendungsintegration, das neben dem zentralen
Application Server unter anderem eine so genannte Message Orientated Middleware
(MOM) namens WebSphere MQ beinhaltet, die bereits seit 1994 existiert und
plattformunabhängig auf einer Vielzahl von Betriebssystemen realisiert wurde. Die
aktuelle Version lautet WebSphere MQ V6.0.2 (2007) und besitzt zur Administration
ein auf dem Eclipse-Framework basierendes Tool, den MQ Explorer, der vom
Anwendungszweck her mit dem TransConnect® Manager zu vergleichen ist. Zur
Modellierung von Prozessen wird der WebSphere Integration Developer eingesetzt, der
eine eigenständige Entwicklungsumgebung – ebenfalls aufbauend auf Eclipse –
darstellt. Das Design und die grundlegende Funktionalität der Oberfläche sind dem
Eclipse BPEL Project durchaus ähnlich, was auf die Unterstützung der Entwicklung
durch IBM zurückzuführen ist.
3 Analyse und Spezifikationen
51
SAP Exchange Infrastructure / Process Integration
Die EAI-Plattform Exchange Infrastructure (XI) [SAPXI07] von SAP, seit Version 7.0
auch Process Integration (PI) [SAPPI07] genannt, ist Bestandteil des SAP NetWeavers.
Dieser beinhaltet wie alle vergleichbaren Produkte ebenfalls einen Application Server
und zudem noch einige weitere Komponenten, die bestimmte Funktionsbereiche von
SAP abdecken. Mit Hilfe des NetWeaver Developer Studios, welches wiederum die
Plattform von Eclipse nutzt, lassen sich eigene Anwendungen und Adapter entwickeln,
um externe Systeme zu integrieren. Der eigentliche Designer zur Modellierung von
Workflows ist aber fester Bestandteil von SAP PI und unterstützt BPEL lediglich als
Importformat, aber nicht zur internen Prozessbeschreibung.
Wie aus den abstrakten Vorstellungen der verwandten Produkte zu entnehmen ist,
werden jeweils unterschiedliche Strategien verfolgt. Während einerseits auf die volle
Integration offener Standards wie BPEL und die Verwendung der Eclipse-Plattform als
Basis für ein Modellierungswerkzeug gesetzt wird (siehe IBM WebSphere MQ),
vertrauen andere Unternehmen auf selbstentwickelte Software, die eigene
Entwicklungsumgebungen mitliefert und entsprechende Schnittstellen zum Import oder
Export externer Standards oder Produkte von Drittanbietern zur Verfügung stellt.
Somit lässt sich sagen, dass mit der Wahl des Eclipse BPEL Projects als
Modellierungswerkzeug für TransConnect® eine durchaus verbreitete Richtung
eingeschlagen wurde, ein auf dem Eclipse-Framework basierendes Tool als Grundlage
für eine Eigenentwicklung zu nutzen.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
52
4 Entwurf der prototypischen Realisierung am Beispiel
von TransConnect®
Dieses Kapitel befasst sich mit dem Entwurf der prototypischen Realisierung, wobei
zunächst die Struktur des im Produktvergleich als zu erweiterndes Modellierungs-
werkzeug ausgewählten Eclipse BPEL Projects dargelegt und anschließend auf den
Architekturentwurf der Erweiterungen und Anpassungen eingegangen wird. Danach soll
in Vorbereitung auf die zu implementierenden zusätzlichen Funktionalitäten im Rahmen
des TransConnect® Developer Studios die konzeptuelle Schnittstelle zum
TransConnect®-Server beschrieben werden. Das letzte Unterkapitel beschäftigt sich mit
dem Entwurf der Ressourcenverwaltung. An dieser Stelle muss erwähnt werden, dass
die Monitoring-Komponente wegen des Fehlens von Abhängigkeiten im Gesamtsystem
innerhalb dieser Diplomarbeit leider nicht entworfen werden kann.
4.1 Architekturentwurf des Prozessmodellierungstools
Das Eclipse BPEL Project nutzt ein internes Datenmodell zum Aufbau einer Hierarchie
der einzelnen Aktivitäten eines Prozesses und deren Attribute. Dieses Datenmodell wird
unter Nutzung des Eclipse Modeling Frameworks (EMF) [EMF07] als so genanntes
Ecore-Model repräsentiert, welches sich über erhältliche Tools leicht aus einem
vorhandenen UML-Diagramm [UML07] generieren lässt. Die Vorteile und Nachteile
eines solchen Modells sind nachfolgend kurz benannt, wobei die positiven Fakten
deutlich überwiegen und somit offensichtlich für die Wahl eines solchen Modells
ausschlaggebend waren.
Vorteile:
Automatische Code-Generierung der Java-Klassenhierarchie anhand des
Modells (Model Driven Development, MDD, [MGSE05], [MGSE07])
Hohe Flexibilität, da generierte Klassen im Nachhinein noch angepasst werden
können, ohne dass die Änderungen bei Neugenerierung überschrieben werden
Hohe Skalierbarkeit, da das Modell in beliebig tiefe Schachtelungsebenen
erweiterbar ist
Unterstützung von Standards (UML, XML) und Open-Source-Frameworks
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
53
Integration anderer Komponenten von Eclipse, wie zum Beispiel das Graphical
Modeling Framework (GMF) [GMF07]
Nachteile:
Abwärtskompatibilität des Modells bei neuen Versionen des Eclipse Modeling
Frameworks nicht immer gegeben (zum Beispiel Version 2.3.0 zu 2.2.3), so dass
zwar die Ausführungskomponente erhalten bleibt, die Modell-Generierung
jedoch weiterhin mit der Vorgängerversion erledigt oder komplett adaptiert
werden muss
Inkompatibilitäten zwischen generiertem Code und manuellen Änderungen
Der folgende Abschnitt beschreibt die grobe Paketstruktur des Eclipse BPEL Projects
sowie den Aufbau des Datenmodells.
4.1.1 Struktur und Aufbau
Das Eclipse BPEL Project besteht zum aktuellen Zeitpunkt aus neun einzelnen Plugins,
wobei jedes ein eigenes Eclipse-Projekt darstellt. Die folgende Abbildung zeigt den
Gesamtaufbau im Überblick, in dem die einzelnen Plugins nochmals zu funktionalen
Gruppen zusammengefasst sind.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
54
Abbildung 27: Gesamtarchitektur Eclipse BPEL Project
Die „Oberflächenkomponente“, welche aus den Plugins UI und Common-UI besteht, ist
für den Aufbau der grafischen Benutzeroberfläche des Prozessmodellierungswerkzeugs
zuständig, während die „Präsentationskomponente“ mit den Plugins Feature und Site
Auslieferungsaspekte des fertigen Produkts beinhaltet. Diese beiden Begriffe haben also
nicht dieselbe Bedeutung und sind demzufolge zu unterscheiden. Wie in der Abbildung
zu sehen ist, sind die Teilprojekte über Abhängigkeiten (Imports, Extension Points,
Referenzen) teilweise eng miteinander verknüpft. In der folgenden Tabelle werden die
Aufgaben der einzelnen Plugins kurz beschrieben.
Plugin-Komponente Aufgabe
common.model Verwaltung des allgemeinen Extension Models
(Erweiterung des BPEL-Sprachstandards)
common.ui Aufbau der grafischen Oberfläche des Editors
feature Logische Zusammenfassung der Plugin-Komponenten zu
einem „Feature“ (ermöglicht die Auslieferung des Produkts
als Ganzes)
model Verwaltung des internen Datenmodells für die Aktivitäten
eines Prozesses
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
55
Plugin-Komponente Aufgabe
runtimes Steuerung allgemeiner Ausführungselemente der Kompo-
nenten sowie von Assistenten
site Erstellung einer Update-Seite zur automatischen Installation
des gesamten Plugins in Eclipse
ui Aufbau der grafischen Modellierungselemente für jede
Aktivität sowie deren Eigenschaften und kontextbezogenen
Menüs
validator Erstellung von Validatoren für bestimmte Objekte sowie den
gesamten Prozessplan
wsil.model Implementierung der Web Service Inspection Language
(WSIL) [WSIL07] zur Identifikation und Beschreibung von
Services zur Laufzeit
Tabelle 14: Aufgaben der Plugin-Komponenten
Das Ressourcen-Management, also das Einlesen eines BPEL-Dokuments und die
Generierung des grafischen Prozessplans sowie die Erzeugung eines BPEL-Dokuments
anhand des Modells, übernehmen die Klassen BPELReader und BPELWriter innerhalb
des Plugins model. Dabei ist zu beachten, dass im aktuellen Stand des Eclipse BPEL
Projects das aus dem Modell resultierende BPEL-Dokument immer wieder komplett
neu generiert wird und eventuelle manuelle Änderungen, Kommentare oder
Formatierungen überschrieben werden. Dieser Aspekt ist ein wichtiges Kriterium für
die Gesamtperformance, denn die vollständige Neugenerierung kann sich bei
Prozessplänen mit einer hohen Anzahl an modellierten Aktivitäten negativ auf die
Speichergeschwindigkeit auswirken. Um die Performance des Designers näher zu
untersuchen, wurde deshalb an definierten Stellen im Quellcode die benötigte Zeit zum
Laden und Speichern von BPEL-Dokumenten gemessen. Während sich der
Speichervorgang allein auf das Schreiben der XML-Datei anhand der im Ecore-Model
vorhandenen Daten beschränkt, kann der Lesevorgang in zwei Teile gegliedert werden.
Einerseits muss die XML-Datei eingelesen und das Ecore-Model aufgebaut werden,
andererseits müssen aber noch die GMF-Oberflächenelemente des Designers
entsprechend der eingelesenen Daten erzeugt und untereinander in Beziehung gesetzt
werden. Letzteres ist ausschlaggebend für die Komplexität, insbesondere wenn ein
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
56
hoher Anteil an solchen Aktivitäten vorhanden ist, die wiederum andere Aktivitäten
beinhalten. Das Ergebnis wird nachstehend veranschaulicht.
Abbildung 28: Untersuchung der Lese- und Schreibperformance
Wie aus dem Diagramm zu entnehmen ist, weist der Designer bei bis zu 100
modellierten Aktivitäten eine nahezu konstante Performance bei allen drei Vorgängen
auf, die jeweils nur leicht ansteigt und dabei unter 50 ms bleibt. Erst ab 100 Aktivitäten
sind Auffälligkeiten zu erkennen. Während sich die benötigte Zeit beim Lese- und
Schreibzugriff auf das XML-Dokument ungefähr linear erhöht, steigt die Dauer des
gesamten Ladevorgangs auf Grund der steigenden Komplexität wie erwartet
exponentiell bis auf über 300 ms (1000 modellierte Aktivitäten) an. Nach erfolgreichem
Ladevorgang sind jedoch keine Einbrüche der Performance mehr zu erwarten. Das
erneute Schreiben des gesamten Prozessplans bei jeder Änderung wirkt sich also nicht
merklich auf die Performance aus, obwohl in Zukunft eine Verbesserung mittels
Synchronisation von Dokument und Modell erzielt werden kann, in dem nur die
jeweiligen Änderungen geschrieben werden. Die Gesamtperformance lässt sich
demnach, wie schon im Produktvergleich grob festgestellt, als sehr gut einschätzen.
Das Datenmodell ist hierarchisch aufgebaut und besitzt als Knoten EClasses. An diesem
Beispiel ist verallgemeinernd zu erwähnen, dass sämtliche Bestandteile des Ecore-
Modells mit dem Präfix E beginnen, um die Unterscheidung von eigenen
0
50
100
150
200
250
300
350
10 20 50 100 500 1000
Zeit
in [
ms]
Anzahl modellierte Aktivitäten (log.)
Schreiben (XML)
Lesen (XML)
Laden (Gesamt)
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
57
benutzerdefinierten Objekten zu gewährleisten. Das Wurzelelement stellt dabei der
Prozess mit seinen Attributen (EAttributes) dar. Sämtliche Elemente sind von der
Klasse ExtensibleElement abgeleitet, die ein erweiterbares WSDL-Element darstellt.
Sie können wahlweise genau einmal oder beliebig oft als EList vorkommen,
beziehungsweise optional sein. Sollte ein Element andere bereits definierte Elemente
benötigen, wird dies über EReferences gelöst.
Mit diesem beschriebenen System ist es nun möglich, auf konzeptueller Ebene ein
komplexes, hinsichtlich der Schachtelungstiefe frei skalierbares Modell mit einer
beliebigen Anzahl von benötigten Elementen und Verknüpfungen zu erstellen und
anschließend das Klassenmodell zu generieren. Es besitzt eine zentrale Factory-Klasse,
welche die dynamische Erzeugung der Elemente bei Verwendung zur Laufzeit
übernimmt, sowie die Pakete model und impl. Das Paket model enthält dabei lediglich
Interface-Klassen, in denen die Schnittstellen der einzelnen Objekte beschrieben
werden, während im Paket impl die eigentliche Funktionalität der Klassen
implementiert ist. Von Seiten der Oberfläche kann dieses Modell nun bei
Benutzerinteraktion über bestimmte Hilfsklassen manipuliert werden. Die folgende
Abbildung veranschaulicht nochmals die wesentlichen Bestandteile der Komponente
model.
Abbildung 29: Aufbau Plugin-Komponente „model“
In der Plugin-Komponente ui hingegen wird die gesamte Oberfläche des Designers
implementiert, wobei sich folgendes Schema der wichtigsten Pakete ergibt:
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
58
Abbildung 30: Aufbau Plugin-Komponente „ui“
Die Adapterverwaltung hat die Aufgabe, für sämtliche modellierbaren Aktivitäten in
geeigneter Weise entsprechende grafische Oberflächenelemente zur Verfügung zu
stellen. In diesem Sinne stellen die Adapter also ein direktes Bindeglied zwischen dem
Datenmodell und der Oberfläche dar. Jegliche Benutzerinteraktion, die in Dialogen,
Eigenschaften-Seiten, Assistenten oder direkt im Editor des Designers erfolgt, löst
direkt oder indirekt eine interne Aktion aus, sofern eine definierte Bedingung erfüllt ist
(Event – Condition – Action, ECA, [ECA07]).
Des Weiteren ermöglicht die Nutzung vordefinierter ExtensionPoints (siehe Abschnitt
3.2.1) beispielsweise die Erweiterung der Editorpalette um neue Schaltflächen oder das
Hinzufügen einer neuen Seite in der Eigenschaften-Ansicht (Property View) einer
Aktivität.
4.1.2 Anpassung der Aktivitäten
Nachdem im vorhergehenden Abschnitt die Architektur des Modells im Überblick
beschrieben wurde, soll nun detailliert herausgearbeitet werden, welche Änderungen
nötig sind, um sämtliche Elemente des MTM auch innerhalb des Modellierungs-
werkzeugs abzudecken. Dabei wird davon ausgegangen, dass die im Designer bereits
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
59
vorhandenen Aktivitäten im WSBPEL-2.0-Standard modelliert wurden und nur noch
adaptiert werden oder komplett neue Aktivitäten hinzugefügt werden müssen. Die
folgende Tabelle stellt die Aktivitäten des MTM den vorhandenen BPEL-Aktivitäten
gegenüber und beschreibt die zu implementierenden Veränderungen. An dieser Stelle
sei darauf hingewiesen, dass vorhandene Aktivitäten oder Attribute, die im Rahmen des
MTM nicht mehr benötigt werden, nur dann aus dem Modell entfernt werden, wenn
eine Verwendung in Zukunft ausgeschlossen ist. Eine vollständige Übersicht über alle
Aktivitäten mit ihren Attributen ist in der Metagrammatik des MTM im Anhang A zu
finden.
Interaktionsorientierte Aktivitäten
Die Aktivitäten Receive, Invoke und Reply werden von WSBPEL 2.0 übernommen,
jedoch in ihren Attributen auf ein Mindestmaß reduziert. Die Pick-Aktivität ist dagegen
im MTM nicht mehr enthalten, da diese ebenfalls durch Receive abgebildet werden
kann. Die folgende Tabelle zeigt die Abbildung der interaktionsorientierten Aktivitäten
nochmals in der Übersicht.
WSBPEL 2.0 MTM Änderung
Receive Receive einfaches Mapping
Pick - Abbildung durch Receive
Invoke Invoke einfaches Mapping
Reply Reply einfaches Mapping
Tabelle 15: Abbildung der interaktionsorientierten Aktivitäten
Kontrollflussorientierte Aktivitäten
Die kontrollflussorientierten Aktivitäten unterliegen teilweise erheblichen Änderungen,
wie die nachstehende Tabelle veranschaulicht.
WSBPEL 2.0 MTM Änderung
Process Process Kontextabhängige Übernahme
mit Kindelementen
Scope - Abbildung durch Process
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
60
WSBPEL 2.0 MTM Änderung
If Switch einfaches Mapping
Flow Fork einfaches Mapping
Wait Delay einfaches Mapping
While Iteration Abbildung aller Schleifen auf
die Iteration-Aktivität ForEach
RepeatUntil
Throw Signal Abbildung aller „initiierenden“
Aktivitäten auf die generische
Signal-Aktivität Rethrow
Compensate
CompensateScope
Exit
Sequence - implizit in anderen Aktivitäten
enthalten Empty
Tabelle 16: Abbildung der kontrollflussorientierten Aktivitäten
Die Process-Aktivität kann fast vollständig übernommen werden, jedoch gibt ein
zusätzliches Attribut an, ob es sich um den Hauptprozess oder einen Subprozess
handelt. Somit entfällt die für Subprozesse konzipierte Scope-Aktivität vollständig. Die
BPEL-Aktivitäten If, Flow und Wait werden auf die MTM-Aktivitäten Switch, Fork und
Delay abgebildet, um die Logik der Geschäftsprozesse verständlicher zu gestalten. So
kann beispielweise ein Switch beliebig viele Fälle (Cases) enthalten, deren Eintreten
jeweils mit einem Bedingungsausdruck (Expression) geprüft wird. Sämtliche Schleifen-
Aktivitäten wurden durch die Aktivität Iteration ersetzt, wobei mit einem neuen
Attribut angegeben werden kann, ob es sich um eine kopf- oder fußgesteuerte Schleife
handelt. Die Signal-Aktivität ersetzt im MTM alle „initiierenden“ Aktivitäten und
besitzt ein Attribut zur Angabe des Typs. Im Rahmen des MTM sind überall dort, wo
untergeordnete Aktivitäten vorkommen können, entweder keine, eine oder beliebig
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
61
viele Aktivitäten zugelassen. Durch diese implizite Abdeckung entfällt an diesen Stellen
somit die explizite Modellierung einer Sequence beziehungsweise einer leeren Aktivität.
Datenflussorientierte Aktivitäten
Bei den datenflussorientierten Aktivitäten kann zunächst die Assign-Aktivität
übernommen werden. Dabei lässt die Quelle der Zuweisung (From) nach wie vor
entweder einen XPath-Ausdruck oder eine Variable zu, während das Ziel (To) nur eine
Variable sein kann. Die Validate-Aktivität ist im MTM jeweils nur noch jeweils auf
eine einzelne Variable anwendbar und überprüft die Gültigkeit entweder anhand des
Variablentyps, eines Schemas (XSD) oder eines beliebigen XPath-Ausdrucks.
Mit den Aktivitäten Translation und Action sind zwei Erweiterungen hinzugekommen,
die im Rahmen von WSBPEL 2.0 als ExtensionActivity definiert werden können. Wie
jedoch bereits in den Anforderungen an das Modellierungswerkzeug beschrieben,
müssen diese Aktivitäten neu implementiert werden, da sie im zu erweiternden Designer
nicht enthalten sind. Die nachstehende Tabelle verdeutlicht dies nochmals im Überblick.
WSBPEL 2.0 MTM Änderung
Assign Assign einfaches Mapping
Validate Validate zusätzliche Nutzung
documentation-Element
ExtensionActivity/Translation Translation zu implementieren
ExtensionActivity/Action Action zu implementieren
ExtensionActivity/Savepoint Savepoint zu implementieren
Tabelle 17: Abbildung der datenflussorientierten Aktivitäten
Die Translation-Aktivität wird dazu verwendet, eine Nachricht über eine
Transformationsvorschrift (XSLT, STX, XQuery) in ein bestimmtes Zielformat zu
konvertieren, wobei eine beliebige Anzahl von Parametern angegeben werden kann.
Über die Aktivität Action lässt sich an jeder Stelle des Prozessplans frei definierbarer
Java-Quellcode ausführen, um kurze Berechnungen oder Statements zu erledigen. Mit
der Savepoint-Aktivität ist es möglich, entweder den gesamten Kontext oder eine
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
62
bestimmte Nachricht als Wiederherstellungspunkt im Falle eines Rollbacks zu
definieren.
Nachdem nun sämtliche Änderungen an den Aktivitäten des vorhandenen Designers
vom Eclipse BPEL Project im Entwurf beschrieben wurden, sollte es möglich sein, mit
dem fertig angepassten Modellierungswerkzeug einerseits auf der Oberfläche Prozesse
mit den Aktivitäten des MTM zu modellieren und andererseits ebenfalls MTM-
konforme Repräsentation des Prozessplans als Ausgabedatei zu generieren und diese an
den TransConnect®
-Server zu senden. Der Entwurf der dazu notwendigen
Kommunikationsschnittstelle wird im Unterkapitel 4.3 beschrieben.
4.2 Projekt- und Ressourcenverwaltung
Ziel einer Verwaltung von Ressourcen innerhalb des TransConnect® Developer Studios
ist die Erstellung von so genannten Szenarien, die einen bestimmten abgegrenzten
Aufgabenbereich des TransConnect®-Servers beschreiben, wenn sie auf diesem
veröffentlicht sind. Diese Szenarien können weitere logische Systeme (wie zum
Beispiel Lagerverwaltung, Lohnbuchhaltung oder Vertrieb) beinhalten, die über
bestimmte Adapter und Transformationen miteinander gekoppelt sind. Die folgende
Abbildung veranschaulicht mögliche Szenarien als Beispiel.
Abbildung 31: TransConnect® Beispielszenarien
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
63
Die zum Serverbetrieb benötigten Ressourcen sind in der nachstehenden Tabelle
aufgezählt und beschrieben. An dieser Stelle muss jedoch erwähnt werden, dass der
Begriff „Ressource“ hier Hardware-Ressourcen wie Hauptspeicher oder Prozessor nicht
mit einschließt, sondern lediglich die zu einem Oberbegriff zusammengefassten
Bestandteile des TransConnect®-Servers beinhaltet. Aus betrieblichen Gründen
befinden sich darin auch Komponenten, die im technischen Sprachgebrauch
normalerweise nicht als Ressourcen bezeichnet werden.
Ressource Beschreibung
Nachrichtentypen Liste mit Datentypen von Nachrichten
Transformationen Vorschriften zur Umwandlung von Nachrichten von
einem Quellformat in ein Zielformat (zum Beispiel
mittels XSLT, STX oder XQuery)
Schemata Verschiedene Beschreibungen des Aufbaus von
Nachrichten
Externe Ressourcen Java-Klassen (.class), Java-Archive (.jar) oder Java-
Bibliotheken (.lib), die bestimmte benötigte
Funktionalitäten kapseln
Adapter und deren
Konfigurationen
Beschreibung der vorhandenen Adapter mit Typ
(Dateiadapter, Datenbankadapter, ...), Subtyp (FTP,
JDBC, ...) und Richtung der Kommunikation
(Inbound, Outbound)
Workflows Prozesspläne, die mit dem Modellierungswerkzeug
erstellt wurden (entweder für Routing oder als
zeitgesteuerte Aufgabe)
Routen Beschreibung von Vorschriften für das Routing mit
Nachrichtentyp, Bedingung und zugehörigem
Workflow
Queues Definition von Warteschlangen mit bestimmtem
Verhalten im Fehlerfall (Ignorieren oder Anhalten)
Logische Systeme Definition von Systemen zur logischen Zuordnung
von Ressourcen innerhalb eines Szenarios
Tabelle 18: Ressourcen des TransConnect®-Servers
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
64
Diese Ressourcen werden bis dato über den externen TransConnect® Manager
administriert (siehe Abschnitt 3.1.1), welcher jedoch einige Nachteile aufweist. In
Bezug auf diese Nachteile werden in der nächsten Tabelle der Manager und das
Developer Studio hinsichtlich ausgewählter Eigenschaften gegenüber gestellt.
Eigenschaft TransConnect® Manager TransConnect
®
Developer Studio
Plattform basiert auf Sybase Central Integration in Eclipse
Anpassungs-
möglichkeit der
Konfigurationen
Inhalte sind fest programmiert,
keine Dynamik möglich
Struktur vom Anwender
weitgehend frei definierbar
Ergonomie Mangelhaft, da Oberfläche und
Layout von Sybase Central zu
nutzen ist
Übersichtliche und gewohnte
Benutzeroberfläche von
Eclipse
Import/Export von
Konfigurationen
nur alle Ressourcen als Ganzes
austauschbar
Austausch jeder einzelnen
Ressource möglich
Tabelle 19: Vergleich TC-Manager mit TC-Developer Studio
Das grundlegende Prinzip einer solchen Ressourcenverwaltung lässt sich auf mehrere
Arten verwirklichen. Auf TransConnect® bezogen, kann man deshalb drei Ansätze
unterscheiden, welche im Folgenden einzeln vorgestellt werden.
4.2.1 Remoteverwaltungsansatz über Vermittler
Der Ansatz einer Remoteverwaltung der Ressourcen verlagert die Geschäftslogik auf
den Server. Das bedeutet, die Projekt- und Ressourcenverwaltung des Developer
Studios bietet eine externe Sicht auf die Ressourcen, die auf dem Server vorhanden
sind. Jedoch erfolgt die Bearbeitung direkt zur Laufzeit auf dem Server, der somit auch
deren Verwaltung übernimmt. Die bidirektionale Schnittstelle hat die Aufgabe, über
eine Vermittlerklasse (Delegate) ein Abbild der Ressourcen vom Server zu laden und
vollzogene Änderungen wieder am Server zu veröffentlichen. Der Client kennt
demnach nur die Methoden der Resource-Schnittstelle, die wiederum interne Methoden
des Resource-Managers aufruft. In der folgenden Abbildung wird dieses Prinzip noch
einmal verdeutlicht.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
65
Abbildung 32: Schema Remoteverwaltungsansatz über Vermittler
Der Hauptvorteil des Remoteverwaltungsansatzes liegt in der Konsistenzsicherheit. Da
sämtliche Informationen zur Laufzeit immer aktuell vom Server geholt werden, wird die
Gefahr minimiert, inkonsistente Zustände zu bearbeiten. Nachteilig wirkt sich auf
diesen Ansatz jedoch der Mehrbenutzerbetrieb aus. Sobald ein Nutzer bestimmte
Ressourcen auf dem Server bearbeitet, muss ein Transaktionssystem diese zum
Schreiben sperren, bis sie wieder explizit freigegeben werden. Dies beeinträchtigt die
Flexibilität erheblich und kann auch eine Reihe anderer Probleme wie z.B. „Dirty Read“
hervorrufen. Veränderte Teilinformationen könnten dabei bereits ausgelesen werden,
ohne dass die gesamte Bearbeitung abgeschlossen ist, bei der eventuell Änderungen
rückgängig gemacht wurden. Somit würde der lesende Client mit inkorrekten
Informationen arbeiten.
Als zweiter großer Nachteil ist die permanente Serververbindung zu nennen, bei der
auftretende Verbindungs- oder Serverprobleme sich direkt auf den Funktionsumfang
auswirken. Ein Monitoring des Servers wäre in diesem Fall nicht mehr möglich und
eventuell gemachte Änderungen müssten verworfen werden, wenn nicht erfolgreich
gespeichert werden kann.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
66
4.2.2 Remoteverwaltungsansatz über Direktzugriff
Der Ansatz eines Direktzugriffes auf die Ressourcen des Servers verfolgt zunächst das
selbe Prinzip wie die Remoteverwaltung über einen Vermittler, jedoch gibt es auf
Serverseite keinen Resource-Manager mehr. Vielmehr kann der Client, das Developer
Studio, direkt auf eine Datenbankschnittstelle zugreifen und somit die entsprechenden
Ressourcen in der Datenbank selbständig manipulieren, wie die folgende Abbildung
zeigt.
Abbildung 33: Schema Remoteverwaltungsansatz über Direktzugriff
Obwohl dieser Ansatz auf den ersten Blick übersichtlicher und einfacher aussieht,
enthält er einige Risiken und Nachteile. Die gesamte Transaktionslogik muss im Client
implementiert werden, während die verwendete interne Datenbank nur ihre eigene
Transaktionssicherheit beim Zugriff auf die Tabellen gewährleisten kann. Zudem
besteht hierbei die Gefahr, dass der Client durch seinen Direktzugriff Daten zerstören
oder ungültige Daten speichern kann, ohne dass diese vorher nochmals serverseitig
überprüft werden. Eine Nutzerverwaltung zwecks Zuordnung von veröffentlichten
Szenarien zu einzelnen Nutzern lässt sich über diesen Ansatz ebenfalls schwer
realisieren.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
67
4.2.3 Lokalverwaltungsansatz
Beim Lokalverwaltungsansatz ist der Client, also das jeweilige Developer Studio, für
die Verwaltung der Ressourcen verantwortlich. Bezogen auf TransConnect® bedeutet
es, dass sämtliche Konfigurationen der Ressourcen im Client persistent gehalten
werden, bis eine Veröffentlichung auf den Server durch den Nutzer explizit ausgelöst
wird. Dann werden die Meta-Informationen über die definierte Schnittstelle (siehe
Unterkapitel 4.3) an den Server geschickt, wo zunächst eine umfangreiche
Versionskontrolle mit den möglicherweise bereits vorhandenen Ressourcen erfolgen
muss. Zur Speicherung werden die Daten vom Resource-Manager in die interne
Datenbank des Servers übertragen. Besonders sei an dieser Stelle noch einmal auf den
Unterschied der Ressourcenversionen hingewiesen. Das lokale Developer Studio besitzt
immer genau den Zustand der Meta-Informationen, den es selber zu einem bestimmten
Zeitpunkt abgerufen hat, während die Version auf dem Server inzwischen schon
aktueller sein kann. Das beschriebene Verfahren ist in der nachstehenden Abbildung
veranschaulicht.
Abbildung 34: Schema Lokalverwaltungsansatz
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
68
Die Erstellung und Bearbeitung der Ressourcen ohne Verbindung zum Server kann
sicherlich als wichtigster Vorteil des Lokalverwaltungsansatzes angesehen werden.
Optional ist es möglich, die aktuelle Konfiguration der Ressourcen vom Server zu
importieren, um sie als Ausgangsbasis für Veränderungen zu nutzen. Weiterhin können
die lokal erstellten Konfigurationen zwischen mehreren Developer Studios ausgetauscht
werden, da es sich um normale Dateien mit definiertem XML-Format handelt. Als
Nachteil ist bei diesem Ansatz die Fehleranfälligkeit zu nennen, denn bis zur manuellen
Veröffentlichung der gemachten Änderungen ist dem Nutzer bis auf grundlegende
Validierungsfunktionalitäten im Client nicht bekannt, ob der Server diese auch
verarbeiten kann. Kann auf Grund fehlender Lizenz des entsprechenden Adapters der
Server zum Beispiel kein SAP-System ansprechen, wird dies erst an dieser Stelle mit
einem Fehler angezeigt. Zudem ist hierbei eine entsprechende Nutzerverwaltung
dringend zu empfehlen, um veröffentlichte Konfigurationen einerseits einem Nutzer
zuordnen zu können, andererseits aber auch die Bearbeitung für andere Nutzer zu
sperren, um möglichen Versionskonflikten vorzubeugen.
Nachdem nun die Ansätze im Detail vorgestellt wurden, soll im nächsten Abschnitt
anhand der definierten Anforderungen an die Projekt- und Ressourcenverwaltung
entschieden werden, welcher Ansatz als Grundlage für den Entwurf dienen soll.
4.2.4 Entwurfsentscheidung und konzeptuelle Architektur
Als wichtigste Anforderungen an die Projekt- und Ressourcenverwaltung wurden im
Abschnitt 3.2.1 die Möglichkeit der Offline-Bearbeitung von Ressourcen sowie deren
Persistenz auf Client-Seite genannt, welche sich lediglich mit dem
Lokalverwaltungsansatz realisieren lassen. Demzufolge wird entschieden, im Rahmen
der Diplomarbeit den Lokalverwaltungsansatz als Basis für die Ressourcenverwaltung
zu nutzen. Die bereits erwähnte Nutzer- und Versionsverwaltung ist jedoch nicht
Bestandteil der Diplomarbeit.
Um die gewünschte Ressourcenverwaltung mit dem Lokalverwaltungsansatz realisieren
zu können, muss der Nutzer zunächst die Möglichkeit haben, im Rahmen des
TransConnect® Developer Studios innerhalb von Eclipse ein neues TransConnect
®-
Projekt anzulegen. Dies geschieht mittels eines Assistenten, der grundlegende
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
69
Projekteinstellungen wie Name und Beschreibung abfragt und über das für Eclipse-
Nutzer bekannte Menü File New Project… aufgerufen werden kann. Nach
Beendigung dieses Assistenten wird das neue Projekt mit einer vordefinierten
Ordnerstruktur erstellt, welche an den Ressourcen des TransConnect® Servers orientiert
ist.
Abbildung 35: Ordnerstruktur Ressourcenverwaltung
Innerhalb des Ordners einer Ressourcenkategorie kann, wie in der Abbildung zu
erkennen, vom Nutzer eine frei wählbare Unterordnerhierarchie angelegt werden, um
beispielsweise die zeitgesteuerten Aufgaben, Workflows oder Transformationen
thematisch zu ordnen. Parallel zum Anlegen der Ordnerstruktur wird beim Erstellen des
Projekts in eine neue TransConnect®-Perspektive gewechselt, was den Vorteil hat, dass
die Eigenschaften einzelner Ressourcen zukünftig in eigenen Views angezeigt werden
können. Entsprechend der jeweiligen Kategorie ist es über das Kontextmenü möglich,
einen weiteren Assistenten oder einen Auswahldialog aufzurufen, um neue Ressourcen
mit spezifischen Einstellungen anzulegen.
Als besonderer Entwurfsaspekt ist hierbei die Verbindung der Ressourcenverwaltung
mit dem Prozessmodellierungswerkzeug anzusehen. Die Aktivitäten in der
nachstehenden Tabelle benötigen externe Ressourcen, die innerhalb des TransConnect®
-
Projekts ausgewählt werden können, wenn sie sich in den entsprechenden Ordnern
befinden.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
70
Aktivität Eigenschaft Benötigte Ressource
Invoke Service WSDL-Beschreibung eines
TransConnect®-Adapters
Operation
Translation Script STX oder XSLT Datei zur
Transformationsbeschreibung
Alle Input/Output Variable
Nachrichtentyp als XML-Schema
Tabelle 20: Benötigte Ressourcen der Aktivitäten
Für die Invoke-Aktivität muss es demzufolge möglich sein, die WSDL-Beschreibung
eines Adapters zu importieren und als Service zu verwenden. Dabei müssen sämtliche
verfügbaren Operationen, die mit dem jeweiligen Adapter ausführbar sind, ebenfalls
einzeln herausgefiltert werden und auswählbar sein. Die Translation-Aktivität benötigt
für die Eigenschaft Script eine Transformationsbeschreibung in Form eines XSLT-,
STX- oder XQuery-Dokuments als Dateireferenz. Fast alle Aktivitäten verwenden
außerdem Variablen (Input / Output), die einen bestimmten Nachrichtentyp besitzen.
Dieser ist indirekt in einer Adapterbeschreibung referenziert und kann innerhalb des
Process Designers einer Variablen zugeordnet werden.
Ziel ist es nun, nicht nur den globalen Rahmen der Ressourcenverwaltung mit
Assistenten und Kontextmenüs zu implementieren, sondern ebenfalls für jede der oben
genannten Aktivitäten einen entsprechenden „Content Assist“ auf der Oberfläche des
Designers anzubieten, bei dem die benötigten Ressourcen aus dem aktuellen Projekt
ausgewählt werden können. Das fertige Projekt kann dann als Archiv gepackt und über
die im folgenden Unterkapitel beschriebene Schnittstelle an den TransConnect®
-Server
gesendet werden.
4.3 Beschreibung der Schnittstelle zu TransConnect®
Wie die nachstehende Abbildung zeigt, besitzt der Server von TransConnect® 1.3.6
Schnittstellen zu allen externen Tools in der Präsentationsschicht, wobei die
Schnittstelle zum Prozessmodellierungswerkzeug als einzige bidirektional gestaltet ist.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
71
Abbildung 36: Schnittstellen TransConnect® 1.3.6 Server
Im Hinblick auf das Monitoring zur Laufzeit ist es somit möglich, einerseits vom
Designer aus Statusinformationen des Servers und Statistiken zu einzelnen Prozessen
abzurufen, aber auch ein eigenständiges periodisches Senden über Events vom Server
aus zu initiieren. Leider ist zum Zeitpunkt der Diplomarbeit die Monitoring-
Schnittstelle mit ihren Interfaces und Transportbeschreibungen noch nicht vorhanden, in
der folgenden schematischen Abbildung der Schnittstelle des Process Designers ist
diese jedoch bereits enthalten.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
72
Abbildung 37: Schnittstelle Process Designer
Im Wesentlichen sind hierbei drei Teilschnittstellen zu unterscheiden:
Process Designer Server
o Ausführung modellierter Prozesse
(Ausführungskomponente, Execution Interface)
o Ausliefern modellierter Prozesse an den Server
(Auslieferungskomponente, Deployment Interface)
Server Process Designer
o Ereignis-Notifikation (Monitoringkomponente, Event Interface)
Das Execution Interface dient der expliziten Ausführung von Prozessen auf dem Server
durch den Nutzer, während mit den Funktionalitäten des Deployment Interfaces die
modellierten Prozesse in Form eines XML-Dokuments lediglich an den Server
ausgeliefert werden. Die entgegengesetzt gerichtete Schnittstelle Event Interface stellt
eine asynchrone Schnittstelle für Monitoring-Events dar. So kann der grafischen
Oberfläche signalisiert werden, dass bestimmte Ausnahmen eingetreten sind, respektive,
dass bestimmte Schwellwerte erreicht wurden.
4 Entwurf der prototypischen Realisierung am Beispiel von TransConnect
73
Zur Kommunikation mit der Projekt- und Ressourcenverwaltung des Developer Studios
wird entsprechend der Abbildung ebenfalls eine eigene Schnittstelle verwendet, um
mittels des Import Interfaces auf einem Server befindliche Szenarien abrufen und
importieren zu können sowie mit dem Deployment Interface neu erstellte
beziehungsweise bearbeitete Projekte auf dem Server zu veröffentlichen. Die
nachstehende Abbildung visualisiert die Kapselung in die beiden genannten
Teilschnittstellen.
Abbildung 38: Schnittstelle Ressourcenverwaltung
Analog zur Schnittstelle zum Prozessmodellierungswerkzeug übernimmt das Eclipse-
Plugin mit seiner Oberfläche die Interaktion mit dem Nutzer. Ebenfalls ist auch die
Funktionalität zum Veröffentlichen (Deployment Logic) enthalten. Zusätzlich existiert
die Resource Logic, welche die gesamte lokale Verwaltung der Ressourcen übernimmt.
Diese komplexe Schnittstelle wird derzeit durch eine Dummy-Implementierung ersetzt,
welche die elementarsten Funktionalitäten des Imports abdeckt und somit eine Anzahl
von Testdaten zur Verfügung stellt. Der Entwurf des Deployment Interfaces ist
hingegen noch nicht abgeschlossen.
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
74
5 Ausgewählte Implementierungsaspekte der
prototypischen Realisierung am Beispiel der
Translation-Aktivität
Dieses Kapitel soll einzelne Aspekte der prototypischen Implementierung am Beispiel
der Aktivität „Translation“ näher betrachten, die als Schlüsselstellen im Gesamtsystem
anzusehen sind.
5.1 Allgemeine Vorgehensweise zur Erweiterung des Designers
Im Folgenden wird die Vorgehensweise zur Erweiterung des grafischen Designers um
die Translation-Aktivität beschrieben. Zur Anpassung bereits vorhandener sowie zum
Hinzufügen weiterer Aktivitäten kann analog vorgegangen werden.
Zunächst wird im Ecore-Model eine neue Klasse mit dem Namen der neuen Aktivität
(„Translation“) hinzugefügt, welche von der Basisklasse Activity (ESuperType)
abgeleitet ist. Nun können sämtliche Attribute als Kindelemente dieser Klasse ergänzt
sowie die benötigten Referenzen (EReferences) wiederum als neue Klasse angelegt
werden. Die folgenden beiden Abbildungen zeigen die fertige Translation-Aktivität als
Ecore-Modell-Ausschnitt und als UML-Klassendiagramm des generierten Interfaces im
Vergleich.
Abbildung 39: Ecore-Model der Translation-Aktivität
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
75
Abbildung 40: UML-Klassendiagramm der Translation-Aktivität
Im Plugin-Manifest der Komponente ui oder eines eigenen Plugins kann die Extension
org.eclipse.bpel.common.ui.paletteAdditions verwendet werden, um auf
logischer Ebene eine neue Schaltfläche in der Palette des Editors hinzuzufügen.
Abbildung 41: Extension für Schaltfläche der Translation-Aktivität
Für die Darstellung der neuen Schaltfläche wird eine Factory-Klasse (abgeleitet von
AbstractUIObjectFactory) angelegt, die den entsprechenden Schaltflächentext sowie
die anzuzeigenden Icons festlegt und über eine Vermittlungsklasse (abgeleitet von
BPELCreationToolEntry) mit der logischen Definition verknüpft ist.
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
76
Unter Nutzung der Extension org.eclipse.bpel.ui.actions kann im nächsten
Schritt eine Aktion definiert werden, die ausgeführt wird, wenn der Benutzer die
angelegte Schaltfläche in der Editorpalette auswählt.
Abbildung 42: Extension für Aktion der Translation-Aktivität
Die eigentliche Aktion wird in einer neuen Klasse, abgeleitet von
AbstractBPELAction, beschrieben und enthält neben einer allgemeinen Beschreibung
die Angabe des anzulegenden Modellobjekts, wenn über die Schaltfläche die Aktivität
in den Prozessplan übernommen werden soll. Außerdem muss ein entsprechender
Adapter innerhalb der Plugin-Komponente „ui“ angelegt werden, der im Standardfall
von der Klasse ActivityAdapter abgeleitet ist und keine weiteren Anweisungen
enthält. Er ist lediglich nötig, um eine Verbindung zwischen der Oberfläche und dem
eigentlichen Datenmodell herzustellen.
Das vorhandene System des Modellierungswerkzeugs verlangt zusätzlich die Erstellung
eines Symbols (Icon) mit dem selben Namen der Aktivität („Translation.gif“) und
dessen Registrierung in der so genannten Image Registry (Klasse
org.eclipse.bpel.ui.IBPELUIConstants).
Zur Serialisierung beziehungsweise Deserialisierung der neuen Aktivität müssen nun
noch die Klassen BPELReader und BPELWriter im Plugin „model“ angepasst werden,
so dass die Elemente mit ihren Attributen entsprechend der MTM-Spezifikation beim
Speichern oder Laden des Prozessplans korrekt geschrieben oder gelesen werden.
Um die Attribute der Aktivität auf der Oberfläche manipulieren zu können, ist es
abschließend nötig, mit Hilfe der Extension org.eclipse.ui.views.properties.
tabbed.propertySections eine neue Seite in der Eigenschaften-Ansicht (Property
View) des Editors zu definieren. Dabei kann wahlweise die vorhandene Eigenschaften-
Kategorie „Details“ verwendet oder eine eigene Kategorie angelegt werden.
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
77
Abbildung 43: Extension für Eigenschaftenseite der Translation-Aktivität
Wie der Abbildung zu entnehmen ist, muss nun eine entsprechende Klasse (abgeleitet
von BPELPropertySection) im Paket org.eclipse.bpel.ui.properties des
Plugins „ui“ angelegt werden, um die Funktionalität und Darstellungselemente zu
implementieren.
Die fertige Eigenschaftenseite der Translation-Aktivität ist nachfolgend zu sehen.
Abbildung 44: Screenshot Eigenschaftenseite der Translation-Aktivität
5.2 Import von externen Transformationsbeschreibungen
Wie im Abschnitt 4.2.4 beschrieben, benötigt die zum Prozessmodellierungstool neu
hinzugefügte Aktivität Translation eine Transformationsbeschreibung als externe
Ressource. Um Fehleingaben des Nutzers zu vermeiden, wurde festgelegt, dass diese
nicht deskriptiv über den Dateinamen angegeben werden darf, sondern bereits lokal
innerhalb des entsprechenden Projektordners („Transformations“) vorhanden sein muss
und somit in der Eigenschaftenseite der Aktivität ausgewählt, respektive importiert
werden kann. Diese Eigenschaftenseite, die bis jetzt lediglich ein Textfeld zur Eingabe
des Skriptnamens vorsieht (siehe Abbildung 38), muss also um eine „Content Assist“-
Funktionalität erweitert werden.
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
78
Das Eingabefeld für den Skriptnamen wird auf seiner rechten Seite um eine Schaltfläche
ergänzt, über die ein Auswahldialog aufgerufen werden kann. Dieser Dialog soll
zunächst intern die vorhandenen Transformationsbeschreibungsdateien analysieren und
die Ergebnisse übersichtlich dem Nutzer zur Auswahl darstellen. Die Analysephase
bezieht sich hierbei nicht auf die syntaktische Korrektheit des Dateinamens, so dass
zum Beispiel nur die Dateiendung mit den zugelassenen Typen übereinstimmen muss,
sondern nimmt bereits eine grobe Untersuchung des Inhalts vor, um ungültige Dateien
zu erkennen und dies dem Nutzer in Form eines andersfarbigen Auswahleintrags zu
signalisieren. Die Eclipse Platform API bietet zwar bereits eine Menge von spezifischen
Auswahldialogen wie zum Beispiel den ElementListSelectionDialog an, jedoch
nutzen die meisten davon die FilteredList-Klasse zur Sammlung der Elemente, die es
leider nicht erlaubt, einzelne Elemente bezüglich ihres Aussehens zu verändern.
Deshalb soll an dieser Stelle eine eigene Dialogklasse SelectScriptTableDialog –
abgeleitet von der Basisklasse Dialog – implementiert werden, die einen TableViewer
(siehe Abschnitt 2.3.2) einsetzt, um die Elemente in Tabellenform zu präsentieren. Der
Inhalt der Tabelle wird zur Laufzeit bei jedem Dialogaufruf mit der Methode
getTableContents() initialisiert, welche nacheinander folgende Schritte ausführt:
1) Identifizieren des TransConnect®-Projekts, in dem sich die momentan
bearbeitete Prozessbeschreibung befindet
2) Lokalisieren des Ordners für Transformationsbeschreibungen innerhalb des
identifizierten Projekts
3) Rekursive Suche nach Dateien innerhalb aller Unterordner dieses Ordners, dabei
a) Analyse und Zuordnung des Typs
b) Hinzufügen zu einer Liste
Bei der Analyse des Typs (3a) wird ein XML-Parser verwendet, der die jeweils
gefundene Datei einliest und in ein Document Object Model (DOM) [DOM05]
umwandelt. Anschließend wird das Wurzelelement untersucht und anhand dessen
Namen der Typ zugeordnet, wobei folgende Typen als Ergebnis der Analyse
vorkommen können:
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
79
Typ Merkmal
XSLT Wurzelelement <xsl:stylesheet>
STX Wurzelelement <stx:transform>
Unbekannt keine XML-Datei oder anderes Wurzelelement
Ungültig Datei leer oder nicht lesbar
Tabelle 21: Identifizierte Typen von Transformationsbeschreibungen
Vergleicht man die identifizierbaren Typen mit den im Rahmen der Metagrammatik der
Translation-Aktivität (siehe Anhang A) verwendbaren Typen, wird deutlich, dass
Transformationsbeschreibungen der Typen „MIX“ und „XQuery“ auf programm-
technischem Wege nicht erkennbar sind, da sie entweder im Falle von „MIX“ eine
Mischung aus STX und XSLT darstellen oder wie bei XQuery kein definiertes
Wurzelelement besitzen. Dateien, die dementsprechend keine XML-Datei sind oder ein
unbekanntes Wurzelelement besitzen, werden als „Unbekannt“ typisiert.
Die vollständige Liste aller gefundenen Dateien, die schließlich von der Methode
getTableContents() zurückgegeben wird, besteht aus einer Sammlung von logischen
Transformationsbeschreibungen, die das Interface ITransformation implementieren.
Abbildung 45: UML-Klassendiagramm der Transformation-Schnittstelle
Wie im UML-Diagramm zu sehen ist, kann über diese Schnittstelle auf die zum Aufbau
der Tabelle notwendigen Attribute Name, Projektpfad und Typ zugegriffen werden,
welche gleichermaßen die Spalten der Tabelle darstellen. Im letzten Schritt sollen die
Einträge, welche einen ungültigen Typ haben, von der Methode markInvalidFiles()
5 Ausgewählte Implementierungsaspekte der prototypischen Realisierung
80
in der Tabelle markiert werden. Ein entsprechender SelectionChangedListener, der
mit der Tabelle verknüpft ist, verhindert außerdem bei Auswahl eines ungültigen
Eintrags die Nutzung der Bestätigungsschaltfläche („OK“), so dass im Endeffekt nur
gültige Transformationsbeschreibungen im Datenmodell abgespeichert werden können.
Die folgende Abbildung zeigt den fertigen Auswahldialog.
Abbildung 46: Screenshot Auswahldialog Transformationbeschreibung
Sollten im Zuge der Weiterentwicklung weitere Auswahlkriterien, Filter oder Attribute
hinzukommen, können diese leicht ergänzt werden. Ebenfalls ist es auf Grund der
bereits beschriebenen Trennung zwischen Darstellung und Logik der Datenbeschaffung
möglich, diesen Dialog an anderen Stellen mit geringfügigem Anpassungsaufwand
wieder zu verwenden.
6 Zusammenfassung und Ausblick
81
6 Zusammenfassung und Ausblick
In diesem letzten Kapitel sollen die Ergebnisse der Diplomarbeit zusammengefasst, der
Projektstand nach der Diplomarbeit untersucht und einige Schlussfolgerungen für die
Weiterentwicklung von TransConnect® gegeben werden. Innerhalb eines Ausblicks
wird außerdem die zukünftige Entwicklung des zugrunde liegenden Standards
betrachtet und der wirtschaftliche Standpunkt von TransConnect® im Vergleich zu
anderen Plattformen bewertet.
6.1 Ergebnisse und Schlussfolgerungen
Anhand der im ersten Kapitel vorgestellten Hauptziele der Diplomarbeit sollen nun die
Ergebnisse zusammengetragen werden. Im Rahmen der Untersuchung existierender
Modellierungswerkzeuge wurde zunächst eine Auswahl von Prozessdesignern
zusammengestellt, die das Potential haben, den gestellten ergonomischen und
technischen Anforderungen zu genügen. Deren Eignung und Einsetzbarkeit,
insbesondere als Grundlage für eine Erweiterung, konnte jedoch nur innerhalb eines
umfangreichen Produktvergleichs objektiv festgestellt werden. Das Eclipse BPEL
Project erfüllte alle gestellten Voraussetzungen, ist hinsichtlich der Anforderungen
anpassbar und wurde somit zur weiteren Entwicklung genutzt.
Die zu vollziehenden Erweiterungen am Datenmodell der Aktivitäten und an der
Oberfläche wurden im nächsten Schritt einzeln detailliert herausgearbeitet, um eine
vollständige Kompatibilität des Designers mit dem MTM zu gewährleisten. Dabei
musste die Metagrammatik des MTM an einzelnen Stellen angepasst werden (siehe
Anhang A), da beispielsweise die im MTM vorhandene Aktivität Merge bislang vom
TransConnect® Server nicht unterstützt wird und somit nicht zu modellieren ist. Der
aktuell vorliegende prototypische Designer ist in der Lage, Prozessbeschreibungen auf
Grundlage des MTM zu modellieren, die nach Veröffentlichung von der WFPE erkannt
und erfolgreich verarbeitet werden können. Ein Komplexbeispiel zum Szenario
„Bestellabwicklung“ befindet sich im Anhang B.
Wie bereits in der Analyse des MTM und im Fazit von [BÖHM07] vermerkt, stellt sich
die Definition von eigenen Aktivitäten und damit die Abweichung vom Standard BPEL
als problematisch heraus. Der Vorteil eines eigenen Sprachmodells für die Steuerung
6 Zusammenfassung und Ausblick
82
von nachrichtenbasierten Prozessen liegt vor allem in der Reduzierung der Komplexität
von WSBPEL-2.0 und der Anpassung auf die speziellen Anforderungen von
TransConnect®. Jedoch wird somit die Möglichkeit ausgeschlossen, die modellierten
Prozessbeschreibungen in anderen Designern zu öffnen oder zu bearbeiten, da diese die
erweiterten, respektive angepassten Aktivitäten nicht verstehen. Analog verhält es sich
mit Aktivitäten, die unter Nutzung der standardisierten ExtensionActivity definiert
wurden. Modelliert man hingegen Prozesse allein mit WSBPEL-2.0-Aktivitäten und
nutzt den in der WFPE integrierten Transformator, der entsprechend dem Mapping in
Abschnitt 4.1.2 arbeitet, lassen sich diese erfolgreich ausführen. Eine Verbesserung
könnte hier jedoch erzielt werden, indem sämtliche Spezialaufgaben wie Translation
oder Savepoint als Webservice innerhalb des TransConnect®-Servers realisiert und über
die standardisierte Aktivität Invoke im Rahmen des Workflows angesprochen werden.
Der angepasste Designer wurde zwar bereits in die Projekt- und Ressourcenverwaltung
integriert, besitzt aber noch keine Schnittstelle zu einer Monitoringkomponente, da
diese noch nicht konzipiert wurde. Ebenfalls müssen in Zukunft noch
Qualitätssicherungsmaßnahmen wie zum Beispiel automatisierte Tests durchgeführt
werden, bevor der Designer produktiv eingesetzt werden kann. Zu verbessern wäre
zudem noch die beim Lokalverwaltungssansatz nötige grundlegende Validierung auf
Seite des Clients, um Fehler bei der Workflow-Erstellung frühzeitig zu erkennen.
Für die Projekt- und Ressourcenverwaltung als Bestandteil des TransConnect®
Developer Studios konnte ein grundlegender Entwurf geschaffen werden, der bereits die
Projekterstellung, Organisation der Ressourcen in einer Verzeichnisstruktur und den
Import von externen Ressourcen am Beispiel von Transformationsbeschreibungen
beinhaltet. Im Zuge der Weiterentwicklung von TransConnect® müssen an dieser Stelle
noch sämtliche Ressourcenkategorien mit entsprechenden Content-Assists
vervollständigt werden. Dazu zählt vor allem das Hinzufügen der möglichen
Adaptertypen, wobei für jeden Adapter vordefinierte WSDL-Beschreibungen
mitgeliefert werden. Denkbar wäre auch ein komplexer Assistent zur Erstellung eines
eigenen benutzerdefinierten Adapters mit anschließender WSDL-Generierung, die über
das Service Dictionary der WFPE bereits möglich ist. Auch hier fehlt noch die
Implementierung der beschriebenen Kommunikationsschnittstelle zur letztendlichen
Realisierung des Lokalverwaltungssansatzes.
6 Zusammenfassung und Ausblick
83
6.2 Ausblick
Die Entwicklung des originalen, durch Dritte unveränderten Eclipse BPEL Projects
wird von der Eclipse Foundation permanent fortgeführt. Wie einleitend beim
Produktvergleich im Unterkapitel 3.3 beschrieben, sind Funktionalitäten wie ein
umfangreiches Runtime-Framework oder Möglichkeiten des Laufzeitdebuggings leider
noch nicht Bestandteil der aktuellen Version. Es ist aber zu erwarten, dass der Designer
in naher Zukunft um diese Eigenschaften ergänzt wird. Die Anpassungen in dieser
Diplomarbeit wurden, wie in den Nicht-Funktionalen Anforderungen erwähnt, vom
Original-Plugin weitgehend unabhängig realisiert beziehungsweise lose gekoppelt.
Damit dürfte es kein Problem darstellen, in Zukunft von Verbesserungen ohne großen
Aufwand zu profitieren.
Bezüglich des Standards WSBPEL ist anzunehmen, dass er sich in nächster Zeit auf
dem Gebiet der Anwendungsintegration weiter etablieren und durchsetzen wird, da
nahezu alle Produkte im EAI-Bereich entweder eine BPEL-Schnittstelle anbieten oder
die Sprache selbst zur Beschreibung der modellierten Prozesse nutzen.
Das Produkt TransConnect® kann zum aktuellen Zeitpunkt als eine auf spezielle
Anforderungen zugeschnittene Branchenlösung in den Bereichen E-Commerce,
Telekommunikation, Energieversorgung und Krankenhausverwaltung angesehen
werden. Dabei steht vorallem die relativ einfache Handhabung im Vordergrund sowie
die Tatsache, dass alle notwendigen Tools in einem Paket unter einer Lizenz
ausgeliefert werden. Dieser pragmatische Ansatz wird auch mit der Einführung des
Developer Studios inklusive Prozessmodellierungswerkzeug weiter verfolgt. Die
Erstellung von Workflows wurde erheblich vereinfacht und kann grafisch ohne
Programmierkenntnisse erfolgen, was den nötigen Anpassungsaufwand in sich
ändernden Integrationsszenarien erheblich reduziert. Trotzdem bietet die Architektur
von TransConnect® die Möglichkeit, neue Anwendungsfelder durch das Entwickeln von
zusätzlichen Adaptern zu erschließen, die über ihre WSDL-Beschreibung unmittelbar
vom Designer unterstützt werden. Somit lässt sich sagen, dass das in dieser
Diplomarbeit prototypisch entwickelte Prozessmodellierungswerkzeug einerseits einen
weiteren Meilenstein im Entwicklungsfortschritt von TransConnect® 1.3.6 darstellt,
andererseits aber auch die praktische Nutzbarkeit der WFPE erneut demonstriert.
Anhang
84
Anhang
A Metagrammatik der generierten Prozessbeschreibung
In diesem Anhang soll die aktuelle Version (Stand August 2007) der Metagrammatik
der vom Prozessmodellierungswerkzeug generierten Prozessbeschreibungen dargestellt
werden. Diese orientiert sich prinzipiell an der Metagrammatik des Message
Transformation Models (MTM), beinhaltet jedoch an vereinzelten Stellen Anpassungen
oder Erweiterungen, die hervorgehoben markiert sind. Es wird die im Abschnitt 2.1.2
beschriebene Notation verwendet.
<process name="name">
<variables>
<variable name="msg" type="set | single">*
</variables>
<services>
<service name="s" type="t">*
</services>
<processsteps>
<!-- implizit immer auch Sequence-->
activity*
</processsteps>
</process>
activity := InteractionActivity
| ControlFlowActivity
| DataFlowActivity
| TransactionAcitivity
InteractionActivity := invoke
| receive
| reply
ControlFlowActivity := switch
| delay
| fork
| signal
| iteration
DataFlowActivity := assign
| translation
| validate
| action
TransactionActivity := savepoint
Anhang
85
Interaktionsorientierte Aktivitäten
<invoke name="inv1"
service="s"
operation="o"
inputVariable="msg1"
outputVariable="msg2">
<catch>
activity*
</catch>
<compensation>
activity*
</compensation>
</invoke>
<receive
name="recv1"
outputVariable="msg1">
</receive>
<reply
name="rep1"
inputVariable="msg1">
</reply>
Kontrollfussorientierte Aktivitäten
<switch name="sw1"
inputVariable="msg1"
inputPart="p">
<case expr="s">*
activity*
</case>
<default>
activity*
</default>
</switch>
<delay name="d1">
(<for>1000</for> |
<until>165165165156</until>)+
</delay>
<fork name="f1">
<forklane>*
activity*
</forklane>
</fork>
<signal
name="sig1"
type="compensate | throw | exit">
</signal>
<iteration
name="iter1"
type="headsteered | footsteered"
Anhang
86
counter="i"?
start="0"?
end="y"?>
<case expr="xyz"/>?
<body>
activity*
</body>
</iteration>
Datenflussorientierte Operatoren
<assign name="assign1">
<copy>*
<from inputVariable="msg1"? part="arg1"?/>
<to outputVariable="msg2" part="arg2"/>
</copy>
</assign>
<translation
name="trans1"
type="XSLT | STX | MIX | XQuery"
script="script.xsl"
inputVariable="msg1"
inputPart="x"
outputVariable="msg2"
outputPart="y">
<parameter
name="p"
value=""/>*
</translation>
<validate
name="val1"
inputVariable="msg2"
schemaname=""
expression="">
<!--if no expression, perform a simple XML-Validation
(wellformed and XSD-validation for msg-type)-->
</validate>
<action name="act1">
java-sourcecode [CDATA]
</action>
Transaktionsorientierte Operatoren
<savepoint
name="save1"
type="CTX | MSG"
inputVariable="msg2">
<!--if type is 'CTX', ignore input variable-->
</savepoint>
Anhang
87
B Komplexbeispiel „Bestellabwicklung“
Nachdem in den Unterkapiteln 4.1 und 5.1 der Entwurf des Process Designers sowie
eine allgemeine Vorgehensweise zur Erweiterung beschrieben wurde, soll in diesem
Anhang ein Komplexbeispiel folgen, welches den Weg von der grafischen
Modellierung eines Prozesses, über die Generierung der Prozessbeschreibung in Form
des MTM bis hin zur Veröffentlichung auf der Workflow-Engine und Erzeugung eines
Prozessplans als Java-Klasse noch einmal im Überblick darstellt.
Der folgende beispielhafte Prozess einer möglichen Bestellabwicklung wurde unter
Nutzung des Process Designers modelliert.
Abbildung 47: Beispielprozess „Bestellabwicklung“
Anhang
88
Zunächst wird über die Receive-Aktivität ReceiveOrder eine Bestellung empfangen und
einer Variablen msg1 zugeordnet. Nach erfolgreicher Validierung wird in Vorbereitung
für eine Abfrage auf der Kundendatenbank eine Transformation der Bestellnachricht in
das Format der Datenbanknachricht durchgeführt. Die Invoke-Aktivität
GetCustomerAccount nutzt diese transformierte Nachricht msg2, um anhand der
Kundennummer in der Bestellung den entsprechenden Kunden in der Datenbank zu
identifizieren und ihn als Rückgabewert in der Variablen msg3 zu speichern.
Nun wird im Rahmen einer Switch-Aktivität (CheckOrder) überprüft, ob das Guthaben
des Kunden für die Bestellung ausreicht. Ist dies der Fall, wird die Bestellung mittels
einer weiteren Transformation in ein zur verwendeten Datenbank passendes Format
umgewandelt (msg4) und schließlich wiederum über ein Invoke (SaveOrder) in der
Datenbank gespeichert. Sollte das Guthaben unzureichend sein, wird mit einer Signal-
Aktivität (NotEnoughMoney) eine entsprechende Fehlermeldung erzeugt, die zur
Laufzeit abgefangen werden muss. Eine mögliche Konsequenz dieses Fehlers wäre das
Senden einer E-Mail an den Kunden oder Kundenbetreuer zur weiteren Bearbeitung.
Wenn beim Überprüfen des Guthabens ungültige Werte verglichen werden oder ein
anderer unerwarteter Fehler auftritt, wird der Prozess wiederum mit einem Signal (Exit)
sofort verlassen. Nach Abarbeitung der Fallunterscheidung werden zum Schreiben einer
Log-Datei wichtige Informationen der Bestellung in eine Variable (msg5) extrahiert,
bevor ein Invoke das Schreiben des Archiv-Logs in das Dateisystem übernimmt.
Nach Abspeichern des fertig modellierten Prozesses generiert das Werkzeug eine XML-
Prozessbeschreibung im Format des angepassten MTM, welche in diesem Beispiel wie
folgt aussieht (siehe Anhang A – Metagrammatik):
<?xml version="1.0" encoding="UTF-8"?>
<process name="OrderExample"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
<services>
<service name="ContentArchive" type="FileAdapter"/>
<service name="syb01" type="JDBCAdapter"/>
<service name="cust01" type="JDBCAdapter"/>
</services>
<variables>
<variable name="msg1" type="ClientInterfaceMessage"/>
<variable name="msg2" type="JDBCAdapterMessage"/>
<variable name="msg3" type="JDBCAdapterMessage"/>
<variable name="msg4" type="JDBCAdapterMessage"/>
<variable name="msg5" type="FileAdapterMessage"/>
</variables>
Anhang
89
<processsteps>
<receive name="ReceiveOrder" outputVariable="msg1"/>
<validate inputVariable="msg1" name="ValidateOrder" schemaname="order.xsd"/>
<translation inputVariable="msg1" name="TranslateOrder1"
outputVariable="msg2" script="order2custdb.xsl" type="XSLT"/>
<invoke inputVariable="msg2" name="GetCustomerAccount"
operation="GETACC" outputVariable="msg3" service="cust01"/>
<switch inputPart="/CONTENT/ORDER/TOTALPRICE"
inputVariable="msg1" name="CheckOrder">
<case expr="<=$msg3/CONTENT/ACCOUNT/CAPITAL">
<translation inputVariable="msg1" name="TranslateOrder2"
outputVariable="msg4" script="order2sybdb.xsl" type="XSLT"/>
<invoke inputVariable="msg4" name="SaveOrder"
operation="Insert" service="syb01"/>
</case>
<case expr=">$msg3/CONTENT/ACCOUNT/CAPITAL">
<signal name="NotEnoughMoney" type="throw"/>
</case>
<default>
<signal name="Exit" type="exit"/>
</default>
</switch>
<assign name="CopyArchiveLog">
<copy>
<from inputVariable="msg4" part="CONTENT"/>
<to outputVariable="msg5" part="ContentAttachment"/>
</copy>
<copy>
<from><![CDATA[ContentAttachment]]></from>
<to outputVariable="msg5" part="CONTENT/FILE/@CONTENTID"/>
</copy>
<copy>
<from inputVariable="msg5"
part="ContentAttachment/ORDERS/O_Orderkey/text()"/>
<to outputVariable="msg5" part="CONTENT/FILE/@NAME"/>
</copy>
</assign>
<invoke inputVariable="msg5" name="WriteArchiveLog"
operation="WRITE" service="ContentArchive"/>
</processsteps>
</process>
Diese Prozessbeschreibung wird nun im TransConnect®
-Server 1.3.6 veröffentlicht und
an die prototypische Workflow Process Engine (WFPE) weitergeleitet. Nach dem im
Abschnitt 3.1.2 beschriebenen Prinzip erzeugt die WFPE nun eine zu der
Prozessbeschreibung passende Java-Klasse als instantiierbarer Prozessplan. Sollte
dieser Prozessplan nicht automatisch beim Eintreffen einer passenden Nachricht durch
die WFPE aufgerufen werden (Modellierung einer Receive-Aktivität), kann durch den
Scheduler ein entsprechender „ScheduledTask“ angelegt und beispielsweise über eine
zeitgesteuerte Aufgabe in TransConnect® eingeplant werden. Im aktuellen
Komplexbeispiel wird der nachfolgend als Quellcode abgebildete Prozessplan auf
Grund der vorhandenen Receive-Aktivität ReceiveOrder jedoch beim Eintreffen einer
Bestellung abgearbeitet und muss somit nicht manuell zeitlich eingeplant werden.
Anhang
90
public class OrderExample extends ProcessPlan
{
private InternalMessage msg1 = null;
private InternalMessage msg2 = null;
private InternalMessage msg3 = null;
private InternalMessage msg4 = null;
private InternalMessage msg5 = null;
public OrderExample()
{
}
@Override
protected InternalMessage executeNode(InternalMessage... input) throws MTMException
{
try
{
/*Receive pattern*/
setNID(1);
msg1 = input[0];
setNID(2);
/*VALIDATE pattern*/
Validate node2 = new Validate("CONTENT", "", order.xsd", false);
node2.setIDs(getPTID(),getPID(),getNID());
node2.execute(msg1);
Anhang
91
setNID(3);
/*Translation pattern*/
Translation node3 = new Translation("order2custdb.xsl", "CONTENT", "CONTENT", Translation.XSLT);
node3.setIDs(getPTID(),getPID(),getNID());
msg2 = node3.execute(msg1);
setNID(4);
/*INVOKE pattern*/
try
{
Invoke node4 = new Invoke("cust01", "GETACC");
node4.setIDs(getPTID(),getPID(),getNID());
node4.setTransactionManager(_pctx.getTransactionManager());
msg3 = node4.execute(msg2);
}
catch( MTMException me )
{
throw me;
}
/*SWITCH pattern*/
if(Expression.evalBooleanExpression(msg1, /CONTENT/ORDER/TOTALPRICE", "<=msg3/CONTENT/ACCOUNT/CAPITAL", false))
{
setNID(5);
/*Translation pattern*/
Translation node5 = new Translation("order2db.xsl", "CONTENT", "CONTENT", Translation.XSLT);
node5.setIDs(getPTID(),getPID(),getNID());
msg4 = node5.execute(msg1);
Anhang
92
setNID(6);
/*INVOKE pattern*/
try
{
Invoke node6 = new Invoke("syb01", "Insert");
node6.setIDs(getPTID(),getPID(),getNID());
node6.setTransactionManager(_pctx.getTransactionManager());
node6.execute(msg4);
}
catch( MTMException me )
{
throw me;
}
}
else if( Expression.evalBooleanExpression( msg1,"/CONTENT/ORDER/TOTALPRICE",">msg2/CONTENT/ACCOUNT/CAPITAL",false))
{
setNID(7);
/*SIGNAL (help) pattern*/
Signal node7 = new Signal(Signal.THROW);
node7.setIDs(getPTID(),getPID(),getNID());
node7.execute(); //throws MTMSignalException
}
else
{
setNID(8);
/*SIGNAL (help) pattern*/
Signal node8 = new Signal(Signal.EXIT);
Anhang
93
node8.setIDs(getPTID(),getPID(),getNID());
node8.execute(); //throws MTMSignalException
}
setNID( 9 );
/*ASSIGN pattern*/
Assign node9 = new Assign( new String[]{"CONTENT",null,"ContentAttachment/ORDERS/O_Orderkey/text()"},
new String[]{"ContentAttachment","CONTENT/FILE/@CONTENTID","CONTENT/FILE/@NAME"},
new String[]{null,"ContentAttachment",null}, false, false );
node9.setIDs( getPTID(), getPID(), getNID() );
msg5 = node9.execute( new InternalMessage[]{msg4,null,msg5} );
setNID(10);
/*INVOKE pattern*/
try
{
Invoke node10 = new Invoke("ContentArchive", "WRITE");
node10.setIDs(getPTID(),getPID(),getNID());
node10.setTransactionManager(_pctx.getTransactionManager());
node10.execute(msg5);
}
catch( MTMException me )
{
throw me;
}
}
Anhang
94
catch(MTMSignalException ex1)
{
//catch a specific signal
switch(ex1.getType())
{
case MTMSignalException.CATCH_THROW:
{
throw new MTMException("MTMSignal: catched a THROW signal");
}
case MTMSignalException.CATCH_COMPENSATE:
{
executeNodeCompensation( 0, getNID() );
break;
}
case MTMSignalException.CATCH_EXIT:
{
break;
}
}
}
catch(MTMException ex2)
{
//abnormal exception
_log.error("processstep error occured during workflow processing",ex2);
_log.debug("starting faultHandling");
executeNodeErrorHandling();
}
Anhang
95
catch(Exception ex3)
{
_log.error("unexpected error occured during workflow processing",ex3);
}
return null;
}
@Override
protected void executeNodeCompensation(int startNID, int endNID)
{
if( startNID > endNID )
return;
if( startNID < 2147483647 && endNID > 2147483647 )
{
}
_log.debug("finished compensations");
}
@Override
protected void executeNodeErrorHandling()
{
_log.debug("finished faultHandling");
}
}
Anhang
96
C Inhaltliche Struktur der beiliegenden CD-ROM
In diesem letzten Anhang wird die Verzeichnisstruktur der CD-ROM, die dieser
Diplomarbeit beiliegt, kurz erläutert und inhaltlich beschrieben.
Verzeichnis Inhaltsbeschreibung
Diplomarbeit Aufgabenstellung, Thesen und die Diplomarbeit in
unterschiedlichen Dateiformaten
Literatur Digital verfügbare Referenzliteratur
Technische Beispiele Beispieldateien (Transformationsbeschreibungen,
Workflows, WSDL-Beschreibungen)
Projekte Im Rahmen der Diplomarbeit bearbeitete Java-
Projekte inklusive Dokumentation im JavaDoc-
Format
Demo Selbstlaufende Präsentation zur Modellierung eines
Beispielprozesses
Tabelle 22: Inhaltliche Struktur der beiliegenden CD-ROM
Literaturverzeichnis
97
Literaturverzeichnis
ACTBP07 Active Endpoints: ActiveBPEL Designer,
http://www.active-endpoints.com/active-bpel-designer.htm, 2007
ANSI75 ANSI/Standards Planning and Requirements Commitee (SPARC), 1975
BÖHM07 BÖHM, M.: Untersuchung der Funktionalitäten der Business Process
Execution Language (BPEL) zur Beschreibung komplexer Nachrichten-
transformationen dargestellt am Beispiel von TransConnect®
, Diplomarbeit,
2006
BPMN06 Object Management Group: Business Process Modeling Notation (BPMN),
Specification BPMN 1.0, http://www.bpmn.org/, Februar 2006
DOM05 World Wide Web Consortium (W3C): Document Object Model (DOM),
http://www.w3.org/DOM/, 2005
ECA07 Wikipedia: Event Condition Action,
http://en.wikipedia.org/wiki/Event_Condition_Action, 2007
ECLBP07 The Eclipse Foundation: BPEL Project, http://www.eclipse.org/bpel/, 2007
ECLI06 CLAYBERG, E.; RUBEL, D.: Eclipse – Building Commercial-Quality
Plug-ins, Second Edition, Addison Wesley, 2006
ECLIFPP GUCLU, K.: A First Look at Eclipse Plug-In Programming,
http://www.developer.com/java/other/article.php/10936_3316241_2, o.J.
EMF07 The Eclipse Foundation: Eclipse Modeling Framework Project (EMF),
http://www.eclipse.org/modeling/emf/, 2007
FEKA06 SQL GmbH: Dokumentation Fachentwurf „Komponentenarchitektur“, 2006
FEKM06 SQL GmbH: Dokumentation Fachentwurf „Konzeptuelles Modell“, 2006
GMF07 The Eclipse Foundation: Graphical Modeling Framework (GMF),
http://www.eclipse.org/gmf/, 2007
IBMWD07 IBM: WebSphere Integration Developer,
http://www-306.ibm.com/software/integration/wid/, 2007
IBMWS07 IBM: WebSphere MQ,
http://www-306.ibm.com/software/integration/wmq/index.html, 2007
Literaturverzeichnis
98
INTCE07 Intalio, Inc.: BPMS Designer Community Edition und Enterprise Edition,
http://www.intalio.com/products/designer/, 2007
INTOS07 Intalio, Inc.: BPMS Designer Open Source Edition,
http://www.eclipse.org/stp/bpmn/, 2007
IXWFM07 Imixs Software Solution GmbH: IX Workflow Modeler,
http://www.imixs.org/websites/imixs-org.nsf/chapter/0030.?OpenDocument,
2007
JGOP06 JBOSS: JBoss jBPM – Graph Oriented Programming,
http://docs.jboss.org/jbpm/v3/userguide, 2006
JOPER07 Eidgenössische Technische Hochschule Zürich, ETH: JOpera Project,
http://www.jopera.ethz.ch, Februar 2007
MGSE05 STAHL, T.; VÖLTER, M.: Modellgetriebene Softwareentwicklung:
Techniken, Engineering, Management, dpunkt-Verlag, 2005
MGSE07 Wikipedia: Modellgetriebene Softwareentwicklung,
http://de.wikipedia.org/wiki/Modellgetriebene_Softwareentwicklung, 2007
MSBTS06 Microsoft Corporation: BizTalk Server 2006,
http://www.microsoft.com/germany/biztalk/default.mspx, 2006
OAWS07 OASIS WS-BPEL Komitee, Web Services Business Process Execution
Language Version 2.0 (Spezifikation), April 2007
REQU06 ROBERTSON, S.; ROBERTSON, J.: Mastering the Requirements Process.
2. Auflage, Addison Wesley, 2006
RFRS EDGAR, N.; HAALAND, K.: Ready For Rational Software – Eclipse User
Interface Guidelines, Version 2.1, http://www.eclipse.org/articles/Article-
UI-Guidelines/Index.html, Februar 2004
SCNPI07 SAP Community Network: NetWeaver Process Integration,
https://www.sdn.sap.com/irj/sdn/pi, 2007
SCNXI07 SAP Community Network: NetWeaver Exchange Infrastructure,
https://www.sdn.sap.com/irj/sdn/xi, 2007
SGNXI07 SAP Germany: NetWeaver Exchange Infrastructure,
http://www.sap.com/germany/plattform/netweaver/components/
exchangeinfrastructure/index.epx, 2007
TCHB06 SQL GmbH: TransConnect® - Die Integrationsplattform, Version 1.3.5,
Handbuch, 07/2006
Literaturverzeichnis
99
UML07 Object Management Group: Unified Modeling Language (UML),
Version 2.1.1, http://www.omg.org/technology/documents/formal/uml.htm,
Februar 2007
WSIL07 IBM, Microsoft: Web Services Inspection Language,
http://www.ibm.com/developerworks/library/specification/ws-wsilspec/,
Januar 2007
Erklärungen
100
Erklärungen
Erklärung über Nutzung und Verantwortung
Nach § 24 Abs. 14 ADPO räume ich der Hochschule ein einfaches Nutzungsrecht an
der Diplomarbeit für Lehre und Forschung ein.
Selbständigkeitserklärung
"Ich versichere, dass ich die Diplomarbeit selbständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt habe."
Dresden, den 15.10.2007
_______________________
Ralf Winter