Diplomarbeit. Verwendung von BPEL zur Service-Orchestrierung innerhalb einer J2EE-Umgebung

Transkript

1 Fachhochschule Braunschweig/Wolfenbüttel Fachbereich Informatik Diplomarbeit Zur Erlangung des akademischen Grades Diplom-Informatiker (FH) Verwendung von BPEL zur Service-Orchestrierung innerhalb einer J2EE-Umgebung Eingereicht von: Sven Mehliß im April 2008 Vorgelegt bei: Herrn Prof. Dr. Bernd Müller (Erstgutachter) Herrn Dipl-Inf (FH) Roger Zacharias (Zweitgutachter)

2

3 Abstract Die Komposition von Services zu Geschäftsprozessen in einem auf einer serviceorientierten Architektur basierendem Enterprise-Informationssystem ist mit herkömmlichen Programmiersprachen unzureichend zu realisieren. Die Business Process Execution Language bietet einen geschäftsprozessorientierten Ansatz für die Komposition von Services, der eine schnelle Anpassung von Geschäftsprozessen und die Verwaltung von Geschäftsprozessinstanzen ermöglicht. Für eine Anwendung in komplexen Enterprise-Informationssystemen müssen weitere Gesichtspunkte wie Sicherheit und direkter Ressourcenaufruf in Betracht gezogen werden, deren technische Umsetzungen maßgeblich den effektiven und effizienten Einsatz bestimmen. Die vorliegende Arbeit stellt die Business Process Execution Language mit ihren wesentlichen Vorteilen dar und beschreibt die Integration in ein Enterprise-Informationssystem unter Berücksichtigung der technischen Erweiterungen und der daraus resultierenden Anpassungen für die vorhandene Anwendung. Schließlich werden in dieser Arbeit bestehende Integrationsmechanismen erläutert und Potentiale in weiteren Bereichen aufgezeigt. i

4 ii Abstract An enterprise information system based on a service oriented architecture composites single services to business processes. This service composition cannot be implemented efficiently with conventional programming languages. The Business Process Execution Language offers a business process oriented approach on service composition while allowing high adaptable business processes which can be monitored and controlled. There is a high necessity to integrate basic features like security and direct resource calls in order to realize an effective and efficient solution that is applicable in today s business environment. This thesis highlights the advantages of the Business Process Execution Language and focuses on the integration into an existing enterprise information system. Finally the integration mechanism and the basic feature potentials are shown.

5 Danksagungen An dieser Stelle möchte ich mich bei meinen Betreuern Herrn Prof. Dr. Bernd Müller, Herrn Roger Zacharias und Herrn Nico vom Hagen für die geleistete Unterstützung bedanken. Die Gespräche und Anregungen haben zum Gelingen dieser Arbeit beigetragen. Weiterhin geht mein Dank an meine Kollegen der Wincor Nixdorf International GmbH, die durch anregende Diskussionen und konstruktive Kritik einen wichtigen Teil zu dieser Arbeit beitrugen, inbesondere an Herrn Thomas Höfer, der mir bei Fragen und Problemen immer zur Seite stand. Für ihre Unterstützung möchte ich mich bei meiner Mutter, meinen Schwiegereltern, meinem Bruder und meinen Schwägerinnen bedanken. Mein besonderer Dank gilt meiner Frau Eva Maria und meiner Tochter Frederike für das Verständis und die Unterstützung während der Zeit der Erstellung der Arbeit. Darüber hinaus bedanke ich mich bei allen weiteren Personen, die auf irgendeine Art zum Gelingen dieser Arbeit beigetragen haben. April 2008 Sven Mehliß iii

6

7 Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Arbeit selbständig und unter ausschließlicher Verwendung der angegebenen Quellen und Hilfsmittel angefertigt zu haben. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Die Arbeit wurde in gleicher oder ähnlicher Form weder veröffentlicht, noch hat sie einer anderen Prüfungsbehörde vorgelegen. Goslar, den 17. April 2008 Sven Mehliß v

8

9 Inhaltsverzeichnis 1 Einführung Einleitung Zielsetzung Systemvoraussetzungen Vorgehensweise und Aufbau der Diplomarbeit Grundlagen Serviceorientierte Architektur Konzepte Komponenten Service Komposition von Services Technologieeinsatz Business Process Execution Language Einführung Kernkonzepte Struktur Kompensierung TravelBooking-Anwendung - Servicebasierte Orchestrierung Komponenten TravelBookingService CarReservationService HotelReservationService CreditCardService Komponenteninteraktion BookTravel vii

10 viii Inhaltsverzeichnis CancelTravel GetTravelReservations Deployment Webservice-Security BPEL-Umgebung BPEL-Server Oracle BPEL Process Manager ActiveBPEL Enterprise Edition Vergleich BPEL-Designer Oracle JDeveloper ActiveBPEL Designer Vergleich Prozess-Management BPEL Console ActiveBPEL Administration Console Vergleich Zusammenfassung TravelBooking-Anwendung - BPEL Komponenten Geschäftsprozesse BookTravel CancelTravel GetTravelReservations Webservice-Security Oracle BPEL Process Manager Integration Web Services Invocation Framework Webservice-Security Fazit ActiveBPEL Enterprise Edition Integration Enterprise JavaBeans-Aufruf

11 Inhaltsverzeichnis ix 7.3 Webservice-Security Fazit Fazit und Ausblick Fazit zur Integration von BPEL in die J2EE-Umgebung Ausblick Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listings Quellenverzeichnis i iii v vii ix A Hardware- und Softwareanforderungen xv A.1 Oracle BPEL Process Manager xv A.2 ActiveBPEL Enterprise Edition xvi B SOAP-Aufrufe und Quelltexte xix C DVD mit Quellcode xxvii

12

13 KAPITEL 1 Einführung 1.1 Einleitung Wenn der Wind des Wandels weht, bauen die Einen Schutzmauern, die Anderen bauen Windmühlen. chinesische Weisheit Die Informatik verstand sich in der Vergangenheit sehr gut darin dem Wind des Wandels mit passend zugeschnittenen Windmühlen zu begegnen. Leider lässt der Wind nicht nach und die Konsequenz davon ist, dass die Windmühlen nach und nach zu Schutzmauern wurden. Natürlich wurden immer neue Windmühlen erstellt, aber das Bestreben der Informatik ist es, eine Windmühle zu erschaffen, die langfristig im Wind besteht. Die Entwicklung von Enterprise-Informationssystemen ist ein komplexer Prozess, in dem viele Probleme bei der Integration von Systemen, neuen Technologien und sich ändernden Anforderungen bewältigt werden müssen. Eine serviceorientierte Architektur (SOA) ist die neueste Methode, um Enterprise-Informationssysteme zu realisieren. Alle führenden Unternehmen bringen Produkte auf den Markt, um SOAs zu entwickeln und Geschäftsprozesse in der IT abzubilden. Dadurch gewinnt der Einsatz einer SOA auf dem Markt immer mehr an Bedeutung. Eine Großteil der 1

14 2 1 Einführung SOAs ist mittels Webservices realisiert. Die Komposition dieser Webservices zu Geschäftsprozessen erfolgt mittels Programmiersprachen, die nicht für diesen speziellen Anwendungsbereich entworfen wurden. Um diesen Anwendungsbereich abzudecken, wurde die Business Process Execution Language (BPEL) entwickelt. BPEL ist eine spezielle Programmiersprache und neuer Standard für die Orchestrierung von Webservices. Dadurch können Geschäftsprozessen deutlich effizienter und flexibler anhand von Services gestaltet und überwacht werden. Die kontinuierliche Weiterentwicklung von BPEL, an der namenhafte IT- Unternehmen beteiligt sind, zeigt, dass in BPEL die Windmühle gesehen wird, die im Wind der effizienten und komplett IT-gestützten Geschäftsprozessverarbeitung besteht. Diese Diplomarbeit vergleicht BPEL mit dem bisherigen Ansatz und beschreibt die Integration in ein vorhandenes Enterprise-Informationssystem. Das Unternehmen Wincor Nixdorf erstellt moderne IT-Systeme, um Prozesse und Abläufe in Banken und Handelsunternehmen zu optimieren. Besonders bei den IT- Managementlösungen, wie dem Cash Management, das die Bargeldflüsse für Banken und Handelsunternehmen optimiert, bietet sich ein erhebliches Potential für die Produktivitätsverbesserung durch die Umsetzung IT-gestützter Geschäftsprozesse. Die bei der Wincor Nixdorf International GmbH erstellten IT-Managementlösungen besitzen in vielen Bereichen deutliche Übereinstimmungen. Im Rahmen dieser Gemeinsamkeiten wurde eine Produktlinie [Zac07] geschaffen, die eine kostengünstige Entwicklung der Produkte ermöglicht. Die gemeinsame IT- Management-Produktlinie bezieht sich auf die Bereiche Analyse, Design, Architektur, Implementierung, Test, Training, Management, Infrastruktur und Prozesse. Es geht in der Produktlinie also nicht nur um die Realisierung einer gemeinsamen technologischen Plattform sondern auch um eine gemeinsame Nomenklatur und um die Erstellung eines gemeinsamen Softwareentwicklungsprozesses bezüglich der Infrastruktur für die Entwicklung, der Dokumentation, dem Build-Management und weiteren gemeinsamen Prozessen und Vorgehensweisen. Mittels dieser Produktlinie lassen sich einzeln vermarktbare Standardsoftwareprodukte erstellen, die auf einem einheitlichen Konzept und auf einer einheitlichen Infrastruktur aus definierten Komponenten basieren. Die Komponenten werden in drei Bereiche unterteilt. Zum einen sind fachliche Komponenten vorhanden, welche die einzelnen Funktionalitäten abbilden. Die technischen Komponenten umfassen

15 1.2 Zielsetzung 3 Desktops, Agenten und Adaptoren. Die Plattformkomponenten stellen Dienste, Utilities und Frameworks zur Verfügung, welche die Basis der Produktlinie bilden. Auf dieser Basis werden die benötigten Fachkomponenten aufgesetzt, um Standardprodukte zu erstellen, die genau die Wünsche des Kunden abbilden. Abbildung 1.1 zeigt zwei Produkte aus der Produktlinie, die auf derselben Basis aufsetzen, aber unterschiedliche Fachkomponenten enthalten. Die Fachkomponenten A und B sind identisch. Abbildung 1.1: Produktlinie Als Architektur liegt der IT-Management-Produktlinie eine SOA zu Grunde. Im Rahmen dieser Produktlinie soll der Einsatz von BPEL zur Orchestrierung der Services evaluiert werden. BPEL soll die Orchestrierung sowohl innerhalb der Fachkomponenten als auch für die gesamten Geschäftsprozesse übernehmen. 1.2 Zielsetzung Bisher wird die Service-Orchestrierung anhand Enterprise JavaBeans (EJB) durchgeführt. In diesem Zusammenhang wird sehr viel Java-Code geschrieben, der sowohl einen hohen Programmieraufwand erfordert als auch sehr unflexibel im Hinblick auf Änderungen ist. Abbildung 1.2 zeigt den derzeitigen Zustand. Als Alternative zum bisherigen Vorgehen soll die Verwendung einer BPEL-Engine zur Service-Orchestrierung untersucht werden. Dadurch sollen zum einen Änderungen und Anpassungen der Geschäftsprozesse stark vereinfacht und zum anderen eine

16 4 1 Einführung Abbildung 1.2: Ist-Zustand der Anwendung Prozessüberwachung ermöglicht werden. Hierzu muss die orchestrierende EJB durch BPEL-Prozessdefinitionen ersetzt werden, die in einer BPEL-Umgebung ausgeführt werden. Der Soll-Zustand wird in Abbildung 1.3 dargestellt. Abbildung 1.3: Soll-Zustand der Anwendung Diese Diplomarbeit verfolgt zwei Ziele. Als erstes soll ein Einblick in BPEL gegeben werden. Dabei wird der Fokus auf die Unterschiede zu der bisherigen programmatischen Umsetzung der Service-Orchestrierung in einer SOA gesetzt. Dieses geschieht anhand einer SOA-basierten Reisebuchungsanwendung, in der im weiteren Verlauf eine BPEL-Umgebung verwendet wird.

17 1.3 Systemvoraussetzungen 5 Das zweite Ziel ist die Darstellung der Integration einer BPEL-Umgebung in ein vorhandenes System unter der Berücksichtigung verschiedener Aspekte und Anforderungen hinsichtlich eines direkten Aufrufs von EJBs und der Verwendung von Webservice-Security. 1.3 Systemvoraussetzungen Die Standardsoftwareprodukte des Unternehmens Wincor Nixdorf International GmbH in der Abteilung Enterprise Management werden auf folgenden Applikationsservern eingesetzt: WebSphere-Applikationsserver von IBM in der Version JBoss-Applikationsserver von JBoss in der Version Im Rahmen dieser Diplomarbeit werden nur BPEL-Engines untersucht, die beide Applikationsserver unterstützen. Für die Datenspeicherung wird eine Oracle-Datenbank in der Version 9i verwendet. Da die Standardsoftwareprodukte auf unterschiedlichen Applikationsservern verwendet werden, kann keine applikationsserverabhängige Webservice-Implementierung verwendet werden, die z.b. WebSphere anbietet. Daher wird das Webservice-Framework Axis 1.2 der Apache Group [Axis] verwendet, um die Services in dem RPC- Format (Informationen zu den verschiedenen Formaten unter [AxisRPC] bereitzustellen. Die angebotenen Webservices der Anwendung sind ausschließlich synchrone Webservices. Deswegen werden vorwiegend synchrone Aufrufe genutzt. Um die Sicherheit der Webservice-Aufrufe zu gewährleisten, wird der Webservice- Security-Standard 1.1 von OASIS [WS-Security] verwendet.

18 6 1 Einführung 1.4 Vorgehensweise und Aufbau der Diplomarbeit Zunächst beschreibt das Kapitel 2 - Grundlagen die Grundlagen einer SOA und von BPEL. Auf Basis einer SOA wird eine Reisebuchungsanwendung erstellt, die in Kapitel 3 - TravelBooking-Anwendung - Servicebasierte Orchestrierung beschrieben wird. Anschließend wird in Kapitel 4 - BPEL-Umgebung eine Übersicht über die BPEL- Umgebungen gegeben, die in der Reisebuchungsanwendung zum Einsatz kommen. In Kapitel 5 - TravelBooking-Anwendung - BPEL wird zum einen die BPEL- Umgebung integriert und zum anderen der Unterschied zur bisherigen Orchestrierung dargestellt. Die spezifischen Analysen der BPEL-Umgebungen hinsichtlich der Ziele geschieht in den Kapiteln 6 - Oracle BPEL Process Manager - und 7 - ActiveBPEL Enterprise Edition. Abschließend wird in dem Kapitel 8 - Fazit und Ausblick ein allgemeines Fazit im Hinblick auf den Nutzen einer BPEL-Engine gegeben und eine Empfehlung hinsichtlich der Integration in die Produktlinie ausgesprochen.

19 KAPITEL 2 Grundlagen 2.1 Serviceorientierte Architektur Die Anforderungen an heutige Enterprise-Informationssysteme, besonders für betriebswirtschaftliche Softwareanwendungen, erfordern ein hohes Maß an Flexibilität. Dies liegt zum einen an den sich schnell ändernden Geschäftsprozessen von Unternehmen, die sich z.b. aus Zusammenschlüssen, Zukäufen oder gesetzlichen Änderungen ergeben. Zum anderen entwickeln sich die Technologien sehr schnell. Nur die Integration von neuen Technologien ermöglicht es, dass die Informationssysteme state of the art bleiben. Enterprise-Informationssysteme sind heterogen, enthalten viele unterschiedliche Systeme, Anwendungen, Technologien und Architekturen. Das System kann auf Dauer die Anforderungen der Industrie nur erfüllen, wenn alle genannten Aspekte kontinuierlich auf dem neuesten Stand der Technik bleiben Es gibt viele Methoden, die Probleme der sich ändernden Anforderungen, der Technologieentwicklung und der Integration zu bewältigen. Die SOA ist die aktuelle Architektur, um komplexe Enterprise-Informationssysteme zu entwickeln. Dabei ist dieser Ansatz keine grundlegend neue Architektur, sondern eine Entwicklung aus bekannten verteilten Anwendungsarchitekturen und Integrationsmethoden. Daher wird die SOA als Evolution anstatt Revolution betrachtet. Diese Evolution war nötig, da alle bisherigen Ansätze fehlende Generalität aufwiesen. Die Technologien waren entweder sprach-, betriebssystem- oder herstellerabhängig. 7

20 8 2 Grundlagen In manchen Fällen waren die Ansätze auch zu komplex oder die ausgetauschten Daten unterlagen einem Modell, auf das sich nicht alle Systeme einigen konnten. Eine SOA ist in einem hohen Maße technologieunabhänigig und bietet daher die nötige Generalität, um langfristig Einsatz zu finden. In einer SOA werden Konzepte, Architekturen und Frameworks festgelegt, die eine kosteneffiziente Entwicklung, Integration und Pflege von Enterprise-Informationssystemen ermöglichen. Dieses geschieht durch Reduktion der Komplexität, einfacher Integration und Wiederverwendung von Komponenten. Besonders im Bereich der Business-to-Business (B2B) Integration spielt eine SOA eine große Rolle, da durch die festgelegten Schnittstellen Prozesse zwischen mehreren Unternehmen einfacher zu realisieren sind. Abbildung 2.1 zeigt einen Kunden, der einen Service des Unternehmens A nutzt. Das Unternehmen A integriert noch zwei weitere Unternehmen, um die Dienstleistung zur Verfügung zu stellen. Dem Kunden bleibt das in diesem Fall verborgen. In Zukunft wird die Integration mehrerer Unternehmen in eine Dienstleistung ein sehr wichtiges Thema werden. Abbildung 2.1: B2B-Integration Für eine SOA gibt es viele Definitionen. In [JMS06] wird auf diese SOA-Definition aus einem Artikel von Bernhard Borges, Kerrie Holley und Ali Arsanjani verwiesen. SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.

21 2.1 Serviceorientierte Architektur Konzepte Eine SOA ist in einem hohen Maße technologieunabhängig. Fälschlicherweise wird eine SOA oft mit Webservices gleichgesetzt. Webservices stellen jedoch nur die am häufigsten verwendete Realisierung dar. Laut [Zac05] besteht das Konzept einer SOA aus folgenden drei unterschiedlichen Rollen, welche in Abbildung 2.2 dargestellt werden. Service-Provider: Der Service-Provider stellt einen Service zur Verfügung. Dieser Service kann in einer Service-Registry beim Service-Broker veröffentlicht werden. Service-Consumer: Der Service-Consumer nutzt einen zur Verfügung gestellten Service und findet diesen über den Service-Broker. Service-Broker: Der Service-Broker verwaltet registrierte Referenzen auf Services und bietet Suchfunktionen an, um die Services zu finden. Abbildung 2.2: SOA-Basiskonzept Die Kommunikation findet ausschließlich über die definierten Schnittstellen der Services statt. Hinter den Schnittstellen bleibt den Kommunikationspartnern die Implementierung verborgen.

22 10 2 Grundlagen Komponenten Eine SOA ist eine Standardarchitektur und sieht laut [Lie07] eine logische Teilung zwischen Applikationen, Integrationsmechanismen, Services und Orchestrierung vor. Die Applikation stellt das neue oder bestehende System und die logische Datenspeicherung dar. Services sind die Schnittstellen zu funktionalen Bereichen oder einzelnen Anwendungen. Die Orchestrierung sorgt für die Steuerung der Abläufe unter Einbeziehung mehrerer Services. Dadurch können einzelne Services zu Geschäftsprozessen zusammengefügt werden. Ein Geschäftsprozess ist durch eine Sammlung von koordinierten Aktivitäten und Serviceaufrufen definiert, die ein Geschäftsergebnis erzeugen. Die Services können z.b. von einem Applikationsserver bereitgestellt werden. Dieses wird in Abbildung 2.3 dargestellt. Die Integrationsarchitektur legt die Kommunikation zwischen einzelnen Services und den Services mit deren Implementierungen fest. Abbildung 2.3: Geschäftsprozessaufbau Die Ebenen Präsentation, Orchestrierung, Services und Integrationsarchitektur sind die wichtigsten Komponenten einer SOA. Wie Abbildung 2.4 zeigt, setzten diese auf bestenden Systemen und der Infrastruktur auf. Die Präsentationsebene bildet das User-Interface zu der Anwendung. Viele verschiedene Möglichkeiten können für die Umsetzung genutzt werden. Es können Portale, Office-Applikationen oder Client-Applikationen (Rich-Client oder Web-Client) verwendet werden.

23 2.1 Serviceorientierte Architektur 11 Abbildung 2.4: SOA-Ebenen [Lie07] In der Orchestierungsebene werden Geschäftsprozesse und -regeln abgebildet. In dieser Ebene befindet sich die Geschäftslogik der Anwendung. Auf der Serviceebene sind die standardisierten Serviceschnittstellen und die Verwaltungsmechanismen zu finden. Die Integrationsarchitekturebene bildet die Infrastruktur zur Verknüpfung der Services und stellt die Verbindung zur Anwendung, zur Datenbank und zum User- Interface dar Service Der Service ist das Herzstück der SOA. Ein Service stellt wie in [Bie04] beschrieben eine fachliche Komponente oder ein Geschäftsprozessabschnitt bereit. Die Funktionalität muss in dem Service abgeschlossen sein. Ebenso muss dieser von anderen Services so weit wie möglich unabhängig sein. Festgelegte Schnittstellen, die strikt von der Implementierung zu trennen sind, bilden den Vertrag zwischen Service-Provider und Service-Consumer. Die Schnittstelle

24 12 2 Grundlagen definiert öffentliche Methodensignaturen und ermöglichen die Technologieneutralität. Der Service-Consumer ruft anhand der definierten Schnittstelle den Service des Service-Providers auf und erhält das definierte Ergebnis. Dabei bleibt die eingesetzte Technologie und Logik dem Service-Consumer verborgen. Die Semantik sollte aus sprechenden Bezeichnungen und Metainformationen bestehen, die einen automatisierten Zugriff auf Funktionalitäten einer Komponente erleichtern. In der Beschreibung eines Services sollten ebenfalls Aspekte der Servicequalität enthalten sein. Diese können sich z.b. auf den Bereich Sicherheit oder Performance beziehen. Besonders wichtig bei der SOA ist die lose Kopplung von Services. Dieses bedeutet, dass nur die nötigsten Abhängigkeiten vorhanden sind. Dadurch erhöht sich zum einen die Wiederverwendbarkeit von Services und zum anderen können Änderungen flexibler durchgeführt werden. Services müssen also nach dem Grundsatz Maximal Cohesion - Minimal Coupling erstellt werden. Sie müssen ihre Aufgabe genau abbilden und dürfen dabei möglichst wenig Verknüpfungen zu anderen Services haben. Es gibt zwei Grundarten von Services, die anhand ihrer Granularität unterschieden werden. Component-Services sind atomare Services, die vollkommen unabhängig von anderen Services sind. Eine grobgranularer Service wird als Composite-Service oder Business-Service bezeichnet. Hierbei werden Component-Services z.b. über Orchestrierung koordiniert. Composite-Services umfassen nur kurze Transaktionen. In [Bie05] werden weitere Servicearten definiert, die in einer SOA verwendet werden. Diese Arten beziehen sich auf ihre Funktionalität und Aufgabe innerhalb der Anwendung. Ein Workflow-Service wird verwendet, wenn längere Transaktion durchgeführt werden. Dieser Service kann als Zustandsautomat betrachtet werden, bei dem der Übergang von dem Start in den Endzustand mehrere Stunden oder Tage dauern kann. Ein weiterer Service ist der Data-Service, ein dem DAO-Pattern [DataAccessObject] ähnlicher Compo-nent-Service, der eine Abstraktion zur konkreten Datenquelle bietet und den Zugriff auf die Persistenzschicht kapselt. Der Compensating-Service ist für Protokolle oder kompensierende Transaktionen nach fachlichen oder technischen Fehlern zuständig, welches durch die lose Kopp-

25 2.1 Serviceorientierte Architektur 13 lung der Services notwendig ist. Die bisher ausgeführten Component-Services sind abgeschlossen und bekommen keine Meldung, dass im weiteren Verlauf des Prozesses ein Fehler aufgetreten ist. Um ein Rollback durchzuführen, müssen die bereits abgeschlossenen Aktionen rückgängig gemacht werden. Abbildung 2.5 zeigt eine virtuelle SOA-Komponente mit diesen Servicearten. Abbildung 2.5: Virtuelle SOA-Komponente [Bie05] In einer SOA sind die Service-Operationen als Nachrichten definiert. In den Nachrichten werden ausschließlich Daten plattform- und sprachunabhängig übertragen, die keine Logik enthalten. Diese Unabhängigkeit kann durch Schemata realisiert werden. Das Konzept unterscheidet sich grundlegend von der Objektorientierung. Services übertragen ausschließlich Daten und kein Verhalten wie z.b. Methoden bei Objekten. Weiterhin sollen Operationen idempotent sein. Operationen, die unabhängig von der Anzahl der Aufrufe mit gleichen Daten immer zu den gleichen Ergebnissen führen, werden als idempotent bezeichnet Komposition von Services Die Komposition von einzelnen Services zu einem Geschäftsprozess ist eines der wichtigsten Konzepte in der SOA. Die Services werden in einer bestimmten Reihenfolge angeordnet und verfolgen festgelegte Regeln. Durch die Komposition von Component-Services zu grobgranularen Services bis hin zum gesamten Geschäftsprozess können Anwendungen flexibel, relativ einfach und übersichtlich erstellt werden. Der Geschäftsprozess kann schnell verändert und an neue Anforderungen angepasst

26 14 2 Grundlagen werden. Erst wenn die Ebene der Service-Komposition erreicht ist, kommen die Vorteile einer SOA zur Geltung. Die Komposition von Services kann grundsätzlich auf zwei verschiedene Arten erfolgen. Orchestrierung Choreographie Die Orchestrierung erfolgt über einen zentralen Service, der, wie in Abbildung 2.6 zu sehen, die Aufrufe der weiteren Services steuert. Dieser Service enthält das gesamte Abbildung 2.6: Orchestrierung [JMS06] Wissen über den Geschäftsprozess und ist für den korrekten Ablauf verantwortlich. Die aufgerufenen Services sind lose gekoppelt und haben keine Informationen über den gesamten Prozess. Bei der Choreographie hingegen gibt es keinen zentralen Koordinator. Wie Abbildung 2.7 zeigt, kennt jeder Service genau seine Stelle in dem Gesamtprozess und weiß, wann welche Operation mit welchem Service ausgeführt werden muss. Die Choreographie findet sein Einsatzgebiet generell innerhalb von Systemen. Ein Beispiel hierfür ist die Aufbereitung größerer Datenmengen über Data-Services. Die Orchestrierung hingegen sollte bei systemübergreifenden Serviceaufrufen verwendet werden. Der Geschäftsprozess kann durch die zentrale Steuerung aus allen Services zusammengestellt werden, da sie den Gesamtprozess nicht kennen. Es besteht durch die Unabhängigkeit der einzelnen Services eine sehr hohe Flexibilität. Änderungen des Geschäftsprozesses finden an einer Stelle statt. Auftretende Fehler können zentral behandelt werden.

27 2.1 Serviceorientierte Architektur 15 Abbildung 2.7: Choreographie [JMS06] In dem Rahmen der Diplomarbeit wird ausschließlich die Orchestrierung verwendet, da ein systemübergreifender Geschäftsprozess betrachtet wird Technologieeinsatz Die Architektur einer SOA mit weiteren Konzepten hinsichtlich Quality of Service wird in Abbildung 2.8 dargestellt. Abbildung 2.8: SOA-Architektur [JMS06] Nachfolgend werden Technologien vorgestellt, die für die Umsetzung einer SOA verwendet werden können. Abbildung 2.9 zeigt dieselbe Architektur mit möglichen Technologien zur Umsetzung. Die Grundlage bildet der Enterprise-Service-Bus, welcher die Kommunikations-Infrastruktur für die Services bereitstellt. Die Kommunikation der Services findet über das SOAP-Protokoll statt. Bereitgestellt werden die Services in diesem Fall als Webservices, die mittels WSDL-Dokumenten (Web

28 16 2 Grundlagen Service Description Language: Informationen in [CJ04]) beschrieben werden. Die Realisierung erfolgt über herkömmliche Programmiersprachen. Jetzt müssen diese einzelnen Services zu einem Geschäftsprozess zusammengesetzt werden, welches durch BPEL realisiert wird. Besonders wichtig ist, dass die Technologien nach den SOA-Richtlinien eingesetzt werden. Die Technologien alleine ergeben noch keine SOA. Abbildung 2.9: SOA-Architektur mit Technologie [JMS06] Wenn die Top-Down-Sicht auf die Architektur angewendet wird, steht auf höchster Ebene der Geschäftsprozess aus angeordneten Services. BPEL wird in diesem geschäftsprozessorientierten Ansatz verwendet und kann sowohl bei Workflow-Services als auch bei Composite-Services eingesetzt werden. 2.2 Business Process Execution Language BPEL repräsentiert einen Zusammenfluss aus den beiden Sprachen WSFL von IBM und XLANG von Microsoft. In WSFL werden Geschäftsprozesse auf Basis von Webservices beschrieben. Diese sind in einem Modell per XML definiert und bilden einen gerichteten Graphen. XLANG hingegen ist eine in Blöcke strukturierte Sprache. BPEL verbindet diese beiden Aspekte und bietet eine breite Möglichkeit der Geschäftsprozessmodellierung. Die erste Version von BPEL wurde von den Unternehmen IBM, BEA und Microsoft im August 2002 entwickelt. Nachdem SAP und Siebel sich ebenfalls anschlossen, wurde im März 2003 die Version 1.1 spezifiziert, die verschiedene Änderungen und Verbesserungen umfasst.

29 2.2 Business Process Execution Language 17 Seit April 2003 wurde BPEL für Standardisierungszwecke OASIS (Organisation for the Advancement of Structured Information Standards [OASIS]) übergeben, wo das WSBPEL TC (Web Services Business Process Execution Language Technical Committee [WSBPEL TC]) gegründet wurde. Im April 2007 wurde der OASIS Standard WS-BPEL in der Version 2.0 veröffentlicht. Die Anzahl der mitwirkenden Unternehmen hat sich stark vergrößert. Bald wird OASIS WS-BPEL in der Version 3.0 verabschieden. Dies zeigt, dass sich BPEL weiterentwickelt und unterstreicht, wie wichtig BPEL für die Industrie ist. Die Spezifikationen sind unter [BPELSpecs] erhältlich. Ebenfalls sind dort Unterschiede der Versionen veranschaulicht, auf die nicht weiter eingangen wird. Die folgenden Kapitel beziehen sich auf [JMS06] Einführung Der Geschäftsprozess wirkt nach außen wie ein einziger Service. Von dem Prozess verwendete Services bleiben nach außen verborgen. Es wird zwischen Geschäftsprozessen unterschieden, die zum einen nur innerhalb eines Unternehmens ablaufen und zum anderen die Services anderer Unternehmen nutzen. Abbildung 2.10 zeigt die beiden unterschiedlichen Arten. Ein unternehmensinterner Geschäftsprozess würde in diesem Fall nur die ersten beiden Services nutzen. Abbildung 2.10: Geschäftsprozessarten