Zusammenfassung

F¨ ur Unternehmen wird es immer wichtiger, sich auf ver¨ anderte Wettbewerbsbedingungen schnell einstellen zu k¨ onnen. Bisher konnten ¨ Anderungen der Gesch¨ aftsprozesse jedoch nicht kosteng¨ unstig genug in die IT ¨ ubernommen werden. Viele Unternehmen haben Probleme mit ihren Altsystemen und stehen vor der Herausforderung, neue L¨ osungen zu finden. In diesem Zusammenhang ist die serviceorientierte Architektur ein oft benutztes Schlagwort der IT-Industrie. Ihre Einf¨ uhrung im Unternehmen verspricht ein hohes Maß an Flexibilit¨ at. Gesch¨ aftsfunktionen sind nicht mehr Bestandteil monolithischer Applikationen, sondern als einzelne Services organisiert. Diese Services lassen sich flexibel zusammenschalten und erm¨ oglichen es, Abl¨ aufe eines Unternehmens einfacher anzupassen und zu verbessern. Bei den heute existierenden Standards ist es aber noch immer schwierig, Workflow-Management- und Altsysteme in einer serviceorientierten Architektur zu integrieren. Diese Arbeit versucht, ein Szenario zu entwickeln, welches den beiden genannten Herausforderungen gerecht wird. Dazu wird ausgehend von einem fiktiven End-to-End-Gesch¨ aftsprozess eine serviceorientierte Architektur basierend auf Web Services entwickelt. Abschließend dient eine Auswertung des Szenarios dazu, um tats¨ achliche Vorteile aus der Sicht eines Unternehmens zu analysieren.

Abstract

It becomes more and more important for companies to react fast on changed competition conditions. Until now, it has been difficult and cost-intensive to adapt the IT to changed business processes. Many companies have trouble with their legacy systems and search for solutions to replace them. In this context, the service-oriented architecture is an often used buzzword of the IT-industry. It promises a high grade of flexibility. Business functions are not part of monolithic applications anymore, but designed as independent services. These services can be plugged together and enable a company to adjust and improve workflows easily. However, with the technology standards of today it is still complicated to integrate workflow management systems and legacy applications with a service-oriented architecture. This diploma thesis focuses on these challenges and tries to develop a scenario in which both problems are solved. For that purpose, a service-oriented architecture based on Web service technologies is designed to support a fictive end-to-end business process. In a closing review the actual benefits of the scenario are analyzed from a company’s point of view.

iii

Inhaltsverzeichnis

1  Einleitung  1

1.1  Aktuelle Entwicklungen  1

1.2  Zielsetzung und Vorgehen  3

1.3  Struktur der Arbeit  3

2  Grundlagen  5

2.1  Serviceorientierte Architektur (SOA)  5

2.1.1  Grundbegriffe  5

2.1.2  Einordnung  5

2.1.3  Einsatz  7

2.2  Web Services  8

2.2.1  Definition  8

2.2.2  Basisstandards  8

2.2.2.1  Web Services Description Language (WSDL)  8

2.2.2.2  SOAP  9

2.2.2.3  Universal Description Descovery and Integration (UDDI)  11

2.2.3  Kommunikation  11

2.2.4  Orchestrierung mit der Web Services Business Process Execution  

Language  (WS-BPEL)  12

2.3  Workflow Management (WfM)  13

2.3.1  Gesch aftsprozess  14

2.3.2  Workflow  14

2.3.3  Workflow-Management-System (WfMS)  14

2.3.4  Workflow Management Coalition (WfM)C  15

2.3.5  Workflow Reference Model  15

2.3.5.1  Organisations- bzw. Rollenmodell  15

2.3.5.2  Work List und Work Item  15

2.3.5.3  Workflow-Enigne  16

2.3.6  Bedeutung  17

2.4  Business Process Management (BPM)  18

2.4.1  Definition  18

2.4.2  Einordnung  18

2.4.3  Modellierung mit der Business Process Modeling Notation (BPMN)  18

3  Auswahl von Softwarekomponenten  21

3.1  Konkrete Architektur - Teil 1  21

3.2  Auswahl einer Workflow-Engine  22

3.2.1  Kriterien der Vorauswahl  23

3.2.2  Markt ubersicht und Vorauswahl  23

3.2.3   

Ubersicht  der vorausgew ahlten Produkte  25

3.2.3.1  Enhydra Shark  26

3.2.3.2  Imixs  26

3.2.3.3  Intalio BPMS  26

3.2.3.4  JBoss jBPM  27

3.2.3.5  ObjectWeb Bonita  27

3.2.4  Kriterien der Endauswahl  27

3.2.5  Endauswahl  28

iv

3.2.6 Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3 Auswahl weiterer Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Eclipse Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.3 Tomcat und Axis2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.4 soapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Konkrete Architektur - Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Intalio|BPMS 32

4.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Intalio|Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.1 BPMN-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2 Process Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.3 Data Mapper und Data Editor . . . . . . . . . . . . . . . . . . . . . 34 4.3 Intalio|Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.1 BPMS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.2 Deployment Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Intalio|Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4.1 Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4.2 Workflow UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.3 Rollenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.4 Form Dispatcher Service . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.5 Form Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4.6 Workflow Deployment Service . . . . . . . . . . . . . . . . . . . . . . 38 4.5 Prozessentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.5.1 Aufruf von Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.5.2 Erstellen von People Activities . . . . . . . . . . . . . . . . . . . . . 39 4.5.3 Eigenwillige Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.6 Unterschiede zu klassischen BPM-Produkten . . . . . . . . . . . . . . . . . 41

5 Integration von Altsystemen 43

5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Generisches System zur Ausf¨ uhrung von Applikationen . . . . . . . . . . . . 44 5.4.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4.2 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5 Einbettung in eine Infrastruktur zur Integration in WS-BPEL-Prozesse . . 46 5.5.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.5.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.5.3 Getroffene Designentscheidungen . . . . . . . . . . . . . . . . . . . . 48

5.5.4 Schnittstellenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . 50 5.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

v

6 Entwicklung eines Szenarios 53

6.1 Eingrenzung des Diskursbereichs . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2 Modellierung des Prozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3 Verwendete Softwaresysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.1 Sapienter JBilling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.3.2 Mozilla Thunderbird . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3.3 OpenOffice.org Writer . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.4 Design des Prozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.4.1 Verfeinerung der Prozessschritte . . . . . . . . . . . . . . . . . . . . 57 6.4.2 Einf¨ uhrung von Unterprozessen . . . . . . . . . . . . . . . . . . . . . 59 6.4.3 Identifikation von Services . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4.4 Datenschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.5 Entwicklung der Workflow-Elemente . . . . . . . . . . . . . . . . . . . . . . 62 6.5.1 Konkretes Rollenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.5.2 Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.6 Entwicklung der Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.6.1 Web Service CarBilling . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.6.2 Web Service CarData . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.6.3 Web Service CarDocument . . . . . . . . . . . . . . . . . . . . . . . 67 6.7 Integration der entwickelten Komponenten . . . . . . . . . . . . . . . . . . . 69 6.7.1 Einrichtung der Client-PCs . . . . . . . . . . . . . . . . . . . . . . . 69 6.7.2 Einrichtung des Server-PCs . . . . . . . . . . . . . . . . . . . . . . . 69 6.7.3 Ver¨ offentlichung des Prozesses . . . . . . . . . . . . . . . . . . . . . . 70

7 Ergebnis, Bewertung und Ausblick 72

7.1 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2.1 Bewertung der Altsystemintegration . . . . . . . . . . . . . . . . . . 72

7.2.2 Bewertung des Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.1 Einsatz in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.2 Datensicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.3 Dynamische Bindung der Web Services . . . . . . . . . . . . . . . . 75 7.3.4 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Rekapitulation 76

Literatur 77

vi

Abbildungsverzeichnis

1 Model of Service-Layers and -Interactions (SL&I), aus Offermann u. a. 2007, Abbildung 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Services can encapsulate varying amounts of logic, aus Erl 2005, Abbildung 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint, aus Erl 2005, Abbildung 5.16 . . . . . . . . . . 9 4 The basic structure of a SOAP message, aus Erl 2005, Abbildung 5.21 . . . 10 5 Web-Service-Kommunikation, nach Erl 2005, Abbildung 5.14 . . . . . . . . 11 6 A common WS-BPEL process definition structure, aus Erl 2005, Abbildung 16.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7 Produktstruktur eines Workflow-Management-Systems, nach WfMC 1995, Abbildung 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8 Schnittstellen eines Workflow-Management-Systems, nach WfMC 1995, Abbildung 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9 BPMN is positioned at the interface between business and IT, aus Krafzig u. a. 2004, Abbildung 7.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10 Sample Business Process Model in BPMN, nach OMG 2006, Abbildung 9.31 20 11 Architekturkonzept vor der Produktauswahl, abgeleitet vom SL&I-Modell . 21 12 Architekturkonzept nach der Produktauswahl . . . . . . . . . . . . . . . . . 31 13 Business Process Management mit Intalio|BPMS, nach Gerber 2007, S. 6 . . 32 14 Der Intalio|Designer, eine IDE f¨ ur BPMN-Prozesse . . . . . . . . . . . . . . 33 15 Der Data Mapper und der Data Editor . . . . . . . . . . . . . . . . . . . . . 34 16 Detaillierte Informationen zu einer Prozessinstanz in der BPMS Console . . 36 17 Aufruf eines Web Services in einem BPMN-Prozess . . . . . . . . . . . . . . 39 18 Erstellung eines People Tasks und einer People Notification in einem BPMN-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 19 UML-Klassendiagramm eines generischen Systems zur Ausf¨ uhrung von Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 20 Exceptions, die von Implementierungen des ToolAgent-Interfaces erzeugt werden k¨ onnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 21 UML-Komponentendiagramm einer Infrastruktur, um aus WS-BPEL-Prozessen clientseitig Altsysteme auszuf¨ uhren . . . . . . . . . . . . . . . . . . . . . . . 47 22 BPMN-Modell des Leihwagenr¨ uckgabeprozesses . . . . . . . . . . . . . . . . 54 23 Verwendetes Konzept zur Einf¨ uhrung von Unterprozessen im Intalio|Designer 60 24 Datenschema des Leihwagenr¨ uckgabeprozesses . . . . . . . . . . . . . . . . 62 25 Konkretes Rollenmodell als Organigramm . . . . . . . . . . . . . . . . . . . 63 26 Formulardesign am Beispiel der Fahrzeuginspektion . . . . . . . . . . . . . . 64 27 Interaktion wichtiger Elemente in JBilling, nach Sapienter 2006 . . . . . . . 65 28 Herkunft der Datenelemente eines ausgeliehenen Leihwagens . . . . . . . . . 67 29 Bearbeitung eines People Tasks in der Workflow UI mit anschließender Ausf¨ uhrung des Altsystems Mozilla Thunderbird . . . . . . . . . . . . . . . . . 71

vii

Tabellenverzeichnis

2 Unterschiede zwischen traditionellen verteilten Systemen und einer SOA, nach Ramanathan 2004, Tabelle 1 . . . . . . . . . . . . . . . . . . . . . . . 7 3 Markt¨ ubersicht und Vorauswahl von frei verf¨ ugbaren Workflow-Engines . . 24 5 Entscheidungstabelle f¨ ur die Workflow-Engine . . . . . . . . . . . . . . . . . 28 7 Entwicklungsziel: Klassische BPM-Produkte und Intalio|BPMS (bereit f¨ ur BPM 2.0), nach Ghalimi 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8 Relevante Operationen, die durch den Web Service AppExecServer zur Verf¨ ugung gestellt werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11 ¨ Ubersicht, wie die Tasks im Szenario umgesetzt werden . . . . . . . . . . . 56 12 Softwaresysteme, die im Szenario verwendet werden . . . . . . . . . . . . . 56 13 Identifizierte Services und ihre Aufgaben . . . . . . . . . . . . . . . . . . . . 61 14 Schnittstellendefinition des CarBilling Web Services . . . . . . . . . . . . . 65 15 Schnittstellendefinition des CarData Web Services . . . . . . . . . . . . . . 66 16 Schnittstellendefinition des CarDocument Web Services . . . . . . . . . . . 68

viii

Abk¨ urzungsverzeichnis

Abk¨ urzung Bezeichnung

AJAX Asynchronous Javascript XML

API Application Programming Interface

ASF Apache Software Foundation

BPD Business Process Diagram

BPM Business Process Management

BPMI Business Process Management Initiative

BPMN Business Process Modeling Notation

BPMS Business Process Management System

CORBA Common Object Request Broker Architecture

DCOM Distributed Component Object Model

DOM Document Object Model

EAI Enterprise Application Integration

EJB Enterprise Java Beans

FTP File Transfer Protocol

HTML Hyper Text Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IDE Integrated Development Environment

JDBC Java Database Connectivity

jPDL jBPM Process Definition Language

LGPL Lesser General Public License

MPL Mozilla Public License

NOA Nice Office Access

OASIS Organization for Advancement of Structured Information Standards

ODE Orchestration Director Engine

OMG Object Management Group

PIPA People Initiating Process Activity

RPC Remote Procedure Call

SGML Standard Generalized Markup Language

SL&I Service-Layers and -Interactions

ix

SMTP Simple Mail Transfer Protocol

SOA Serviceorientierte Architektur

SQL Structured Query Language

UDDI Universal Description, Discovery and Integration

UNO Universal Network Objects

URL Uniform Resource Location

W3C World Wide Web Consortium

WfM Workflow Management

WfMC Workflow Management Coalition

WfMS Workflow Management System

WS-BPEL Web Services Business Process Execution Language

WSDL Web Service Description Language

WSFL Web Services Flow Language

XML Extensible Markup Language

XPath XML Path Language

x

1 Einleitung

Die Einleitung dient dazu, ausgehend von aktuellen Entwicklungen die Zielsetzung und die Struktur der Arbeit zu erl¨ autern.

1.1 Aktuelle Entwicklungen

Wir leben heute in einer immer st¨ arker vernetzten Welt aus Information und Technik. Outsourcing von Gesch¨ aftsfeldern, die Kooperation mit Kunden und Lieferanten und der stetige Konkurrenzdruck treiben Unternehmen dazu, immer gr¨ oßere Mengen an Daten schnell und effizient auszutauschen, um so effektiver und produktiver zu sein.

Den genannten Herausforderungen stehen meist heterogene IT-Landschaften gegen¨ uber, die aus einer Vielzahl von Softwareapplikationen, basierend auf unterschiedlichen Programmiersprachen und Plattformen, bestehen. Ein effizienter Informationsaustausch wird behindert, weil ein hoher Kosten- und Zeitaufwand n¨ otig ist, Spezialschnittstellen zu erstellen und zu warten. Außerdem k¨ onnen Gesch¨ aftsprozesse nur sehr langsam ge¨ andert werden, da die IT umst¨ andlich angepasst werden muss ¹ .

Die serviceorientierte Architektur, kurz SOA, ist in diesem Zusammenhang ein oft benutztes Schlagwort der IT-Industrie. Hierbei handelt es sich um ein neues Architekturkonzept f¨ ur Softwareapplikationen. F¨ uhrende IT-Unternehmen Firmen wie IBM, Microsoft, BEA, Oracle und SAP stellen schon seit einiger Zeit ihre Produkte auf SOA um oder unterst¨ utzen die Entwicklung neuer Standards f¨ ur diese Architektur ² . Doch bisher gibt es keine einheitliche Definition dar¨ uber, was eine SOA tats¨ achlich ist und aus welchen Komponenten sie besteht ³ . Dieser Mangel behindert die Entwicklung von einheitlichen Methoden zur Einf¨ uhrung oder Verwaltung einer SOA.

Im Folgenden werden zwei Definitionen vorgestellt:

An SOA is a business concept, an idea or approach, of how IT functionality

”

can be planned, designed, and delivered as modular business services to achieve specific business benefits. The conceptual SOA vision includes clearly defined business, IT and architectural goals, and a governance model and policies to help enforce standards and technical requirements of the SOA over time.“ 4

Service Oriented Architecture (SOA) is a paradigm for organizing and utili-

”

zing distributed capabilities may be under the control of different ownership domains.“ 5

Demnach ist SOA ein neues Paradigma der Softwareentwicklung und zun¨ achst unabh¨ angig von Technologien und Standards zu betrachten, mit denen eine SOA realisiert werden kann. Die Grundlage aller Definitionen ist die Serviceorientierung, also die Verwendung von Services in Softwareapplikationen.

¹ Vgl. Krafzig u. a. 2004, S. 1 - 12

² Vgl. IBM 2007; Microsoft 2007; BEA 2007; Oracle 2007; SAP 2007

³ Vgl. Seeley 2006

⁴ Marks u. Bell 2006, S. 2

⁵ OASIS 2006, S. 8

1

Offermann u. a. haben sieben verschiedene Bereiche der IT-Industrie identifiziert, die sich mit Serviceorientierung besch¨ aftigen ⁶ :

• Internet Application Development

• Application Development

• Enterprise Application Integration

• Workflow Management

• Business Process Management

• Collaborative Business Process Integration

• Grid Computing

In jedem Bereich gibt es einen anderen Blickwinkel auf Serviceorientierung. Die Blickwinkel enthalten jeweils ¨ ahnliche oder auch verschiedene Teilansichten einer SOA. Diese Erkenntnis war Ausgangspunkt, ein einheitliches Architekturmodell f¨ ur eine SOA zu schaffen, welches die Schwerpunkte aller oben genannten Bereiche integriert. Das Ergebnis ist das Service-Layers and -Interactions (SL&I) - Modell, welches in Abbildung 1 zu sehen ist.

Abbildung 1: Model of Service-Layers and -Interactions (SL&I), aus Offermann u. a. 2007, Abbildung 1

Das SL&I-Modell erkl¨ art, wie Services Gesch¨ aftsprozesse unterst¨ utzen, wie Altsysteme wiederverwendet und Benutzerinteraktionen in eine SOA eingebunden werden k¨ onnen. Gleichzeitig hilft das Modell die unterschiedlichen Sichtweisen, die es auf Serviceorientierung gibt, besser zu verstehen. Eine Beachtung dieser Sichtweisen ist wichtig, um ein

⁶ Vgl. Offermann u. a. 2007, S. 3

2

allgemeines Verst¨ andnis ¨ uber SOA zu bekommen und um konsistente Konzepte f¨ ur diese Architektur zu entwickeln ⁷ .

1.2 Zielsetzung und Vorgehen

Das Ziel der Arbeit ist zu zeigen, dass das SL&I-Modell mit den heute existierenden Standards und Technologien implementiert werden kann. Dazu wird wie folgt vorgegangen:

Zun¨ achst findet eine Technologie- und Softwareauswahl statt. Ausgehend von einem Architekturkonzept werden die f¨ ur eine Realisierung n¨ otigen Softwarekomponenten ausgew¨ ahlt bzw. selbst entwickelt. Es werden ausschließlich freie Softwareprodukte benutzt. Im Falle einer Wiederverwendung des Szenarios durch ein Unternehmen ergibt sich so der Vorteil, dass keine Lizenzkosten entrichtet werden m¨ ussen. Der Rahmen anf¨ anglicher Investitionskosten bleibt gering. Das Ergebnis des ersten Schritts ist eine Architektur, welche den Ausgangspunkt f¨ ur die Entwicklung eines Szenarios darstellt.

F¨ ur die Entwicklung des Szenarios wird im n¨ achsten Schritt ein beispielhafter End-to-End-Gesch¨ aftsprozess modelliert. Anschließend wird eine Unterst¨ utzung des Gesch¨ aftsprozesses durch die im ersten Schritt ausgew¨ ahlte Architektur realisiert. Im Vordergrund steht dabei die Integration von Workflow-Management- und Altsystemen.

Im letzten Schritt wird das Szenario aus der Sicht eines Unternehmens bewertet, um tats¨ achliche Vorteile gegen¨ uber konventionellen Technologien zu ermitteln.

1.3 Struktur der Arbeit

Die Arbeit besteht neben der Einleitung aus sechs weiteren Kapiteln.

Das zweite Kapitel beschreibt Grundlagen zu den Themen SOA, Web Services, Workflow Management und Business Process Management. Es werden Zusammenh¨ ange zwischen den einzelnen Themen erl¨ autert und existierende Standards vorgestellt, die f¨ ur das weitere Verst¨ andnis der Arbeit wichtig sind.

Im dritten Kapitel wird zun¨ achst eine Architektur zur Realisierung des SL&I-Modells beschrieben. Anschließend werden die daf¨ ur ben¨ otigten Softwarekomponenten ausgew¨ ahlt. Im Vordergrund steht dabei die Auswahl einer Workflow-Engine. Erst findet eine Marktubersicht statt. Anschließend werden die vorausgew¨ ahlten Produkte in einer Endauswahl ¨

den Anforderungen gegen¨ ubergestellt. Das Ergebnis der Auswahl wird die Open Source Workflow-Engine Intalio Tempo als Bestandteil des Produkts Intalio|BPMS sein.

Im vierten Kapitel geht es zun¨ achst um das Konzept von Intalio|BPMS. Daraufhin wird die Community Edition von Intalio|BPMS ausgf¨ uhrlich vorgestellt. Abschließend werden konzeptionelle St¨ arken und Schw¨ achen der Software erl¨ autert.

Das f¨ unfte Kapitel beschreibt die Entwicklung einer Infrastruktur, um Altsysteme in Intalio-Prozesse zu integrieren. Die entwickelte Infrastruktur ist unabh¨ angig vom Szenario zu betrachten, welches im sechsten Kapitel erl¨ autert wird. Die Infrastruktur kann f¨ ur beliebige Intalio-Prozesse wiederverwendet werden.

Das sechste Kapitel erl¨ autert die Entwicklung eines Szenarios basierend auf der im Verlauf der Arbeit entstandenen Architektur. Zu Beginn wird f¨ ur einen ausgew¨ ahlten Diskursbereich ein Gesch¨ aftsprozess modelliert. Danach wird analysiert, wie die einzelnen

⁷ Vgl. Offermann u. a. 2007, S. 1

3

T¨ atigkeiten des Gesch¨ aftsprozesses durch Services, Workflow-Elemente und Altsysteme unterst¨ utzt werden k¨ onnen. Es werden Serviceschnittstellen definiert, Formularinhalte geplant und Altsysteme ausgew¨ ahlt. Der Planungsprozess ist sehr umfangreich, weshalb sich mehrere Abschnitte damit besch¨ aftigen. Nach der Planung werden die einzelnen Komponenten miteinander integriert. Das Resultat ist ein Szenario, in dem ein Gesch¨ aftsprozess durch eine SOA unterst¨ utzt wird, die sowohl Workflow-Management- also auch Altsysteme integriert.

Im siebten Kapitel wird schließlich die Zielsetzung erneut aufgegriffen. Anfangs wird das Ergebnis der Arbeit festgehalten. Anschließend wird eine Bewertung der entwickelten Altsysteminfrastruktur und des entwickelten Szenarios durchgef¨ uhrt. Zum Schluss werden Ankn¨ upfungspunkte f¨ ur weitere Arbeiten aufgezeigt.

4

2 Grundlagen

In diesem Kapitel werden Grundlagen zu den Themen SOA, Web Services, Workflow Management und Business Process Management beschrieben. Es werden Zusammenh¨ ange zwischen den einzelnen Themen erl¨ autert und existierende Standards vorgestellt, die f¨ ur das weitere Verst¨ andnis der Arbeit wichtig sind.

2.1 Serviceorientierte Architektur (SOA)

Nachdem in der Einleitung bereits zwei Definitionen zu dem Begriff SOA vorgestellt und sieben unterschiedliche Sichtweisen auf Serviceorientierung identifiziert wurden, wird nun auf den Service-Begriff eingegangen, es werden Unterschiede zu anderen Architekturkonzepten erl¨ autert und es wird erkl¨ art, wann sich der Einsatz einer SOA anbietet und wann nicht.

2.1.1 Grundbegriffe

Einer der wichtigsten Grundbegriffe im Zusammenhang mit Serviceorientierung ist der Service-Begriff. Er ist f¨ ur das weitere Verst¨ andnis der Arbeit besonders wichtig und wird deshalb an dieser Stelle erl¨ autert:

Ein Service besitzt zwei Elemente, ein Schnittstelle und eine Implementierung. W¨ ahrend die Schnittstelle auf einheitlichen, plattformunabh¨ angigen Standards beruht, kann die Implementierung in einer beliebigen Programmiersprache erfolgen. Zu jedem Service gibt es eine Servicebeschreibung, in der festgehalten wird, wie mit dem Service kommuniziert werden kann. Der Informationsaustausch zwischen Serviceanbieter und Servicenutzer findet nachrichtenbasiert statt. Im Gegensatz zu Objekten werden Services meist zustandslos implementiert. Aus Sicht eines Servicenutzers ist die Implementierung eines Services eine Black box“. Er braucht die Implementierung nicht zu kennen. Die Servicebeschreibung

”

enth¨ alt alle n¨ otigen Informationen, um mit dem Service kommunizieren zu k¨ onnen ⁸ .

2.1.2 Einordnung

Die steigende Komplexit¨ at von Softwaresystemen hat in der Vergangenheit immer wieder zu neuen Paradigmen der Softwareentwicklung gef¨ uhrt - von der imperativen Programmierung zur Objektorientierung, dann weiter ¨ uber die Komponentenorientierung bis hin zur

Serviceorientierung. Jedes Paradigma brachte neue Designkonzepte mit sich. Diese Designkonzepte l¨ osten sich aber nicht unbedingt gegenseitig ab. Beispielsweise ist es m¨ oglich, die einzelnen Services einer SOA objektorientiert zu implementieren, ohne damit die Service-orientierung zu verletzen. Das bedeutet, dass die Serviceorientierung weniger bekannte Paradigmen ersetzt, als vielmehr auf ihnen aufbaut. Die SOA besitzt den bisher h¨ ochsten Grad an Abstraktion und erhebt den Anspruch, besonders gut f¨ ur die Realisierung großer, verteilter Softwaresysteme geeignet zu sein - Softwaresysteme, bei denen es bisher schwierig war, die Komplexit¨ at mit den bekannten Architekturkonzepten zu bew¨ altigen. Es kann schlussgefolgert werden, dass die Serviceorientierung sich nicht direkt mit anderen Paradigmen, wie beispielsweise der Komponentenorientierung oder der Objektorientierung,

⁸ Vgl. OASIS 2006, S. 17

5

Abbildung 2: Services can encapsulate varying amounts of logic, aus Erl 2005, Abbildung 3.1

vergleichen l¨ asst, da sich diese Konzepte auf unterschiedlichen Abstraktionsniveaus befinden ⁹ .

Traditionelle verteilte Systeme wie Remote Procedure Call (RPC), Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM) und Enterprise Java Beans (EJB) haben eine festgelegte Granularit¨ atsstufe, beispielsweise Funktionen bei RPC und Objekte bei CORBA. In einer SOA ist das anders. Services k¨ onnen als Funktionen, Objekte, Teilprozesse oder andere Entit¨ aten definiert werden ¹⁰ . Dadurch bleibt eine SOA anpassbar f¨ ur beliebige Anwendungsgebiete. Dieser Sachverhalt wird durch Abbildung 2 veranschaulicht.

In einer SOA ist es durch die starke Abstraktion m¨ oglich, den Gesch¨ aftsprozess im Fokus der Entwicklung zu behalten. Bei traditionellen Systemen ging dieser Fokus durch die feine Granularit¨ at schnell verloren. Es mussten systemnahe Schnittstellen verwendet werden, um einzelne Komponenten miteinander zu integrieren. Der Integrationscode war zudem applikations- und datenspezifisch, was eine Wiederverwendung stark einschr¨ ankte ¹¹ . Es war sehr kostenintensiv Spezialschnittstellen zu erstellen und aufrechtzuerhalten.

In einer SOA beruhen Services auf wohldefinierten und plattformunabh¨ angigen Standards. Eine Wiederverwendung ist unbegrenzt m¨ oglich. Services werden zu den Integrationspunkten einzelner Applikationen ¹² . Die Implementierungen der Services k¨ onnen auf unterschiedlichen Programmiersprachen beruhen und separat gepflegt werden. Des weiteren k¨ onnen Services zu neuen, h¨ oherwertigen Services zusammengesetzt werden. Ganze Gesch¨ aftsfunktionen lassen sich so als Services abbilden. Tabelle 2 auf der n¨ achsten Seite hebt die Unterschiede zwischen traditionellen verteilten Systemen und einer SOA hervor.

⁹ Vgl. Stojanovic u. Dahanayake 2005, S. 248; Marin u. a. 2005, S. 545

¹⁰ Vgl. Ramanathan 2004

¹¹ Vgl. Ramanathan 2004

¹² Vgl. Ramanathan 2004; OASIS 2006, S. 9 - 11

6

Tabelle 2: Unterschiede zwischen traditionellen verteilten Systemen und einer SOA, nach Ramanathan 2004, Tabelle 1

2.1.3 Einsatz

Eine der Hauptmotivation eine SOA einzuf¨ uhren ist das Bestreben die Flexibilit¨ at der IT in einem Unternehmen zu erh¨ ohen ¹³ . Die Verwendung einer SOA ist aber nicht immer sinnvoll. Die gemeinsame Nutzung von Services und ihre Wiederverwendung sind zentrale Eigenschaften einer SOA. Dadurch ist die Anzahl der Servicenutzer gemeinhin sehr hoch. Eine SOA ist netzwerkzentriert und ben¨ otigt komplexe Kontroll- und ¨ Uberwachungsmechanismen, um einen reibungslosen Betrieb zu gew¨ ahrleisten. Es wird eine Management-Infrastruktur ben¨ otigt, die f¨ ur einige Projekte zu teuer sein mag. F¨ ur die folgenden Anwendungsf¨ alle ist eine SOA nicht unbedingt die richtige Wahl ¹⁴ :

• Kurzlebige Systeme, die beispielsweise Bestandteil einer ¨ Ubergangsl¨ osung sind und

deren Funktionalit¨ at nicht in geplanten Systemen wiederverwendet werden soll

• Autonome Systeme, die nicht f¨ ur die Integration mit anderen Systemen gedacht sind

• Applikationen, die w¨ ahrend des Betriebs auf große Datenmengen zugreifen - hier ist es nicht sinnvoll, etwa die Datenbankanbindung als Service zu realisieren. Dies trifft beispielsweise auf geographische Kartierungswerkzeuge zu, welche dem Benutzer eine komplexe GUI anbieten.

Die genannten Anwendungsf¨ alle sind aber in den meisten Unternehmensanwendungen nicht zu finden. Verglichen mit den Integrationsans¨ atzen der Vergangenheit bietet eine SOA zentrale Vorteile f¨ ur ein Unternehmen: wiederverwendbare, plattformunabh¨ angige Services, eine Entwicklung basierend auf Industriestandards und die M¨ oglichkeit ¨ Anderun-

gen in der IT schnell umzusetzen, um mit der Geschwindigkeit des Wettbewerbs Schritt halten zu k¨ onnen. Nach dem World Wide Web Consoritum (W3C) ¹⁵ ist eine SOA f¨ ur folgende Anwendungsf¨ alle besonders gut geeignet ¹⁶ :

• Systeme, die ¨ uber das Internet operieren und bei denen Geschwindigkeit und Verl¨ asslichkeit nicht garantiert werden k¨ onnen

• Eine heterogene IT-Landschaft mit Integrationsbedarf, in der Komponenten eines verteilten Systems auf verschiedenen Plattformen betrieben werden

¹³ Vgl. Krafzig u. a. 2004, S. 239

¹⁴ Vgl. Ramanathan 2004

¹⁵ Das W3C ist eine nicht gewinnorientierte Standardisierungsorganisation, siehe Jacobs 2007

¹⁶ Vgl. W3C 2004a, S. 62

7

• Ein verteilter Entwicklungsprozess, der nicht zentral gesteuert werden kann

• Anwendungen, die ¨ uber das Netzwerk integriert werden sollen und als Services gekapselt werden k¨ onnen

2.2 Web Services

In diesem Abschnitt wird erkl¨ art, was Web Services sind, und es werden die wichtigsten Standards in Verbindung mit Web Services erl¨ autert.

2.2.1 Definition

Die W3C definiert einen Web Service wie folgt:

A Web service is a software system designed to support interoperable machine-

”

to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“ 17

In Bezug auf den Service-Begriff ¹⁸ einer SOA sind Web Services die gebr¨ auchlichste Form der Umsetzung. Das besondere an ihnen ist, dass sie auf offenen Standards beruhen und Internettechnologien nutzen.

2.2.2 Basisstandards

Die wichtigsten Standards, aus denen sich Web Services zusammensetzen, sind WSDL, SOAP und UDDI. Diese Standards werden im Folgenden vorgestellt.

2.2.2.1 Web Services Description Language (WSDL)

Die Web Services Description Language, kurz WSDL, ist eine auf XML basierte Sprache, um Web Services zu beschreiben ¹⁹ . Eine in WSDL verfasste Beschreibung eines Services liegt in einer Form vor, die sowohl von Menschen gelesen als auch von Maschinen verarbeitet werden kann.

Damit ein Servicenutzer mit einem Web Service kommunizieren kann, braucht er eine Vielzahl von Informationen ¨ uber den Web Service. Zu diesen Informationen geh¨ ort, wel-

che Operationen der Service anbietet, welche Nachrichten- und Netzwerkprotokolle f¨ ur die Kommunikation zu verwenden sind und die Netzwerkadresse des Web Services. Dieses Wissen wird dem Servicenutzer in Form einer WSDL-Beschreibung zur Verf¨ ugung gestellt. Der Inhalt einer WSDL-Beschreibung l¨ asst sich in zwei Kategorien aufteilen: in die abstrakte und konkrete Beschreibung. Abbildung 3 auf der n¨ achsten Seite veranschaulicht diesen Sachverhalt.

Die Definition der Operationen, die ein Service anbietet, und der Datentypen, die von den Operationen verwendet werden, bildet die abstrakte Beschreibung. In ihr wird die Funktionalit¨ at der Serviceschnittstelle beschrieben, ohne auf konkrete Details einzugehen,

¹⁷ W3C 2004a, S. 7

¹⁸ Siehe Abschnitt 2.1.1 auf Seite 5

¹⁹ Siehe Spezifikation W3C 2007b

8

Abbildung 3: WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint, aus Erl 2005, Abbildung 5.16

beispielsweise ” wie“ und ” wo“ im Netzwerk die Funktionalit¨ at bereitgestellt wird. Technologieangaben wie zu verwendende Netzwerkprotokolle und Nachrichtenformate geh¨ oren der abstrakten Beschreibung nicht an. Sie sind Bestandteil der konkreten Beschreibung. Die konkrete Beschreibung enth¨ alt außerdem den Service Endpoint. Dies ist ein oft in diesem Zusammenhang verwendeter Fachbegriff, der die physikalische Adresse bezeichnet, mit der ein Web Service im Netzwerk angesprochen werden kann. Der Service Endpoint wird in der WSDL-Beschreibung als URL ²⁰ angegeben. Eine URL ist wiederum eine eindeutige Bezeichnung f¨ ur den Ort einer Ressource im Netzwerk.

Die Trennung der Informationen in einer WSDL-Beschreibung gew¨ ahrleistet, dass bei ¨ Anderungen an der zugrunde liegenden Technologieplattform die Integrit¨ at der Servicebeschreibung gewahrt bleibt ²¹ . WSDL benutzt XML Schema ²² , um die Datentypen zu beschreiben, die f¨ ur die Kommunikation zwischen Serviceanbieter und Servicenutzer verwendet werden. In einer WSDL-Beschreibung wird mit Hilfe von XML Schema die Struktur, der Inhalt und die Semantik der Datentypen definiert, bevor sie den Operationen als Ein-oder Ausgabe zugeordnet werden. Sowohl WSDL als auch XML Schema sind Standards, die von dem World Wide Web Consortium (W3C) gepflegt und weiterentwickelt werden. Bei WSDL wird momentan an der Version 2.0 gearbeitet, welche die Vorg¨ angerversion 1.1 abl¨ osen soll.

2.2.2.2 SOAP

SOAP ²³ ist ein Kommunikationsprotokoll zum Austausch von XML-basierten Nachrichten. Die Spezifikation regelt, wie Daten in den Nachrichten abzubilden und zu interpretieren sind, definiert aber keine Vorschriften zur Semantik. Es wird ein Rahmenwerk zur Verf¨ u-

²⁰ Abk¨urzung f¨ ur Uniform Resource Location

²¹ Vgl. Erl 2005, S. 134

²² Siehe Spezifikation W3C 2004b

²³ Siehe Spezifikation W3C 2007a

9