Fachbereich Informatik/Mathematik - htw-dresden.dewloka/pubs/DA_winter.pdfHochschule für Technik...

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


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


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


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


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.


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>


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.


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


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.


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.


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:


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


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.


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.


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


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.


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


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


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


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:


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)


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


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.


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:


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


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.


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


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.


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.


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


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.


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


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.


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.


35


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


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


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.


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


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.


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


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


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


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.


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


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


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.


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


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


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


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.


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


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.


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


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


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)


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:


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


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.


Process Process Kontextabhängige Übernahme

mit Kindelementen

Scope - Abbildung durch Process


60


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


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.


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


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


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


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.


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.


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.


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


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


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.


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.


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.


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.


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


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.


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.


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.


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:


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()


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


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


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.


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>



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"


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"


inputPart="x"

outputVariable="msg2"

outputPart="y">

<parameter

name="p"

value=""/>*

</translation>

<validate

name="val1"


schemaname=""

expression="">



</validate>

<action name="act1">

java-sourcecode [CDATA]

</action>

Transaktionsorientierte Operatoren

<savepoint

name="save1"

type="CTX | MSG"

inputVariable="msg2">



</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="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;





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);


msg2 = node3.execute(msg1);

setNID(4);

/*INVOKE pattern*/

try

{

Invoke node4 = new Invoke("cust01", "GETACC");


node4.setTransactionManager(_pctx.getTransactionManager());


}

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);



Anhang

92

setNID(6);

/*INVOKE pattern*/

try

{

Invoke node6 = new Invoke("syb01", "Insert");




}


{

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.execute(); //throws MTMSignalException

}

else

{

setNID(8);

/*SIGNAL (help) pattern*/

Signal node8 = new Signal(Signal.EXIT);

Anhang

93


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");




}


{

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


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


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


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

Fachbereich Informatik/Mathematik - htw-dresden.dewloka/pubs/DA_winter.pdfHochschule für Technik...

Documents

Transcript of Fachbereich Informatik/Mathematik - htw-dresden.dewloka/pubs/DA_winter.pdfHochschule für Technik...