Integration von Workflow-Management- und Altsystemen in einer serviceorientierten Architektur

Inhaltsverzeichnis

1 Einleitung
1.1 Aktuelle Entwicklungen
1.2 Zielsetzung und Vorgehen
1.3 Struktur der Arbeit

2 Grundlagen
2.1 Serviceorientierte Architektur (SOA)
2.1.1 Grundbegriffe
2.1.2 Einordnung
2.1.3 Einsatz
2.2 Web Services
2.2.1 Definition
2.2.2 Basisstandards
2.2.2.1 Web Services Description Language (WSDL)
2.2.2.2 SOAP
2.2.2.3 Universal Description Descovery and Integration (UDDI)
2.2.3 Kommunikation
2.2.4 Orchestrierung mit der Web Services Business Process Execution Language (WS-BPEL)
2.3 Workflow Management (WfM)
2.3.1 Geschäftsprozess
2.3.2 Workflow
2.3.3 Workflow-Management-System (WfMS)
2.3.4 Workflow Management Coalition (WfMC)
2.3.5 Workflow Reference Model
2.3.5.1 Organisations- bzw. Rollenmodell
2.3.5.2 Work List und Work Item
2.3.5.3 Workflow-Enigne
2.3.6 Bedeutung
2.4 Business Process Management (BPM)
2.4.1 Definition
2.4.2 Einordnung
2.4.3 Modellierung mit der Business Process Modeling Notation (BPMN)

3 Auswahl von Softwarekomponenten
3.1 Konkrete Architektur - Teil 1
3.2 Auswahl einer Workflow-Engine
3.2.1 Kriterien der Vorauswahl
3.2.2 Marktübersicht und Vorauswahl
3.2.3 Übersichtdervorausgewählten Produkte
3.2.3.1 Enhydra Shark
3.2.3.2 Imixs
3.2.3.3 Intalio|BPMS
3.2.3.4 JBoss jBPM
3.2.3.5 ObjectWeb Bonita
3.2.4 Kriterien der Endauswahl
3.2.5 Endauswahl
3.2.6 Entscheidung
3.3 Auswahl weiterer Produkte
3.3.1 Java
3.3.2 Eclipse Framework
3.3.3 Tomcat und Axis2
3.3.4 soapUI
3.4 Konkrete Architektur - Teil 2

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

5 Integration von Altsystemen
5.1 Motivation
5.2 Anforderungen
5.3 Vorgehensweise
5.4 Generisches System zur Ausführung von Applikationen .
5.4.1 Konzept
5.4.2 Modellierung
5.5 Einbettung in eine Infrastruktur zur Integration in WS-BPEL-Prozesse
5.5.1 Konzept
5.5.2 Funktionsweise
5.5.3 Getroffene Designentscheidungen
5.5.3.1 Verwendung von zwei Web Services
5.5.3.2 Direkte Kommunikation zwischen Formular und Web Ser- vice AppExecServer
5.5.3.3 Speicherung von Altsystemkonfigurationen im Web Service AppExecClient
5.5.3.4 Explizite Korrelation über die Variable Task-Id
5.5.4 Schnittstellenbeschreibung
5.6 Implementierung

6 Entwicklung eines Szenarios
6.1 Eingrenzung des Diskursbereichs
6.2 Modellierung des Prozesses
6.3 Verwendete Softwaresysteme
6.3.1 Sapienter JBilling
6.3.2 Mozilla Thunderbird
6.3.3 OpenOffice.org Writer
6.4 Design des Prozesses
6.4.1 Verfeinerung der Prozessschritte .
6.4.2 Einführung von Unterprozessen . .
6.4.3 Identifikation von Services
6.4.4 Datenschema
6.5 Entwicklung der Workflow-Elemente
6.5.1 Konkretes Rollenmodell
6.5.2 Formulare
6.6 Entwicklung der Services
6.6.1 Web Service CarBilling
6.6.2 Web Service CarData
6.6.3 Web Service CarDocument
6.7 Integration der entwickelten Komponenten .
6.7.1 Einrichtung der Client-PCs
6.7.2 Einrichtung des Server-PCs
6.7.3 Veröffentlichung des Prozesses

7 Ergebnis, Bewertung und Ausblick
7.1 Ergebnis
7.2 Bewertung
7.2.1 Bewertung der Altsystemintegration
7.2.1.1 Umsetzung
7.2.1.2 Wartungsfreundlichkeit . .
7.2.1.3 Wiederverwendbarkeit
7.2.1.4 Robustheit
7.2.2 Bewertung des Szenarios
7.2.2.1 Effektivität
7.2.2.2 Effizienz
7.2.2.3 Flexibilität
7.3 Ausblick
7.3.1 Einsatz in der Praxis
7.3.2 Datensicherheit
7.3.3 Dynamische Bindung der Web Services
7.3.4 Transaktionen

8 Rekapitulation

Literatur

Abbildungsverzeichnis

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

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

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

4 The basic structure of a SOAP message, aus Erl 2005, Abbildung 5.21

5 Web-Service-Kommunikation, nach Erl 2005, Abbildung 5.14

6 A common WS-BPEL process definition structure, aus Erl 2005, Abbildung 16.1

7 Produktstruktur eines Workflow-Management-Systems, nach WfMC 1995, Abbildung 3

8 Schnittstellen eines Workflow-Management-Systems, nach WfMC 1995, Ab- bildung 6

9 BPMN is positioned at the interface between business and IT, aus Krafzig u. a. 2004, Abbildung 7.3

10 Sample Business Process Model in BPMN, nach OMG 2006, Abbildung 9.31

11 Architekturkonzept vor der Produktauswahl, abgeleitet vom SL&I-Modell

12 Architekturkonzept nach der Produktauswahl

13 Business Process Management mit Intalio|BPMS, nach Gerber 2007, S. 6

14 Der Intalio|Designer, eine IDE für BPMN-Prozesse

15 Der Data Mapper und der Data Editor

16 Detaillierte Informationen zu einer Prozessinstanz in der BPMS Console

17 Aufruf eines Web Services in einem BPMN-Prozess

18 Erstellung eines People Tasks und einer People Notification in einem BPMN- Prozess

19 UML-Klassendiagramm eines generischen Systems zur Ausführung von Ap- plikationen

20 Exceptions, die von Implementierungen des ToolAgent-Interfaces erzeugt werden können

21 UML-Komponentendiagramm einer Infrastruktur, um aus WS-BPEL-Prozessen clientseitig Altsysteme auszuführen

22 BPMN-Modell des Leihwagenrückgabeprozesses

23 Verwendetes Konzept zur Einführung von Unterprozessen im Intalio|Designer

24 Datenschema des Leihwagenrückgabeprozesses

25 Konkretes Rollenmodell als Organigramm

26 Formulardesign am Beispiel der Fahrzeuginspektion

27 Interaktion wichtiger Elemente in JBilling, nach Sapienter 2006

28 Herkunft der Datenelemente eines ausgeliehenen Leihwagens

29 Bearbeitung eines People Tasks in der Workflow UI mit anschließender Aus- führung des Altsystems Mozilla Thunderbird

Tabellenverzeichnis

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

3 Marktübersicht und Vorauswahl von frei verfügbaren Workflow-Engines

5 Entscheidungstabelle für die Workflow-Engine

7 Entwicklungsziel: Klassische BPM-Produkte und Intalio|BPMS (bereit für BPM 2.0), nach Ghalimi 2005

8 Relevante Operationen, die durch den Web Service AppExecServer zur Ver- fügung gestellt werden

11 Übersicht,wiedieTasksimSzenarioumgesetztwerden

12 Softwaresysteme, die im Szenario verwendet werden

13 Identifizierte Services und ihre Aufgaben

14 Schnittstellendefinition des CarBilling Web Services

15 Schnittstellendefinition des CarData Web Services

16 Schnittstellendefinition des CarDocument Web Services

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

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

1.1 Aktuelle Entwicklungen

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

Den genannten Herausforderungen stehen meist heterogene IT-Landschaften gegenüber, 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ötig ist, Spezialschnittstellen zu erstellen und zu warten. Außerdem können Geschäftsprozesse nur sehr langsam geändert werden, da die IT umständlich angepasst werden muss¹.

Die serviceorientierte Architektur, kurz SOA, ist in diesem Zusammenhang ein oft benutz- tes Schlagwort der IT-Industrie. Hierbei handelt es sich um ein neues Architekturkonzept für Softwareapplikationen. Führende IT-Unternehmen Firmen wie IBM, Microsoft, BEA, Oracle und SAP stellen schon seit einiger Zeit ihre Produkte auf SOA um oder unter- stützen die Entwicklung neuer Standards für diese Architektur². Doch bisher gibt es keine einheitliche Definition darüber, was eine SOA tatsächlich ist und aus welchen Komponen- ten sie besteht³. Dieser Mangel behindert die Entwicklung von einheitlichen Methoden zur Einführung 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.“⁴

”Service Oriented Architecture(SOA)is a paradigm for organizing and utili- zing distributed capabilities may be under the control of different ownership domains.“⁵

Demnach ist SOA ein neues Paradigma der Softwareentwicklung und zunächst unabhängig 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.

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

- 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 Blick- winkel enthalten jeweils ähnliche oder auch verschiedene Teilansichten einer SOA. Diese Erkenntnis war Ausgangspunkt, ein einheitliches Architekturmodell für eine SOA zu schaf- fen, 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 in dieser Leseprobe nicht enthalten

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

Das SL&I-Modell erklärt, wie Services Geschäftsprozesse unterstützen, wie Altsysteme wiederverwendet und Benutzerinteraktionen in eine SOA eingebunden werden können. Gleichzeitig hilft das Modell die unterschiedlichen Sichtweisen, die es auf Serviceorien- tierung gibt, besser zu verstehen. Eine Beachtung dieser Sichtweisen ist wichtig, um ein allgemeines Verständnis über SOA zu bekommen und um konsistente Konzepte für 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ächst findet eine Technologie- und Softwareauswahl statt. Ausgehend von einem Architekturkonzept werden die für eine Realisierung nötigen Softwarekomponenten ausgewählt 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üssen. Der Rahmen anfänglicher Investitionskosten bleibt gering. Das Ergebnis des ersten Schritts ist eine Architektur, welche den Ausgangspunkt für die Entwicklung eines Szenarios darstellt.

Für die Entwicklung des Szenarios wird im nächsten Schritt ein beispielhafter End-to-End- Geschäftsprozess modelliert. Anschließend wird eine Unterstützung des Geschäftsprozesses durch die im ersten Schritt ausgewählte 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ächliche Vorteile gegenüber 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änge zwischen den einzelnen Themen erläutert und existierende Standards vorgestellt, die für das weitere Verständnis der Arbeit wichtig sind.

Im dritten Kapitel wird zunächst eine Architektur zur Realisierung des SL&I-Modells be- schrieben. Anschließend werden die dafür benötigten Softwarekomponenten ausgewählt. Im Vordergrund steht dabei die Auswahl einer Workflow-Engine. Erst findet eine Markt- übersicht statt. Anschließend werden die vorausgewählten Produkte in einer Endauswahl den Anforderungen gegenübergestellt. 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ächst um das Konzept von Intalio|BPMS. Daraufhin wird die Community Edition von Intalio|BPMS ausgführlich vorgestellt. Abschließend werden konzeptionelle Stärken und Schwächen der Software erläutert.

Das fünfte Kapitel beschreibt die Entwicklung einer Infrastruktur, um Altsysteme in Intalio-Prozesse zu integrieren. Die entwickelte Infrastruktur ist unabhängig vom Szenario zu betrachten, welches im sechsten Kapitel erläutert wird. Die Infrastruktur kann für beliebige Intalio-Prozesse wiederverwendet werden.

Das sechste Kapitel erläutert die Entwicklung eines Szenarios basierend auf der im Ver- lauf der Arbeit entstandenen Architektur. Zu Beginn wird für einen ausgewählten Dis- kursbereich ein Geschäftsprozess modelliert. Danach wird analysiert, wie die einzelnen Tätigkeiten des Geschäftsprozesses durch Services, Workflow-Elemente und Altsysteme unterstützt werden können. Es werden Serviceschnittstellen definiert, Formularinhalte ge- plant und Altsysteme ausgewählt. Der Planungsprozess ist sehr umfangreich, weshalb sich mehrere Abschnitte damit beschäftigen. Nach der Planung werden die einzelnen Kompo- nenten miteinander integriert. Das Resultat ist ein Szenario, in dem ein Geschäftsprozess durch eine SOA unterstützt 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ührt. Zum Schluss werden Anknüpfungspunkte für weitere Arbeiten aufgezeigt.

2 Grundlagen

In diesem Kapitel werden Grundlagen zu den Themen SOA, Web Services, Workflow Management und Business Process Management beschrieben. Es werden Zusammenhänge zwischen den einzelnen Themen erläutert und existierende Standards vorgestellt, die für das weitere Verständnis 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 Architekturkon- zepten erläutert und es wird erklärt, 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ür das weitere Verständnis der Arbeit besonders wichtig und wird deshalb an dieser Stelle erläutert:

Ein Service besitzt zwei Elemente, ein Schnittstelle und eine Implementierung. Während die Schnittstelle auf einheitlichen, plattformunabhängigen Standards beruht, kann die Im- plementierung in einer beliebigen Programmiersprache erfolgen. Zu jedem Service gibt es eine Servicebeschreibung, in der festgehalten wird, wie mit dem Service kommuniziert wer- den 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 ”Blackbox“.ErbrauchtdieImplementierungnichtzukennen.DieServicebeschreibung enthält alle nötigen Informationen, um mit dem Service kommunizieren zu können⁸.

2.1.2 Einordnung

Die steigende Komplexität von Softwaresystemen hat in der Vergangenheit immer wieder zu neuen Paradigmen der Softwareentwicklung geführt - von der imperativen Programmie- rung zur Objektorientierung, dann weiter über die Komponentenorientierung bis hin zur Serviceorientierung. Jedes Paradigma brachte neue Designkonzepte mit sich. Diese Design- konzepte lösten sich aber nicht unbedingt gegenseitig ab. Beispielsweise ist es möglich, 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öchsten Grad an Abstraktion und erhebt den Anspruch, besonders gut für die Realisierung großer, verteilter Softwaresysteme geeignet zu sein - Softwaresysteme, bei denen es bisher schwie- rig war, die Komplexität mit den bekannten Architekturkonzepten zu bewältigen. Es kann schlussgefolgert werden, dass die Serviceorientierung sich nicht direkt mit anderen Pa- radigmen, wie beispielsweise der Komponentenorientierung oder der Objektorientierung,

Abbildung in dieser Leseprobe nicht enthalten

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

vergleichen lässt, da sich diese Konzepte auf unterschiedlichen Abstraktionsniveaus befin- den⁹.

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ätsstufe, beispielsweise Funktionen bei RPC und Objekte bei CORBA. In einer SOA ist das anders. Services können als Funktionen, Objekte, Teilprozesse oder andere Entitäten definiert werden¹⁰. Dadurch bleibt eine SOA anpassbar für beliebige Anwendungsgebiete. Dieser Sachverhalt wird durch Abbildung 2 veranschaulicht.

In einer SOA ist es durch die starke Abstraktion möglich, den Geschäftsprozess im Fokus der Entwicklung zu behalten. Bei traditionellen Systemen ging dieser Fokus durch die feine Granularität 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änkte¹¹. Es war sehr kostenintensiv Spezialschnittstellen zu erstellen und aufrechtzuerhalten.

In einer SOA beruhen Services auf wohldefinierten und plattformunabhängigen Standards. Eine Wiederverwendung ist unbegrenzt möglich. Services werden zu den Integrationspunk- ten einzelner Applikationen¹². Die Implementierungen der Services können auf unterschied- lichen Programmiersprachen beruhen und separat gepflegt werden. Des weiteren können Services zu neuen, höherwertigen Services zusammengesetzt werden. Ganze Geschäfts- funktionen lassen sich so als Services abbilden. Tabelle 2 auf der nächsten Seite hebt die Unterschiede zwischen traditionellen verteilten Systemen und einer SOA hervor.

Abbildung in dieser Leseprobe nicht enthalten

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ühren ist das Bestreben die Flexibilität der IT in einem Unternehmen zu erhöhen¹³. Die Verwendung einer SOA ist aber nicht im- mer 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ötigt komplexe Kontroll- undÜber- wachungsmechanismen, um einen reibungslosen Betrieb zu gewährleisten. Es wird eine Management-Infrastruktur benötigt, die für einige Projekte zu teuer sein mag. Für die folgenden Anwendungsfälle ist eine SOA nicht unbedingt die richtige Wahl¹⁴:

- Kurzlebige Systeme, die beispielsweise Bestandteil einer Übergangslösung sind und deren Funktionalität nicht in geplanten Systemen wiederverwendet werden soll
- Autonome Systeme, die nicht für die Integration mit anderen Systemen gedacht sind
- Applikationen, die während 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älle sind aber in den meisten Unternehmensanwendungen nicht zu finden. Verglichen mit den Integrationsansätzen der Vergangenheit bietet eine SOA zentrale Vorteile für ein Unternehmen: wiederverwendbare, plattformunabhängige Services, eine Entwicklung basierend auf Industriestandards und die MöglichkeitÄnderungen in der IT schnell umzusetzen, um mit der Geschwindigkeit des Wettbewerbs Schritt halten zu können. Nach dem World Wide Web Consoritum (W3C)¹⁵ ist eine SOA für folgende Anwendungsfälle besonders gut geeignet¹⁶:

- Systeme, die über das Internet operieren und bei denen Geschwindigkeit und Verlässlichkeit nicht garantiert werden können
- Eine heterogene IT-Landschaft mit Integrationsbedarf, in der Komponenten eines verteilten Systems auf verschiedenen Plattformen betrieben werden
- Ein verteilter Entwicklungsprozess, der nicht zentral gesteuert werden kann
- Anwendungen, die über das Netzwerk integriert werden sollen und als Services gekapselt werden können

2.2 Web Services

In diesem Abschnitt wird erklärt, was Web Services sind, und es werden die wichtigsten Standards in Verbindung mit Web Services erläutert.

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 machine- processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, ty- pically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“¹⁷

In Bezug auf den Service-Begriff¹⁸ einer SOA sind Web Services die gebräuchlichste 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 verar- beitet werden kann.

Damit ein Servicenutzer mit einem Web Service kommunizieren kann, braucht er eine Vielzahl von Informationen über den Web Service. Zu diesen Informationen gehört, wel- che Operationen der Service anbietet, welche Nachrichten- und Netzwerkprotokolle für die Kommunikation zu verwenden sind und die Netzwerkadresse des Web Services. Dieses Wissen wird dem Servicenutzer in Form einer WSDL-Beschreibung zur Verfügung gestellt. Der Inhalt einer WSDL-Beschreibung lässt sich in zwei Kategorien aufteilen: in die ab- strakte und konkrete Beschreibung. Abbildung 3 auf der nächsten 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ät der Serviceschnittstelle beschrieben, ohne auf konkrete Details einzugehen,

Abbildung in dieser Leseprobe nicht enthalten

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“imNetzwerkdieFunktionalitätbereitgestelltwird.Technolo- gieangaben wie zu verwendende Netzwerkprotokolle und Nachrichtenformate gehören der abstrakten Beschreibung nicht an. Sie sind Bestandteil der konkreten Beschreibung. Die konkrete Beschreibung enthält 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ür den Ort einer Ressource im Netzwerk.

Die Trennung der Informationen in einer WSDL-Beschreibung gewährleistet, dass beiÄn- derungen an der zugrunde liegenden Technologieplattform die Integrität der Servicebe- schreibung gewahrt bleibt²¹. WSDL benutzt XML Schema²², um die Datentypen zu be- schreiben, die für die Kommunikation zwischen Serviceanbieter und Servicenutzer verwen- det 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ängerversion 1.1 ablösen 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ü-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: The basic structure of a SOAP message, aus Erl 2005, Abbildung 5.21

gung gestellt, so dass beliebige applikationsspezifische Informationen über das Netzwerk übertragen werden können.

Eine SOAP-Nachricht ist nach dem Head-Body-Pattern modelliert, ähnlich wie eine HTML- Seite. Hiernach werden die Kontextinformationen von dem eigentlichen Inhalt getrennt. Bei einer SOAP-Nachricht können Kontextinformationen beispielsweise Daten über die Authentifizierung und das Routing sein. Diese Kontextinformationen werden im Head- Bereich gespeichert. Der eigentliche Inhalt einer Nachricht befindet sich im Body-Bereich. SOAP selbst wirkt wie ein ”Briefumschlag“,derdieXML-Nachrichteinschließt.WebSer- vices verwenden SOAP, um untereinander zu kommunizieren. Mittels SOAP können Ope- rationen aufgerufen und im Gegenzug die Ergebnisse oder Fehlermeldungen übertragen werden. Es wird auch, ähnlich wie bei einer E-Mail, das Anhängen von Dateien unter- stützt. Abbildung 4 veranschaulicht generisch den Inhalt einer SOAP-Nachricht.

XML als Nachrichtenformat zu verwenden ist neu. Konventionelle Protokolle übertragen die Daten binär. Die binären Formate sind aber meist nur für eine Programmiersprache oder zumindest eine Plattform konzipiert. Dadurch bleiben solche Protokolle in ihren Anwendungsbereichen beschränkt. Bei SOAP ist das nicht so, weil es auf etablierten Internetstandards basiert. Es gewährleistet ein Höchstmaß an Flexibilität und ist deshalb besonders für lose gekoppelte Systeme, wie Web Services, geeignet.

SOAP-Nachrichten sind eigenständige Kommunikationseinheiten, die mit einer Fülle zu- sätzlicher Informationen ausgestattet werden können, welche die Zustellung und Verar- beitung von Nachrichteninhalten betreffen. Die Flexibilität wird allerdings auch durch Nachteile in der Verarbeitungsgeschwindigkeit erkauft. So führen SOAP-Nachrichten ne- ben den eigentlichen Daten eine Reihe von Meta-Informationen mit, die auf beiden Seiten verarbeitet werden müssen. Besonders das Netzwerk muss dieser zusätzlichen Belastung Stand halten.

Damit SOAP-Nachrichten im Netzwerk verschickt werden können, wird ein Transportpro- tokoll benötigt. Die SOAP-Spezifikation macht dazu keine Angaben. Grundsätzlich können unterschiedliche Transportprotokolle wie HTTP²⁴, FTP²⁵ oder SMTP²⁶ verwendet wer- den. Auch HTTPS²⁷, die verschlüsselte Version des HTTP-Protokolls, ist möglich. So ist SOAP für die verschiedensten Netzwerkarchitekturen geeignet. SOAP wird vom World Wide Web Consortium (W3C) entwickelt und hat mittlerweile den Status einer W3C- Empfehlung erreicht. Aktuell befindet sich SOAP in der Version 1.2. Seither ist SOAP keine Abkürzung mehr für Simple Object Access Protocol, sondern ein eigener Begriff. Diese Veränderung wurde vorgenommen, weil das Anwendungsgebiet des Protokolls ur- sprünglich ein anderes war und die Deutung nicht mehr als passend erschien.

2.2.2.3 Universal Description Descovery and Integration (UDDI)

Um die Auffindbarkeit von Web Services im Netzwerk zu erleichtern, können zentrale Verzeichnisse eingerichtet werden, die auf der Technologie Universal Description Discovery and Integration, kurz UDDI²⁸, beruhen. UDDI ist zwar auch ein wichtiger Basisstandard, soll aber in dieser Arbeit nicht näher erläutert werden, da er für die Entwicklung des Szenarios nicht relevant ist.

2.2.3 Kommunikation

Das Zusammenwirken von WSDL und SOAP wird anhand von Abbildung 5 veranschaulicht. Wie zu sehen ist, kommunizieren zwei Web Services miteinander. Ein Web Service fungiert dabei als Serviceanbieter, der andere als Servicenutzer. Es wird deutlich, dass die ausgetauschten SOAP-Nachrichten immer dem Nachrichtenformat des jeweils anderen Web Services entsprechen müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Web-Service-Kommunikation, nach Erl 2005, Abbildung 5.14

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: A common WS-BPEL process definition structure, aus Erl 2005, Abbildung 16.1

2.2.4 Orchestrierung mit der Web Services Business Process Execution Language (WS-BPEL)

Die Web Services Business Process Execution Language, kurz WS-BPEL²⁹, ist eine XML- basierte Sprache, um Geschäftsprozesse zu beschreiben, die sich durch die Ausführung von Web Services unterstützen lassen. Einzelne Aktivitäten eines Geschäftsprozesses werden in einem WS-BPEL-Prozess durch Web Services repräsentiert und in einer vorgegebenen Reihenfolge aufgerufen. Es entsteht eine logische Verknüpfung mehrerer Web Services, die auch als Komposition oder Orchestrierung bezeichnet wird. Die Ablauflogik gleicht dabei der des Geschäftsprozesses. In Abbildung 6 ist die Struktur eines WS-BPEL-Prozesses dargestellt.

Eine graphische Repräsentation der modellierten Prozesse ist nicht Bestandteil der Spezi- fikation. Mittlerweile gibt es unterschiedliche Formen der Darstellung, die von Hersteller zu Hersteller variieren. Um den Ablauf eines Geschäftsprozesses festzuhalten, stehen in WS-BPEL zahlreiche Sprachkonstrukte zur Verfügung. Sie werden strukturierte Aktivitä- ten genannt und steuern den Kontrollfluss eines WS-BPEL-Prozesses. Im einfachsten Fall wird der Inhalt von Variablen ausgewertet, um ausgehend von dem Ergebnis alternative Pfade im WS-BPEL-Prozess zu beschreiten. Zu den strukturierten Aktivitäten gehören so genannte Scopes. Mit diesen Konstrukten ist der Entwickler in der Lage, Aktivitäten zu bündeln und zu einer transaktionalen Einheit zusammenzufassen. In einem Scope kön- nen auftretende Fehler und Ereignisse behandelt werden. Außerdem ist es möglich durch Kompensation bereits ausgeführte Aktivitäten zurückzusetzen. So eignet sich WS-BPEL auch für die Unterstützung sehr komplexer Geschäftsprozesse.

Ein Mangel von WS-BPEL ist, dass eine direkte Interaktion mit realen Personen nicht unterstützt wird. Viele Geschäftsprozesse kommen ohne die Interaktion mit realen Personen aber nicht aus. Von IBM und SAP wurde aus diesem Grund ein Whitepaper mit dem Namen BPEL4People³⁰ veröffentlicht, das Anforderungen an eine WS-BPEL-Erweiterung stellt, welche die Interaktion mit Personen ermöglicht.

Ursprünglich geht WS-BPEL auf die beiden Kompositionssprachen WSFL³¹ und XLANG zurück, die von IBM bzw. Microsoft entwickelt wurden. In der Vergangenheit haben ge- meinsame Bemühungen der beiden Unternehmen zu der Sprache WS-BPEL geführt, die nun seit 2003 von der Organization for Advancement of Structured Information Standards (OASIS)³² standardisiert und weiterentwickelt wird³³. Aktuell befindet sich die Spezifika- tion in der Version 2.0.

Die Sprache WS-BPEL basiert auf zahlreichen W3C-Standards, hauptsächlich WSDL³⁴, XML Schema³⁵ und XPath³⁶. Als öffentliche Ein- und Ausgangspunkte besitzt jeder WS- BPEL-Prozess eine WSDL-Beschreibung, wodurch er als Web Service veröffentlicht werden kann. Außerdem werden WSDL-Beschreibungen externer Web Services eingebunden, um sie aus dem Prozess heraus aufrufen zu können. Die in WSDL-Beschreibungen mittels XML Schema definierten Datentypen können für die Deklaration von Variablen in einem WS-BPEL-Prozess verwendet werden. Mittels XPath ist es möglich, einzelne Elemente komplexer Datentypen zu selektieren, um diese auswerten oder verändern zu können. Da- mit WS-BPEL-Prozesse ausgeführt werden können, ist eine WS-BPEL-Engine erforder- lich. Sie ist in der Lage Instanzen eines WS-BPEL-Prozesses zu erzeugen und parallel zu verwalten.

Bei der Benennung von Web-Service-Spezifikationen hat sich das Präfix WS-* durchge- setzt. Außer WS-BPEL gibt es noch zahlreiche andere Spezifikationen, die das Präfix WS-* besitzen, beispielsweise WS-Adressing oder WS-Security. Solche Spezifikationen ha- ben alle gemein, dass sie den Funktionsumfang von Web Services um einen jeweils anderen Aspekt erweitern, der für den Einsatz in einem Unternehmen von Interesse sein mag. Erl unterscheidet zwei Web-Service-Generationen. Die erste Generation besteht nur aus den Basisstandards WSDL, SOAP und UDDI. In der zweiten Generation kommen zahlreiche WS-* Spezifikationen hinzu³⁷. Die Erläuterung dieser Spezifikationen ist nicht Bestandteil dieser Arbeit. Für einen genauenÜberblick wird auf entsprechende Fachliteratur verwie- sen³⁸.

2.3 Workflow Management (WfM)

In diesem Abschnitt wird auf das Thema Workflow Management, kurz WfM, eingegangen. Zunächst werden die Zusammenhänge zwischen Geschäftsprozess, Workflow und Workflow- Management-System erklärt. Anschließend wird das Referenzmodell der Workflow Mana- gement Coalition vorgestellt und letztlich die Rolle von Workflow Management im Rahmen einer SOA verdeutlicht.

2.3.1 Geschäftsprozess

Ein Geschäftsprozess ist eine Tätigkeit, die ein materielles oder immaterielles Produkt er- zeugt und damit ein eindeutiges Ergebnis liefert. Geschäftsprozesse sind dadurch gekenn- zeichnet, dass sie den Wert eines Produkts erhöhen, indem sie Ressourcen verbrauchen. Sie besitzen immer einen definierten Anfang und ein definiertes Ende und gehören zu der Ablauforganisation eines Unternehmens. Am Ende bestimmter Geschäftsprozesse steht der Kunde. Daher soll bei der Gestaltung solcher Geschäftsprozesse die Kundenorientierung immer im Vordergrund stehen³⁹.

2.3.2 Workflow

Seitens der IT kann ein Geschäftsprozess durch einen Workflow unterstützt werden. Ein Workflow bildet entweder nur Teile oder auch den gesamten Geschäftsprozess ab. Work- flows setzten sich aus einzelnen Aktivitäten zusammen, die zuvor im Geschäftsprozess modelliert wurden. Die Aktivitäten eines Workflows repräsentieren einzelne Arbeitsschrit- te des Geschäftsprozesses, die von Personen bzw. Applikationen ausgeführt werden. Der Ablauf eines Workflows kann durch auftretende Ereignisse beeinflusst werden. Somit ist der Ablauf eines Workflows nicht immer gleich. Genau wie ein Geschäftsprozess besitzt ein Workflow immer einen definierten Anfang und ein definiertes Ende⁴⁰.

2.3.3 Workflow-Management-System (WfMS)

Workflow Management befasst sich mit allen Aufgaben, die im Umgang mit Workflows anfallen. Dazu gehören die Bereiche Analyse, Modellierung, Simulation, Reorganisation sowie Ausführung und Steuerung von Workflows⁴¹. Ein Workflow-Management-System, kurz WfMS, ist eine IT-Plattform zur Unterstützung des Workflow Managements. WorkflowManagement-Systeme gehören zum Spektrum der kommunikationsorientierten Werkzeuge, die arbeitsteilige Prozesse zwischen Menschen unterstützen sollen. Der Einsatz eines Workflow-Management-Systems zur rechnergestützten Steuerung betrieblicher Abläufe bringt eine Reihe von Vorteilen mit sich⁴²:

- Zeitersparnis
- Mitarbeitermotivation
- Kostenersparnis
- Managementunterstützung
- Kundenorientierung

Eine gute Dokumentation der zu unterstützenden Geschäftsprozesse ist aber Grundvorraussetzung für den Einsatz von Workflows. Zudem sind Workflows nicht für jeden Geschäftsprozess geeignet. Maurer hat folgende Prozessmerkmale aufgestellt, die den Workflow-Einsatz begünstigen sollen⁴³:

- Gut strukturierte Prozesse
- Stabile Prozessstruktur
- Hohe Frequenz der Geschäftsvorfälle
- Stark arbeitsteilige Prozessausführung
- Zahlreiche heterogene Einzelapplikationen

Diese Merkmale werden im Verlauf der Arbeit noch einmal aufgegriffen, wenn es im Zusammenhang mit der Entwicklung des Szenarios darum geht, einen beispielhaften Geschäftsprozess zu erarbeiten.

2.3.4 Workflow Management Coalition (WfMC)

Die Workflow Management Coalition, kurz WfMC, ist eine gemeinnützige Vereinigung und wurde 1993 gegründet, um einheitliche Begrifflichkeiten festzulegen und standardisierte Schnittstellen im Bereich des Workflow Managements zu schaffen. Das Hauptziel ist, ein Referenzmodell für Workflow-Management-Systeme zu etablieren, damit herstellerunabhängig Module von Workflow-Management-Systemen miteinander verknüpft und betrieben werden können. Die Faktoren Aufwand und Risiko, welche bei der Integration von Workflow-Produkten entstehen können, sollen somit minimiert werden. Die Organisation besteht heute aus über 300 Mitgliedern, die sich aus Herstellern, Beratungsunternehmen, Wissenschaftlern und Anwendern zusammensetzen⁴⁴.

2.3.5 Workflow Reference Model

In diesem Abschnitt wird auf das Referenzmodell eingegangen, welches die WfMC zur Architektur von Workflow-Management-Systemen entwickelt hat. In Abbildung 7 auf der nächsten Seite ist die generische Struktur eines Workflow-Management-Systems zu sehen. Die Abbildung enthält zahlreiche Komponenten, die noch nicht beschrieben worden sind. Im Folgenden werden die wichtigsten erläutert.

2.3.5.1 Organisations- bzw. Rollenmodell

In einem Rollenmodell wird die Aufbauorganisation eines Unternehmens abgebildet. Eine Rolle entspricht dabei einer Funktion eines Mitarbeiters in einem Unternehmen. Jeder Mitarbeiter kann beliebig viele Rollen besitzen. Die aufgenommenen Rollen werden für die Zuweisung von Aktivitäten verwendet. Dies hat den Vorteil, dass ein Workflow unabhängig von einzelnen Personen implementiert werden kann. Ein Rollenmodell fungiert als Berechtigungskonzept im Rahmen des Workflow Managements. Für ein Unternehmen muss es nur einmal angelegt werden. Ein Rollenmodell ist also unabhängig von einzelnen Workflows aber Vorraussetzung für ihre Implementierung.

2.3.5.2 Work List und Work Item

Wenn sich ein Mitarbeiter mittels eines Workflow-Clients am Workflow-Management- System anmeldet, bekommt er abhängig von den Rollen die er besitzt, die gerade anfal- lenden Aufgaben aus allen Workflow-Instanzen angezeigt. Die Liste mit den anfallenden Aufgaben wird als Work List bezeichnet. Ein einzelner Eintrag der Work List heißt Work Item. Ein Work Item repräsentiert die in einer Aktivität einer Workflow-Instanz anfallende Arbeit.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Produktstruktur eines Workflow-Management-Systems, nach WfMC 1995, Abbildung 3

2.3.5.3 Workflow-Enigne

Zentraler Bestandteil eines Workflow-Management-Systems ist die Workflow-Engine. Eine Workflow-Engine ist serverseitig für die Ausführung der Workflows verantwortlich. Die WfMC hat in ihrem Referenzmodell fünf Schnittstellen für eine Workflow-Engine defi- niert. Diese Schnittstellen regeln die Kommunikation mit den anderen Komponenten eines Workflow-Management-Systems. Abbildung 8 auf der nächsten Seite gibt einenÜberblick.

Wie zu erkennen ist, sind die einzelnen Schnittstellen durchnummeriert. Interface 1 (Pro- cess Definition Interface) dient der Anbindung eines Modellierungswerkzeugs an die Work- flow-Engine⁴⁵. Die Spezifikation dieser Schnittstelle enthält unter anderem ein Datenfor- mat zum Austausch von Prozessdefinitionen. Interface 2 (Workflow Client Applications) ist eine generische Schnittstelle zwischen der Workflow-Engine und den Workflow-Clients⁴⁶. Sie ermöglicht theoretisch die Eigenentwicklung eines Workflow-Clients, der einen an das Unternehmen angepassten Funktionsumfang besitzt. In der Spezifikation von Interface 3 (Invoked Applications) wird festgelegt, wie Softwaremodule, die lokal installiert oder über das Netzwerk erreichbar sind, in Workflows eingebunden werden können⁴⁷. Inter-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Schnittstellen eines Workflow-Management-Systems, nach WfMC 1995, Ab- bildung 6

face 4 (Other Workflow Enactment Services) gestattet die Anbindung weiterer WorkflowManagement-Systeme⁴⁸. Interface 5 (Administration and Monitoring Tools) schließlich ermöglicht, dass Administrations- undÜberwachungswerkzeuge von Drittanbietern auf die Workflow-Engine zugreifen können⁴⁹.

2.3.6 Bedeutung

Die Interaktion mit Personen spielt eine zentrale Rolle bei der Entwicklung eines Szenarios im Sinne des SL&I-Modells⁵⁰. In der zu konstruierenden SOA wird ein WS-BPEL-Prozess die oberste Ebene einnehmen. Wie in Abschnitt 2.2.4 beschrieben, sind WS-BPEL-Prozesse jedoch nicht in der Lage, direkt mit Personen zu interagieren, da sie nur mit Web Services kommunizieren können. Der Umweg muss also über einen Web Service führen, der in der Lage ist, die genannte Interaktion zu realisieren.

An dieser Stelle kommen Workflow-Engines ins Spiel. Sie bringen die gesamte Infrastruk- tur mit, die für die Interaktion mit Personen erforderlich ist. Die Idee besteht darin, eine Workflow-Engine als Web Service zu kapseln, um sie so in WS-BPEL-Prozesse einbin- den zu können. Der Web Service steuert die Workflow-Engine derart, dass Work Items aus einem WS-BPEL-Prozess heraus erstellt werden können. Ergebnisse erledigter Work Items gelangen über den Web Service zurück an den WS-BPEL-Prozess. Auf diese Art ist es möglich die Interaktion mit Personen mit verhältnismäßig geringem Aufwand zu realisieren.

2.4 Business Process Management (BPM)

In diesem Abschnitt wird auf das Thema Business Process Management eingegangen und dessen Rolle im Rahmen einer SOA verdeutlicht. Der Schwerpunkt liegt dabei auf der Modellierungssprache BPMN und ihrem Zusammenhang mit WS-BPEL.

2.4.1 Definition

Business Process Management, kurz BPM, ist ein Verfahren zur prozessorientierten Organisation eines Unternehmens. Es konzentriert sich auf strategische und operationale Aspekte der Prozessorientierung und kann als Erweiterung des klassischen Workflow Managements betrachtet werden⁵¹.

Um BPM betreiben zu können, ist eine technische Plattform erforderlich. Diese Plattform wird Business Process Management System, kurz BPMS, genannt. Sie unterstützt den gesamten Lebenszyklus eines Geschäftsprozesses bestehend aus Planung, Modellierung, Ausführung undÜberwachung⁵². Ziel einer solchen Plattform ist es, sowohl Wirtschafts- analytikern, Softwareentwicklern als auch Systemadministratoren die Entwicklung und Veröffentlichung von Geschäftsprozessen zu ermöglichen⁵³. BPM will somit eine Verbin- dung schaffen zwischen der Business- und der IT-Seite eines Unternehmens.

Im Zusammenhang mit einer SOA ist BPM interessant, da es sehr wirkungsvolle Kon- zepte anbietet, um die Services einer SOA an die Geschäftsprozesse eines Unternehmens auszurichten⁵⁴.

2.4.2 Einordnung

Der Vorgänger von BPM ist das zehn Jahre ältere Business Process Reengeneering, kurz BPR, das in den 1990ern sehr populär war. Mit BPR wurde ein radikales Redesign der Geschäftsprozesse durchgeführt, um deutliche Verbesserungen bei den Faktoren Kosten, Zeit und Qualität zu erzielen. Diese Philosophie ging aber nicht auf. Nachdem zwischen 60% und 70% aller BPR-Projekte gescheitert waren, kam die Bewegung zum Stillstand⁵⁵.

Im Unterschied zu BPR führt BPM kein radikales Redesign der Geschäftsprozesse durch. Es steht die kontinuierliche Weiterentwicklung im Vordergrund. Beide Verfahren haben gemeinsam, dass Geschäftsprozesse auf den Kunden ausgerichtet werden, um die Unternehmensziele besser erreichen zu können.

2.4.3 Modellierung mit der Business Process Modeling Notation (BPMN)

Die Business Process Modelling Notation, kurz BPMN, ist eine graphische Modellierungs- sprache für Geschäftsprozesse. Sie wird im Rahmen von BPM verwendet, um auf einheitli- che Weise Geschäftsprozesse zu modellieren. Das Anliegen der Entwickler von BPMN ist es, eine standardisierte Notation anzubieten, die für alle Geschäftsleute leicht verständlich ist:

[...]

---

¹ 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

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

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

⁸ Vgl. OASIS 2006, S. 17

⁹ 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

¹³ 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

¹⁷ W3C 2004a, S. 7

¹⁸ Siehe Abschnitt 2.1.1 auf Seite 5

¹⁹ Siehe Spezifikation W3C 2007b

²⁰ Abkürzung für Uniform Resource Location

²¹ Vgl. Erl 2005, S. 134

²² Siehe Spezifikation W3C 2004b

²³ Siehe Spezifikation W3C 2007a

²⁴ Abkürzung für Hypertext Transfer Protocol

²⁵ Abkürzung für File Transfer Protocol

²⁶ Abkürzung für Simple Mail Transfer Protocol

²⁷ Abkürzung für Hypertext Transfer Protocol Secure

²⁸ Siehe Spezifikation OASIS 2004

²⁹ Siehe Spezifikation OASIS 2007b

³⁰ Siehe IBM u. SAP 2005

³¹ Abkürzung für Web Services Flow Language

³² Die OASIS ist genau wie die W3C eine nicht gewinnorientierte Standardisierungsorganisation, siehe OASIS 2007a

³³ Vgl. Erl 2005, S.567-568

³⁴ Siehe Abschnitt 2.2.2.1 auf Seite 8

³⁵ Siehe Spezifikation W3C 2004b

³⁶ Abkürzung für XML Path Language, siehe Spezifikation W3C 1999

³⁷ Vgl. Erl 2005, S. 157

³⁸ Siehe http://www.specifications.ws, Erl 2005 o. ä.

³⁹ Vgl. Krallmann u. a. 2002, S. 247 ff.

⁴⁰ Vgl. Müller 2005, S. 8

⁴¹ Vgl. Müller 2005, S. 10

⁴² Vgl. Oberweis 2002, S. 55

⁴³ Vgl. Maurer 1996, S. 18

⁴⁴ Vgl. Müller 2005, S. 17; WfMC 2007

⁴⁵ Vgl. WfMC 1995, S. 28 ff.

⁴⁶ Vgl. WfMC 1995, S. 32 ff.

⁴⁷ Vgl. WfMC 1995, S. 36 ff.

⁴⁸ Vgl. WfMC 1995, S. 41 ff.

⁴⁹ Vgl. WfMC 1995, S. 44 ff.

⁵⁰ Siehe Abbildung 1 auf Seite 2

⁵¹ Vgl. Aalst 2004, S. 1

⁵² Vgl. Krafzig u. a. 2004, S. 105

⁵³ Vgl. Krafzig u. a. 2004, S. 107

⁵⁴ Vgl. Krafzig u. a. 2004, S.103

⁵⁵ Vgl. Krafzig u. a. 2004, S. 104