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

Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik

Diplomarbeit im Studiengang Wirtschaftsinformatik

Thema:

Untersuchung der Funktionalitäten der Business Process Execution Language

(BPEL)

Nachrichtentransformationen

zur

Beschreibung

dargestellt

am

TransConnect

eingereicht von:

Matthias Böhm

eingereicht am:

01.09.2006

Betreuer:

Prof. Dr. rer. oec. habil. Uwe Wloka (HTW Dresden) Prof. Dr.-Ing. Wolfgang Lehner (TU Dresden) Dipl.-Ing. oec. Jürgen Bittner (SQL GmbH)

komplexer Beispiel

von

Inhaltsverzeichnis

Inhaltsverzeichnis Inhaltsverzeichnis ................................................................................................................. I Glossar .................................................................................................................................IV Abbildungsverzeichnis .......................................................................................................VI Tabellenverzeichnis ............................................................................................................IX Abkürzungsverzeichnis ....................................................................................................... X 1

Einleitung ........................................................................................................................ 1 1.1 Ausgangssituation und Motivation.......................................................................... 1 1.2 Zielstellungen und Perspektiven der Diplomarbeit ................................................. 2 1.3 Aufbau der Diplomarbeit......................................................................................... 4

2

Grundlegende Technologien und Analyseergebnisse.................................................. 6 2.1 Unterscheidung von Integrationsformen ................................................................. 6 2.2 Enterprise Application Integration (EAI) ................................................................ 9 2.3 Service Oriented Architecture (SOA).................................................................... 12 2.3.1 XML-Sprachspezifikationen ..................................................................... 12 2.3.2 Web-Services............................................................................................. 16 2.3.3 Enterprise Service Bus (ESB).................................................................... 27 2.4 Business Process Management (BPM).................................................................. 31 2.5 TransConnect Anforderungsanalyse...................................................................... 34 2.5.1 Das Produkt TransConnect im Überblick.................................................. 34 2.5.2 Istzustandsanalyse ..................................................................................... 35 2.5.3 Sollanalyse und allgemeine Anforderungen.............................................. 40

3

Business Process Execution Language (BPEL) und deren Alternativen................. 43 3.1 Entwicklung der Sprachspezifikationen ................................................................ 45 3.2 WSBPEL 2.0 ......................................................................................................... 48 3.2.1 Überblick und Ziele ................................................................................... 48 3.2.2 Struktur eines BPEL-Prozesses ................................................................. 50 3.2.3 Ausgewählte Aspekte der Verarbeitung .................................................... 60 3.3 Spracherweiterungsvorschläge für WSBPEL........................................................ 65 3.3.1 BPEL for Java (BPELJ)............................................................................. 65 3.3.2 WSBPEL Extension for people (BPEL4people) ....................................... 69 3.3.3 WSBPEL Extension for Sub-processes (WSBPEL-SPE) ......................... 72 3.3.4 Information Integration for BPEL (II4BPEL) ........................................... 74 3.4 Produktvergleich aktueller BPEL-Implementationen ........................................... 77 3.5 Alternative Beschreibungssprachen ...................................................................... 79 3.5.1 Unified Modeling Language 2.0 (UML) Aktivitätsdiagramme ................ 80 3.5.2 Business Process Modelling Notation (BPMN) ........................................ 82

I

Inhaltsverzeichnis

3.5.3 Web Service Choreography Description Language (WS-CDL) ............... 84 3.5.4 XML Process Definition Language (XPDL)............................................. 85 3.5.5 ebXML Business Process Specification Schema (ebBP) .......................... 87 4

Nachrichtentransformationsmodell ............................................................................ 90 4.1 Inhalt und Abgrenzung .......................................................................................... 90 4.2 Anforderungen an ein Transformationsmodell...................................................... 92 4.2.1 Funktionale Anforderungen....................................................................... 93 4.2.2 Nicht-Funktionale Anforderungen .......................................................... 103 4.3 Definition des Message Transformation Model (MTM) ..................................... 110 4.3.1 Einordnung des Modells.......................................................................... 110 4.3.2 Definition des konzeptuellen Nachrichtenmodells.................................. 113 4.3.3 Definition des konzeptuellen Prozessmodells ......................................... 116 4.4 Analyse und Optimierung von Transformationsprozessen ................................. 134 4.4.1 Regelbasierte Analyse und Optimierung................................................. 135 4.4.2 Einführung eines Kostenmodells............................................................. 137 4.4.3 Kostenbasierte Optimierung .................................................................... 141

5

Beschreibung von Nachrichtentransformationen mit WSBPEL ........................... 148 5.1 Generelle Beschreibungsansätze ......................................................................... 148 5.2 Beschreibung des Message Transformation Model (MTM) mit WSBPEL ........ 154 5.2.1 Beschreibung des konzeptuellen Nachrichtenmodells ............................ 155 5.2.2 Beschreibung des konzeptuellen Prozessmodells.................................... 156 5.3 Bewertung von BPEL.......................................................................................... 161 5.3.1 Bewertungskriterien................................................................................. 162 5.3.2 Bewertung aus unterschiedlichen Perspektiven ...................................... 165

6

Prototypische Realisierung am Beispiel von TransConnect................................... 169 6.1 Entwurf ................................................................................................................ 169 6.1.1 Architekturentwurf TransConnect 2.0 Server ......................................... 171 6.1.2 Datenbankentwurf TransConnect 2.0 DataStore ..................................... 185 6.1.3 Definition von Maßnahmen zur Qualitätssicherung................................ 192 6.2 Implementierung.................................................................................................. 196 6.2.1 Implementierung der WorkflowProcessEngine....................................... 196 6.2.2 Ausgewählte Verarbeitungsaspekte......................................................... 201 6.2.3 Stand der Realisierung und offene Problemstellungen............................ 212 6.3 Beispielszenario “ETL-Prozess” ......................................................................... 214 6.3.1 Einführung in das Beispielszenario ......................................................... 215 6.3.2 Transformationsprozesse des Beispielszenarios...................................... 218

7

Zusammenfassung und Ausblick .............................................................................. 226 7.1 Zusammenfassung der Ergebnisse....................................................................... 226 7.2 Schlussfolgerungen.............................................................................................. 227 7.3 Ausblick............................................................................................................... 228

II

Inhaltsverzeichnis

Anhang............................................................................................................................... 230 A Metagrammatik von WSBPEL 2.0 ........................................................................... 230 B Metagrammatik der internen XML-Beschreibung des MTM................................... 237 C Relationenmodell des TransConnect DataStore ....................................................... 241 D Physischer Datenbankentwurf des TransConnect DataStore ................................... 242 E Schemata des Beispielszenarios................................................................................ 245 F WSBPEL-Transformationsprozesse des Beispielszenarios ...................................... 249 G Inhaltliche Struktur der beiliegenden DVD .............................................................. 251 Literaturverzeichnis ......................................................................................................... 252 Erklärungen ...................................................................................................................... 260 Erklärung über Nutzung und Verwertung .................................................................... 260 Selbständigkeitserklärung............................................................................................. 260

III

Glossar

Glossar Adapter

Eine Software-Komponente, welche die Interoperabilität verschiedener Systeme ermöglicht. Hierbei wird zwischen InboundAdaptern (Interaktion vom Fremdsystem initiiert) und OutboundAdaptern (Interaktion vom aktuellen System initiiert) unterschieden.

Choreografie

Art der Komposition, wobei die dezentrale Interaktion von Diensten mit einer nicht ausführbaren Prozessbeschreibungssprache aus einer globalen Sicht beschrieben wird.

Instrumentierung

Meint die Erweiterung von Programmpfaden um zusätzliche Komponenten die der Analyse nach der Ausführung dienen. Diese, auch als Instrumentalisierung bezeichnete, Vorgehensweise kommt vor allem im Gebiet des Compilerbaus zum Einsatz.

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.

Echtzeit

Echtzeitbetrieb ist ein Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten ständig derart betriebsbereit sind, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. [DIN 44300]

Enterprise Service Bus

Ein nachrichtenbasiertes und ereignisgesteuertes MiddlewareSystem, welches durch eine Dezentralität der Infrastruktur und Zentralität der Konfiguration gekennzeichnet ist und eine, weitestgehend auf Standards basierende, Dienstorchestrierung ermöglicht.

Komposition

Zusammensetzung eines Dienstes aus mehreren bestehenden Diensten mit einer Prozessbeschreibungssprache. Arten der Komposition stellen die Orchestrierung und die Choreografie dar.

Message Transformation Model

Das MTM ist ein konzeptuelles, graphorientiertes Modell zur Beschreibung von Transformationsprozessen der komplexen Nachrichtentransformation und gliedert sich in ein Nachrichtenmodell und ein Prozessmodell.

IV

Glossar

Nachrichtentransformation

Beschreibt die Transformation von Nachrichten als Spezialfall der Datentransformation, wobei zwischen elementarer (syntaktische Transformationen) und komplexer (semantische Transformationen als Folge von Prozessschritten) Nachrichtentransformation unterschieden werden muss.

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.

Process Engine

Software-Komponente zur Erzeugung und Ausführung von Prozessinstanzen eines, mit einer Prozessbeschreibungssprache modellierten, Prozesses.

Prozess

Beschreibung des beschreibungssprache. bezeichnet.

Prozessbeschreibungssprache

Eine derartige Sprache kann als Metamodell zur Beschreibung von teilweise automatisierten Geschäftsprozessen in Form einer Folge von Prozessschritten verstanden werden. Typische Ausprägungen solcher Sprachen sind graphische Ausdrucksformen oder XMLSchemata.

Prozessinstanz

Instanz eines modellierten Prozesses, die ausführbar und eineindeutig identifizierbar ist. Sofern der Begriff Prozesstyp verwendet wird, kann hier synonym der Begriff Prozess zum Einsatz kommen.

Transformationsprozess

Spezifikation eines Prozesses zur Beschreibung einer komplexen Nachrichtentransformation als Menge von spezifischen Prozessschritten und funktionalen Abhängigkeiten.

Web-Service

Web-Services sind selbstbeschreibende, gekapselte SoftwareKomponenten, die eine Schnittstelle anbieten, über die ihre Funktionen entfernt aufgerufen und die lose durch den Austausch von Nachrichten miteinander gekoppelt werden können. [GIEVDE]

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.

Prozessablaufs mit einer ProzessWird synonym auch als Prozesstyp

V

Abbildungsverzeichnis

Abbildungsverzeichnis Abbildung 1: Abbildung 2: Abbildung 3: Abbildung 4: Abbildung 5: Abbildung 6: Abbildung 7: Abbildung 8: Abbildung 9: Abbildung 10: Abbildung 11: Abbildung 12: Abbildung 13: Abbildung 14: Abbildung 15: Abbildung 16: Abbildung 17: Abbildung 18: Abbildung 19: Abbildung 20: Abbildung 21: Abbildung 22: Abbildung 23: Abbildung 24: Abbildung 25: Abbildung 26: Abbildung 27: Abbildung 28: Abbildung 29: Abbildung 30: Abbildung 31: Abbildung 32: Abbildung 33: Abbildung 34: Abbildung 35: Abbildung 36: Abbildung 37: Abbildung 38: Abbildung 39: Abbildung 40: Abbildung 41:

Dimensionen der Integrationsformen .......................................................... 7 Integrationsepochen..................................................................................... 8 Topologien der Anwendungsintegration ................................................... 10 Erweiterte EAI-Referenzarchitektur nach [KELL02] ............................... 11 XML Sprachspezifikationen nach [LESC04]............................................ 13 XSL-Transformation eines XML-Dokumentes......................................... 15 STX-Transformation eines XML-Dokumentes......................................... 16 Abstrakter Aufbau eines Web-Service nach [SOCO06] ........................... 19 Aufrufarchitektur von Web-Services......................................................... 20 Web-Service Protokollstapel ..................................................................... 21 Aufbau eines WSDL-Dokumentes ............................................................ 22 Aufbau eines UDDI-Verzeichnisses.......................................................... 24 Aufbau einer SOAP-Nachricht.................................................................. 25 Topologie eines Enterprise Service Bus.................................................... 30 Logischer Aufbau eines Enterprise Service Bus ....................................... 30 Workflow Referenzmodell der WfMC [WFMC95].................................. 33 Überblick der Gesamtarchitektur von TransConnect nach [TCHB06] ..... 35 Teilkomponenten von TransConnect 1.3.4................................................ 36 Aufbau des TransConnect-Servers ............................................................ 36 Common Client Interface (CCI) nach [TCWS05]..................................... 38 Datenmodell des TransConnect-Datastore ................................................ 39 Varianten der Web-Service-Komposition ................................................. 45 Entwicklung der Sprachspezifikationen .................................................... 46 Grundstruktur eines BPEL-Prozesses........................................................ 51 Verwaltung von BPEL-Prozessinstanzen.................................................. 60 Identifikationsmechanismus von BPEL-Prozessinstanzen........................ 61 Parallelverarbeitung in WSBPEL.............................................................. 62 Fehlerbehandlung und Kompensation in BPEL-Prozessen....................... 63 Orchestrierung von Java-Komponenten .................................................... 68 Interaktionsmöglichkeiten zwischen Prozess und Aufgabe ...................... 72 Aufrufszenarien in WSBPEL-SPE ............................................................ 73 Funktionsweise der II4BPEL Data Management Activities...................... 76 Klassifizierung der Alternativen zu WSBPEL .......................................... 80 Ebenen der Choreografie bei WS-CDL..................................................... 85 Metamodell der XPDL-Prozessdefinition [XPDL05] ............................... 86 Sprachkomponenten von ebXML BPSS ................................................... 88 Beliebig viele Quell- und Zielsysteme ...................................................... 94 Verarbeitungsmodelle................................................................................ 95 Content Based Routing.............................................................................. 96 Ansätze der Nachrichtengranularität ......................................................... 97 Hinzufügen von Knoten............................................................................. 99

VI

Abbildungsverzeichnis

Abbildung 42: Abbildung 43: Abbildung 44: Abbildung 45: Abbildung 46: Abbildung 47: Abbildung 48: Abbildung 49: Abbildung 50: Abbildung 51: Abbildung 52: Abbildung 53: Abbildung 54: Abbildung 55: Abbildung 56: Abbildung 57: Abbildung 58: Abbildung 59: Abbildung 60: Abbildung 61: Abbildung 62: Abbildung 63: Abbildung 64: Abbildung 65: Abbildung 66: Abbildung 67: Abbildung 68: Abbildung 69: Abbildung 70: Abbildung 71: Abbildung 72: Abbildung 73: Abbildung 74: Abbildung 75: Abbildung 76: Abbildung 77: Abbildung 78: Abbildung 79: Abbildung 80: Abbildung 81: Abbildung 82: Abbildung 83: Abbildung 84: Abbildung 85: Abbildung 86:

Entfernen von Knoten.............................................................................. 100 Alternativen der Validierung von Nachrichten ....................................... 102 Kanonisches Datenmodell ....................................................................... 104 Transaktionssicherheit ............................................................................. 107 Reduzierung des Änderungsaufwandes................................................... 108 Adaptierte 3-Schichten-Architektur ........................................................ 112 Aufbau des konzeptuellen Nachrichtenmodells ...................................... 114 Entwurfsdimensionen des Prozessmodells.............................................. 117 Art des Prozessmodells............................................................................ 118 Orientierung des Prozessmodells............................................................. 119 Repräsentation des Prozessmodells ......................................................... 119 Grundmodell – „Gerichteter Graph“ ....................................................... 121 Zusammenhänge von Mustern anderer Quellen...................................... 122 Vorgehensweise bei der Analyse und Optimierung ................................ 135 Kostenaufteilung innerhalb einer MOM-Referenzarchitektur ................ 138 Filtern von Nachrichteninhalten .............................................................. 143 Verarbeitung einer Nachrichtenmenge.................................................... 144 Überführung externer Datenrepräsentationen ......................................... 146 Elementarmuster-Ansatz ......................................................................... 149 Komplexmuster-Ansatz ........................................................................... 150 Prozess-Ansatz......................................................................................... 152 Dienst-Ansatz .......................................................................................... 153 XML-Schema Darstellung einer Nachricht............................................. 155 SWOT-Analyse WSBPEL 2.0................................................................. 168 Teilkomponenten von TransConnect 2.0................................................. 170 Adapterspezifische Workflow-Integration .............................................. 172 Workflow zwischen MessageQueue und Outbound-Adaptern ............... 172 Workflow zwischen Inbound- und Outbound-Adaptern ......................... 173 Architekturentwurf TransConnect 2.0 Server ......................................... 174 Adapterformen in TransConnect 2.0 ....................................................... 175 Message Konzept..................................................................................... 176 Entwurf WFPE: Aufbau der Core Engine ............................................... 178 Entwurf WFPE: logische Stratifizierung des Process Parser .................. 179 Entwurf WFPE: Aufbau des Process Parser............................................ 181 Entwurf WFPE: Aufbau des ServiceDictionary ...................................... 182 Entwurf WFPE: Aufbau der Runtime Environment................................ 183 Realisierung des MTM Prozessmodells .................................................. 184 Vorgehensweise beim Datenbankentwurf ............................................... 186 TransConnect DataStore – Entity Relationship Model ........................... 188 Entwurf der TransConnect Testsuite ....................................................... 194 Zustandsdiagramm der Klasse MessageDataTable ................................. 203 Überführung von externen Daten in das interne Format ......................... 204 Überführung des internen Formats in eine persistente Repräsentation ... 205 Einsatz des NodeID-Konzeptes für den Recovery-Prozess..................... 209 Verteilungsaspekte in TransConnect-Clustern ........................................ 211

VII

Abbildungsverzeichnis

Abbildung 87: Abbildung 88: Abbildung 89: Abbildung 90: Abbildung 91: Abbildung 92: Abbildung 93: Abbildung 94: Abbildung 95: Abbildung 96: Abbildung 97: Abbildung 98: Abbildung 99: Abbildung 100: Abbildung 101:

Betriebswirtschaftlicher Kontext des Beispielsszenarios ........................ 216 Systemarchitektur des Beispielszenarios................................................. 217 Untergliederung des Beispielszenarios in Teilprozesse .......................... 219 Transformationsprozess bs_process1_async ........................................... 220 Transformationsprozess bs_process1_sync............................................. 221 Transformationsprozess bs_process2 ...................................................... 222 Transformationsprozess bs_process3 ...................................................... 224 XML-Schema Einkauf............................................................................. 246 XML-Schema Vertrieb ............................................................................ 247 Relationenmodell CRM-DB .................................................................... 247 Relationenmodell TPCH-Benchmark nach [TPCH05] ........................... 248 WSBPEL-Transformationsprozess bs_process1_async .......................... 249 WSBPEL-Transformationsprozess bs_process1_sync............................ 249 WSBPEL-Transformationsprozess bs_process2 ..................................... 250 WSBPEL-Transformationsprozess bs_process2 ..................................... 250

VIII

Tabellenverzeichnis

Tabellenverzeichnis Tabelle 1: Tabelle 2: Tabelle 3: Tabelle 4: Tabelle 5: Tabelle 6: Tabelle 7: Tabelle 8: Tabelle 9: Tabelle 10: Tabelle 11: Tabelle 12: Tabelle 13: Tabelle 14: Tabelle 15: Tabelle 16: Tabelle 17: Tabelle 18: Tabelle 19: Tabelle 20:

Alternative Web-Service Protokolle nach [BIRO03] ............................... 26 Anforderungen an TransConnect 2.0 ........................................................ 41 Ziele des Sprachentwurfs von WSBPEL 2.0 nach [BPEL06] .................. 50 Überblick BPEL-Aktivitäten .................................................................... 54 Elemente eines UML 2.0 Aktivitätsdiagramms nach [UML05]............... 82 Elemente eines BPMN 1.0-Diagrammes nach [BPMN06]....................... 83 Ebenen der Transformation nach [HOH04].............................................. 92 ACID-Eigenschaften im Kontext der Nachrichtentransformation.......... 105 Musterkatalog des konzeptuellen Prozessmodells.................................. 124 TypI-Anomalien...................................................................................... 136 TypII-Anomalien .................................................................................... 137 Abbildung der interaktionsorientierten Muster....................................... 158 Abbildung der kontrollflussorientierten Muster ..................................... 159 Abbildung der datenflussorientierten Muster ......................................... 161 Allgemeine Bewertungskriterien von Prozessbeschreibungssprachen ... 164 Einschätzung von WSBPEL ................................................................... 166 Package-Grobstruktur der Workflow Process Engine ............................ 197 Datenschemata des Beispielszenarios..................................................... 245 Hierarchische Struktur des IDOC-Typen DEBMAS05 nach [SAPIFR] 246 Inhaltliche Struktur der beiliegenden DVD ............................................ 251

IX

Abkürzungsverzeichnis

Abkürzungsverzeichnis ACID

Atomicity Consistency Integrity Durability

ALE

Application Link Enable

ANSI

American National Standards Institution

BLOB

Binary Large Object

BMI

Business Modeling & Integration (BMI) Domain Task Force (DTF)

BPEL

Business Process Execution Language

BPEL4people

BPEL Extension for people

BPEL4SQL

BPEL Extension for SQL

BPEL4WS

Business Process Execution Language for Web Services

BPELJ

BPEL for Java

BPMN

Business Process Modeling Notation

BPM

Business Process Management

CCI

Common Client Interface

CLOB

Character Large Object

CMS

Content Management System

CORBA

Common Object Request Broker Architecture

CPA

Collaboration Protocol Agreement

CPP

Collaboration Protocol Profile

CSV

Colon Separated Values

DAO

Data Access Objects

DBMS

Datenbank Management System

DCOM

Distributed Component Object Model

DDL

Data Description Language

DMA

Data Management Activity

DML

Data Manipulation Language

DOM

Document Object Model

DTD

Document Type Definition

EAI

Enterprise Application Integration

ebXML BPSS

Electronic Business using XML Business Process Specification Schema

EDA

Enterprise Data Access

X

Abkürzungsverzeichnis

EJB

Enterprise Java Bean

ERM

Entity Relationship Model

ERP

Enterprise Resource Planning

ESB

Enterprise Service Bus

ESQL

Extended Structured Query Language

ETL

Extraction Transformation Loading

FXT

Functional XML Transformation

GTL

Generic Template Language

HTTP

HyperText Transfer Protocol

IDE

Integrated Development Environment

IDL

Interface Definition Language

II4BPEL

Information Integration for BPEL

IMA

Inbound Message Actitvity

JDBC

Java DataBase Connectivity

J2EE

Java 2 Enterprise Edition

JCA

Java Connector Architecture

JMS

Java Message Services

JSR

Java Specification Request

JUDDI

Java Universal Description, Discovery and Integration

JVM

Java Virtual Machine

MAD

Molekül-Atom-Datenmodell

MDR

MetaData Repository

MMDBMS

Main Memory DBMS

MTM

Message Transformation Model

OASIS

Organization for the Advancement of Structured Information Standards

ODS

Opertional DataStore

OEM

Object Exchange Model

OMG

Object Management Group

QoS

Quality of Service

RDBMS

Relational DataBase Management System

RM

Relationenmodell

RMI

Remote Method Invocation

SAP XI

SAP eXchange Infrastructure

XI

Abkürzungsverzeichnis

SAX

Simple API for XML

SDL

Data Storage Definition Language

SGML

Standard Generalized Markup Language

SOA

Service Oriented Architecture

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

STX

Streaming Transformation for XML

SWOT

Strength Weaknesses Opportunities Threats

TPC-H

Transaction Processing Council

UDDI

Universal Description, Discovery and Integration

UDT

User Defined Type

UML

Unified Modelling Langugae

UN/CEFACT

United Nations – Centre for Trade Facilitation and Electronic Business

URI

Uniform Resource Identifier

VDB

Virtual Database

W3C

World Wide Web Consortium

WAPI

Workflow Application Programming Interface

WfMC

Workflow Management Coalition

WFMS

Workflow Management System

WFPE

Workflow Process Engine

WS-CAF

Web Services Composite Application Framework

WS-CDL

Web service Choreography Description Language

WSBPEL

Web Service Business Process Execution Language

WSBPEL-SPE

WSBPEL Extension for Subprocesses

WSDL

Web Services Definition Language

WSFL

Web Services Flow Language

WSIL

Web Services Inspection Language

XLANG

Web Services for Business Process Design

XML

Extensible Markup Language

XPDL

XML Process Definition Language

XSL-FO

Extensible Stylesheet Language Formatting Objects

XSLT

Extensible Stylesheet Language for Transformation

YAT

Yet Another Tree-based Data Model

XII

1 Einleitung

1

Einleitung

Die horizontale Integration von Systemen durch eine nachrichtenbasierte Kommunikation über Middleware-Systeme stellt eine, sich immer weiter verbreitende, Art der Anwendungsintegration dar, um eine hinreichend lose Kopplung der partizipierenden Systeme und Anwendungen zu gewährleisten. Dies ist wiederum die Grundlage dafür, die IT-Infrastruktur auf dynamische Veränderungen der Geschäftsprozesse flexibel anpassen zu können. Mit der Business Process Execution Language (BPEL) hat sich zwar mittlerweile ein Standard für die Orchestrierung von Web-Services weitestgehend durchgesetzt, jedoch ist im Rahmen dieser Diplomarbeit zu untersuchen, ob dieser funktional-orientierte Sprachstandard auch zur Beschreibung von komplexen Nachrichtentransformationen in datenzentrischen Prozessen geeignet ist. Die Konzepte, Modelle und prototypischen Realisierungen sollen hierbei am Beispiel der Integrationsplattform TransConnect der Firma SQL GmbH veranschaulicht werden.

1.1

Ausgangssituation und Motivation

Der Standard BPEL wurde aktuell in einer stark überarbeiteten Form als WSBPEL 2.0 veröffentlicht und wird derzeit als beste Lösung auf dem Gebiet der Dienst-Orchestrierung angesehen. Hierbei wird eine Menge von Dienstaufrufen in einem Prozess spezifiziert und innerhalb einer BPEL-Implementation zur Ausführung gebracht. Trotzdem existieren weiterführende Spracherweiterungsvorschläge und alternative Beschreibungssprachen. Neben

der

eigentlichen

Dienstorchestrierung

werden

jedoch

auch

in

anderen

Anwendungsgebieten derartige Prozesse mit einer Menge von Teilschritten und der Angabe von funktionalen Abhängigkeiten spezifiziert. Somit liegt die Anwendung von BPEL in angrenzenden Gebieten wie der Geschäftsprozessmodellierung, der Simulation und eben auch der Nachrichtentransformation nahe. Dies hätte den Vorteil zum einen existente Modellierungswerkzeuge wiederverwenden zu können und darüber hinaus einen

1

1 Einleitung

anerkannten Standard für die Prozessbeschreibung, mit all den Vorzügen wie Portabilität und Erlernbarkeit, zu nutzen. Aus dieser Überlegung heraus soll im Rahmen der Weiterentwicklung des Produktes TransConnect, WSBPEL zur Beschreibung komplexer Nachrichtentransformationen in datenzentrischen Prozessen eingesetzt werden. Hierbei wird TransConnect von der Version 1.3.x zu TransConnect 2.0 weiterentwickelt, wobei eine grundlegende Architekturänderung erfolgen soll. Bislang existieren lediglich fest implementierte Workflows welche über Konfigurationen hinsichtlich spezifischer Quell- und Zielsysteme anpassbar sind, jedoch im Rahmen der komplexen Nachrichtentransformation keine ausreichende Flexibilität gewährleisten. Die komplexe Nachrichtentransformation soll in diesem Kontext als Gesamtheit aller Verarbeitungsaspekte einer Nachricht in Integrationsprozessen verstanden werden. Zwar existieren ausgereifte Technologien für elementare Transformationsschritte, jedoch fehlt es an einem fundierten Modell für die komplette Spezifikation derartiger datenzentrischer Transformationsprozesse. Ein derartiges konzeptuelles Modell muss analog zu BPEL die umfangreichen Möglichkeiten der Spezifikation des Kontrollflusses abbilden. Im Gegensatz zu BPEL ist jedoch, möglichst ohne von der Standardisierung abzuweichen, vor allem die Möglichkeit der Abbildung komplexer Datenflüsse ebenfalls zu berücksichtigen. Sofern das Modell hinreichend generisch definiert wird, ist der Einsatz in EAI-, ETL- und MessagingMiddleware-Lösungen denkbar, da hier ähnliche Prozesse jedoch mit unterschiedlichen Schwerpunkten Gegenstand der Betrachtung sind.

1.2 Auf

Zielstellungen und Perspektiven der Diplomarbeit Grund

der

dargestellten

Ausgangssituation

und

Motivation

ergeben

sich

unterschiedliche Zielstellungen und damit auch Perspektiven der Diplomarbeit. Diese gilt es zunächst genauer zu identifizieren und anschließend exakt zu differenzieren. Prinzipiell sind hierbei die vier folgenden Perspektiven zu unterscheiden.

2

1 Einleitung

•

Theoretische Untersuchung der Funktionalitäten von WSBPEL

•

Systematische und strukturierte Modellbildung für Nachrichtentransformationen

•

Einschätzung, ob WSBPEL zur Beschreibung des Modells geeignet ist

•

Nachweis der Realisierbarkeit des Modells am Beispiel von TransConnect

Die Perspektive der theoretischen Untersuchung der Funktionalitäten von WSBPEL umfasst die prinzipielle Analyse der Beschreibung und Verarbeitung von WSBPELProzessen, wobei die aktuelle Sprachspezifikation WSBPEL 2.0 Gegenstand der Betrachtung sein soll. Darüber hinaus sind jedoch auch Spracherweiterungen und alternative Beschreibungssprachen

auf

dem Gebiet

der

Prozessbeschreibung

zu

berücksichtigen, um WSBPEL in diesem Kontext auch adäquat einordnen zu können. Im Rahmen der systematischen und strukturierten Modellbildung soll dann zunächst ein konzeptuelles Modell für komplexe Nachrichtentransformationen entwickelt werden, welches sich weniger an WSBPEL, als viel mehr an den Anforderungen für derartige Prozessbeschreibungen orientiert. Dabei ist zwar das Zusammenspiel externer und interner Repräsentationen herauszustellen, die Verbindung zu dem Produkt TransConnect soll jedoch auf dieser Ebene explizit nicht betrachtet werden. Die beiden ersten Perspektiven sind dann in der dritten Perspektive, der Einschätzung ob BPEL

zur

Beschreibung

des

definierten

Modells

geeignet

ist,

bewertend

zusammenzuführen. Dabei ist zu untersuchen, inwieweit BPEL als Sprache zur Beschreibung von Transformationsschritten geeignet ist, beziehungsweise einen Vorschlag zu unterbreiten mit einer Aussage, welche Bestandteile notwendig sind oder an welchen Stellen die Sprache erweitert werden müsste. Die vierte Perspektive widmet sich der prototypischen Realisierung des definierten Modells in TransConnect. Dies soll die Umsetzbarkeit der theoretischen Betrachtungen praktisch nachweisen. Hierbei ist jedoch nicht nur das selbstdefinierte Modell zu verwirklichen, sondern vielmehr ein Architekturentwurf für die Kernkomponenten von TransConnect 2.0 zu unterbreiten und für diese dann eine prototypische Implementation vorzunehmen. Die Aspekte des konzeptuellen Modells und die Funktionalität des Prototyps sind durch die Spezifikation von Transformationsschritten in einem gewählten Szenario zu verdeutlichen.

3

1 Einleitung

1.3

Aufbau der Diplomarbeit

Der Aufbau der Arbeit orientiert sich inhaltlich an den beschriebenen Zielstellungen und Perspektiven der Diplomarbeit. Es wird eine Strukturierung in sieben Kapitel vorgenommen. Referenzen zwischen diesen folgen dabei einer ebenenabhängigen Bezeichnung. So wird durchgängig eine Unterscheidung zwischen Kapitel (Ebene 1), Teilkapitel (Ebene 2) und Abschnitt (Ebene 3) getroffen. Neben dieser Einleitung dient das Kapitel 2 der Einführung in grundlegende Technologien und Architekturprinzipien. In dieses Kapitel wurde außerdem die Anforderungsanalyse von TransConnect eingegliedert, da diese natürlich Einfluss auf die spätere konzeptuelle Modellbildung hat. Das Kapitel 3 befasst sich im Wesentlichen mit der Perspektive der theoretischen Untersuchung der Funktionalitäten von WSBPEL. Hierbei wird zunächst die zeitliche Entwicklung

von

BPEL

berücksichtigt

und

in

den

Kontext

der

Prozessbeschreibungssprachen eingeordnet. Ferner ist natürlich WSBPEL 2.0 als aktuelle Version des Sprachstandards zu analysieren. Da mittlerweile eine Reihe von Spracherweiterungen vorgeschlagen wurden, ist auch auf diese näher einzugehen, sowie ein kurzer Überblick über BPEL-Implementationen zu geben. Diese Perspektive wird mit der Betrachtung von alternativen Beschreibungssprachen abgerundet. Während bis zu diesem Punkt im Prinzip Gegebenes analysiert und untersucht wurde, folgt im Kapitel 4 die Definition eines konzeptuellen Nachrichtenmodells für komplexe Nachrichtentransformationen im Rahmen der Perspektive der systematischen und strukturierten Modellbildung für Nachrichtentransformationen. Hierfür muss zunächst der Begriff

der

komplexen

Nachrichtentransformation

abgegrenzt

werden,

bevor

Anforderungen an das Modell definiert werden können. Anschließend wird das Message Transformation Model (MTM) im Detail erörtert und definiert. Da der effizienten Verarbeitung von Nachrichten in diesem Kontext eine besonders große Bedeutung zukommt,

wird

das

Kapitel

mit

der

Betrachtung

von

Analyse-

und

Optimierungsmöglichkeiten abgeschlossen. Wie bereits im vorangegangenen Teilkapitel verdeutlicht, soll im Kapitel 5 eingeschätzt

4

1 Einleitung

werden ob WSBPEL zur Beschreibung des Modells geeignet ist. Hierfür werden zunächst generelle Beschreibungsansätze vorgestellt, bevor die Beschreibbarkeit des MTM mit WSBPEL 2.0 diskutiert wird. Im Rahmen dieses Kapitels wird dann letztendlich eine Bewertung von WSBPEL 2.0 aus unterschiedlichen Sichten vorgenommen. Die Ergebnisse der Kapitel 4 und 5 werden im Rahmen der prototypischen Realisierung praktisch umgesetzt. Diese praktische Perspektive der Diplomarbeit wird im Kapitel 6 beschrieben

und

Beispielszenario

beinhaltet nutzt

den

die

Spezifikation

Diskursbereich

des

eines

Beispielszenarios.

„TPC-H“-Benchmarks.

Dieses Um

die

Verständlichkeit zu erhöhen werden alle Beispiele der Diplomarbeit in diesem Kontext modelliert. Im Rahmen dieser Arbeit sollen Quelltexte und Konfigurationsmöglichkeiten weitestgehend vermieden werden. Diese sind im Rahmen des erstellten Prototypen TransConnect 2.0 auf der beiliegenden DVD einzusehen. Abschließend werden im Kapitel 7 die Ergebnisse dieser Arbeit zusammengefasst und ein Ausblick auf Weiterentwicklungen von Sprachstandards und alternativen Technologien gegeben. Zusammenfassend ist also festzustellen, dass die Kapitel 2 und 3 die theoretische Untersuchung von Grundlagen dieser Arbeit adressieren. Aufbauend darauf stehen in den Kapiteln 4 und 5 die eigenen theoretischen Ergebnisse im Mittelpunkt der Betrachtung. Im Kapitel 6 werden dann letztendlich auch die eigenen praktischen Ergebnisse in Form einer prototypischen Realisierung beschrieben. An dieser Stelle sei noch auf die Problematik der Begriffsabbildungen verwiesen. So kann zum einen nicht vollständig auf Anglizismen verzichtet werden, da die Entwicklung von TransConnect ausschließlich in englischer Sprache erfolgt und somit eine Übersetzung an einigen Stellen nur zu Missverständnissen führen würde. Zum anderen wird zwar ein Glossar als Überblick der wichtigsten Begrifflichkeiten angeboten, jedoch sollen die vollständigen Begriffabgrenzungen, auf Grund deren Komplexität, erst in den jeweiligen Kapiteln erfolgen.

5

2 Grundlegende Technologien und Analyseergebnisse

2

Grundlegende Technologien und Analyseergebnisse

In diesem Kapitel wurden die Grundlagen für das Verständnis der Diplomarbeit gelegt. Zum einen wird somit auf relevante Konzepte beziehungsweise Technologien und zum anderen auf die Anforderungsanalyse des Produktes TransConnect eingegangen. Hierbei werden zunächst prinzipiell die Integrationsformen unterschieden. Dem folgt die kurze Erwähnung der Enterprise Application Integration und die ausführliche Betrachtung der Service Oriented Architecture. Außerdem sollen die Grundlagen des WorkflowManagements als Teil des Business Process Managements vorgestellt werden. Dieses Grundlagenkapitel wird dann mit der Darstellung der Ergebnisse der Istzustands- und der Sollanalyse bezüglich der Weiterentwicklung des Produktes TransConnect abgeschlossen.

2.1

Unterscheidung von Integrationsformen

Da diese Arbeit im Kontext von Integrationsszenarien angelegt ist und mit dem Produkt TransConnect, eine so genannte Integrationsplattform, prototypisch erweitert werden soll, bietet sich zunächst die Definition des Begriffes Integration und die anschließende Unterscheidung der Integrationsformen an. Der Begriff der Integration lässt sich dabei auf das lateinische Wort Integer zurückführen, welches in diesem Zusammenhang mit „ganz“ zu übersetzen ist. Somit bezeichnet die Integration die Herstellung eines Ganzen [WIKIDE]. Im übertragenen Sinne ist mit Integration also die globale Zusammenführung lokaler Systeme hinsichtlich bestimmter Integrationsobjekte mit einer festgelegten Integrationsart gemeint. Aufbauend auf diesen Dimensionen: Integrationsobjekt und Integrationsart, können dabei Integrationsformen unterschieden werden. In Bezug auf die Integrationsart wird eine hierarchische Aufteilung entsprechend der Granularität

vorgenommen.

So

unterscheidet

man

zwischen

Prozessintegration,

Anwendungsintegration und Informationsintegration. Die Informationsintegration kann man nun wiederum in Funktions- und Datenintegration differenzieren. Auf die einzelnen

6

2 Grundlegende Technologien und Analyseergebnisse

Integrationsformen, mit Bezug auf die Informationsart, wird im Rahmen der Darstellung der Historie detaillierter eingegangen. Teilweise wird auch die Oberflächenintegration in Form von Portalen, als betriebswirtschaftlich wichtige Integrationsform in die Unterteilung aufgenommen, soll jedoch in dieser Arbeit nicht weiter betrachtet werden. Die Unterteilung nach einem Integrationsobjekt erfolgt nach der Vorgehensweise der Integration. Man unterscheidet dabei zunächst zwischen horizontaler und vertikaler Integration. Bei der horizontalen Integration interagieren zwei Systeme auf gleicher Ebene miteinander, indem sie die angebotenen Schnittstellen nutzen. Ein Beispiel hierfür ist die Kommunikation zwischen zwei eigenständigen WFMS. Bei der vertikalen Integration hingegen, wird eine globale Sicht auf mehrere lokale Systeme erzeugt. Hierbei können, im Gegensatz zur horizontalen Integration, neue Funktionalitäten bzw. Daten erzeugt und angeboten werden. Dabei unterscheidet man zwischen der materialisierten Integration, wobei die Daten redundant an globaler Stelle vorgehalten werden, und der virtuellen Integration, bei der ausschließlich Metadaten global abzulegen sind [HERG03]. Die folgende Abbildung visualisiert die Unterscheidung der Integrationsformen noch einmal.

Im

Weiteren

ist

Abbildung 1:

Dimensionen der Integrationsformen

noch

chronologische

der

Aspekt

der

Entwicklung

der

Integrationsarchitekturen mit in die Betrachtung aufzunehmen. Im Wesentlichen lassen sich dabei vier Epochen identifizieren:

7

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 2:

Integrationsepochen

Die historisch gesehen früheste Integrationsform war die Datenintegration. So entstand die Datenbank-Technologie selbst als Mittel zur Integration, indem die unternehmensweiten Daten in einer Unternehmensdatenbank verwaltet werden sollten. Da jedoch die Anforderungsanalyse und der Entwurf eines solchen ganzheitlichen Datenbestandes nicht bewältigt wurde, entwickelten sich zunehmend dezentrale Datenbestände innerhalb von Unternehmen [BITT05]. Auf Grundlage dieser Situation samt deren Nachteilen, wurden zunehmend verteilte und föderierte Datenbanken untersucht und eingesetzt [DADA96]. So wurden

Datenbestände

auf

Schema-Ebene

in

einer

globalen

Repräsentation

zusammengeführt. In der zweiten Epoche kam es zu einem Wandel hin zur vollständigen Informationsintegration, wobei sowohl Daten als auch Funktionalitäten in einem System integriert wurden. Hier wurde vor allem auf Standardsoftware-Produkte wie z.B. SAP R/3 gesetzt. Auf Grund des fortwährenden Anstieges der Anzahl unterschiedlicher Systeme und Anwendungen in betrieblichen Systemstrukturen war die dritte Epoche vor allem von der Anwendungsintegration geprägt. Dabei liegt der Fokus speziell auf der Integration ähnlicher und sich ergänzender Daten und Funktionalitäten der einzelnen Anwendungen mit Hilfe von EAI-Plattformen. Im Rahmen der Anwendungsintegration kam der Sicherung der Konsistenz eine bedeutende Rolle zu, da hier nicht mehr vertikal sondern horizontal integriert wurde. Die vierte Epoche verkörpert das Aufkommen der Prozessintegration. Hierbei werden verstärkt

SOA-Technologien

eingesetzt.

Die

Kernkomponente

einer

solchen

8

2 Grundlegende Technologien und Analyseergebnisse

Integrationsarchitektur stellt die Process-Engine dar, welche beispielsweise mit WSBPEL beschriebene Prozesse ausführt. Der große Vorteil dieser Architektur ist die rekursive Integrationsmöglichkeit von Prozessen, da sie selbst wieder einen Web-Service darstellen. Somit umschließt die Prozessintegration sowohl horizontale als auch vertikale Integrationsprozesse. Dabei fällt auf, dass eine Korrelation zwischen der Epoche und der Granularität der Informationsform gegeben ist. Allerdings sollte diese Einteilung nicht falsch verstanden werden. So werden Konzepte und Architekturen früherer Epochen selbstverständlich auch in aktuelleren Architekturen weiterhin eingesetzt. Deshalb sind diese Epochen eher als eine Art Schalenmodell zu interpretieren. Auf die beiden historisch jüngsten Integrationsarchitekturen soll im Rahmen der Teilkapitel 2.2 und 2.3 noch einmal detaillierter eingegangen werden. Weiterhin kann bereits festgestellt werden, dass im Rahmen der Diplomarbeit Methoden der Prozessintegration auf die Anwendungs- und Informationsintegration anzuwenden sind.

2.2

Enterprise Application Integration (EAI)

Wie zuvor gehend bereits dargestellt wurde, ist die Anwendungsintegration als eine spezielle Integrationsform zu verstehen, wobei eine Middleware-Plattform: der EAI-Server zur prozessorientierten Integration von heterogenen Anwendungssystemen eingesetzt wird [WIKIDE]. Die wesentlichsten Ziele einer EAI sind nachfolgend kurz aufgeführt und erläutert [HORN06]. •

Erhöhung der Flexibilität Durch die Nutzung existenter Adapter brauchen keine Schnittstellen realisiert, sondern lediglich die EAI-Plattform konfiguriert werden.

•

Kopplung heterogener Softwaresysteme Die

automatisierte

Interaktion

zwischen

Anwendungssystemen

wird

über

9

2 Grundlegende Technologien und Analyseergebnisse

Schnittstellenadapter und Konnektoren für proprietäre Systeme realisiert. •

Datenkonsistenz Bei dieser horizontalen Integration sichert die EAI-Plattform auch die Einhaltung von Quality of Service (QoS) und besonders die Datenkonsistenz und -integrität.

•

Integration statt Migration Auf Grund der hinlänglich bekannten Migrationsprobleme stellt die Integration eine bedeutend einfachere und flexiblere Variante dar. So können aktuelle Systeme in einem Verbund mit Legacy-Systemen genutzt werden.

Bei der Anwendungsintegration unterscheidet man prinzipiell zwei Arten voneinander, die Enterprise Application Integration innerhalb eines Unternehmens und die Business-toBusiness-Integration über Unternehmensgrenzen hinweg [EICH02]. Eines der Wesensmerkmale von EAI ist, dass die Kommunikation nicht mehr direkt, also Peer-to-Peer, zwischen den einzelnen Anwendungen, sondern über eine Hub&SpokeArchitektur, die EAI-Plattform, erfolgt. Diese unterschiedlichen Topologien sind in der nachfolgenden Abbildung noch einmal dargestellt.

Abbildung 3:

Topologien der Anwendungsintegration

Die Grundidee dieser Topologie einer EAI-Plattform ist es, anwendungsspezifische Adapter anzubieten und somit die theoretische Anzahl der notwendigen Schnittstellen und Datentransformationen von n*(n-1) auf 2n zu reduzieren. Leider wird diese Architektur nur in den wenigsten EAI-Plattformen in dieser theoretischen Vollkommenheit realisiert. Oftmals werden innerhalb der EAI-Plattform direkte Transformationen von einer Anwendung zu einer anderen definiert und somit die Peer-to-Peer-Verbindung lediglich in ein zentrales Middleware-System ausgelagert. Dies hat zur Folge, dass die avisierte

10

2 Grundlegende Technologien und Analyseergebnisse

Erhöhung der Flexibilität nur teilweise realisiert wird. Nachdem nunmehr die Ziele und die Topologie von EAI-Lösungen betrachtet wurden, soll an dieser Stelle noch einmal genauer auf den Aufbau einer EAI-Plattform eingegangen werden. Hierfür wird die EAI-Referenzarchitektur nach [KELL02] herangezogen und um spezielle Realisierungsformen erweitert. Die folgende Abbildung zeigt dieses erweiterte Referenzmodell.

Abbildung 4:

Erweiterte EAI-Referenzarchitektur nach [KELL02]

Dabei kann prinzipiell eine Stratifizierung der EAI-Plattform in drei Ebenen festgestellt werden. Auf oberster Ebene ist die Prozessschicht zu nennen, in welcher Konfigurationen und Anweisungen für das Routing, Mapping und den Workflow hinterlegt sind. Dabei handelt es sich hier noch nicht um eine Prozessintegration sondern eher um eine bloße Prozessorientierung. Diese basiert auf der Kommunikationsschicht, welche auf Grund des Ziels der losen Kopplung oftmals nachrichtenorientiert ist. Die wesentlichsten Komponenten dieser Ebene sind der Message Broker und der Operational DataStore. Diese ermöglichen beispielsweise die asynchrone Verarbeitung mittels des Message Queueings. Die unterste Ebene ist die Protokoll-Adapter-Schicht. Diese abstrahiert einzelne Anwendungssysteme durch den Einsatz von generischen Adaptern und die Realisierung von Standard-Schnittstellen. Durch die Entwicklungstendenz hin zu einer serviceorientierten Architektur wird das Gebiet der Enterprise Application Integration neue Perspektiven erhalten. So ist einerseits

11

2 Grundlegende Technologien und Analyseergebnisse

denkbar, dass EAI-Plattformen als Realisierungsgrundlage einer SOA dienen. Andererseits werden natürlich auch die Konzepte und Technologien der SOA eine Veränderung der EAI bewirken. Diese Gebiete schließen einander dabei nicht aus, sondern ergänzen sich vielmehr gegenseitig.

2.3

Service Oriented Architecture (SOA)

Die Serviceorientierte Architektur (SOA) beschreibt im eigentlichen Sinne eine Strategie, die IT-Infrastruktur an den Geschäftsprozessen eines Unternehmens auszurichten. Sie kann also als Paradigma für die Organisation und Nutzung von verteilten Funktionalitäten verstanden werden. Um diese Anforderung zu erfüllen, wird SOA gleichermaßen auch als Beschreibung einer Systemarchitektur

angesehen.

Dabei

interagieren

lose

gekoppelte

Dienste,

nachrichtenbasiert, über definierte Schnittstellen und automatisiert miteinander [WIKIDE]. Ein wichtiger Aspekt der SOA ist, dass keine bestimmten Realisierungen gefordert werden. Somit können neben den Web-Services auch verteilte Komponenten, wie beispielsweise DCOM, CORBA und EJB, zum Einsatz kommen. Allerdings haben sich mittlerweile bereits Realisierungsformen durchgesetzt. So werden vornehmlich XML-basierte Protokolle eingesetzt, weshalb im Abschnitt 2.3.1 die XML Sprachspezifikationen überblicksartig dargestellt werden. Darauf aufbauend haben sich mittlerweile

Web-Services,

inklusive

gewisser

Standardprotokolle,

weitestgehend

durchgesetzt. Diese werden im Abschnitt 2.3.2 näher analysiert. In Bezug auf das Middleware-System, welches die eigentlichen Dienste verwaltet und somit eine SOA erst möglich macht, wird in der Literatur zunehmend der Begriff des Enterprise Service Bus referenziert, so dass dieser im Abschnitt 2.3.3 zu diskutieren ist. 2.3.1

XML-Sprachspezifikationen

An dieser Stelle sind die Grundlagen in Form der XML-Sprachspezifikationen noch einmal

12

2 Grundlegende Technologien und Analyseergebnisse

aufzugreifen und etwas genauer darzustellen. Dabei stellt XML prinzipiell die Voraussetzung einer losen und nachrichtenbasierten Kopplung dar. Die extensible Markup Language (XML) gibt, in Form einer Metasprache, die Regeln zur Definition von anwendungsspezifischen, automatisiert verarbeitbaren Sprachen vor. Der Standard wurde dabei von dem World Wide Web Consortium (W3C), in Anlehnung an die Standard Generalized Markup Language (SGML), spezifiziert [WIKIDE]. Als Merkmale von XML sind weiterhin vor allem die Baumstruktur und die Intention der Trennung von Daten und deren Präsentation aufzuführen. Prinzipiell existieren viele Gemeinsamkeiten zwischen Datenmodellen für semistrukturierte Daten, wie beispielsweise OEM oder YAT, und XML. Dementsprechend kann XML, als strukturtragende Sprache, auch für die Repräsentation von unregelmäßigen Strukturen mit fehlenden oder wiederholten Komponenten eingesetzt werden [GMHW98], [GIEVDE]. Im Weiteren wird ein Überblick über die XML-Sprachspezifikationen gegeben, von denen einige bereits selbst XML-Sprachen darstellen. Die folgende Abbildung, welche in Anlehnung an [LESC04] und [JECK03] erstellt wurde, zeigt zunächst die einzelnen Spezifikationen und deren Zusammenhänge.

Abbildung 5:

XML Sprachspezifikationen nach [LESC04]

Die hierbei grau eingefärbten Elemente stellen nur indirekt mit XML verbundene

13

2 Grundlegende Technologien und Analyseergebnisse

Sprachspezifikationen dar und bleiben deshalb weitestgehend unbeachtet. Einzig die SGML muss an dieser Stelle erwähnt werden, da diese Spezifikation die Grundlage für die Entwicklung von XML dargestellt hat. So wurden auch das Konzept der Document Type Definition, zur Beschreibung der Struktur eines XML-Dokumentes übernommen. Den Kern der XML-Spezifikationen bildet die Meta-Sprache XML sowie XML-Schema und XML-Namespace. Die beiden letzten sind bereits wiederum selbst XML-Sprachen. XML-Schema ersetzt zunehmend die Verwendung von DTD, wobei die Struktur detaillierter und in XML-Form beschrieben wird. Mit XML-Namespace ist eine Möglichkeit gegeben, Konflikte bei der gemeinsamen Verwendung von XML-Sprachen zu vermeiden, indem logische Namensräume für Elemente definiert werden können. Auf diesem Kern bauen nun zwei Arten von Spezifikationen auf. Zum einen sind dies die XML-Sprachen, welche anwendungsseitig genutzt werden. Beispiele hierfür stellen XML Metadata Interchange, zur Übertragung von anwendungsseitigen Metadaten, und die XHTML zur Darstellung von Daten, dar. Zum anderen existieren jedoch auch Spezifikationen welche die Verarbeitung von XML-Dokumenten adressieren. Mit XMLLink können Links auf ein oder mehrere XML-Dokumente beschrieben werden. Darüber hinaus bietet XML Pointer die Möglichkeit bestimmte Marken innerhalb eines XMLDokumentes, auch über Dokumentgrenzen hinweg, zu referenzieren. Eine sehr bedeutsame Spezifikation wurde anfänglich unter dem Namen Extensible Stylesheet Language (XSL) veröffentlicht. Später ist diese in die drei Einzelteile XSL-FO, XSLT und XPath zerlegt worden. XPath stellt dabei eine Anfragesprache für XML-Dokumente zur Extraktion von Teilbäumen aus dem Gesamtbaum und gleichzeitig die Grundlage für XSLT, XQuery und XPointer dar. Die Spezifikation Extensible Stylesheet Language Transformation (XSLT) dient zur Transformation eines XML-Dokumentes entsprechend eines Stylesheets. Im Gegensatz dazu adressiert Extensible Stylesheet Language Formatting Objects (XSL-FO) die grafische Darstellung eines XML-Dokumentes entsprechend eines ähnlichen Stylesheets. Während XPath für die Adressierung von Teilbäumen entworfen wurde, erweitert XQuery diese Spezifikation und stellt eine umfassendere Anfragesprache für XML-Dokumente dar. Da im Kontext der Nachrichtentransformation besonders XSLT interessant ist, soll an

14

2 Grundlegende Technologien und Analyseergebnisse

dieser Stelle noch einmal genauer auf diese Sprachspezifikation eingegangen werden. XSLT transformiert ein Input-Dokument entsprechend eines übergebenen Stylesheets und erzeugt dabei ein verändertes XML-Dokument. Dies ist in nachfolgende Abbildung noch einmal visualisiert.

Abbildung 6:

XSL-Transformation eines XML-Dokumentes

Dabei wird zunächst das XML-Dokument eingelesen und das Document Object Model des Dokumentes im Hauptspeicher aufgebaut, so dass gleichzeitig auf alle Knoten der logischen Baumstruktur zugegriffen werden kann. Anschließend wird auch das StylesheetDokument eingelesen und auf dessen Grundlage das Orginal-DOM transformiert. Das Ergebnis dieser Transformation ist ein verändertes DOM im Hauptspeicher, welches in ein Ausgabe-XML-Dokument geschrieben wird. Hinterfragt man dieses Verarbeitungsmodell kritisch, offenbart sich ein wesentlicher Nachteil. So ist eine Verarbeitung von sehr großen XML-Dokumenten nicht möglich, da die Transformation des Dokumentes erst beginnen kann, wenn das gesamte DOM im Hauptspeicher erzeugt wurde. Damit ist festzustellen, dass XSL-Transformationen nur geringfügig skalierbar sind. Dieser Kritikpunkt war der Ausgangspunkt für Bemühungen hin zu einer datenstromorientierten Transformation von XML-Dokumenten. Im Rahmen der Dissertation [BECK04] wurde dann die XML-Sprache „Streaming Transformation for XML“ (STX) definiert. Die nachfolgende Abbildung zeigt das, gegenüber XSLT veränderte, Verarbeitungsmodell.

15

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 7:

STX-Transformation eines XML-Dokumentes

Im Gegensatz zur Verarbeitung mit XSLT liest der STX-Prozessor zyklisch XMLFragmente aus dem Datenstrom, transformiert diese Teilbäume entsprechend des Stylesheet-Dokumentes und schreibt Teilergebnisse in den Output-Datenstrom. Hierdurch können beliebig große Dokumente verarbeitet werden, wobei die notwendigen Hauptspeicher-Ressourcen allein von der Größe der verarbeiteten Teilbäume abhängen. Somit ist die Forderung nach Skalierbarkeit erfüllt. Allerdings werden dabei Nachteile hinsichtlich Ausdruckskraft und Erstellungsaufwand hingenommen. Auf Grundlage der Notwendigkeit von speziellen Stylesheet-Dokumenten bei der Nutzung von STX, hat sich in der Praxis auch die hybride Transformation mit XSLT/STX verbreitet. Hierbei liest ein STX-Prozessor zyklisch Teilbäume aus einem Datenstrom, übergibt diese als Pakete an einen XSLT-Prozessor, welcher diese entsprechend übergebener xslDokumente transformiert und als Ergebnispakete zurückgibt, und schreibt die Ergebnisse anschließend in den Output-Datenstrom. So können auf der einen Seite existente Stylesheet-Dokumente wiederverwendet und die Ausdrucksstärke von XSLT genutzt werden. Gleichzeitig sind aber auch die Verarbeitungsvorteile von STX anwendbar.

2.3.2

Web-Services

Wie bereits eingangs dargestellt, stellen Web-Services lediglich eine Art der Realisierung einer SOA dar. Der Begriff des “Web-Service” ist zunächst inhaltlich abzugrenzen. So findet man in [JECK04] unter anderem die Definition der Gesellschaft für Informatik zu diesem Thema:

16

2 Grundlegende Technologien und Analyseergebnisse

“Web-Services sind selbstbeschreibende, gekapselte Software-Komponenten, die eine Schnittstelle anbieten, über die ihre Funktionen entfernt aufgerufen, und die lose durch den Austausch von Nachrichten miteinander gekoppelt werden können. [...]“ Gesellschaft für Informatik, [GIEVDE] Da in der Literatur jedoch eine Vielzahl von unterschiedlichen Definitionen und Begriffsabgrenzungen existieren, werden nachfolgend die Haupteigenschaften von WebServices herausgearbeitet um diese zu charakterisieren [BIRO03], [EICH02], [GIEVDE], [HALÖ04], [KÜMP04], [STÖH05], [WELT05], [W3CORG], [WIKIDE]. •

Programmtechnisch zugreifbar Auf Web-Services kann über verschiedene Application Programming Interfaces (APIs) zugegriffen werden. Web-Services sind zur Kommunikation zwischen Software-Komponenten konzipiert, was sie klar von gewöhnlichen WebAnwendungen, die zum Zwecke der Kommunikation zwischen Mensch und Software-Komponenten verwendet werden, abgrenzt. Demzufolge haben WebServices an sich auch kein Graphical User Interface (GUI).

•

Selbstbeschreibend Für jeden Web-Service werden zusätzlich Metadaten vorgehalten, welche den Dienst und dessen korrekte Nutzung beschreiben und durch den Aufrufer auswertbar sind. Typischer Weise werden Dienstname, Dienstbeschreibung, ausführbare Operationen, sowie deren Input- und Output-Parameter verwaltet.

•

Gekapselt Ein Web-Service ist als eine gekapselte Funktionalität zu verstehen, welche auf eine Anfrage hin ausgeführt wird, und dabei entweder einen Informationsdienst oder eine transaktionale Verarbeitung darstellt. In der Regel sind derartige Dienste sehr grobgranular, da die Wiederverwendbarkeit von feingranularen Funktionalitäten ein Irrglaube vergangener Zeiten war.

17

2 Grundlegende Technologien und Analyseergebnisse

•

Lose gekoppelt Der Informationsaustausch zwischen aufrufender Stelle und Web-Service erfolgt über Nachrichtenaustausch. Hierdurch wird eine Implementationsunabhängigkeit erreicht, da der Dienst sowohl plattform- als auch programmiersprachenunabhängig ist.

•

Ortstransparent Web-Services können mit Einschränkungen als ortstransparent und damit auch als verteilte Komponenten, bezeichnet werden, da die aufrufende Anwendung keinerlei statische Informationen über den Standort des Web-Service benötigt. Dies wird durch den Prozess, des dynamischen Auffindens und dem anschließenden Binden des Dienstes, ermöglicht. Es liegt allerdings keine völlige Ortstransparenz vor, da die aufrufende Stelle zwar keine Informationen über den tatsächlichen Standort des Dienstes benötigt, ihr allerdings stets die Tatsache eines entfernten Aufrufes bewusst ist.

•

Protokolltransparent Der Aufruf von Web-Services und die Nachrichtenübermittlung kann über verschiedene Internetprotokolle realisiert werden. Hierbei sind unbedingt die Transportprotokolle von den Nachrichtenprotokollen zu unterscheiden, wobei für beide Typen Nutzungsalternativen existieren. Dennoch haben sich mittlerweile bestimmte Protokolle durchgesetzt und werden deshalb oft fälschlicherweise als die Basisprotokolle für Web-Services bezeichnet.

•

Komponierbar Es ist möglich einen neuen Web-Service per Komposition aus mehreren bestehenden Diensten zu erstellen. Somit kann noch einmal die bereits angesprochene Implementationsunabhängigkeit unterstrichen werden, da für die aufrufende Stelle völlig transparent ist, ob sie mit einem elementaren oder einem zusammengesetzten Dienst arbeitet.

Nachdem nunmehr die Charakteristika von Web-Services genauer bestimmt wurden, ist darauf basierend der Aufbau eines solchen Dienstes zu beschreiben. Dies kann zunächst aus

18

2 Grundlegende Technologien und Analyseergebnisse

einer stark abstrahierten Sicht erfolgen. Ein Dienst ist dabei, wie nachfolgend dargestellt, auf die drei Grundkomponenten Adressbindung, Dienstvertrag und Dienstimplementierung zu reduzieren [SOCO06].

Abbildung 8:

Abstrakter Aufbau eines Web-Service nach [SOCO06]

Wird diese abstrakte Sichtweise vorerst beibehalten, kann man zunächst feststellen [W3CORG], dass auf einen Web-Service über einen so genannten Endpunkt (Service Endpoint oder synonym Port) zugegriffen werden kann. Dieser ist als eine Assoziation zwischen einer spezifizierten Bindung und einer konkreten Netzwerk-Adresse zu verstehen. Die Bindung (Service Interface Binding) stellt wiederum die Verbindung zwischen dem Dienstvertrag, dem verwendeten Protokoll und dem Datenformat für die Übermittlung von Nachrichten mit diesem Web-Service dar. Der Dienstvertrag (Service Interface oder synonym PortType) ist somit eine übertragungsprotokoll- und datenformatunabhängige Schnittstellenspezifikation mit der die Operationen des Web-Service logisch beschrieben werden. An dieser Stelle ist die Analogie zum Vertragskonzept nach B. Meyer der klassischen Client/Server-Architekturen aufzuzeigen [FRIT06]. Dieses Vertragskonzept regelt die Rechte und Pflichten von Kunden (Dienstkonsument) und Lieferanten (Dienstanbieter) mit Hilfe von zwei Zusicherungen. Wenn der Client zusichert die Operationen eines Dienstes nur unter erfüllten Vorbedingungen aufzurufen, sichert der Dienst (Dienstanbieter) zu, einen Zustand zu

19

2 Grundlegende Technologien und Analyseergebnisse

erzeugen in dem die Nachbedingungen erfüllt sind. Die eigentliche Dienstimplementierung (Service Implementation) realisiert zwar die Spezifikation des Dienstvertrages, jedoch besteht hierbei keinerlei technische Abhängigkeit zwischen Schnittstelle und Implementierung, so dass die Implementationsunabhängigkeit erhalten bleibt. Typischerweise wird die Implementation mit Hilfe einer höheren objektorientierten Programmiersprache wie beispielsweise Java oder C# .NET realisiert. Die notwendige Vermittlung von dokumentorientierter zu objektorientierter Verarbeitung übernehmen Middleware-Systeme. Im Folgenden soll nun die Aufrufsemantik innerhalb einer Architektur aufgezeigt werden, in der, Dienstkonsumenten Web-Services unbestimmter Dienstanbieter nutzen wollen, welche bestimmte Funktionalitäten realisieren. Dies wird durch die nachfolgende Abbildung noch einmal verdeutlicht.

Abbildung 9:

Aufrufarchitektur von Web-Services

Wie bereits erwähnt, sind Web-Services eigentlich protokollunabhängig. Da sich mittlerweile jedoch mit WSDL, UDDI und SOAP Standardprotokolle weitestgehend durchgesetzt haben, wurden diese in die zuvorgehende Abbildung integriert. In einem ersten Schritt werden die Metadaten des Web-Service, zum Beispiel das WSDLDokument, durch den Dienstanbieter in einem zentralen Dienstverzeichnis veröffentlicht. Das Dienstverzeichnis kann beispielsweise nach dem UDDI-Standard aufgebaut sein, wobei Dienstanbieter und Dienste katalogisiert werden. Die Veröffentlichung ist also die Voraussetzung eines erfolgreichen Aufrufes durch einen Dienstkonsumenten. Will der

20

2 Grundlegende Technologien und Analyseergebnisse

Dienstkonsument diesen Web-Service aufrufen, ohne den Endpunkt des Dienstes beispielsweise von einem früheren Aufruf zu kennen, stellt der Client in einem zweiten Schritt eine Suchanfrage an das Dienstverzeichnis, indem er den Namen beziehungsweise die nachgefragte Funktionalität angibt. Das Ergebnis der Suchanfrage wird dann in einem dritten Schritt zurück an den Client, in Form des WSDL-Dokumentes und der URI des Endpunktes, übermittelt. Im vierten Schritt bindet der Client den Web-Service über dessen Endpunkt. Darauf folgend kann im fünften Schritt vom Client eine SOAP-Nachricht, welche den Aufruf einer Operation des Web-Service enthält, erstellt und zum Beispiel über das Transportprotokoll HTTP an den Endpunkt versandt werden. Nachdem der WebService die Operation ausgeführt hat, erstellt dieser in einem sechsten Schritt eine Ergebnisnachricht im SOAP-Format und sendet diese wiederum an den Client zurück. Da in der Erläuterung der Aufrufsemantik bereits die Standardprotokolle WSDL, UDDI und SOAP benannt wurden, sollen diese im Weiteren etwas genauer analysiert und dargestellt werden. Zwar machen diese Protokolle den Kern der Web-Service Spezifikationen aus, jedoch existieren eine Menge angrenzender Standards, so dass zunächst ein Blick auf den so genannten “Web-Service Protokollstapel” zu werfen ist, um die inhaltliche Einordnung dieser zu verdeutlichen [W3CORG], [HALÖ04].

Abbildung 10:

Web-Service Protokollstapel

21

2 Grundlegende Technologien und Analyseergebnisse

Web Services Description Language (WSDL) Die WSDL [WSDL01], [WSDL06] ist eine XML-basierte Sprache zur Beschreibung des Dienstvertrages sowie der Bindung des Web-Services an einen Endpunkt. Dabei ist der Verwendungszweck durchaus mit der bekannten Interface Definition Language (IDL) von CORBA oder COM [BIRO03] vergleichbar. In einem WSDL-Dokument wird eine Schnittstelle, mit einer Menge von Operationen, spezifiziert. Außerdem enthält das Dokument Informationen zu den Protokollen, Datenformaten der Nachrichten und den Adressen über die auf die einzelnen Schnittstellen zugegriffen werden kann. Die wohl wichtigste Eigenschaft von WSDL ist die Separation der abstrakten Spezifikation der Funktionalität des Dienstes von den Bindungsspezifika und Details des Dienstes. Dies wird erreicht, indem das WSDL-Dokument in zwei Teile gegliedert ist: den abstrakten Teil, in dem die Schnittstellen, samt Operationen und ihren Input- und Output-Nachrichten, protokollunabhängig angegeben werden, sowie den implementationsabhängigen Teil, welcher Informationen über die Bindung an ein Kommunikationsprotokoll, das Format der Input- und Output-Nachrichten sowie die Spezifikation von zugreifbaren Adressen enthält [STÖH05]. Der Aufbau wird nachfolgend noch einmal in einer Abbildung veranschaulicht.

Abbildung 11:

Aufbau eines WSDL-Dokumentes

22

2 Grundlegende Technologien und Analyseergebnisse

Die einzelnen Teile der vorangegangenen Abbildung stellen in WSDL definierte XMLElemente dar. Dabei ist zu erwähnen, dass mehrere message- und operation-Elemente verwendet werden können. Die Abbildung zeigt weiterhin noch einmal die semantische Unterteilung des WSDL-Dokumentes. So wird mit dem abstrakten Teil die logische Schnittstellenspezifikation vorgenommen. Mit dem service-Element können dann die eigentlichen aufrufbaren Endpunkte definiert werden wobei mit dem binding-Element, der abstrakte Teil implementationsabhängig abgebildet wird. Universal Description, Discovery and Integration (UDDI) Wie bereits bei der Aufrufarchitektur eines Web-Services erwähnt, kann ein zentrales Dienstverzeichnis erforderlich sein. Mit UDDI [UDDI04] hat sich derzeit bereits ein Standard für solche Verzeichnisse durchgesetzt. Ein derartiges Verzeichnis stellt Funktionalitäten, ebenfalls in Form von Web-Services, bereit, mit denen ein Client WSDLDokumente in Abhängigkeit von Einschränkungskriterien abfragen kann. Dies ist dann unumgänglich,

wenn

der

Client

das

WSDL-Dokument

eines

Web-Services

beziehungsweise eine Lokalisierung dessen nicht vorhält. Dabei liegt es natürlich auf der Hand, dass diese Architektur die lose Kopplung durch Web-Services unterstreicht, da der Client zunächst nur geringfügige Informationen über den Dienst benötigt. Die Nutzung eines zentralen, internetweiten Verzeichnisses ist allerdings eher begrenzt, da die Zahl öffentlicher Web-Services momentan noch gering ist. Die meisten Web-Services sind unternehmensintern beziehungsweise in einem abgrenzbaren Unternehmensverbund zu halten, so dass sich wenige internetweite, dafür jedoch viele private intranetweite, Verzeichnisdienste etablieren werden [WELT05].

23

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 12:

Aufbau eines UDDI-Verzeichnisses

Die vorangegangene Abbildung zeigt den Aufbau eines UDDI-Verzeichnisses. Die Spezifikation legt dabei ein Datenschema für die Verwaltung der Web-Services, sowie die Zugriffsfunktionalitäten zum Veröffentlichen, Suchen und Zugriff, in Form von WebServices,

fest.

Somit

Dienstbeschreibungen

müssen

einem

Dienstkonsumenten,

der UDDI-Verzeichnisdienste

bekannt

sein,

wenigstens damit

die

er die

Dienstbeschreibungen anderer Dienste erlangen kann. Das Verzeichnis verwaltet die Daten in drei semantisch getrennten Beständen. In den “White pages” werden, dabei die Stammdaten der einzelnen Dienstanbieter vorgehalten. Die “Yellow pages” klassifizieren die Dienste und Dienstanbieter entsprechend Branchen, Geografie und hergestellten Produkten. In den “Green pages” werden letztlich die eigentlichen Dienstbeschreibungen abgelegt. Hier finden sich allgemeine Dienstbeschreibungen, diverse Metadaten und natürlich die WSDL-Dokumente beziehungsweise wenigstens die Referenzen, wo die WSDLDokumente zu finden sind. Simple Object Access Protocol (SOAP) Das SOAP-Protokoll stellt ein XML-basiertes, zustandsloses und unidirektionales Übertragungsprotokoll innerhalb von Web-Service-Architekturen dar. Mit SOAP wird in einem solchen Szenario allerdings lediglich der Aufbau der übermittelten Nachrichten beschrieben und nicht das eigentliche Transportprotokoll. Hierzu verwendet man andere Protokolle wie beispielsweise HTTP [WELT05], [BIRO03].

24

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 13:

Aufbau einer SOAP-Nachricht

Wie in der zuvor gehenden Abbildung dargestellt, hat eine SOAP-Nachricht einen sehr einfachen und dennoch erweiterbaren Aufbau. So besteht diese aus einem optionalen Header und einem zwingend erforderlichen Body, welcher allerdings beliebige Nutzdaten beinhalten kann. Beide Teile werden in einem, als logische Klammer genutzten, Umschlag: dem SOAP-Envelope, eingebettet. Die gesamte SOAP-Nachricht wird dann als Nutzdaten an ein Transport-Protokoll, vornehmlich HTTP, gebunden [STÖH05], [HALÖ04]. Der SOAP-Header besteht aus einer Reihe von so genannten Header-Blocks, welche beliebige XML-Elemente sind, und als Verarbeitungsinformationen für die eigentlichen Nutzdaten verwendet werden. Beispiele für solche verarbeitungsrelevanten Informationen sind Authentifizierung und Autorisierung des Senders oder die Transaktionssteuerung. Diese Erweiterungsmöglichkeit des SOAP-Protokolls wurde bewusst eingeführt, um den SOAP-Standard möglichst einfach und verständlich zu halten. Der SOAP-Body besteht aus einem Rumpf-Element, in dem die eigentlichen Daten der Nachricht serialisiert enthalten sind. Dabei kann es laut der Spezifikation drei Arten solcher Rumpfelemente geben: Aufruf, Antwort und Fehler. Die Art des Körpers kann also die Art der Verarbeitung der Daten beeinflussen. Eine Erweiterung des SOAP-Protokolls ist die optionale Spezifikation von Attachments. Die Möglichkeit Binärdaten an die Nachricht anzuhängen, resultiert aus der Serialisierung der strukturierten Daten in XML-Daten. Alle diese Teile werden durch den SOAP-Envelope zusammengefasst, welcher zusätzliche Attribute sowie die Deklaration von Namensräumen enthält [HALÖ04], [SCST01].

25

2 Grundlegende Technologien und Analyseergebnisse

Da Web-Services eigentlich protokollunabhängig sind und mit WSDL, UDDI und SOAP lediglich die Hauptvertreter vorgestellt wurden, soll an dieser Stelle ein Überblick der möglichen Alternativen gegeben werden [BIRO03]. Verwendung

Protokoll

Alternativprotokolle

Beschreibung

WSDL

Verzeichnisdienste

UDDI

Übertragung

SOAP

Transport

HTTP

SIDL (Service Interface Description Language) SCL (SOAP Contract Language) NASSL (Network Accessible Service Specification Language) WIDL (Web Interface Description Language) DISCO (Dicovery) ADS (Advertisment and Discovery of Services) WS-Inspection XML-RPC (XML Remote Procedure Call) WDDX (Web Development Data Exchange) WS-Attachments MIME (Multi-purpose Internet Mail Extension) DIME (Direct Internet Message Encapsulation) ebXML (Electronic Business XML) JMS (Java Messaging Service) ICE (Information and Content Exchange) SMTP (Simple Mail Transfer Protocol) BEEP (Blocks Extensible Exchange Protocol) Jabber

Tabelle 1:

Alternative Web-Service Protokolle nach [BIRO03]

Abschließend kann zusammengefasst werden, dass Web-Services auf bereits existenten und bewährten Technologien aufbauen und diese konsequent um eine Implementationsunabhängigkeit erweitern. Die Vorteile einer derartigen Architektur liegen vor allem in der Integrationsmöglichkeit und Interoperabilität. Allerdings sind hiermit auch einige Nachteile in folgenden Bereichen verbunden: •

Sicherheitsaspekte

•

Performance

•

erhöhte Komplexität

26

2 Grundlegende Technologien und Analyseergebnisse

Letztendlich bleibt zu erwähnen, dass den Middleware-Systemen im Rahmen der Anwendung von Web-Services eine größere Bedeutung zukommt, da diese die diversen Standardprotokolle und Konzepte realisieren, was die fortwährende Etablierung der 3-Tierund n-Tier-Architekturen unterstreicht.

2.3.3

Enterprise Service Bus (ESB)

Wie bereits einführend erwähnt stellt der ESB eine Variante der technischen Realisierung einer SOA dar. Da der Begriff des Enterprise Service Bus derzeit sehr kontrovers diskutiert wird und die Konsolidierungsphase noch lange nicht erreicht ist, soll die Definition des ESB auf Grundlage von Charakteristika erfolgen. Nachfolgend sind jedoch zunächst zwei Zitate aufgeführt, welche eine allgemeine Einordnung des ESB geben. "An ESB provides communication between distributed componentes, support both SOA and EDA, supports Web services, and provides transformation and intelligent content based routing." Gartner, [HOH04b] "[...] software infrastructure that enables service-oriented architectures (SOA) by acting an intermediary layer of middleware through which a set of reusable business services are made widely available." Forrester, [LAPL04] Im Weitern werden die wesentlichen Charakteristika herausgearbeitet und beschrieben, da die Begriffsabbildungen des ESB von einem Entwurfsmuster bis hin zu einem MiddlewareSystem reichen [HOH04b], [LAPL04], [IBM04a], [IBM05a], [IBM05b], [MS04a], [SOCO06], [BHAR05], [OSTL04].

27

2 Grundlegende Technologien und Analyseergebnisse

•

Middleware-System Entgegen des in [IBM05a] dargestellten ESB, in Form eines Musters für die Interaktion einer Menge von unterschiedlichen Software-Systemen, ist dieser eher als ein Middleware-System zu verstehen, welches allerdings als eine Menge von Instanzen genutzt werden kann.

•

nachrichtenbasiert und ereignisgesteuert Um eine lose Kopplung der integrierten Anwendungen zu erreichen realisiert ein ESB einen nachrichtenbasierten Datenaustausch und weist eine ereignisgesteuerte Verarbeitung auf. Die asynchrone Nachrichtenverarbeitung war auch die Ursache für die Bezeichnung als Bus.

•

Dezentralität der Infrastruktur Der ESB kann auf der einen Seite zentral installiert sein. Auf der anderen Seite ist es jedoch möglich einen logischen Bus über mehrere ESB-Instanzen hinweg aufzubauen. In [IBM05b] werden hierfür die vier Muster: Global, Directly connected, Brokered und Federated ESB vorgestellt.

•

Zentralität der Konfiguration Obwohl sich der logische ESB über mehrere Instanzen erstrecken kann, werden alle zentral konfiguriert, so dass es nur einen „locus of control“ gibt.

•

Dienstorchestrierung Die Orchestrierung der einzelnen „am Bus angeschlossenen“ Dienste wird durch eine Service Orchestration Engine realisiert, wobei kein spezieller Standard vorgegeben wird, viele Dinge jedoch für WSBPEL sprechen. Dabei bietet sich ein privates Dienstverzeichnis innerhalb des ESB an.

•

weitestgehend auf Standards basierend Der ESB soll nicht nur die Möglichkeit bieten Web-Services zu orchestrieren sondern darüber hinaus beliebige Dienste über Standardschnittstellen zu integrieren. Hierbei sind neben Web-Services auch JMS, JCA, RMI sowie spezielle Adapter relevant.

28

2 Grundlegende Technologien und Analyseergebnisse

•

internes Datenformat Auf Grund der Offenheit sowohl für XML-basierte als auch für alternative Schnittstellen, muss der ESB ein internes Datenmodell aufweisen welches in der Lage ist, alle Formate abzubilden.

•

Metadatenverwaltung Weiterhin wird eine Metadatenverwaltung für automatisierte Transformationen und Translationen benötigt, welche das einfache Einbinden neuer Dienste erleichtern soll.

•

definierte Grundfunktionalitäten Die wesentlichsten Grundfunktionalitäten sind Messaging, Datentransformationen, Content based Routing, Quality of Service und die Definition von Geschäftsregeln. Nach [LAPL04] unterteilt Forrester die Grundfunktionalitäten in die drei Kategorien: control, change und connection. Die control-Kategorie umfasst dabei die Sicherheit, QoS und das Monitoring, während die change-Kategorie vor allem Datentransformationen und das Mapping adressiert. Der connection-Kategorie sind letztlich alle Protokolle, Nachrichtenverarbeitungen und Verteilungsaspekte zugeordnet.

Nachdem nunmehr die Charakteristika eines ESB näher bestimmt sind, stellt sich die Frage in wieweit sich die Bus-Topologie des ESB von den bekannten Hub&Spoke-Topologien respektive den Broker-Systemen unterscheidet. Letztendlich ist die Dezentralität der Infrastruktur der entscheidende Aspekt. So kann ein Bus-System wie der ESB nach [IBM04a] und [MS04a] als Menge horizontal integrierter Hubs und damit als Spezialform eines Hubs, verstanden werden. Dies veranschaulicht die folgende Abbildung noch einmal.

29

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 14:

Topologie eines Enterprise Service Bus

Neben der impliziten Dezentralität der Infrastruktur, unterscheidet sich der ESB auch durch die weitgehende Nutzung von Standard-Schnittstellen. So existiert eher die Anforderung an die zu integrierenden Dienste eine Standardschnittstelle zu realisieren, als wie in einer Hub&Spoke-Architektur üblich, spezielle Adapter für jede Anwendung anzubieten. Nachdem nunmehr die Charakteristika und die Topologie des ESB näher betrachtet wurden, soll weiterhin auch der logische Aufbau des ESB berücksichtigt werden. Die folgende Abbildung zeigt zunächst diesen schematischen Aufbau.

Abbildung 15:

Logischer Aufbau eines Enterprise Service Bus

30

2 Grundlegende Technologien und Analyseergebnisse

Analysiert man nun diesen Aufbau, finden sich natürlich die eingangs erwähnten, wesentlichen Charakteristika wieder. Darüber hinaus bietet sich im Rahmen eines ESB die Definition eines konzeptuellen Modells an. Dies kann man in diesem Kontext in ein Datenmodell und ein Prozessmodell unterscheiden. Zwar kann auch direkt das Prozessmodell einer Workflow-Beschreibungssprache beziehungsweise das Datenmodell einer Standard-Schnittstelle übernommen werden, jedoch scheint dies auf Grundlage der Offenheit für unterschiedliche Schnittstellen nicht als optimale Variante. Abschließend kann man zusammenfassen, dass der Begriff des Enterprise Service Bus noch nicht endgültig definiert wurde, allerdings eine Abgrenzung an Hand von Charakteristika möglich ist. Hierbei ähneln die Konzepte stark denen von bewährten EAI-Plattformen. Somit kann der ESB als eine Adaption von EAI-Lösungen in einer serviceorientierten Architektur verstanden werden.

2.4

Business Process Management (BPM)

Da mittlerweile, auf Grund der zunehmenden Durchdringung aller Arbeitsprozesse mit DVAnwendungen,

die

Service-Orchestrierung

und

die

Geschäftsprozessmodellierung

zunehmend verschmelzen, soll an dieser Stelle zunächst die Perspektive der Geschäftsprozessmodellierung und anschließend die Perspektive der automatisierten Ausführung von Geschäftsprozessen mit Hilfe von WFMS betrachtet werden. BPM stellt dabei den Hauptbegriff sowohl für die eigentliche betriebswirtschaftliche Modellierung und Optimierung als auch für die technisch-orientierte Automatisierung dar. Unter einem Geschäftsprozess ist in diesem Zusammenhang eine inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Funktionen zu verstehen, welche auf die Bearbeitung eines Materials oder Informationsobjektes ausgerichtet ist. Hierbei werden wertschöpfende Aktivitäten einer Organisation funktionsübergreifend zusammengefasst [WIKIDE]. Bei der eigentlichen Modellierung von Geschäftsprozessen werden komplexe Sachverhalte der Realität innerhalb des Diskursbereiches abstrahiert und somit eine Analyse erst ermöglicht. Hierfür werden zwei Arten von Modellierungswerkzeugen eingesetzt. Zum

31

2 Grundlegende Technologien und Analyseergebnisse

einen sind das rein grafisch orientierte Werkzeuge, wie beispielsweise das ARIS Toolset [ARIS06]. Auf der anderen Seite existieren Werkzeuge welche eine grafische Modellierung zulassen

und

gleichzeitig

die

Generierung

von

Prozessen

unterschiedlicher

Prozessbeschreibungssprachen ermöglichen. Im Weiteren soll kurz auf das Wesen eines Geschäftsprozesses eingegangen werden, indem die unterschiedlichen Sichten auf den Geschäftsprozess, in Anlehnung an das ARIS Referenzmodell, kurz erläutert werden. Hauptsächlich unterscheidet man hierbei zwischen vier Sichten: •

Organisationssicht

•

Prozesssicht

•

Funktionssicht

•

Datensicht

Die Organisationssicht bildet dabei die Aufbauorganisation in Form von Organigrammen und einen Teil der Ablauforganisation ab. Die Funktionssicht untergliedert einen Prozess rekursiv in Teilprozesse bis hin zu den eigentlichen Aktivitäten, welche auch synonym als Verrichtungen

bezeichnet

werden.

In

der

Datensicht

wird

die

Struktur

von

Informationsobjekten aus einem rein statischen Blickwinkel modelliert. Innerhalb der Prozesssicht werden die eigentlichen Prozessabläufe modelliert. Hierbei wird Bezug zu den drei anderen Schichten hergestellt, um den Prozess mit all seinen Facetten darzustellen. Somit wird der Datenfluss, als auch der Kontrollfluss, innerhalb der Prozesssicht modelliert, wobei eine Trennung zwischen diesen beiden möglich und sinnvoll ist. Wie bereits erwähnt umfasst BPM auch die Automatisierung von Geschäftsprozessen. Dabei wird die Prozesssicht inklusive der Referenzen auf die drei anderen Sichten auf eine automatisiert verarbeitbare Beschreibung abgebildet. Diese technische Beschreibung kann dann in einem Workflow Management System (WFMS) zur Ausführung gebracht werden. Ein WFMS verwaltet dabei mehrere Workflows. Ein Workflow wird in diesem Kontext auch einfach Prozess genannt und stellt dabei eine abstrakte Vorlage dar. Soll eine solche Vorlage durch das WFMS zur Ausführung gebracht werden, wird eine Prozessinstanz

32

2 Grundlegende Technologien und Analyseergebnisse

angelegt und abgearbeitet. Hierbei können mehrere Prozessinstanzen eines Workflows gleichzeitig verarbeitet werden. Die folgende Abbildung zeigt das, aus [WFMC95] entnommene, Workflow Referenzmodell der Standardisierungsorganisation WfMC.

Abbildung 16:

Workflow Referenzmodell der WfMC [WFMC95]

Auf Grundlage dieser Abbildung sollen nun die einzelnen Komponenten sowie die fünf definierten Schnittstellen beschrieben werden. Der Workflow Enactment Service beschreibt eine Laufzeitumgebung in der die Workflows, unter zu Hilfenahme von beliebig vielen Workflow Engines, instantiiert und abgearbeitet werden. Der Zugriff auf diese Umgebung erfolgt über die Workflow API (WAPI). Eine Workflow Engine stellt dabei die Umgebung zur

Ausführung

einer

oder

mehrerer

Workflow-Instanzen

dar.

Innerhalb

des

Referenzmodells wird auch ein Vorschlag für Zustandsübergänge während des Lebenszyklusses einer Workflow-Instanz gegeben. Die erste Schnittstelle wurde zwischen den Process Definition Tools, also den Process Designern, und dem WFMS definiert. Diese wird durch ein definiertes Prozessmodell und Datenmodell, wie beispielsweise WSBPEL 2.0, realisiert. Das zweite Interface existiert zwischen beliebigen Client-Applikationen und dem WFMS zur Beschreibung des Aufrufes einer

Workflow-Verarbeitung.

In

einer

dienstorientierten

Architektur,

in

der

Prozessbeschreibungen selbst wieder Dienste sind, kann beispielsweise WSDL und SOAP

33

2 Grundlegende Technologien und Analyseergebnisse

diese Schnittstelle darstellen. Ähnliches gilt auch für das dritte Interface, welches die Interaktion zwischen dem WFMS und den genutzten Diensten und Anwendungen beschreibt. Die vierte Schnittstelle beschreibt die horizontale Integration mehrerer, eventuell verteilter, Workflow Enactment Services. An dieser Stelle sei noch einmal auf den ESB verwiesen, welcher in Form der dezentralen Infrastruktur ein ähnliches Konzept verfolgt. Das fünfte Interface repräsentiert letztendlich die Schnittstelle zwischen einem grafischen

Verwaltungs-

und

Überwachungswerkzeug

sowie

dem

WFMS,

zur

Konfiguration des Systems. Abschließend bleibt zu erwähnen, dass für die Schnittstellen vier und fünf nicht unbedingt Standardisierungen erforderlich sind. Im Gegensatz dazu sind Standards für die Schnittstellen eins bis drei absolut notwendig, will man für die Kriterien Flexibilität und Portabilität einen hohen Realisierungsgrad erreichen.

2.5

TransConnect Anforderungsanalyse

Neben den bislang beschriebenen Konzepten und Basistechnologien, stellt das Produkt TransConnect der SQL GmbH, eine der wichtigsten Grundlagen für die Diplomarbeit dar. Nachdem zunächst ein allgemeiner Überblick über das Produkt gegeben und eine detaillierte

Istzustandsanalyse

durchgeführt

wurde,

ist

die

Beschreibung

der

Anforderungsanalyse mit der Definition von Sollanforderungen abzuschließen. Auf Grundlage dieser Anforderungen wird in den nachfolgenden Kapiteln letztendlich BPEL analysiert und die Konzepte der Nachrichtentransformation diskutiert. 2.5.1

Das Produkt TransConnect im Überblick

Die Grundlage für das Produkt TransConnect wurde im Jahre 1998 mit den zwei Diplomarbeiten [TUHR98] und [WERN98] gelegt. Dabei wurde zunächst die Kopplung zwischen RDBMS und SAP untersucht und in Form eines ALE-Translators realisiert. Im Laufe der Weiterentwicklung des Produktes wurde TransConnect in eine komplexe

34

2 Grundlegende Technologien und Analyseergebnisse

Integrationsplattform für die Anwendungsintegration überführt und ist mittlerweile als EAI-Server zu bezeichnen. Die Gesamtarchitektur ist vor allem von der XML-basierten, nachrichtenorientierten Arbeitsweise und von dem Adapterkonzept geprägt. So werden alle externen Systeme über die produkt- beziehungsweise standardspezifischen Adapter angesprochen. Für den Fall, dass Nachrichten an den TransConnect-Server gesandt werden, stehen eine Reihe von standardisierten Client-Interfaces und System Listener breit. Die folgende Abbildung verdeutlicht noch einmal das Wesen des Adapterkonzeptes.

Abbildung 17:

Überblick der Gesamtarchitektur von TransConnect nach [TCHB06]

Der TransConnect-Server kann durchaus, hinsichtlich Zielstellung und Funktionalität, mit dem SAP Integration Server verglichen werden [BITT05]. Dieser stellt die wesentlichste Komponente der SAP Exchange Infrastructure (XI) dar.

2.5.2

Istzustandsanalyse

In diesem Abschnitt soll auf die aktuelle Version des Produktes TransConnect und dessen Komponenten

eingegangen

werden

[TCHB06],

[TCWS05].

Dabei

wird

dieser

Istzustandsanalyse die Version „TransConnect 1.3.4“ zu Grunde gelegt. Zum Zeitpunkt der Diplomarbeit wurde zwar bereits an einer Version 1.3.5 gearbeitet, diese soll jedoch an dieser Stelle nicht betrachtet werden.

35

2 Grundlegende Technologien und Analyseergebnisse

Grundsätzlich kann TransConnect in die drei Teilkomponenten: TransConnect Manager, TransConnect Server und TransConnect Datastore untergliedert werden. Hierbei nutzt der TransConnect Server einen J2EE Application Server sowie den TransConnect Datastore, welcher wiederum ein RDBMS verwendet. Der TransConnect Manager ermöglicht die Konfiguration dieser beiden Teilkomponenten. Dieses Zusammenspiel wird durch die folgende Abbildung verdeutlicht, wobei die 3-Tier-Architektur deutlich wird.

Abbildung 18:

Teilkomponenten von TransConnect 1.3.4

Da die Ebene der Präsentation für diese Arbeit nicht von Belang ist, soll der TransConnect Manager im Weiteren vollständig ausgeklammert werden. In diesem Abschnitt wird ausschließlich auf den TransConnect Server, sowie den TransConnect Datastore eingegangen. Die nachfolgende Abbildung zeigt den Aufbau des TransConnect Servers. Anhand dieser Darstellung soll nun der Aufbau und die Arbeitsweise von TransConnect erläutert werden.

Abbildung 19:

Aufbau des TransConnect-Servers

36

2 Grundlegende Technologien und Analyseergebnisse

Der TransConnect-Server umfasst wiederum eine Reihe von Komponenten. Alle Konfigurationen dieser Komponenten werden in einem zentralen, dateibasiertem Metadata Repository verwaltet. Prinzipiell können Informationen aus zwei Datenquellen verarbeitet werden. Entweder wird eine Nachricht von einem externen System an eines der Client-Interfaces, beziehungsweise an einen der System Listener, gesandt oder es wird per Zeitsteuerung direkt eine TransConnect-Nachricht entsprechend

generiert.

spezifischer

Die

eingehenden

Routing-Informationen,

Nachrichten an

einen

werden

dann,

Standardworkflow

weitergeleitet. Hierbei wird grundlegend zwischen synchroner und asynchroner Verarbeitung unterschieden. Im Falle der synchronen Verarbeitung wird die eingehende Nachricht direkt an den Workflow weitergegeben. Im Gegensatz dazu wird bei asynchroner Verarbeitung

die MessageQueue als Synchronisationselement vor den Workflow

geschaltet. Der Prozess des Routings ist dabei fest codiert, ermöglicht jedoch die Verarbeitung einer Nachricht in mehreren Workflows. Der Standardworkflow umfasst in der minimalen Variante die Interaktion mit einem Zielsystem über einen Adapter. Optional kann dieser, eine weitere Interaktion mit einem Lookup-System, ebenfalls über einen Adapter, vorgeschaltet werden. Im Falle der asynchronen Verarbeitung ist außerdem eine optionale Ergebnisprüfung zum Ende des Standardworkflows möglich. Der Interaktion mit einem Adapter geht in der Regel ein Mapping voraus, welches die eigentliche Nachrichtentransformation mit XSLT oder STX darstellt. Die Skripte hierfür werden zur Entwicklungszeit mit einem Werkzeug eines Drittanbieters erzeugt. Letztendlich wird also die Interaktion mit einem Zielsystem über einen Adapter vorbereitet. Wie bereits erwähnt stellt das Adapterkonzept eines der wesentlichsten Konzepte von TransConnect dar. In Abbildung 17 wurden bereits die nutzbaren Adapter grafisch dargestellt. Prinzipiell bleibt zu erwähnen, dass jeder Adapter das geringfügig veränderte Common Client Interface (CCI) implementiert. Somit können die unterschiedlichen Adapter in gleicher Weise vom TransConnect-Server genutzt werden.

37

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 20:

Common Client Interface (CCI) nach [TCWS05]

Ein weiterer Aspekt der Verarbeitung in TransConnect ist die Realisierung der Transaktionssicherheit. Diese umfasst im Wesentlichen drei Teile: die Verhinderung von Datenverlust, die Vermeidung von Doppelverarbeitung sowie die Ermöglichung der Rücksetzbarkeit sofern dies von den Zielsystemen unterstützt wird. Die Teilkomponenten Transport und Persistence können als grundlegend bezeichnet werden. So ist unter dem Transport der Fluss von Anwendungsdaten zwischen Adaptern zu verstehen. Dabei werden die Nachrichten zunächst in interne TransConnect-Nachrichten transformiert. Eine solche Nachricht hat einen relativ einfachen Aufbau. So enthält diese bestimmte interne Attribute, die Nutzdaten als XML-Dokument, sowie eventuelle Binärdaten als Attachment. Eng verbunden mit diesem Aufbau ist auch das nachfolgend dargestellte Datenmodell, welches den eigentlichen Nachrichteninhalt als BLOB verwaltet und damit den Ansatz des dokumentorientierten Nachrichtenmodells noch einmal unterstreicht.

38

2 Grundlegende Technologien und Analyseergebnisse

Abbildung 21:

Datenmodell des TransConnect-Datastore

Dieses Datenschema wird dabei von einem beliebigen RDBMS verwaltet. Der Zugriff auf die Daten erfolgt mit der Teilkomponente Persistence, welche den Datenzugriff per JDBC realisiert, da eine zusätzliche Abstraktionsebene aus Performance-Gründen völlig inakzeptabel wäre. Letztendlich gewährleistet der TransConnect-DataStore die Sicherung der Datenbestände gegen Verlust bei Systemausfall. Um die Istanalyse nunmehr abzuschließen, sollen ferner die Defizite von TransConnect 1.3.x identifiziert werden, welche eine grundlegende Überarbeitung rechtfertigen und damit die Entwicklung von TransConnect 2.0 begründen.

Der

•

Unzureichende Flexibilität des Standardworkflows

•

Dateibasiertes Metadaten-Repository

•

Maßnahmen der Qualitätssicherung nahezu nicht vorhanden

•

Fehlende Funktionalitäten hinsichtlich Monitoring und Ressourcenverwaltung

•

Optimierungspotential hinsichtlich Verarbeitungseffizienz

•

Unzureichende Wiederverwendbarkeit von Adapterfunktionalitäten Schwerpunkt

dieser

Arbeit

adressiert

die

unzureichende

Flexibilität

des

39

2 Grundlegende Technologien und Analyseergebnisse

Standardworkflows. Darüber hinaus werden allerdings auch damit korrelierte Defizite aufgegriffen und untersucht.

2.5.3

Sollanalyse und allgemeine Anforderungen

Nachdem innerhalb der Istzustandsanalyse die aktuelle Version „TransConnect 1.3.4“ im Detail beschrieben wurde, soll in diesem Abschnitt die Anforderungen an die Version „TransConnect 2.0“ definiert werden. Dabei fokussieren diese vorrangig die Überarbeitung des Kerns des TransConnect-Servers. Die generelle Zielstellung für TransConnect 2.0 ist die Erhöhung der Flexibilität bei der Definition von Integrationsszenarien. So sollen, wie im EAI-Bereich mittlerweile fast üblich, Methoden der Prozessintegration auf die Anwendungsintegration angewandt werden. Im Gegensatz zu den alternativen Produkten, ist dabei jedoch, auf Grund von datenzentrischen Prozessen, besonderes Augenmerk auf die Informationsintegration zu legen. Dieses Hauptziel soll durch die Beschreibung der Nachrichtenverarbeitung in TransConnect mit Hilfe einer Prozessbeschreibungssprache realisiert werden. Hierfür wurde die Sprache WSBPEL ausgewählt. Grundsätzlich werden bei der Überarbeitung allerdings die wichtigsten Konzepte in angepasster Form übernommen. So wird weiterhin die Einteilung der Hauptkomponenten, das Adapterkonzept sowie die nachrichtenbasierte und transaktionssichere Verarbeitung erhalten bleiben. Die nachfolgende Tabelle benennt zunächst die Anforderungen. Dabei werden diese in zwei Kategorien: Muss- und Kann-Anforderungen unterteilt. Diese beziehen sich einerseits auf den Kern von TransConnect 2.0 und damit andererseits auch auf die prototypische Implementierung im Rahmen dieser Diplomarbeit. Kategorie

Anforderung

Muss

Prozessmodellierung mit einer Workflow-Beschreibungssprache Flexibilität

40

2 Grundlegende Technologien und Analyseergebnisse

Kategorie

Kann

Tabelle 2:

Anforderung hohe Performance Skalierbarkeit Transaktionssicherheit Umfassendes Ressourcenmanagement Umfassendes Monitoring Unabhängigkeit vom Application Server Unabhängigkeit vom Datenbank Server Unabhängigkeit von der Hardware-Plattform und dem Betriebssystem Kompatibilität zu Vorgängerversion / Migrationsmöglichkeiten Unabhängigkeit von Workflow-Beschreibungssprache Echtzeitähnliches Verhalten Verarbeitbarkeit von Nachrichtenmengen (Batch-Verarbeitung) Definition eines konzeptuellen Modells Definition von Maßnahmen zur Qualitätssicherung Anforderungen an TransConnect 2.0

Die einzelnen Anforderungen sind nun noch etwas detaillierter zu diskutieren. Die Forderung nach Flexibilität adressiert die eingeschränkten Möglichkeiten der Definition von Nachrichtenverarbeitungen mit den in Abschnitt 2.5.2 vorgestellten Routing, Standardworkflow und Mapping. So soll der Zugriff auf beliebig viele Zielsysteme inklusive der Definition von Geschäftlogik innerhalb einer Nachrichtenverarbeitung ermöglicht werden. Damit geht auch die Nutzung einer Workflow-Beschreibungssprache einher, da somit die Web-Service-Orchestrierung der Prozessintegration auf die Anwendungsintegration angewandt werden kann. Die weiteren Muss-Anforderungen betreffen eher rein technische Aspekte. So ist eine hohe Performance sowie die Skalierbarkeit essentiell für datenzentrische Prozesse. Auch die Transaktionssicherheit muss weiterhin gewährleistet sein, so dass Anomalien verhindert werden und die Wiederherstellung eines bestimmten Verarbeitungszustandes des TransConnect Servers jederzeit möglich ist. Das umfassende Ressourcenmanagement meint die Definition von Grenzwerten für benutzte Hardware-Ressourcen und eine lastbewusste Verwaltung von Prozessinstanzen. Das Monitoring schließt sich daran an und adressiert die umfassende Analyse von Ressourcen, Prozesszuständen und Kontrollflüssen zur Laufzeit, wobei dies über das einfache Schreiben von Log-Dateien hinausgehen sollte. Weiterhin ist auf die Unabhängigkeit vom DBMS, vom Application Server, sowie von der Plattform zu achten,

41

2 Grundlegende Technologien und Analyseergebnisse

so dass auch TransConnect 2.0 einen sehr hohen Portabilitätsgrad hinsichtlich dieser drei Ebenen aufweist. Außerdem muss die Kompatibilität zur Vorgängerversion gewährleistet sein

und

geeignete

Möglichkeiten

zur

Überführung

der

Beschreibung

von

Transformationsprozessen angeboten werden. Diese Muss-Anforderungen werden außerdem um einige Kann-Anforderungen erweitert. So ist die Unabhängigkeit von der Workflow-Beschreibungssprache anzustreben, um zum einen flexibel auf Standardänderungen von WSBPEL reagieren und zum anderen auch deren Alternativen einsetzen zu können. Daran schließt sich auch die Definition eines konzeptuellen Modells an, welches mit Einschränkungen die Vorrausetzung für die Unabhängigkeit von der Workflow-Beschreibungssprache ist. Eine sehr schwierig zu erfüllende Kann-Anforderung ist die Realisierung eines „echtzeitähnlichen“ Verhaltens. Unter Echtzeit ist dabei die garantierte Ausführung einer Verarbeitung innerhalb eines definierten Zeitraums oder bis zu einem bestimmten Zeitpunkt zu verstehen. Da dies bei interaktiven Systemen eigentlich nicht vollständig zu realisieren ist, soll dies lediglich durch

ein

präemptives

Multitasking

realisiert

werden.

In

Bezug

auf

die

Nachrichtengranularität, auf welche im Kapitel 4 genauer eingegangen wird, wäre die Verarbeitung von Nachrichtenmengen über den gesamten Prozess hinweg denkbar. Abschließend ist auch die Definition von Maßnahmen zur Qualitätssicherung eine KannAnforderung. Hierbei sind nicht nur die Spezifikation von Testfällen im Rahmen einer Testsuite, sondern vielmehr auch die Anwendung von statischen und dynamischen Analysen zu berücksichtigen. Die hier definierten Anforderungen werden in den folgenden Kapiteln thematisch wieder aufgegriffen und letztendlich, im Rahmen der prototypischen Implementierung, praktisch realisiert.

42

3 Business Process Execution Language (BPEL) und deren Alternativen

3

Business Process Execution Language (BPEL) und deren Alternativen

Mit der Business Process Execution Language (BPEL) hat sich in den letzten Jahren ein Standard zur Beschreibung von Geschäftsprozessen in einer dienstorientierten Architektur weitestgehend durchgesetzt. Dieser war eigentlich zur Orchestrierung von Web-Services angelegt, wird nun jedoch auch auf dem Gebiet des BPM verstärkt eingesetzt. Dabei geniest der Standard die entschiedene Unterstützung durch einflussreiche Unternehmen und Marktforschungsinstitute. Diese Aussage kann an Hand von Zitaten belegt werden: “Supposed to play the same role to Workflow that SQL played to RDBMS.” IBM, [MEIR05] "SAP will base the BPM technology on an emerging standard, Business Process Execution Language for Web Services. In the past, the company considered using Business Process Modeling Language in its business process technology stack." SAP, [BPMORG] „Eine Service-Orientierte Architektur mit BPEL als Eckpfeiler [...]. Oracle unterstützt SOA analog zu SQL vor 25 Jahren“ Oracle, [ORA05] “Gartner believes that BPEL will emerge as the leading industry standard for Web service orchestration and coordination of business processes.” Gartner, [ORA05] “BPEL is the future of the integration space in my view…Why? Because the value is so much higher when you provide not only a way to integrate applications, but also a way to create services from them and put them into business processes.” Forrester Research, [ORA05]

43

3 Business Process Execution Language (BPEL) und deren Alternativen

Neben BPEL existieren allerdings eine Reihe von alternativen Sprachen und proprietären Konzepten. In diesem Kapitel ist deshalb nicht nur die Funktionalität von BPEL zu untersuchen und zu bewerten, sondern der Blick auch auf aktuelle Spracherweiterungen und Alternativen zu richten. Die unterschiedlichen Workflow-Beschreibungssprachen werden dabei hinsichtlich zwei Kriterien unterschieden. Zum einem nach dem Abstraktionsgrad, welcher zwar nicht exakt quantifizierbar ist, jedoch in Bezug auf die Sprachkomplexität, die Art der Verwendung sowie den technischer Bezug bewertbar ist. Zum anderen kann eine Differenzierung entsprechend der Sprachintension erfolgen. Dazu sind zunächst die Begriffsabbildungen zu definieren: •

Choreografie Eine Workflow-Beschreibungssprache ermöglicht die Choreografie von Diensten, sofern keine zentrale Komponente erforderlich ist, welche die eigentliche Interaktion der beteiligten Dienste verwaltet und steuert. Somit kann unter der Choreografie die dezentrale Interaktion von Diensten verstanden werden, welche aus einer globalen Sicht mit einer nicht ausführbaren Sprache beschrieben wird. Die Choreografie ist also bildlich als eine Menge von unabhängigen Tänzern zu verstehen, welche eine einheitliche Choreografie tanzen.

•

Orchestrierung Im Gegensatz zur Choreografie, ist bei der Beschreibung einer Orchestrierung von Diensten, eine zentrale Komponente erforderlich, welche die beschriebenen Prozesse ausführt. Die Orchestrierung ist damit die zentrale Interaktion von dezentralen Diensten, wobei diese in einer direkt oder indirekt ausführbaren Sprache beschrieben sind. Möchte man auch diese Komponente verbildlichen, kann man diese auch als „den Dirigenten eines Orchesters“ darstellen.

•

Komposition Die Komposition beschreibt wie ein Dienst aus mehreren bestehenden Diensten zusammengesetzt werden kann. Mögliche Varianten der Komposition stellen die Orchestrierung und die Choreografie dar.

44

3 Business Process Execution Language (BPEL) und deren Alternativen

Die Unterscheidung der Komposition in Orchestrierung und Choreografie wird von der nachfolgenden Abbildung, welche an [ORA06b] angelehnt ist, noch einmal verdeutlicht, da das Verständnis der Differenzierung zwischen den beiden Möglichkeiten essentiell für dieses Kapitel ist.

Abbildung 22:

Varianten der Web-Service-Komposition

Den Schwerpunkt dieses Kapitels bildet die Sprachspezifikation WSBPEL 2.0 [BPEL06], weshalb die Untersuchung der alternativen Sprachspezifikationen auf ein Mindestmaß beschränkt wurde.

3.1

Entwicklung der Sprachspezifikationen

In diesem Teilkapitel wird die Historie der wichtigsten Prozessbeschreibungssprachen der letzten sieben Jahre aufgearbeitet. Dabei ist der semantische Aspekt der einzelnen Sprachen zunächst weitestgehend ausgeblendet. An dieser Stelle sei bereits auf die Teilkapitel 3.2 und 3.5 verwiesen, in denen WSBPEL 2.0 sowie aktuelle Alternativen zu diesem Sprachstandard detaillierter untersucht werden. Um die Vielzahl, teils redundanter Prozessbeschreibungssprachen gedanklich zu strukturieren, bietet sich eine Differenzierung in grundlegende Strömungen der Standarisierung an. Hierzu kann das Kriterium der Standardisierungsorganisation herangezogen werden. Dementsprechend sind nachfolgend die derzeit aktivsten Organisationen auf dem Gebiet des BPM benannt.

45

3 Business Process Execution Language (BPEL) und deren Alternativen

•

OMG (Object Management Group) [OMGORG]

•

WfMC (Workflow Management Coalition) [WfMCORG]

•

OASIS (Organization for the Advancement of Structured Information Standards) [OASIS]

•

W3C (World Wide Web Consortium) [W3CORG]

•

BMI (Business Modeling & Integration (BMI) Domain Task Force (DTF)) [BMIORG]

Die einzelnen Strömungen der Standardisierung werden in der nachfolgenden Abbildung dargestellt und anschließend etwas genauer erläutert [KÜMP04], [BART05]. Das Koordinatensystem weist dabei vier logische Dimensionen auf. Während die x-Achse die Zeit-Dimension und die y-Achse den Abstraktionsgrad abbilden, wurde die Farbgebung zur Unterscheidung zwischen proprietären und standardisierten Sprachen genutzt. Letztlich bildet der Aspekt der Standardisierungsorganisation die vierte Dimension.

Abbildung 23:

Entwicklung der Sprachspezifikationen

46

3 Business Process Execution Language (BPEL) und deren Alternativen

Die älteste Organisation dieses Kontextes ist die OMG, welche bereits 1989 gegründet wurde und fortwährend unter anderem an der Spezifikation von UML arbeitet. Diese ist zwar nicht konkret auf die Workflow-Beschreibung ausgerichtet, allerdings kommen die UML Aktivitätsdiagramme durchaus auch auf diesem Gebiet zur Anwendung. Auf Grund des universellen Charakters und der ausschließlichen grafischen Darstellung, wurde diese Sprache mit einem sehr hohem Abstraktionsniveau eingestuft. Die zweitälteste Standardisierungsorganisation ist die WfMC, welche bereits 1993 die erste Version der XPDL veröffentlicht hatte. Die Einstufung auf einem mittleren Abstraktionsniveau ist mit dem Bezug zur eigentlichen Ausführung, allerdings mit einer Fixierung auf WorkflowBeschreibungen, zu begründen. Die dritte Strömung wird durch die BMI, als ein Zusammenschluss der BPMI und OMG, vorangetrieben. Diese spezifiziert mit BPMN eine rein grafische Notation für Workflow-Beschreibungen, weshalb diese auf einem sehr hohen Abstraktionsniveau

angesiedelt

ist.

Obwohl

die

beiden

folgenden

Strömungen

chronologisch die jüngsten sind, kommt diesen dennoch eine sehr hohe Bedeutung zu. So spezifiziert das W3C mit WS-CDL eine Sprache zur Beschreibung von Choreographien von Web-Services und bildet somit eine mittlere Abstraktionsebene im Bereich der Workflow-Beschreibungen, da sie zwar bereits technisch orientiert, jedoch nicht zur Ausführung gedacht, sind. Die Standardisierungen der OASIS befassen sich zum einem mit der Orchestrierung von Web-Services (WSBPEL) und zum anderen mit dem Austausch von Informationen innerhalb von Unternehmensverbünden (ebXML BPSS). Da die Standards der OASIS Sprachen definieren, welche direkt innerhalb von MiddlewareSystemen eingesetzt werden können, ist das Abstraktionsniveau als gering einzuschätzen. An dieser Stelle soll noch einmal etwas genauer auf die Historie von WSBPEL 2.0 eingegangen werden. So liegen deren Wurzeln in den proprietären Sprachen WSFL (IBM) und XLANG (Microsoft). Diese Sprachen wurden dann 2002 innerhalb eines Industriekonsortiums von IBM, Microsoft, SAP, Siebel und BEA in den Standard BPEL 1.0 konsolidiert und anschließend 2003 an die Standardisierungsorganisation OASIS als Version BPEL4WS 1.1 übergeben [IBM06a]. Die Version WSBPEL 2.0 wurde nun letztendlich im Juni 2006 veröffentlicht.

47

3 Business Process Execution Language (BPEL) und deren Alternativen

3.2

WSBPEL 2.0

Nachdem im ersten Teilkapitel bereits auf die Historie der WSBPEL-Spezifikation eingegangen wurde, ist nun WSBPEL 2.0 detailliert zu untersuchen. Hierbei wird ausgehend von einem grundlegendem Überblick der Spezifikation und deren Ziele, die Struktur von BPEL-Prozessen analysiert. Dieser statischen Perspektive, folgt eine Betrachtung der dynamischen Aspekte der Verarbeitung. Die Aussagen dieses Kapitels stützen sich, sofern nicht anders angegeben, auf den Quellen [BPEL03] und [BPEL06], wobei sich die WSBPEL 2.0 Spezifikation zu Beginn der Diplomarbeit noch im Status eines „Commitee Drafts“ befand. 3.2.1

Überblick und Ziele

WSBPEL 2.0 stellt eine XML-basierte Beschreibungssprache dar, welche zur Orchestrierung von Web-Services verwendet und dabei selbst wieder als Web-Service veröffentlicht wird. In der Literatur wird WSBPEL oft auch als „Programmieren im Großen“ bezeichnet. Die Anwendungsgebiete dieser Sprache sind dabei breit gefächert. So ist der Einsatz im Business-to-Consumer- (B2C), Business-to-Business- (B2B) und EAI-Bereich, aber auch zur Erstellung von workflow-basierten verteilten Anwendungen denkbar. Da BPEL auf existenten Technologien aufbaut, enthält die Spezifikation Verweise auf die zu Grunde liegende Standards: WSDL 1.1, XML Schema 1.0, XPath 1.0, XSLT 1.0, Infoset und optional Basic Profile 1.1. Generell unterscheidet die Spezifikation zwischen zwei Arten von WSBPEL-Prozessen: •

Abstrakte BPEL-Prozesse

•

Ausführbare BPEL-Prozesse

Unter einem abstrakten BPEL-Prozess ist dabei eine abstrahierte Prozessdefinition zu verstehen, welche lediglich teilweise spezifiziert ist. Dabei stehen abstrakten Prozessen, im

48

3 Business Process Execution Language (BPEL) und deren Alternativen

Vergleich zu ausführbaren Prozessen, zusätzliche Funktionalitäten zur Verfügung. So können „opaque“-Definitionen verwendet werden, mit denen explizit deklariert werden kann, was vor Partnern zu verbergen ist. Eine zweite Möglichkeit stellt die bewusste Reduzierung von Details dar. Damit kommt einem abstrakten Prozess ausschließlich eine deskriptive Rolle zu. Einsatzgebiete von abstrakten Prozessen könnten beispielsweise „Business Templates“ sein, welche in der Art von Best Practices für bestimmte Diskursbereiche verwendet werden. Ein ausführbarer BPEL-Prozess ist hingegen vollständig spezifiziert und beruht ausschließlich auf der Nutzung von Web-Services und XML-Standardprotokollen. Dabei sind alle Details festzulegen, welche zur Ausführung erforderlich sind, weshalb der Abstraktionsgrad deutlich geringer als bei einem abstrakten Prozess ist. Aufbauend auf der Historie von Prozessbeschreibungssprachen und dem Aufbau aktueller Systemarchitekturen lassen sich eine Reihe von Anforderungen an das Prozessmodell von WSBPEL 2.0 ableiten. Diese sind nachfolgend aufgezählt [IBM06a]. •

Portabilität und Interoperabilität

•

Flexible Integration

•

Rekursive Komposition

•

Zerlegung und Komposition unterschiedlicher Aspekte

•

Verwaltung des Lebenszyklusses von Prozessen in zustandsbehafteten Interaktionen

•

Wiederherstellbarkeit und Kompensationen

Unter Beachtung dieser Anforderungen wurden die Ziele des Sprachentwurfes von WSBPEL 2.0 in der Spezifikation zusammengetragen. Die nachfolgende Tabelle benennt zunächst die einzelnen Ziele und deren Realisierung in der WSBPEL 2.0 Spezifikation. Ziel

Zielrealisierung

Interoperabilität

Nutzung existenter Web-Technologien in Form von offenen Standards XML-basierter Nachrichtenaustausch Nutzung von Web-Services um eine lose Kopplung zu erreichen

Flexible Integration

49

3 Business Process Execution Language (BPEL) und deren Alternativen

Ziel

Zielrealisierung

Rekursive Komposition

Unterschiedliche Sichten Verwaltung des Lebenszyklusses Wiederherstellbarkeit Tabelle 3:

keine Einschränkung des Anwendungsgebietes (B2C, B2B, ...) gleiches Standard-Prozessintegrationsmodell für abstrakte und ausführbare Prozesse Zerlegung und Komposition von Prozessen als Web-Services Nutzung von hierarchischen und graphenorientierten Prozessmodell Trennung von abstrakten und ausführbaren Prozessen Implementationstransparenz für Nutzer des Prozesses (um die innere Entscheidungsfindung und Realisierung zu verbergen) Implizite Erzeugung und Termination von Prozessinstanzen Definition eines Identifikationsmechanismus für Prozessinstanzen Modell für lang andauernde Transaktionen incl. der Kompensationsverarbeitung

Ziele des Sprachentwurfs von WSBPEL 2.0 nach [BPEL06]

Abschließend ist festzustellen, dass WSBPEL teilweise ähnliche Ziele wie Web-Services aufweist. Hier sind vor allem die Interoperabilität und die flexible Integration als nahezu äquivalent zu nennen. Weitere vergleichbare Ziele sind die rekursive Komposition und die Beschreibung unterschiedlicher Sichten, welche allerdings in einer leicht veränderten Semantik Verwendung finden. Lediglich die Verwaltung des Lebenszyklusses und die Wiederherstellbarkeit sind allein WSBPEL zuzuordnen, da BPEL-Prozesse innerhalb langandauernder Transaktionen definiert auf Ausnahmen reagieren sollen.

3.2.2

Struktur eines BPEL-Prozesses

Mit der Struktur des BPEL-Prozesses soll eine statische Sicht auf diesen gegeben werden, weshalb hier zunächst weitestgehend auf die Betrachtung von Verarbeitungsaspekten verzichtet wird. Ganz allgemein ist zunächst festzustellen, dass ein BPEL-Prozess in zwei Teile: den Deklarationsteil und den Prozessbeschreibungsteil, gegliedert ist. Während der Deklarationsteil alle Vereinbarungen, Festlegungen und Definitionen enthält, bildet der Prozessbeschreibungsteil den Ablauf des eigentlichen Prozesses, in Form von teilweise hierarchisch geschachtelten Aktivitäten, ab. Auf Grund dieses hierarchischen und rekursiven Aufbaus, ist eine Metagrammatik notwendig, welche den exakten Aufbau eines

50

3 Business Process Execution Language (BPEL) und deren Alternativen

BPEL-Prozesses beschreibt. Diese wurde in Anlehnung an [BPEL06] im Anhang A zusammengefasst. Die nachfolgende Abbildung zeigt noch einmal den Aufbau eines BPELProzesses mit dessen wichtigsten Elementen, welche nachfolgend detaillierter beschrieben werden.

Abbildung 24:

Grundstruktur eines BPEL-Prozesses

Der Deklarationsteil umfasst dabei die Prozessattribute, Erweiterungsdefinitionen, ImportVerweise, PartnerLinks, Nachrichtenreferenzen, Variablendeklarationen, CorrelationSets sowie Fault- und Eventhandlers. Die Prozessattribute beschreiben grundlegende Eigenschaften des Gesamtprozesses. Hierbei kann der Name des Prozesses, der Zielnamensraum, eine Anfragesprache, eine Ausdruckssprache und das Verhalten bei einem JoinFailure oder einem StandardFault spezifiziert werden. Der Standardwert für die Anfrage- und die Ausdruckssprache ist "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0",

was

impliziert,

dass

XPath 1.0 Verwendung findet. Weiterhin ist zu beachten, dass die Unterscheidung zwischen einem abstrakten und einem ausführbaren Typ an Hand des referenzierten Namensraumes getroffen wird. Sofern von Spracherweiterungen von WSBPEL 2.0 gebraucht gemacht werden soll oder die Sprache eigenständig zu erweitern ist, sind die benutzten Erweiterungen zunächst zu

51

3 Business Process Execution Language (BPEL) und deren Alternativen

deklarieren. Dabei können unter dem extensions-Element beliebig viele extensions spezifiziert werden. Dabei ist jeweils zum einen der Namensraum zu definieren in dem die Erweiterung eingebunden ist und zum anderen ob der BPEL-Prozessor diese Erweiterung unterstützen muss und andernfalls den aktuellen Prozess mit exit beenden soll. Da BPEL-Prozesse unter anderem auch partnerLinkTypes, variableProperties und propertyAliases aus WSDL 1.1 nutzen, sind Funktionalitäten erforderlich, mit denen auf externe Dokumente verwiesen werden kann. Diese Möglichkeit ist mit dem import-Element gegeben, wobei beliebig viele Import-Deklarationen genutzt werden können. Für jede dieser Deklarationen ist dabei der absolute Namensraum, eine relative Position sowie optional der Importtyp anzugeben. Somit können beispielsweise auch nutzerdefinierte, komplexe XML-Typen Anwendung finden. Die PartnerLinks stellen die Interaktionsschnittstellen zu anderen Web-Service dar, welche selbstverständlich mit WSDL beschrieben sind. Hierbei wurden ähnlich zu der stufenweisen Definition von Web-Services einige Abstraktionsebenen eingeführt. Auf abstrakter Ebene können so genannte PartnerLinkTypes definiert werden, welche Informationen zur Rolle des Aufrufers und dem jeweiligen PortType aufweisen. Ein solcher PartnerLinkType ist mit dem PortType einer WSDL-Beschreibung zu vergleichen. Auf der nächsten Ebene wird dann der PartnerLink definiert, welcher dem Port in WSDL ähnelt. Hierbei können beliebig viele PartnerLinks mit einem PartnerLinkType genutzt werden. Letztendlich werden die PartnerLinks dann über konkrete endpoint references in Form von service-ref-Elementen genutzt, welche eine direkte Verbindung zu den service-Elementen in WSDL haben. Dadurch wird das dynamische Binden von PartnerLinks zur Laufzeit ermöglicht. Mit dem MessageExchange-Element und dessen MessageExchange-Kindelementen können Abhängigkeiten zwischen so genannten Inbound Message Actitvities (IMA) und einer reply-Aktivität deklariert werden. Hier wird zunächst jedoch lediglich der Name angegeben, welcher dann innerhalb eines receives referenziert wird. Die notwendigen Variablendeklarationen können, mit Hilfe des variables-Elementes und beliebig vieler variable-Kindelementen vorgenommen werden. Dabei sind WSDLNachrichtentypen,

einfache

und

komplexe

XML-Schematypen

sowie

XML-

52

3 Business Process Execution Language (BPEL) und deren Alternativen

Schemaelemente als Typ der Variablen verwendbar. Bei dieser Deklaration kann der Namensraum, der Name, der Nachrichtentyp, sowie eventuelle Untertypen und Elemente angegeben werden. Die CorrelationSets erlauben auf deklarative Weise die Verbindung zwischen versandten beziehungsweise empfangenen Nachrichten und Instanzen des BPEL-Prozesses zu beschreiben, da alle Prozessinstanzen an die gleiche endpoint-reference gebunden sind und somit ein Routing der eingehenden Nachrichten zu den einzelnen BPEL-Prozessinstanzen erforderlich ist. Die Deklaration erfolgt mit dem correlationSets-Element und dessen correlationSet-Kindelementen. Hierbei werden für jedes CorrelationSet ein Name sowie eine Eigenschaftsliste angegeben. Die einzelnen Eigenschaften dieser Liste sind einfache XML-Schematypen und werden in dem referenzierten WSDL-Dokument deklariert. Auf Grundlage der Werte dieser Eigenschaften können dann die einzelnen Nachrichten konkreten Prozessinstanzen zugeordnet werden. Mit der Möglichkeit der Definition von so genannten FaultHandlers können nutzerdefinierte Fehlerbehandlungen initiiert werden. Die Art der Deklaration ähnelt dabei sehr stark den aus objektorientierten Programmiersprachen bekanntem Exception Handling mit try-catch-Konstrukten. In WSBPEL können entweder spezielle Fehler mit catch abgefangen und mit einer beliebigen Aktivität behandelt oder mit catchall auf alle möglichen Fehlertypen reagiert werden. Mögliche auftretende Fehler sind zum einen Fehler die in Folge eines invokes vom Partner zurückgesandt, oder zum anderen Fehler welche explizit mit der throw-Aktivität initiiert wurden. Die Eventhandler bieten sehr umfangreiche Funktionalitäten der Behandlung von Ereignissen und Alarmen an. Die Deklaration wird mit dem eventHandlers-Element und dessen Kindelementen onEvent und onAlarm, welche jeweils beliebig oft benutzt werden können, vorgenommen. Innerhalb der onEvent- und onAlarm-Elemente wird dann eine scope-Aktivität angegeben und somit entweder ein kompletter Prozess oder einzelne ScopeAktivitäten assoziiert. Im Gegensatz zum Deklarationsteil umfasst der Prozessbeschreibungsteil exakt eine Aktivität. Da Aktivitäten jedoch hierarchisch geschachtelt werden können, ist hiermit der vollständige BPEL-Prozess beschreibbar. Unter einer Aktivität ist dabei ein Baustein zu

53

3 Business Process Execution Language (BPEL) und deren Alternativen

verstehen, welcher an unterschiedlichen Stellen des Prozesses einsetzbar ist und im Rahmen der Betrachtung als gerichteter Graph einen Knoten darstellt. Da die einzelnen Aktivitäten im eigentlichen Sinne die Mächtigkeit einer Prozessbeschreibungssprache definieren, sollen sie an dieser Stelle besondere Beachtung finden. Zunächst ist jedoch die Erweiterung des Sprachumfanges von WSBPEL 1.1 zu WSBPEL 2.0 an Hand der Veränderung der Aktivitäten in Form einer Tabelle zu beleuchten. Kategorie

BPEL4WS 1.1 [BPEL03]

WSBPEL 2.0 [BPEL06]

Basisaktivitäten







Strukturierte Aktivitäten

Transaktionsaktivitäten Web-ServiceAktivitäten



Erweiterung Tabelle 4:

Überblick BPEL-Aktivitäten

Basisaktivitäten In der Kategorie der BPEL Basisaktivitäten wurden alle Aktivitäten zusammengefasst, welche eine elementare Funktion repräsentieren, das heißt selbst keine weiteren Aktivitäten enthalten können, sowie nicht den Web-Service-Aktivitäten zugeordnet werden.

54

3 Business Process Execution Language (BPEL) und deren Alternativen

•

Assign Die Assign-Aktivität ist als einfache Wertzuweisung für Variablen zu verstehen. Hierbei kann diese beliebig viele elementare Wertzuweisungen in Form des copyElementes enthalten. Da allein damit keine umfangreichen XML Transformationen realisierbar wären, kann die Funktion bpel:doXslTransform(...) genutzt werden. Dieser sind die URI eines Stylesheets, eine Variable, sowie optionale Parameter für den XSLT-Prozessor zu übergeben.

•

Validate Mit der validate-Aktivität, welche erst in WSBPEL 2.0 eingeführt wurde, kann der Zustand einer Variablen gegen dessen XML- respektive WSDL-Definition auf Gültigkeit überprüft werden.

•

Throw Die throw-Aktivität erlaubt die Erzeugung einer Störung innerhalb des Prozesses. Dies ist mit dem throw-Schlüsselwort objektorientierter Programmiersprachen wie beispielsweise C# und Java zu vergleichen, womit eine Ausnahme erzeugt wird.

•

Rethrow Diese Aktivität dient dem weitergeben einer behandelten Ausnahme, weshalb rethrow ausschließlich in einem faultHandler genutzt werden darf.

•

Exit Die exit-Aktivität, welche in WSBPEL 2.0 die terminate-Aktivität ersetzt, erlaubt das sofortige Beenden des aktuellen Prozesses, ohne jegliche Kompensation beziehungsweise Fehlerbehandlung.

•

Wait Diese Aktivität bewirkt eine Unterbrechung der Abarbeitung für einen bestimmten Zeitraum (duration) respektive bis zu einem vorgegebenem Zeitpunkt (deadline).

55

3 Business Process Execution Language (BPEL) und deren Alternativen

•

Empty Für die Empty-Aktivität ist keinerlei Operation vorgesehen. Somit stellt dies lediglich einen leeren Knoten dar, der beispielsweise zur Synchronisation von parallelen Abläufen eingesetzt werden kann.

Strukturierte Aktivitäten Unter den strukturierten Aktivitäten sind im Allgemeinen Aktivitäten zu verstehen, welche wiederum beliebige Aktivitäten enthalten können. Somit bilden diese die Grundlage der hierarchischen Prozessbeschreibung in WSBPEL. •

Sequence Die sequence-Aktivität stellt eine oder mehrere Aktivitäten dar, welche sequentiell, in der vorgegebenen Reihenfolge, abgearbeitet werden. Das Ende dieser Aktivität tritt mit dem Ende der Bearbeitung der letzten Aktivität ein.

•

If Eine erst in WSBPEL 2.0 eingeführte Aktivität stellt die if-Aktivität dar, welche die frühere switch-Aktivität vollständig ersetzt und die Ausführung genau einer Aktivität bewirkt. Sie enthält neben der Angabe einer Bedingung in Form der so genannten condition, beliebig viele elseif-Elemente, für welche ebenfalls eine Aktivität anzugeben ist. Des Weiteren kann ein else-Element, wiederum in Verbindung mit einer Aktivität, genutzt werden.

•

While Die while-Aktivität stellt eine kopfgesteuerte Iteration dar, welche solange ausgeführt wird, bis die zu spezifizierende Bedingung den booleschen Wert falsch annimmt. Dabei kann als Schleifenkörper eine Aktivität angegeben werden.

•

RepeatUntil Ähnlich wie die while-Aktivität stellt auch repeatuntil eine Iteration dar, wobei der

56

3 Business Process Execution Language (BPEL) und deren Alternativen

Schleifenkörper auch hier durch eine Aktivität abgebildet wird. Im Gegensatz zum while, wurde repeatuntil allerdings erst in WSBPEL 2.0 eingeführt und stellt eine fußgesteuerte Iteration dar, welche solange ausgeführt wird, bis die zu spezifizierende Bedingung den booleschen Wert wahr annimmt. •

Pick Die pick-Aktivität stellt ganz abstrahiert betrachtet eine Art EventHandler dar. So werden innerhalb dieser Aktivität beliebig viele Event/Aktivitäts-Paare spezifiziert, um festzulegen welche Aktivität beim Eintritt eines bestimmten Ereignisses auszuführen ist. Treten mehrere der Ereignisse ein, ist lediglich das erste Ereignis auszuwerten. Dabei können sowohl Nachrichten als auch so genannte Alarme der Auslöser sein. Der wichtigste Unterschied zu einem EventHandler ist, dass die pickAktivität blockierend auf Ereignisse wartet. Somit ist diese Aktivität durchaus mit der Receive-Aktivität zu vergleichen.

•

Flow Die flow-Aktivität ermöglicht die nebenläufige Verarbeitung beliebiger Aktivitäten und deren Synchronisation. So endet die flow-Aktivität im Gegensatz zur SequenceAktivität erst dann wenn alle parallelen Aktivitäten beendet wurden. Ein essentieller Bestandteil dieser Aktivität ist die Spezifizierung so genannter Links.

•

Foreach Prinzipiell ist die foreach-Aktivität zunächst als eine kopfgesteuerte Schleife zu verstehen, welche erst seit WSBPEL 2.0 existent ist und solange abläuft, bis startCounterValue plus eine Zählvariable kleiner gleich finalCounterValue ist. Der Schleifenkörper besteht dabei stets aus einer scope-Aktivität. Hierbei sind jedoch einige Besonderheiten zu beachten. So kann foreach in zwei Ausprägungen genutzt werden: o Parallel o Seriell

57

3 Business Process Execution Language (BPEL) und deren Alternativen

Bei der Nutzung eines parallelen foreach werden alle scope-Aktivitäten parallel zur Ausführung gebracht, so dass implizit eine flow-Aktivität modelliert wurde. Im Fall der seriellen foreach entspricht dies der sequence-Aktivität. Web-Service-Aktivitäten Unter den Web-Service-Aktivitäten sind Knoten zu verstehen, welche die Interaktion eines BPEL-Prozesses mit so genannten PartnerLinks also anderen Web-Services beschreiben. •

Receive Die receive-Aktivität erlaubt es den Prozess in ein blockierendes Warten auf eine passende Nachricht zu versetzen. Über das messageExchange-Attribut kann dabei eine reply-Aktivität assoziiert werden.

•

Reply Mit dieser Aktivität kann eine Nachricht als Antwort auf eine so genannte Inbound Message Activity (IMA) versand werden. Eine solche IMA ist eines der Elemente: receive, onMessage oder onEvent. Als Gegenstück zum receive kann auch hier über das messageExchange-Attribut eine receive-Aktivität assoziiert werden.

•

Invoke Im Gegensatz zur reply-Aktivität kann invoke zum Versenden einer Nachricht an ein System verwendet werden, wobei dem Senden nicht das Empfangen einer damit verbunden Nachricht vorausgehen muss. Neben dem unidirektionalen Aufruf kann die Invoke-Aktivität auch in einem Request-Response-Modus verwendet werden, wobei die Invoke-Aktivität synchron auf das Eintreffen einer Antwortnachricht wartet.

Transaktions-Aktivitäten Diese Aktivitäten bieten die Möglichkeit das ACID-Prinzip [GRAY81], [GRAY93] auf den Kontext der Web-Service-Orchestrierung abzubilden. Hierbei stehen besonders Aspekte

58

3 Business Process Execution Language (BPEL) und deren Alternativen

wie Atomarität und Isolation im Vordergrund. •

Scope Die umfassende scope-Aktivität dient zur Definition einer Aktivität mit eigenen partnerLinks,

messageExchanges,

Variablen,

correlationSets,

faultHandlers,

compensationHandler, terminationHandler und eventHandlers. Ruft man sich jetzt Basisaktivitäten wie sequence und flow in Erinnerung so kann man unter scope durchaus einen Teilprozess beziehungsweise eine Transaktion verstehen. •

Compensate Diese Aktivität dient zur Ausführung der Kompensation bereits erfolgreich beendeter scope-Aktivitäten, wobei diese allerdings nur in faultHandlern, compensationHandlern respektive terminationHandlern verwendet werden dürfen.

•

CompensationScope Die compensateScope-Aktivität dient dem gleichen Zweck wie compensate, jedoch wird hierbei eine spezifische Aktivität angegeben.

Erweiterung WSBPEL 2.0 bietet eine grundlegende Erweiterungsmöglichkeit. Diese wird unter anderem dazu benutzt die im Teilkapitel 3.3 vorgestellten BPEL-Erweiterungen derart zu realisieren, dass die proprietären Funktionalitäten innerhalb dieser einen Aktivität gekapselt werden. •

ExtensionActivity Die extensionActivity erlaubt die Erweiterung von WSBPEL durch die Einführung neuer Aktivitäten in Form eines Elementes. Dies bietet auf der einen Seite die Möglichkeit der permanenten und flexiblen Erweiterung. Auf der anderen Seite birgt dies jedoch die Gefahr von nicht standardisierten Erweiterungen in sich, wodurch die Abhängigkeit von spezifischen Produkten bedeutend erhöht wird.

59

3 Business Process Execution Language (BPEL) und deren Alternativen

3.2.3

Ausgewählte Aspekte der Verarbeitung

Nachdem nunmehr die statischen Aspekte von BPEL-Prozessen beschrieben wurden, soll in diesem Abschnitt auf ausgewählte dynamische Aspekte der Verarbeitung von BPELProzessen eingegangen werden. Hierfür wurden die folgenden drei Themen ausgewählt: •

Der Lebenszyklus von BPEL-Prozessen

•

Die parallele Verarbeitung von Teilprozessen

•

Fehlerbehandlung und Kompensationen

Der Lebenszyklus von BPEL-Prozessen Das Interaktionsmodell von WSBPEL, welches direkt von WSDL unterstützt wird, stellt im eigentlichen Sinne ein zustandsloses Client/Server-Modell für synchrone beziehungsweise unkorrelierte asynchrone Interaktionen dar. Da BPEL-Prozesse auf Grund ihrer Semantik jedoch eher langandauernde und zustandsbehaftete Interaktionen abbilden, kommt dem Lebenszyklus von BPEL-Prozessen eine besondere Bedeutung zu.

Abbildung 25:

Verwaltung von BPEL-Prozessinstanzen

Wie in der zuvorgehenden Abbildung visualisiert, ist ein BPEL-Prozess als eine Vorlage für eine Menge von parallelen Prozessinstanzen anzusehen. Ganz abstrakt betrachtet besteht ein BPEL-Prozess aus einem Start, einem definierten Verhalten und einem Ende.

60

3 Business Process Execution Language (BPEL) und deren Alternativen

Hierbei ist jedoch anzumerken, dass der Start und das Ende nicht explizit angegeben werden, sondern implizit in den Funktionalitäten von WSBPEL enthalten sind. Der Start eines BPEL-Prozesses kann durch Aktivitäten, welche auf eingehende Nachrichten warten, abgebildet werden. Somit können die receive- und die pick-Aktivität, in Verbindung mit dem Setzen des Attributes createInstance auf “yes“, als Start-Aktivität eines Prozesses genutzt werden. Hierbei muss ein BPEL-Prozess wenigstens eine StartAktivität aufweisen. Allerdings kann dieser ein definiertes Verhalten vorausgehen. Sofern während des eigentlichen Prozessablaufes weitere Interaktionen mit anderen Web-Services initiiert werden, besteht die Problematik der Zuordnung von Antwortnachrichten an die bestimmten Prozessinstanzen. Dafür stellt WSBPEL einen Identifikationsmechanismus für Prozessinstanzen in Form der CorrelationSets zur Verfügung. Diese Zuordnung ist zunächst wieder schematisch dargestellt.

Abbildung 26:

Identifikationsmechanismus von BPEL-Prozessinstanzen

Die in einem CorrelationSet festgelegten Attribute werden bei der Assoziation innerhalb der SOAP-Nachricht erwartet, da andernfalls keine Zuordnung zu bestimmten Prozessinstanzen möglich ist. Das Ende eines Prozesses kann entweder normal oder abnormal erfolgen. Bei einem normalen Ende, wurde die Prozessinstanz zunächst erfolgreich abgearbeitet und anschließend von der BPEL-Implementation zerstört. Im Gegensatz dazu ist bei einem abnormalen Ende entweder ein Fehler innerhalb der

61

3 Business Process Execution Language (BPEL) und deren Alternativen

Prozessabarbeitung aufgetreten oder die Prozessinstanz wurde explizit mit der exitAktivität, beispielsweise in Folge einer nicht erfolgreichen Validierung, abgebrochen und damit ebenfalls zerstört. Die parallele Verarbeitung von Teilprozessen Neben der eigentlichen parallelen Verarbeitung von mehreren Prozessinstanzen ermöglicht der Sprachumfang von WSBPEL auch die explizite und implizite Modellierung von paralleler Verarbeitung innerhalb einer Prozessinstanz. Diese soll nun kurz herausgearbeitet und zunächst in Form einer Abbildung dargestellt werden.

Abbildung 27:

Parallelverarbeitung in WSBPEL

Im Wesentlichen lassen sich drei verschiedene Möglichkeiten der Parallelverarbeitung differenzieren. Die explizite Variante ist die Nutzung der Flow-Aktivität, welche n parallele Aktivitäten, die natürlich wiederum hierarchisch aufgebaut sein können, ausführt und erst dann beendet wird, sobald alle Teilaktivitäten beendet sind. Eine weitere Variante ist die Nutzung der ForEach-Aktivität. Diese ist zwar eigentlich eine kopfgesteuerte Schleife, kann allerdings neben der seriellen Verarbeitung auch parallel ausgeführt werden. Hierbei wird die Abbruchbedingung nur einmal bewertet und dann implizit in eine Flow-Aktivität transformiert, wobei die referenzierte Scope-Aktivität für jede berechnete Iteration einmal ausgeführt werden muss. Die dritte Variante ist die Nutzung der EventHandler, welche innerhalb eines Prozesses oder einer Scope-Aktivität definiert wurden. Hierbei sind beliebig viele Scope-Aktivitäten, welche von den jeweiligen EventHandlern referenziert

62

3 Business Process Execution Language (BPEL) und deren Alternativen

werden, parallel verarbeitbar. Die ForEach-Aktivität und die Variante der EventHandler haben gemeinsam, dass Sie ausschließlich die Verarbeitung von Scope-Aktivitäten initiieren können, um die nebenläufige Veränderung der gemeinsamen Daten zu unterbinden, da beide nur implizit die Parallelverarbeitung ermöglichen. Fehlerbehandlung und Kompensationen Grundlegend muss man zunächst zwischen der Fehlerbehandlung und der Kompensation unterscheiden, da sie zwar oft in Verbindung eingesetzt werden, jedoch völlig unterschiedliche Dinge adressieren. So versteht man unter Fehlerbehandlung die Reaktion auf anomales Verhalten eines Teilprozesses, was durch einen Fehler angezeigt wird. Fehler können dabei als Folge der Interaktion mit anderen Web-Services oder explizit mit der throw-Aktivität auftreten. Im Gegensatz dazu adressiert eine Kompensation die Rücksetzung erfolgreich abgeschlossener Teilprozesse in Form von Scopes. Die eigentliche Behandlung wird durch die optional zu definierenden Fault- und CompensationHandler vorgenommen. Die folgende Abbildung zeigt schematisch ein Fehlerszenario und visualisiert dabei wie Fault- und CompensationHandler zusammen eingesetzt werden.

Abbildung 28:

Fehlerbehandlung und Kompensation in BPEL-Prozessen

63

3 Business Process Execution Language (BPEL) und deren Alternativen

Die Abbildung 28 zeigt einen BPEL-Prozess, dessen Hauptaktivität eine Sequence ist und für den ein FaultHandler F0 deklariert wurde. Die Sequence beinhaltet zwei Scopes S1 und S2 mit den jeweiligen Fault- und CompensationHandlern. Im Weiteren wird angenommen, dass die Scope-Aktivität S1 samt aller inneren Aktivitäten erfolgreich ausgeführt wurde. Bei der Ausführung der Aktivität A2, innerhalb von S2, kommt es dann jedoch zu einem Fehler (1.). Dieser wird von dem nahesten FaultHandler (2.) mit catch beziehungsweise catchAll abgefangen. Nun bestehen die Möglichkeiten diesen Fehler entweder lokal zu behandeln (3.b) und dann die Verarbeitung fortzusetzen oder den Fehler per expliziter rethrow-Aktivität (3.a) an die nächst höhere Ebene weiter zu werfen. Im letzteren Falle würde dann wiederum der FaultHandler F0 den Fehler (4.) abfangen. Hiermit würde aber signalisiert dass der gesamte Prozess nicht erfolgreich war, weshalb auch die ScopeAktivität S1 rückgängig zu machen wäre. Der FaultHandler F0 könnte nun ein compensate initiieren, wodurch alle Scopes, mit einem erfolgreichen Endzustand, per Kompensation rückgängig gemacht würden, oder er ruft per compensateScope einen bestimmten ComensationHandler (5.) auf. Dieser kann nun wiederum entweder alle gemachten Änderungen lokal (6.b) zurücksetzen, oder rekursiv CompensationHandler innerer Scopes (6.a) aufrufen, welche dann wiederum definierte Behandlungen (7.) durchführen. Abschließend bleibt noch zu erwähnen, dass die Zustände der einzelnen Scopes vorgehalten werden, so dass CompensationHandler den Zustand des eigenen Scopes sowie die Zustände aller höheren Ebenen auswerten können. Im Gegensatz dazu ist der Aufruf gerade inverse. So

kann

ein

CompensationHandler

ausschließlich

aus

FaultHandlern,

CompensationHandlern oder TerminationHandlern der höheren Ebene aufgerufen werden. Am Ende dieses Teilkapitels bleibt mit Ausblick auf die prototypische Implementierung festzustellen, dass die statischen Funktionalitäten nahezu vollständig als relevant für die Nachrichtentransformation einzuschätzen sind, während die dynamischen Aspekte der Verarbeitung lediglich im übertragenen Sinne und stark reduziert übernommen werden.

64

3 Business Process Execution Language (BPEL) und deren Alternativen

3.3

Spracherweiterungsvorschläge für WSBPEL

In diesem Teilkapitel sollen die wichtigsten BPEL-Erweiterungsvorschläge aufgezeigt werden. Dabei ist zu erwähnen, dass die Erweiterungen in Bezug auf die Defizite des Sprachstandards

BPEL4WS

1.1

entwickelt

wurden,

welcher

noch

keinerlei

Erweiterungsmöglichkeit besaß. 3.3.1

BPEL for Java (BPELJ)

Die erste BPEL-Erweiterung ist “BPEL for Java” (BPELJ), welche im März 2004, in Folge einer Zusammenarbeit der Firmen “International Business Machines (IBM)” und “BEA Systems”, veröffentlicht wurde [BEXA04]. Dieser Erweiterungsvorschlag basiert auf dem Standard BPEL4WS 1.1 und befasst sich mit der gemeinsamen Nutzung von BPEL und Java zur effizienten Beschreibung von Geschäftsprozessen. Dabei wird die Trennung zwischen beiden Sprachen auf Grund des Verwendungszweckes getroffen. So wird BPEL auch als “Programming in the large” und Java als “Programming in the small” bezeichnet. Die Motivation für BPELJ ist einfach aus der ausschließlichen Orientierung von BPEL auf Web-Services abzuleiten. So waren die generellen Möglichkeiten auf Web-Services begrenzt, weshalb keine Komposition von J2EE-Komponenten realisierbar war und dementsprechend Altanwendungen zu überarbeiten wären. Weitere Defizite die für eine derartige

Spracherweiterung

gesprochen

haben,

waren

die

mangelnde

Erweiterungsmöglichkeit, die Frage der Parameterübergabe und die umständlichen und inperformanten XPath-Ausdrücke für einfache Zuweisungen, Initialisierungen und Bedingungen. Im Wesentlichen betrifft der Spracherweiterungsvorschlag die drei nachfolgend genannten und anschließend beschriebenen technischen Ziele, welche mit BPELJ realisiert werden sollen. •

Einbettung von Java-Quelltext in BPEL-Prozesse

•

Orchestrierung von Java-Komponenten

65

3 Business Process Execution Language (BPEL) und deren Alternativen

•

Erweiterung des Transaktionskonzeptes

Einbettung von Java-Quelltext in BPEL-Prozesse Prinzipiell werden zwei unterschiedliche Vorgehensweisen, BPEL und Java gemeinsam zu nutzen, unterstützt. So können zum einen Java-Snippets – kleine Quelltext-Fragmente – direkt in dem BPEL-Prozess verwendet werden. Der Nachteil hiervon ist, dass lediglich lokaler sequentieller Quellcode genutzt werden kann. Zum anderen kann ein BPELJProzess als eine Java-Klasse erstellt werden. Hierbei wird der eigentliche, leicht veränderte, BPEL-Prozess als Java Class Annotation direkt in der Quelltextdatei hinzugefügt. Somit können innerhalb des Prozesses dann einfache Methodenaufrufe genutzt werden. Dabei ergeben sich drei Änderungen für die Prozess-Deklaration. So wird der Prozess entsprechend des Namens der Java-Klasse benannt. Die Import-Deklarationen innerhalb des BPEL-Prozesses können entfallen, da hier die Import-Statements der Java-Klasse genutzt werden. Letztlich ist der Kontext aller Java-Snippets das Package, in dem die JavaKlasse definiert wurde. Java Snippets können also als Blöcke von Java-Quelltext verstanden werden, welcher in einem J2EE-Container ausgeführt wird. Hierbei können diese als Snippet-Aktivität, als Variableninitialisierungen oder als BPEL-Ausdrücke, also als Bedingungen, als Zeitausdrücke oder aber als Zuweisungen, verwendet werden. Allgemein betrachtet sind einige Gemeinsamkeiten mit Java Server Pages (JSP) zu erkennen. Innerhalb eines Snippets hat man vollen Zugriff auf alle Variablen, CorrelationSets und Statusinformationen. Ein Beispiel für die bereits genannte Snippet-Aktivität ist nachfolgend dargestellt. gesamtBetrag = menge * preis; if(gesamtBetrag>100) gesamtBetrag = gesamtBetrag * rabatt;

Die Snippet-Aktivität kann als eine private Methode verstanden werden, welche keinen Rückgabewert hat. Demzufolge adressiert diese eher einfache Zuweisungen und

66

3 Business Process Execution Language (BPEL) und deren Alternativen

Transformationen, während komplexere Transformationen eher in separate Java-Klassen ausgelagert und dann lediglich per Java Partner Link aufgerufen werden. Das Mapping zwischen den XML- und den Java-Variablen wird auf Grundlage des Attributes bpelj:xmlBinding durchgeführt.

In Bezug auf die verwendbaren Datentypen erweitert BPELJ die Auswahl um definierte Java-Klassen und –Interfaces. Elementare Java-Typen werden bewusst nicht angeboten, um ein großes Maß an Redundanz zu beseitigen. Wird in einem Snippet eine Variable definiert so kann auf diese nicht aus anderen Snippets zugegriffen werden. Auch ein returnStatement würde lediglich den aktuellen Snippet und nicht den gesamten Prozess beenden. Java Snippets können auch in Bedingungen von Schleifen, Alternativen und den Synchronisations-Bedingungen eingesetzt werden. Dies bietet sich vor allem bei der Verarbeitung von Java-Objekten an, welche von den orchestrierten Java-Komponenten an den Prozess übermittelt wurden. Letztlich können auch Deadline und Zeitdauerbeschränkungen mittels Java-Snippets in der Wait-Aktivität angeben werden. Auch die Nutzung nativer Java Exceptions per throw aus einem Java Snippet sind realisierbar, wobei die FaultHandler auf diese in der gleichen Weise wie auf die Throw-Aktivität zu reagieren haben. Orchestrierung von Java-Komponenten Mit der Definition von Java Partner Links ermöglicht BPELJ die Nutzung von JavaKomponenten mit der gleichen Aufrufsemantik wie Web-Services. Dies ermöglicht die einfache Integration von Altanwendungen und die Vermeidung von PerformanceEngpässen, welche durch die Verarbeitung von XML verursacht wird. Hierbei sind jedoch einige Dinge zu bemerken. Statt der WSDL-Metadaten eines Web-Service werden die JavaKomponenten über ein einfaches Java-Interface beschrieben. Die implementierenden Objekte müssen entweder in der gleichen JVM verarbeitet werden oder aber über RMI entfernt erreichbar sein. Letztendlich existieren zwei Aufruf-Varianten. So können die Java Partner Links entweder aus einfachen Java Snippets heraus aufgerufen werden oder über die BPEL-Aktivitäten invoke, receive und reply. Der wichtigste Unterschied der beiden Varianten ist die Möglichkeit der dynamischen Zuweisung von implementierenden Klassen

67

3 Business Process Execution Language (BPEL) und deren Alternativen

von externer Stelle bei der Nutzung der Standard-Konstrukte. Im Weiteren adaptiert BPELJ den Identifikationsmechanismus von Prozessinstanzen mittels den CorrelationSets. Hierbei ergeben sich nahezu keinerlei Änderungen zu dem BPEL-Standard. Allerdings wird in BPELJ die Nutzung so genannter opaquen Korrelationen vorgeschlagen, was die Transparenz des Identifikationsmechanismus fordert. Dies sollte dann ausschließlich durch die BPEL-Implementation realisiert werden. Weiterhin wird die Verwendung von Callbacks an Stelle von CorrelationSets vorgeschlagen, da somit der Identifikationsmechanismus entfallen könnte, weil die Antwort eines Aufrufes eines Java Partners per Returnwert der aufgerufenen Methode erfolgen kann.

Abbildung 29:

Orchestrierung von Java-Komponenten

Wie durch die Abbildung 29 gezeigt, können mit einem BPELJ-Prozess zugleich WebService als auch lokale und verteilte Java-Komponenten orchestriert werden. Erweiterung des Transaktionskonzeptes Ein weiterer Aspekt der BPELJ-Spezifikation ist die Erweiterung des BPELTransaktionskonzeptes um die Erfüllung des ACID-Prinzips. Dabei ist für eine ScopeAktivität lediglich ein Attribut acid auf “true“ zu setzen. Ein solcher Acid-Scope hat dabei die gleichen Eigenschaften wie ein normaler Scope, mit der zusätzlichen Bedingung, dass der Status der Transaktion erst zum Ende der Aktivität persistent gemacht wird. Das Hauptproblem liegt allerdings immer noch in der Kompensation von Dienstaufrufen, für

68

3 Business Process Execution Language (BPEL) und deren Alternativen

welche nicht garantiert werden kann ob sie erfolgreich ausgeführt oder rückgängig gemacht wurden. Scheitert eine Transaktion so ist diese erneut auszuführen. Damit es nicht zu einer Endlosschleife kommt, wird die Wiederholung der Transaktion nach retryCount Versuchen abgebrochen. Die Integration in WSBPEL 2.0 wird auf unterschiedliche Weise erfolgen. So ist angedacht die Snippet-Aktivität innerhalb der neuen extensionActivity einzuführen. Die sonstigen Java-Snippets und anderen Spracherweiterungen durch BPELJ sollen in Form von Einbettungen in die Standard-Konstrukte unter einem bestimmten Namespace erfolgen. Zusammenfassend lässt sich feststellen, dass BPELJ eine Spracherweiterung vorschlägt, welche auf dem Erweiterungsmechanismus von WSBPEL aufbaut und eine Möglichkeit bietet, alle Aspekte eines Geschäftsprozesses mit einer Mischung aus BPEL und Java zu beschreiben, wobei die lose Kopplung natürlich beeinträchtigt, jedoch auch eine ganze Reihe von interessanten Möglichkeiten hinzugefügt wird. Letztendlich bleibt noch zu erwähnen, dass im Moment noch nicht eindeutig fest steht, ob dies ein proprietärer Spracherweiterungsvorschlag bleibt, zur offiziellen Spracherweiterung deklariert oder in die artverwandten Spezifikationen JSR207 (Process Definition for Java) oder JSR208 (Java Business Integration) integriert wird.

3.3.2

WSBPEL Extension for people (BPEL4people)

Eine andere BPEL-Erweiterung stellt “WS-BPEL Extension for people” (BPEL4people) dar, welche erst im Juli 2005, in Zusammenarbeit von IBM und SAP veröffentlicht wurde [BEXB05]. BPEL4people adressiert dabei die Problematik von Human Interactions, da WSBPEL eigentlich nur auf Web-Services ausgelegt ist, und somit ausschließlich die automatisierte Interaktion von Software-Komponenten betrifft, zur Abbildung von Geschäftsprozessen jedoch natürlich auch die Schnittstelle zu manuellen Verarbeitungen gegeben sein muss. Innerhalb des Erweiterungsvorschlages werden, wie nachfolgend dargestellt, eine Reihe

69

3 Business Process Execution Language (BPEL) und deren Alternativen

von Szenarien beschrieben in denen Personen an Geschäftsprozessen beteiligt sind und Vorschläge unterbreitet, wie dies in BPEL abgebildet werden könnte. •

People-Aktivität Eine Person soll an einer bestimmten Stelle eines Prozesses eine konkrete Aufgabe realisieren. Dies kann als automatisierte Zuweisung einer Aufgabe zu einem Mitarbeiter verstanden werden.

•

Personen starten Geschäftsprozesse Auf Grund unterschiedlicher Berechtigungen darf nur eine Gruppe aller Mitarbeiter einen bestimmten Prozess starten. Aus diesem Grund ist es sinnvoll die Mitarbeiter mit diesem Prozess zu assoziieren.

•

Personen verwalten lang andauernde Prozesse Es sind Szenarien vorstellbar, in denen eine Person auf Ausnahmen innerhalb eines Prozesses reagieren muss und zur Laufzeit des Prozesses eine Entscheidung über dessen weiteren Fortgang in Anbetracht des betriebswirtschaftlichen Kontextes zu treffen hat.

•

Übergänge zwischen Personen und automatisierten Diensten Da es bei Betrachtung eines Prozesses als Web-Service unwichtig ist, ob dieser intern Human Interactions initiiert oder nicht, ist es erforderlich, dass die Übergänge zwischen der automatisierten Verarbeitung und einer Human Interaction möglichst harmonisch realisiert werden.

•

Interaktionsmuster o 4-Augen-Prinzip

(Entscheidungsfindung

mehrerer

Personen,

welche

teilweise nichts von den anderen Personen wissen dürfen) o Eskalation (Rücknahme einer Aufgabe von einer Person, welche beispielsweise aus Krankheit oder anderweitiger Verhinderung die Aufgabe nicht erfüllen kann) o Nominierung (eine Führungskraft ordnet erst zur Laufzeit des Prozesses, den Mitarbeitern Aufgaben zu)

70

3 Business Process Execution Language (BPEL) und deren Alternativen

o Zusammenhängende Ausführung (Eine Person führt eine Folge von Aufgaben zusammenhängend aus) Aufbauend auf diesen Szenarien definiert der Spracherweiterungsvorschlag eine Reihe von Funktionalitäten welche erforderlich sind um ein großes Spektrum der Human Interactions abzudecken. Für den Kontext der Integration von Personen in Geschäftsprozesse werden fünf semantische Rollen definiert: Process initiator, Process stakeholder, Potential owner, Owner und Business Administrator. Diese Rollen werden unter dem Begriff „Generic Human Roles“ zusammengefasst und beschreiben die Art der Integration einer Person. Um jedoch tatsächlich eine Person zu referenzieren, muss zunächst ein so genannter People Link deklariert werden, welcher die Assoziation zu einer Generic Human Role vornimmt und mit den bekannten Partner Links zu vergleichen ist. Dabei werden Queries angegeben, mit welchen dann die People Resolution, also die Zuordnung konkreter Personen zu den PeopleLinks, durchgeführt wird. Mit der PeopleActivity wird BPEL um eine Aktivität erweitert, welche nicht wie gewöhnlich durch eine Software-Komponente realisiert wird, sondern durch die Handlung einer Person. Dabei wird das Prinzip der People Resolution, welches zuvor beschrieben wurde, angewendet. Eine BPEL-Implementation würde bei der Ausführung einer solchen Aktivität beispielsweise eine Aufgabe innerhalb des Systems anlegen. Zu beachten ist die Möglichkeit der Angabe einer Deadline um die Blockierung von Prozessen durch die Nichterfüllung von Human Interaction zu verhindern. Innerhalb dieser PeopleActivity ist auch eine so genannte Task zu referenzieren. Diese repräsentiert eine Aufgabe die von einer Person zu realisieren ist. Natürlich kann eine solche Aufgabe auch Eigenschaften, wie beispielsweise eine Deadline, Input- und OutputDaten oder eine Priorität, haben. Die Spracherweiterung definiert eine Menge von Anfrageoperationen mit denen die aktuellen Aufgaben, zum Beispiel aus einem Client der alle Aufgaben verwaltet, durchsucht werden können. Dabei sind die unterschiedlichen Status der Aufgaben zu beachten. Außerdem existieren unterschiedliche Arten der Interaktion zwischen einem Prozess und einer Aufgabe, welche mit der folgenden

71

3 Business Process Execution Language (BPEL) und deren Alternativen

Abbildung lediglich dargestellt und benannt werden sollen.

Abbildung 30:

Interaktionsmöglichkeiten zwischen Prozess und Aufgabe

Weitere Diskussionspunkte in der Spracherweiterung sind die Behandlung des Kontextes in dem ein Prozess abgearbeitet wird, ein User Interface, über das die Input- und Outputdaten der konkreten Aufgabe zwischen Person und Software auszutauschen sind und letztlich wie man Dienste definieren könnte, welche sozusagen von Personen „implementiert“ werden. Die Erweiterung von WSBPEL ist wie auch bei BPELJ über die extensionActivity angedacht. Hierbei soll die peopleActivity als Kind-Element dieser benutzt werden.

3.3.3

WSBPEL Extension for Sub-processes (WSBPEL-SPE)

Mit “WS-BPEL Extension for Sub-processes – BPEL-SPE” haben IBM und SAP im September 2005 einen weiteren gemeinsamen Erweiterungsvorschlag für WSBPEL 2.0 unterbreitet [BEXC05]. Diese Erweiterung widmet sich vor allem dem Defizit, dass in BPEL Teilprozesse nicht ausreichend beschrieben werden können, so dass Kriterien wie Modularisierung und Wiederverwendbarkeit nicht gegeben sind. Der Erweiterungsvorschlag diskutiert dabei inhaltliche Probleme und syntaktische Fragen ohne eine exakte Sprachdefinition zu veröffentlichen. Insgesamt werden diese Hauptziele verfolgt:

72

3 Business Process Execution Language (BPEL) und deren Alternativen

•

Realisierung einer engen Bindung zwischen den Lebenszyklen von Haupt- und Teilprozessen

•

Definition von Prozess-Aktivitäten (Teilprozessen) innerhalb eines Hauptprozesses

•

Zugriff aus Teilprozessen auf Daten des Hauptprozesses

•

BPEL-Engine übergreifender Aufruf von Teilprozessen

Im Kern der Erweiterung werden 3 Aspekte diskutiert: die Definition von Teilprozessen, der Aufruf von Teilprozessen, sowie die Kommunikation/Koordination zwischen Prozessen. Bei der Definition von Prozessen unterscheidet man im Wesentlichen zwischen zwei Arten: Teilprozesse innerhalb eines Hauptprozesses und eigenständige Prozesse. Die zweite Art kann allerdings gleichermaßen sowohl als eigenständiger Prozess als auch als Teilprozess ausgeführt werden. Die unterschiedlichen Typen von Teilprozessen veranschaulicht auch die nachfolgende Abbildung.

Abbildung 31:

Aufrufszenarien in WSBPEL-SPE

Auch bei dem Aufruf der Teilprozesse werden zwei grundlegende Vorgehensweisen unterschieden, welche zwar noch weiter untersetzt werden, an dieser Stelle jedoch nicht im Detail zu analysieren sind. Die erste Variante wäre die Realisierung des Aufrufes als receive-reply-Muster, wobei die erste Aktivität des Teilprozesses eine receive-Aktivität im Sinne von Übergabeparametern ist und der letzte Knoten als reply-Aktivität als Rückgabewert modelliert werden kann. Die Variante zwei ist etwas fehleranfälliger. So

73

3 Business Process Execution Language (BPEL) und deren Alternativen

könnte man auch hier die erste Aktivität als receive modellieren. Allerdings wäre bei diesem Aufruf eine aufzurufende Operation des Hauptprozesses zu übergeben, welche am Ende des Teilprozesses mittels invoke aufgerufen wird. Der Aufruf wird bei beiden Varianten gleichermaßen mit der neu eingeführten call-Aktivität realisiert. Bei der Kommunikation/Koordination zwischen Prozessen werden vor allem Szenarien der Kommunikation zwischen unterschiedlichen BPEL-Infrastrukturen beschrieben, sowie die Beendigung, Fehlerbehandlung und Kompensation von Prozessen angesprochen. Die Erweiterung ist vor allem für sehr komplexe Prozessbeschreibungen als sehr sinnvoll einzuschätzen. Insgesamt wird allerdings auch diese Erweiterung nicht in den eigentlichen WSBPEL 2.0 Standard übernommen, sondern bleibt als Erweiterung bestehen, wobei diese auf BPEL aufbaut und deren Grundfunktionalitäten nutzt, und somit optional von BPEL Implementationen realisiert werden kann.

3.3.4

Information Integration for BPEL (II4BPEL)

Eine weitere BPEL-Erweiterung ist „Information Integration for BPEL“ (II4BPEL). Allerdings ist diese im eigentlichen Sinne noch nicht als Spracherweiterungsvorschlag, sondern vielmehr als ein proprietäres Konzept von IBM anzusehen, welches Ende 2004, im Rahmen des WebSphere Application Servers, veröffentlicht wurde [BEXD04]. In [MEIR05] ist allerdings von BPEL4SQL die Rede, so dass die Vermutung nahe liegt, dass IBM dies als vierten offiziellen Spracherweiterungsvorschlag publizieren wird. Die Motivation für die Integration von SQL-Funktionalität in BPEL ist der Technologietransfer existenter und bewährter Technologien in BPEL, um damit nicht nur lang andauernde und auf Web-Services beruhende Geschäftsprozesse abzubilden, sondern BPEL auch zur Informationsintegration und Anwendungsintegration in datenintensiven Prozessen einsetzen zu können. So wäre der Einsatz von BPEL mit wenigen Erweiterungen beispielsweise in ETL-Tools und CMS durchaus vorstellbar. Das Hauptproblem liegt im Impedance Mismatch zwischen der kontrollflussorientierten, tupelweisen Verarbeitung von BPEL und der datenflussorientierten, satzweisen Verarbeitung datenzentrischer Systeme.

74

3 Business Process Execution Language (BPEL) und deren Alternativen

Der Kern der Erweiterung II4BPEL definiert 4 neue BPEL-Aktivitäten, welche von IBM „Data Management Activities“ (DMA) genannt werden und einen einfacheren und effizienteren Zugriff auf Datenbestände ermöglichen sollen. Diese sind im Weiteren genannt und anschließend beschrieben. •

SQL-Aktivität

•

RetrieveSet-Aktivität

•

PersistSetChanges-Aktivität

•

StatementList-Aktivität

SQL-Aktivität Mit der SQL-Aktivität können einzelne SQL-Statements gegen eine spezifizierte DataSource ausgeführt werden. Damit kann eine Menge von Datensätzen in Form eines SetReference referenziert, Änderungen am Datenbestand initiiert, Wertzuweisungen zu Prozessvariablen gemacht oder Stored Procedures aufgerufen werden. RetrieveSet-Aktivität Die RetrieveSet-Aktivität ermöglicht das Laden der Daten welche durch eine SetReference referenziert werden. Dies ist erforderlich sofern die Daten im Prozess zu transformieren oder an einen Partner zu übermitteln sind, so dass folglich die einfache Arbeit mit Referenzen nicht mehr möglich ist. PersistSetChanges-Aktivität Die PersistSetChanges-Aktivität stellt eine Möglichkeit dar, vorgenommene Änderungen an dem transienten Set, welches zuvor mit einer RetrieveSet-Aktivität geladen wurde, im Datenhaltungssystem persistent zu machen. Diese Funktionalität ist dem, aus JDBC bekanntem, „updateable ResultSet“ sehr ähnlich. StatementList-Aktivität In dieser Aktivität können beliebig viele Statements hinterlegt werden, welche dann in

75

3 Business Process Execution Language (BPEL) und deren Alternativen

einer Art Batch-Verarbeitung ausgeführt werden. Dabei können SQL-, RetrieveSet- und PersistSetChanges-Statements verwendet werden. Zwei wesentliche Konzepte sind bei der Diskussion von II4BPEL unbedingt zu erwähnen: DataSources und SetReferences. Unter einer DataSource wird in diesem Kontext ein Datenhaltungssystem

verstanden,

auf

welchem

über

die

JDBC-Schnittstelle

Datenoperationen ausgeführt werden können. Eine DataSource wird dabei systemintern durch eine Instanz des Datentyps tDataSource repräsentiert. Eine SetReference ist darauf aufbauend eine Referenz auf eine Tabelle innerhalb der angegebenen DataSource. Auch dies wird durch einen Datentyp repräsentiert: tSetReference. Somit kann eine Instanz dieser logischen Tabelle als Input- und Output-Parameter der DMAs verwendet werden. Nachfolgend wird noch einmal das Zusammenspiel zwischen den DMAs, den DataSources und den SetReferences schematisch dargestellt.

Abbildung 32:

Abschließend

bleibt

Funktionsweise der II4BPEL Data Management Activities

zusammenzufassen,

dass

es

eine

ganze

Reihe

von

Anwendungsszenarien für derartige datenzentrische Prozesse gibt, in denen man auf Grund von Komplexitätsreduzierung, aber vor allem wegen Performanceverbesserungen bewusst auf die lose Kopplung des Nachrichtenaustausches mittels Web-Services verzichtet, jedoch die Vorteile einer Prozessbeschreibung weiter nutzen möchte. II4BPEL adressiert damit ähnliche Ziele wie diese Arbeit, genügt jedoch den definierten Anforderungen nicht.

76

3 Business Process Execution Language (BPEL) und deren Alternativen

3.4

Produktvergleich aktueller BPEL-Implementationen

In diesem Teilkapitel soll lediglich ein grober Überblick über die wichtigsten BPELImplementationen gegeben werden. Dabei ist einer BPEL-Implementation eine große Bedeutung als Middleware-Plattform zu zugestehen, da diese die WSBPEL-Spezifikation realisiert und teilweise die im Teilkapitel 3.3 vorgestellten Spracherweiterungen unterstützt. Eine BPEL-Implementation lässt sich grundlegend in zwei Komponenten differenzieren: den BPEL-Designer und die BPEL-ProcessEngine, wobei teilweise auch ausschließlich ProcessEngines angeboten werden. Ein BPEL-Designer ermöglicht die Modellierung von BPEL-Prozessen mit einem graphischen Editor, wobei die meisten Designer in Form einer IDE erstellt wurden, so dass aus dem Designer direkt auf die ProcessEngine zugegriffen werden kann. Die ProcessEngine hingegen ermöglicht das Deployment von BPEL-Prozesse und damit letztendlich die Ausführung von Prozessinstanzen. Gegenwärtig entdecken nahezu alle Application Server-Hersteller das Gebiet des BPM für sich und integrieren die entsprechenden Komponenten in die Application Server, wobei an dieser Stelle festzuhalten ist, dass prinzipiell kein Anwendungsserver erforderlich ist. Im Weiteren soll nun kurz auf ausgewählte kommerzielle und nicht-kommerzielle BPEL-Implementationen eingegangen werden. Kommerzielle BPEL-Implementationen •

BPWS4J (IBM, http://www.alphaworks.ibm.com/tech/bpws4j) Die Business Process Execution Language for Web Services Java (BPWS4J) – Laufzeitumgebung von IBM ist eine BPEL-Implementation, welche den Standard selbst sowie alle genannten Spracherweiterungen realisiert. Dabei wird ein Designer für Eclipse im Rahmen des WebSphere Developer Studios angeboten. Diese Komponenten werden von IBM, integriert in dem Application Server WebSphere, vertrieben.

•

BPEL Process Manager (Oracle, http://oracle.com/technology/products/ias/bpel/) Der Oracle Process Manager ist eine BPEL-Implementation, welche neben den Standardfunktionalitäten, diverse proprietäre Erweiterungen beinhaltet. Der Process

77

3 Business Process Execution Language (BPEL) und deren Alternativen

Manager umfasst neben der eigentlichen Laufzeitumgebung auch einen Designer welcher in Form eines Plugins sowohl in den JDeveloper als auch in Eclipse eingebettet werden kann. Die Laufzeitumgebung benötigt standardmäßig den Oracle Application Server, kann aber auch unter JBoss und BEA WebLogic zum Einsatz kommen. •

ccBPM (SAP, http://help.sap.com/ saphelp_nw04/helpdata/de/3c/831620a4f1044dba38b370f77835cc/content.htm ) SAP weist im Rahmen des SAP NetWeaver eigene Konstrukte auf mit denen Integrationsprozesse und vor allem auch Geschäftsprozesse modelliert werden können. Allerdings können beispielsweise mit der cross component der eXchange Infrastruktur (XI) auch BPEL-Prozesse modelliert, importiert und exportiert werden.

•

Biztalk Server (Microsoft, http://www.microsoft.com/biztalk/) Obwohl der Biztalk-Server eigentlich ebenfalls seine eigenen Sprachkonstrukte aufweist, welche im Übrigen noch stark an XLANG erinnern, unterstützt Microsoft auch den Import und Export von BPEL-Prozessen und damit deren Ausführung.

Nicht-Kommerzielle BPEL-Implementationen •

Agila (Apache, http://incubator.apache.org/projects/agila/index.html ) Die Agila Engine ist ein Apache Open Source Projekt, welches mittlerweile mit der BPEL-Implementation Twister konsolidiert wurde. Das Hauptziel von Agila ist es, eine

möglichst

leichtgewichtige

BPEL-Engine,

jedoch

mit

vollem

Funktionsumfang, anzubieten. •

jBPM (JBoss, http://www.jboss.com/products/jbpm) JBoss bietet mit jBPM eine BPEL-Implementierung an, welche einen BPELDesigner als auch die eigentliche Laufzeitumgebung enthält. Diese ist in den JBoss Application Server integriert und wird als separate Server-Variante angeboten. JBoss realisiert dabei nicht nur die Standardfunktionalitäten von BPEL sondern unter anderem auch die Spracherweiterung BPELJ.

78

3 Business Process Execution Language (BPEL) und deren Alternativen

•

PXE (FiveSigth, http://pxe.fivesight.com/ ) Die Process eXecution Engine (PXE) ist eine reine Ausführungsumgebung für BPEL4WS und WSBPEL, wobei sie als Sourceforge-Project verwaltet wird. Diese Laufzeitumgebung ist unter anderem auch in den Sun Application Server eingebettet worden, um im Zusammenspiel mit der IDE NetBeans, die BPELModellierung und -Ausführung zu ermöglichen.

•

ActiveBPEL (ActiveBPEL, http://activebpel.org/index.html ) Die ActiveBPEL Engine stellt ein Open Source Projekt dar, welches mittlerweile in der Version 2.0 ist und neben der eigentlichen Laufzeitumgebung auch einen BPELDesigner sowie eine Web-Konsole anbietet.

Natürlich gibt es noch weitere BPEL-Implementierungen. Beispiele für derartige Engines sind in [HANT06], [OSWI06], [IBM06a] und [KÜMP04] benannt. Abschließend muss jedoch eingeschätzt werden, dass zum Zeitpunkt dieser Arbeit noch keine BPELImplementation existierte, welche den Standard WSBPEL 2.0 vollständig realisierte.

3.5

Alternative Beschreibungssprachen

In diesem Teilkapitel soll ein Überblick der, zum Zeitpunkt der Diplomarbeit aktuellen, alternativen Prozessbeschreibungssprachen gegeben werden, wobei die einzelnen Sprachen entsprechend des, in Teilkapitel 3.1 eingeführten, Abstraktionsgrades geordnet wurden. Dabei sind die jeweiligen Beschreibungen nicht als vollständige Analyse, sondern vielmehr als ein Blick über die Grenzen der Diplomarbeit zu verstehen. Prinzipiell lassen sich die Alternativen verschiedenen Ebenen zuordnen, welche durch die folgende Abbildung zunächst visualisiert und anschließend beschrieben werden.

79

3 Business Process Execution Language (BPEL) und deren Alternativen

Abbildung 33:

Klassifizierung der Alternativen zu WSBPEL

Die Sprachen BPMN und UML Aktivitätsdiagramme beschreiben jeweils eine grafische Notation mit der Geschäftsprozesse abgebildet werden können. Dabei definieren diese keine Sprache mit der Geschäftsprozesse wirklich technisch beschreibbar sind. Auf der Beschreibungsebene werden zwar technisch verarbeitbare Definitionen erstellt, allerdings sind die so definierten Prozessbeschreibungen lediglich als Metadaten zu verstehen, welche nicht ausführbar sind. Die eigentlichen ausführbaren Sprachen, besser indirekt ausführbaren Sprachen, sind in die Realisierungsebene einzuordnen und stellen somit, vom Entwurf der Sprache, die eigentlichen Alternativen zu WSBPEL dar. Ein wichtiger Punkt ist die Möglichkeit der Generierung einer Prozessbeschreibung der jeweils niedrigeren Ebene. Ebenfalls das Reverse Engineering sollte in naher Zukunft in diesen Bereich Einzug halten. 3.5.1

Unified Modeling Language 2.0 (UML) Aktivitätsdiagramme

Die Unified Modeling Language wurde in Zusammenarbeit von Booch, Jacobson und Rumbaugh entwickelt und anschließend 1997 an die Standardisierungsorganisation OMG (Object Manifest Group) übergeben. Im Jahr 2005 wurde dann die generell überarbeitete Version 2.0 als abgeschlossen freigegeben. Die Sprachspezifikation gliedert sich dabei in drei Teile: die UML Infrastructure, UML Superstructure und UML OCL RFP. Dabei enthält UML 2.0 als Standard mittlerweile 13 Diagrammarten. Mit diesen können die unterschiedlichen Aspekte der Analyse und des Entwurfes objektorientierter Software mit Hilfe einer rein grafischen Notation abgebildet werden. Das Aktivitätsdiagramm ist dabei in die Gruppe der Verhaltensdiagramme der UML einzuordnen [WIKIDE], [UML05]. Die Aktivitätsdiagramme werden prinzipiell zur Beschreibung von sowohl manuellen als

80

3 Business Process Execution Language (BPEL) und deren Alternativen

auch automatisierten Aktivitäten eingesetzt und bilden so den Kontroll- und Datenfluss ab, welche

bei

den

UML

Aktivitätsdiagrammen

explizit

getrennt

werden.

Die

Hauptanwendungsgebiete sind die Spezifikation von Anwendungsfällen im Rahmen der Anforderungsanalyse und die Abbildung der dynamischen Aspekte eines Systems in Form von Ablauf- oder auch Flussdiagrammen. Es existieren bereits sehr viele Arbeiten, welche aufzeigen inwieweit die UML 2.0 Aktivitätsdiagramme auch zur Beschreibung von Geschäftsprozessen und damit ferner auch für Integrationsprozesse Einsatz finden können. Die Ausdrucksmöglichkeiten wurden dabei mit UML 2.0 im Vergleich zu UML 1.5 noch einmal erweitert, indem die Semantik noch stärker an die der Petri-Netze angenähert wurde [NIER05], [GAGM06]. Ein Aktivitätsdiagramm kann auf Knoten und Kanten reduziert werden, wobei Knoten entweder Kontrollknoten oder Objektknoten und die Kanten entweder Kontrollflüsse oder Objektflüsse sind. Die wichtigsten Elemente eines Aktivitätsdiagramms sind in der nachfolgenden Tabelle, nach [UML05], noch einmal kurz aufgeführt und erläutert. Knoten

Beschreibung

Activity

Repräsentiert das gesamte Diagramm. Hierbei kann eine Aktivität wiederum beliebig viele Aktivitäten enthalten Ist eine ausführbare Aktivität und damit eine elementare Funktion mit ein- und ausgehenden Kanten Beendet jegliche Verarbeitung

Action ActitivityFinal Datastore DecisionNode FlowFinal ForkNode InitialNode JoinNode

Abbildung

Zentraler Speicherplatz für alle persistenten Informationen Auf Grund einer Entscheidung wird eine von mehreren ausgehenden Flusskanten weiter verfolgt. Beendet die Verarbeitung eines Flusses Initiiert die parallele Verarbeitung von beliebig vielen nebenläufigen Prozessen. An dieser Stelle beginnt der Kontrollfluss nachdem eine Aktivität aufgerufen wurde. Synchronisiert mehrere, parallel verarbeitete Flüsse

81

3 Business Process Execution Language (BPEL) und deren Alternativen

Knoten

Beschreibung

MergeNode

Führt mehrere, alternative Flüsse wieder zusammen

ObjectNode

Bildet den Datenfluss ab, wobei unterschiedliche Arten verwendbar sind Ein Kontrollfluss verläuft von einer Aktivität zu einer anderen, wobei keine Daten übergeben werden. Der Datenfluss gestattet die Übermittlung von Objekten (Daten) zwischen Aktivitäten, wobei wiederum verschiedene Notationsformen existieren

ControlFlow ObjectFlow

Tabelle 5:

Abbildung

Elemente eines UML 2.0 Aktivitätsdiagramms nach [UML05]

Abschließend bleibt festzustellen, dass UML prinzipiell zwar zur Abbildung von Integrationsprozessen einsetzbar wäre, auf Grund des Charakters der grafischen Notation, jedoch zwingend eine Transformation in eine XML-basierte Sprache wie beispielsweise BPEL oder XPDL notwendig macht. Somit ist die Verwendbarkeit von UML im Rahmen dieser Diplomarbeit abzulehnen.

3.5.2

Business Process Modelling Notation (BPMN)

Die Business Process Modelling Notation (BPMN) wurde von dem BPMI-Konsortium entwickelt und 2004 veröffentlicht. Diese erste Version wurde von der OMG 2006 in einer überarbeiteten Fassung herausgegeben. BPMN stellt dabei eine grafische Notation für Geschäftsprozesse bereit und kann folglich selbst nicht ausgeführt werden [BMIORG]. Das Ziele dieser Beschreibungsnotation war es, die semantische Lücke zwischen dem Geschäftsprozessentwurf und der Geschäftsprozessrealisierung zu schließen, indem eine Abbildung spezifiziert werden sollte, welche gleichermaßen von allen Beteiligten: vom Analysten bis hin zum technischen Entwickler, verstanden werden kann. Außerdem sollte somit eine standardisierte Darstellung von Geschäftsprozessen ermöglicht werden, welche gleichzeitig eine Abbildung auf XML-basierte Sprachen wie BPEL zulässt. Hierbei war eine

Konsolidierung

anderer

grafischer

Notationen,

wie

beispielsweise

UML

82

3 Business Process Execution Language (BPEL) und deren Alternativen

Aktivitätsdiagramme und ebXML BPSS das Ziel [BPMN06], [BPMORG]. An dieser Stelle wird auf eine umfassende Darstellung verzichtet und lediglich das Grundmodell in Form der nachfolgenden Tabelle, nach [BPMN06], dargestellt. Knoten

Beschreibung

Event

Ein Ereignis beeinflusst den Prozessablauf und hat in der Regel eine Ursache respektive ein Ergebnis. (zum Beispiel: Start, End) Ist eine abgrenzbare Funktion, wobei diese entweder elementar oder zusammengesetzt sein kann. (zum Beispiel: Process, Task) Damit können beliebige Kontrollflüsse modelliert werden. Gateways können dabei unterschiedliche Typen haben. Abbildung des Kontrollflusses, indem dieser Aktivitäten miteinander verbindet. Damit kann der Datenfluss zwischen zwei Rollen über die Grenzen des Pools hinweg dargestellt werden. Hiermit können Informationen von Objekten der Verarbeitungsabfolge referenziert werden Repräsentiert einen Beteiligten und ist gleichermaßen eine Schwimmbahn Partitionierungsmöglichkeit des Pools, um diesen besser zu verwalten. Datenobjekte können den Kontrollfluss und damit auch den Datenfluss nicht beeinflussen, sondern lediglich die Verarbeitung einer Aktivität beeinflussen. Hiermit kann der Kontrollfluss nicht beeinfluss werden und damit hat dies nur Bedeutung für Dokumentation und Analyse Zusätzliche Informationen für die Beschreibung des Geschäftsprozesses

Activity Gateway Sequence Flow Message Flow Assoziation Pool Lane DataObject

Group Text Annotation Tabelle 6:

Abbildung

Elemente eines BPMN 1.0-Diagrammes nach [BPMN06]

Ein wichtiger Punkt bei BPMN ist die Möglichkeit der Generierung von XML-basierten Prozessbeschreibungen. Auf Grund des Ansatzes einer sprachunabhängigen Darstellung, kann diese grafische Notation neben WSBPEL 2.0 ebenfalls für andere Sprachen wie beispielsweise XPDL 2.0 oder der älteren BPML 1.0 eingesetzt werden.

83

3 Business Process Execution Language (BPEL) und deren Alternativen

Zusammenfassend ist jedoch zu behaupten, dass BPMN im Kontext des BPM durchaus mit den UML 2.0 Aktivitätsdiagrammen vergleichbar ist und diesen auf Grund des Konsolidierungsaspektes vorgezogen werden sollte. Die Verwendbarkeit von BPMN im Kontext der Diplomarbeit ist analog zu UML 2.0 abzulehnen.

3.5.3

Web Service Choreography Description Language (WS-CDL)

Im Gegensatz zu UML und BPMN ist die Web Service Choreography Description Language (WS-CDL) eine XML-basierte Prozessbeschreibungssprache, wobei sie der Beschreibungsebene zuzuordnen ist. Somit ist sie nicht als ausführbare Sprache, sondern vielmehr als globale Beschreibung der Interaktion zwischen Partnern mit heterogenen Ausführungsumgebungen zu verstehen. Dieser Standard wurde seit 2002 im Rahmen des World Wide Web Consortiums (W3C) bearbeitet und dann Ende 2005 als “Candidate Recommendation” veröffentlicht [WSCDL05]. Das

Hauptziel

der

Spezifikation

implementationsunabhängige

ist

also

die

globale,

plattform-

und

Beschreibung

des

beobachtbaren

Verhaltens

von

Interaktionen zwischen den beteiligten Systemen. Dabei definiert WS-CDL ausschließlich Prozessmetadaten. Es liegt dann dezentral in der Verantwortung der Beteiligten ihre jeweiligen Teile der Choreografie mit einer direkt oder indirekt ausführbaren Sprache wie beispielsweise Java oder WSBPEL zu realisieren. Somit kann WS-CDL als Erweiterung der WSDL angesehen werden, da beide beobachtbares Verhalten, lediglich auf anderen Abstraktionsebenen, beschreiben. Das Zusammenspiel wird noch einmal durch die folgende Abbildung verdeutlicht.

84

3 Business Process Execution Language (BPEL) und deren Alternativen

Abbildung 34:

Ebenen der Choreografie bei WS-CDL

Die Sprachkomponenten der WS-CDL lassen sich im Grunde in drei Kategorien: die Deklaration von Beteiligten, die Informationsbeschreibungen und die Aktivitäten einteilen. Hierbei

unterscheidet

man

wiederum

zwischen

kontrollflussorientierten

und

interaktionsorientierten Aktivitäten. Die WS-CDL versucht eine so genannte „Information Driven Collaboration“ zu realisieren, weil davon ausgegangen wird, dass eines der wichtigsten Charakteristika des beobachtbaren Verhaltens von Geschäftsprozessen der Informationsaustausch ist. Zusammenfassend

ist

einzuschätzen,

dass

WS-CDL

eine

XML-basierte

Beschreibungssprache für Choreografien ist, welche allerdings nicht mit dem Ziel der direkten Ausführung entworfen wurde und damit einen mittleren Abstraktionsgrad aufweist. Prinzipiell wäre der Einsatz der WS-CDL auch im Rahmen dieser Diplomarbeit denkbar, wobei vor allem die starke Informationsorientierung dafür sprechen würde. Allerdings weist sie einen höheren Abstraktionsgrad als WSBPEL auf, welcher natürlich mit dem Verlust von Modellierungsmöglichkeiten verbunden ist, weshalb auch WS-CDL im Rahmen dieser Arbeit nicht zum Einsatz kommen wird.

3.5.4 Die

XML Process Definition Language (XPDL) XML

Process

Definition

Language

(XPDL)

ist

eine

XML-basierte

Prozessbeschreibungssprache, welche seit 1993 von der Workflow Management Coalition

85

3 Business Process Execution Language (BPEL) und deren Alternativen

(WfMC) bearbeitet und im Jahre 2005 als Version 2.0 veröffentlicht wurde. Dabei lässt sie sich der Kategorie Orchestrierung und damit der Realisierungsebene zuordnen. Das Hauptziel der Version 2.0 war es, eine technische Beschreibung der grafischen BPMNProzessabbildungen zu gewährleisten und somit als Generierungsziel dienen zu können [XPDL05]. Der Hauptunterschied zu WSBPEL liegt in der ausschließlichen Orientierung von XPDL auf die Geschäftsprozessbeschreibung, wobei der Interaktion von Personen innerhalb des Geschäftsprozesses eine größere Bedeutung zugestanden wird, als der Interaktion mit anderen

Systemen,

Datentransformationen.

Transaktionen, Dies

äußert

Fehlerbehandlungen, sich

in

der

Kompensationen

Abwesenheit

der

und

genannten

Verarbeitungsaspekte [BPMORG]. Mit der Analyse des nachfolgend dargestellten und unverändert aus [XPDL05] übernommenen Metamodells der XPDL-Prozessdefinition, wird die Korrelation mit der BPMN offensichtlich.

Abbildung 35:

Metamodell der XPDL-Prozessdefinition [XPDL05]

86

3 Business Process Execution Language (BPEL) und deren Alternativen

Diese Ähnlichkeit zur BPMN äußert sich dabei nicht nur in der Namensgebung, sondern auch in einigen Verarbeitungskonzepten und der expliziten Trennung von Kontroll- und Datenfluss. Der Kontrollfluss lässt sich im Wesentlichen mit den Prozessaktivitäten (Activity) und den Kanten (Transitions) modellieren. Somit weist XPDL ein graphorientiertes Prozessmodell auf. Eine Aktivität kann manuell oder automatisiert verarbeitet werden, was in dieser Art einzig in XPDL integriert wurde. In Bezug auf den Datenfluss weist die Sprache zwar spezielle Data Objects, Data Fields und den MessageFlow auf, lässt aber explizite Konstrukte wie beispielsweise das Assign in WSBPEL vermissen. Zusammenfassend lässt sich einschätzen, dass XPDL eine konkrete XML-basierte Prozessbeschreibungssprache ist, welche eher die Abbildung lokaler Geschäftsprozesse adressiert und damit aber auf den Gebieten der Anwendungs- und Informationsintegration Nachteile aufweist. Prinzipiell wäre der alternative Einsatz von XPDL im Rahmen der Diplomarbeit zur Beschreibung von Nachrichtentransformationen jedoch möglich.

3.5.5

ebXML Business Process Specification Schema (ebBP)

Der XML-basierte Standard eBusiness eXtensible Markup Language (ebXML) ist aus einer Zusammenarbeit der Organisationen OASIS und UN/CEFACT im Jahre 1999 entstanden. Dieser adressiert die unternehmensübergreifende Kollaboration, mit Hilfe von XML, auf Ebene der Geschäftsprozesse und ist somit ausschließlich dem B2B-Bereich zuzuordnen. Dieser Standard differenziert sich dabei in Teilstandards für die grundlegende Architektur, die

Spezifikation

Nachrichtendienst.

von Im

Geschäftsprozessen, Weiteren

soll

den

Verzeichnisdienst

ausschließlich

die

und

den

Spezifikation

von

Geschäftsprozessen mit Hilfe des ebXML Business Process Specification Schema (BPSS), welches auch schlicht als ebBP bezeichnet wird, im Mittelpunkt der Betrachtung stehen. Die erste Version dieses Teilstandards wurde im Jahr 2001 veröffentlicht, dann aber 2005 im Rahmen von ebBP 2.0.1 noch einmal überarbeitet. Die wohl wichtigste Eigenschaft von ebBP ist, dass sie im Gegensatz zu WSBPEL, neben der Orchestrierung, auch die Choreografie beschreibt. Somit werden die Geschäftsprozesse eines Unternehmens

87

3 Business Process Execution Language (BPEL) und deren Alternativen

dezentral, aus der Sicht eines Unternehmens, beschrieben und ausgeführt, weshalb ebBP der Realisierungsebene zu zuordnen ist. Die wesentlichsten Komponenten einer derartigen Beschreibung und die Schritte zur Konfiguration in einem unternehmensübergreifenden Prozess werden durch die folgende Abbildung dargestellt [EBBP05], [MAAG03].

Abbildung 36:

Sprachkomponenten von ebXML BPSS

Jedes Unternehmen definiert also dezentral mit Hilfe von ebBP die eigenen, öffentlich sichtbaren Geschäftsprozesse, wobei für jeden Prozess eine so genannte Business Process Specification definiert wird. Diese Prozessbeschreibung beinhaltet eine Menge von betriebswirtschaftlichen

Transaktionen,

welche

wiederum

eine

Menge

von

Geschäftsdokumenten verarbeiten. Die Gesamtheit der Prozessbeschreibungen repräsentiert letztendlich das Unternehmen in Form des Collaboration Protocol Profile (CPP). Auf Grund des dezentralen Charakters ist weiterhin eine Konfiguration notwendig. Hierbei einigen sich zwei Unternehmen im Rahmen eines Collaboration Protocol Agreements (CPA), welche Geschäftsprozesse sie voneinander nutzen wollen. Dies kann man als die Schnittmenge der beiden unternehmensspezifischen CPPs auffassen. Letztendlich erhält jeder der beiden Geschäftspartner diese Vereinbarung, um sein Informationssystem entsprechend dieser zu konfigurieren. Eine

Business

transaction

ist

als

elementare

Funktion

innerhalb

eines

betriebswirtschaftlichen Szenarios anzusehen. Dabei beinhaltet eine solche Transaktion eine request-Aktivität, mehrere Dokumentenflüsse und schließlich eine response-Aktivität. Außerdem kann die Transaktion so genannte Business signals versenden, welche als

88

3 Business Process Execution Language (BPEL) und deren Alternativen

Ereignisse und Bestätigungen aufzufassen sind. Die Spezifikation definiert schließlich sechs verschiedene Transaction Pattern, wie beispielsweise Request/Response oder Data Exchange. Zusammenfassend lässt sich feststellen, dass ebBP eine konkrete XML-basierte Prozessbeschreibungssprache ist, welche die Orchestrierung und Choreografie innerhalb eines ebXML-Szenarios abbildet und mit beliebigen grafischen Notationen, wie beispielsweise BPMN oder UML 2.0, dargestellt werden kann. Auf Grund der eher geringen Flexibilität in Bezug auf die Beschreibbarkeit und der ausschließlichen Ausrichtung auf den ebXML-Standard, erscheint die Einsetzbarkeit von ebBP im Rahmen der Diplomarbeit zwar prinzipiell als möglich, wird jedoch ebenfalls nicht weiter verfolgt.

89

4 Nachrichtentransformationsmodell

4

Nachrichtentransformationsmodell

Bislang wurden ausschließlich Grundlagen sowie die Prozessbeschreibungssprache WSBPEL mit all deren Facetten betrachtet. Nun soll der Blick auf die eigentliche Nachrichtentransformation gerichtet werden. Nachdem zunächst eine Begriffsklärung und inhaltliche Abgrenzung vorgenommen wird, sind Anforderungen für komplexe Nachrichtentransformationen in Form von funktionalen und nicht-funktionalen Anforderungen zu definieren. Den Schwerpunkt dieses Kapitels bildet die Definition eines konzeptuellen Nachrichtentransformationsmodells, welches die zuvor beschriebenen Anforderungen realisiert. Für dieses Modell wird der Begriff des Message Transformation Model (MTM) eingeführt. Abschließend sollen auch die theoretische Analyse und Optimierung von Prozessbeschreibungen, auf Grundlage des definierten Modells, in die Betrachtungen einbezogen werden.

4.1

Inhalt und Abgrenzung

Bevor

in

den

folgenden

Teilkapiteln

konzeptuelle

Modelle

für

die

Nachrichtentransformation definiert werden, ist zunächst eine Begriffsklärung entsprechend den Ebenen der Transformation vorzunehmen. Der Begriff der Transformation wird in der Informatik ganz allgemein auf die Umformung einer Struktur abgebildet. Eine Spezialform dieser ist die Datentransformation, welche Daten eines Quellformates in ein bestimmtes Zielformat transformiert [WIKIDE], [WIKIEN]. Dabei sind drei grundlegende Transformationsschritte zu unterscheiden: •

Mapping der Datenformate

•

Generierung von Transformationsvorschriften

•

Ausführung der Transformation

Bei dem Mapping ist festzulegen, welche Datenfelder des Quellformates auf welche Felder

90

4 Nachrichtentransformationsmodell

des Zielformates abzubilden sind. Hierbei können 1:N und N:1-Beziehungen sowie einfache Berechnungen erforderlich sein. Nachdem die Abbildung vorgenommen wurde, ermöglichen

die

hierfür

angebotenen

Werkzeuge

die

Generierung

Transformationsvorschriften. In der Regel werden dabei XSLT-, STX- oder

von

XQuery-

Skripte, beziehungsweise ausführbare Programme in Form von Java oder anderen Sprachen erzeugt. Diese Transformationsvorschriften können dann zur Ausführung gebracht werden um übergebene Dokumente oder Nachrichten zu transformieren. Die Nachrichtentransformation ist wiederum ein Spezialfall der Datentransformation. Diese betrifft die Datentransformation von Nachrichten, welche in der Regel einen ähnlichen Aufbau aufweisen und unter Umständen Bezug zu dem Quellsystem beziehungsweise zu den Zielsystemen enthalten können. Die Methoden der Datentransformation werden analog auch auf die Nachrichtentransformation angewandt. Diese sehr allgemeine Begriffsabgrenzung der Nachrichtentransformation kann an dieser Stelle nicht ausreichen. Um diese jedoch detaillierter zu unterscheiden, sind zunächst die Ebenen der Transformation nach [HOH04a] einzuführen. Nr.

Ebene

Inhaltsbezug

Erläuterung

3

Datenstrukturen

verlustfrei / verlustbehaftet / angereichert

2

Datentypen

verlustfrei / verlustbehaftet

1

Datenrepräsentation

verlustfrei

Semantische Abbildung der Transformation von komplexen Anwendungsobjekten, wobei auf dieser Ebene Beziehungen und Abhängigkeiten beachtet werden. Dabei wird nicht nur die Veränderung, sondern auch die Anreicherung, von Datenstrukturen adressiert. Syntaktische Abbildung der Datenfelder samt Datentypen einer Eingangsnachricht auf die Felder einer Ausgangsnachricht. Hierbei werden zum einen Datentypkonvertierungen, aber zum anderen auch Ersetzungen und Verkettungen (beispielsweise mit XSLT) beschrieben. Einfache Formatkonvertierungen, wobei der Inhalt vollständig wiederhergestellt werden kann. Beispiele hierfür sind die Überführung von CSV in XML, aber auch Kompression und Verschlüsselung.

91

4 Nachrichtentransformationsmodell

Nr.

Ebene

Inhaltsbezug

Erläuterung

0

Transport

verlustfrei

Transformation von Nachrichten zum Zwecke der Übertragung mittels bestimmter Transportprotokolle, wobei der Inhalt nicht verändert wird.

Tabelle 7:

Ebenen der Transformation nach [HOH04]

Auf Grundlage der vorangestellten Tabelle kann die, für diese Arbeit essentielle, Unterscheidung in elementare und komplexe Nachrichtentransformationen getroffen werden. So hat die elementare Nachrichtentransformation die Ebenen null bis zwei zum Gegenstand und beschreibt somit die Umformung einer Nachricht auf syntaktischer Ebene ohne, dass die Nachricht um zusätzliche Daten angereichert wird. Dies kann auch als Nachrichtentransformation in engeren Sinne verstanden werden. Darauf aufbauend betrifft die komplexe Nachrichtentransformation vor allem die Ebene drei, wobei jedoch die elementare Nachrichtentransformation ebenfalls eingeschlossen ist. Diese kann auch als Nachrichtentransformation im weiteren Sinne gesehen werden und stellt die semantische Transformation von Nachrichten beziehungsweise von Nachrichtenfolgen, unter Beachtung von Abhängigkeiten, dar. Auf Grund der Komplexität solcher Transformationen können diese nur als Folge von kontrollfluss- und datenflussorientierten Teilschritten dargestellt werden. Letztendlich kann der Begriff der komplexen Nachrichtentransformation als Synonym für die komplette Nachrichtenverarbeitung innerhalb einer Message-OrientedMiddleware (MOM) [DESS04] benutzt werden. In dem nachfolgenden Teilkapitel werden Anforderungen und Problemstellungen innerhalb von Nachrichtentransformationsszenarien vorgestellt, welche die Beschreibung der so eben eingeführten komplexen Nachrichtentransformation erfordern.

4.2

Anforderungen an ein Transformationsmodell

Innerhalb dieses Teilkapitels werden Transformationsszenarien mit deren spezifischen Problemstellungen vorgestellt. Diese sind somit gleichzeitig auch als Anforderungen an ein allgemeines Transformationsmodell für komplexe Nachrichtentransformationen anzusehen.

92

4 Nachrichtentransformationsmodell

Hierbei sind zu jeder Anforderung mögliche Ansätze und Varianten zu diskutieren. Im Wesentlichen

werden

die

Anforderungen

in

funktionale

und

nicht-funktionale

Anforderungen unterschieden. Die folgenden Ausführungen erheben dabei keinen Anspruch auf die vollständige Diskussion der einzelnen Szenarien, sondern sollen lediglich das Verständnis für die Anforderungen an ein konzeptuelles Modell für komplexe Nachrichtentransformationen verbessern. 4.2.1

Funktionale Anforderungen

Die funktionalen Anforderungen beschreiben explizite Grundfunktionalitäten der Nachrichtentransformation, welche mit Hilfe des MTM abbildbar sein sollen. Somit sind inhaltliche Aspekte der komplexen Nachrichtentransformation Gegenstand dieses Abschnitts. Im Weiteren werden, die nachfolgend genannten, Anforderungen genauer betrachtet. •

Beliebig viele Quell- und Zielsysteme

•

Synchrones und Asynchrones Verarbeitungsmodell

•

Content Based Routing

•

Umgang mit unterschiedlichen Datenrepräsentationen

•

Umgang mit unterschiedlichen Datenmengen

•

Transformation der Semantik von Nachrichten

•

unterschiedliche Methoden der elementaren XML-Nachrichtentransformation

•

Validierung von Nachrichten

Beliebig viele Quell- und Zielsysteme Prinzipiell ist die Anforderung gegeben, dass ein Transformationsprozess mit N Quellsystemen und M Zielsystemen interagieren kann. Dies ist beispielsweise für das Nachladen von Daten erforderlich. Hierfür sind die Systeme derart zu abstrahieren, dass die Interaktion unabhängig vom Typ des Systems erfolgen kann. Die folgende Abbildung zeigt die Notwendigkeit der Integration von Interaktionskomponenten.

93

4 Nachrichtentransformationsmodell

Abbildung 37:

Beliebig viele Quell- und Zielsysteme

Dabei sind prinzipiell fünf Interaktionen zu unterscheiden: •

initiirendes Receive (R1)

•

nicht-initiierendes Receive (R2)

•

Request-Response Invoke (I1)

•

Request Invoke (I2)

•

Reply (RE)

Grundlegend ist festzustellen, dass ein Prozess nur genau ein initiierendes Receive (R1) enthalten kann, welches implizit auch der Start der Prozessinstanz ist. Allerdings können weitere Nachrichten mit mehreren nicht-initiierenden Receive (R2) empfangen werden. Das Request-Response Invoke (I1) stellt die dritte Möglichkeit dar, ein Quellsystem zu nutzen, wobei sowohl Nachrichten gesendet als auch empfangen werden. Weiterhin bietet das Request Invoke (I2) die Möglichkeit auch ausschließlich Nachrichten an ein Zielsystem zu senden. Hierbei bleibt zu erwähnen, dass ein System, wie beispielsweise S3 der obigen Abbildung, sowohl Quell- als auch Zielsystem sein kann. Letztendlich bietet das Reply (RE) die Möglichkeit eine Antwort an das System zu senden, von dem die Eingabenachricht mit Hilfe des initiierenden Receive empfangen wurde. Somit ist festzustellen, dass die Integration von Interaktionsmustern in das konzeptuelle Modell erforderlich ist.

94

4 Nachrichtentransformationsmodell

Synchrones und Asynchrones Verarbeitungsmodell Nachdem bei dem zuvorgehenden Aspekt bereits die Interaktionsmuster beschrieben wurden, besteht weiterhin die Notwendigkeit der Abbildbarkeit, sowohl des synchronen als auch des asynchronen Verarbeitungsmodells. Um diese beiden Modellen grundlegend zu unterscheiden, stellt die folgende Abbildung diese zunächst nebeneinander.

Abbildung 38:

Verarbeitungsmodelle

Ein Transformationsprozess im synchronen Verarbeitungsmodell wird dabei blockierend aufgerufen und liefert nach dessen Beendigung optional ein Ergebnisdokument per Reply an die aufrufende Stelle zurück. Im Gegensatz dazu wird ein Transformationsprozess im asynchronen Verarbeitungsmodell nicht blockierend ausgeführt, was impliziert, dass die aufrufende Stelle nicht auf die Beendigung des Prozesses wartet. Zwar könnte auch im asynchronen Modell eine Ergebnisnachricht, mittels Invoke, an die aufrufende Stelle übermittelt werden, jedoch, wäre diese dann nicht direkt mit dem ursprünglichen Aufruf korreliert. Betrachtet man diese Anforderung nun im Hinblick eines generischen Nachrichtentransformationsmodells, so wäre prinzipiell die Modellierung der Rückgabe von Ergebnisnachrichten allein mit einem Invoke-Muster möglich, jedoch würde dies eine explizite Unterscheidung der Verarbeitungsmodelle nicht zulassen, so dass sich an dieser Stelle das Reply-Muster anbietet. Content Based Routing Eine

essentielle

Anforderung

bei

der

Beschreibung

von

komplexen

Nachrichtentransformationen, ist die Ermöglichung des so genannten Content Based

95

4 Nachrichtentransformationsmodell

Routing. Grundlegend ist zunächst festzustellen, dass einer Datenflussanalyse zwingend eine Kontrollflussanalyse vorausgehen muss, da der Datenfluss in rein funktional getriebenen Anwendungen eine untergeordnete Rolle spielt. Somit definiert der Kontrollfluss den Datenfluss. Beim Content Based Routing beeinflusst der Datenfluss jedoch auch aktiv den Kontrollfluss, indem die Auswahl alternativer Pfade innerhalb eines Transformationsprozesses, auf Grund der verarbeiteten Daten getroffen wird. Die nachfolgende Abbildung verdeutlicht dies noch einmal.

Abbildung 39:

Content Based Routing

Bei der Verarbeitung von XML-Nachrichten bieten sich, in Bezug auf das Content Based Routing eines Prozesses, Optimierungen an. So stellt sich das Problem, dass für die Routing-Operation Einzelwerte des XML-Dokumentes kostenintensiv, beispielsweise mit XPath, ermittelt werden müssen. Sofern auf einen unveränderten Wert also mehrfach lesend zugegriffen wird, kann eine zuvorgehende Extraktion des Einzelwertes und dessen materialisierte und damit redundante Zwischenspeicherung eine Reduzierung der aufgewendeten Kosten bedeuten. Umgang mit unterschiedlichen Datenrepräsentationen Die Forderung nach der Verarbeitbarkeit von unterschiedlichen Datenrepräsentationen ist nicht nur auf dem Gebiet der Nachrichtentransformationen präsent. Grundlegend ist festzustellen, dass beliebige Datenrepräsentationen, wie beispielsweise relationale Daten, XML oder andere Datenformate, in dem Transformationsprozess verarbeitet werden. Dementsprechend müssen sowohl unstrukturierte, semistrukturierte als auch strukturierte Daten verarbeitbar sein. Aus diesem Grund stellt sich die Frage nach einem internen

96

4 Nachrichtentransformationsmodell

Datenmodell zur generischen Abbildung aller Datenrepräsentationen. Hierbei sind grundlegend zwei Ansätze zu unterscheiden. Zum einen besteht die Möglichkeit alle eingehenden Nachrichten in eine spezifische Repräsentation zu überführen. Dies ist der am häufigsten genutzte Ansatz, wobei in der Regel XML, als strukturtragende und damit semistrukturierte Repräsentation, verwendet wird. Zum anderen könnte man ein Datenmodell definieren, welches gleichermaßen die Abbildung alle Repräsentationen zulässt. Dieser zweite Ansatz hätte vor allem den Vorteil intern den Overhead von XML, in Bezug auf Speicherplatz und Verarbeitungseffizienz [IBM04b], zu reduzieren. Umgang mit unterschiedlichen Datenmengen Bei der Nachrichtentransformation ist die Granularität der Nachrichten zu berücksichtigen. Dabei besteht eine Nachricht stets aus einem Kopfbereich und einem Datenbereich. Mit einer abstrakten Sichtweise auf den Datenbereich lassen sich hierbei prinzipiell vier verschiedene Ansätze voneinander differenzieren. Diese sind nachfolgend grafisch nebeneinander gestellt und anschließend beschrieben.

Abbildung 40:

•

Ansätze der Nachrichtengranularität

Einzelattribut Bei diesem grobgranularsten Ansatz weist eine Nachricht, einen Datensatz mit genau einem Attribut auf. Somit wird der eigentliche Inhalt als BLOB verwaltet. Dieser Ansatz ist ein Spezialfall der Attributmenge.

•

Attributmenge Bei der Attributmenge wird eine Nachricht mit einem Datensatz und N Attributen verwaltet. Somit kann ein Geschäftsobjekt abgebildet werden. Dies ist ein

97

4 Nachrichtentransformationsmodell

Spezialfall der Tupelmenge. •

Tupelmenge Die Tupelmenge ist eine Nachricht mit M Datensätzen und N Attributen. Somit kann eine logische Tabelle und damit eine Menge von Geschäftsobjekten verwaltet werden. Dies ist wiederum der Spezialfall der Nachrichtenmenge.

•

Nachrichtenmenge Die Nachrichtenmenge stellt die generellste Form dar. Hierbei werden K Nachrichten mit jeweils Mk Datensätzen und Nk Attributen verwaltet.

Auf Grund der höchsten Generalität des Ansatzes der Nachrichtenmenge, scheint dieser Ansatz als die geeignete Wahl. Allerdings ist natürlich zu diskutieren, woraus die Notwendigkeit der Verwaltung von Nachrichtenmengen entsteht. Prinzipiell lässt sich die Anforderung der Verarbeitung von Nachrichtenmengen mit drei Argumenten begründen. Zum ersten besteht die Notwendigkeit der Zusammenführung von Nachrichten, beispielsweise bei der Synchronisation von Parallelverarbeitung oder beim Nachladen von Daten. Somit muss zwangsläufig vor der Zusammenführung mit einer Nachrichtenmenge gearbeitet werden. Das zweite Argument betrifft die Performance. Wenn man Extremfälle bedenkt, in denen entweder sehr viele kleine oder wenige sehr große Nachrichten verarbeitet werden, ist es naheliegend, dass dies nicht optimal ist. Hier kann eine Zusammenführung vieler kleiner Nachrichten zu einer Größeren, respektive die Trennung einer großen Nachricht in Kleinere, Kosten sparen. Dieser Aspekt wird im Teilkapitel 4.4 noch einmal detaillierter aufgegriffen. Zum dritten können heterogene Systeme Schnittstellen aufweisen, welche mit einer unterschiedlichen Granularität arbeiten. So ist beispielsweise vorstellbar, dass ein Quellsystem S1 eine Nachricht versendet, welche eine vollständige Bestellung repräsentiert. Das Zielsystem S2 hat jedoch eine Schnittstelle, welche die einzelnen Bestellpositionen als Nachrichten entgegen nimmt. Somit wäre auch hier eine Trennung und anschließende Verarbeitung von Nachrichtenmengen erforderlich. Transformation der Semantik von Nachrichten Neben der Anforderung des Umgangs mit unterschiedlichen Datenrepräsentationen, besteht

98

4 Nachrichtentransformationsmodell

die Forderung nach der Möglichkeit der Transformation der Semantik von Nachrichten. Derartige Transformationen adressieren das Hinzufügen, Ändern und Entfernen von Knoten innerhalb einer Nachricht. Das Hinzufügen von Knoten erfordert implizit die Zusammenführung von mindestens zwei Nachrichten. Hierbei sind in Anlehnung an das relationale Modell prinzipiell zwei Arten zu unterscheiden. Zum einen sind Mengenoperationen, also Vereinigung, Durchschnitt und Differenz, und damit die Zusammenführung von Knoten gleichen Typs zu einer Knotenmenge relevant. Zum anderen darf jedoch auch der Verbund von Knoten unterschiedlichen Typs, entsprechend eines Verbundknotens, in Form des Joins nicht außer Acht gelassen werden. Bevor diese Problematik nachfolgend in Form einer Abbildung noch einmal veranschaulicht wird, sei an dieser Stelle auf [LIND04] und [LANG05] verwiesen, wobei in letzterem die Bewertung der Qualität von zusammengeführten XML-Daten diskutiert wird.

Abbildung 41:

Hinzufügen von Knoten

Neben dem Hinzufügen von Knoten besteht die Anforderung des Entfernens von Knoten. Dies geschieht durch Auswahl der zu übernehmenden Knoten, ähnlich eines Filters. Auch dabei sind wiederum zwei Varianten in Anlehnung an das relationale Modell zu unterscheiden. So sind im Rahmen der Projektion Knotentypen auszuwählen, wodurch nicht spezifizierte Knotentypen aus dem Baum entfernt werden. Bei der Selektion werden Knoten aus einer Knotenmenge entsprechend eines Prädikates ausgewählt und die dazu disjunkte Knotenmenge entfernt. Diese beiden Varianten zeigt die folgende Abbildung.

99

4 Nachrichtentransformationsmodell

Abbildung 42:

Entfernen von Knoten

Nachdem nunmehr die Anforderungen der Veränderung der semantischen Struktur aufgezeigt wurden, ist an dieser Stelle bereits ein Blick auf die Realisierbarkeit mit aktuellen Technologien zu richten. Für die Transformation von XML-Nachrichten ist festzustellen, dass das Entfernen von Knoten, beispielsweise mit XSLT und XQuery unproblematisch ist. Im Gegensatz dazu offenbaren sich Defizite bei der Zusammenführung von XML-Dokumenten mit XSLT. Diesem Defizit kann jedoch mit der Verwendung von XQuery entgegengetreten werden. Zusammenfassend bleibt also einzuschätzen, dass kein allgemeines Modell für die Transformation der Semantik von XML-Nachrichten, respektive beliebiger Nachrichten existiert. Unterschiedliche Methoden der elementaren XML-Nachrichtentransformation Da es durchaus vorstellbar ist, dass sich eine komplexe Nachrichtentransformation ausschließlich aus einer Menge von elementaren Transformationsschritten zusammensetzt oder solche zumindest enthält, besteht die Anforderung der Ausführbarkeit derartiger Transformationsvorschriften. Analysiert man hierzu die Technologien auf dem Gebiet der XML-Transformation, so erscheint es sinnvoll die folgenden Transformationssprachen zu unterstützen. •

Extensible Stylesheet Language Transformation (XSLT)

•

Streaming Transformation for XML (STX)

•

XQuery

•

XStreamQuery

100

4 Nachrichtentransformationsmodell

•

Functional XML Transformation (FXT)

Während XSLT sich bereits weitestgehend durchgesetzt hat und somit undiskutabel ist, sollen auch die aufgezählten Alternativen eingesetzt werden. So beseitigt STX, welche aus der Dissertation [BECK04] hervorgegangen ist, die Verarbeitungsnachteile von XSLT. Auch XQuery kann für die Nachrichtentransformation eingesetzt werden. Dies ist sinnvoll, da diese ausdrucksstärker als XPath in XSLT ist. XStreamQuery beseitigt wiederum die Verarbeitungsnachteile von XQuery. Mit FXT, welche aus der Dissertation [BERL05] hervorgegangen ist, soll weiterhin eine relativ unbekannte Transformationssprache unterstützt werden, welche ihre Vorteile vor allem in der Ausdruckskraft und der effizienten Verarbeitung sieht. An dieser Stelle sei noch auf den sehr interessanten Ansatz [IBM06b] verwiesen. Dieser bietet eine SQL-Erweiterung die Extended Structured Query Language (ESQL), innerhalb des Produktes WebSphere Message Broker, an. Hierbei kann mit einer sehr stark an SQL angelehnten Syntax, eine eingehende Nachricht in eine ausgehende Nachricht transformiert werden. Die Ausführung einer solchen ESQL-Anweisung kann somit ebenfalls als elementarer Transformationsschritt angesehen werden, welcher ebenso wie beispielsweise eine XSL-Transformation in eine komplexe Nachrichtentransformation eingebettet werden könnte. Neben der Ermöglichung von elementaren Nachrichtentransformationen in Form der Ausführung von standardisierten oder proprietären Sprachkonstrukten, sollte eine Erweiterungsmöglichkeit für die flexible Transformation angeboten werden. Dafür bietet es sich an, die Ausführung von Operationen in einer prozeduralen Programmiersprache zuzulassen, womit Spezialprobleme lösbar sind. Validierung von Nachrichten Im Rahmen der komplexen Nachrichtentransformation kommt auch der Validierung von Nachrichten respektive der Daten einer Nachricht eine hohe Bedeutung zu. Hierbei ist die Interaktion mit externen Systemen, beispielsweise in Form von eingehenden Nachrichten oder dem Nachladen von Daten, als Hauptfehlerquelle zu identifizieren.

101

4 Nachrichtentransformationsmodell

Die Anforderung einer Ermöglichung der Validierungen von Nachrichten kann prinzipiell mit zwei Ansätzen realisiert werden. Diese sind zunächst durch eine Abbildung dargestellt und anschließend detaillierter beschrieben.

Abbildung 43:

Alternativen der Validierung von Nachrichten

Unter der expliziten Validierung ist ein spezieller Prozessschritt zu verstehen, welche explizit zu modellieren ist und eine Bedingung in Bezug auf eine Input-Nachricht prüft. Ist die Bedingung wahr wird die Nachricht schlicht weitergeleitet. Andernfalls muss ein Fehler signalisiert werden. Als Alternative dazu ist jedoch auch eine implizite Validierung vorstellbar, wobei für eine Nachricht Constraints definiert werden. Diese Bedingungen sind sowohl beim Erzeugen der Nachricht als auch bei jeglicher Transformation der Nachricht zu prüfen. Sofern eine Bedingung nicht erfüllt ist, muss auch hier ein Fehler signalisiert werden. Vergleicht man diese beiden Varianten miteinander, so ist festzustellen, dass die Variante b) eine strenge Konsistenz der Nachrichten unterstützt und somit nie inkonsistente Zustände auftreten können. Im Gegensatz dazu kann dies bei der Variante a) nicht garantiert werden. Allerdings stellt die Variante a) eine effizientere und zugleich flexiblere Alternative dar. So sind hierbei nicht bei jeder Änderungen kostenverursachende Bedingungsüberprüfungen durchzuführen. Außerdem können, unabhängig von dem Nachrichtentyp, unterschiedliche Bedingungen definiert werden. Zusammenfassend bleibt also festzustellen, dass die Auswahl einer Alternative der Validierung von Nachrichten entsprechend den Prioritäten eines konkreten Einsatzzweckes zu treffen ist. Dabei sind Effizienz und Flexibilität gegen die Konsistenzsicherung abzuwägen. Außerdem sollte die Validierungsfunktionalität über die bloße Überprüfung der

102

4 Nachrichtentransformationsmodell

Wohlgeformtheit und der Korrektheit hinsichtlich definierter Schemata hinausgehen und den Vergleich der Daten mit Bedingungen ermöglichen.

4.2.2

Nicht-Funktionale Anforderungen

Im Gegensatz zu den funktionalen Anforderungen beschreiben die nicht-funktionalen Anforderungen

keine

expliziten

Funktionalitäten,

sondern

die

impliziten

Rahmenbedingungen der Nachrichtentransformation. Somit sind Aspekte der Art und Charakteristik von Nachrichtentransformationen der Gegenstand dieses Abschnittes. Auch diese Anforderungen sollen zunächst genannt und anschließend genauer erläutert werden. •

Flexibilität

•

Zuverlässige Verarbeitung

•

Effiziente Verarbeitung

Flexibilität Unabhängig von der jeweiligen Datenrepräsentation gibt es Szenarien, welche den Aufbau eines zentralen nutzerdefinierten Datenmodells erfordern. Dies ist vor allem dann der Fall, wenn eine Vielzahl von Systemen flexibel auf Schemaebene miteinander integriert werden soll. Hierfür bietet sich die Definition eines Kanonischen Datenmodells [HOH04a], [SOCO06] an. Dabei wird für die anwendungsübergreifende Domäne ein globales Datenmodell definiert. Anstatt dann Transformationen direkt zwischen zwei Systemen zu definieren, werden für ein zusätzliches System S1 lediglich zwei Transformationen erstellt. Eine Transformation von dem Schema-S1 zu dem kanonischen Datenmodell und eine Transformation von dem kanonischen Datenmodell zu dem Schema-S1. Dieser Ansatz hat vor allem den Vorteil der Flexibilität und des geringen Änderungsaufwandes. Allerdings hat er auch zwei wesentliche Nachteile. So leidet natürlich die Performance, da anstatt einer Transformation der Nachricht stets zwei auszuführen sind. Der zweite Nachteil ist die Schwierigkeit der Definition eines solchen globalen Datenmodells, da die übergreifende

103

4 Nachrichtentransformationsmodell

Domänenkenntnis bei zunehmend dezentral verwalteten Datenbeständen oft nicht gegeben ist. Die folgende Abbildung vergleicht anschaulich die Transformation über ein kanonisches Datenmodell mit der direkten Transformation.

Abbildung 44:

Kanonisches Datenmodell

Für die Realisierung eines solchen Kanonischen Datenmodells lassen sich zwei Ansätze unterscheiden. So können die Transformationsvorschriften auf der einen Seite zur Entwicklungszeit, beispielsweise mit einem Werkzeug, erstellt und zur Laufzeit nur noch ausgeführt werden. Auf der anderen Seite wäre es vorstellbar, neben dem Kanonischen Datenmodell in Form des globalen Schemas, Mapping-Informationen in Bezug auf die einzelnen System-Schemata, im Rahmen eines Metadata Repositories vorzuhalten. Somit könnte man dann die Transformationsvorschriften zur Laufzeit generieren. Hierbei müsste zwar abermals eine Beeinträchtigung der Performance hingenommen werden, jedoch könnte somit flexibler auf die fortwährenden Schemaänderungen reagiert werden. Das kanonische Datenmodell ist besonders für Szenarien geeignet, in denen der Flexibilität, in Form des Hinzufügens von Systemen und sich ständig ändernden Schemata, eine höhere Bedeutung als der Performance zugesprochen wird. Zuverlässige Verarbeitung Im Rahmen von komplexen Nachrichtentransformationen muss die zuverlässige Verarbeitung in Form der Transaktionssicherheit gewährleistet werden. Im Gegensatz zum Transaktionskonzept von RDBMS sind jedoch zusätzliche Problemstellungen in die Betrachtung mit aufzunehmen. Diese Probleme resultieren aus der Interaktion mit

104

4 Nachrichtentransformationsmodell

verschiedenen Systemarten, welche nicht notwendiger Weise eine transaktionale Verarbeitung unterstützen. Im Weiteren soll unter einer Transaktion eine abgegrenzte Folge von Transformationsschritten verstanden werden. Die avisierte Transaktionssicherheit soll im Wesentlichen die folgenden drei Ziele realisieren. •

Verhinderung von Nachrichtenverlust

•

Vermeidung von Doppelverarbeitung

•

Rücksetzbarkeit von Interaktionen mit Systemen (Request Invoke)

Um diese Ziele zu realisieren, besteht die Anforderung das ACID-Prinzip [GRAY81], [GRAY93] analog umzusetzen. Die folgende Tabelle benennt zunächst die einzelnen Eigenschaften

und

interpretiert

diese

im

Kontext

der

komplexen

Nachrichtentransformation. ACID-Eigenschaft

Beschreibung im Kontext der Nachrichtentransformation

Atomicity

Dies meint die Ununterbrechbarkeit im Sinne des „Alles oder Nichts“-Prinzips. Somit ist die Rücksetzbarkeit von Transformationen als auch von Interaktionen zu beachten. Im Rahmen der Konsistenzerhaltung wird angenommen das eine Transaktion die verarbeitete Nachrichtenmenge und die externen Systeme von einem konsistenten Ausgangszustand in einen ebenfalls konsistenten Zustand überführt. Die Isolation von Transaktionen adressiert die Forderung, dass inkonsistente Zwischenzustände anderen Transaktionen nicht zugänglich gemacht werden dürfen. Die Dauerhaftigkeit meint, dass die Ergebnisse von Transaktionen in Form von transformierten Nachrichten nicht verloren gehen dürfen und wieder herstellbar sein müssen.

Consistency

Isolation Durability Tabelle 8:

ACID-Eigenschaften im Kontext der Nachrichtentransformation

Im Weiteren sind bereits Möglichkeiten hinsichtlich der Realisierung der soeben beschriebenen Eigenschaften zu diskutieren. Hierbei ist zunächst festzulegen, dass ein Transformationsprozess selbst als eine Transaktion angesehen wird. Außerdem können innerhalb dieser Transaktion stratifizierte Transaktionen verwendet werden.

105

4 Nachrichtentransformationsmodell

Die Ununterbrechbarkeit ist nun dadurch realisierbar, dass beim Beginn einer Transaktion ein UNDO-Image der Input-Nachricht gesichert wird. Somit ist die Rücksetzbarkeit der eigentlichen Nachrichtentransformation gewährleistet. Um jedoch Interaktionen auf externen Systemen zurückzusetzen, müssen zwei Fälle unterschieden werden. Sofern, dass jeweilige System die transaktionale Verarbeitung unterstützt, ist lediglich ein ROLLBACK zu initiieren. Im anderen Falle muss eine Kompensation spezifiziert und ausgeführt werden. Die Konsistenzerhaltung wird durch die implizite Ausführung von Validierungen vor dem Ende der Transaktion realisiert. Sofern diese nicht erfolgreich waren, ist die Rücksetzung der Transaktion zu initiieren. Die Isolation kann durch die Nutzung von separaten DataDictionaries realisiert werden. So wird die Sichtbarkeit von Variablen auf den Kontext der aktuellen Transaktion begrenzt. Die Dauerhaftigkeit wird in Analogie zur Ununterbrechbarkeit mit Hilfe von REDO-Images gewährleistet. Somit können die Ergebnisse erfolgreich ausgeführter Transaktionen stets wieder hergestellt werden. In Bezug auf die Verwaltung der UNDO- und REDO-Images sind prinzipiell zwei Varianten vorstellbar. So können diese entweder physisch in Form der Ergebnisnachrichten oder logisch in Form von Transformationsschritten gesichert werden. Letztendlich bietet sich die Unterstützung einer hybriden Variante an, da die logische Variante bedeutende Performance-Vorteile im produktiven Betrieb und lediglich Nachteile beim Recovery aufweist. Im Gegensatz dazu kann bei der physischen Variante das gleiche Ergebnis garantiert werden, während dies unter Einbeziehung von externen Systemen bei der logischen Variante nicht der Fall ist. Die Realisierungsaspekte sind in der nachfolgenden Abbildung noch einmal überblicksartig dargestellt.

106

4 Nachrichtentransformationsmodell

Abbildung 45:

Transaktionssicherheit

Letztendlich sind zwei Fehlerszenarien denkbar, welche durch geeignete Recovery Maßnahmen kompensiert werden müssen. Auf der einen Seite kann es entweder explizit nach einer Validierung oder implizit in Folge der Interaktion mit einem externen System zu einem lokalen Fehler kommen. Hierbei muss ein Partial-UNDO (R1) sowie gegebenenfalls ein Global-UNDO (R3) erfolgen. Auf der anderen Seite kann das verarbeitende System selbst ausfallen. Hierbei wäre der Systemzustand in Form eines Global-REDO (R4) wieder herzustellen. Die Transaktionssicherheit kann schließlich durch die beschriebenen Maßnahmen weitestgehend gewährleistet werden. Allerdings ist an dieser Stelle zu erwähnen, dass eine strenge Konsistenz nicht

erreicht wird. Hierfür wären Freigabeprotokolle wie

beispielsweise das Two-Phase-Commit (2PC) erforderlich, welche jedoch auf Grund der heterogenen Systemarten nicht oder nur unverhältnismäßig realisierbar sind. Effiziente Verarbeitung Im Rahmen der komplexen Nachrichtentransformation ist eine hohe Performance als eine der entscheidensten Anforderungen zu verstehen. Um diese zu erreichen sind natürlich Konzepte zur effizienten Verarbeitung von Nachrichten einzubeziehen. An dieser Stelle sollen ausgewählte Beispiele näher betrachtet werden.

107

4 Nachrichtentransformationsmodell

•

Reduzierung des Änderungsaufwandes Das erste Konzept betrifft die Reduzierung des Änderungsaufwandes. Wird eine Nachricht mehrmals transformiert, wobei jeweils nur bestimmte Teilknoten betroffen sind, würde eine inkrementelle Änderung, ausschließlich transformierter Knoten, im lokalen Datenbestand eine immense Kostenersparnis bedeuten. Das Grundkonzept ist die Annotation der einzelnen Knoten und Blätter, sofern diese verändert wurden. Die folgende Abbildung stellt das Prinzip der Annotation dar.

Abbildung 46: Reduzierung des Änderungsaufwandes

Geht man weiter davon aus, dass ein aktueller, also „sauberer“ Baum vorliegt, so kann bei jeder Änderung der betroffene Knoten und all seine Kindelemente als „unsauber“ annotiert werden. Dies ist dann rekursiv an das Elternelement weiter zu geben. Nachdem beliebige Änderungen vorgenommen wurden, kann an Hand der Annotationen ermittelt werden, welche Teile wirklich verändert wurden, so dass nur diese in einem Delta-Update in den Datenbestand einzubringen sind. Ein weiteres Anwendungsgebiet

wäre

beispielsweise

die

Gewährleistung

der

Transaktionssicherheit, wobei eine Menge von Versionen einer Nachricht zu verwalten sind. Mit diesem Konzept könnte beispielsweise ein inkrementelles, physisches Logging realisiert werden. •

Trennung von Datenfluss und Kontrollfluss In Anlehnung an die Dissertation [LIUD03], ist weiterhin eine Optimierung des Datenflusses dahingehend vorstellbar, dass große Datenmengen nicht zentral über den eigentlichen Transformationsprozess, sondern dezentral übermittelt werden.

108

4 Nachrichtentransformationsmodell

Das Hauptaugenmerk hierbei liegt auf der Trennung von Kontroll- und Datenflüssen. Auf Grund der Komplexität dieses Ansatzes, dessen Erläuterung schlicht zu weit führen würde, soll an dieser Stelle die Referenz der entsprechenden Arbeiten in Form von [LILW02], [LILW03], [LSLW03] und [LIUD03] genügen. •

Verarbeitung von Nachrichtenmengen Da

im

Kontext

der

komplexen

Nachrichtentransformation

der

Durchsatzoptimierung eine höhere Bedeutung zukommt als der Optimierung der Verarbeitungszeiten

von

Einzelnachrichten,

Nachrichtenmengen

ebenfalls

einen

stellt

relevanten

die

Ansatz

Verarbeitung mit

sehr

von

hohem

Optimierungspotenzial dar. An dieser Stelle sei bereits auf den Abschnitt 4.4.3 verwiesen in dem ein detaillierter Optimierungsvorschlag für diesen Ansatz unterbreitet wird. •

Constraint-basiertes Caching Auch das Nachladen von Daten und das anschließende Zusammenführen von mindestens zwei Nachrichten stellt eine wesentliche Anforderung dar. Hat man es an dieser Stelle jedoch mit sehr vielen kleinen Nachrichten und dem Nachladen von Stammdaten zu tun, kann dies sehr kostenintensiv sein. So werden häufig gleiche Anfragen ausgeführt, welche auf Grund der geringen Änderungshäufigkeit in der Regel die gleichen Ergebnisse liefern. An dieser Stelle bietet sich der Aufbau eines constraint-basierten Caches an. Ein solcher wird auch im Rahmen der Prototypischen Realisierung verwendet, so dass an dieser Stelle lediglich auf das Kapitel 6 verwiesen werden soll.

•

Art des Datenflusses innerhalb des Workflows Ein weiterer Aspekt mit hohem Optimierungspotenzial ist die Art des Datenflusses innerhalb des Workflows. Dabei ist die Weiterleitung der Nachrichten und die Bereitstellung der Daten einer Nachricht Gegenstand der Betrachtung. In Bezug auf diesen Ansatz ist ebenfalls auf das Kapitel 6 zu verweisen.

109

4 Nachrichtentransformationsmodell

4.3

Definition des Message Transformation Model (MTM)

Nachdem im zuvorgehenden Teilkapitel bereits die Anforderungen und teilweise alternative Ansätze in Bezug auf die komplexe Nachrichtentransformation dargestellt wurden,

soll

in

diesem

Teilkapitel

ein

konzeptuelles

Modell

für

komplexe

Nachrichtentransformationen, das Message Transformation Model (MTM), definiert werden, welches die Anforderungen und Problemstellungen aufgreift und behandelt. 4.3.1

Einordnung des Modells

Die Notwendigkeit eines allgemeines Modells zur Beschreibung von komplexen Nachrichtentransformationen wird im Wesentlichen durch die Heterogenität der Datenrepräsentationen von Nachrichten sowie den unterschiedlichen Prozessmodellen alternativer Prozessbeschreibungssprachen begründet. Das konzeptuelle Transformationsmodell gliedert sich folglich in ein konzeptuelles Nachrichtenmodell und ein konzeptuelles Prozessmodell. Mit dem Nachrichtenmodell sollen beliebige Nachrichten und Datenformate abbildbar sein. Somit werden mit diesem Teilmodell die statischen Aspekte der Nachrichtentransformation in Form von Nachrichten beschrieben. Das Ziel des Nachrichtenmodells ist ein hoher Grad der Datenunabhängigkeit. Das Prozessmodell hingegen, beschreibt den eigentlichen Transformationsprozess. Hierbei nutzt es das definierte Nachrichtenmodell. Dementsprechend bildet das Prozessmodell die dynamischen Aspekte einer komplexen Nachrichtentransformation ab. Die Zielstellung des Prozessmodells ist letztendlich die Unabhängigkeit von konkreten Prozessbeschreibungssprachen. Nachdem nun die Anforderungen und Ziele des konzeptuellen Transformationsmodells geklärt wurden, soll dieses, in Analogie zur Drei-Schichten-Architektur nach ANSI/SPARC [ANSI75], in eine adaptierte Drei-Schichten-Architektur eingeordnet werden. Die externe Ebene umfasst dabei auf der einen Seite die unterschiedlichen standardisierten Abbildungen von Nachrichten und damit auch von Daten. Beispiele für diesen Teil der externen

Ebene

sind

XML

und

relationale

Daten,

aber

auch

spezielle

110

4 Nachrichtentransformationsmodell

Nachrichtenprotokolle. Die andere Seite der externen Ebene fasst die verschiedenen Prozessbeschreibungssprachen, wie beispielsweise WSBPEL, deren Spracherweiterungen und Alternativen, zusammen. Letztendlich stellt die externe Ebene also die Sicht eines Nutzers auf Nachrichten beziehungsweise Transformationsprozesse, unabhängig von darüber liegenden Abstraktionsstufen, dar. Im Gegensatz zu der externen Ebene, welche als standard- und sprachorientiert einzuschätzen ist, bildet die konzeptuelle Ebene die Anforderungen komplexer Nachrichtentransformationen in Bezug auf deren statischen und dynamischen Aspekte ab. Somit

stellt

die

konzeptuelle

Prozessbeschreibungen

dar,

Ebene

weshalb

eine

diese

Generalisierung

eine

von

Daten-

Datenunabhängigkeit

und

und eine

Unabhängigkeit von speziellen Prozessbeschreibungen realisiert. An dieser Stelle sei noch einmal unterstrichen, dass sich das hier definierte konzeptuelle Modell zwar an anderen Modellen, wie beispielsweise dem Relationenmodell, orientiert, diese jedoch jeweils Spezialisierungen darstellen. Die interne Ebene stellt die physische Realisierung des definierten konzeptuellen Modells dar. Diese interne Repräsentation muss dabei nicht notwendiger Weise vom konzeptuellen Modell

abweichen.

Allerdings

bieten

sich

intern

wiederum

unterschiedliche

Realisierungsalternativen an. Da die interne Abbildung von dem konzeptuellen Modell abhängt und dieses realisieren soll, ist es natürlicher Weise auch Gegenstand dieses Teilkapitels. Die nachfolgende Abbildung zeigt die logische Drei-Schichten-Architektur und damit die Einordnung des konzeptuellen Modells. Dabei enthält die externe Ebene lediglich Beispiele, deren Anzahl zum Zwecke der Übersichtlichkeit auf ein überschaubares Maß begrenzt wurde.

111

4 Nachrichtentransformationsmodell

Abbildung 47:

Adaptierte 3-Schichten-Architektur

Das hier definierte Transformationsmodell greift dabei die jeweiligen Vorteile existenter Modelle auf und erweitert diese um die Spezifika der Nachrichtentransformation. Das konzeptuelle Nachrichtenmodell orientiert sich zunächst grundlegend an dem relationalen Datenmodell [CODD70]. Da dies jedoch ausschließlich für strukturierte Daten konzipiert wurde, bilden weiterhin auch evolutionäre Modelle wie beispielsweise das „Molekül-Atom-Datenmodell“ (MAD) [HMMS87] die Grundlage. Diese Modelle wurden um Konzepte von Modellen zur Abbildung von semistrukturierten Daten, wie beispielsweise des „Object Exchange Model“ (OEM) [PAGW95] und des “Yet Another Tree-based Data Model” (YAT) [CDSS98], sowie des XML-Datenmodells angereichert. Da diese Modelle bereits umfassend in der Literatur diskutiert wurden, sollen sie hier nicht näher betrachtet werden. In Analogie zum Nachrichtenmodell lehnt sich auch das konzeptuelle Prozessmodell an das Relationenmodell an und bedient sich der Mengenoperationen und relationalen Operationen,

da

diese

wesentliche

Operationen

zur

Beschreibung

von

Datentransformationen bereitstellen. Da in einem Transformationsprozess jedoch auch die

112

4 Nachrichtentransformationsmodell

Beschreibbarkeit von Kontrollflüssen gewährleistet sein muss, reichen die Mittel des Relationenmodells nicht aus. So werden diese um Semantiken des ebenfalls mathematisch fundierten Petri-Netz-Modells [BAUM90], [DEOB96], [BROY98], [GIFP06] erweitert. An dieser Stelle sei erwähnt, dass bereits sehr interessante Arbeiten, wie beispielsweise [STAH04] und [HINZ05], existieren, welche sich mit der Überführung von BPELProzessen in Petri-Netze auseinandersetzen und damit die Beschreibbarkeit von komplexen Prozessen mit dem Petri-Netz-Modell nachgewiesen haben. An dieser Stelle ist auch das PI-Kalkül, zur Beschreibung paralleler Prozesse, wenigstens zu nennen, welches neben dem Lambda-Kalkül, zur Beschreibung von sequentiellen Prozessen, steht. Dessen Konzepte sind zwar nicht direkt in das konzeptuelle Modell eingegangen, jedoch stellt eine derartige formale Beschreibung eine Alternative dar. Im Rahmen der folgenden Abschnitte wird neben der inhaltlichen Diskussion des konzeptuellen Nachrichtenmodells und des konzeptuellen Prozessmodells auch eine formale Beschreibung des Modells definiert. Eine derartige Beschreibung bietet einige Vorteile. Der wesentlichste Vorteil ist die Unabhängigkeit der exakten Spezifikation von konkreten Sprachen und Plattformen. Außerdem sind Analysen im Rahmen der Qualitätssicherung vorstellbar, welche die Testbarkeit von Prozessbeschreibungen erhöhen und formale Korrektheitsbeweise zulassen. Schließlich sind, in Analogie zu Compilern und Anfrageoptimierern, selbst komplexe Optimierungen von Transformationsprozessen realisierbar.

4.3.2

Definition des konzeptuellen Nachrichtenmodells

In diesem Abschnitt ist zum einem das konzeptuelle Nachrichtenmodell zu definieren und zum anderen Ansätze dessen interner Realisierungsmöglichkeit vorzustellen. Das konzeptuelle

Nachrichtenmodell

soll

dabei

die

statischen

Aspekte

eines

Transformationsprozesses in Form eines generischen Nachrichtenmodells beschreiben. Hierbei

muss

dieses

hinreichend

generalisiert

sein,

um

die

unterschiedlichen

Nachrichtenprotokolle und Datenrepräsentationen abbilden zu können.

113

4 Nachrichtentransformationsmodell

In Anlehnung an das Molekül-Atom-Modell kann das Meta-Modell von Nachrichten, innerhalb des konzeptuellen Nachrichtenmodells, als ein Molekültyp „Message“ dargestellt werden. Dieser Molekültyp setzt sich aus den zwei Atomtypen Kopfsegment und Datensegment zusammen. Hierbei besteht eine 1:1-Kardinalität zwischen diesen beiden Atomtypen. Des Weiteren existiert eine unidirektionale, rekursive Referenz mit einer 1:CNKardinalität des Datensegmentes auf sich selbst. Der logische Aufbau des Kopfsegmentes und des Datensegmentes sind stark an das relationale Model angelehnt, weisen jedoch erweiterte Aspekte auf. So setzt sich das Kopfsegment aus k Name-Wert-Paaren zusammen. Das Datensegment hingegen besteht aus einer logischen Tabelle mit m Attributen und n Tupeln. Die Attribute können dabei sowohl atomare Typen aufweisen, als auch wiederum selbst ein Datensegment und damit eine „Nested Table“ darstellen. Die folgende Abbildung stellt noch einmal das MetaModell und den logischen Aufbau einer solchen Nachricht nebeneinander.

Abbildung 48:

Aufbau des konzeptuellen Nachrichtenmodells

Das konzeptuelle Nachrichtenmodell gewährleistet, auf Grund der geschachtelten Tabellen, eine dynamische, strukturtragende und generische Abbildung aller Datenrepräsentationen. Die Organisation in Tabellen reduziert dabei den Overhead für die Verwaltung der

114

4 Nachrichtentransformationsmodell

Metadaten und damit der Struktur auf ein Mindestmaß. Außerdem ermöglicht das Modell einen Direktzugriff auf einzelne Datenwerte, ohne bei jedem Zugriff Hilfsstrukturen anzulegen. Somit wäre auch ein inkrementelles Update von Nachrichten möglich. Nachdem das konzeptuelle Nachrichtenmodell nun grundlegend eingeführt und veranschaulicht wurde, ist an dieser Stelle eine Nachricht exakt zu definieren: Definition 4.1:

Message

Sei M ein Nachrichtentyp der sich mit M = (H, D) aus einem Kopfsegmenttyp H und einem Datensegmenttyp D beschreibt so ist eine Nachricht m mit m ⊆ M definiert. Weiterhin sei ein Kopfsegment mit H = {a1, ..., an} als Menge von elementaren Attributen mit n>0 und ein Datensegment mit D = A1 × ... × Am als Menge von Attributtypen mit m>0 definiert, wobei der Attributtyp Ai entweder atomar ist oder mit Ai ⊆ D ein Datensegment abbilden kann. So wird definiert, dass ein Attribut ai: D → Ai die Abbildung eines Attributtyps auf ein Datensegmenttyp

ist.

Außerdem

wird

für

alle

Tupel

eines

Datensegmentes

∀ t ∈ d: t[ai] ≡ t[i] definiert. Ein weiterer wesentlicher Aspekt des konzeptuellen Nachrichtenmodells ist die Überführung der externen Datenrepräsentationen in dieses Modell. Während die Abbildung von relationalen Daten direkt auf das Modell angewandt werden kann, ist dies bei der Überführung von XML ungleich komplexer. Prinzipiell wird hierbei, in Anlehnung an SQL:2003 Part 14: SQL und XML [SQL05a], eine Element-orientierte, genauer eine strukturorientierte, Zerlegung avisiert. Dabei erfolgt die Zerlegung generisch auf Grundlage selbstdefinierter, strukturspezifischer Regeln und damit unabhängig vom konkreten Inhalt. Während bislang ausschließlich das konzeptuelle Modell und damit ein theoretisches Beschreibungsmodell dargestellt wurde, soll an dieser Stelle bereits ein Blick auf die internen Realisierungsalternativen gerichtet werden. Die tatsächliche transiente und persistente Realisierung wird allerdings erst im Kapitel 6 umfassend dargestellt. Nachfolgend sind die drei unterschiedlichen Ansätze der internen Realisierung benannt.

115

4 Nachrichtentransformationsmodell

•

Dokumentenorientierter Ansatz

•

Attributorientierter, grobgranularer Ansatz

•

Attributorientierter, feingranularer Ansatz

Der dokumentenorientierte Ansatz verwaltet beliebige Datenrepräsentationen indem diese schlicht als BLOB verarbeitet werden. Somit ergibt sich natürlich die Problematik des Direktzugriffes auf einzelne Werte, was hierbei sehr inperformant sein kann. Die attributorientierten

Ansätze

zerlegen

die

Datenrepräsentationen

in

Attribute

beziehungsweise Elemente. Der attributorientierte, feingranulare Ansatz zerlegt ein eingehendes Dokument bis auf die atomaren Attribute und gestattet somit einen Direktzugriff. Der attributorientierte, grobgranulare Ansatz gliedert sich genau zwischen die beiden vorangestellten Ansätze ein und weist zwar eine Untergliederung in Attribute auf, kann hierbei jedoch ausschließlich eine Liste von elementaren oder komplexen Teilfragmenten enthalten. Somit kann der Zugriff auf Einzelwerte zwar unterstützt werden, jedoch ist dieser Ansatz eher unflexibel. Zur vollständigen Realisierung des konzeptuellen Modells bietet sich folglich ausschließlich die dritte Variante in Form des attributorientierten, feingranularen Ansatzes an. Mit dem konzeptuellen Modell wurden nunmehr die statischen Aspekte des Transformationsmodells beschrieben. Die Veranschaulichung, wie dieses Modell dann tatsächlich in Form einer prototypischen Implementierung und eines Datenmodells abgebildet werden kann, folgt im Kapitel 6 an einem Beispiel.

4.3.3 Das

Definition des konzeptuellen Prozessmodells konzeptuelle

Prozessmodell

adressiert

die

dynamischen

Aspekte

eines

Transformationsprozesses. Hiermit wird also ein Verarbeitungsmodell für das konzeptuelle Nachrichtenmodell definiert. Im Rahmen dieses Abschnitts sind zunächst die wesentlichen Entwurfsdimensionen vorzustellen und zu diskutieren. Nachdem dann eine Auswahl der Varianten hinsichtlich der einzelnen Dimensionen getroffen wurde, sind kurz ähnliche

116

4 Nachrichtentransformationsmodell

Ansätze aus anderen Arbeiten vorzustellen. Letztendlich wird abschließend das eigene konzeptuelle Prozessmodell im Detail exakt spezifiziert. Prinzipiell sind drei grundlegende Entwurfsdimensionen zu unterscheiden. Die erste Dimension bildet die Art des Prozessmodells. Diese Art beschreibt dabei die Modellierungs- und Verarbeitungsaspekte des Prozesses aus einer ganz abstrakten Perspektive. Die zweite Dimension ist die Orientierung des Prozessmodells. Unter der Orientierung soll in diesem Kontext der Entwurf der einzelnen Prozessschritte verstanden werden. Dabei hat die Orientierung des Prozessmodells einen nicht zu vernachlässigenden Einfluss auf die Art. Die dritte Dimension bildet letztendlich die Repräsentation des Prozessmodells. Dies meint die Art einer möglichen Realisierung im Rahmen der internen Ebene. Die nachfolgende Abbildung zeigt die drei Dimensionen und benennt bereits die Varianten der einzelnen Dimensionen.

Abbildung 49:

Entwurfsdimensionen des Prozessmodells

Im Weiteren werden nun die drei einzelnen Dimensionen vorgestellt und die jeweiligen Alternativen diskutiert. Bei der Art des Prozessmodells sind die zwei Alternativen: das hierarchische oder auch blockorientierte und das graphenorientierte Modell zu unterscheiden.

Das

hierarchische

Modell

schachtelt

dabei

einzelne

elementare

Prozessschritte mit Hilfe von strukturierten Prozessschritten. Um mit einem derartigen Modell komplexe Prozesse zu modellieren sind teilweise sehr tiefe Strukturen erforderlich. Außerdem ist ein derartiges Modell sehr restriktiv, so dass es sich vor allem zur

117

4 Nachrichtentransformationsmodell

Modellierung automatisierter Prozesse eignet. Im Gegensatz zu diesem Ansatz verfolgt die graphenorientierte

Alternative

das

Konzept,

dass

es

ausschließlich

elementare

Prozessschritte gibt, welche auch als Knoten bezeichnet werden. Diese Knoten sind dann mit beliebigen gerichteten Kanten verbunden, um den Prozessablauf zu modellieren. Somit liegt auf der Hand, dass dieses Prozessmodell eine bedeutend flexiblere Modellierung und eine effizientere Verarbeitung auf Grund der einheitlichen Ausführungsebene zulässt. Allerdings birgt eine derart flexible Modellierung die Gefahr der Unübersichtlichkeit in sich, da hier Modelle erzeugt werden können, welche durchaus mit „Spagetti-Code“ vergleichbar sind. Die nachfolgende Abbildung stellt die beiden Arten eines Prozessmodells noch einmal grafisch nebeneinander.

Abbildung 50:

Art des Prozessmodells

Hinsichtlich der Dimension Orientierung sind wiederum zwei Varianten zu unterscheiden. Die erste Variante ist ein sprachorientiertes Prozessmodell. Hierbei bilden die einzelnen Aktivitäten

einer

Prozessbeschreibungssprache

die

Prozessschritte

eines

Transformationsprozesses ab. Dies veranschaulicht auch den Einfluss der Orientierung auf die Art, da bei Orientierung an einer blockorientierten Sprache zwangsläufig eine hierarchische Art des Prozessmodells die Folge ist. Die alternative Variante dazu stellt das anforderungsorientierte Prozessmodell dar, bei dem sich die einzelnen Prozessschritte an den semantischen Anforderungen an den Transformationsprozess orientieren. Somit werden bei erweiterten Anforderungen lediglich einzelne Prozessschritte hinzugefügt. Die folgende Abbildung visualisiert diese Aspekte.

118

4 Nachrichtentransformationsmodell

Abbildung 51:

Orientierung des Prozessmodells

Während die Dimensionen Art und Orientierung vorrangig die konzeptuelle Ebene betreffen, adressiert die Dimension Repräsentation eher die interne Ebene der vorgestellten Drei-Schichten-Architektur. Auch bei der Repräsentation sind zwei Varianten zu differenzieren. Die erste Variante verkörpert die interpretierte Repräsentation des Prozesses, indem zur Ausführungszeit ein Objektgraph parametrisierter Objekte abgearbeitet wird. Die Bezeichnung als interpretierte Repräsentation wurde gewählt, da die Verarbeitungsreihenfolge erst zur Laufzeit festgelegt wird. Somit wäre es möglich den Prozess zur Laufzeit zu verändern und zu erweitern. Die zweite Variante stellt eine kompilierte Repräsentation dar. Hierbei wird ein statischer Prozessplan als eine Art Template generiert. Durch Parametrisierung dieses Prozessplans kann dann eine konkrete Prozessinstanz ausgeführt werden. Der Vorteil dieser zweiten Variante ist vor allem die bessere Performance im Vergleich zur ersten Variante. Die nachfolgende Abbildung zeigt die beiden Alternativen der Repräsentation eines Prozessmodells grafisch.

Abbildung 52:

Repräsentation des Prozessmodells

Nachdem die einzelnen Dimensionen im Detail vorgestellt wurden, wird nun eine Auswahl

119

4 Nachrichtentransformationsmodell

der Varianten vorgenommen, welche für das hier definierte konzeptuelle Prozessmodell in Frage kommen. In Bezug auf die Art des Prozessmodells ist die Entscheidung auf das graphenorientierte Prozessmodells gefallen. Allerdings mit einer Einschränkung. So wird eine Ausnahme gemacht und ebenfalls ein hierarchisches Element integriert. Das Risiko der sehr flexiblen Modellierung wird dadurch beseitigt, dass dem Endnutzer, beispielsweise mit WSBPEL, eine hierarchische und damit restriktive Sprache angeboten wird. Lediglich auf der konzeptuellen und internen Ebene werden die externen Beschreibungen dann auf das graphenorientierte Prozessmodell abgebildet. Hierdurch kann eine sehr effiziente Verarbeitung und die Abbildbarkeit aller externen Prozessbeschreibungssprachen gewährleistet werden. Auf Grund des Einflusses zwischen der Dimension der Orientierung und der Art bietet sich für die Dimension der Orientierung des Prozessmodells die anforderungsorientierte Variante an. Außerdem kann mit diesem Ansatz die geforderte Unabhängigkeit von der Prozessbeschreibungssprache realisiert werden, welche notwendig ist, da die Prozessbeschreibungssprachen die Modellierung des Datenflusses nur ungenügend unterstützen. In Bezug auf die Dimension der Repräsentation sind beide Varianten vorstellbar und weisen in Bezug auf das konzeptuelle Modell keine Vorteile beziehungsweise Nachteile auf. An dieser Stelle wird jedoch bereits im Hinblick auf die prototypische Realisierung im Kapitel 6 aus Effizienzgründen die kompilierte Repräsentation ausgewählt. Da nunmehr die wesentlichen Entwurfsdimensionen geklärt sind, soll im Weiteren auf die eigentliche Definition des Prozessmodells eingegangen werden. Die Basis des konzeptuellen Prozessmodells wird durch ein definiertes Grundmodell „Directed Graph“ realisiert. Hierfür wurde das Konzept des JBoss Graph Oriented Programming [JGOP06], entsprechend der Spezifika von Transformationsprozessen, adaptiert. Das Grundmodell beschränkt sich dabei auf drei Komponenten. Die erste ist ein Knoten (Node), welcher einen Prozessschritt darstellt. Die zweite Komponente ist eine Kante, also ein Übergang (Transition) zwischen zwei Knoten. Mit diesen beiden Komponenten kann bereits ein gerichteter Graph und damit ein graphenorientiertes Prozessmodell definiert werden. Dieses wird jedoch um ein hierarchisches Element, den Prozess, erweitert. Die nachfolgende Abbildung zeigt die Komponenten des Grundmodells und deren Beziehungen.

120

4 Nachrichtentransformationsmodell

Abbildung 53:

Grundmodell – „Gerichteter Graph“

Nachdem die Komponenten des Grundmodells nun bestimmt sind, müssen auch die Beziehungen zwischen diesen spezifiziert werden. So kann ein Knoten beliebig viele ausgehende Übergänge haben. Er kann weiterhin, während der Ausführung einer vom Prozess abgeleiteten Prozessinstanz, beliebig viele aktive ausgehende Übergänge haben, jedoch nicht mehr als die Gesamtzahl seiner ausgehenden Übergänge. Ein Übergang hat exakt einen Zielknoten. Allerdings können mehrere Übergänge einen Knoten referenzieren. Der Prozess ist ein hierarchisches Element und beinhaltet einen Start, einen aktuellen und einen End-Knoten. Dabei ist der Prozess selbst ein spezialisierter Knoten, so dass eine rekursive Verarbeitung mit beliebiger Schachtelungstiefe ermöglicht wird. Um das Grundmodell genauer zu spezifizieren, ist dieses in Form des Prozesses formal zu beschreiben. Definition 4.2:

Prozess

Ein Prozesstyp P definiert sich mit P = (N, S, F) als eine 3-Tupel-Darstellung eines gerichteten Graphen, wobei N mit N = { n1, ..., nn } und n>0 eine Menge von Knoten, S mit S = { s1, ..., sm }, m>0 und si = { o1, ..., ok } mit k>0 eine Menge von Diensten, samt deren jeweiligen Operationen, und F mit F ⊆ ( N × S ) eine Menge von Flussrelationen darstellt. P ist dabei mit P ⊆ N gleichzeitig ein Knotentyp. Ein Prozess p mit p ⊆ P weist dabei einen bestimmten Zustand z(p) mit z(p) = { z(n1), ..., z(nn) } auf. Der Prozesszustand ergibt sich also aus der Gesamtheit der einzelnen Knotenzustände z(ni) mit z(ni) = {M[]} und ((M[] =

¬∅) ∨ (M[] = ∅)).

121

4 Nachrichtentransformationsmodell

Laut Definition erhält ein Knoten also eine Menge von Input-Nachrichten, führt Verarbeitungen entsprechend seines Knotentyps und seiner Parametrisierung durch und leitet letztendlich eine Menge von Output-Nachrichten weiter. Die einzelnen Nachrichten entsprechen dabei dem konzeptuellen Nachrichtenmodell, welches ja bereits im Abschnitt 4.3.2 definiert wurde, und werden von Knoten zu Knoten weitergeleitet. Aufbauend auf dem Grundmodell „Directed Graph“ wird nun das vollständige anforderungsorientierte konzeptuelle Prozessmodell definiert. Hierbei werden spezifische Muster als spezialisierte Prozessschritte und damit als Knotentypen definiert. Ähnliche Ansätze existieren auch in der Literatur, wie beispielsweise [HOH04a] und [IBM05a]. Darin werden diese Muster oftmals als „Messaging Pattern“ oder „Mediation Pattern“ bezeichnet. In der folgenden Abbildung wird ein Vergleich zwischen ausgewählten Mustern der zuvorgehend genannten Quellen gezogen.

Abbildung 54:

Zusammenhänge von Mustern anderer Quellen

Obwohl [HOH04a] einen umfangreichen Katalog an Mustern definiert, können diese, auf Grund diverser Defizite, nicht direkt auf die komplexe Nachrichtentransformation angewandt werden. So sind die Muster oft zu allgemein gehalten, teilweise unvollständig definiert und oftmals mit anderen Aspekten vermischt. So wird beispielsweise mit dem „Content Enricher“ das Nachladen von Daten modelliert. Hierbei wird jedoch nicht ausschließlich die Datenanreicherung einer Nachricht, sondern vielmehr auch das Abfragen von Daten bei einer bestimmten Ressource beschrieben. Somit wird hier die Zusammenführung unterschiedlicher Daten entsprechend eines Schlüsselattributes und die

122

4 Nachrichtentransformationsmodell

Interaktion mit anderen Systemen miteinander vermischt, so dass dies nicht die Grundlage für ein konzeptuelles Modell bilden kann, welches auf Redundanzfreiheit ausgelegt ist. Letztendlich bleibt festzuhalten, dass in der relevanten Literatur verschiedenste Muster diskutiert werden. Diese werden jedoch nicht im Rahmen eines allgemeinen Gesamtmodells, sondern jeweils allein stehend betrachtet, was dazu führt, dass diese eher abstrakte Entwurfsmuster als konkrete Bestandteile eines Prozessmodells darstellen. Ausgehend von den funktionalen Anforderungen innerhalb des Gebietes der komplexen Nachrichtentransformation wurden folglich eigene Muster definiert, welche sich in drei Kategorien klassifizieren lassen. Die Muster sollten so angelegt sein, dass sie gleichermaßen den Kontrollfluss, Datenfluss sowie die Interaktion mit externen Systemen abbilden und dabei einen möglichst redundanzfreien Charakter aufweisen. Die folgende Tabelle soll zunächst einen Überblick über die einzelnen Muster sowie jeweils eine Kurzbeschreibung geben, bevor die einzelnen Muster wirklich im Detail dargestellt werden. Kategorie

Name

Beschreibung

Interaktionsorientierte Muster

Invoke

Senden/Empfangen einer Nachricht an eine/von einer Operation eines hinreichend abstrahierten Dienstes Empfangen einer Eingabenachricht von der aufrufenden Stelle Senden einer Ergebnisnachricht an die aufrufende Stelle Auswahl von ausgehenden Knoten entsprechend inhaltsbasierter Bedingungen (Alternative). Start einer parallelen Verarbeitung und Weitergabe der eingehenden Nachrichten Verzögerung der Verarbeitung bis zu einem Zeitpunkt beziehungsweise für eine Zeitspanne Initiiert ein Signal, worauf kontrolliert mit einem SignalHandler reagiert werden kann Einfache Wertzuweisungen in Form von elementaren oder komplexen Objekten. Durchführung elementarer Transformationen mittels XMLTransformationssprachen (XSL, STX, ...) Auswahl von Tupeln entsprechend einer Selektionsbedingung Auswahl von Attributen entsprechend einer Attributliste Verbund von Daten mehrerer Nachrichten entsprechend einer Verbundbedingung

Kontrollflussorientierte Muster

Receive Reply Switch Fork Delay Signal

Datenflussorientierte Muster

Assign Translation Selection Projection Join

123

4 Nachrichtentransformationsmodell

Kategorie

Name

Beschreibung

Setoperation Anwendung der Mengenoperationen Vereinigung, Durchschnitt und Differenz auf eine Nachrichtenmenge Split Zerlegung einer großen Nachricht in mehrere kleine Nachrichten OrderBy Sortierung einer Nachrichtenmenge entsprechend eines Sortierattributs Validate Validierung von Nachrichten entsprechend einer Prüfbedingung. Action Ausführen einer beliebigen Java-Klasse (einfache Erweiterungsmöglichkeit) Tabelle 9:

Musterkatalog des konzeptuellen Prozessmodells

Im Weiteren werden nun die einzelnen Muster näher beschrieben. Hierbei steht neben der eigentlichen Erläuterung der Semantik auch die formale Beschreibung im Mittelpunkt. Außerdem wird die Untergliederung in die Musterkategorien beibehalten. Interaktionsorientierte Muster Diese Musterkategorie beschreibt jegliche Kommunikation und Datenaustausch mit externen Systemen über Dienste. Die Dienste sind dabei derart abstrahiert, dass die Interaktion unabhängig vom Typ des externen Systems ist. Definition 4.3:

Invoke

ι⊆N ι s, o (m1) = M[] { m1, m2}

mit

So ← m1.d m2 = (hnew , d ← m s, o) Das Invoke-Muster beschreibt den Aufruf einer Operation o eines Dienstes s. Dies stellt die einzige Möglichkeit dar, Nachrichten an andere Systeme zu senden. Unabhängig ob die Zielsysteme synchron oder asynchron arbeiten, wird das Invoke für einzelne Prozessinstanzen stets synchron ausgeführt. Im Wesentlichen lassen sich zwei Anwendungsarten identifizieren. Zum einen ist das ein Request-Response-Invoke, wobei

124

4 Nachrichtentransformationsmodell

der Aufruf als eine Anfrage aufgefasst wird und dementsprechend ein Anfrageergebnis zurück liefert. Zum anderen ist ein einfaches Request-Invoke vorstellbar, womit ausschließlich eine Schreib-Anfrage realisiert wird. Das Invoke-Muster ist ein spezifischer Knotentyp. Außerdem wird das Muster durch einen Dienstnamen und einen Operationsnamen parametrisiert. Als Input erhält dieser Knoten eine Nachricht, dessen Datensegment an die Operation gesandt wird. Der Rückgabewert des Invoke sind zwei Nachrichten. Zum einen wird die unveränderte Input-Nachricht und zum anderen eine neu erstellte Nachricht zurückgegeben. Die zweite Nachricht setzt sich dabei aus einem neuem Kopfsegment sowie einem Datensegment, welches aus dem Anfrageergebnis konstruiert wird, zusammen. Definition 4.4:

Receive

ρ⊆N ρ () = { m1 } mit p = P ← m in m1 = (hnew , d ← m in) Das Receive-Muster beschreibt das Empfangen einer Eingabenachricht von einer aufrufenden Stelle. Das erste Receive in einem Prozess stellt die implizite Startaktivität dar. Beim Erhalt einer Nachricht wird also ein Prozess des bestimmten Prozesstyps erstellt. Neben diesem initiierenden Receive, stellt das nicht-initiierende Receive eine zweiten Variante des Receives dar. Auch das Receive ist wie alle folgenden Muster ein spezifischer Knotentyp. Der Knoten erhält eine Nachricht von einem externen System, konstruiert daraus das Datensegment einer Nachricht, welche dem konzeptuellen Nachrichtenmodell folgt. Außerdem wird ein neues Kopfsegment erzeugt.

125

4 Nachrichtentransformationsmodell

Definition 4.5:

Reply

ϕ⊆N ϕ (m1) = { } mit mout ← m1.d Die interaktionsorientierten Muster werden durch das Reply-Muster komplettiert. Dieses beschreibt das Senden einer Ergebnisnachricht des Transformationsprozesses an die aufrufende

Stelle.

Somit

wird

dieses

Muster

ausschließlich

in

synchronen

Transformationsprozessen zum Einsatz kommen. Selbstverständlich ist auch das Reply ein spezifischer Knotentyp. Bei dessen Ausführung wird eine Ergebnisnachricht aus dem Datensegment, der als Parameter übergebenen Nachricht, konstruiert und an das externe System gesandt. Kontrollflussorientierte Muster Diese Kategorie umfasst ausschließlich Spezialfälle der Abbildung von Kontrollflüssen, da eine Ganze Reihe elementarer beziehungsweise komplexer Muster bereits mit dem Grundmodell „Gerichteter Graph“ ausreichend beschrieben werden kann und somit kein spezieller Knotentyp benötigt wird. Definition 4.6:

Switch

SWITCH ⊆ N SWITCH expr[], n[] (m1) = (expri ∧ ( m1 → ni ) ) ∨ ( ∀ i ¬ expri ∧ ( m1 → nm ) ) mit expr[] = {expr1, …, exprn} mit n>0 n[] = {n1, …, nm} mit m=n+1 Das Switch-Muster stellt eine einfache Alternative dar. Letztendlich werden Bedingungen in Bezug auf die Daten einer eingehenden Nachricht bewertet und damit die Ausgabe der Nachricht auf einen spezifizierten Knoten bewirkt. Somit kann innerhalb des konzeptuellen Prozessmodells ein „Content Based Routing“ realisiert werden. Parametrisiert wird dieser Knotentyp durch die Angabe von n Bedingungs-Knoten-Paaren

126

4 Nachrichtentransformationsmodell

und einem Einzelknoten. Hierbei werden die Bedingungen nacheinander bewertet. Ist dabei eine Bedingung war, wird die Input-Nachricht ausschließlich auf den dazugehörigen Knoten weiter geleitet. Sofern alle Bedingungen falsch sind, wird die Nachricht an den Einzelknoten weitergeleitet. Die Switch-Aktivität ermöglicht bei einem graphbasierten Prozessmodell auch die Modellierung von jeglichen Iterationen. Definition 4.7:

Delay

DELAY ⊆ N DELAY t (m1) = m1 mit t = timestamp ∨ time Das Delay-Muster erlaubt die einfache Verzögerung der Verarbeitung einer Nachricht bis zu einem spezifizierten Zeitpunkt oder für einen spezifizierten Zeitraum. Dabei wird dieses Muster mit dem jeweiligen Zeitraum beziehungsweise Zeitpunkt parametrisiert. Eine InputNachricht wird nach der Verzögerung unverändert als Output-Nachricht an den nächsten Knoten übergeben. Definition 4.8:

Fork

FORK ⊆ N FORK n[] (m1) = ∀ i ( m1 → ni ) mit n[]={n1, …, nn } mit n>1 Mit dem FORK-Muster wird das konzeptuelle Prozessmodell mit der Möglichkeit der Parallelverarbeitung innerhalb eines Prozesses ausgestattet. Hierbei ist zu sichern, dass jeder ausgehende Übergang in einem eigenen Thread abgearbeitet wird. Die Parametrisierung erfolgt durch die Angabe der Menge von Zielknoten. Eine eingehende Nachricht wird dann unverändert an alle Knoten gesandt. Somit kann dieses Muster auch als

Prozesserzeugung

angesehen

werden

und

bildet

damit

den

Beginn

einer

Parallelverarbeitung. Das Ende der jeweiligen Parallelverarbeitung wird durch das Zusammenführen der Verarbeitungslinien in einem Knoten realisiert.

127

4 Nachrichtentransformationsmodell

Definition 4.9:

Signal

SIGNAL ⊆ N SIGNAL n, type (m1) = m2 mit m2.d = m1.d m2.h = signaltyp → m1.h Das SIGNAL-Muster dient der Initiierung von beliebigen Signalen mit denen unterschiedlichste

Ereignisse

angezeigt

werden

können. Das Datensegment der

übergebenen Nachricht bleibt hierbei unverändert. Lediglich in das Kopfsegment ist der Typ des initiierten Signals einzutragen. Dieses Muster wird dabei mit einem Knoten sowie einem Signaltyp parametrisiert. Letztendlich kann somit das Kopfsegment einer eingehenden Nachricht verändert und an einen beliebigen Knoten, den so genannten SignalHandler, weitergeleitet werden. Dieser Handler muss anschließend in kontrollierter Art und Weise auf das Signal reagieren. Datenflussorientierte Muster Die Kategorie der datenflussorientierten Muster stellt den Kern der komplexen Nachrichtentransformation

dar.

Hierbei

werden

Muster

definiert

welche

eine

Nachrichtenmenge erhalten, diese entsprechend ihres Knotentyps transformieren und anschließend eine gegebenenfalls veränderte Nachrichtenmenge zurückgeben. Definition 4.10: Assign

ζ⊆N ζ part(m1),part(m2) (m1, m2) = m3 mit m3.h ≡ m2.h m2 → m3 ∧ m1.part(m1) → m3.part(m2) Das Assign-Muster dient der einfachen Wertzuweisung zu Teilen einer Nachricht. Hierbei wird ein elementarer Wert oder ein komplexes Objekt der Nachricht m1 einem bestimmten

128

4 Nachrichtentransformationsmodell

Punkt innerhalb der Nachricht m2 zugewiesen, so dass letztendlich die Nachricht m3 entsteht. Dabei ist es notwendig als Parameter zum einen die Nachrichten und zum anderen die jeweiligen Nachrichtenteile zu spezifizieren, welche für die einfache Wertzuweisung relevant sind. Dabei wird das Kopfsegment nicht verändert. Definition 4.11: Translation

τ⊆N τ file, type (m1) = m2 mit m1 ⊇ m2 m1.h ≡ m2.h type = ’XSLT’ ∨ ’STX’ ∨ ’XQuery’ Die Translation beschreibt eine „Verschiebung“ von Daten. Hierbei können die XMLTransformationssprachen XSLT, STX, XQuery, XStreamQuery und FXT verwendet werden. Parametrisiert wird das Muster mit dem jeweiligen Typ der Transformation sowie dem jeweiligen Skript beziehungsweise der jeweiligen Anfrage. Nachdem eine Input-Nachricht übergeben wurde, wird die XML-Repräsentation dieser erstellt, die XML-Transformation auf diese angewandt, sowie eine neue konzeptuelle Nachricht auf Grundlage des Transformationsergebnisses erzeugt. Bei der Transformation bleibt das Kopfsegment unverändert. Definition 4.12: Selektion

σ⊆N σ expr (m1) = m2 mit m1.h ≡ m2.h m2.d ={ t| t ∈ m1.d ∧ expr }

129

4 Nachrichtentransformationsmodell

Die Selektion dient der Auswahl von Tupel, welche einem Prädikat oder auch Selektionsbedingung genügen. Somit wird der Nachrichteninhalt gefiltert, indem Datensätze ausgewählt werden. Dabei wird dieser Knotentyp ausschließlich mit einem Prädikat parametrisiert. Als Input erhält er eine Nachricht. Die Output-Nachricht wird nun so konstruiert, dass das Kopfsegment unverändert übernommen wird und alle Tupel des Datensegmentes der InputNachricht, welche dem Prädikat entsprechen, in das Datensegment der Output-Nachricht übernommen werden. Definition 4.13: Projektion

π⊆N π β (m1) = m2 mit m1.h ≡ m2.h

β⊆D m2.d ={ tβ | t ∈ m1.d } Mit der Projektion wird eine zweite Möglichkeit der Filterung des Nachrichteninhalts angeboten. Hierbei werden Attribute entsprechend einer Attributliste, also einer Positivliste, ausgewählt. Die Parametrisierung erfolgt ausschließlich über die Angabe der Attributliste, wobei die Attributliste definitionsgemäß nur Attribute enthalten darf, welche Teil des Datensegmentes der eingehenden Nachricht sind. Es werden alle Tupel des Datensegmentes der eingehenden Nachricht entsprechend dieser Attributliste reduziert und in das Datensegment der Output-Nachricht übernommen. Dabei kann gleichzeitig eine Umbenennung der Attributnamen sowie eine Permutation der Attribute erfolgen. Das Kopfsegment der Inputund Output-Nachricht sind dabei äquivalent.

130

4 Nachrichtentransformationsmodell

Definition 4.14: Join

⊆N a[]

(m1[]) = m2 {∀ i ((m1[i].d ∪ m1[i+1].d) ∧ (m1[i].d(a[i]) = (m1[i+1].d(a[i+1]))) }

mit

m2.h ≡ m1[0].h i>1

Mit dem Join-Knotentyp kann eine Nachrichtenmenge zu einer Nachricht zusammengefügt werden, wobei ein Verbund der Datensegmente entsprechend eines Verbundattributes errechnet wird. Parametrisiert wird dies durch eine Menge von Attributnamen sowie durch die optionale Angabe des Join-Typs und des Join-Algorithmus. Eine eingehende Nachrichtenmenge wird nun derart verarbeitet, dass zunächst der Verbund zwischen m[0] und m[1] mit dem Prädikat Value(a[0])=Value(a[1]) berechnet wird und anschließend das Ergebnis dieses Verbundes wiederum einem Join mit der nächsten Nachricht unterzogen wird, bis die komplette Nachrichtenmenge zu einer Nachricht zusammengefasst wurde. Definition 4.15: Mengenoperationen

μ⊆N μ (m1[]) = m2 Union:

∪ (m1[]) = m2 { t ∈ m1[0] ∨ t ∈ m1[i] }

Intersect:

∩ (m1[]) = m2 { t ∈ m1[0] ∧ t ∈ m1[i] }

Difference:

− (m1[]) = m2 { t ∈ m1[0] ∧ t ∉ m1[i] }

mit

m2.h = m1[0].h i>1

Eine weitere Möglichkeit der Zusammenführung von Nachrichten bietet das Muster der Mengenoperation. Hierbei werden die Tupel der Datensegmente der eingehenden Nachrichtenmenge entsprechend des Typs der Mengenoperation zusammengeführt. Der Typ kann Vereinigung (Union), Durchschnitt (Intersect) und Differenz (Difference) sein. Der Durchschnitt ist dabei kein elementarer Operator.

131

4 Nachrichtentransformationsmodell

Definition 4.16: Split

ψ⊆N ψ (m1) = m2[] mit ∀ i (m2[i].h ≡ m1.h) m2[i].d = t ∈ m1.d mit (m2[i].d ∩ m2[i+1].d = ∅) Der Split-Knotentyp arbeitet entgegengesetzt der Mengenoperationen. So wird eine eingehende Nachricht in n Nachrichten zerlegt, wobei das Datensegment der erzeugten Nachrichten jeweils ein Tupel des Datensegmentes der eingehenden Nachricht enthält. Das Kopfsegment der eingehenden Nachricht ist äquivalent zu jedem Kopfsegment der ausgehenden Nachrichten. Definition 4.17: OrderBy

ω⊆N ω β, type (m1[]) = m2[] { m[] → m[] } mit β⊆D (m1[] − m2[] = ∅) ∧ (m2[] − m1[] = ∅) type= ’asc’ ∨ ’desc’ Mit dem OrderBy-Muster können Nachrichtenmengen entsprechend einer Liste von Vergleichsattributen und einer Ordnung sortiert werden. Dabei stellt die Sortierung eine reine Permutation von Nachrichten dar, wobei die Nachrichten selbst nicht verändert werden und alle Nachrichten die in der eingehenden Nachrichtenmenge enthalten sind auch in der ausgehenden Nachrichtenmenge vorkommen müssen. Somit sind die Differenzen der beiden Nachrichtenmengen stets eine leere Menge. Definition 4.18: Validate

υ⊆N υ expr (m1) = m2 { (m1 ∧ expr) ∨ (herror ∧ dnew ∧ ¬ expr )}

132

4 Nachrichtentransformationsmodell

Der Validate Knotentyp ermöglicht eine Validierung der Daten einer eingehenden Nachricht. Dabei wird überprüft ob die Nachricht respektive die Daten der Nachricht dem angegebenen Prädikat entsprechen. Sofern dies der Fall ist, wird eine äquivalente Nachricht an den nächsten Knoten übermittelt, andernfalls wird ein Fehler signalisiert sowie eine Fehlernachricht weitergeleitet. Definition 4.19: Action ACTION ⊆ N ACTION c,o[] (m1) = m2 Das Action-Muster stellt die Erweiterungsmöglichkeit dieses konzeptuellen Prozessmodells dar. Dabei wird diesem Prozessschritt eine Input-Nachricht übergeben, beliebige lokale Operationen entsprechend der Parametrisierung ausgeführt und anschließend die veränderte Nachricht an einen Ausgangsknoten übergeben. Dieses Muster steht für Transformationen zur Verfügung, welche sich nicht in einem generischen Muster vereinen lassen. Neben den im Rahmen dieses konzeptuellen Modells vorgestellten Mustern, wären weitere Muster für das Transformationsmodell denkbar. An dieser Stelle soll kurz auf Gründe eingegangen werden, warum diese letztendlich nicht in das Modell aufgenommen wurden. •

While / Foreach Diese Muster wurden entfernt, da alle Iterationen mit dem Switch-Knotentyp abbildbar sind und das Modell möglichst redundanzarm sein sollte.

•

Monitor In Anlehnung an [IBM05a] sollte damit das explizite Logging abgebildet werden. Da dies jedoch implizit bei jedem Knotentyp realisiert wird, ist es überflüssig.

•

Aggregator Mit diesem Muster sollten Aggregatfunktionen auf Nachrichtenmengen und einzelne Datensegmente ausführbar sein. Da im Kontext der komplexen

133

4 Nachrichtentransformationsmodell

Nachrichtentransformation, jedoch das Ergebnis wiederum eine Nachricht wäre, ist die Anwendbarkeit eines derartigen Mustern eingeschränkt. •

Store / Restore Mit Store und dem entgegengesetzten Restore sollen Datenobjekte im lokalen Datenhaltungssystem zwischengespeichert und zu einem späteren Zeitpunkt wieder geladen werden. Der Sinn dieses Musters wäre vor allem die Unterstützung einer effizienten Verarbeitung, indem nur die Daten durch den Workflow transportiert werden, welche wirklich notwendig sind. Diese Muster sind überflüssig, da sie in konkreten Systemen stets implizit realisiert werden.

•

Wrapper / Unwrapper Die Muster Wrapper und das wiederum entgegengesetzte Unwrapper sollte dazu dienen eine Nachricht im Datensegment einer neuen Nachricht zu verpacken und wieder zu entpacken. Da dies implizit beim Receive, Invoke und Reply realisiert wird sind diese Knotentypen redundant.

Nachdem nun das konzeptuelle Transformationsmodell in Form des Nachrichtenmodells und des Prozessmodells definiert wurde, ist im Kapitel 5 unter anderem die Überführung von WSBPEL 2.0 in das konzeptuelle Modell aufzuzeigen.

4.4

Analyse und Optimierung von Transformationsprozessen

Während im Zuge der Beschreibung der Nicht-Funktionalen Anforderungen bereits auf die effiziente Verarbeitung eingegangen wurde, soll nun die Analyse und Optimierung von Transformationsprozessen Gegenstand der Betrachtung sein. Die folgende Abbildung veranschaulicht zunächst die prinzipielle Vorgehensweise bei derartigen Veränderungen.

134

4 Nachrichtentransformationsmodell

Abbildung 55:

Vorgehensweise bei der Analyse und Optimierung

Hierbei ist der Blick zum einen auf die regelbasierte Analyse und Optimierung von Prozessspezifikationen und zum anderen auf die kostenbasierte Optimierung der Transformationsprozesse zu richten. Um eine kostenbasierte Optimierung vornehmen zu können, ist jedoch zunächst ein detailliertes Kostenmodell für den Kontext der Nachrichtentransformation einzuführen. 4.4.1 Die

Regelbasierte Analyse und Optimierung Grundlage

für

die

regelbasierte

Analyse

und

Optimierung

von

Transformationsprozessen bilden statische Analysen der Software-Qualitätssicherung [FRIT06]. Gegenstand dieser Analysen ist die Überprüfung der Vollständigkeit der Parametrisierung von Prozessschritten, die Aufdeckung von Inkonsistenzen der Prozessbeschreibung sowie die Optimierung von Kontroll- und Datenflüssen. Um das zu erreichen, werden prinzipiell Anomalien in den beiden Kategorien „kontrollflussspezifische Anomalien“ und „datenflussspezifische Anomalien“ definiert. Ziel der Analyse und Optimierung ist es dann derartige Anomalien aufzudecken und in spezifizierter Art und Weise darauf zu reagieren. Eine Anomalie ist somit als eine 4-Tupel-Darstellung zu sehen. Diese umfasst zuerst die Einordnung in eine Kategorie. Außerdem muss sie einen Namen, die eigentliche Anomaliedefinition sowie eine Reaktion aufweisen. Die Reaktion kann dabei

entweder

die

Signalisierung

eines

Fehlers

(TypI-Anomalie)

oder

eine

Optimierungsanweisung (TypII-Anomalie) sein. Innerhalb des Prozesses der Analyse werden folglich Validierungen in Bezug auf TypI-Anomalien vorgenommen. Sofern hierbei keine Anomalie aufgedeckt wurde, war die Analyse erfolgreich, andernfalls muss diese mit

135

4 Nachrichtentransformationsmodell

einem Fehler enden. Bei der Optimierung wird, in Analogie zur Analyse, eine Validierung hinsichtlich der TypII-Anomalien durchgeführt und der Prozess entsprechend der spezifizierten Optimierungsanweisungen verändert. Um das Verständnis für derartige Analysen zu erhöhen soll zuvor noch kurz ein Überblick über die Datenflussanalyse [FRIT06] von gewöhnlichen Programmen gegeben werden. Hierbei werden Datenflüsse entlang von Kontrollflüssen analysiert. Dabei kann eine Variable definiert (D) werden, indem ihr ein Wert zugewiesen wird. Nachdem dies geschehen ist, kann die Variable referenziert (R) werden, indem sie entweder in eine Berechnung eingeht (Rc) oder als Teil eines Prädikates (Rp) genutzt wird. Zum Beginn und am Ende eines Programms wird der Variablenwert zerstört und die Variable somit undefiniert (U). In den beiden nachfolgenden Tabellen werden nun Beispiele für die einzelnen Anomalien aufgezeigt. Von diesen allgemeinen Definitionen ist für eine tatsächliche Realisierung eine konkrete Regelbasis abzuleiten, welche detailliert die Parametrisierung der einzelnen Prozessschritte einschließt und deshalb an dieser Stelle schlicht zu weit führen würde. Kategorie

Anomaliename Anomaliedefinition

Kontrollflussspezifische Anomalien Datenflussspezifische Anomalien

Rec-0 Inv-0 Term UR Param 2Pa

Tabelle 10:

Kategorie

TypI-Anomalien

Anomaliename Anomaliedefinition

Kontrollfluss- NA spezifische Anomalien Swi1 Swi2 Datenflussspezifische

Reply jedoch kein Receive im Prozess enthalten kein Invoke im Prozess enthalten unmögliche Termination Zugriff auf eine nicht initialisierte Variable Unvollständige Parametrisierung Zwei aufeinander folgende Projektionen P1 und P2 mit P1 ⊆ P2

DD

nicht erreichbare Prozesspfade Switch enthält unmögliche Bedingungen Überdeckende SwitchKnoten Doppelte Definition

Optimierungsanweisung Entfernung der Prozesspfade Entfernen des kompletten Prozesspfades Entfernung schwächerer Switch-Knoten Entfernen der ersten Zuweisung

136

4 Nachrichtentransformationsmodell

Kategorie

Anomaliename Anomaliedefinition

Optimierungsanweisung

spezifische Anomalien

DU UU 2T

Entfernen der Zuweisung Entfernen der Variablen Zusammenführung zu einer 2-Phasen-Transformation Entfernen der Projektion P1 Entfernen der schwächeren Selektion

Unnötige Definition Unnötige Deklaration Zwei aufeinander folgende elementare Translationen Zwei aufeinander folgende Projektionen mit P1 ⊇ P2 Zwei aufeinander folgende Selektionen bezüglich des gleichen Attributes Zwei aufeinander folgende Validierungen bezüglich des gleichen Attributes

2Pb 2S 2V Tabelle 11:

Entfernen der schwächeren Validierung

TypII-Anomalien

Zusammenfassend

lässt

Prozessbeschreibungen

sich absolut

festhalten,

dass

notwendig

die ist,

regelbasierte um

die

Analyse Qualität

von von

Transformationsprozessen zu sichern und, dass zahlreiche Optimierungsaspekte existieren, um suboptimal modellierte Prozesse in effizientere Prozessbeschreibungen zu überführen. Das Problem hierbei ist, dass bei Verwendung von elementaren Transformationen ein Rückschritt von der Ebene der Attribut- auf die Ebene der Dokumentverarbeitung erfolgt und somit die Analyse und Optimierung erheblich erschwert wird. Da das Potenzial der regelbasierten Optimierung letztendlich begrenzt ist, soll diese Art um eine kostenbasierte Optimierung ergänzt werden.

4.4.2

Einführung eines Kostenmodells

In diesem Abschnitt soll ein Kostenmodell eingeführt werden, mit dessen Hilfe Kosten für Transformationsprozesse bewertet werden können und das somit die Grundlage für die kostenbasierte Umformung von derartigen Prozessen darstellt. Dabei werden zunächst die Gesamtkosten der Nachrichtenverarbeitung in Teilkosten zerlegt. Letztendlich werden in diesem Rahmen ebenfalls die Kosten der einzelnen Muster des MTM eingeschätzt. Prinzipiell soll in diesem Kontext unter Kosten die CPU-Auslastung, der Speicherbedarf

137

4 Nachrichtentransformationsmodell

sowie die effektive Verarbeitungszeit verstanden werden. Um die Kosten der Nachrichtentransformation realistisch bewerten zu können, soll das Kostenmodell in Bezug auf eine allgemein bewährte Architektur eines Message Broker Systems konzipiert und an dieser Stelle diskutiert werden. Diese Referenzarchitektur geht dabei von einer nachrichtenbasierten, wahlweise synchronen oder asynchronen, Verarbeitung aus. Somit können Dienste Nachrichten an das Interface des Systems senden. Diese werden entweder synchron verarbeitet oder mit Hilfe eines Message Queueings persistent im Systems hinterlegt. Ein Scheduler erzeugt nun Prozessinstanzen und initiiert damit die Verarbeitung der Nachricht in einem Transformationsprozess. Während dieses Prozesses muss die Transaktionssicherheit gewährleistet sein, weshalb Versionen der eingehenden Nachrichten persistent abgelegt werden. Letztendlich können dann mit Hilfe von Adaptern heterogene Dienste und damit externe Systeme genutzt werden. Die folgende Abbildung visualisiert die beschriebene Architektur noch einmal.

Abbildung 56:

Kostenaufteilung innerhalb einer MOM-Referenzarchitektur

Nachdem hiermit die Referenzarchitektur einführend betrachtet wurde, sollen nun die Gesamt- und Teilkosten der Nachrichtenverarbeitung identifiziert werden. Hierfür sind zunächst die Gesamtkosten eines Transformationsprozesses zu definieren.

138

4 Nachrichtentransformationsmodell

Definition 4.20: Kosten eines Transformationsprozesses C Seien C (p) die Kosten eines Transformationsformationsprozesses p, so wird definiert, dass sich diese Kosten mit C (p) = α * β * (Cc (p) + Ct (p) + Ca (p)) aus den Kommunikationskosten Cc (p), den Verarbeitungskosten Ct (p) sowie den internen Verwaltungskosten Ca (p) ergeben. Diese sind mit α = sizeof( m ) von der Größe und mit

β = dim( m ) von der Dimension oder hierarchischen Tiefe einer eingehenden Nachricht abhängig. Wie soeben definiert, unterteilen sich die Gesamtkosten in drei Teilkomponenten. Diese sollen im Weiteren einzeln definiert und beschrieben werden. Definition 4.21: Kommunikationskosten Cc (p) Seien Cc (p) die Kommunikationskosten, so wird definiert, dass sich diese mit Cc (p) = Σ C (ink) + Σ C (sl) aus der Summe der Kosten für interaktionsorientierte Prozessschritte in sowie der Summe der Kosten für Verarbeitungen der externen Systeme s ergeben. Weiterhin wird definiert, dass sich die Kosten für das interaktionsorientierte Muster Invoke mit C(ι

s, o

(m1)) = C(Aufruf) + C(Transfer) + C(Verarbeitung)

[+ C(RückTransfer) + C(Empfangen)] als Summe der Kosten für den Aufruf eines Dienstes, des Datentransfers, der eigentlichen Verarbeitung,

sowie ggf. dem

Datenrücktransfer der Ergebnisse und deren Empfangen ergibt. Im Gegensatz dazu werden die Kosten für das Receive Muster lediglich mit C(ρ()) = C(RückTransfer) + C(Empfangen) als Summe der Kosten für Datentransfer und Empfangen der Nachricht definiert. In Analogie zum Invoke sind letztendlich die Kosten des Reply-Musters mit C(ϕ (m1)) = C(Aufruf) + C(Transfer) definiert. Die Kommunikationskosten wurden dabei in der voraus gegangenen Abbildung mit dem Buchstaben A markiert. Ihnen werden die einzelnen interaktionsorientierten Prozessschritte des konzeptuellen Prozessmodells des MTM sowie die Kosten für Verarbeitungen externer Systeme zugeordnet. Die interaktionsorientierten Muster umfassen dabei Kosten für das

139

4 Nachrichtentransformationsmodell

Empfangen und Senden von Nachrichten, wobei sowohl Kosten für den Aufruf mittels Adaptern als auch die notwendigen Kosten für den Netztransfer und die externe Verarbeitung enthalten sind. Die Einbeziehung der externen Systeme in das Kostenmodell ist dabei notwendig, da die Optimierung des gesamten Integrationsprozesses im Vordergrund steht. Definition 4.22: Verarbeitungskosten Ct (p) Seien Ct (p) die Verarbeitungskosten eines Transformationsprozesses so ergeben sich diese per Definition mit Ct (p) = Σ C (kni) + Σ C (dnj) als Summe der Kosten für kontrollflussorientierte Prozessschritte und der Summe der Kosten für datenflussorientierte Prozessschritte, welche sich wiederum folgender Maßen definieren: C(SWITCH expr[], n[] (m1))= Σ C (expr i → m1) C (FLOW n[] (m1)) = count(n) * CONST newthread C (DELAY t (m1)) = t C (ζ part(m1),part(m2)) = C(extract from m1) + C(write to m2) C(τ file, type (m1)) = C(read document) + C(Aufbau DOM) + C(Transformation) + C(Aufbau DOM’) + C(write document) C(σ expr (m1)) = C(read ∧ validierung ∀ t ∈ m1) + C(Übernahme der Tupel) C(π β (m1)) = C(Ermittlung der Attribute) + C(Auswahl der Attribute bei jedem Datensatz) C(

a[]

(m1[]))= C(m1 x m2) + C( C(σ expr (m1 x m2)) )

C(μ (m1[])) = Σ C (μ (m1[i-1], m1[i] ) mit C (μ (m1, m2) = C(validierung ∀ m) + C(Ermittlung gleicher Datensätze) C(ψ (m1)) = C(count(m1.d)) + count(m1.d) *( C(new M) + C(copy(h, d[i])) ) C(ω β, type (m1[])) = C(Sortieralgorithmus) C(υ expr (m1))= count(m1.d) *(C(check(m1.d[i]))) C(ACTION c,o[] (m1)) = C(Laden c) + Σ ( C(Aufruf o) + C(Verarbeitung o)) Die Verarbeitungskosten des Transformationsprozesses, welche auch schlicht als Transformationskosten bezeichnet werden können, wurden in der Abbildung mit B

140

4 Nachrichtentransformationsmodell

bezeichnet. Sie schließen alle kontroll- und datenflussorientierten Muster des MTM ein. Definition 4.23: Interne Verwaltungskosten Ca (p) Seien

Ca

Ca (p) =

(p)

die

internen

Verwaltungskosten,

so

ergeben

sich

diese

mit

Cq(m, count(M)) + Cp (p, count(P)) + Ctx (p) aus den Kosten für das

transaktionale MessageQueueing Cq der eingehenden Nachrichten, den Kosten für die Verwaltung von Prozessinstanzen Cp und den Kosten für die Realisierung der Transaktionssicherheit Ctx mit Ctx (p) = C(undo) + Σ C ( Ctx (ini)) + C(redo). Die internen Verwaltungskosten können im Rahmen dieses Kostenmodells auch als Kosten der Administration verstanden werden. Hierbei zählen nur die Kosten zu dieser Kategorie, welche nicht der eigentlichen Transformation oder der Interaktion dienen, sondern ausschließlich der internen Verwaltung, wie beispielsweise die Realisierung der Transaktionssicherheit oder das Message Queueing. Durch das hier definierte Kostenmodell wird die kostenbasierte Optimierung ermöglicht. Nachdem nun die Teilkosten eines Transformationsprozesses und besonders die Kosten der einzelnen Muster des MTM bestimmt wurden, sind nun zwar keine exakten Kostenberechnungen jedoch vergleichende Kostenabschätzungen realisierbar.

4.4.3

Kostenbasierte Optimierung

Derartige

kostenbasierte

Optimierungen

basieren

im

Wesentlichen

auf

der

Kostenbewertung und anschließender Auswahl, funktional äquivalenter, Varianten von Transformationsprozessen. Hierbei lassen sich drei Möglichkeiten der Bildung dieser Varianten unterscheiden. •

Vertauschen von Operatoren des Transformationsprozesses

•

Ersetzen kompletter Teilbäume des Transformationsprozesses

•

statistikbasierte Parametrisierung von Operatoren des Transformationsprozesses

141

4 Nachrichtentransformationsmodell

Das Vertauschen von Operatoren bezieht sich dabei vor allem auf die datenflussorientierten Muster, welche eine selektive Wirkung auf die Daten einer Nachricht haben. Beispiele hierfür sind die Muster Selection, Setoperation und Translation. So ist es selbstverständlich optimaler die Datenmenge möglichst frühzeitig in einem Transformationsprozess zu reduzieren. Im Gegensatz zu der reinen Vertauschung adressiert das Ersetzen von Teilbäumen, die Entfernung

von

nicht-optimalen

Teilgraphen

des

Transformationsprozesses

und

gegebenenfalls deren Ersetzung durch alternative Teilgraphen, wobei die nach außen sichtbare Gesamtfunktionalität eines Transformationsprozesses nicht verändert werden darf. Allerdings kann die interne Verarbeitung eklatant von der ursprünglichen Prozessverarbeitung abweichen. Anders als bei den ersten beiden Möglichkeiten muss der Optimierung mittels der statistikbasierten Parametrisierung von Operatoren eine mehrfache Ausführung des Transformationsprozesses vorausgegangen sein. Aufbauend auf erhobenen Statistiken kann dabei eine Regenerierung der Prozessbeschreibung vorgenommen werden. Derartige Statistiken können Aufschluss über den durchschnittlichen Nachrichtendurchsatz, die durchschnittliche Nachrichtengröße, Selektivitäten sowie über Häufigkeitsverteilungen hinsichtlich alternativer Kontrollflüsse geben. Im Weiteren sind die drei Möglichkeiten der kostenbasierten Optimierung jeweils mit einem Beispiel zu unterlegen. Hierfür wurden die folgenden drei Optimierungsbeispiele ausgewählt. •

Filtern von Nachrichteninhalten (Vertauschen von Operatoren)

•

Zusammenfassen von Nachrichten (Ersetzen von Teilbäumen)

•

Überführung externer Datenrepräsentationen (statistikbasierte Parametrisierung)

Filtern von Nachrichteninhalten Angenommen in einem Transformationsprozess wird lediglich eine Nachricht von S1 empfangen, deren Nachrichteninhalt in Form einer Projektion und Selektion gefiltert und anschließend an S2 gesendet. Sofern die Selektion tatsächlich eine selektive Wirkung auf

142

4 Nachrichtentransformationsmodell

den Nachrichteninhalt hat, ist dieser Transformationsprozess nicht optimal. Die folgende Abbildung zeigt dies zunächst grafisch.

Abbildung 57:

Filtern von Nachrichteninhalten

Prinzipiell kann die Kostenreduktion für Ct (p) bei der Variante b damit begründet werden, dass die Kosten für die Projektion kleiner als bei Variante a sind, da dieser Operator weniger Tupel verarbeiten muss, wobei die Kosten für die Selektion bei beiden Varianten gleich sind. Um diese Kostenreduktion nachzuweisen, wird für das Beispiel eine Selektivität von 10% unterstellt. Auf Grund dessen ergibt sich folgende Kostenreduktion.

ΔC =

( C(σa expr (min)) + C(πa β (min)) ) - ( C(σb expr (min)) + C(πb β (min)) )

ΔC =

C(πa β (min)) - C(πb β (min))

ΔC =

( C(Ermittlung der Attribute a) + C(Auswahl der Attributwerte ∀ t a ∈ min) ) - ( C(Ermittlung der Attribute b) + C(Auswahl der Attributwerte ∀ t b ∈ min) )

ΔC =

0.9 * C(Auswahl der Attributwerte ∀ t a ∈ min)

Nach der Vertauschung befindet sich die Selektion an der frühest möglichen Stelle, da die Nachricht erst mit dem Receive in den Verwaltungsbereich des Transformationsprozesses gelangt. Zusammenfassen von Nachrichten Wie bereits erwähnt kann das Zusammenfassen einer Menge von Nachrichten zu einer

143

4 Nachrichtentransformationsmodell

großen Nachricht und der anschließenden Transformation als eine Gesamtnachricht Performancevorteile bieten. Um dies zu realisieren sind jedoch die einfachen Receive und Invoke Muster durch komplexere Konstrukte zu ersetzen, welche diesen Sachverhalt abbilden. Um die grundlegende Abschätzung eines Kostenvergleiches zwischen der Verarbeitung einer Menge von Nachrichten und einer zusammengefassten Nachricht zu zeigen, wird weiterhin von einem Transformationsprozess ausgegangen, indem eine Nachricht von S1 empfangen, Daten von S2 nachgeladen und anschließend an S3 gesandt werden. Nachfolgend ist dies wiederum zunächst dargestellt.

Abbildung 58:

Verarbeitung einer Nachrichtenmenge

Während bei der Verarbeitung von Einzelnachrichten, wobei der Transformationsprozess aus Receive, Invoke (Request-Response), Join und Invoke (Request) besteht, ist bei der Verarbeitung von zusammengeführten Nachrichten das erste Receive sowie das letzte Invoke jeweils durch ein komplexes Konstrukt zu ersetzen. Entscheidend bei dieser Umformung des Transformationsprozesses ist die einmalige Nutzung des Invoke- sowie des Join-Knotens zur Anreicherung der Nachrichtenmenge. Die Reduktion der Kosten eines Transformationsprozesses kann dann annähernd wie folgt angegeben werden. Dabei wird bewusst vernachlässigt, dass die Kosten für das Invoke- und Join-Muster eigentlich abhängig von der Größe des Nachrichteninhaltes ist.

144

4 Nachrichtentransformationsmodell

ΔC =

(n-1) * ( C(ι s, o (min)) + C(

a[]

(min[])) )

- C( μ (min[]) ) - C( ψ (min) ) mit n ... Anzahl der zusammengeführten Nachrichten Prinzipiell ist jedoch zu erkennen, dass bei einer Vergrößerung von n eine Kostenreduzierung für die einzelne Nachricht erreicht wird. Allerdings muss man an dieser Stelle die Verzögerung beachten, welche sich direkt proportional zu n verhält. Die Optimierung der Verarbeitungszeiten in Bezug auf die einzelnen Nachrichten sorgt jedoch nicht gleichzeitig für einen optimalen Nachrichtendurchsatz. Dieser wird erst bei der rekursiven Einbeziehung der Verarbeitungszeiten erzielt. So stellt sich der optimale Durchsatz ein, sofern ti( Sammlung Nachrichten ) = ti-1( Verarbeitung Nachrichtenmenge ) ist. Um dies zu erreichen bietet es sich an, solange eingehende Nachrichten zu sammeln bis die Verarbeitung der aktuellen Nachrichtenmenge abgeschlossen ist. Damit strebt das System selbstständig gegen ein Optimum. Überführung externer Datenrepräsentationen Auf

Grundlage

von

statistischen

Auswertungen

der

Verarbeitung

von

Transformationsprozessen, kann sich eine optimale Prozessbeschreibung doch als suboptimal herausstellen. Am Beispiel soll nun die Erhebung von Häufigkeitsverteilungen hinsichtlich alternativer Kontrollflüsse veranschaulicht werden. Dabei wird eine Nachricht von S1 empfangen, in Abhängigkeit des Nachrichtentyps entweder an Kontrollfluss A oder Kontrollfluss B weitergeleitet und letztendlich an S3 gesendet. Sofern die Nachricht an Kontrollfluss A weitergeleitet wird muss sich diese im Zustand parsed befinden um feingranular auf deren Attribute zugreifen zu können. Andernfalls wird die Nachricht bei Nutzung des Kontrollfluss B zunächst in den Zustand unparsed versetzt um anschließend eine XMLTransformation ihrer Daten vornehmen zu können. Da ohne Kenntnisse der Häufigkeitsverteilungen von einer 50%igen Wahrscheinlichkeit für beide Fälle auszugehen ist, wird der Receive-Operator derart parametrisiert, dass die Nachricht beim Empfangen in

145

4 Nachrichtentransformationsmodell

den Zustand parsed überführt wird. Angenommen während der Ausführung des Transformationsprozesses konnte eine Haufigkeitsverteilung mit P(B)=0.712 erhoben werden. So werden die eingehenden Nachrichten in einem Großteil der Fälle unnötiger Weise in den feingranularen Zustand parsed überführt, obwohl zunächst kein Zugriff auf Einzelattribute notwendig ist, und die Nachricht vor der Translation wieder den Zustand unparsed annehmen muss. Die folgende Abbildung zeigt dieses Szenario schematisch.

Abbildung 59:

Überführung externer Datenrepräsentationen

An dieser Stelle bietet sich eine veränderte Beschreibung des Transformationsprozesses auf Basis dieser Statistiken mit einer veränderten Parametrisierung an. Die Kostenreduktion kann hierbei wie folgt qualitativ beschrieben werden.

ΔC =

(C( parse() ) + 0.712 * C( unparse() )) - (C( initunparsed()) + 0.241 * C( parse() )) mit C( parse() ) ≈ C( unparse() ) und C( parse() ) > C( initunparsed() )

ΔC =

0.759 * C( parse() + 0.712 * C( unparse() ) - C( initunparsed()

Bei derartigen statistischen Erheben, könnten natürlich auch andere Aspekte wie

146

4 Nachrichtentransformationsmodell

beispielsweise die Selektivität beachtet werden, weshalb dies auch in Kombination mit den anderen Möglichkeiten der kostenbasierten Optimierung anwendbar ist. So zeigt beispielsweise die Abbildung, die Vertauschung der Kontrollflüsse des Switch-Knotens, da somit in der Mehrzahl der Fälle, unnötige Kosten für mehrfache Bedingungsprüfungen entfallen. An dieser Stelle sei noch auf den Abschnitt 6.1.1 verwiesen, indem die Integration der Analyse und Optimierung von Transformationsprozessen in einen Parser beschrieben wird. Als Konsequenz dieses Kapitels bleibt letztendlich die Definition des konzeptuellen Nachrichtentransformationsmodells festzuhalten, welches durch unterschiedliche externe Beschreibungen abgebildet werden kann. Eine Variante ist die Beschreibung dieses Modells mit WSBPEL 2.0, welche im folgenden Kapitel detailliert dargestellt ist.

147

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

5

Beschreibung von Nachrichtentransformationen mit WSBPEL

Nachdem

die

Problematik

der

komplexen

Nachrichtentransformation

in

dem

zuvorgehenden Kapitel auf rein konzeptueller Ebene diskutiert wurde, soll nun wieder der Bezug zu der im Kapitel 3 dargestellten Prozessbeschreibungssprache WSBPEL 2.0 hergestellt werden. Hiermit ist das definierte Message Transformation Model (MTM), im Rahmen der externen Ebene, standardisiert zu beschrieben. Dabei ist unbedingt die Richtung der Abbildung zu beachten. So ist es erklärtermaßen nicht das Ziel beliebige BPEL-Prozesse auf das MTM abzubilden. Die eigentliche Intention ist die Beschreibung komplexer Transformationsprozesse mit Hilfe von BPEL. Zunächst sind prinzipielle Beschreibungsansätze zu diskutieren, welche zur Abbildung von Nachrichtentransformationen mit Prozessbeschreibungssprachen vorstellbar sind. Nachdem dann ein Ansatz ausgewählt wurde, wird gezeigt wie das MTM mit Hilfe von WSBPEL beschrieben werden kann, respektive wie eine WSBPEL-Beschreibung in eine interne Repräsentation

des

MTM

zu

überführen

ist.

Abschließend

werden

dann

Bewertungskriterien definiert, auf deren Grundlage eine Einschätzung der Sprache WSBPEL aus unterschiedlichen Perspektiven erfolgen soll.

5.1

Generelle Beschreibungsansätze

Unabhängig von bestimmten Prozessbeschreibungssprachen lassen sich generell vier unterschiedliche

Ansätze

zur

Beschreibung

von

Nachrichtentransformationen

unterscheiden. Im Rahmen dieses Teilkapitels sollen die Ansätze mit ihren Vorteilen und Nachteilen detailliert vorgestellt werden. Dabei ist prinzipiell festzustellen, dass die Abbildung von Interaktionen und des Kontrollflusses unproblematisch ist, da alle ausführbaren Prozessbeschreibungssprachen als kontrollflussorientiert einzuschätzen sind. Es ergibt sich jedoch die Problematik der Abbildung

des

Datenflusses,

da

die

Funktionalitäten

der

aktuellen

148

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Prozessbeschreibungssprachen an dieser Stelle nicht ausreichen. Elementarmuster-Ansatz Diese Variante der Beschreibung von Nachrichtentransformationen geht von der Annahme aus, dass Transformationen elementar sind und mit einer einzigen Aktivität beschrieben werden können. Auf Grund dieser Annahme kann der Elementarmuster-Ansatz auch als „Minimal-Ansatz“ bezeichnet werden. Hierbei wird die Transformation als eine Black-Box angesehen, welche mit Hilfe einer geeigneten Parametrisierung unterschiedliche Transformationstypen abbilden kann. Dabei sind

elementare

Wertzuweisungen

über

XPath,

aber

auch

umfangreichere

Transformationen mit Hilfe von XML-Transformationssprachen denkbar. Letztendlich könnte dann die Parametrisierung einer derartigen Einzelaktivität in das verarbeitende System projiziert werden. Die folgende Abbildung zeigt ein einfaches Szenario, welches diesem Ansatz folgt.

Abbildung 60:

Elementarmuster-Ansatz

Der Vorteil dieses Ansatzes ist vor allem die direkte Unterstützung durch ausführbare Prozessbeschreibungssprachen. So lässt beispielsweise WSBPEL 2.0 mit der AssignAktivität einfache Zuweisungen als auch den Aufruf von XSLT-Skripten zu, womit standardisierte BPEL-Implementationen einsetzbar wären. Ein weiterer Vorteil ist die Einfachheit dieses Ansatzes. Allerdings weist diese Variante auch erhebliche Nachteile auf. So reicht dieser Ansatz nicht aus, um komplexe Nachrichtentransformationen abzubilden, da die Transformation als

149

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

einzelner Prozessschritt dargestellt wird und somit das Nachladen von Daten und das Content Based Routing nicht ermöglicht. Außerdem ist die Interaktion mit externen Systemen nicht eingeschlossen. Zusammenfassend bleibt einzuschätzen, dass dieser Ansatz für die Beschreibung komplexer Nachrichtentransformationen nicht adäquat erscheint, jedoch für funktional getriebene Geschäftsprozesse oftmals ausreichend ist. Komplexmuster-Ansatz Der Komplexmuster-Ansatz verfolgt die Annahme, dass sich Nachrichtentransformationen, mit einer Menge von kontrollfluss- und datenflussorientierten Aktivitäten beschreiben lassen. Damit ordnet er sich zwischen den Elementarmuster-Ansatz und die nachfolgend beschriebenen Ansätze ein, so dass er auch als “Middle-of-the-road-Ansatz” bezeichnet werden kann. Eine mit diesem Ansatz beschriebene Transformation schließt kontrollflussorientierte Aktivitäten in die Betrachtung mit ein. Die Abbildung des Datenflusses beschränkt sich immer noch auf elementare Transformationen in Form von Elementarmustern. Die Idee ist, dass der Geschäftsprozess global mit all seinen Facetten modelliert wird und nur, die für die Nachrichtentransformation relevanten, Teile des Prozesses in das verarbeitende System projiziert werden. Die folgende Abbildung verdeutlicht diesen Ansatz.

Abbildung 61:

Komplexmuster-Ansatz

150

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Wie bereits beim Elementarmuster-Ansatz dargestellt, weist auch dieser Ansatz den Vorteil der direkten Unterstützung durch Prozessbeschreibungssprachen auf. Außerdem lassen sich hiermit umfangreichere Transformationen inklusive des Content Based Routing und anderen Abhängigkeiten realisieren. Doch auch dieser Ansatz weist noch zwei Hauptprobleme auf. Zum einen ist dies das außer Acht lassen der Interaktion mit externen Systemen. Zum anderen können auch hiermit nur sehr umständlich datenflussorientierte Prozesse abgebildet werden. Letztendlich ist festzustellen, dass dieser Ansatz gegenüber dem Elementarmuster-Ansatz den Vorteil der Kontrollflussorientierung hat, jedoch ebenfalls nicht adäquat für die Abbildung von datenintensiven Transformationsprozessen ist. Prozess-Ansatz Mit diesem Ansatz soll den Nachteilen der zuvor beschriebenen Varianten entgegengetreten werden. Hierbei wird davon ausgegangen, dass ein Transformationsprozess nur durch eine vollständige Prozessbeschreibung realisiert werden kann. Da hier der Gesamtprozess in die Betrachtung aufgenommen wird, soll dieser auch als „Maximal-Ansatz“ bezeichnet werden. Neben

den

kontrollflussorientierten

Aktivitäten

werden

dabei

auch

die

interaktionsorientierten Aktivitäten mit eingeschlossen, so dass ein Transformationsprozess mit beliebig vielen Quell- und Zielsystemen realisiert werden kann. Der wichtigste Aspekt bei diesem Ansatz ist, dass auch datenflussorientierte Muster in Form von Aktivitäten abgebildet

werden,

wobei

unterschiedliche

Muster

nicht

durch

verschiedene

Parametrisierungen, sondern als unterschiedliche Aktivitäten modelliert werden. Um einen Transformationsprozess vollständig zu beschreiben, sollen auch lokale Variablen, Kompensationen und Fehlerbehandlungen abgebildet werden. Die nachfolgende Abbildung veranschaulicht dies noch einmal.

151

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Abbildung 62:

Der

Vorteil

dieses

Ansatzes

ist

vor

Prozess-Ansatz

allem:

die

gleichzeitige

Kontroll-

und

Datenflussorientierung sowie die Einbeziehung der Interaktion mit externen Systemen. Damit sind alle vorstellbaren Transformationsszenarien modellierbar, wobei eine natürliche Abbildung mit separierten Aktivitäten ermöglicht wird. Allerdings hat dieser Ansatz auch einen schwerwiegenden Nachteil. Während sich bei den zuvor

gehend

dargestellten

Prozessbeschreibungssprachen

Ansätzen, gestützt

auf wurde,

die

direkte sind

bei

Unterstützung diesem

von Ansatz

Spracherweiterungen hinsichtlich der verwendeten Transformationsmuster, welche wiederum auf den Anforderungen der komplexen Nachrichtentransformation beruhen, notwendig. Damit geht die Möglichkeit verloren, existente BPEL-Implementationen nutzen zu können. Zusammenfassend

überwiegen

die Vorteile der

Modellierungsmächtigkeit indem

anforderungsbezogene Transformationsmuster einbezogen werden um den Datenfluss adäquat abzubilden. Auf Grund der Abbildbarkeit jeglicher Transformationsszenarien scheint

dieser

Ansatz

die

geeignete

Wahl

um

das

MTM

mit

einer

Prozessbeschreibungssprache abzubilden. Dienst-Ansatz Mit diesem Ansatz sollen die Vorteile der zuvor beschriebenen Varianten in einem Ansatz

152

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

zusammengeführt werden. Dabei ist davon auszugehen, dass keine Prozessbeschreibungssprache ausreichende Funktionalitäten zur Beschreibung des Datenflusses enthält. Da jedoch

die

direkte

Unterstützung

weiterhin

erhalten

beleiben

soll,

sind

die

Transformationsmuster in separate Transformationsdienste auszulagern. Auf Grund der Verbindung der Vorteile der anderen Ansätze kann dieser auch als „Alternativ-Ansatz“ verstanden werden. Sofern alle datenflussorientierten Muster in separate Dienste ausgelagert werden, ist die vollständige Modellierung eines komplexen Transformationsprozesses als Menge von Dienstaufrufen und kontrollflussorientierten Mustern möglich. In der folgenden Abbildung ist dies schematisch dargestellt.

Abbildung 63:

Die

Vorteile

ergeben

sich

Prozessbeschreibungssprachen,

Dienst-Ansatz

somit

aus

der

direkten

bei

gleichzeitiger

Unterstützung

Abbildbarkeit

durch jeglicher

Transformationsszenarien. Aus diesem Blickwinkel der Modellierung würde zunächst vieles für einen solchen Ansatz sprechen. Aber auch dieser Ansatz bringt einige Nachteile mit sich. So ist die Modellierung sehr unnatürlich, da selbst einfache datenflussorientierte Muster mittels Dienstaufrufen abgebildet werden und somit schnell unüberschaubare Prozesse entstehen können. Der zweite wesentliche Nachteil ist die schlechte Performance. Wird in einem solchen Szenario tatsächlich eine BPEL-Implementation genutzt, resultiert jeder Dienstaufruf im Aufruf

153

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

eines Web-Service, womit natürlich ein immenser Overhead hinsichtlich Datentransfer und Verarbeitung verbunden ist. Da bei der Verarbeitung von datenzentrischen Prozessen in nachrichtenorientierten Systemen, Performance eine Schlüsselrolle einnimmt, wird im Weiteren die Beschreibung von komplexen Nachrichtentransformationen mit WSBPEL 2.0 an Hand des ProzessAnsatzes realisiert. Während der Dienst-Ansatz eine Alternative dazu darstellt, sind der Elementarmuster-Ansatz und der Komplexmuster-Ansatz weitestgehend auszuschließen.

5.2

Beschreibung des Message Transformation Model (MTM) mit WSBPEL

In diesem Teilkapitel soll nun, aufbauend auf der Auswahl des Beschreibungsansatzes, eine konkrete Beschreibung des MTM mit der Prozessbeschreibungssprache WSBPEL vorgeschlagen werden. Hierbei soll ausschließlich diese Prozessbeschreibungssprache in die

Betrachtung

einbezogen

werden,

obwohl

analog

auch

Abbildungen

der

Alternativsprachen realisierbar wären. An dieser Stelle sei bereits auf das Kapitel 6 verwiesen, in welchem unter anderem die praktische Überführung von WSBPEL-Prozessen in das interne Model, in Form des “Process Parsers“ beschrieben wird. Allerdings ist bereits zu erwähnen, dass diese Überführung in mehreren Schritten abläuft. In einem ersten Schritt wird die WSBPELProzessbeschreibung in eine interne XML-Sprache transformiert, welche dem MTM genügt. Diese Überführung von WSBPEL in das interne XML-Format ist folglich der Betrachtungspunkt

dieses

Teilkapitels.

Die

Metagrammatik

dieser

internen

Sprachdefinition wurde als Anhang B beigefügt.

154

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

5.2.1

Beschreibung des konzeptuellen Nachrichtenmodells

Der erste Teil der Abbildung des MTM mit WSBPEL umfasst die Beschreibung des konzeptuellen

Nachrichtenmodells

und

damit

des

statischen

Aspektes

von

Nachrichtentransformationsprozessen. Der exakte Gegenstand dieser Teilbeschreibung ist also die Abbildung der, mit Definition 4.1 eingeführten, Message als Teil des MTM und darauf aufbauend die Beschreibung von Nachrichtenmengen. Prinzipiell muss zunächst die Frage gestellt werden, welche Sprachkomponenten von WSBPEL 2.0 hierfür herangezogen werden können. Betrachtet man sich die, in Abschnitt 3.2.2 dargestellte, Struktur von BPEL-Prozessen, so liegt die Abbildung als Variablen auf der Hand. Derartige Variablen können als WSDL-Nachrichtentypen, einfache und komplexe XML-Schematypen sowie XML-Schemaelemente modelliert werden. Auf Grund der Art der Verwendung derartiger Variablen bietet sich, mit Hinblick auf die prototypische Realisierung, die Abbildung der Message als XML-Schematyp an. An dieser Stelle soll neben dem Typ Message auch der Typ MessageSet eingeführt werden. Dieser Typ begründet sich aus der Funktionalen Anforderung der Verarbeitung von Nachrichtenmengen und ist als eine Liste von elementaren Nachrichten zu verstehen. Die folgende Abbildung zeigt die Darstellung des komplexen XML-Schematyps Message.

Abbildung 64:

XML-Schema Darstellung einer Nachricht

155

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Allgemein betrachtet stellt dieser Schematyp eine XML-Repräsentation des konzeptuellen Nachrichtenmodells dar. Aus diesem Grunde ist auch dessen Struktur aus der Definition 4.1 abgeleitet. So enthält eine Nachricht ein Kopfsegment (header) und ein Datensegment (data). Das Kopfsegment besteht dabei aus einer Reihe von elementaren Attributen. Im Gegensatz dazu setzt sich das Datensegment aus einer Menge von Tupeln (datarows) zusammen, wobei jedes Tupel wiederum eine Menge von Attributen aufweist. Diese Attribute können dabei entweder elementar (attribute) oder selbst wieder ein Datensegment (data) sein. Dieser Aspekt der Abbildbarkeit von rekursiven Strukturen ist dabei eine wichtige Anforderung an die Beschreibung des konzeptuellen Nachrichtenmodells. Letztendlich bleibt nun noch zu klären, wie diese Typen mit Hilfe von WSBPEL zur Beschreibung des statischen Aspektes von Transformationsprozessen eingesetzt werden können. Das folgende XML-Metagrammatik Fragment veranschaulicht dies. ? *

Zusammenfassend ist also festzustellen, dass die Beschreibung des konzeptuellen Nachrichtenmodells mit WSBPEL 2.0 auf Grund der Nutzung von bewährten XMLTechnologien

unproblematisch

ist.

Diese

Beschreibung

des

konzeptuellen

Nachrichtenmodells wird im folgenden Abschnitt wieder aufgegriffen und mit der Beschreibung des konzeptuellen Prozessmodells in Verbindung gesetzt.

5.2.2

Beschreibung des konzeptuellen Prozessmodells

Nach der Beschreibung des konzeptuellen Nachrichtenmodells stellt die Abbildung des konzeptuellen Prozessmodells den zweiten Teil der Beschreibung des MTM mit WSBPEL 2.0 dar. Hierbei ist der dynamische Aspekt von Nachrichtentransformationsprozessen und damit der Schwerpunkt der gesamten Beschreibung, Gegenstand dieses Abschnittes. Um

156

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

etwas genauer zu sein, wird nun also die Abbildung des, im Abschnitt 4.3.3 definierten, Prozesses und der einzelnen Prozessschritte in Form von Mustern in die Betrachtung einbezogen. Die Zielsprache der Überführung ist, wie bereits erwähnt, ein internes XML-Format, welches das MTM realisiert. Da XML generell hierarchisch und damit blockorientiert ist, wird das graphenbasierte MTM, ebenfalls hierarchisch abgebildet. Prinzipiell ist zwar eine vollständige Abbildung möglich, um jedoch den Komplexitätsgrad der internen Verarbeitung nicht unnötiger Weise zu erhöhen, wurde die XML-Repräsentation des MTM um ein Muster – die Iteration, zur Beschreibung von Schleifenkonstrukten – erweitert. Im Weiteren wird nun die Beschreibung des internen Formates mit WSBPEL diskutiert, wobei die bereits eingeführte Unterteilung in Musterkategorien wiederverwendet wird. Prinzipiell ist voranzustellen, dass WSBPEL eine kontrollflussorientierte Sprache ist und somit generell alle interaktionsorientierten und kontrollflussorientierten Muster des MTM unproblematisch beschrieben werden können. Im Gegensatz dazu offenbaren sich jedoch Defizite bei der Abbildung der datenflussorientierten Muster mit WSBPEL. Nachfolgend sollen die einzelnen Musterkategorien im Detail untersucht werden, wobei jedoch nicht auf die Beschreibung jeglicher Elemente sondern vielmehr lediglich auf den Prozess und die einzelnen Aktivitäten eingegangen wird. Die detaillierte Abbildung auf Attributebene wird im Kapitel 6 dann exakt referenziert. Interaktionsorientierte Muster Im MTM werden mit den Mustern Receive, Invoke und Reply die elementarsten interaktionsorientierten Muster verwendet. Im Vergleich dazu weist WSBPEL zusätzliche Aktivitäten auf, welche eine ähnliche Parametrisierung benötigen. Somit können sowohl die Receive als auch die Pick-Aktivität intern als Receive abgebildet werden. Die prinzipielle Beschreibung der interaktionsorientierten Muster wird durch die folgende Tabelle veranschaulicht.

157

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

WSBPEL 2.0

internes XML-Format

Bemerkung

Receive Pick Invoke Reply

Receive

einfaches Mapping ausschließlich ’onMessage’ einfaches Mapping

Invoke Reply

Tabelle 12:

Abbildung der interaktionsorientierten Muster

Um diese WSBPEL-Aktivitäten nutzen zu können müssen PartnerLinkTypes und die von diesen referenzierten WSDL-Dokumente erstellt werden. In diesen Dokumenten wird der definierte XML-Schematyp Message als WSDL-Nachrichtentyp integriert. Kontrollflussorientierte Muster Analog

zu

den

interaktionsorientierten

Mustern

lassen

sich

ebenfalls

alle

kontrollflussorientierten Muster des MTM mit WSBPEL-Aktivitäten beschreiben. Auch hier können teilweise unterschiedliche WSBPEL-Aktivitäten auf die generischen Muster des MTM abgebildet werden. Da das MTM sowohl einen Hauptprozess als auch Subprozesse zulässt, wobei jeweils die Transaktionssicherheit zu gewährleisten ist, können die Process- und Scope-Aktivitäten das Process-Muster

beschreiben.

Hierbei

resultiert

eine

Process-Aktivität

in

einem

Hauptprozess, während die Scope-Aktivität auf einen Subprozess abgebildet wird. Die Muster Switch, Fork und Delay sind stark an WSBPEL angelehnt und können fast direkt übernommen werden. Das Hilfskonstrukt Iteration kann mit den Schleifenkonstrukten While, ForEach und repeatUntil abgebildet werden, da es sowohl kopf- als auch fußgesteuerte Schleifen unterstützt. Das Signal-Muster kann mit Hilfe aller initiierenden Aktivitäten in Form von Throw, Rethrow, Compensate, CompensateScope und Exit dargestellt werden. Die WSBPEL-Konstrukte Sequence und Empty sind hingegen nicht explizit zu beschreiben, da diese implizit in dem Grundmodell, respektive den jeweiligen anderen Mustern enthalten sind. Die folgende Tabelle zeigt noch einmal eine Übersicht der Abbildung aller kontrollflussorientierten Mustern.

158

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

WSBPEL 2.0

internes XML-Format

Bemerkung

Process Scope If Flow Wait While ForEach RepeatUntil Throw Rethrow Compensate CompensateScope Exit Sequence Empty

Process

Kontextabhängige Übernahme mit Kindelementen einfaches Mapping einfaches Mapping einfaches Mapping Prinzipiell auch mit Switch und graphenbasiertem Grundmodell realisierbar. Abbildung aller „initiierenden“ Aktivitäten auf das generische SignalMuster

Tabelle 13:

Switch Fork Delay Iteration Signal

-

implizit in anderen internen Mustern enthalten (Umsetzung kontextbezogen)

Abbildung der kontrollflussorientierten Muster

Datenflussorientierte Muster Im Gegensatz zu den interaktionsorientierten und kontrollflussorientierten Mustern stellt sich die Abbildung der datenflussorientierten Muster ungleich schwerer dar. So werden bis auf die Assign- und Validate-Aktivitäten keinerlei datenflussorientierte Muster angeboten. Allerdings ist unbedingt zu erwähnen, das WSBPEL mit der extensionActivity und der Erweiterbarkeit der Assign-Aktivität, umfassende Erweiterungsmöglichkeiten bereitstellt. Prinzipiell lassen sich dabei drei Ansätze der Beschreibung der datenflussorientierten Muster mit WSBPEL unterscheiden. Zunächst sind diese Ansätze zu diskutieren, bevor dann letztendlich eine Auswahl getroffen wird. •

Nutzung der Assign-Aktivität mit unterschiedlicher Parametrisierung Bei diesem Ansatz wird versucht die Beschreibung jeglicher datenflussorientierter Muster in der Assign-Aktivität zu kapseln. Hierbei sind die verschiedenen Muster mit geeigneten Parametrisierungen voneinander zu unterscheiden.

•

Nutzung der extensionActivity zur Kapselung eigener Elemente Mit diesem Ansatz wird von der Erweiterungsmöglichkeit von BPEL gebrauch

159

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

gemacht, wobei alle datenflussorientierten Muster als Kindelemente der ExtensionActivity verwendet werden. Damit bleibt die Portabilität mit Ausnahme der Erweiterungen erhalten, so dass diese Prozesse mit Einschränkungen auch in anderen Process Engines verwendet werden können. •

Erweiterung des Metamodells von WSBPEL 2.0 Der letzte Ansatz stellt zugleich die wohl schlechteste Variante dar. Hierbei werden für jedes datenflussorientierte Muster neue Aktivitäten definiert und entsprechend genutzt. Obwohl dies der „natürlichste“ Ansatz ist, führt dieser gleichzeitig zu einer Inkonformität in Bezug auf die Sprachspezifikation, weshalb dieser im Weiteren außer Acht gelassen wird.

Letztendlich wurde der Ansatz der Nutzung der extensionActivity zur Beschreibung nahezu aller datenflussorientierten Muster ausgewählt. Dabei ist anzumerken, dass somit zwar die Konformität und Portabilität erhalten bleibt, allerdings derartige Erweiterungen nicht in allgemein verfügbaren Process Designern genutzt werden können. Für die nahe Zukunft ist jedoch zu erwarten, dass diese die Definition eigener „ExtensionActivity-Typen“ ermöglichen und somit dieser Nachteil außer Acht gelassen werden kann. Abschließend bleibt zu erwähnen, dass alternative Abbildungsvarianten vorstellbar wären. So könnte man zum einen wirklich alle datenflussorientierten Muster, einschließlich Assign und Validate, mit der extensionActivity beschreiben. Zum anderen könnten jedoch neben dem Assign auch das Translation-, das Projection- sowie mit Einschränkungen das Selection-Muster als Assign dargestellt werden. Die folgende Tabelle zeigt die allgemeine Abbildung der datenflussorientierten Muster. WSBPEL 2.0

internes XML-Format

Bemerkung

Assign ExtensionActivity/Translation ExtensionActivity/Selection ExtensionActivity/Projection ExtensionActivity/Join ExtensionActivity/Setoperation ExtensionActivity/Split

Assign Translation Selection Projection Join Setoperation Split

einfaches Mapping auch als Assign sinnvoll auch als Assign sinnvoll

160

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

WSBPEL 2.0

internes XML-Format

ExtensionActivity/OrderBy Validate

OrderBy Validate

ExtensionActivity/Action

Action

Tabelle 14:

Bemerkung zusätzliche Nutzung documentation-Element

Abbildung der datenflussorientierten Muster

Zusammenfassend bleibt festzustellen, dass die definierten datenflussorientierten Muster, unabhängig von der hier beschriebenen konkreten Abbildung zwischen WSBPEL und der internen XML-Repräsentation des MTM, in Anlehnung an das Teilkapitel 3.3, als ein Spracherweiterungsvorschlag für WSBPEL unter dem Namen „WSBPEL Extension for Message Transformation (WSBPEL-MT)“ veröffentlicht werden könnten.

5.3

Bewertung von BPEL

In

diesem

Teilkapitel

ist

WSBPEL

2.0,

unter

Einbeziehung

der

Spracherweiterungsvorschläge, einzuschätzen und zu bewerten. Hierbei sind bei der Bewertung jedoch verschiedene Perspektiven in Form von Anwendungsgebieten zu unterscheiden, da die Bewertung dieser Beschreibungssprache natürlich abhängig vom Anwendungskontext der Sprache ist. Hierfür wurden die folgenden Perspektiven identifiziert und in die Betrachtung einbezogen. •

Web-Service-Orchestrierung

•

Geschäftsprozessmodellierung

•

Nachrichtentransformation

Die Perspektive Web-Service-Orchestrierung betrifft das eigentliche Einsatzgebiet von WSBPEL, wofür diese Sprache ursprünglich entworfen wurde. Hierbei ist die zentrale und ausführbare Komposition von Web-Services der Gegenstand. Da sich WSBPEL inzwischen jedoch derart etabliert hat, wird diese Sprache auch in anderen Anwendungsszenarien

161

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

eingesetzt. So adressiert die Perspektive der Geschäftsprozessmodellierung zunächst die abstrakte Ebene der Modellierung von Geschäftprozessen, mit der Möglichkeit diese durch Anreichungen in ausführbare Prozesse zu überführen. Diese beiden Perspektiven stellen die Hauptanwendungsgebiete von WSBPEL dar. Allerdings sind auch speziellere Perspektiven zu berücksichtigen. So ist die Perspektive der Nachrichtentransformation eher als Zweckentfremdung von WSBPEL zu verstehen. Die Nachrichtentransformation beschreibt hierbei unterschiedliche Integrationsszenarien, wobei der Schwerpunkt auf datenzentrischen Prozessen liegt. Ein Beispiel hierfür ist unter anderem der ETL-Prozess. Diese Perspektive hat im Gegensatz zu den zuvor genannten Perspektiven, höhere Anforderungen an die Modellierung des Datenflusses. Prinzipiell sind jedoch noch weitere Perspektiven vorstellbar. So ist der Einsatz von WSBPEL überall dort vorstellbar, wo Ablauflogik inklusive Abhängigkeiten abgebildet werden soll. Ein Beispiel hierfür wäre die Simulation von betrieblichen Prozessen, wobei vor allem der Aspekt der parallelen Verarbeitung in den Vordergrund zu rücken wäre. Im Rahmen dieses Teilkapitels sollen zunächst ganz allgemein Bewertungskriterien eingeführt und diskutiert werden. Anschließend erfolgt eine Einschätzung von WSBPEL hinsichtlich der einzelnen Kriterien. Diese Einschätzung bildet die Grundlage für die Bewertung von WSBPEL hinsichtlich der hier vorgestellten Perspektiven. 5.3.1

Bewertungskriterien

Für eine fundierte Bewertung von WSBPEL aus den unterschiedlichen Perspektiven sind zwangsläufig allgemeine Bewertungskriterien für Prozessbeschreibungssprachen zu definieren. Diese Kriterien sollen das Rahmenwerk für die Einschätzung von WSBPEL bilden. Um die Übersichtlichkeit zu wahren und das Verständnis zu erhöhen, werden zunächst Gruppen von Bewertungskriterien eingeführt und anschließend beschrieben. Die folgende Auswahl wurde hierbei getroffen.

162

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

•

Beschreibungskriterien

•

Modellierungsmöglichkeiten der Interaktion

•

Modellierungsmöglichkeiten des Kontrollflusses

•

Modellierungsmöglichkeiten des Datenflusses

•

Qualitätskriterien

Die Gruppe der Beschreibungskriterien fasst dabei all jene Kriterien zusammen, welche die Art

der

Prozessdefinition

Modellierungsmöglichkeiten Kategorien:

Interaktion,

charakterisieren.

umfassen

alle

Kontrollfluss

Die

funktionalen und

drei Kriterien

Datenfluss.

Die

Gruppen

der

der jeweiligen Gruppen

von

Bewertungskriterien werden letztendlich durch die Gruppe der Qualitätskriterien komplettiert, welche alle nicht-funktionalen Kriterien einschließt. Die folgende Tabelle gibt nun einen Überblick über die elementaren Kriterien der einzelnen Gruppen. Kriteriengruppe

Kriterium

Beschreibung

Beschreibungskriterien

Notation Art der Prozessbeschreibung Abstraktionsgrad / Granularität

grafisch | XML | formal hierarchisch | graphenbasiert Komplexität und Detaillierungsgrad der Beschreibung sprachorientiert | anforderungsorientiert Schachtelung von Prozessen und Teilprozessen möglich? Bietet die Sprache Erweiterungsmöglichkeiten? initiierendes Receive (R1), nicht-initiierendes Receive (R2), Request-Response-Invoke (I1) und Request-Invoke (I2) Reply (RE) Unabhängigkeit der Interaktion von Diensttyp und Ort Werden die Aspekte sauber getrennt oder miteinander vermischt? Abbildung von Folgen

Orientierung der Beschreibung Strukturierbarkeit / Modularisierbarkeit Erweiterbarkeit Modellierungsmöglichkeiten der Interaktion

Unterstützung der fünf grundlegenden Interaktionsmuster Kommunikation mit externen Partnern Trennung zwischen Interaktion und Verarbeitung Sequenz

163

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Kriteriengruppe

Kriterium

Beschreibung

Modellierungsmöglichkeiten des Kontrollflusses

Sequenz Alternative Iteration Parallelverarbeitung Ereigniskonzept

Abbildung von Folgen Abbildung von Entscheidungen Schleifen Abbildung paralleler Prozesse Beschreibung von Ereignissen/Signalen und entsprechenden Handlern Einflussnahme der Daten auf den Kontrollfluss Verarbeitung von Daten mit unterschiedlichen Datenmodellen gleichzeitige Verarbeitung von mehreren Datenobjekten einfache Wertzuweisungen zu Attributen Unterstützung von elementaren Dokumenttransformationen Überprüfung der Daten hinsichtlich Bedingungen Standardtreue der Produkte und Fortschritte der Standardisierung Etablierung der Sprache / Marktdurchdringung Entwurfsbezogene Einschätzung des Leistungsverhaltens Geringer Änderungsaufwand bei Wechsel von Produkten Mehrfachverwendung von Prozessen und Teilprozessen Analysierbarkeit von Prozessen auf Grundlage einer formalen Spezifikation Unabhängigkeit der Prozessbeschreibung von eigentlichen Verarbeitung des Prozesses

Modellierungsmöglichkeiten des Datenflusses

Content Based Routing Umgang mit unterschiedlichen Datenrepräsentationen Umgang mit Datenmengen elementare Zuweisungen elementare Transformationen Datenvalidierungen Standardisierung Unterstützung durch die Industrie Performance Portabilität Wiederverwendbarkeit Analysierbarkeit (Verifikation) Unabhängigkeit von der Implementierung

Tabelle 15:

Allgemeine Bewertungskriterien von Prozessbeschreibungssprachen

Die hiermit eingeführten Kriterien stellen die Grundlage für die folgende Bewertung von WSBPEL dar. Dabei können diese allgemeinen Kriterien jedoch auch zum Vergleich von WSBPEL mit alternativen Prozessbeschreibungssprachen eingesetzt werden.

164

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

5.3.2

Bewertung aus unterschiedlichen Perspektiven

Im Rahmen dieses Abschnittes soll zunächst WSBPEL 2.0 auf Grundlage der definierten Bewertungskriterien eingeschätzt werden. Anschließend ist diese Einschätzung dann einzusetzen um eine Bewertung aus unterschiedlichen Perspektiven vornehmen zu können. Zusammenfassend sollen danach die wesentlichsten Vorteile und Nachteile von WSBPEL in einer SWOT-Analyse gegenüber gestellt werden, bevor letztendlich eine Aussage hinsichtlich der Eignung zur Beschreibung der komplexen Nachrichtentransformation getroffen wird. Die Einschätzung von WSBPEL basiert dabei exakt auf den zuvor definierten Kriterien. Die folgende Tabelle zeigt die Einschätzung von WSBPEL 2.0, wobei die Spracherweiterungsvorschläge bereits in die Betrachtung mit einbezogen wurden. Kriteriengruppe

Kriterium

Einschätzung

Beschreibungskriterien

Notation Art der Prozessbeschreibung

XML hierarchisch (teilweise graphenorientiert) hohe Komplexität und Detaillierungsgrad sprachorientiert Schachtelung von Prozessen nur mit WSBPEL-SPE ja, sehr gut integriert ja, alle Muster abbildbar

Abstraktionsgrad / Granularität

Modellierungsmöglichkeiten der Interaktion

Modellierungsmöglichkeiten des Kontrollflusses

Orientierung der Beschreibung Strukturierbarkeit / Modularisierbarkeit Erweiterbarkeit Unterstützung der fünf grundlegenden Interaktionsmuster Kommunikation mit externen Partnern Trennung zwischen Interaktion und Verarbeitung Sequenz Alternative Iteration Parallelverarbeitung Ereigniskonzept Content Based Routing

ja, in der Regel gegeben, jedoch nicht bei BPELJ ja ja (sequence) ja (if) ja (while, foreach,repeatuntil) ja (flow) ja (throw, compensate, exit, ...) ja, mit XPath möglich

165

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Kriteriengruppe

Modellierungsmöglichkeiten des Datenflusses

Kriterium

Einschätzung

Content Based Routing

ja, mit XPath möglich

Umgang mit Datenmengen unterschiedlichen Datenrepräsentationen elementare Zuweisungen elementare Transformationen

nein, jedoch nur XML beliebige (mit II4BPEL XMLteilweise Typen nutzbar gegeben) ja, mit XPath möglich ja, jedoch Beschränkung auf XSLT ja (validate) gut, seit WSBPEL2.0 durch gezielte Erweiterungsmöglichkeit sehr gut (vgl. Einleitung Kapitel 3)

Datenvalidierungen Standardisierung Unterstützung durch die Industrie Performance Portabilität Wiederverwendbarkeit Analysierbarkeit (Verifikation) Unabhängigkeit von Implementierung Tabelle 16:

schlechte “performance by design” relativ gut, bei Verzicht auf Erweiterungen sehr gut, durch rekursive Definition als Web-Service keine formale Analysierbarkeit gegeben gegeben bei Verzicht auf Spracherweiterung

Einschätzung von WSBPEL

Nachdem WSBPEL hinsichtlich der einzelnen Kriterien eingeschätzt wurde, kann nun die tatsächliche Bewertung in Bezug auf die unterschiedlichen Perspektiven erfolgen. •

Web-Service-Orchestrierung WSBPEL ist prinzipiell sehr gut für die Orchestrierung geeignet, da sie ausreichend detailliert ist und alle Modellierungsaspekte für die satzorientierte Verarbeitung von funktional getriebenen Prozessen aufweist. Als Hauptvorteil auf diesem Gebiet ist die rekursive Komposition zu einem Web-Service zu nennen. Durch die XMLNotation und die blockorientierte Beschreibungsart ist WSBPEL für eine automatisierte Verarbeitung geschaffen.

•

Geschäftsprozessmodellierung Im Gegensatz zu der Perspektive der Web-Service-Orchestrierung offenbaren sich aus der Perspektive der Geschäftsprozessmodellierung noch Defizite. Der

166

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

Hauptkritikpunkt ist die hohe Komplexität und fehlende Modularisierbarkeit. Diesem wird zwar durch die Definitionsmöglichkeit von abstrakten Prozessen und der Spracherweiterung WSBPEL-SPE entgegen getreten, kann diese jedoch nicht vollständig beheben. Ein weiterer Kritikpunkt ist die, durch die XML-Notation begründete, blockorientierte Beschreibungsart. So ist an dieser Stelle die grafische Notation BPMN in Verbindung mit der Generierung von WSBPEL-Prozessen zu empfehlen. •

Nachrichtentransformation Während bei den beiden zuvorgehenden Perspektiven, die Modellierungsmöglichkeiten hinsichtlich des Kontrollflusses essentiell waren, muss bei dieser Perspektive auch die Betrachtung des Datenflusses mit einbezogen werden. So kann prinzipiell eingeschätzt werden, dass WSBPEL auf der einen Seite sehr umfangreiche Möglichkeiten aufweist den Kontrollfluss zu modellieren, jedoch auf der anderen Seite Defizite bei der Modellierung des Datenflusses hat. Damit ist eine Abbildung der komplexen Nachrichtentransformation mit WSBPEL allein nicht möglich. Bezieht man jedoch Spracherweiterungen wie ii4BPEL oder die selbst definierte WSBPEL-MT mit ein, kommt man zu dem Schluss, dass WSBPEL vor allem durch die umfassenden Erweiterungsmöglichkeiten auch für die Modellierung von

datenzentrischen

Prozessen

im

Rahmen

der

komplexen

Nachrichtentransformation geeignet ist. Aufbauend auf der Einschätzung und den unterschiedlichen Bewertungen, sollen im Weiteren die Vorteile und Nachteile von WSBPEL in einer SWOT-Analyse zusammengefasst werden. Im Rahmen dieser Analyse sind die Stärken (Strength), Schwächen

(Weaknesses),

Chancen

(Opportunities)

und

Risiken

(Threats)

des

Sprachstandards WSBPEL. 2.0 gegenüber zu stellen.

167

5 Beschreibung von Nachrichtentransformationen mit WSBPEL

positiv

negativ

Strengths Eintreten

Weaknesses

•

sehr gute Standardisierung

•

schlechte „performance by design“

•

rekursive Verwendung als Web-

•

hohe Komplexität / hoher

gewiss

Service

Detaillierungsgrad

•

prinzipiell gute Portabilität

•

•

Abbildung des Kontrollflusses

•

Erweiterbarkeit

Abbildung des Datenflusses

Threats

Opportunities

•

Eintreten

•

große Produktauswahl

ungewiss

•

Spracherweiterungen für

Verwendung von Erweiterungen

Spezialprobleme Abbildung 65:

schlechte Portabilität bei

•

Sicherheitsaspekte

•

Transaktionssicherheit

SWOT-Analyse WSBPEL 2.0

Zusammenfassend ist die Aussage zu treffen, dass WSBPEL zur Beschreibung komplexer Nachrichtentransformationen geeignet ist. Dies wird dadurch erreicht, dass WSBPEL bereits

kontrollflussorientiert

ist

und

somit

alle

interaktionsorientierten

und

kontrollflussorientierten Muster des MTM unproblematisch abgebildet werden können. Das Fehlen von geeigneten datenflussorientierten Aktivitäten in WSBPEL wird vor allem durch die umfassende Erweiterbarkeit des Sprachstandards kompensiert.

168

6 Prototypische Realisierung am Beispiel von TransConnect

6

Prototypische Realisierung am Beispiel von TransConnect

Auf Grundlage der theoretischen Betrachtungen der zuvorgehenden Kapitel wird nun eine prototypische Realisierung der diskutierten Konzepte und Modelle beschrieben, um deren Anwendbarkeit in praktischen Szenarien nachzuweisen. Das folgende Zitat soll noch einmal die Notwendigkeit eines solchen Nachweises verdeutlichen. „Bedenke, dass Du zu jeder Erkenntnis ihre Nutzanwendung setzen musst, damit die Wissenschaft nicht unnütz sei.“ Leonardo da Vinci, entnommen aus [REBE06] Die Realisierung soll dabei am Beispiel des Produktes TransConnect durchgeführt werden. Da die aktuelle TransConnect-Version 1.3.4 respektive 1.3.5 hierfür allerdings hätte grundlegend überarbeitet werden müssen, ist die Entscheidung gefallen, dass die Ergebnisse dieser Arbeit direkt in TransConnect 2.0, fortan TC2 genannt, einfließen sollen. Somit ist das Ziel, der hier beschriebenen Realisierung, die prototypische Implementierung des EAI-Servers TC2, wobei der Schwerpunkt vor allem auf der Umsetzung des MTM im Rahmen einer so genannten Workflow Process Engine (WFPE) liegt. Zunächst soll hierbei ein Vorschlag für den Entwurf von TC2 und dessen Teilkomponenten unterbreitet, diskutiert und anschließend näher erläutert werden. Danach ist die Implementierung des beschriebenen Entwurfes etwas genauer dargestellt. Dabei werden ausgewählte Verarbeitungskonzepte herausgegriffen und im Detail diskutiert. Abschließend soll die Beschreibung von komplexen Nachrichtentransformationen und die Anwendung von TC2 an einem komplexen Beispielszenario veranschaulicht werden.

6.1

Entwurf

Im Rahmen dieses Kapitels ist ein Vorschlag für den Entwurfes von TC2 zu unterbreiten.

169

6 Prototypische Realisierung am Beispiel von TransConnect

Hierbei werden die Teilkomponenten und deren Zusammenspiel auf einer abstrakten Ebene dargestellt. Zunächst sind nun die Teilkomponenten von TC2 und die zu Grunde liegenden Systeme zu identifizieren sowie voneinander abzugrenzen. TC2 gliedert sich im Wesentlichen in die drei Teilkomponenten TransConnect Manager, TransConnect Server sowie den TransConnect DataStore und realisiert dabei eine 3-Tier-Architektur. Die Differenzierung der Teilkomponenten wird durch die folgende Abbildung veranschaulicht.

Abbildung 66:

Teilkomponenten von TransConnect 2.0

Der TransConnect Manager bildet die Ebene der Präsentation ab. Diese Teilkomponente gestattet die Konfiguration, Verwaltung, Steuerung und das Monitoring der anderen Teilkomponenten. Die Grundlage für dessen Realisierung stellt das Eclipse-Framework dar. Im Rahmen dieses Managers soll auch ein BPEL-Designer als Eclipse-Plugin integriert werden. Die Geschäftslogik von TransConnect wird durch die Teilkomponente TransConnect Server abgebildet. Dieser Server kann prinzipiell als eigenständiger Server betrachtet werden, der allerdings auch in einen Application Server eingebettet werden könnte. Ein solcher Application Server wird jedoch vor allem für die webbasierten Anwendungen der Administration benötigt. Dabei wird ein hoher Grad der Portabilität hinsichtlich des

170

6 Prototypische Realisierung am Beispiel von TransConnect

Application Servers angestrebt. Die zu verwaltenden Daten werden in der Teilkomponente TransConnect DataStore abgebildet. Dieser unterteilt sich in einen Operational DataStore (ODS), in dem sich häufig ändernde Daten verwaltet werden, und in ein MetaData Repository (MDR), indem selten zu ändernde Metadaten vorgehalten werden. Auch hierbei wird die Unabhängigkeit von bestimmten DBMS fokussiert. Im Weiteren befasst sich diese Arbeit explizit nicht mit der Teilkomponente TransConnect Manager. Auch die Anwendungen der Administration werden weiterhin nicht mehr in die Betrachtung einbezogen. Die folgenden Abschnitte dieses Teilkapitels diskutieren folglich die Teilkomponenten TransConnect Server und TransConnect DataStore. Letztendlich sollen bereits an dieser Stelle Maßnahmen zur Qualitätssicherung definiert und damit kurz auf die TransConnect TestSuite eingegangen werden. 6.1.1

Architekturentwurf TransConnect 2.0 Server

Die Teilkomponente TransConnect Server ist die Hauptkomponente des gesamten TC2. In diesem Abschnitt soll nun ein Architekturvorschlag für diesen Server unterbreitet werden, welcher sich teilweise an bewährten Konzepten der Vorgängerversionen orientiert, aber vor allem auch grundlegend neue Ansätze integriert. Ein solcher Ansatz ist die Einführung der Prozessorientierung, in Form einer Workflow Process Engine. Hierbei ist der Architekturentwurf des Servers sehr stark davon abhängig, wie der Einflussbereich dieser Process Engine definiert wird. Aus diesem Grunde ist der Diskussion des konkreten Architekturentwurfes die Betrachtung von unterschiedlichen Ansätzen voranzustellen, wie die Prozessorientierung prinzipiell in den TransConnect Server eingebettet werden könnte. Hierzu wird ein einfaches Basismodell zu Grunde gelegt, welches im Wesentlichen aus Inbound- und Outbound-Adaptern, einem Dispatcher, MessageQueues und natürlich den eigentlichen Workflows besteht. Prinzipiell lassen sich drei verschiedene Ansätze der Integration der Prozessorientierung identifizieren. Der Erste Ansatz geht davon aus, dass ein Workflow lediglich die Transformation von Nachrichten in Bezug auf einen konfigurierten Outbound-Adapter

171

6 Prototypische Realisierung am Beispiel von TransConnect

realisiert. Dies stellt die Minimalvariante dar, wobei diese durchaus mit dem Entwurfsmuster „Message Channel“ nach [HOH04a] vergleichbar ist. Hierbei ist ein Zugriff auf mehrere Outbound-Adapter aus einem Workflow nicht möglich, womit auch das Nachladen von Daten nicht realisierbar wäre. Die folgende Abbildung visualisiert den Kernaspekt dieses Ansatzes noch einmal.

Abbildung 67:

Adapterspezifische Workflow-Integration

Der zweite Ansatz erweitert den ersten Ansatz um die Annahme, dass ein Workflow auf beliebig viele Outbound-Adapter zugreifen kann. Außerdem wird der Workflow nicht durch Übergabe einer Nachricht aktiviert, sondern liest bei der asynchronen Verarbeitung die Nachrichten aus der MessageQueue. Damit kann ein Workflow beliebig viele Nachrichten verarbeiten, welche von unterschiedlichsten Inbound-Adaptern empfangen worden sein können. Auch dieser Ansatz soll noch einmal mittels einer Abbildung veranschaulicht werden.

Abbildung 68:

Workflow zwischen MessageQueue und Outbound-Adaptern

Der dritte Ansatz stellt in diesem Zusammenhang den Maximalansatz dar. Hierbei wird davon ausgegangen, dass ein Workflow direkt mit beliebig vielen Inbound-Adaptern und beliebig vielen Outbound-Adaptern interagiert. Außerdem wird eine MessageQueue hier nicht

mehr

als

dynamisches

Element

angesehen,

sondern

als

einfaches

172

6 Prototypische Realisierung am Beispiel von TransConnect

Synchronisationselement, welches an unterschiedlichen Stellen des Workflows genutzt werden kann. Bei diesem Ansatz könnte man völlig auf den Dispatcher verzichten und alle Transformationsprozesse als Teilprozesse eines Hauptprozesses definieren. Der Vorteil eines solchen Ansatzes wäre, dass die komplette Konfiguration als Workflow-Prozess beschreibbar wäre. Die folgende Abbildung zeigt diese noch einmal.

Abbildung 69:

Workflow zwischen Inbound- und Outbound-Adaptern

Letztendlich bleibt nun, die Auswahl eines Ansatzes für den Architekturentwurf des TransConnect Server zu treffen. Im Weitern soll der Ansatz zwei verfolgt werden. Dies ist mit der potentiell guten Performance bei gleichzeitig sehr hoher Modellierungsflexibilität zu begründen. Außerdem spricht die Anlehnung an die Architektur des TransConnect 1.3.x Servers ebenfalls für diesen Ansatz. Wie bereits erwähnt ist der Architekturentwurf des TC2 Servers stark mit der soeben getroffenen Auswahl korreliert. Auf diesen Architekturentwurf wird im Weiteren detaillierter eingegangen. Zunächst soll der Gesamtentwurf des Servers dargestellt und beschrieben werden, bevor anschließend die jeweiligen Teilkomponenten in die Betrachtung

mit

aufgenommen

werden.

Die

folgende

Abbildung

zeigt

diesen

Gesamtentwurf.

173

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 70:

Architekturentwurf TransConnect 2.0 Server

Die einzelnen Bestandteile dieses Architekturentwurfes sollen zunächst überblicksartig beschrieben werden, bevor die wichtigsten im Einzelnen detaillierter zu betrachten sind. Der TransConnect Server bietet eine Reihe so genannter „Inbound Adapter“ an, welche passiv auf eingehende Nachrichten warten, diese in das interne Format überführen und anschließend an den Dispatcher weiterleiten. Die Inbound-Adapter können nach der Verarbeitung der Nachricht optional eine Ergebnisnachricht zurückgeben. Der Dispatcher verteilt die eingehenden Nachrichten nun entsprechend lokal definierter Metadaten indirekt auf MessageQueues, respektive direkt auf bestimmte Prozesse, welche durch die so genannte Workflow Process Engine (WFPE) verwaltet werden. Eine direkte Weiterleitung an die WFPE impliziert dabei eine synchrone Verarbeitung, während die indirekte Weiterleitung über MessageQueues eine asynchrone Verarbeitung ermöglicht. Als Alternative zu den Inbound-Adaptern, können Prozesse der WFPE auch zeitgesteuert mittels des Schedulers initiiert werden. Die WFPE selbst ermöglicht die Überführung von Prozessbeschreibungen in eine ausführbare Form und verwaltet deren Verarbeitung. Dabei schließt diese Verarbeitung auch den Aufruf von Diensten in Form von Outbound-Adaptern und lokalen Diensten, wie beispielsweise die MessageQueue, ein. Die soeben genannten Outbound-Adapter ermöglichen eine aktive Interaktion mit anderen Systemen. Hierbei kann sowohl lesend (pull) als auch schreibend (push) auf die Fremdsysteme zugegriffen

174

6 Prototypische Realisierung am Beispiel von TransConnect

werden. Im Gegensatz zu den Inbound-Adaptern wird die Interaktion dabei stets vom TransConnect Server initiiert. Da die Inbound- und Outbound-Adapter Nachrichten und Daten der Fremdsysteme in interne

Nachrichten

überführen

und

somit

durch

das

definierte

konzeptuelle

Nachrichtenmodell beeinflusst werden, sollen im Weiteren die Inbound- und OutboundAdapter mit in die detaillierte Betrachtung aufgenommen werden. Um das Verständnis für die unterschiedlichen Adapterformen zu erhöhen, werden deren wesentliche Charakteristika durch die folgende Abbildung nebeneinandergestellt.

Abbildung 71:

Adapterformen in TransConnect 2.0

Der Hauptaspekt der Inbound-Adapter ist, dass diese passiv agieren und lediglich Nachrichten empfangen können. In der Regel werden diese Adapter innerhalb von PushInteraktionen eingesetzt. Allerdings darf auch die Pull-Interaktion nicht vernachlässigt werden, da dies die Grundlage dafür bildet, dass TransConnect unter anderem auch als Basis für Portallösungen eingesetzt werden kann. Während die Client-Interfaces selbstdefinierte und –realisierte Schnittstellen darstellen und vorrangig auf bewährten Protokollen basieren, können die System Listener sowohl Realisierungen proprietärer Schnittstellen als auch eigene „Teilserver“ darstellen. Im Gegensatz zu den Inbound-Adaptern agieren die Outbound-Adapter stets aktiv. Allerdings können auch diese sowohl Daten schreiben als auch lesen. Die OutboundAdapter realisieren dabei das Common Client Interface (CCI), so dass diese mit

175

6 Prototypische Realisierung am Beispiel von TransConnect

Einschränkungen unabhängig von ihrem speziellen Adaptertyp in TransConnect verwendet werden können. Auf eine detailliertere Erläuterung des Aufbaus der Outbound-Adapter soll an dieser Stelle verzichtet werden, da deren Konzept aus TransConnect 1.3.x übernommen wurde. Auf Grundlage des einführend gewählten Ansatzes der Workflowintegration kann festgestellt werden, dass aus einem Workflow zwar auf beliebige OutboundAdapter jedoch auf keine InboundAdapter zugegriffen werden kann. Abschließend bleibt zu erwähnen, dass mit dem TransConnect-Listener und dem TransConnect-Adapter bereits die Voraussetzung für eine Interaktion von TransConnect-Instanzen und damit für die Ausführung von verteilten Prozessen geschaffen wurde. Eine besondere Bedeutung kommt der Realisierung des konzeptuellen Nachrichtenmodells als Teil des definierten MTM zu. So wird die interne Nachrichtenabbildung von nahezu allen Teilkomponenten des TransConnect Servers genutzt. Die Inbound- und OutboundAdapter überführen beliebige Datenrepräsentationen der Fremdsysteme auf syntaktischer Ebene und damit innerhalb der Transformationsebenen 0 und 1, in die interne Nachrichtenrepräsentation. Alle Datentransformationen in dem TransConnect Server, gleich ob auf syntaktische oder semantischer Ebene, werden dann ausschließlich auf der internen Nachrichtenrepräsentation durchgeführt. Die folgende Abbildung visualisiert das angesprochene Message Konzept.

Abbildung 72:

Message Konzept

Eine weitere Teilkomponente, die hierbei beachtet werden sollte, ist die MessageFactory.

176

6 Prototypische Realisierung am Beispiel von TransConnect

Ausschließlich mit dieser Komponente können Nachrichtenkörper erzeugt werden. Damit ist diese auch die geeignete Stelle für eine zentrale Schlüsselverwaltung. Der MessageDataConverter Standardrepräsentationen

bietet in

Funktionalitäten das

interne

zur

effizienten

Nachrichtenformat

Überführung

und

deren

von

inversen

Operationen. Prinzipiell soll an dieser Stelle noch einmal betont werden, dass die rekursive Schachtelung der

MessageDataTable-Typen

die

Voraussetzung

dafür

darstellt

beliebige

Datenrepräsentationen abbilden zu können. Während dieser Datenbereich alle Nutzdaten inne hat, wird der Kopfbereich der Nachricht ausschließlich für TransConnect-spezifische Daten verwendet, wobei eine Reihe von Standardattributen persistent verwaltet werden, während alle optional beigefügten Attribute ausschließlich transient vorzuhalten sind. Nachdem nun der Realisierungsentwurf des konzeptuellen Nachrichtenmodells aufgezeigt wurde ist im Schwerpunkt dieses Abschnittes die Realisierung des konzeptuellen Prozessmodells des MTM zu diskutieren. Wie eingangs bereits erwähnt, wird dieses durch die Workflow Process Engine (WFPE) realisiert, weshalb an dieser Stelle deren Entwurf mit in die Betrachtung aufgenommen werden soll. Die WFPE besteht im Wesentlichen wiederum aus vier Teilkomponenten: die Core-Engine, den Process Parser, das Service Dictionary sowie die Runtime Environment. Die Teilkomponente Core-Engine definiert dabei die Schnittstelle zur gesamten Process Engine und realisiert diese Schnittstelle. Dabei nutzt sie die drei übrigen Teilkomponenten. Da die Core-Engine somit den zentralen Teil der Process Engine bildet, soll deren Aufbau stellvertretend herangezogen werden um den Gesamtaufbau der WFPE zu beschreiben. Die folgende Abbildung zeigt diesen Aufbau.

177

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 73:

Entwurf WFPE: Aufbau der Core Engine

Wie durch die Abbildung verdeutlicht setzt sich die Schnittstelle der WFPE zum einen aus der eigentlichen Schnittstellendefinition IProcessEngine und der ProcessEngineFactory zusammen. Die Factory wird hierbei zum Zugriff auf die Schnittstellenrealisierung genutzt, so dass die aufrufende Stelle keine Informationen über die Realisierung benötigt. Dies ermöglicht letztendlich den änderungsfreien Austausch der Process Engine. Der Process Parser wird zur Überführung von externen Prozessbeschreibungen in interne, ausführbare Prozesstypen eingesetzt. Eine der Grundforderungen an diesen Process Parser war die Unabhängigkeit von konkreten Beschreibungssprachen, um zum einen unterschiedlichste Prozessbeschreibungssprachen unterstützen zu können und zum anderen eine effizient ausführbare Prozessdefinition zu erzeugen, welche dem Anforderungsprofil des TransConnect Servers genügt. Aus diesem Grunde weist der Process Parser eine logische Stratifizierung in vier Ebenen auf, wobei jede Ebene einen wohl definierten Teilschritt der Überführung realisiert. An dieser Stelle sei am Rande auf die Analogie zur Verarbeitung von SQL-Anfragen nach [SACL79] verwiesen. Um eine möglichst hohe Flexibilität bei der Prozessdefinition zuzulassen und ein umfassendes Monitoring zu ermöglichen, wird die Parser Architektur „offen“ gestaltet. Dies meint, dass zum einen die Ergebnisse jeder Parser-Ebene einsehbar sind und zum andern, dass das Parsing wahlfrei auf jeder Ebene begonnen werden kann. Die folgende Abbildung veranschaulicht die soeben beschriebene logische Stratifizierung des Process Parsers.

178

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 74:

Entwurf WFPE: logische Stratifizierung des Process Parser

Nachdem die Ebenen des Process Parser nun überblicksartig dargestellt wurden, sollen diese genauer beschrieben werden. Die Ebene eins realisiert die Abbildung von externen Prozessbeschreibungen auf die interne XML-Prozessbeschreibung. Bei XML-basierten Prozessbeschreibungssprachen kann dies mit einer einfachen XSL-Transformation bewerkstelligt werden. So wird beispielsweise ein XSLT-Skript benötigt, welches die in Abschnitt 5.2.2 beschriebenen Abbildungen zwischen BPEL und der internen Darstellung realisiert. Die Konsequenz aus dieser Parser-Ebene ist, dass die Abhängigkeit von externen Beschreibungssprachen auf ein Mindestmaß reduziert wurde, indem pro unterstützter externer Sprache lediglich ein spezifisches XSLT-Skript zu erstellen ist. Im Rahmen der Ebene der internen Analyse und Optimierung wird die interne XMLProzessbeschreibung zunächst analysiert und bei einem erfolgreichen Abschluss der Analysephase derart transformiert, dass eine „optimale“ Prozessbeschreibung das Ergebnis dieser Ebene ist. Die Analyse erfolgt dabei, wie im Abschnitt 4.4.1 beschrieben, regelbasiert. Anschließend wird die Optimierung ausgeführt, welche sich wiederum in zwei Phasen untergliedert. In der ersten Optimierungsphase werden regelbasierte Optimierungen der Prozessbeschreibung vorgenommen. So sind beispielsweise zwei aufeinander folgende

179

6 Prototypische Realisierung am Beispiel von TransConnect

XSLT-Translationsschritte zu einem Schritt zusammenzufassen, der eine so genannte TwoPhase-Transformation kostenbasierte

durchführt.

Optimierung

auf

Die

zweite

Grundlage

des

Optimierungsphase in

Abschnitt

adressiert

4.4.2

die

definierten

Kostenmodells. Dabei werden für Varianten der Prozessbeschreibung die Kosten entsprechend den festgelegten Gewichtungen bewertet und die „optimalste“ Variante ausgewählt. Die Ebene drei stellt die Java Generierung dar. Hierbei werden aus der internen XMLProzessbeschreibung Java-Klassen generiert. Um die Änderbarkeit zu realisieren, weist dieser Java-Generator einen template-basierten Ansatz auf. So werden beispielsweise Templates für den Prozess und die einzelnen Prozessschritte erstellt. Diese weisen nun Platzhalter für Parameter und Subtemplates auf. Die Vorgehensweise des Generators ist es nun rekursiv die XML-Prozessbeschreibung zu iterieren und die entsprechenden Daten zu extrahieren. Diese Daten ersetzen nun die Parameter in den einzelnen Templates. Nachdem alle Platzhalter ersetzt wurden, kann die Klasse physisch gesichert werden. Wichtig ist, dass jede generierte Klasse von der abstrakten Superklasse ProcessPlan abgeleitet wird und somit als Thread einsetzbar ist. Die Beeinflussung des Generators soll, in Anlehnung an [ALFI06], mit Hilfe von Hints ermöglicht werden. An dieser Stelle sei lediglich eine Auswahl derartiger Hints genannt, welche in diesem Kontext sinnvoll und realisierbar sind. •

STREAM_DATA

•

JOIN-ALGORITHM

•

DEFAULT_PARSE_MESSAGES

•

MERGE_MESSAGES

•

NO_PARALLEL_FLOW

•

MATERIALIZED_DATA

•

LOCAL_STORE_DATA

In der abschließenden Ebene 4 wird letztendlich eine Objektinstanziierung realisiert. Dazu wird die Java-Klasse zunächst kompiliert und in die JVM geladen. Danach kann ein neues Objekt des ProzessPlanes erzeugt werden. Nachdem die Objektinstanziierung das erste Mal

180

6 Prototypische Realisierung am Beispiel von TransConnect

erfolgt ist, können neue Objekte des ProzessPlanes sehr effizient durch die einfache Objektinstanziierung

erstellt

werden.

Um

die

Betrachtung

des

ProcessParsers

abzuschließen, visualisiert die folgende Abbildung dessen Aufbau.

Abbildung 75:

Entwurf WFPE: Aufbau des Process Parser

Die zweite zu betrachtende Teilkomponente der WFPE ist das Service Dictionary. Diese Teilkomponente stellt ein Verzeichnis für Dienste innerhalb des TransConnect dar, welche aus dem Workflow heraus genutzt werden. Dabei werden Instanzen konfigurierter Objekte vorgehalten, wie beispielsweise ein konfigurierter JDBCAdapter mit all dessen Verbindungseinstellungen. Prinzipiell müssen alle vorgehaltenen Dienste die einheitliche Schnittstelle IService realisieren. Dies kann entweder direkt oder mit Hilfe eines Wrappers geschehen. Der WSDLGenerator des Service Dictionary kann nun dazu genutzt werden, für alle ServiceTypen WSDL-Dokumente zu generieren. Diese Generierung ist notwendig um eine Modellierung in einem Process Designer zu ermöglichen. Die folgende Abbildung zeigt den beschriebenen Aufbau des ServiceDictionary noch einmal.

181

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 76:

Entwurf WFPE: Aufbau des ServiceDictionary

Auf Grundlage der Tatsache, dass alle Dienstaufrufe aus jeglichen Workflows über dieses Service Dictionary erfolgen, stellt es einen geeigneten Ort für den Aufbau eines Datencaches dar. In diesem Kontext bietet sich vor allem ein constraint-basiertes Caching an, bei dem Datenobjekte in Abhängigkeit ausgeführter Anfragen vorgehalten werden. Während die Teilkomponenten Process Parser und Service Dictionary vorrangig statische Aspekte adressieren, bildet die WFPE-Teilkomponente Runtime Environment das Kernstück der Ausführung von Prozessplänen. Hierbei stellt ein Prozessplan die ausführbare Repräsentation eines Prozesstyps dar. Sowohl bei der Initiierung durch einen Inbound-Adapter als auch bei der zeitgesteuerten Initiierung werden nun Instanzen dieses Prozessplans erzeugt und sollen anschließend zur Ausführung gebracht werden. Das zentrale Element der Runtime Environment stellt der so genannte ProcessManager dar, welcher eine Liste von ProcessContainern verwaltet. Außerdem realisiert dieser das Ressourcen Management in Form von Speicherallokation und einer Begrenzung der Thread-Anzahl, sowie die Prioritätenverwaltung der ProcessContainer. Ein derartiger ProcessContainer stellt die Ausführungsumgebung eines Prozessplans dar. Diesen Grundaufbau der Runtime Environment zeigt die folgende Abbildung.

182

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 77:

Entwurf WFPE: Aufbau der Runtime Environment

Der ProcessContainer kann als einfacher Thread angesehen werden, welcher zyklisch Prozesspläne, startet. Hierzu entnimmt der ProcessContainer zunächst eine Aufgabe aus der ProcessQueue. Dies ist eine blockierende Aktion, dass heißt der aktuelle Thread wartet gegebenenfalls so lange, bis eine Aufgabe in die ProcessQueue eingestellt wird. Danach entnimmt der ProcessContainer einen freien ThreadWorker aus dem ThreadPool, wobei auch dies eine blockierende Aktion ist. Anschließend wird dem ThreadWorker lediglich der aktuelle Prozessplan übergeben und letztendlich gestartet. Nachdem der ThreadWorker gestartet wurde, beginnt der Zyklus von neuem, noch bevor der aktuelle Prozessplan beendet wurde. Diese Vorgehensweise sorgt für eine effiziente Verarbeitung, wobei dies vor allem auf Multi-Prozessor-Hardware Vorteile in sich birgt. Abschließend bleibt festzustellen, dass die Runtime Environment unter besonderer Berücksichtigung einer effizienten Verarbeitung realisiert werden sollte, da diese erheblichen Einfluss auf die Gesamtperformance des TC2 hat. Auch die Prioritätenverwaltung des ProcessManagers setzt an der Stelle des ProcessContainers an. So können Prioritäten ausschließlich für

183

6 Prototypische Realisierung am Beispiel von TransConnect

komplette ProcessContainer festgelegt werden. Somit wird ermöglicht, dass beispielsweise ein performance-kritischer Prozesstyp gegenüber anderen, nicht-kritischen Prozesstypen bevorzugt behandelt wird. Die einzelnen Prozesspläne nutzen intern dann die Operatoren des MTM, um beispielsweise elementare Transformationen durchzuführen oder um auf das Service Dictionary zuzugreifen. Die soeben angesprochenen Operatoren des MTM sind die Realisierungen des in Abschnitt 4.3.3 definierten konzeptuellen Prozessmodells. Da im Rahmen der prototypischen Realisierung der kompilierte Ansatz verfolgt wird, entfallen hierbei die wichtigsten kontrollflussorientierten Muster. Dies ist darin begründet, dass derartige Muster nicht interpretativ ausgewertet werden brauchen, da sie direkt in den Quelltext des Prozessplans, als triviale Java-Kontrollstrukturen, generiert werden können. In ähnlicher Weise ist auch das Reply-Muster als einfache return-Anweisung realisierbar. Die folgende Abbildung zeigt dies noch einmal in einer übersichtlichen Form.

Abbildung 78:

Realisierung des MTM Prozessmodells

Weiterhin beeinflusst die Auswahl des kompilierten Ansatzes auch den Entwurf der einzelnen Muster. Während bei dem interpretiertem Ansatz eine Nachricht direkt von einem Knoten an den anderen gegeben wird, erhält ein Knoten im kompiliertem Ansatz eine Nachricht von der Prozessplaninstanz und gibt eine nicht notwendigerweise

184

6 Prototypische Realisierung am Beispiel von TransConnect

verschiedene Nachricht nach der Verarbeitung wieder an den Prozessplan zurück. Somit kann als ein Hauptunterschied festgestellt werden, dass beim interpretierten Ansatz jeder Knoten seine Nachfolger kennt. Beim kompiliertem Ansatz ist dies nicht der Fall. Hier werden diese Kontrollstrukturen durch den Prozessplan abgebildet. Letztendlich fiel die Wahl vor allem wegen der höheren Effizienz, der einfacheren Handhabbarkeit und der besseren Überwachbarkeit auf den kompilierten Ansatz. Damit weicht die interne Ebene in gewisser Weise von dem konzeptuellen Grundmodell ab. Dies zeigt wiederum die Unabhängigkeit der internen Darstellung von dem konzeptuellen Modell. Zusammenfassend kann festgehalten werden, dass der Entwurf des TransConnect 2.0 Servers bewährte Konzepte der Vorgängerversionen, wie beispielsweise das OutboundAdapter-Konzept und den Ansatz der MessageQueues aufgreift und in den neuen Architekturentwurf integriert. Dieser neue Entwurf ist vor allem durch die Workflow Process Engine geprägt.

6.1.2

Datenbankentwurf TransConnect 2.0 DataStore

Nachdem nunmehr der Entwurf des „TransConnect Servers“ beschrieben wurde, soll nun der Datenaspekt von TC2 mit in die Betrachtung aufgenommen werden. Hierzu ist die Teilkomponente „TransConnect DataStore“ zu untersuchen, sowie deren Entwurf vorzustellen. Der Zweck dieser Teilkomponente ist auf der einen Seite die zentrale Metadatenverwaltung aller Komponenten von TC2. Auf der anderen Seite bildet sie die Grundlage für eine ausfallsichere und asynchrone Verarbeitung von Nachrichten, sowie für ein umfassendes Monitoring der Verarbeitungsprozesse. Diese zwei unterschiedlichen Ziele begründen die logische Differenzierung zwischen dem „Metadata Repository (MDR)“ und dem „Operational Datastore (ODS)“ des TransConnect DataStore. Im

Rahmen

dieses

Abschnitts

soll

das

klassische

Vorgehensmodell

des

Datenbankentwurfes verfolgt werden, wobei auf die Ergebnisse der einzelnen Schritte im Detail eingegangen wird. Die folgende Abbildung zeigt die hier benutzte Vorgehensweise.

185

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 79:

Wie

die

Abbildung

bereits

Datenbankentwurfes

einen

Anforderungsanalyse

in

Vorgehensweise beim Datenbankentwurf

verdeutlichte,

sinkenden einer

weist

die

Abstraktionsgrad

textuellen

und

Folge auf. damit

der So

Phasen

des

resultiert

die

sehr

abstrakten

Anforderungsspezifikation. Im Rahmen des konzeptuellen Entwurfes werden die Anforderungen in eine formale Spezifikation überführt. Hierzu wird ein Entity Relationship Model (ERM) [CHEN76] definiert, welches noch unabhängig von dem formalen Datenmodell ist. Das so beschriebene semantische Schema wird dann mit dem logischen Entwurf in das logische Schema überführt. Da der TransConnect DataStore ein RDBMS nutzen soll, wird hierbei ein Relationenmodell (RM) erstellt. Dieses ist immer noch unabhängig von konkreten DBMS. Erst im Rahmen des Physischen Entwurfes wird das DBMS-spezifische, physische Schema festgelegt. Anforderungsanalyse Im Rahmen der Anforderungsanalyse sollen nun, ausgehend von den eingangs erwähnten Anwendungsproblemen, Anforderungen an den TransConnect DataStore definiert werden. Die Anforderungen widerspiegeln dabei die Daten, welche durch den Datenbankentwurf abzubilden sind. Für das MetadataRepository lassen sich die folgenden konkreten Anforderungen identifizieren: •

Abbildung von definierten Prozesstypen samt deren Prozessdokumenten, welche mittels des „Process Parsers“ in das System eingebracht werden

•

Abbildung von Zeitmodellen für die zeitgesteuerte Ausführung von Prozesstypen

•

Verwaltung von Konfigurationsmöglichkeiten der unterschiedlichen Adaptertypen sowie von konkreten Konfigurationen instanziierter Adapter

186

6 Prototypische Realisierung am Beispiel von TransConnect

•

Abbildung von adapterspezifischen Nachrichtentypen

•

Verwaltung

beliebig

vieler

MessageQueueTypen

für

das

asynchrone

Verarbeitungsmodell •

Verwaltung von Routinginformationen, welche Aussagen erlauben mit welchen Prozesstypen ein Nachrichtentyp zu verarbeiten ist und ob dies synchron oder asynchron erfolgen soll

•

Bereitstellung von Analyse- und Optimierungsregel sowie von JavaTemplates für den Process Parser

•

Verwalten

von

technischen

Konfigurationsparametern

für

die

einzelnen

TransConnect-Teilkomponenten Neben

diesen

Anforderungen

an

die

Verwaltung

von

Metadaten,

muss

der

Datenbankentwurf folgenden Anforderungen des Operational DataStores genügen. •

feingranulare Verwaltung von Nachrichten und deren Zuständen

•

Abbildung der Zugehörigkeit von Nachrichten zu MessageQueueTypen

•

Verwaltung von Prozessen und deren Zuständen, sowie von Ergebnisnachrichten bei dem synchronen Verarbeitungsmodell

•

Vorhalten von Daten für Recovery-Prozesse bei Systemausfall

Konzeptueller Entwurf Die recht allgemein gehaltenen und informellen Anforderungsbeschreibungen sollen nun in der Phase des konzeptuellen Entwurfes in eine formale Spezifikation überführt werden. Hierfür wird ein Entity Relationship Models (ERM) mit der Notation von Chen definiert, wobei für eine bessere Übersichtlichkeit auf die Darstellung von Attributen zu verzichten ist. Dieses Modell bildet das semantische Schema des TransConnect DataStore. Die folgende Abbildung zeigt zunächst das ERD bevor dieses detaillierter erläutert werden soll.

187

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 80:

TransConnect DataStore – Entity Relationship Model

Da die einzelnen Entitäts- und Beziehungstypen aus der zuvorgehenden Abbildung entnommen werden können, wird an dieser Stelle auf eine explizite Identifikation verzichtet. Nunmehr soll jedoch auf die Überführung der Anforderungen in das ERM näher eingegangen werden. So wurde die „Abbildbarkeit von Prozesstypen“ in die Entitäten ProcessType, ProcessLanguage und ProcessDocument überführt. Hierbei ist ein ProcessType exakt einer ProcessLanguage, wie zum Beispiel WSBPEL 2.0, zuzuordnen, was die initiale Prozessbeschreibung charakterisiert. Dabei kann ein ProcessType beliebig viele ProcessDocuments, wie beispielsweise XSLT-Skripte, haben. Die „Abbildbarkeit von Zeitmodellen“ in Form der Entität Schedule setzt ebenfalls am ProcessType an, da somit zeitgesteuert eine Instanz eines bestimmten ProcessTypes initiiert werden kann. Weiterhin wird die „Abbildung von Adapterkonfigurationen“ mit den Entitäten Adapter, AdapterType und AdapterPropertyType beschrieben. Dabei nutzt ein ProcessType eine Menge von konfigurierten Adaptern. Jeder Adapter ist dabei von einem speziellen Adaptertyp, wobei dieser wiederum eine Menge von AdapterTypeProperties definiert.

188

6 Prototypische Realisierung am Beispiel von TransConnect

Die Beziehung zwischen einem Adapter und den spezifischen AdapterTypeProperties beschreibt folglich eine konkrete Ausprägung der Adapterkonfiguration. Die Überführung der

“Adapterspezifischen

Nachrichtentypen“

MessageQueueTypes“

erfolgte

MessageQueueType.

Die

MessageQueueType

werden

schlicht

drei

auf

Entitäten

weiterhin

dazu

und die

der

Entitäten

ProcessType, verwendet

„Verwaltung

von

MessageType

und

MessageType die

„Abbildung

und von

Routinginformationen“ vorzunehmen. Dies wurde in Form eines multiplen Beziehungstyps dargestellt. Die Beschreibung des MetadataRepositories kann letztendlich mit den alleinstehenden

Entitäten

MTMAnalysisRules,

MTMOptimizationRules

und

MTMJavaTemplates sowie Configuration und ConfigurationGroup abgeschlossen werden, wobei einzig die rekursiven Eltern-Kind-Beziehungstypen hervorzuheben sind. Aufbauend auf dem MetadataRepository wird der Operational DataStore definiert. Die zentrale Entität ist hierbei die Message, welche von einem bestimmten MessageType ist und gegebenenfalls mittels einer MessageQueue synchronisiert wird. Da ein feingranularer Ansatz verfolgt wird, weist eine Message exakt eine DataTable auf. Diese hat eine Menge von DataAttribute, welche wiederum eine Menge von DataValue aufweist. Dabei ist zu beachten, dass es sich um „nested datatables“ handelt. So kann jeder DataValue selbst wieder eine DataTable sein. Damit wurde die „feingranulare Abbildung von Nachrichten“ sowie deren „Zuordnung zu MessageQueueTypen“ realisiert. Letztendlich wird die „Abbildung von Prozessen“ und das „Vorhalten von Daten für das Recovery“ durch die Entität Process realisiert, welche konkrete Prozessinstanzen verkörpert. Logischer Entwurf Im Rahmen des logischen Entwurfes soll nun das semantische Schema in ein logisches Schema überführt werden, wobei der Bezug zu dem Relationenmodell als formales Datenmodell hergestellt wird. Hierfür werden die klassischen Regeln zur Transformation eines ERM in das Relationenmodell herangezogen. Auf Grund der Komplexität des entworfenen Relationenmodells, wurde dieses in den Anhang C ausgelagert. Im Weiteren sollen nun einzelne Aspekte aus dem RM herausgegriffen und kurz erläutert werden. Die Relation ProcessType ist der zentrale Punkt des MDR. In ihr werden die Metadaten

189

6 Prototypische Realisierung am Beispiel von TransConnect

einer Prozessdefinition persistent abgelegt. Dabei werden die Prozessbeschreibungen jeder Ebene des Process Parsers vorgehalten. Ein ProcessType hält außerdem eine Referenz auf eine

ProcessLanguage.

In

dieser

Relation

ist

für

jede

weitere

unterstützte

Prozessbeschreibungssprache ein Datensatz anzulegen. Die Schedule-Relation referenziert nun die Relation ProcessType um Zeitmodelle für Prozesse abzubilden. Obwohl diese Beziehung eine 1:1-Kardinalität aufweist, sollen sie getrennt bleiben, um die verschiedenen Aspekte zu separieren. Ein ProcessType kann weiterhin durch die genutzten Adapter charakterisiert werden. Hierbei wurden alle N:M-Beziehungstypen in Relationen überführt. So wird beispielsweise die Abbildung der konkreten Konfigurationseigenschaften eines Adapters mit der Relation AdapterProperty gewährleistet. Der zweite Aspekt der hier etwas genauer betrachtet werden soll, ist die Abbildung der Routing-Informationen von Nachrichten. Dabei wurde der multiple Beziehungstyp in die Relation RoutingTable überführt, welche die Grundlage für die Verarbeitung des Dispatchers, des TransConnect Servers, bildet. So wird hier ein Mapping zwischen MessageTypes, ProcessTypes und eventuell MessageQueueTypes vorgenommen. Im Rahmen des ODS bildet die Relation Message den logischen Mittelpunkt. So enthält die Relation MessageQueue, welche als Synchronisationselement verstanden werden kann, lediglich Fremdschlüssel auf die Message. Eine Message kann dabei einen Process initiieren, ein Prozessergebnis, oder ein REDO-Image einer abgeschlossenen Interaktion sein. Eine besondere Bedeutung kommt in diesem Kontext auch der Relation DataTable zu. Mit

der

Relation

Prozess

können

die

Zustände

der

Verarbeitung

der

WorkflowProcessEngine einem Monitoring unterworfen werden. Um den logischen Entwurf abzuschließen sollen kurz drei alternative Ansätze erwähnt werden, welche eine vermeintlich höhere Performance zur Folge haben könnten, allerdings den logischen Entwurf entscheidend verändern würden. •

Datei-basiertes Persistenzsystem Erste Versuche in der SQL GmbH haben ergeben, dass die Performance mit steigender Nachrichtenanzahl überproportional sinkt. Außerdem eröffneten sich die

190

6 Prototypische Realisierung am Beispiel von TransConnect

Notwendigkeit der Realisierung eines Transaktionssystems, so dass dieser Ansatz als nicht praktikabel einzuschätzen ist. •

Einsatz einer XML-Datenbank / hybriden DBMS Auf Grund der vorrangigen Verarbeitung von XML birgt dieser Ansatz entscheidende Performance-Vorteile in sich. Da hierbei auf Grund der schlechten Standardisierung der Schnittstellen, allerdings die Portabilität eingeschränkt wird, soll auch dieser Ansatz nicht weiter betrachtet werden.

•

Nutzung von Fremdsystemen für Persistent MessageQueueing Die Nutzung von Fremdsystemen ist, trotz vermeintlicher Performancevorteile, auszuschließen, da das Monitoring des DataStore vollständig erhalten bleiben muss.

Zusammenfassend bleibt also einzuschätzen, dass die Verwendung eines RDBMS als Grundlage für den TransConnect DataStore die geeignete Wahl darstellt. Allerdings sollten hierbei neben den klassischen Systemen auch Spezialsysteme, wie zum Beispiel Hauptspeicherdatenbankbetriebssysteme (MMDBMS), untersucht werden, welche zu erheblichen Verbesserungen der Performance führen könnten. Physischer Entwurf Mit dem physischen Entwurf soll das logische Schema in ein physisches Schema und damit in eine DBMS-spezifische Form gebracht werden. Hier ist noch einmal explizit auf die Sollanalyse im Abschnitt 2.5.3 zu verweisen, in der festgelegt wurde, dass TC2 derart erstellt werden soll, dass beliebige RDBMS zum Einsatz kommen können. Aus diesem Grunde wird bewusst und trotz der Forderung nach einer hohen Performance auf Stored Procedures, Trigger sowie Spezialfunktionalitäten, hinsichtlich XML-Funktionalitäten und User Defined Types (UDT), verzichtet. Für die speziellen DBMS sind somit nur spezifische create-Skripte anzubieten in denen die initialen SDL, DDL und DML-Statements enthalten sind. An dieser Stelle sei auf den Anhang D verwiesen, in welchem der physische Entwurf am Beispiel des Sybase ASE 15 beschrieben ist. Abschließend bleibt einzuschätzen, dass vieles, aber vor allem die Notwendigkeit einer hohen Performance, für ein Abweichen von der Sollanalyse in Bezug auf die Nutzung von

191

6 Prototypische Realisierung am Beispiel von TransConnect

Stored Procedures und Triggern spricht. So könnten viele Verarbeitungsaspekte sehr effizient auf deklarative Weise mit Stored Procedures gelöst werden, anstatt diese im TransConnect Server zu verarbeiten und hierfür eine Menge von Anfragen an das DBMS zu stellen. Allerdings müssen auch die Nachteile eines solchen Vorgehens betrachtet werden, da eine derartige Entscheidung zur Folge hätte, dass permanent die spezifischen Prozeduren für die verbreitetsten DBMS auf aktuellem Stand vorzuhalten wären. Dies wäre natürlich wiederum mit einem deutlichen Anstieg des Aufwandes verbunden. Letztendlich wird wegen der Brisanz dieses Themas der Sollanalyse Folge geleistet und ein physisches Schema definiert, welches sich auf Grundfunktionalitäten beschränkt.

6.1.3

Definition von Maßnahmen zur Qualitätssicherung

Im Rahmen des Entwurfes darf neben den vorgestellten Hauptkomponenten auch der Aspekt der Qualitätssicherung nicht vernachlässigt werden. Hierbei steht zum einen die Standardisierung eines ganzheitlichen Testprozesses und zum anderen der Aufbau einer Testsuite im Mittelpunkt der Betrachtung. Zunächst soll jedoch der Begriff der Softwarequalität exakt abgegrenzt werden. Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. DIN ISO 9126, [ISO9126] Somit geht die Softwarequalitätssicherung über den Test von funktionalen Anforderungen hinaus und berücksichtigt auch nicht-funktionale Anforderungen wie beispielsweise die Performance und die Robustheit des Systems. Dementsprechend kann der Prozess der Qualitätssicherung im Kontext der Software-Entwicklung in die folgenden drei Bereiche untergliedert werden.

192

6 Prototypische Realisierung am Beispiel von TransConnect

•

Validierung – Nachweis der Gültigkeit

•

Verifikation – Nachweis der Korrektheit

•

Debugging – Identifikation von Fehlern

Betrachtet man nun die Phasen eines Softwareentwicklungsprozesses [SCHL04], so liegt der Schluss nahe, dass in jeder dieser Phasen qualitätssichernde Maßnahmen zu ergreifen sind. Diese sind im Weiteren etwas detaillierter zu betrachten. In der Phase der Analyse wird die Formalisierung der Anforderungen in einem Anforderungstest überprüft. Analog dazu ist auch die Spezifikation des Entwurfes im Rahmen des Designtests zu testen. Dabei können der Anforderungstest und der Designtest dem Bereich der Validierung, also dem für gültig Erklären des geplanten Systems, zugeordnet werden. Darauf aufbauend umfasst der Bereich der Verifikation den Nachweis der korrekten Realisierung von funktionalen Anforderungen. Hierbei wird die Phase der Implementierung mit einem Funktionstest und die Integration mit einem Integrationstest abgeschlossen. In den abschließenden Phasen Einsatz und Wartung sind letztendlich Akzeptanz- und Konfigurationstests durchzuführen, welche gleichermaßen den Bereichen Validierung als auch Verifikation zuzuordnen sind. Der Bereich des Debugging umfasst Methoden zum Auffinden von Fehlern bei nichterfolgreicher Verifikation. Nachdem nunmehr ein grundlegender Überblick über die Softwarequalitätssicherung gegeben wurde, soll nun der Bezug zur Entwicklung von TC2 hergestellt werden. Dazu ist zunächst festzustellen, dass bis zur aktuellen Version von TransConnect weder eine Standardisierung des Testprozesses noch eine automatisiert ausführbare Testsuite existierte. Demzufolge ist es ein erklärtes Ziel der Entwicklung von TC2 dem entgegen zu treten. Im Folgendem soll nun ein Vorschlag für den Ablauf des Testprozesses einschließlich eines Entwurfes der „TransConnect Testsuite“ unterbreitet werden. Dies wird zunächst visualisiert und anschließend genauer diskutiert.

193

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 81:

Entwurf der TransConnect Testsuite

Der Testprozess für TransConnect-Weiterentwicklungen soll, wie durch die Abbildung veranschaulicht, in vier Teilschritte differenziert werden, wobei deren Unterbrechung durch die eigentlichen Entwicklungsphasen beachtenswert ist. Im ersten Schritt ist ein Review der Anforderungsspezifikation durch, nicht direkt an der Entwicklung beteiligte, Mitarbeiter durchzuführen. Sofern diese Überprüfung erfolgreich war, ist in dem zweiten Schritt ein Review der Entwurfsspezifikation, analog zu Schritt eins, vorzunehmen. Falls auch dieser keine Beanstandungen hervorgerufen hat, soll in einem dritten Schritt die TransConnect Testsuite ausgeführt werden. Dies ist der Hauptschritt des Testprozesses. An dieser Stelle soll der Aufbau der TransConnect Testsuite in die Betrachtung aufgenommen werden. Die Testsuite

wird

grundlegend

in

die

drei

Teilkomponenten

Testumgebung,

Testprotokollierung und Testauswertung gegliedert. Innerhalb der Testumgebung werden die eigentlichen Testfälle zur Ausführung gebracht. Grundlegend wird hierbei mit Klassentests, den so genannten Unit- oder Modultests, begonnen. Sofern diese erfolgreich waren schließen sich daran die so genannten Integrationstests an, wobei das Zusammenspiel von Mengen von Einheiten getestet wird. Dabei ist auf die Testreihenfolge zu achten. So werden Subklassen nach ihren Superklassen und nutzende nach benutzten

194

6 Prototypische Realisierung am Beispiel von TransConnect

Klassen getestet. Die Unit- und Integrationstest bilden zusammen eine Gruppe, welche begleitend und abschließend zur Phase der Implementierung durchgeführt werden. Als Werkzeuge können hierbei JUnit und spezielle Werkzeuge zur automatisierten Testung von GUIs eingesetzt werden. Die zweite große Gruppe von Testfällen umschließt der Systemtest. Dabei ist der Installationsprozess und das Gesamtsystem zu überprüfen. Für den Systemtest ist eine Menge von speziellen Testszenarien, welche dann automatisiert ausgeführt werden, zu definieren. Dabei sollte sowohl die korrekte Funktionserfüllung als auch die Robustheit bei definierten Fehlern untersucht werden. Prinzipiell muss die Interaktion mit Fremdsystemen in den Test einbezogen werden. Sofern dies nicht automatisierbar ist, sind Simulatoren zu entwickeln, welche gegenüber TransConnect die Interaktion mit dem Fremdsystem simulieren. Während die bislang beschriebenen Testfälle obligatorisch für jede Version auszuführen sind, können die folgenden Testfälle optional in regelmäßigen Zeitabständen realisiert werden. In dieser Gruppe sind beispielsweise Konfigurationstests

und

Performancetests

zu

erwähnen.

Für

den

System- und

Konfigurationstest bietet sich die Nutzung von virtuellen Umgebungen an, um automatisiert Ausgangszustände wiederherstellen zu können. Der gesamte Testprozess wird letztendlich durch einen vierten Schritt abgeschlossen, in dem ein Akzeptanztest hinsichtlich Bedienbarkeit, Ergonomie und Verständlichkeit mit nicht involvierten Mitarbeitern realisiert wird. Abschließend soll an dieser Stelle noch einmal auf eine wesentliche Schwierigkeit beim Test von TC2 eingegangen werden. Auf Grund der Interaktion mit unterschiedlichsten Fremdsystemen im Rahmen von flexibel modellierbaren Prozessen, kommt es zu einer infiniten und damit nicht testbaren kombinatorischen Explosion von Anwendungsfällen, so dass Gruppen von typischen Szenarien zu definieren sind. Letztendlich können alle qualitätssichernden Maßnahmen nach Dijkstra lediglich das Vorhandensein von Fehlern nachweisen, nicht jedoch deren Abwesenheit [DIJK69].

195

6 Prototypische Realisierung am Beispiel von TransConnect

6.2

Implementierung

Aufbauend auf den zuvorgehend diskutierten Entwürfen, soll nun deren Realisierung in den Mittelpunkt der Betrachtung gerückt werden. Dabei ist zunächst darauf zu verweisen, dass die Teilkomponenten TransConnect Server und TransConnect DataStore, mittels Java 1.5, im Rahmen dieser Arbeit von Grund auf neu implementiert wurden. Da diese prototypische Implementierung ein relativ großes Ausmaß angenommen hat, soll es explizit nicht das Ziel dieses Teilkapitels sein, die Implementierung vollständig darzustellen, sondern vielmehr sind Schwerpunkte herauszugreifen und detailliert zu erläutern. In dem ersten Abschnitt soll mit der Implementierung der Workflow Process Engine die praktische Realisierbarkeit der Inhalte dieser Arbeit aus einer statischen Perspektive nachgewiesen werden. Anschließend wird in dem folgenden Abschnitt eine Teilmenge von interessanten Verarbeitungsaspekten ausgewählt und exemplarisch dargestellt um auch die Realisierbarkeit aus der dynamischen Perspektive aufzuzeigen. Letztendlich wird dieses Teilkapitel von einer Betrachtung des aktuellen Standes der prototypischen Realisierung einschließlich offener Problemstellungen und ausstehender Punkte der Implementierung abgerundet.

6.2.1

Implementierung der WorkflowProcessEngine

Wie bereits im Abschnitt 6.1.1 dargestellt, untergliedert sich die Workflow Process Engine (WFPE) in die vier Teilkomponenten: Core Engine, Process Parser, Runtime Environment und Service Dictionary. Dies bildet zugleich die Grundlage für die interne Package-Struktur der WFPE. Die nachfolgende Tabelle zeigt diese Package-Struktur und stellt die Verbindung zu den Inhalten der einzelnen Komponenten her. Teilkomponente Package-Name

Beschreibung

Core Engine

Schnittstellendefinition und -implementation

com.sqlgmbh.tc.server.wfpe.core

196

6 Prototypische Realisierung am Beispiel von TransConnect

Teilkomponente Package-Name Process Parser

Runtime Environment Service Dictionary

Tabelle 17:

Beschreibung

com.sqlgmbh.tc.server.wfpe.parse Parser zur Überführung externer XML-basierter Prozessbeschreibungen in interne, ausführbare Java-Klassen com.sqlgmbh.tc.server.wfpe.re Ausführungsumgebung für Workflow-Prozesse und Operatorimplementationen des Message Transformation Models (MTM) com.sqlgmbh.tc.server.wfpe.sdict Internes Dienstverzeichnis für Adapter, MessageQueues und technische Dienste, sowie Dienstimplementationen und Sonderfunktionalitäten

Package-Grobstruktur der Workflow Process Engine

Im Rahmen dieses Abschnitts wird zweckmäßiger Weise, ebenfalls die Package Struktur aufgegriffen und ausgehend von den jeweiligen Klassendiagrammen die eigentliche Implementierung der einzelnen Teilkomponenten beschrieben. Auf die Abbildung der Klassendiagramme wird an dieser Stelle jedoch explizit, auf Grund deren Komplexität, verzichtet und auf den Anhang G und damit auf die beiliegende DVD verwiesen. Die erste zu diskutierende Teilkomponente ist die Core Engine, welche im Wesentlichen die Schnittstellendefinition und deren Realisierung enthält. Die Schnittstellendefinition setzt sich dabei aus dem Interface IProcessEngine und der Klasse ProcessEngineFactory zusammen. Die Kombination aus diesen beiden Teilen gewährleistet die, nach außen, änderungsfreie Austauschbarkeit der ProcessEngine, da die aufrufende Stelle keine Kenntnis von der implementierenden Klasse benötigt. Im Rahmen der vorliegenden TC2Implementation lassen sich hierbei drei aufrufende Stellen identifizieren. So nutzen die MessageQueue

und

der

Scheduler

die

WFPE

im

Rahmen

des

asynchronen

Verarbeitungsmodells, während der Dispatcher synchrone Anfragen direkt an die WFPE delegiert. Die beschriebene Schnittstelle wird durch die WFProcessEngine realisiert, welche dabei dem Entwurfsmuster Singleton [MARI02] folgt. Dieses Entwurfsmuster sichert, dass stets mit dem gleichen Objekt gearbeitet wird um den Zustand der Engine über lange Zeit aufrecht zu erhalten und eine zentrale Metadatenverwaltung zur Laufzeit zu ermöglichen. Die Core Engine nutzt dabei die Schnittstellen der drei übrigen

197

6 Prototypische Realisierung am Beispiel von TransConnect

Teilkomponenten der WFPE um letztendlich die, mittels der Schnittstelle IProcessEngine definierten, Funktionalitäten vollständig zu realisieren. Als zweite Teilkomponente soll nun die Implementation des Process Parsers beschrieben werden. Dieser wird vorrangig zur Entwicklungszeit eingesetzt und überführt externe, xmlbasierte

Prozessbeschreibungen

in

interne,

ausführbare

Java-Klassen.

Diese

Teilkomponente wird durch die Schnittstelle IParser abgegrenzt. Die realisierende Klasse, der ParserManager, verwendet die einzelnen Schichten des Parser, welche jeweils als separate Klasse umgesetzt wurden. Die ParserLayer1 ermöglicht hierbei die Abbildung von beliebigen externen Prozessbeschreibungen auf die interne XML-Repräsentation des MTM. Dies wurde als einfache XSLT-Transformation realisiert, so dass für jede zu unterstützende Prozessbeschreibungssprache lediglich ein weiteres XSLT-Skript im TransConnect DataStore zu hinterlegen ist. Im Rahmen der prototypischen Realisierung wurde ausschließlich ein Skript für WSBPEL 2.0 erstellt. Mit der ParserLayer2 wurde eine Ebene für die Analyse und Optimierung der internen Darstellung vorgesehen. An dieser Stelle bleibt jedoch zu erwähnen, dass die ParserLayer2 bislang nicht realisiert wurde. Hier bieten sich allerdings im Wesentlichen drei Alternativen für die regelbasierte Analyse und Optimierung an, die nachfolgend kurz benannt sind. •

XSLT-Skript zur Abbildung der Gesamtheit der Regeln

•

XQuery-Anfragen zur Abbildung der einzelnen Regeln

•

Internes Regelformat und Transformation mit der W3C DOM API

Aus dem derzeitigen Blickwinkel erscheint die Variante zwei auf Grund der größten Ausdruckskraft und Flexibilität am geeignetsten. Aufbauend auf dieser regelbasierten Transformation sind kostenbasierte Optimierungen vorstellbar, wobei Varianten von Prozessbeschreibungen gebildet werden sollten und anschließend die als kostenoptimalste Variante bewertete auszuwählen ist. Die nächsttiefere ParserEbene ist die ParserLayer3, welche eine Überführung der internen XML-Darstellung in eine interne Java-Darstellung vornimmt. Hierbei wird der Ansatz eines template-basierten Generators verfolgt, wobei Templates und Subtemplates definiert werden. Im Prozess der Überführung werden dann

198

6 Prototypische Realisierung am Beispiel von TransConnect

die Platzhalter durch einfache String-Ersetzungen mit konkreten Parametrisierungen belegt und anschließend in übergeordnete Templates eingesetzt. Eine alternative dazu wäre die erneute Nutzung von XSLT, worunter allerdings die Wartbarkeit stark gelitten hätte. In der ParserLayer4

kommt

es

dann

abschließend

zur

Kompilierung

und

initialen

Objektinstanziierung der Java-Klasse. Die Klasse ParserDAO kapselt alle Datenzugriffe des ProcessParser, wobei sie dem Entwurfsmuster DataAccess Object (DAO) [ASHM04] folgt, indem sie als Sammlung von Datenzugriffen realisiert wurde. Abschließend ist zu erwähnen,

dass

die

einzelnen

Ebenen

des

Process

Parser

ausschließlich

zur

Entwicklungszeit abgearbeitet werden und damit als nicht Performance-kritisch einzuschätzen sind. Im Gegensatz dazu kommt es bei der Teilkomponente RuntimeEnvironment, also der eigentlichen Ausführungsumgebung von Transformationsprozessen, vor allem auf eine hohe Performance an. Hierbei steht nicht unbedingt eine minimale Verarbeitungszeit eines Transformationsprozesses

im

Vordergrund,

als

vielmehr

eine

globale

Durchsatzoptimierung. In gewohnter Weise wurde auch diese Teilkomponente mit einer exakt definierten Schnittstelle, dem IRuntimeEnvironment-Interface, versehen. Dieses wird durch die Klasse ProcessManager realisiert, die wiederum als Singleton entworfen wurde. Der damit zentrale ProcessManager verwaltet eine Liste von ProcessContainern und regelt die

Ressourcenverwaltung

und

Prioritätenvergabe.

Außerdem

nutzt

er

den

TransactionManager und den ResultCallback. Dieser Callback ermöglicht die Realisierung des

synchronen

Verarbeitungsmodells,

trotz

der

ausschließlichen,

im

Weiteren

beschriebenen, asynchronen, internen Verarbeitung. Der ProcessContainer, als Subklasse von Thread, stellt die Ausführungsumgebung für einen Prozesstyp dar. Hierbei wird ein zentraler ThreadPool und jeweils eine ProcessQueue genutzt. Im Wesentlichen durchläuft ein ProcessContainer-Thread eine Endlosschleife, wobei er zu Beginn auf einen Process in der ProcessQueue wartet. Anschließend blockiert er bis der ThreadPool wieder einen freien ThreadWorker bereitstellt. Nun kann ein Objekt des spezifischen Prozesstyps in Form eines Processplans erzeugt und zur Ausführung gebracht werden. Sobald die Ausführung des Processplans beendet ist und eine Ergebnisnachricht zurückgegeben wurde, wird der ResultCallback aktiviert, so dass eine wartende synchrone Anfrage erfolgreich beendet

199

6 Prototypische Realisierung am Beispiel von TransConnect

werden kann. Abschließend gibt sich der ThreadWorker selbst wieder an den ThreadPool frei. Jede generierte Prozessbeschreibung muss eine Subklasse der bereits genannten abstrakten Klasse Processplan sein. Ein derartiger Transformationsprozess nutzt eine Reihe von Operatorimplementationen des MTM, wie beispielsweise Translation, Selection oder Join, welche alle von der Superklasse Node abgeleitet wurden. Die Tatsache, dass die Klasse Processplan selbst auch von Node abgeleitet ist, ermöglicht die hierarchische Schachtelung von ProzessTypen. Im Rahmen des vorgestellten Prototypen wurden die einzelnen Operatoren des MTM als Java-Klassen implementiert, welche die interne Repräsentation des Nachrichtenmodells in Form der Klasse Message transformieren. Falls an dieser Stelle ein rein-XML-basierter Ansatz verfolgt werden soll, ist die Realisierung der einzelnen Operatoren als XML-Transformationen mit XSLT, STX oder XQuery vorstellbar, wobei die spezifischen Parametrisierungen als Argumente an den jeweiligen Prozessor übergeben werden. Weiterhin weist auch die Runtime Environment mit dem RuntimeEnvironmentDAO ein separates Data Access Object auf. Um die Beschreibung der Ausführungsumgebung abzuschließen ist noch einmal zu betonen, dass die Unterscheidung der Ausführungsmodelle lediglich nach außen hin suggeriert, nicht jedoch intern umgesetzt wird um eine möglichst hohen Durchsatz zu erreichen, da das hier beschriebenen Verarbeitungsmodell auf diese Weise sehr effizient arbeitet. Dies wird zum einen durch die Hohe Parallelität und zum anderen durch das Thread-Monitor-Konzept erreicht, wodurch unnötige Polling-Ansätze vermieden werden. Das MTM enthält unter anderem auch interaktionsorientierte Muster, welche konfigurierte Dienste referenzieren. Zur Verwaltung dieser Dienste wird ein internes Dienstverzeichnis mit speziellen ServiceWrappern für die einzelnen Komponenten benötigt. Dies wurde in der Teilkomponente Service Dictionary realisiert. An dieser Stelle sei dieses explizit von anderen Produkten und Projekten wie zum Beispiel JUDDI [JUDDI] abgegrenzt, welche durch die zusätzliche Abstraktionsebenen den kritischen Faktor Performance, erheblich beeinträchtigt hätten. Diese Teilkomponente wird durch die Schnittstelle IServiceDictionary beschrieben, welche wiederum durch die Klasse ServiceManager realisiert wird, wobei auch diese dem Entwurfsmuster Singleton folgt. Der ServiceManager verwaltet das Verzeichnis von

200

6 Prototypische Realisierung am Beispiel von TransConnect

Diensten, wobei jeder Dienst die Schnittstelle IService implementieren muss, damit er unabhängig

von

dessen

Typ

verwendet

werden

kann.

In

der

prototypischen

Implementierung wurden Dienste für den File- und den JDBC-Adapter, die MessageQueue sowie den technischen Dienst ZipWriter erstellt. Die komplette Datenzugriffslogik wurde wiederum in der Klasse ServiceDictionaryDAO gekapselt. Abschließend soll noch auf die Spezialkomponenten Cache und WSDL-Generator aufmerksam gemacht werden. So bietet sich der Aufbau eines Cache und dessen optionale Verwendung für das Nachladen von Stammdaten in Transformationsprozessen an. Hierbei wurde ein constraint-basierter Cache erstellt, welche die Input-Nachricht als Parameter auffasst und, auf dessen Vergleich basierend, Daten aus dem Cache wiederverwendet. Somit kann dieser Cache als sehr grobgranular eingeschätzt werden, da nur exakt gleiche Anfragen zu einem Cache-Hit führen. Eine Hauptproblematik ist die Konsistenz der Daten in diesem Cache, da in lose gekoppelten Systemen keine Aussage darüber getroffen werden kann, ob die Daten noch aktuell und damit streng konsistent sind. Somit kann lediglich eine schwache Konsistenz erreicht werden, indem maximale Cachezeiten vorgegeben werden, nachdem die Daten spätestens wieder aus dem Cache zu entfernen sind. Die zweite Spezialkomponente ist der WSDLGenerator,

welcher

die

Generierung

von

WSDL-Dokumenten

für

Implementierungen des Interface IService ermöglicht. Dies ist die Grundlage für die Nutzung der eigenen Dienste beispielsweise im Rahmen von BPEL-Designern von Drittanbietern. Hierbei wird die W3C DOM API verwendet um zur Entwicklungszeit die notwendigen Dokumente zu generieren.

6.2.2

Ausgewählte Verarbeitungsaspekte

Aufbauend auf der zuvorgehend beschriebenen statischen Sicht auf die Implementierung, sollen nun aus einer dynamischen Sicht Verarbeitungsaspekte ausgewählt und genauer diskutiert werden. Dabei bietet sich der Bezug zu den, in Teilkapitel 4.2 definierten, funktionalen und nicht-funktionalen Anforderungen an ein Nachrichtentransformationsmodell an. Zunächst ist jedoch die Auswahl der einzelnen Aspekte zu benennen.

201

6 Prototypische Realisierung am Beispiel von TransConnect

•

Verarbeitung von Nachrichten beliebiger Datenrepräsentationen

•

Datenströme und Datenflüsse in modellierten Transformationsprozessen

•

Recovery-Prozess nach Ausfall des TransConnect Servers

•

Verteilungsaspekte bei der Ausführung von Workflows

Verarbeitung von Nachrichten beliebiger Datenrepräsentationen Die interne Repräsentation des MTM-Nachrichtenmodells, in Form der Klassen Message und MessageDataTable, bildet die Grundlage für die Realisierbarkeit der Anforderungen des Content Based Routing, des Umgangs mit unterschiedlichen Datenrepräsentationen, die Transformation der Semantik von Nachrichten sowie für die Flexibilität bei der Modellierung des Datenaspektes. Hierbei wird die Nachricht aus einem Kopfsegment, in Form einer Hashmap, und einem Datensegment zusammengesetzt. Das Datensegment (Klasse MessageDataTable) stellt einen unidirektionalen Baum von logischen Tabellen dar, welcher rekursiv iteriert und entsprechend verarbeitet werden kann. Auf Grund der Komplexität dieser feingranularen Struktur und der Interaktionen mit derartigen Objekten sollen im Folgendem, spezielle Vorgehensweisen der Verarbeitung solcher Objekte vorgestellt werden. Die MessageDataTable kann dabei während des eigenen Lebenszyklusses verschiedene Zustände annehmen. Prinzipiell ist die Parallelität von Zuständen zu beachten, da zum einen der Zustand der Granularität der Daten und zum anderen der Zustand der Aktualität der transienten Daten in Bezug auf deren persistente Repräsentation verwaltet wird. Das folgende Zustandsdiagramm zeigt die wesentlichsten Übergänge der angesprochen Zustände.

202

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 82:

Zustandsdiagramm der Klasse MessageDataTable

Um die einzelnen Aspekte der Verarbeitung an der MessageDataTable besser darstellen zu können, ist an dieser Stelle ein Beispiel einzuführen, an dem fortan die einzelnen Schritte erläutert werden. Angenommen es werden Daten des folgenden Schemas verwaltet. Bestellung (ID, Kunde, Datum, Prioritaet) Bestellposition (ID, Posnr, Artnr, Menge, Preis)

Ein erster wichtiger Schritt bei der Verarbeitung derartiger Daten ist die Überführung beliebiger Datenrepräsentationen in das interne Format. Hierbei lassen sich im Wesentlichen die fünf unterschiedlichen Formate: XML, CSV, relationale Daten, strukturierte Objekte und Binärdaten identifizieren. Für jedes dieser Formate wurden nun spezielle Überführungsregeln definiert. Um die Übersichtlichkeit zu wahren, soll nun jedoch lediglich die Überführung von XML in das interne Format exemplarisch dargestellt werden. Prinzipiell sind bei der Überführung von XML-Daten in die interne, transiente Struktur drei Regeln zu differenzieren. Bei der Abbildung unterschiedlicher Kindelemente (a) werden die einzelnen Elemente als Attribute des Elternelementes interpretiert. Somit beinhaltet eine derartige logische Tabelle exakt einen Datensatz. Im Unterschied dazu wird bei der Abbildung von gleichen Elementen (b) zunächst ein Knoten mit dem Namen angelegt, welcher eine weitere logische Tabelle enthält. Hierbei umfasst diese Tabelle eine Menge von Tupeln deren Anzahl gleich der Anzahl der Elemente ist. Die Kindelemente

203

6 Prototypische Realisierung am Beispiel von TransConnect

dessen, werden wiederum als Attribute dargestellt. Dabei sind alle Kindelemente als Attribute enthalten, auch wenn diese nicht in allen Eltern-Elementen vorkommen. Die dritte Regel adressiert die Abbildung von XML-Attributen (c) und ist mit Variante zwei zu vergleichen, mit der Einschränkung, dass die erstellte logische Tabelle stets nur einen Datensatz enthalten kann und Attribute eines Elternelementes darstellen. Die folgende Abbildung zeigt diese Überführung von externen XML-Daten in die transiente, interne Struktur.

Abbildung 83:

Überführung von externen Daten in das interne Format

In einem zweiten Schritt kann nun die interne, transiente Repräsentation in eine interne, persistente Repräsentation überführt werden, indem die Nachricht in den zu Grunde liegenden TransConnect DataStore eingebracht wird. Hierbei ergibt sich die Schwierigkeit, dass zur Entwicklungszeit die Struktur der Nachrichten nicht bekannt ist und DDLTransaktionen das System unnötig belasten würden, so dass eine generische Relationenstruktur zur Speicherung dieser unidirektionalen Tabellenbäume notwendig ist.

204

6 Prototypische Realisierung am Beispiel von TransConnect

Die folgende Abbildung veranschaulicht zunächst die interne, persistente Repräsentation am bekannten Beispiel, bevor näher auf die Überführung eingegangen wird.

Abbildung 84:

Überführung des internen Formats in eine persistente Repräsentation

Da die Überführung der transienten in die persistente Repräsentation und vice versa relativ oft im Lebenszyklus eines Workflows ausgeführt wird, kommt hierbei natürlich dem effizienten Zugriff eine große Bedeutung zu. So wird das Konzept verfolgt, rekursiv für jede transiente MessageDataTable, ein Insert-Statement auf die Relation DataTable sowie je einen Batch von Insert-Statements für die Relationen DataAttribute und DataValue anzulegen und diese dann zusammenhängend auszuführen. Somit kann die Anzahl der physischen Datenbankanfragen in dem obigen Beispiel der drei MessageDataTable auf neun Anfragen reduziert werden. An dieser Stelle sei erwähnt, dass dies jedoch bei sehr großen und tief geschachtelten XML-Dokumenten ineffizient ist. Hier wäre es kostengünstiger die MessageDataTable „Bestellung“ in der Applikation wieder in einen Zustand „unparsed“ zu versetzen und diesen dann als CLOB persistent zu machen, was in lediglich drei physischen Datenbankanfragen resultieren würde. Bei einem abermaligen Zugriff müsste man dann die MessageDataTable wieder in den Zustand „parsed“ versetzen,

205

6 Prototypische Realisierung am Beispiel von TransConnect

um innerhalb des Workflows gezielt lesend und schreibend auf Einzelwerte zugreifen zu können. Als „Best Practice“ kann an dieser Stelle noch der bewusste Hint an den Java Generator des Process Parsers genannt werden. So bietet es sich an eine MessageDataTable bis zur Ausführung einer Translation, welche beispielsweise mit XSLT erfolgt, im Zustand „unparsed“ zu belassen und erst danach den, in der Regel reduzierten, Umfang der MessageDataTable in den Zustand „parsed“ zu versetzen. Auf das Lesen derartiger Datenstrukturen wird im Weiteren explizit verzichtet, obwohl auch hierfür effiziente Algorithmen der Verarbeitung definiert wurden. Neben dem Aspekt der direkten Zugreifbarkeit auf die einzelnen Attribute und der Tatsache der Overhead-Reduzierung, bietet diese feingranulare Verwaltung der Daten im Rahmen der MessageDataTable einen weiteren Vorteil. So ermöglicht diese generische, persistente Struktur, trotz der Generizität, umfangreiche Anfragemöglichkeiten auf einer Menge von Nachrichten. Ein Beispiel für eine derartige Auswertung ist folgende SQL-Anweisung, welche alle Bestellnummern, der durch das System verarbeiteten Nachrichten, liefert. SELECT DISTINCT Value FROM DataAttribute a, DataValue d WHERE d.DID = a.DID AND d.CID = a.CID AND a.Name = 'O_Orderkey'

Abschließend

bleibt

einzuschätzen,

dass

eine

derartige

feingranulare

Nachrichtenrepräsentation notwendig ist, will man unabhängig von spezifischen Technologien das höchste Maß an Flexibilität erreichen. Datenströme und Datenflüsse in modellierten Transformationsprozessen Die funktionale Anforderung nach dem Umgang mit unterschiedlichen Datenmengen und damit letztendlich auch der Verarbeitbarkeit von beliebig großen Nachrichten erfordert eine Verarbeitung der Nachrichten als Datenstrom. Damit ist zwar einerseits eine Verbesserung der Effizienz möglich, andererseits jedoch auch eine Menge von Schwierigkeiten bei deren Realisierung verbunden, auf welche an dieser Stelle kurz eingegangen wird. Da eine Nutzung von Datenströmen auch den eigentlichen Datenfluss in den modellierten

206

6 Prototypische Realisierung am Beispiel von TransConnect

Workflows beeinflusst, soll dies ebenfalls in die Betrachtung mit einbezogen werden. Im Rahmen des erstellten Prototypen basiert der Standard-Datenfluss auf dem internen Nachrichtenmodell und realisiert deshalb noch kein ganzheitliches DataStreaming. Derzeit wird angenommen, dass lediglich nach jeder lesenden Interaktion mit einem OutboundAdapter die Ergebnisnachricht zur Realisierung der Transaktionssicherheit in den TransConnect DataStore einzubringen ist. Unabhängig von der Persistenz wird die gesamte Nachricht durch den Workflow befördert und mehrmals gelesen beziehungsweise verändert. Soll nun ganzheitlich DataStreaming zum Einsatz kommen, hat dies eine Reihe von Auswirkungen auf das derzeitige Verarbeitungsmodell. So ist eine Nachricht nach jeglicher Veränderung in den Datenbestand einzubringen und vor einem Zugriff von dort wieder zu laden. Dies ist erforderlich, da in Java eine Reihe von Datenströmen nicht rücksetzbar sind, was impliziert, dass sie nur einmal gelesen werden können. Auch eine Konvertierung in einen ByteArryInputStream ist an dieser Stelle aussichtslos, da während dieser Operation intern ein Byte-Array mit den gesamten Daten der Nachricht angelegt würde und somit der Verarbeitung von beliebig großen Nachrichten entgegensteht. Neben dieser eklatanten Beeinflussung des internen Datenflusses im TransConnect Server, verursacht die durchgängige Verwendung von Datenströmen eine Reihe von weiteren funktionalen Problemen. •

Content Based Routing nicht/nur mit Einschränkungen möglich So muss für bestimmte Aussagen erst der gesamte Datenstrom gelesen werden, bevor die Entscheidung über das Routing getroffen werden kann, so dass die Vorteile des Streamings verloren gehen.

•

Transformation der Semantik von Nachrichten nur teilweise möglich Da bei der Ausführung der einzelnen datenflussorientierten Muster die gesamte Nachricht im Hauptspeicher erforderlich ist, wären viele Anwendungsszenarien bei Einsatz von Datenströmen schlicht nicht realisierbar.

•

unterschiedliche Methoden der Nachrichtentransformation nicht einsetzbar Sofern generell DataStreaming zum Einsatz kommen soll, würde die Anwendung von beispielsweise XSLT auf Grund des internen Aufbaus des DOM keinen Sinn

207

6 Prototypische Realisierung am Beispiel von TransConnect

mehr machen, so dass sich auf SAX-basierte Transformationen wie beispielsweise STX zu beschränken wäre. •

Validierung von Nachrichten nur eingeschränkt möglich. Für die Validierung von Nachrichten gelten im Wesentlichen die gleichen Aussagen wie für das Content based Routing

•

Flexibilität der Modellierung stark eingeschränkt Letztendlich muss also das Urteil gefällt werden, dass DataStreaming die Flexibilität der Modellierung stark einschränkt, da ein Großteil der bewährten Muster und Konstrukte nicht verwendet werden können.

Auf Grundlage der aufgezählten Nachteile sollte die Verarbeitung von Datenströmen nur in Spezialfällen eingesetzt werden und nicht den Standardfall darstellen. Doch wie könnte man die Problematik der beliebig großen Nachrichten realisieren? Prinzipiell können hierbei zwei Ansätze den Ausweg bilden. Zum ersten könnte man Nachrichten völlig transparent partitionieren und in den Operatoren des MTM dann sequentiell die einzelnen Partitionen verarbeiten. Zum zweiten könnte man, unter der Annahme, dass bei sehr großen Nachrichten kein feingranularer Workflow zu durchlaufen ist, dem Generator einen Hint geben, dass DataStreaming zu verwenden ist, woraufhin ein Workflow mit einem veränderten internen Datenfluss erzeugt wird. Bei dieser zweiten Variante wäre die Modellierung jedoch auf eine gewisse Maximalanzahl von Prozessschritten und eine Auswahl von ausführbaren Operatoren begrenzt. Recovery-Prozess nach Ausfall des TransConnect Server Der Recovery-Prozess soll die funktionale Anforderung der zuverlässigen Verarbeitung erfüllen.

Wie

bereits

kurz

erwähnt,

wird

die

Annahme

verfolgt,

dass

die

Transaktionssicherheit durch das Anlegen von REDO-Images nach jeder lesenden Interaktion mit externen Systemen erreicht wird. Es ist explizit nicht notwendig nach jedem Prozessschritt derartige Images anzulegen, da bei den kontroll- und datenflussorientierten Operatoren des MTM gesichert ist, dass eine wiederholte Ausführung exakt das gleiche Ergebnis liefert.

208

6 Prototypische Realisierung am Beispiel von TransConnect

Die Hauptproblematik beim Recovery-Prozess nach einem Server-Ausfall stellt die Ermittlung des Prozesszustandes vor dem Ausfall, sowie die gezielte Wiederholung eines Teils des Workflow-Prozesses dar. Hierfür wird nachfolgend das Konzept der NodeIDs eingeführt. So hat die abstrakte Superklasse Processplan ein Datenmember currentNID, welches zur Ausführung des Prozesses stets die aktuelle NodeID enthält. Hierbei wird jeder Kante des logischen Graphen eine NodeID zugeordnet, welche eineindeutig den aktuellen Knoten der Verarbeitung identifiziert, da eine Kante stets nur ein Knoten als Ziel haben kann. Im Rahmen der ParserLayer3 wird der Kontrollgraph der zu generierenden JavaKlasse derart instrumentiert, dass vor jeder Ausführung eines Knotens die Methode setNID(x) mit der NodeID des Zielknotens aufgerufen wird. Diese IDs werden dabei intern durch den Generator vergeben. Beim Anlegen der REDO-Images wird dann die aktuelle NodeID vermerkt, so dass bei einem Systemausfall, das letzte REDO-Image gelesen werden muss und daraus der Prozesszustand vor Ausfall des Servers ermittelt werden kann. Der Problematik der Ausführung eines Teils der Workflow-Prozesses wird anschließend derart entgegengetreten, dass nach der Ermittlung der NodeID der, vor dem Server-Ausfall noch nicht beendeten, Prozesse spezielle Prozesstypen für die einzelnen Zwischenstände mit dem Process Parser generiert werden. Die folgende Abbildung zeigt die Konzepte noch einmal schematisch, bevor mögliche Fehlerquellen diskutiert werden.

Abbildung 85:

Einsatz des NodeID-Konzeptes für den Recovery-Prozess

Neben der Verwendung der NodeIDs hat die Abbildung auch das Laden der REDO-Images

209

6 Prototypische Realisierung am Beispiel von TransConnect

verdeutlicht. Angenommen in der obigen Abbildung kommt es bei NID=3, 4 oder 5 zu einem Fehler wird das REDO-Image des letzten erfolgreichen Invoke, also bei NID=2, mittels dem Receive-Operator geladen und der Recovery-ProzessType vollständig ausgeführt. An dieser Stelle sei allerdings auch auf mögliche Fehlerquellen dieses Ansatzes verwiesen. Da ein derartiger Recovery-Prozess ausschließlich REDO-Images von lesenden Interaktionen berücksichtigt, besteht die Gefahr der Doppelverarbeitung von Nachrichten. Um dem entgegenzutreten und eine vollständige Transaktionssicherheit zu gewährleisten, muss das Konzept der TIDs aus TransConnect 1.3.x weiterhin angewandt werden, um eineindeutig feststellen zu können ob eine Nachricht bereits erfolgreich an ein Fremdsystem versandt wurde. Ein weiteres Defizit sind Schleifenkonstrukte. So kann zwar die aktuelle Position innerhalb einer Schleife bestimmt werden, allerdings ist es allein mit den NodeIDs nicht möglich zu bestimmen, wie oft die Schleife bislang durchlaufen wurde. Somit bietet es sich an bei einem Fehler innerhalb einer Schleife den Recovery-Prozess vor Beginn des Schleifenkonstruktes neu zu beginnen, wobei allerdings theoretisch andere Ergebnisse erzielt werden können, als beim originalen Prozessablauf. Abschließend ist zu erwähnen, dass das NodeID-Konzept auch für den Verarbeitungsaspekt des Monitorings von Verarbeitungszeiten und Kontrollflüssen und damit zum Anlegen von Statistiken für die kostenbasierte Optimierung, wiederverwendet werden kann. Hierbei ist, abhängig vom gewählten Monitor-Level, bei jedem Operator die NodeID an den Monitor zu melden, um eine historische Auswertung von Datenflüssen entlang spezifischer Kontrollflüsse, unter Einbeziehung der benötigten Verarbeitungszeiten, auswerten zu können. Die Auswertungen des Monitors könnten dann als Statistik-Hints zur ReGenerierung von Prozessplänen an den Process Parser weitergeleitet werden. Verteilungsaspekte bei der Ausführung von Workflows Der Überblick zu ausgewählten Verarbeitungsaspekten wird nun mit der Diskussion von Verteilungsaspekten abgeschlossen. Mit Verteilung ist in diesem Kontext die Einbeziehung mehrerer Middleware-Systeme zur Realisierung einer Transformation gemeint. Hierbei sind zunächst die grundlegenden Konzepte der Verarbeitung in einem Cluster von TransConnect-Instanzen gegenüber zu stellen.

210

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 86:

Das

Konzept

(A)

verfolgt

Verteilungsaspekte in TransConnect-Clustern

den

Ansatz

mehrere

TransConnect-Instanzen

auf

unterschiedlichen Servern, jedoch mit synchronisierten Repositories in einem Cluster zusammenzufassen, um eine Lastverteilung zu realisieren. Hierbei fungiert eine zentrale TC-Instanz einzig als Lastverteiler und verarbeitet selbst keine Prozesse. Der Prozess der Verteilung bleibt für den Nutzer transparent, da sich der Cluster für diesen wie eine TCInstanz verhält. Bei dem Konzept B bilden zwei TransConnect-Instanzen einen so genannten RecoveryVerbund („Hot-Standby“), indem das System 1 einen Prozess P1 lokal ausführt. Ein System 2 ist zunächst passiv und überwacht lediglich ob das System A noch aktiv ist, indem dieses in regelmäßigen Zeitabständen ein Polling ausführt. Sofern System 1 ausfällt, stellt System 2 den letzten konsistenten Zustand von 1 her und verarbeitet selbst den Prozess P1 weiter. Dies kann noch nicht als verteilter Prozess bezeichnet werden. Im Gegensatz dazu werden bei dem dritten Ansatz (C) wirklich verteilte Prozesse verarbeitet. Hierbei ruft ein Prozess p1 des Systems 1 explizit, mittels des InvokeOperators, einen Prozess p2 des Systems 2 auf. Realisiert wird dies durch die im Abschnitt 6.1.1 eingeführten Teilkomponenten TransConnectAdapter und TransConnectListener.

211

6 Prototypische Realisierung am Beispiel von TransConnect

Prinzipiell sind dabei auch Szenarien vorstellbar, in denen ein System 1 einen Prozess von sich selbst aufruft, so dass rekursive Aufrufsemantiken realisierbar sind. Neben dieser expliziten Variante sind auch implizit verteilte Prozesse vorstellbar, bei denen ein Prozess transparent teilweise von System 1 realisiert und dann der Prozesszustand an System 2 übermittelt wird, welches den Prozess letztendlich erst beendet. Die Entscheidung wann die Verarbeitung von System 1 auf System 2 übergehen soll, kann dabei implizit durch das System, beispielsweise auf Grundlage der Zugehörigkeit der Systeminstanzen und externen Systeme zu bestimmten Subnetzen, getroffen werden.

6.2.3

Stand der Realisierung und offene Problemstellungen

Auf Grund der Komplexität des Themengebietes und des Funktionsumfangs der avisierten Entwicklung von TransConnect 2.0 ist die prototypische Realisierung tatsächlich nur als ein Prototyp anzusehen welcher die Grundlage für die Entwicklung von TC2 bieten kann. Aus dem Grunde ist in diesem Abschnitt kurz auf den Stand der prototypischen Realisierung einzugehen und offene Problemstellungen herauszustellen. Zunächst einmal ist festzustellen, dass der TransConnect 2.0 Server mittlerweile in einem Zustand ist, indem die im folgenden Teilkapitel beschriebenen, Prozesse des Beispielszenarios vollständig funktionieren und dabei eine akzeptable Grundperformance im Millisekunden-Bereich aufweist. Allerdings existiert noch eine Reihe von Implementierungsausständen und offenen Fragen der Realisierung. Die folgende Aufzählung gibt zunächst einen groben Überblick über die einzelnen offenen Punkte. •

Implementierung der nicht betrachteten Teilkomponenten o TransConnect 2.0 Manager o TransConnect 2.0 Admin-Anwendungen o TransConnect 2.0 Testsuite

212

6 Prototypische Realisierung am Beispiel von TransConnect

•

Implementierung offener Punkte des TransConnect 2.0 Servers o fehlende Inbound- und OutboundAdapter o Analyse und Optimierung von Prozesstypen o alternative Nutzung von DataStreaming o Recovery-Prozess für den Fall des Server-Ausfalls o Transaktionssicherheit/Dienstgüte (Quality of Service) o Monitoring von Verarbeitungszeiten und Kontrollflüssen o Realisierung der TransConnect-Clustering-Konzepte o Review hinsichtlich Robustheit/Effizienz/Code-Optimierung o Vervollständigung der Metadatenverwaltung

•

Untersuchen von Problemstellungen o fehlende Designer-Unterstützung (ggf. eigene Adaption) o Unterstützung alternativer Prozessbeschreibungssprachen

Die Implementierung der nicht betrachteten Teilkomponenten umfasst zum einen die Teilkomponenten, welche in dieser Arbeit völlig aus der Betrachtung ausgeschlossen wurden. Zum anderen ist die TransConnect 2.0 Testsuite, auf welche im Abschnitt 6.1.3 kurz eingegangen wurde, zu realisieren. Im Gegensatz dazu betrifft die Implementierung der offenen Punkte des TransConnect 2.0 Servers zwar mehr oder weniger die Themen dieser Arbeit, allerdings konnten auch diese aus Zeitgründen nicht vollständig realisiert werden. So sind beispielsweise die fehlenden Inbound- und OutboundAdapter zu implementieren, da sich in dieser prototypischen Realisierung auf die Implementierung des File- und JDBC-Adapters (OutboundAdapter) und eines Pseudo-SAPListeners (Inbound-Adapter) beschränkt wurde. Außerdem sind hierbei eine Reihe von Einzelkonzepten zu realisieren, welche im Rahmen dieser Arbeit zu mindestens spezifiziert und diskutiert wurden. Während

die

beiden

zuvor

genannten

Hauptpunkte

vor

allem

die

Spezifikationsverfeinerung und die Realisierung der einzelnen Punkte zum Gegenstand haben, existieren auch Problemstellungen, welche einer weiteren Analyse und Untersuchung bedürfen. So ist zum einen die Problematik der BPEL-Designer-

213

6 Prototypische Realisierung am Beispiel von TransConnect

Unterstützung zu analysieren, da zum momentanen Zeitpunkt, auf Grund der Aktualität des WSBPEL-Standards, kein Designer existiert, der vollständig WSBPEL 2.0 realisiert. Zwar befinden sich interessante Projekte wie das „Eclipse BPEL Project“ in der Entwicklung, jedoch ist hier zunächst zu untersuchen, ob diese Lösung eine grafische Nutzung der Erweiterungsmöglichkeiten von WSBPEL unterstützt, da diese in großem Umfang zur Realisierung des MTM eingesetzt wurden. Sollte diese Analyse in einer negativen Einschätzung resultieren, bestünden an dieser Stelle prinzipiell, die folgenden zwei Möglichkeiten. •

Auswahl eines Designers, mit Erweiterungsmöglichkeiten (z.B. bietet der Sybase PowerDesigner eine so genannte Generic Template Language (GTL))

•

Anpassung eines OpenSource-Designers auf die Sprachkonstrukte des MTM

Zum anderen ist über die Unterstützung anderer Prozessbeschreibungssprachen zu entscheiden. Hierbei ist zunächst die Eignung festzustellen und anschließend eine Abbildung dieser externen Sprache auf die interne XML-basierte Repräsentation des MTM zu definieren. Zusammenfassend kann jedoch eingeschätzt werden, dass mit dieser prototypischen Realisierung die theoretischen Konzepte und Modelle dieser Arbeit implementiert wurden und somit deren Umsetzbarkeit demonstriert werden konnte. Der entstandene Prototyp ist letztendlich als funktionale Grundlage für die Entwicklung von TransConnect 2.0 anzusehen.

6.3

Beispielszenario “ETL-Prozess”

Die prototypische Realisierung soll nun mit der Spezifikation eines Beispielszenarios abgeschlossen werden. Hierbei soll die Modellierung mit dem Message Transformation Model (MTM) auf konzeptueller Ebene im Vordergrund stehen.

214

6 Prototypische Realisierung am Beispiel von TransConnect

Da das Produkt TransConnect als Integrationsplattform für EAI- und ETL-Prozesse entworfen wurde, liegt die Auswahl des Beispielszenarios bereits nahe. Um die unterschiedlichsten Aspekte von Transformationsprozessen verdeutlichen zu können, wurde bewusst ein Beispielszenario im Bereich von ETL-Prozessen definiert. Hiermit kann sowohl die Verarbeitung von Tupel-orientierten als auch von Datenmengen-orientierten Prozessen veranschaulicht werden. Natürlich können im Rahmen dieses Teilkapitels die definierten Prozesse nicht aus sämtlichen Perspektiven betrachtet werden. Somit sei an dieser Stelle auf die beiliegende DVD verwiesen, auf deren inhaltliche Struktur im Anhang G eingegangen wird. 6.3.1

Einführung in das Beispielszenario

Das in diesem Abschnitt vorgestellte Beispielszenario wurde aus einem, durch die SQL GmbH im Jahr 2001 erfolgreich realisierten, Projekt der Südsalz GmbH abgeleitet. Hierbei wurden durch TransConnect Daten von einem SAP R/3 System, genauer von den Modulen FI (Financial Accounting), SD (Sales and Distribution), MM (Materials Management) und CO (Controlling) empfangen und tupel-orientiert in eine konsolidierte Datenbank eingebracht. Aus dieser wurden die Daten dann, mit Hilfe eines ETL-Tools, mengenorientiert aller 24 h in ein zentrales Data Warehouse übernommen. Im Weiteren soll nun das daraus abgeleitete Beispielszenario definiert werden. Hierzu ist zunächst der betriebswirtschaftliche Kontext zu erläutern. Die Aktiengesellschaft XYZ (XYZ AG) hat im Jahr 2004 ein partielles Spin-off durchgeführt, indem die Abteilungen Einkauf und Vertrieb in zwei unabhängige Gesellschaften mit beschränkter Haftung ausgegliedert wurden. Allerdings sind beide Gesellschaften mit Einkaufs- und Vertriebsprozessen beauftragt. Die folgende Abbildung zeigt zunächst das Zusammenspiel der einzelnen Gesellschaften des Beispielszenarios.

215

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 87:

Betriebswirtschaftlicher Kontext des Beispielsszenarios

Das führende System in Bezug auf die Nummernvergabe in den Einkaufs- und Vertriebsprozessen ist dabei Bestandteil der IT-Infrastruktur der X GmbH. In regelmäßigen Abständen erfolgt schließlich ein Stammdatenabgleich der Y GmbH. Die derzeitige Hauptproblematik im Jahr 2006 liegt darin begründet, dass bei diesem Spinoff durch die XYZ AG nicht auf eine homogene IT-Infrastruktur geachtet wurde, sondern die Tochtergesellschaften „freie Hand“ bei der Auswahl der Systeme hatten. Somit hat die XYZ AG derzeit keine Sicht auf die ganzheitlichen Daten des Unternehmens, wodurch die Bereiche Einkauf und Vertrieb in globale Auswertungen nicht mit einbezogen werden können. Auf Grund dieser Gegebenheit entschied die Konzernleitung der XYZ AG, dass ein ganzheitliches Data Warehouse aufzubauen ist. Dabei soll lediglich die Konzernleitung ihre Analysen auf dem eigentlichen Data Warehouse und damit auf dem ganzheitlichen Datenbestand durchführen. Für die einzelnen Tochtergesellschaften werden, aus Performance-Fragen sowie aus firmenpolitischen Gründen, physische Teilmengen der Gesamtsicht zur Auswertung bereitgestellt. Nachdem nun der betriebswirtschaftliche Kontext erläutert wurde, ist im Weiteren auf die eigentliche Systemarchitektur des Beispielszenarios einzugehen. Die folgende Abbildung visualisiert

zunächst

den

logischen

Datenfluss

innerhalb

der

angesprochenen

Systemarchitektur.

216

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 88:

Systemarchitektur des Beispielszenarios

Um den grundlegenden Datenfluss innerhalb dieses Szenarios zu erläutern, sollen nun auch die einzelnen Datenschemata in die Betrachtung mit aufgenommen werden. So werden, initiiert durch Geschäftsvorfälle im SAP, Daten der X GmbH, mittels des IDoc-Formats, unmittelbar in die konsolidierte Datenbank eingebracht. Dabei werden die speziellen IDocTypen, DEBMAS05, CREAMS03, MATMAS03 und ORDERS05 aus den Modulen SD und MM verwendet. Die Bewegungsdaten von Einkaufs- und Vertriebsprozessen der Y GmbH werden aus einem proprietären System exportiert und im Filesystem als XMLDateien hinterlegt. Da die Y GmbH eine Menge von heterogenen Systemen unterhält, sind vor dem Einbringen der Daten in die konsolidierte Datenbank, spezielle Daten aus einer CRM-Datenbank nachzuladen, welche physisch in einem MS SQL Server verwaltet wird. Das Schema der konsolidierten Datenbank (KDB) entspricht einem erweiterten TPCHSchema [TPCH05], welches um diverse Flag-Attribute und Zeitstempel erweitert wurde und keinerlei Constraints enthält. Somit werden gegebenenfalls nicht-konsistente Daten und Duplikate zunächst in die KDB eingebracht.

217

6 Prototypische Realisierung am Beispiel von TransConnect

Während zwischen den Quellsystemen und der KDB sehr viele Transaktionen, welche eher tupelorientiert sind, verarbeitet werden, sind die Daten der KDB nur einmal täglich als Datenmenge in das Data Warehouse (DWH) zu übernehmen. Vor einer derartigen Übernahme ist der Prozess des DataCleansings [RADO00], [GALH01], [MUFR03] auszuführen. Anschließend können dann die Daten in das DWH eingebracht werden. Hierbei ist zu erwähnen, dass das DWH exakt dem TPCH-Schema entspricht und alle geforderten Constraints definiert. Nachdem die Daten übernommen wurden, werden die Bewegungsdaten aus der KDB entfernt und die Stammdaten mit einem speziellen Flag versehen. Schließlich soll das Daten-Delta, welches soeben in das DWH eingebracht wurde, ebenfalls auf die beiden DataMarts (DMs) verteilt werden. Hierbei weisen die DMs ein reduziertes TPCH-Schema, jedoch mit unterschiedlichen Bezeichnungen, auf. Bei dem Einbringen der Daten ist darauf zu achten, das in das DM1 nur die Bewegungsdaten der X GmbH und in das DM2 nur die Bewegungsdaten der Y-GmbH aufgenommen werden, wobei die Stammdaten allerdings vollständig in beide DMs einzubringen sind. Auf Grund der Komplexität des Szenarios sowie der speziellen Technologien der einzelnen Systemen soll das Produkt TransConnect 2.0 zur Integration aller am Beispielszenario beteiligten Systeme eingesetzt werden. Abschließend sei an dieser Stelle noch auf den Anhang E verwiesen, indem die einzelnen Daten-Schemata der einzelnen Systeme in Form von Relationenmodellen, XSD-Schemata und im Falle der SAP IDocs als hierarchsische Strukturen dargestellt wurden.

6.3.2

Transformationsprozesse des Beispielszenarios

Im Rahmen dieses Abschnittes sollen nun die einzelnen Transformationsprozesse des Beispielszenarios im Detail erläutert werden. Hierfür sind diese zunächst zu identifizieren und voneinander abzugrenzen. Prinzipiell wird dabei die Vorgehensweise verfolgt, die Prozesse auf konzeptueller Ebene mit Hilfe des MTM und damit graphenorientiert, zu spezifizieren. Die, naturgemäß hierarchische, Beschreibung der Transformationsprozesse

218

6 Prototypische Realisierung am Beispiel von TransConnect

mit WSBPEL wurde im Anhang F beigefügt. Um das einführend dargestellte Beispielszenario zu realisieren, bietet sich auf Grund der unterschiedlichen Verarbeitungs- und Zeitmodelle eine Differenzierung in mehrere Prozesse an. So wird eine Teilung in drei Prozesse vorgenommen, wobei der erste Prozess alternativ im synchronen, als auch im asynchronen Verarbeitungsmodell dargestellt wird. Die folgende Abbildung visualisiert zunächst die Untergliederung in die Teilprozesse.

Abbildung 89:

Untergliederung des Beispielszenarios in Teilprozesse

Dabei wird erkenntlich, dass die Prozesse bs_process1 und bs_process2 eher einzelne Datensätze verarbeiten, während der bs_process3 große Datenmengen handhabt. Im Weiteren wird diese sehr abstrakte Sichtweise verlassen und versucht die drei einzelnen Prozesse auf konzeptueller Ebene im Detail zu erläutern. Der erste Prozess bs_process1 wird durch automatisierte Aufrufe seitens des SAP R/3Systems initiiert. Dafür sind sowohl push-Anfragen im Rahmen von asynchronen Prozessen in TransConnect, als auch push&pull-Anfragen im Rahmen von synchronen Prozessen vorstellbar. Die folgende Abbildung zeigt nun einführend die MTMSpezifikation des bs_process1 als asynchron verarbeiteten Prozess.

219

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 90:

Transformationsprozess bs_process1_async

Vor Beginn dieses Prozesses wurde ein IDoc von dem SAP-System an den InboundAdapter SAP-Listener von TransConnect gesandt. Dieser führte eine Transformation des IDocFormates, unter zu Hilfenahme der speziellen Metadaten, in eine interne XMLRepräsentation aus. Anschließend verteilte der Dispatcher die Nachricht auf die MessageQueue ‚sap_mq’. Da für diesen Nachrichtentyp festgelegt wurde, dass er einen Prozess initiiert, wurde folglich asynchron eine Instanz des Prozesstypen bs_process1 angelegt die nun zur Ausführung gebracht wird. Zunächst wird die MessageQueue aufgerufen und die nächste Nachricht ausgekettet, wodurch die eigentlichen Daten in den Verwaltungsbereich der Prozessinstanz gelangen. Treten hierbei Fehler auf, kommt es zu einem Rollback der MessageQueue für diese spezielle Nachricht. Im Prozess wird nun mittels des Switch-Knotens unterschieden, ob ein IDoc vom Typ DEBMAS, CREAMS, MATMAS oder ORDERS vorliegt. Anschließend werden typspezifische Schematransformationen und Vorbereitungen der INSERTStatements ausgeführt. Sofern keiner der vier erwarteten IDoc-Typen vorliegt, ist die Prozessinstanz sofort zu beenden. Abschließend werden die Daten dann in die Konsolidierte Datenbank eingebracht. Sofern dies alles erfolgreich war kommt es zu einem Commit für die spezifische Nachricht in der MessageQueue und der Prozess kann beendet werden.

220

6 Prototypische Realisierung am Beispiel von TransConnect

Alternativ zu der soeben dargestellten asynchronen Variante kann der gleiche Prozess auch als synchroner Prozesstyp modelliert werden. Die nachfolgende Abbildung zeigt wiederum zunächst die MTM-Spezifikation.

Abbildung 91:

Transformationsprozess bs_process1_sync

Im Wesentlichen unterscheidet sich die synchrone Variante von der asynchronen darin, dass die Transaktionsverwaltung der MessageQueue entfällt und dass ein Receive-Knoten den Prozessstart und ein Reply-Knoten das Prozessende markiert. Auf Grund der einheitlichen internen Verarbeitung auf asynchrone Weise, ist zunächst die ProcessInputNachricht zu lesen und am Ende des Prozesses eine OutputNachricht in Form des ProcessResult zu schreiben. Während das MTM von Grund auf graphenorientiert entworfen wurde, weist WSBPEL eine Mischung aus hierarchischen und graphenorientierten Aspekten auf. Neben der hierarchischen Struktur ist hierbei vor allem die Nutzung der ExtensionActivity zu beachten, welche eine Nutzung der momentanen BPEL-Designer entgegensteht. Im Gegensatz zum ersten Prozess wird der zweite Process bs_process2 nicht durch ein externes System, sondern durch die interne Zeitsteuerung von TransConnect, in Form der Scheduler-Komponente, initiiert. Somit ist keine Input-Nachricht, respektive OutputNachricht zu verwalten, so dass direkt mit der asynchronen Verarbeitung eines Prozesses dieses Prozesstyps begonnen werden kann. Die folgende Abbildung zeigt die MTM-

221

6 Prototypische Realisierung am Beispiel von TransConnect

Spezifikation dieses Prozesstyps auf konzeptueller Ebene.

Abbildung 92:

Transformationsprozess bs_process2

Zu Beginn des Prozesses ist eine so genannte Pickup-Mask zum Lesen aus dem Filesystem zu definieren. Diese Leseoperation wird dann anschließend durch das Invoke des FileAdapters ausgeführt. Hierbei werden eine unbestimmte Menge von Dateien gelesen und in Form einer Nachricht zurückgegeben. Diese gilt es nun mit Hilfe des Split-Knoten in n Nachrichten aufzuteilen, wobei n gleich der Anzahl der Dateien ist. Da Konflikte hinsichtlich der Reihenfolge der Verarbeitung in diesem Szenario nicht ausgeschlossen werden können, sind die Nachrichten im Weiteren aufsteigend nach dem Zeitstempel des letzten Schreibens dieser Datei zu sortieren. Anschließend wird eine Schleife, ebenfalls in Abhängigkeit der Anzahl der Dateien, durchlaufen. Hierbei ist darauf zu achten, dass das

222

6 Prototypische Realisierung am Beispiel von TransConnect

konzeptuelle MTM auf Grund der Graphenorientierung keine Konstrukte für Iterationen bereitstellt. An dieser Stelle sei jedoch angemerkt, dass sowohl die externe BPELRepräsentation, als auch die interne XML- und Java-Repräsentationen hierfür Sprachbestandteile anbieten. Im Rahmen einer Iteration wird zunächst ein Switch-Knoten ausgewertet, wobei der Typ der Dateien evaluiert wird. Sofern eine Datei vom Typ *.vertrieb ist, kommt es zu einer Schematransformation und einer Vorbereitung von SELECT-Statements. Diese werden benötigt um aus der CRM-Datenbank den Name des Kundenbetreuers nachzuladen. In einem weiteren Schritt wird dann ein Join der Bestellungen

mit

den

Namen

entsprechend

der

Kundennummer

durchgeführt.

Anschließend sind die INSERT-Statements vorzubereiten. Ist die Datei vom Typ *.einkauf stellt sich die Sache einfacher dar, da hier keine Daten nachzuladen sind. So ist lediglich die Schematransformation und die Vorbereitung der INSERT-Statements auszuführen. Wird ein unbekannter Typ geladen, muss der Prozess sofort beendet werden. Unabhängig von dem Typ der Datei wird wiederum eine Validierung der Ergebnisnachricht vorgenommen und ein Union mit den bereits vorbereiteten Statements durchgeführt. Der Prozess wird dann letztendlich abgeschlossen, indem die Daten äquivalent zu dem bs_process1 in die konsolidierte Datenbank eingebracht werden. Auch für diesen Prozesstyp soll kurz die WSBPEL-Beschreibung erwähnt werden. Hierbei ist besonders auf Unterschiede der Schleifenkonstrukte und die Notwendigkeit der umfangreichen Nutzung der ExtensionActivity zu achten. Auch der dritte Prozess bs_process3 wird durch den Scheduler des TransConnect initiiert und folgt somit dem bs_process2 mit einem äquivalenten Verarbeitungsmodell. Im Gegensatz zu den ersten beiden Prozessen ist dieser jedoch nicht tupelorientiert sondern verarbeitet Datenmengen. Auch für diesen Prozesstyp soll zunächst die konzeptuelle MTMSpezifikation dargestellt werden.

223

6 Prototypische Realisierung am Beispiel von TransConnect

Abbildung 93:

Transformationsprozess bs_process3

Eines der Hauptprobleme, welches sich bei der Übernahme der Daten aus der konsolidierten Datenbank in das Data Warehouse und später in die Data Marts ergibt, ist die Behandlung von Duplikaten. Hier bieten sich mehrere Möglichkeiten an. So könnten alle Schlüssel der Datensätze ermittelt werden welche noch nicht in das Data Warehouse eingebracht wurden, um diese Datensätze dann in einem Delta-Update in den Datenbestand zu übernehmen. Eine weitere Variante ist die so genannte UPSERT (UPdate/inSERT)Funktionalität einiger DBMS, bei der über Parameter das Verhalten bei duplikaten Schlüsseln determiniert werden kann. Im vorliegenden Prozess wird eine dritte Variante genutzt, wobei alle übernommenen Datensätze in der konsolidierten Datenbank mit einem

224

6 Prototypische Realisierung am Beispiel von TransConnect

Flag markiert werden und damit letztendlich auf effiziente Weise nur das Daten-Delta geladen werden kann. Um dies zu realisieren ist in einem ersten Schritt ein StoredProcedure-Aufruf vorzubereiten, um das in der Einführung angesprochene, DataCleansing durchzuführen. Nachdem diese Verarbeitung in der konsolidierten Datenbank abgeschlossen ist, kann das Daten-Delta relativ einfach geladen werden. Hierbei ist zu beachten, dass bei diesem Schritt jegliche Stamm- und Bewegungsdaten geladen werden, welche noch nicht übernommen wurden. Direkt im Anschluss können diese Daten nun ohne Schematranslationen in das Data Warehouse eingebracht werden. Nachdem dies ausgeführt wurde, erfolgt die Schematranslation in das Zielschema der Data Marts direkt auf dem geladenen Daten-Delta. Nun soll jedoch nicht die gesamte Menge der Daten in beide Data Marts eingebracht werden. Aus diesem Grunde wird an dieser Stelle eine Parallelverarbeitung initialisiert, welche zwar nicht zwingend erforderlich ist, jedoch ein gewisses Optimierungspotential in sich birgt. In der ForkLane 1 werden nun Selektionen hinsichtlich der Bewegungsdaten der X GmbH vorgenommen, während in der ForkLane 2 Selektionen hinsichtlich der Y GmbH errechnet werden. Damit wurden die Bewegungsdaten des geladenen Daten-Deltas disjunkt getrennt, während die Stammdaten in beiden Fällen vollständig erhalten blieben. Abschließend werden die ausschließlich für die Selektion benötigten Attribute entfernt und letztendlich die Daten in die spezifischen Data Marts eingebracht. Um die eingebrachten Daten als verarbeitet zu markieren wird zum Schluss abermals eine Stored Procedure in der konsolidierten Datenbank aufgerufen, welche die speziellen Flags für die Stammdaten setzt und aus Effizienzgründen einen Teil der Bewegungsdaten aus dem Datenbestand entfernt. Zusammenfassend ist festzustellen, dass im Rahmen dieser prototypischen Realisierung die Umsetzbarkeit des Message Transformation Model (MTM) gezeigt werden konnte und ein Architekturvorschlag derart entworfen und implementiert wurde, dass dieser die fundierte Grundlage für die vollständige Entwicklung von TransConnect 2.0 bilden kann. Allerdings existieren natürlich noch offene Problemstellungen, die es im Nachgang dieser Arbeit zu erörtern gilt.

225

7 Zusammenfassung und Ausblick

7

Zusammenfassung und Ausblick

Abschließend sind zum einen die Ergebnisse dieser Arbeit zusammen zu fassen und Schlussfolgerungen

zu

ziehen,

welchen

Einfluss

diese

Ergebnisse

auf

die

Weiterentwicklung von TransConnect und auf die Fortführung von wissenschaftlichen Untersuchungen auf dem Gebiet der komplexen Nachrichtentransformation haben kann. Zum anderen soll ein Ausblick auf relevante Entwicklungen von Standards und Technologien auf diesem Gebiet, aus der momentanen Perspektive heraus, gegeben werden.

7.1

Zusammenfassung der Ergebnisse

Die Ergebnisse dieser Arbeit sollen an Hand der vier, in der Einleitung vorgestellten, Perspektiven beschrieben werden. Die theoretische Untersuchung der Funktionalitäten von WSBPEL hat dabei ergeben, dass BPEL prinzipiell sehr gut für die Spezifikation von Dienst-Orchestrierungen und Integrationsprozessen geeignet ist. Trotz der Vielzahl von interessanten Spracherweiterungsvorschlägen und den Alternativen auf unterschiedlichen Abstraktionsebenen, ist jedoch einzuschätzen dass ein Nachrichtentransformationsmodell vor allem bei der Spezifikation des Datenflusses über die Funktionalitäten von BPEL hinausgehen muss. In Bezug auf die Spracherweiterungsvorschläge und die Realisierung des MTM sind besonders die umfassenden Erweiterungsmöglichkeiten von WSBPEL hervorzuheben. Im

Rahmen

der

systematischen

und

strukturierten

Modellbildung

für

Nachrichtentransformationen, wurde das generische Message Transformation Model (MTM) entwickelt. Dieses setzt sich aus einem konzeptuellen Nachrichtenmodell sowie einem konzeptuellen Prozessmodell zusammen und orientiert sich an den Anforderungen der Nachrichtentransformation. Das Modell vereint sowohl ausgeprägte Möglichkeiten der Spezifikationen des Kontrollflusses, als auch des Datenflusses und kann somit in unterschiedlichsten Anwendungsgebieten zum Einsatz kommen.

226

7 Zusammenfassung und Ausblick

Betrachtet man nun WSBPEL hinsichtlich der Eignung zur Beschreibung des MTM, so ist festzustellen, dass die interaktionsorientierten und kontrollflussorientierten Muster problemlos abbildbar sind, da das MTM eine Redundanzarmut aufweist. Die vollständige Beschreibbarkeit der datenflussorientierten Muster resultiert einzig und allein aus der umfassenden Erweiterbarkeit. Somit kann die Aussage getroffen werden, dass WSBPEL prinzipiell die Beschreibung des MTM ermöglicht, wodurch existente grafische Modellierungswerkzeuge wiederverwendet werden könnten. Allerdings wird hinsichtlich der Ausführbarkeit der spezifizierten Prozesse, lediglich ein geringer Grad der Portabilität erreicht, da die genutzte BPEL-Implementation entweder ebenfalls das MTM unterstützen muss oder eben ein Großteil der datenflussorientierten Muster schlicht nicht verwendbar sind. Mit

der

prototypischen

Realisierung

wurde

zunächst

ein

Vorschlag

eines

Architekturentwurfes für die entscheidenden Komponenten von TC2, den TransConnect Server und den TransConnect DataStore unterbreitet. Die Implementierung dieses Entwurfes konnte dabei nicht nur die Umsetzbarkeit des MTM nachweisen, sondern vielmehr, auf Grund des Erreichens einer gewissen Grundperformanz, eine realistische Lösung für die Integration einer Workflow Process Engine in TransConnect 2.0 bieten. Die Spezifikation des Beispielszenarios konnte dabei den Einsatz in unterschiedlichen Anwendungsszenarien und den damit verbundenen Prozesscharakteristika, verdeutlichen.

7.2

Schlussfolgerungen

Nachdem die einzelnen Ergebnisse dieser Arbeit überblicksartig dargestellt wurden, muss man sich natürlich die Frage stellen, welche Auswirkungen diese Ergebnisse auf weitere Untersuchungen und Entwicklungen haben können. Zunächst sind hierbei die Schlussfolgerungen für die Entwicklung von TransConnect 2.0 zu ziehen. So können die Ergebnisse dieser Arbeit die theoretische und mit Einschränkungen, auch praktische Grundlage für die vollständige Entwicklung von TransConnect 2.0 darstellen. Das MTM ist dabei, in Bezug auf die kontinuierliche Entwicklung der

227

7 Zusammenfassung und Ausblick

Anforderungen, ebenfalls dynamisch weiter zu entwickeln. Das MTM stellt die Grundlage für die Unterstützung beliebiger Prozessbeschreibungssprachen dar. Aufbauend auf der Flexibilität des generischen, konzeptuellen Modells kann sich von einer primären Fixierung auf EAI-Prozesse gelöst und der Aspekt der Unterstützung beliebiger Integrationsprozesse in Form der Informations-, Anwendungs- und Prozessintegration, im Rahmen eines Enterprise Service Bus (ESB), in den Mittelpunkt der Produktdarstellung gerückt werden. Neben den Schlussfolgerungen für die Entwicklung von TransConnect, sind jedoch auch Auswirkungen auf wissenschaftliche Forschungsbemühungen denkbar. So existieren bislang

keine

vollständig

spezifizierten

Modelle

für

die

komplexe

Nachrichtentransformation, beziehungsweise die Prozessbeschreibung von datenintensiven Prozessen. Hier kann das Message Transformation Model (MTM) einen generischen Ausgangspunkt für Spezialmodelle auf den Gebieten EAI, ETL, Message-Queueing und anderen Anwendungsgebieten bilden. Dabei existieren noch eine Reihe von Aspekten die weiterführenden Untersuchungen bedürfen. So ist das spezifizierte Kostenmodell zu verfeinern und die Analyse und Optimierung von Transformationsprozessen genauer zu spezifizieren. Auf Grund der wichtigen nicht-funktionalen Anforderung einer effizienten Verarbeitung sind performantere Algorithmen für die einzelnen Operatoren des MTM zu finden. Die Hauptschwierigkeit liegt hierbei in der zusätzlichen Dimension des Nachrichtenmodells in Form der rekursiven Strukturen.

7.3

Ausblick

Abschließend soll ein Blick auf zukünftige Entwicklungen auf dem Gebiet der Prozessbeschreibung im Allgemeinen und der komplexen Nachrichtentransformation in speziellen Anwendungsgebieten geworfen werden. Prinzipiell ist zu erwarten, dass eine Konsolidierung der Prozessbeschreibungssprachen hinsichtlich ihrer Abstraktionsebenen erfolgen wird. So kann davon ausgegangen werden, dass sich WSBPEL 2.0 innerhalb der Realisierungsebene noch weiter durchsetzen und eine gewisse Vormachtstellung einnehmen wird. Dies ist vor allem durch die starke

228

7 Zusammenfassung und Ausblick

Unterstützung

aus

Industrie und

Wissenschaft, sowie durch den

umfassenden

Standardisierungsprozess, einschließlich der Spracherweiterungen für Spezialprobleme, zu begründen. Deshalb erscheint es aus dem derzeitigen Blickwinkel als überaus sinnvoll innerhalb der SQL GmbH Knowhow auf diesem Gebiet aufzubauen. BPEL wird nicht nur im Rahmen des Produktes TransConnect, sondern vielmehr auch im Projektgeschäft eine zunehmend wichtigere Rolle spielen. Speziell für WSBPEL ist kurzfristig die vollständige Unterstützung der Version 2.0 durch die führenden BPEL-Implementationen zu erwarten, was momentan schlicht noch nicht der Fall ist. Dabei wird es zu einer Marktbereinigung kommen, der viele kleinere derzeitige Implementationen zum Opfer fallen werden. Für die Beschreibbarkeit des MTM mit WSBPEL wird die Funktionalität der BPEL-Designer zu untersuchen sein, in wie weit diese, die Erweiterungsmöglichkeit der Sprache tatsächlich realisieren. Mittelfristig sind weitere Spracherweiterungen zu erwarten, welche alle samt Spezialprobleme adressieren. So wäre unter anderen die Publikation der, für das MTM erforderlichen, Erweiterungen als „WSBPEL Extension for Message Transformation (WSBPEL-MT)“ vorstellbar. Auf dem Gebiet der Modellbildung für datenintensive Prozesse der komplexen Nachrichtentransformation ist ebenfalls eine Konsolidierung zu erwarten. So konvergieren die Beschreibungen von Workflows, von EAI- und ETL-Prozessen, sowie von Prozessen des MessageQueueings. Aus dieser Konvergenz heraus und der Tatsache des Mangels an generischen Modellen, ist mit einer umfassenden Modellbildung auf diesem Gebiet zu rechnen, zu der das definierte Message Transformation Model (MTM) einen Teil beitragen kann.

229

Anhang

Anhang A Metagrammatik von WSBPEL 2.0 In diesem Anhang ist die Metagrammatik von WSBPEL 2.0, welche in Fragmenten in [BPEL06] enthalten ist, zusammengefasst worden. ? * * ? + ? + ? + ? + ? * activity ? activity ? * ? + * ... * (durationexpr | deadline-expr )? duration-expr ? ... activity

Ein activity-Element kann dabei eine der nachfolgend dargestellten Aktivitäten sein: standard-elements ( from-spec

231

Anhang

to-spec | ...assign-element-of-other-namespace... ) + standard-elements standard-elements standard-elements standard-elements ( duration-expr | deadline-expr ) standard-elements standard-elements activity+ standard-elements ... bool-expr ... activity * ... bool-expr ...

232

Anhang



activity ? activity

standard-elements ... bool-expr ... activity standard-elements activity ... bool-expr ... standard-elements + ? + * activity * (duration-expr | deadline-expr) activity standard-elements ? + activity+

233

Anhang

standard-elements unsigned-integer-expression unsigned-integer-expression ? unsigned-integer-expression ... standard-elements ? + * standard-elements ? + * standard-elements ?

234

Anhang

+ * activity ? activity ? activity * * standard-elements ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... ? ... ? ... see above under for syntax ... activity

235

Anhang

standard-elements standard-elements standard-elements standard-elements

236

Anhang

B Metagrammatik der internen XML-Beschreibung des MTM Im Rahmen dieses Anhangs soll, in Analogie zu Metagrammatik von WSBPEL, die Metagrammatik der internen XML-Beschreibung des MTM dargestellt werden.

* * * activity* actitvity:= invoke | receive | switch | flow | delay | validate | translation | selection | projection | join | setoperation | split | oderby | action

Interaktionsorientierte Muster activity* activity*

237

Anhang





Kontrollflussorientierte Muster activity* * activity* activity* (1000 | 165165165156)+ * activity*

? activity*

238

Anhang



Datenflussorientierte Muster * * * *

*

+ *

240

Anhang

C Relationenmodell des TransConnect DataStore

241

Anhang

D Physischer Datenbankentwurf des TransConnect DataStore Der physische Datenbankentwurf wird am Beispiel des DBMS Sybase Adaptive Server Enterprise 15 (ASE 15) vorgestellt. An dieser Stelle soll jedoch auf die ganzheitliche Darstellung,

auf

Grund

der

Komplexität,

verzichtet

und

lediglich

Teilaspekte

herausgegriffen werden. Storage Definition Language (SDL) DISK INIT name = "disk07", physname = "data\disk07.dat", vdevno = 7, size = 204800, -- 204800 (blocks) * 4096 (pagesize) = 800 MB dsync = true go -- Initialisierung anderer Database und Dump Devices IF EXISTS( SELECT 1 FROM master.dbo.sysdatabases WHERE NAME = 'MessagePool') BEGIN USE master DROP DATABASE MessagePool END go USE master go CREATE DATABASE MessagePool ON disk07 = 150 –- 150 MB auf dem „data device“ disk07 LOG ON disk08 = 20 -- 20 MB auf dem „log device“ disk08 go

Data Definition Langugae (DDL) Bei der Datendefinition wurde einer Reihe von Grundregeln gefolgt, welche zunächst genannt und gleichzeitig mit Beispielen untersetzt werden:

242

Anhang

•

Primärschlüssel wurden stets als numerische Datentypen definiert, wobei zusammengesetzte Primärschlüssel nicht gänzlich vermieden wurden

•

Fremdschlüssel wurden ebenfalls als numerische Datentypen definiert

•

Prinzipiell kamen Domänen für die Definition von Datentypen zum Einsatz

•

EXECUTE sp_addtype d_flag, 'BIT', 'NOT NULL' EXECUTE sp_addtype d_id_long, 'NUMERIC(15,0)', 'NOT NULL' EXECUTE sp_addtype d_id_short,'SMALLINT', 'NULL'

Um Abhängigkeiten und Charakteristika von Daten direkt im physischen Datenbankentwurf abzubilden, kamen Defaults und Rules zum Einsatz

•

CREATE DEFAULT df_priority AS 5 CREATE DEFAULT df_timestamp AS getdate() go EXECUTE sp_bindefault 'df_priority', 'ProcessType.Priority' EXECUTE sp_bindefault 'df_timestamp','MessageQueue.Timestamp' go

Indices kommen generell implizit als CLUSTERED Index (Blätter enthalten die Datenseiten) bei jedem Primärschlüssel und explizit als NONCLUSTERED Index (Blätter enthalten Indexseiten) bei jedem Fremdschlüssel sowie bei ausgewählten Attributen zum Einsatz. In Ausnahmefällen werden teilweise auch Primärschlüssel als NONCLUSTERED definiert.

•

CREATE UNIQUE INDEX Iu_name ON ProcessType ( Name ASC ) CREATE INDEX I_ProcessLanguage ON ProcessType ( LID ASC ) go

Darüber hinaus wurde jedoch explizit auf Identities (Sybase SequenzGenerator), Stored Procedures, Trigger, XML- und Java-Funktionalitäten verzichtet um einen hohen Portabilitätsgrad hinsichtlich des DBMS zu erreichen.

•

Prinzipielle Deaktivierung von AutoCommit SET ’CHAINED ON’

Nachfolgend soll lediglich exemplarisch die Definition der Relation Message verdeutlicht werden.

243

Anhang

CREATE TABLE Message ( MID d_id_long NOT DID d_id_long NOT MTID d_id_short NOT Type VARCHAR(255) NOT State SMALLINT NOT Creator d_name NOT Created d_timestamp NOT Modified d_timestamp NOT constraint PK_MESSAGE primary key nonclustered (MID) ) go

NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

ALTER TABLE Message ADD CONSTRAINT fk25 FOREIGN KEY (State) REFERENCES MessageState (State) ALTER TABLE Message ADD CONSTRAINT fk15 FOREIGN KEY (DID) REFERENCES DataTable (DID) ALTER TABLE Message ADD CONSTRAINT fk13 FOREIGN KEY (MTID) REFERENCES MessageType (MTID) go

Abschließend soll noch die Frage der Zugriffrechte veranschaulicht werden. EXECUTE sp_addlogin ’transconnect’, ’tc2’, ’MessagePool’ EXECUTE sp_adduser ’transconnect’ GRANT ALL ON Message to transconnect

244

Anhang

E Schemata des Beispielszenarios Im Rahmen dieser Anlage wird ein Überblick über die einzelnen Datenschemata des Beispielszenarios gegeben. Die nachfolgende Tabelle gibt zunächst einen groben Überblick. Systemkategorie Systemname

Schemabeschreibung

Quellsystem

IDoc-Typen DEBMAS05, CREAMS03, MATMAS03 oder ORDERS05 XSD für Dokumente des Vertriebs und des Einkaufs CRM-DB mit Mitarbeitern, Kunden und Kundenbeziehungen Erweitertes TPCH-Datenbankschema, mit zusätzlichen Flag- und TimestampAttributen TPCH-Datenbankschema reduziertes TPCH-Datenschema, wobei die Bezeichnungen vom TPCH abweichen

SAP R/3-System XML-Dateien MS SQL Server

Konsolidierte DB

Sybase ASE 15

Data Warehouse Data Marts

Sybase ASIQ 12.6 IBM DB2 UDB 8.2 Oracle Database 10g

Tabelle 18:

Datenschemata des Beispielszenarios

Um die Übersichtlichkeit zu wahren wird hier, für das Quellsystem SAP R/3, lediglich das Schema des IDoc DEBMAS05 veranschaulicht. Dieses weist die folgende logische Struktur auf, wobei die Attribute außer Acht gelassen wurden [SAPIFR]. Segmentname

Beschreibung

E1KNA1M [1:1] E1KNA11 [0:1] E1KNA1H [0:999999] E1KNA1L [0:999999] E1KNVVM [0:9999] E1KNVPM [0:9999] E1KNVDM [0:9999] E1KNVIM [0:9999] E1KNVLM [0:9999] E1KNVVH [0:999999] E1KNVVL [0:999999] E1KNB1M [0:9999] E1KNB5M [0:9999]

Master Kundenstamm Grunddaten (KNA1) Kundenstamm: zusätzliche allgemeine Felder (KNA1) Master Kundenstamm Grunddaten: Texte, Kopf Master Kundenstamm Grunddaten: Textzeile Master Kundenstamm Vertriebsdaten (KNVV) Master Kundenstamm Partnerrolllen (KNVP) Master Kundenstamm Dokumentenanforderung (KNVD) Master Kundenstamm Steuerindikatoren (KNVI) Master Kundenstamm Lizenzen (KNVL) Master Kundenstamm Vertriebsdaten: Texte, Kopf Master Kundenstamm Vertriebsdaten: Textzeile Master Kundenstamm Buchungskreis (KNB1) Master Kundenstamm Mahndaten (KNB5)

245

Anhang

Segmentname E1KNB1H [0:999999] E1KNB1L [0:999999] E1KNBKM [0:9999] E1KNVAM [0:9999] E1WRF12 [0:9999] E1WRF4M [0:9999] E1KNVKM [0:9999] E1KNVKH [0:999999] E1KNVKL [0:999999] E1KNEXM [0:999999] E1KNASM [0:999999] E1KNKAM [0:1] E1KNKKM

[0:9999]

Beschreibung Master Kundenstamm Buchungskreis: Texte, Kopf Master Kundenstamm Buchungskreis: Textzeile Master Kundenstamm Bankverbindungen und Bankenstamm Master Kundenstamm Abladestellen (KNVA) Segment für Werk/Empfangsstellen Segment für Werk/Abteilungen Master Kundenstamm Ansprechpartner (KNVK) Master Kundenstamm Ansprechpartner: Texte, Kopf Master Kundenstamm Ansprechpartner: Textzeile Master Kundenstamm Exportdaten Master Kundenstamm Zusätzliche EG-Steuernummer Master Kundenstamm Kreditmanagement Zentraldaten (KNKA) Master Kundenstamm Kreditmanagement Kontrollber.daten (KNKK) Master Kundenstamm Kreditmanagement: Text, Kopf Master Kundenstamm Kreditmanagement: Text, Zeile Kundenstamm: Kreditkartendaten Segment für Werksstamm Segment für Lieferwerk zeitabhängig Segment für Werk/Händler-ID der Kreditkartenunternehmen Segment für Werk/Warengruppen Segment für Wertartikelfindung Segment für Ausnahmen der Wertartikelfindung

E1KNKKH [0:999999] E1KNKKL [0:999999] E1VCKUN [0:999999] E1WRF1M [0:9999] E1WRF3M [0:9999] E1WRF5M [0:9999] E1WRF6M [0:9999] E1T023W [0:9999] E1T023X [0:9999] Tabelle 19: Hierarchische Struktur des IDOC-Typen DEBMAS05 nach [SAPIFR]

Die XML-Dateien folgen im Weiteren ebenso spezifischen Schemata. Dieses wurden in den Dateien Vertrieb.xsd und Einkauf.xsd definiert.

Abbildung 94:

XML-Schema Einkauf

246

Anhang

Abbildung 95:

XML-Schema Vertrieb

Die Schemata der Quellsysteme werden durch das folgende Relationenmodell der CRMDB komplettiert.

Abbildung 96:

Relationenmodell CRM-DB

Abschließend soll nun noch stellvertretend für die Schemata der Konsolidierten DB, des

247

Anhang

Data Warehouse und der einzelnen Data Marts das Schema des TPCH-Benchmarks [TPCH05] veranschaulicht werden.

Abbildung 97:

Relationenmodell TPCH-Benchmark nach [TPCH05]

248

Anhang

F WSBPEL-Transformationsprozesse des Beispielszenarios Dieser Anhang enthält die WSBPEL-Beschreibungen der Transformationsprozesse des Beispielszenarios. Somit bilden diese die externe Beschreibung der, in Abschnitt 6.3.2 abgebildeten, konzeptuellen Transformationsprozesse.

Abbildung 98:

WSBPEL-Transformationsprozess bs_process1_async

Abbildung 99:

WSBPEL-Transformationsprozess bs_process1_sync

249

Anhang

Abbildung 100: WSBPEL-Transformationsprozess bs_process2

Abbildung 101: WSBPEL-Transformationsprozess bs_process2

250

Anhang

G Inhaltliche Struktur der beiliegenden DVD Verzeichnisstruktur Beispielszenario

Inhaltsbeschreibung Prozessbeschreibungen der unterschiedlichen Überführungsebenen (BPEL, MTM, Java), incl. Daten Schemata und Testdaten (Prozesse, Schemata, Testdaten)

Diplomarbeit

Aufgabenstellung, Thesen sowie die eigentliche Diplomarbeit in unterschiedlichen Formaten

Literatur

Referenzierte Literatur, sofern digital verfügbar (Diplomarbeiten, Dissertationen, EBooks, Paper, Sonstiges, Spezifikationen, Vorlesungsunterlagen, Vorträge)

Paper

„Working Draft“ eines Papiers für die BTW 2007, mit dem das definierte Message Transformation Model (MTM) publiziert werden soll.

Präsentationen

Auswahl von Präsentationen, welche im Zeitraum der Diplomarbeit gehalten wurden.

TransConnect1.3

Dokumentation des Istzustandes von TransConnect (incl. der, vor Beginn der Diplomarbeit, erstellten Entwürfe für TransConnect 2.0)

TransConnect2.0

Prototypische Realisierung am Beispiel von TransConnect 2.0 (Java Projektverzeichnis), incl. eines vorkonfigurierten SQL Servers (Sybase ASE 15) der alle Datenbanken des Beispielszenarios enthält.

Tabelle 20:

Inhaltliche Struktur der beiliegenden DVD

251

Literaturverzeichnis

Literaturverzeichnis ALFI06

ALBRECHT, J; FIEDLER,M: Datenbank-Tuning – einige Aspekte am Beispiel von Oracle 10g, Datenbankspektrum Heft 16, 02/2006

ANSI75

ANSI/ Standards Planning and Requirements Commitee (SPARC); 1975

ARIS06

ARIS Plattform, IDS Scheer AG, http://www.ids-scheer.de/, 2006

ASHM04

ASHMORE, D. C.: The J2EE Architect’s Book – How to be a successful technical architect for J2EE applications, DVT Press, Lombard, 2004

BART05

BARTONIZ, M.: BPMS, BPML, BPEL, BPMN, WMS, XPDL, … - Alles ist so schön bunt hier, Artikel, http://www.bpm-guide.de/articles/17, 2005.

BAUM90

BAUMGARTEN, B: Petri-Netze, Grundlagen und Anwendungen, BIWissenschaftsverlag, Zürich, 1990

BECK04

BECKER, O.: Serielle Transformationen von XML – Probleme, Methoden, Lösungen, Humboldt-Universität zu Berlin, MathematischNaturwissenschaftliche Fakultät II, Dissertation, 2004

BERL04

BERLEA, A.: Efficient XML Processing with Tree Automata, Technische Universität München, Fakultät für Informatik, Dissertation, 2004

BEXA04

BEA, IBM: BPELJ : BPEL for Java, White Paper, 2004

BEXB05

IBM, SAP: WS-BPEL Extension for People – BPEL4People, White Paper, 2005

BEXC05

IBM, SAP: WS-BPEL Extension for Sub-processes – BPEL-SPE, White Paper, 2005

BEXD04

IBM: Information Integration for BPEL on WebSphere Process Server, Manual, 2005

BHAR05

BHARTI, N.: ESB vendors enhance their 'SOA middleware', Artikel, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1 071210,00.html, 2005

BIRO03

BIRAMEN, E.: Web Services – Aktueller Entwicklungsstand und Zukunftsaussichten, Wirtschaftsuniversität Wien, Diplomarbeit, 2003

252

Literaturverzeichnis

BITT05

BITTNER, J.: Möglichkeiten zur Integration verschiedener Datenbanken und DB-Applikationen, Vortrag, 108. DB-Stammtisch HTW-Dresden 06/2005

BMIORG

Business Modeling & Integration (BMI) Domain Task Force (DTF), http://bmi.omg.org, ehemals Business Process Management Initiative (BPMI), http://www.bpmi.org/

BPEL03

BEA, IBM, MICROSOFT, SAP, SIEBEL: Business Process Execution Language for Web Services Version 1.1, Spezifikation, 2003

BPEL06

OASIS: Web Services Business Process Execution Language Version 2.0, Spezifikation (Committee Draft), 2006

BPMN06

BMI: Business Process Modelling Notation Version 1.0, Spezifikation, 2006

BPMORG

DUBRAY, J.-J.: Electronic Business Artikelsammlung, http://www.ebpml.org/

BROY98

BROY, M.: Informatik – Eine grundlegende Einführung, Band 2 Systemstrukturen und Theoretische Informatik; Springer-Verlag, Heidelberg, 2. Auflage, 1998

CHEN76

CHEN, P. P.-S.: The Entity-Relationship Model – Toward a Unified View of Data, ACM Transaction on Database Systems, 1976

CODD70

CODD, E. F.: A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, 1970

DADA96

DADAM, P.: Verteilte Datenbanken und Client/Server-Systeme – Grundlagen, Konzepte, Realisierungsformen, Springer-Verlag, Heidelberg, 1996

DEOB96

DESEL, J.; OBERWEIS, A.: Petri-Netze in der Angewandten Informatik: Einführung, Grundlagen und Perspektiven, Wirtschaftsinformatik, 38. Jahrgang, Heft 4, 1996

DESS04

DESSLOCH, S.: Message-oriented Middleware, Vorlesungsunterlagen TU Kaiserslautern, 2005

DIJK69

DIJKSTRA, E. W.: The Programming task Considered as an Intellectual Challenge, Vortrag, Eindhoven, 1969

DIN44300

DIN 44300: Informationsverarbeitung, 1995

Process

Markup

Languages,

253

Literaturverzeichnis

EBBP05

OASIS: ebXML Business Process Specification Schema, Version 2.0.1, Spezifikation, 2005

EICH02

EICHHORN, F: Evaluation von Webservice-Techniken für den Einsatz zur Business-to-Business Integration (B2BI), Friedrich-Alexander-Universität Erlangen-Nürnberg, Institut für Informatik, Lehrstuhl Verteilte Systeme und Betriebssysteme, Diplomarbeit, 2002

FRIT06

FRITZSCHE H., Software-Qualitätssicherung, Vorlesungsunterlagen HTW Dresden, 2006

GAGM06

GALLINA, B.; GUELFI, N.; Mammar, A.: Structuring Business Nested Processes Using UML 2.0 Activity Diagrams and Translating into XPDL, Multikonferenz Wirtschaftsinformatik, 2006

GALH01

GALHARDAS, H.: Declarative Data Cleaning: Language, Model, and Algorithms, 27th VLDB Conference, 2001

GIEVDE

Gesellschaft für Informatik e.V., http://www.gi-ev.de/

GIFP06

Gesellschaft für Informatik, Fachgruppe 0.0.1 - Petrinetze und verwandte Systemmodelle, http://www.informatik.uni-hamburg.de/TGI/GI-Fachgruppe0.0.1/

GMHW98

GOLDMAN, R; MCHUGH, J.; WIDOM, J.: From Semistructured Data to XML: Migrating the Lore Data Model and Query Language, International Conference on Foundations of Data Organization, 1998

GRAY81

GRAY, J.: The Transaction Concept: Virtues and Limitations, Proceedings of Seventh International Conference on Very Large Databases, 1981

GRAY93

GRAY, J.; REUTER, A.: Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, Inc., 1993

HALÖ04

HAUSER, T.; LÖWER, U.: Web Services – Die Standards, Galileo Press, Bonn, 1.Auflage, 2004

HANT06

HANTSCHEL, R.; RUF, F.; STROTBEK, H. : Vergleich von BPEL Laufzeitumgebungen, Universität Stuttgart, Institut für Architektur von Anwendungssystemen, Fallstudie, 2006

HERG03

HERGULA, K.: Daten- und Funktionsintegration durch Föderierte Datenbanksysteme, Technischen Universität Kaiserslautern, Fachbereich Informatik, Dissertation, 2003

254

Literaturverzeichnis

HINZ05

HINZ, S.: Implementierung einer Petrinetz-Semantik für BPEL, HumboldtUniversität zu Berlin, Institut für Informatik, Diplomarbeit, 2005.

HMMS87

HÄRDER, T.; MEYER-WEGENER, K.; MITSCHANG, B.; SIKELER, A.: PRIMA - a DBMS Prototype Supporting Engineering Applications, 13 th International Conference on Very Large Databases, 1987

HOH04a

HOHPE, G.; WOOLF, B.: Enterprise Integration Patterns – Designing, Building and Deploying Message Solutions, Addison-Wesley, Boston, 4.Auflage, 2004

HOH04b

HOHPE, G.: Buchstabensuppe - Was steckt eigentlich hinter ESB, SOA, SOAP, WSDL & Co?, EAI Expertentag, Vortag 25.11.2004

HORN06

HORN, T.: EAI Enterprise Application http://www.torsten-horn.de/techdocs/eai.htm

IBM04a

IBM: Patterns: Implementing an SOA Using an Enterprise Service Bus, Redbook, 2004

IBM04b

IBM: Improve XML transport performance, Part 1: Bandwidth versus processing trade-offs in transporting XML documents, Artikel, http://www-128.ibm.com/developerworks/xml/library/x-trans1.html, 2004

IBM05a

IBM: Model and build ESB SOA frameworks – Adapt service-oriented architectures for easy application integration, Artikel, http://www-128.ibm.com/developerworks/web/library/wa-soaesb/index.html, 2005

IBM05b

IBM: SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus, Artikel, http://www128.ibm.com/developerworks/webservices/library/ws-soa-progmodel4/, 2005

IBM06a

KÖNIG, D.: WSBPEL Standards Roadmap, IBM, MKWI 2006 – Multikonferenz Wirtschaftsinformatik, Vortrag, 22.02.2006

IBM06b

IBM: WebSphere Message Broker - Extended Structured Query Language (ESQL), Manual, http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/ topic/com.ibm.etools.mft.doc/ak00990.htm

ISO9126

DIN 66272: International Standard ISO/IEC 9126: Software Engineering Product Quality, 2004

JECK03

JECKLE, M.; Extensible Markup Language (XML), Vorlesungsunterlagen HS Furtwangen, 2003

Integration,

Artikel,

255

Literaturverzeichnis

JECK04

JECKLE, M.; Web Service, Übersicht verschiedener Begriffsdefinitionen zum Thema Web Service, Artikel, http://www.jeckle.de/webServices/ , 2004

JGOP06

JBOSS: JBoss jBPM – Graph http://docs.jboss.org/jbpm/v3/userguide/, 2006

JUDDI

Java implementation of the Universal Description, Discovery, and Integration (UDDI) specification for Web Services, http://ws.apache.org/juddi/

KELL02

KELLER, W.: Enterprise Application Integration – Erfahrungen aus der Praxis, dpunkt.verlag, Heidelberg, 1.Auflage, 2002

KÜMP04

KÜMPEL, A.: Strategien zur Prozessorchestrierung und WorkflowIntegration in Web-Applikationen, Universität Kaiserslautern, Fakultät Informatik AG Integrierte Kommunikationssysteme, Diplomarbeit, 2004.

LANG05

LAU, H-L; NG, W.: A Unifying Framework for Merging and Evaluating XML Information, 10th International Conference DASFAA, 2005

LAPL04

LAPLANTE, A.: To ESB Or Not To ESB - Although still an evolving concept, the enterprise service bus (ESB) is gaining momentum., Artikel, http://www.webservicespipeline.com/trends/showArticle.jhtml;jsessionid=H MB3T0WEABOHWQSNDBCSKHSCJUMEKJVN?articleId=47205223&pg no=1&queryText=, 2004

LEHN03

LEHNER, W.: Datenbanktechnologie für Data-Warehouse-Systeme – Konzepte und Methoden. dpunkt.verlag, Heidelberg, 1.Auflage, 2003.

LESC04

LEHNER, W.; SCHÖNING, H: XQuery – Grundlagen und fortgeschrittene Methoden, dpunkt.verlag, Heidelberg, 1.Auflage, 2004

LILW02

LIU, D.; LAW, K.; WIEDERHOLD, G.: Analysis of Integration Models for Service Composition, Third International Workshop on Software and Performance, 2002

LILW03

LIU, D.; LAW, K.; WIEDERHOLD, G.: Data-flow Distribution in FICAS Service Composition Infrastructure, 15th International Conference on Parallel and Distributed Computing Systems, 2003

LIND04

LINDHOLM, T.: A Threeway Merge for XML Documents, ACM symposium on Document engineering, 2004

LIUD03

LIU, D : A Distributed Data Flow Model for composing Software Services, Stanford University, Department of Electrical Engineering, Dissertation, 2003

Oriented

Programming,

256

Literaturverzeichnis

LSLW03

LIU, D.; SAMPLE, N.; PENG, J.; LAW, K.; WIEDERHOLD, G.: Active Mediation Technology for Service Composition, Workshop on ComponentBased Business Information Systems Engineering (CBBISE'03), 2003

MAAG03

MAAG, L.: Entwicklung eines Systems zur graphischen Modellierung von Interaktionen zwischen Geschäftspartnern basierend auf bestehenden B2BStandards, Universität Zürich, Institut für Informatik, Diplomarbeit, 2003

MARI02

MARINESCU, F.: EJB Design Pattern – Advanced Patterns, Processes and Idioms, John Wiley & Sons, Inc., New York, 2002

MEIR05

MEIER, A.; MITSCHANG, B.; LEYMANN, F; WOLFSON, D.: On Combining Business Process Integration and ETL Technologies, BTW, Vortrag, 2005

MS04a

MICROSOFT: patterns & practices - Integration Pattern, White Paper excerpt, 2004

MUFR03

MÜLLER, H.; FREYTAG, J.-C.: Problems, Methods, and Challenges in Comprehensive Data Cleansing, Technical Report HUB-IB-164, Humboldt University Berlin, 2003

NIER05

NIERMANN, T.: Modellierung und Automatisierung von Geschäftsprozessen mit Hilfe von UML und BPEL, FHDW-Schriftenreihe Band 08/2004, Shaker Verlag, Aachen, 2005

OASIS

Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/home/index.php

OMGORG

Object Management Group (OMG), http://www.omg.org/

ORA05

KÜHNE, C: Oracle BPEL Process Manager, Oracle Deutschland GmbH, Vortrag, 2005

ORA06

MATJAZ, B.: A Hands-on Introduction to BPEL, Artikel, http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html, 2006

OSTL04

OSTLER, U.: Enterprise Service Bus: Die pragmatische Art zu integrieren, Artikel, http://www.silicon.de/enid/business_software/8995, 2004

OSWI06

OSWI: Open Source Workflow Intiatives, Übersicht Workflow Engine Implemenationen, http://www.gripopprocessen.nl/index.php?id=35#4, 2006

PAGW95

PAPAKONSTANTINOU, Y.; GARCIA-MOLINA, H.; WIDOM, J.: Object Exchange Across Heterogeneous Information Sources, ICDE Conf., 1995

257

Literaturverzeichnis

RADO00

RAHM, E.; DO, H.-H.: Data Cleaning: Problems and Current Approaches, IEEE Bulletin of the Technical Committee on Data Engineering, Vol 23 No. 4, 2000

REBE06

FRANKEN, F.: Der Neue Redenberater 2006, Loseblatt-Werk, Verlag Norman Rentrop, Bonn 2006

SACL79

SELINGER, P. G.; ASTRAHAN, M. M.; CHAMBERLIN, D.D; LORIE, R. A.; PRICE, T. G.: Access Path Selection in a Relational Database Management System, SIGMOD, 1979

SAPIFR

SAP: Interface Repository, Metadatenverzeichnis für IDOC-Nachrichten, http://ifr.sap.com/catalog/query.asp?language=DE

SCHL04

SCHLINGLOFF, H: Qualitätssicherung von Software, Vorlesungsunterlagen Humboldt-Universität zu Berlin, 2004

CDSS98

CLUET, S; DELOBEL, C.; SIMEON, J.; SMAGA, K.: Your mediators need data conversion!, SIGMOD, 1998.

SCST01

SCRIBNER, K; STIVER, M: SOAP developer’s guide – Spezifikation, XML, BizTalk-Server, Markt+Technik Verlag, 2001

SOCO06

EICHHORST, P.: Informations- und Anwendungsintegration mit Serviceorientierten Architekturen (SOA), Socon Inc., Gesellschaft für Informatik Regionalgruppe Dresden, Vortrag 11.04.2006

SQL05a

MELTON, J.: Information technology – Database languages – SQL – Part 14: XML-Related Specifications (SQL/XML) (ISO/IEC 9075-14:2003 (SQL/XML)), 2003

STAH04

STAHL, C: Transformation von BPEL4WS in Petrinetze, HumboldtUniversität zu Berlin, Institut für Informatik, Diplomarbeit, 2004.

STÖH05

STÖHR, K.: Aspekte der Abbildung von Geschäftsprozessen, spezifiziert im Business Process Definition Metamodel, in BPEL4WS, Universität Leipzig Fakultät für Mathematik und Informatik, Diplomarbeit, 2005

TCHB06

SQL GmbH: TransConnect Die Integrationsplattform, Version 1.3.4, Handbuch, 02/2006

TCWS05

SQL GmbH: Workshop TransConnect – Installation, Administration, Anwendung, Entwicklung, Kursunterlagen, 11/2005

258

Literaturverzeichnis

TPCH05

Transaction Processing Performance Council, TPC-H – ad-hoc, decision support benchmark, Revision 2.3.0, http://www.tpc.org/tpch/default.asp, 2005

TUHR98

UHR, T.: Replikationstechnologien für die Kopplung von SAP-R/3 und SQLDatenbanken unter Nutzung eines ALE-Translators, Hochschule für Technik und Wirtschaft Dresden (FH), Fachbereich Informatik/Mathematik, Diplomarbeit, 1998

UDDI04

OASIS: Universal Description, Discovery and Integration 3.0.2, 2004

UML05

OMG: Unified Modeling Language (UML) Specification Version 2.0, 2003 2005

W3CORG

World Wide Web Consortium, http://www.w3.org/

WELT05

WELTE, SVEN: Entwurf serviceorientierter Anwendungen, Universität Kaiserlautern, Diplomarbeit, 2005

WERN98

WERNECKE, D.: Anforderungen an einen ALE-Translator und Konzeption einer Realisierung, Hochschule für Technik und Wirtschaft Dresden (FH), Fachbereich Informatik/Mathematik, Diplomarbeit, 1998

WFMC95

WfMC: Workflow Management Coalition – The Workflow Reference Model, White Paper, 1995

WfMCORG

Workflow Management Coalition (WfMC), http://www.wfmc.org/

WIKIDE

Wikipedia: deutsch, http://de.wikipedia.org/wiki/Hauptseite

WIKIEN

Wikipedia: englisch, http://en.wikipedia.org/wiki/Main_Page

WSCDL05

W3C: Web Services Choreography Description Language Version 1.0, 2005

WSDL01

W3C: Web Services Description Language (WSDL) 1.1, 2001

WSDL06

W3C: Web Services Description Language (WSDL) Version 2.0, 2006

XPDL05

WfMC: Workflow Management Coalition – Process Definition Interface XML Process Definition Language 2.0, 2005

259

Erklärungen

Erklärung über Nutzung und Verwertung 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 01.09.2006 _______________________ Matthias Böhm