Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen

Tesis , 2006 , 117 Páginas , Calificación: 1,3

Informática - Informatica de negocios

Ein zurzeit aktuelles Thema im Bereich der Informationstechnologie sind die so genannten service-orientierten Architekturen (SOA).Viele Firmen beschäftigen sich aktuell mit Serviceorientierung und prüfen, ob die Einführung einer solchen Architektur einen Mehrwert für das Unternehmen bringen kann. Diese Arbeit analysiert das Konzept serviceorientierter Architekturen. Der Schwerpunkt liegt dabei auf der Verbindung und den daraus resultierenden Vorteilen dieser Architektur im Zusammenhang mit Unternehmensportalen. Zusätzlich zu der Analyse von serviceorientierten Architekturen und Unternehmensportalen wird im Anschluss an diese theoretischen Betrachtungen die Umsetzung eines Portal-Protypen in einem Unternehmen beschrieben. Damit ergeben sich für die Arbeit drei elementare Themenbereiche: 1.) service-orientierte Architekturen 2.) Unternehmensportale
3.) konkrete Realisierung eines Portal-Prototypen für die Collogia AG Das grundlegende Konzept serviceorientierter Architekturen liegt darin, über einheitliche Schnittstellen ausgewählte Funktionen oder Daten bereitzustellen. Eine Komponente der Architektur, die dieses leisten kann, wird dabei als Service bezeichnet. Auf diese Weise können komplexe, zusammenhängende heterogene Anwendungen erstellt und verknüpft werden. Das verwendete Prinzip serviceorientierter Architekturen ist dabei nicht neu. Verteilte Anwendungen auf heterogener Basis können beispielsweise ebenfalls durch CORBA realisiert werden (vgl. [Corba 2006]). Bei CORBA spricht man in diesem Zusammenhang von definierten Diensten und Protokollen. Daher ist lediglich der Begriff des Services relativ neu, die grundlegende (technische) Idee allerdings nicht. Somit können serviceorientierte Architekturen durchaus als eine Weiterentwicklung des CORBA-Prinzips gesehen werden (vgl. [Dostal u.a. 2005]). Das erste Auftreten des Begriffes serviceorientierter Strukturen ist dabei auf Hewlett-Packard zurückzuführen [Hauser und Löwer 2004]. HP wollte 1999 mit e-Speak eine Plattform für das Web schaffen, auf der Daten und Funktionalitäten als Service zur Verfügung gestellt werden können. Das Produkt fand allerdings keine Akzeptanz am Markt. Das e-Speak Projekt scheiterte, aber der Begriff service-orientierter Architekturen war damit geboren [Hauser und Löwer 2004].

Inhaltsverzeichnis

1 Einleitung

2 Service-orientierte Architekturen
2.1 Einordnung des Architekturbegriffes
2.2 Definition einer Software-Architektur
2.3 Ziele einer Software-Architektur
2.4 Grundlagen service-orientierter Architekturen
2.4.1 Einführung
2.4.2 Begriffsabgrenzung
2.4.3 Der Anspruch an SOA - Definition und Ziele
2.5 Die Implementierung service-orientierter Architekturen
2.5.1 SOAP
2.5.2 Web Service Description Language (WSDL)
2.5.3 Universal Description, Discovery and Integration (UDDI)
2.6 Weiterführende Aspekte service-orientierter Architekturen
2.6.1 Top-Down Ansatz
2.6.2 Granularität
2.6.3 Umsetzung von Geschäftsprozessen in SOA
2.6.3.1 Business Process Execution Language (BPEL)

3 Unternehmensportale
3.1 Historische Entwicklung und Begriffsabgrenzung
3.2 Klassifizierung von Portalen
3.2.1 Offene und geschlossene Portale
3.2.2 Horizontale und Vertikale Portale
3.3 Analyse von Unternehmensportalen
3.3.1 Definition eines Unternehmensportals
3.3.2 Motivation für die Einführung eines Unternehmensportals
3.3.2.1 Kooperation
3.3.2.2 Unterstützung der Unternehmensstrategie
3.3.2.3 Motivation der Mitarbeiter
3.3.3 Kernelemente eines Unternehmensportals
3.3.3.1 Personalisierung und Benutzerverwaltung
3.3.3.2 Single Sign On
3.3.3.3 Kommunikation und Collaboration
3.3.3.4 Workflow Management
3.3.3.5 Wissensmanagement
3.3.4 Integration
3.3.4.1 Datenintegration
3.3.4.2 Systemintegration
3.3.4.3 Prozessintegration
3.4 Die Bedeutung des Portals im Rahmen SOA
3.4.1 Standards für Portalimplementierungen
3.4.2 Portallösungen im SOA-Umfeld

4 Entwurf und Implementierung eines Portal-Prototypen
4.1 Einführung und Überblick in die SOA-Strategie der SAP AG
4.1.1 SAP Architektur Überblick
4.1.2 Architektur des SAP Enterprise Portals
4.2 Überblick über die Systemlandschaft
4.2.1 Einführung
4.2.2 Betrachtung der einzelnen Komponenten
4.2.2.1 Infrastruktur der Systemlandschaft
4.2.2.2 Portal-Server
4.2.2.3 Supplier Relationship Management System
4.2.3 Fachliche Struktur des Unternehmensportals
4.3 Abgrenzung Produktivportal vs. Prototypenimplementierung
4.4 Vorteile für das Unternehmen durch die Portaleinführung
4.5 Anwendungsintegration im Unternehmensportal
4.5.1 Integration eines SAP Backend-Systems
4.5.1.1 Aufgabenbeschreibung
4.5.1.2 Vorgehensweise
4.5.1.3 Aktivierung von Single Sign On (SSO)
4.5.1.3.1 SAP Logon Tickets
4.5.2 Web Service Integration am Beispiel von google.de

5 Fazit und Ausblick

6 Literaturverzeichnis

7 Anhang
A) SOAP und WSDL Beispiele
B) Java Beispiele
C) Screenshots aus dem Unternehmensportal der Collogia AG

Abbildungsverzeichnis

Abbildung 1: Funktionsweise service-orientierter Architekturen [Dostal u.a. 2005]

Abbildung 2: Schematische Darstellung des EAI-Konzepts [Kaib 2002]

Abbildung 3: Aufbau einer SOAP-Nachricht [Dostal u.a. 2005]

Abbildung 4: Dokumentenstruktur eines WSDL-Dokuments [Hauser, Löwer 2004]

Abbildung 5: Entwicklung der Geschäftsprozessmodellierungssprachen [Dostal u.a. 2005]

Abbildung 6: Basisstruktur eines WSBPEL-Dokuments [Dostal u.a. 2005]

Abbildung 7: Beispiel eines Portals

Abbildung 8: Kategorisierungsmatrix für Portale [Grossmann Koschek 2005]

Abbildung 9: Motive für die Einführung eines Unternehmensportals

Abbildung 10: Prinzip des Single Sign On

Abbildung 11: EAI Prinzip zur Systemintegration [Grossmann Koschek 2005]

Abbildung 12: SAP NetWeaver Komponentenübersicht [Goebel, Ritthaler 2004]

Abbildung 13: Komponenten des SAP Enterprise Portals [Goebel, Ritthaler 2004]

Abbildung 14: Überblick Unification Server [Goebel, Ritthaler 2004]

Abbildung 15: Systemlandschaft Collogia AG

Abbildung 16: Benutzer und Gruppen der Collogia AG

Abbildung 17: Rollenhierarchie im Portal der Collogia AG

Abbildung 18: Portal Content Directory der Collogia AG

Abbildung 19: Worksetansicht im Unternehmensportal der Collogia AG

Abbildung 20: Portal Content des GB SAP Beratung

Abbildung 21: Rollenzuordnung zur Gruppe "SAP Beratung"

Abbildung 22: Portalinhalt für einen Mitarbeiter des GB IT-Services

Abbildung 23: Portalinhalt für ein Mitglied der Gruppe "Vorstand"

Abbildung 24: Portalbereich eines Mitarbeiters der Collogia AG

Abbildung 25: Integration des Mailservers im Unternehmensportal

Abbildung 26: Transaktion "db13" im SRM-System auf colvm11

Abbildung 27: Konfiguration eines Backend-Systems im Portal

Abbildung 28: Anlegen eines neuen iViews

Abbildung 29: Workset GB SAP Beratung

Abbildung 30: Portalausschnitt eines Mitarbeiters des GB SAP Beratung

Abbildung 31: Integration eines SAP-Systems im Unternehmensportal

Abbildung 32: Eingabemaske für den Google Web Service

Abbildung 33: Ergebnisanzeige des Google Web Services

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Vorwort

Für die Realisierung meiner Diplomarbeit habe ich mich relativ frühzeitig dazu entschieden, diese Arbeit nicht ausschließlich auf rein theoretischer Basis zu schreiben. Ich wollte diese Arbeit nutzen, um einen weiteren Schritt in die Praxis zu gehen. Daher habe ich nach einem Unternehmen gesucht, dass mir die Möglichkeit bietet (nach einem einführenden Praktikum) eine Diplomarbeit direkt im Unternehmen zu schreiben. Bei dieser Suche habe ich mich für die Collogia Unternehmensberatung AG in Köln entschieden. Dort habe ich zunächst ein dreimonatiges Praktikum im SAP Basis Bereich absolviert, um anschließend auch dort meine Diplomarbeit schreiben zu können.

Mein zu bearbeitendes Diplomthema liegt im Bereich der service-orientierte Architekturen (SOA). Der Schwerpunkt der Arbeit soll dabei in der Analyse der Kombination von service- orientierten Architekturen und Unternehmensportalen liegen. Durch die Arbeit in der SAP Basis Abteilung der Collogia AG standen mir neben den Ressourcen für den Aufbau einer Systemlandschaft auch eine aktuelle Portalsoftware zur Verfügung (SAP Enterprise Portal 6.0). Diese Kombination bot für mich eine sehr gute Chance, weil ich so zum einen die Möglichkeit hatte, mich auf wissenschaftlicher Basis intensiv mit service-orientierten Architekturen zu beschäftigen, auf der anderen Seite sehr wertvolle praktische Erfahrungen im SAP-Umfeld sammeln konnte. Zur Veranschaulichung der Bedeutung eines Unternehmensportals im SOA-Umfeld habe ich für die Collogia AG einen Portal-Prototypen auf Basis des SAP Enterprise Portals entwickelt.

Danksagung

An dieser Stelle möchte ich mich zunächst bei der Collogia AG bedanken, die mir die benötigten Ressourcen für meine Diplomarbeit zur Verfügung gestellt hat. Neben der eigentlichen Arbeit an meinem Diplomthema habe ich auch durch das Umfeld in der Unternehmensberatung und einigen kleinen Projekten sehr viel dazulernen können. Ich habe in dieser relativ kurzen Zeit wichtige Erfahrungen gemacht, die mir ohne den Schritt in die Praxis vergönnt geblieben wären. Für diese Möglichkeit bin ich sehr dankbar. Besonderer Dank gilt dabei meinen beiden Betreuern Bernd Stevens und Markus Stockhausen. Von beiden Mitarbeitern der Collogia AG habe ich nicht nur fachliche Unterstützung beim Aufbau des Unternehmensportals erhalten, sondern auch wertvolle Unterstützung und zahlreiche Hinweise für die grundlegenden theoretischen Kapitel dieser Diplomarbeit bekommen. Darüber hinaus möchte ich mich ebenfalls bei Herrn Juniorprofessor Dr. Thomas Barth für die Betreuung dieser Diplomarbeit und die damit verbundene gute Zusammenarbeit bedanken.

1 Einleitung

Ein zurzeit aktuelles Thema im Bereich der Informationstechnologie sind die so genannten service-orientierten Architekturen (SOA). Viele Firmen beschäftigen sich aktuell mit Service-orientierung und prüfen, ob die Einführung einer solchen Architektur einen Mehrwert für das Unternehmen bringen kann. Diese Arbeit analysiert das Konzept service-orientierter Architekturen. Der Schwerpunkt liegt dabei auf der Verbindung und den daraus resultierenden Vorteilen dieser Architektur im Zusammenhang mit Unternehmensportalen. Zusätzlich zu der Analyse von service-orientierten Architekturen und Unternehmensportalen wird im Anschluss an diese theoretischen Betrachtungen die Umsetzung eines Portal-Protypen in einem Unternehmen beschrieben. Damit ergeben sich für die Arbeit drei elementare Themenbereiche:

1.) service-orientierte Architekturen
2.) Unternehmensportale
3.) konkrete Realisierung eines Portal-Prototypen für die Collogia AG

Das grundlegende Konzept service-orientierter Architekturen liegt darin, über einheitliche Schnittstellen ausgewählte Funktionen oder Daten bereitzustellen. Eine Komponente der Architektur, die dieses leisten kann, wird dabei als Service bezeichnet. Auf diese Weise können komplexe, zusammenhängende heterogene Anwendungen erstellt und verknüpft werden. Das verwendete Prinzip service-orientierter Architekturen ist dabei nicht neu. Verteilte Anwendungen auf heterogener Basis können beispielsweise ebenfalls durch CORBA realisiert werden (vgl. [Corba 2006]). Bei CORBA spricht man in diesem Zusammenhang von definierten Diensten und Protokollen. Daher ist lediglich der Begriff des Services relativ neu, die grundlegende (technische) Idee allerdings nicht. Somit können service-orientierte Architekturen durchaus als eine Weiterentwicklung des CORBA-Prinzips gesehen werden (vgl. [Dostal u.a. 2005]). Das erste Auftreten des Begriffes service-orientierter Strukturen ist dabei auf Hewlett-Packard zurückzuführen [Hauser und Löwer 2004]. HP wollte 1999 mit e-Speak eine Plattform für das Web schaffen, auf der Daten und Funktionalitäten als Service zur Verfügung gestellt werden können. Das Produkt fand allerdings keine Akzeptanz am Markt. Das e-Speak Projekt scheiterte, aber der Begriff service-orientierter Architekturen war damit geboren [Hauser und Löwer 2004]. Heute werden service-orientierte Architekturen, kurz SOA genannt, von einigen Experten als „Hype“ bezeichnet. Sie rechnen nicht damit, dass sich solche Architekturen durchsetzen werden und somit bald vom Softwaremarkt verschwinden. Entgegengesetzte Ansichten sehen in SOA eine Revolution, um IT-Architekturen neu und flexibel zu gestalten. Diese Diplomarbeit macht es sich zur Aufgabe, die Aspekte service- orientierter Architekturen zu analysieren. Im Vordergrund stehen, nach einer generellen Betrachtung service-orientierter Architekturen, die Verbindung und der daraus resultierende Mehrwert dieser Architekturen mit prozessorientierten Unternehmens- portalen. Kapitel 2 beinhaltet eine umfassende Analyse service-orientierter Architekturen. Dabei wird der Begriff zunächst in den Kontext allgemeiner IT-Architekturen eingeordnet. Danach werden service-orientierte Architekturen definiert und ihre wesentlichen Merkmale und Ziele vorgestellt. Es wird aufgezeigt, dass die verwendeten Prinzipien nicht völlig neu sind (vgl. vorangegangenes CORBA-Beispiel), allerdings einen entscheidenden Mehrwert im Gegensatz zu bisherigen Architekturen leisten können. Nach der Analyse des generellen Konzepts werden Möglichkeiten zur Implementierung serviceorientierter Architekturen vorgestellt. Zum Abschluss dieses Kapitels werden weiterführende Aspekte behandelt. Dazu zählen unter anderem die strategische Einführung service-orientierter Architekturen und die Verbindung von service-orientierten Architekturen mit Geschäftsprozessmodellierungssprachen. Kapitel 3 analysiert anschließend die Thematik der Unternehmensportale. In diesem Kapitel wird ebenfalls zunächst der Portal-Begriff eingeordnet, um anschließend aufzuzeigen, wie man Portale kategorisieren kann. Der Fokus liegt dabei auf prozessorientierten Unternehmensportalen. Diese werden definiert, anschließend werden die Vorteile und Kernelemente eines prozessorientierten Unternehmensportals vorgestellt. Am Ende des dritten Kapitels werden dann beide Themenkomplexe miteinander verknüpft. Diese Verknüpfung stellt den eigentlichen Mehrwert der vorliegenden Diplomarbeit dar. Nach einer separaten Betrachtung beider Themenkomplexe wird die Verbindung zwischen service-orientierten Architekturen und prozessorientierten Unternehmensportalen aufgezeigt. Abschließend wird der Vorteil analysiert, den Unternehmen aus einer solchen Verbindung für sich nutzen können. In dem nachfolgenden Kapitel 4 werden dann, aufbauend auf dem vermittelten theoretischen Wissen der Kapitel 2 und 3, ausgewählte Funktionen eines Unternehmensportals in Form eines Portal-Prototypen für die Collogia AG realisiert. Dieses Kapitel beschreibt den praktischen Teil der Diplomarbeit und dient zur Veranschaulichung der in Kapitel 3 beschriebenen Aspekte eines Unternehmensportals. Das abschließende Kapitel 5 fasst die Arbeit aus den vorangegangenen Kapiteln noch einmal zusammen. Neben einem Fazit der vorliegenden Arbeit wird ebenfalls ein Blick auf die Zukunft service-orientierter Architekturen geworfen.

2 Service-orientierte Architekturen

2.1 Einordnung des Architekturbegriffes

Um das Konzept service-orientierter Architekturen zu verstehen, muss man sich mit den sprachlichen Bausteinen beschäftigen: „Service-orientierung“ und „Architektur“. Um an das Thema heranzuführen, wird in diesem Kapitel zunächst allgemein auf den Begriff der Architekturen in IT-Projekten eingegangen. Danach wird der konkrete Ansatz der serviceorientierten Architekturen analysiert.

Der Architekturgedanke im Zusammenhang mit Software ist circa 30 Jahre alt ist [Shaw, Garlan 1996]. Daher gibt es auch eine Vielzahl unterschiedlicher Definitionen zu diesem Gebiet. Es existiert nicht die einheitliche Definition für Software-Architektur (vgl. [Software Engineering Institute 2006]. Es geht vielmehr darum, die Vorteile einer Software- Architektur zu erkennen. Diese können allerdings nicht allgemein vordefiniert werden, sondern sind vom jeweiligen Softwareprojekt abhängig. Ein Beispiel zeigt der Vergleich zwischen der Suchmaschine Google (www.google.de) und der Kommunikation zwischen den Systemen einer Bank. Google muss in der Lage sein, viele Anfragen pro Sekunde performant beantworten zu können. Dabei können die Daten unverschlüsselt übertragen werden, da die Ergebnisse dieser öffentlichen Suchmaschine nicht vertraulich sind. Bei einem Banksystem hingegen ist es sehr wichtig, dass die Daten vertraulich behandelt werden und es keinem unbefugten Dritten gelingt, diese Übertragung abzuhören. Somit werden in beiden Szenarien unterschiedliche Anforderungen an die jeweilige Software- Architektur gestellt. Auf der einen Seite ist der Anspruch an Sicherheit bei der Übertragung hoch, auf der anderen Seite ist die Performanz des Systems das entscheidende Kriterium. Das Ziel dieses einleitenden Kapitels ist es daher nicht, Software-Architektur eindeutig zu definieren und die möglichen Vorteile diverser Architekturen zu beleuchten. Es dient lediglich dazu, ein Grundverständnis für Architekturen und deren Nutzen zu legen. Die nachfolgende Betrachtung ist mit Hinblick auf service-orientierte Architekturen zu sehen. Zunächst wird in diesem Rahmen eine Definition gegeben, anschließend konkrete Vorteile genannt. Sind diese Grundlagen definiert, werden die service-orientierten Architekturen im Kapitel 2.4 im Detail betrachtet. Weiterführende Literatur zum allgemeinen Verständnis von Softwarearchitekturen findet sich beispielsweise in [Posch u.a. 2004] oder [Vogel u.a. 2005].

2.2 Definition einer Software-Architektur

Wie im vorangegangenen Kapitel erwähnt, gibt es für die Architektur einer Software keine allgemeingültige Definition. Es existieren in der Literatur eine Vielzahl von parallelen Definitionen. Zur Verdeutlichung werden im Folgenden drei ausgewählte Definitionen von Software-Architektur vorgestellt:

„ Eine Software-Architektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Komponenten. “ [Balzert 2002]

„ Software-Architektur besch Äftigt sich mit dem Design und der Implementierung von Software auf höchster Strukturebene. Sie ist das Resultat des sorgf Ältig ausgew Ählten Zusammenbaus einer bestimmten Anzahl an architektonischen Elementen, um sowohl den Hauptfunktionalit Äten, als auch den Performance Anforderungen wie Verteilbarkeit und Verfügbarkeit gerecht zu werden. Software-Architektur besch Äftigt sich mit Abstraktion, mit Dekomposition und Komposition, mit Stilen und Ästhetik. “ (vgl. [Kruchten 1994])

Eine Software-Architektur besteht (a) aus einer Verteilungsstrategie und (b) einer Koordinationsstrategie. Die Verteilungsstrategie hat die Aufgabe, dass gesamte System in eigenst Ändige, nicht-überschneidende Teile oder Komponenten aufzuteilen. Die Koordinationsstrategie beschreibt die exakt definierten Schnittstellen zwischen diesen Teilen. (vgl. [Crispen, Stuckey 94])

Diese ausgewählten Definitionen sollen exemplarisch verdeutlichen, dass es keine allgemeingültige Definition zu diesem Thema gibt. Die Definition einer SoftwareArchitektur ist immer ausgehend von den verfolgten Zielen und Absichten der jeweiligen Arbeit heraus zu sehen. Daher wird an dieser Stelle im Hinblick auf service-orientierte Architekturen eine eigene Definition von Software-Architekturen gegeben:

Eine Software-Architektur ist eine abstrakte Sicht auf das Gesamtsystem. Sie abstrahiert von Implementierungsdetails und beschreibt die Kommunikation der Softwarekomponenten untereinander. Sie sorgt dafür, dass das System flexibel und leicht erweiterbar ist. Außerdem soll durch die Architektur die Wiederverwendung von Komponenten gefördert werden.

Eine Architektur legt ausgehend von den Anforderungen, aber unabhängig von dem konkreten System, das Fundament eines Projekts fest. Sie bestimmt damit die tragenden Säulen, jedoch nicht die Details für das zu entwickelnde System [Buschmann u.a. 1996]. Aufbauend auf der hier gegebenen Definition wird im nachfolgenden Kapitel die allgemeine Motivation einer Software-Architektur beschrieben. Anschließend wird die service-orientierte Architektur als eine konkrete Ausprägung einer Software-Architektur detailliert vorgestellt.

2.3 Ziele einer Software-Architektur

Genauso vielfältig wie die in der Literatur angegebenen Definitionen zum Begriff SoftwareArchitektur sind auch die beschriebenen Ziele, die diese bringen soll. Der Nutzen einer Software-Architektur kann aus verschiedenen Blickwinkeln betrachtet werden. Diese sind dabei aber immer abhängig von den jeweiligen Rahmenbedingungen eines Projekts. Mit der Blickrichtung auf service-orientierte Architekturen werden an dieser Stelle folgende Ziele definiert, die eine Software-Architektur (also auch SOA) leisten muss und die im Folgenden erläutert werden (vgl. [Posch u.a. 2004]):

- eine effiziente Grundlage für das Entwicklungsprojekt bieten
- den aus den Anforderungen ermittelten Workflow spezifizieren
- flexibel auf fachliche und technische Änderungen reagieren können
- die Software muss leicht erweiterbar und einzelne Komponenten austauschbar sein
- ein Verständnis bei allen Beteiligten für das System schaffen

Da eine Software-Architektur das technische Grundgerüst eines jeden Entwicklungsprojekts ist, hängt der Erfolg des Projekts stark von der Qualität der gewählten Software-Architektur ab. Software wird inkrementell entwickelt, man spricht vom so genannten iterativ inkrementellen Entwicklungsprozess. Ohne diesen ist es nicht möglich, Software wirtschaftlich zu entwickeln. Die Architektur stellt den notwendigen Integrationsrahmen dar, in dem iterativ entwickelt werden kann (vgl. [Kruchten 2000]). Gäbe es keine grundlegende Architektur in Software-Projekten, müsste bei jeder neuen Änderung das Gesamtkonzept angepasst werden. Solche Änderungen sind nicht wirtschaftlich und ab einer bestimmten Projektgröße auch nicht mehr möglich. Damit dient die gewählte Software-Architektur als effiziente Grundlage für das Entwicklungsprojekt. Ein weiterer Punkt, in dem eine gute Software-Architektur die Effizienz eines Entwicklungsprojekts steigert, liegt in der Zusammenarbeit mit dem Projektmanagement. Ein Teamleiter kann anhand der Architektur das System aufteilen, Meilensteine festlegen und Arbeitspakete verteilen. In Zusammenarbeit mit dem Software-Architekten kann er anhand der Architektur einen für ihn ausreichenden Blick über das Gesamtsystem erhalten. So können Projektpläne aufgestellt und das Softwareprojekt gesteuert werden. Ohne eine effiziente Software-Architektur wäre dies ebenfalls nicht möglich [Posch u.a. 2004]. Das zweite definierte Ziel ist die geforderte Flexibilität auf fachliche und technische Änderungen. Flexibilität ist auf fachlicher Basis noch wichtiger als auf der technischen Seite. Oft stehen zu Beginn eines Software-Projekts noch nicht alle Anforderungen fest oder der Kunde ändert seine Anforderungen im laufenden Projekt. Eine stabile Software- Architektur dient dazu, auf diese Änderungswünsche flexibel zu reagieren, ohne jedes Mal das Gesamtkonzept anpassen zu müssen. Ähnliches gilt für den dritten Punkt, die Erweiterbarkeit von Software. Zum einen betrifft dies das Hinzufügen von neuen Funktionalitäten, zum anderen muss man in der Lage sein, die Software auch auf mehrere Rechner zu verteilen oder einzelne Komponenten auszutauschen, was durch die Schaffung oder Nutzung von standardisierten Schnittstellen erreicht werden kann. Eine Software-Architektur muss gewährleisten, dass bei Bedarf Komponenten der Software beliebig verteilt werden können, ohne konzeptionelle Änderungen vorzunehmen. Der letzte Punkt der hier aufgelisteten Ziele betrifft das Verständnis aller Beteiligten in einem Software-Projekt. Eine Architektur, die dem gesamten Projekt zugrunde liegt, definiert bestimmte Schnittstellen und sorgt für die Zuordnung fachspezifischer Termini. Dieses Verständnis ist vor allem bei großen Projekten wichtig und dient den vielen verschiedenen Projektbeteiligten als gemeinsame Kommunikationsbasis.

2.4 Grundlagen service-orientierter Architekturen

2.4.1 Einführung

Eingangs wurde bereits erwähnt, dass man sich mit den sprachlichen Bausteinen „Service-orientierung“ und „Architektur“ beschäftigen muss, um das Konzept SOA zu verstehen (vgl. 2.1). Der Begriff der Architektur im Zusammenhang mit Software ist im vorangegangenen Kapitel bereits definiert und erläutert worden.

Services sind in service-orientierten Architekturen die beschriebenen Komponenten, die miteinander kommunizieren. Ein Service beschreibt eine wohl definierte, in sich abgeschlossene fachliche Funktion. Er verfügtüber eine klar definierte Schnittstelle. Diese Schnittstelle legt fest, wie der Service aufgerufen werden kann, welche Parameter zuübergeben sind und wie das Resultat aussieht [Richter u.a. 2005].

Der Aufruf eines Services ist standardisiert. Es wird exakt festgelegt wie und mit welchem Parameter ein Service aufgerufen werden kann. Der Service wird von einem Anbieter bereitgestellt und kann dann von einem Nutzer verwendet werden. Dabei muss weder der Servicenutzer den Anbieter kennen, noch umgekehrt. Beide Parteien können völlig unabhängig voneinander agieren. Durch die Definition ist jeder Service exakt spezifiziert.

Ein Servicenutzer erkennt anhand der Servicedefinition, welche Parameter übergeben werden müssen und welche Form das zurückgelieferte Ergebnis des Services hat. Somit definiert sich die gesamte Architektur durch das Zusammenspiel dieser Services. Die Betonung der Architektur liegt dabei auf einer losen Kopplung. Es ist möglich, die Architektur um weitere Services zu ergänzen, oder einen existierenden Service auszutauschen. Der Service selbst verbirgt seine eigenen Implementierungsdetails gegenüber seiner Umgebung. Dadurch können Services, die eine identische Schnittstelle bieten, ausgetauscht werden ohne dass der Nutzer diese Veränderung bemerkt. Dieses Prinzip macht die Flexibilität und damit einen der wesentlichen Vorteile SOA aus (vgl. Kapitel 2.3 Ziele einer Software-Architektur). Ein Nutzer ist nicht an einen bestimmten Dienst gebunden, wenn er einen Service in Anspruch nehmen möchte. Er stellt eine Anfrage über den benötigten Dienst. Das Ergebnis dieser Anfrage liefert einen Dienstanbieter. Die Suche bezieht sich dabei auf den eigentlichen Service, nicht auf den konkreten Anbieter, der diesen Dienst implementiert. Innerhalb service-orientierter Architekturen gibt es ein zentrales Verzeichnis, welches die Kommunikation zwischen den Services koordiniert. Sobald man die Architektur um einen Service erweitert, wird dieser in dem zentralen Verzeichnis registriert. Bei dieser Registrierung wird neben den definierten Schnittstellenbeschreibungen auch der Funktionsumfang des Services gespeichert. Wird ein bestimmter Dienst benötigt, stellt der Benutzer eine Anfrage an den Verzeichnisdienst. Abbildung 1 verdeutlicht dieses Prinzip:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Funktionsweise service-orientierter Architekturen [Dostal u.a. 2005]

Der in dieser Abbildung gezeigte Service Contract ist ein Vertrag zwischen dem Konsumenten und dem Anbieter des Services. Grundlage dieses Vertrages ist die angegebene Schnittstellenbeschreibung des Dienstes [Dostal u.a. 2005]. Darüber hinaus können auch funktionsunabhängige Eigenschaften wie beispielsweise Verfügbarkeit oder maximale Antwortzeit geregelt werden. Dadurch ermöglicht es dieser Vertrag, Services auch nach außen an externe Partner weiterzugeben. Diese können den angebotenen Service dann auf Basis des zugrunde liegenden Vertrages in Anspruch nehmen. So kann ein Unternehmen, das seine Prozesse auf SOA umstellt, sukzessive eine B2B Anwendungslandschaft mit seinen Geschäftspartnern aufbauen. Vertragliche Grundlage bietet der dabei geschlossene Service Contract der verwendeten Services (vgl. [Dostal u.a. 2005]).

Durch diese Einführung in die grundlegenden Funktionsweisen service-orientierter Architekturen soll vor allem eine Sache deutlich werden: Service-orientierte Architekturen sind ein fachliches Konzept, indem ohne Bezug zu einer konkreten technischen Realisierung Services definiert werden. SOA sind somit technologieunabhängig und betrachten, beispielsweise in einem Unternehmen, die durchgehenden Geschäftsprozesse auf einer höheren Ebene (vgl. [Richter u.a. 2005]). Dabei nutzen SOA ebenfalls Aspekte anderer Architekturen, wie beispielsweise das Prinzip der losen Kopplung, oder das Information-Hiding-Prinzip (vgl. [Dostal u.a. 2005]). Diese werden allerdings nicht auf technischer, sondern auf fachlicher Ebene verwendet. Service- orientierte Architekturen sind ein Konzept, dass von der konkreten Implementierung und Anwendungslandschaft des Unternehmens abstrahiert, um die Geschäftsprozesse ganzheitlich zu betrachten. Sobald diese Prozesse umfassend als Service definiert worden sind, können service-orientierte Architekturen eingeführt werden. In diesem Zusammenhang spielen Web Services und Enterprise Application Integration (EAI) eine Rolle. Diese Begriffe werden im nachfolgenden Kapitel definiert und von SOA abgegrenzt.

2.4.2 Begriffsabgrenzung

Enterprise Application Integration (EAI)

Geschäftsanwendungen und deren Abbildungen in IT-Systemen sind im Laufe der Zeit immer komplexer geworden. In einem Unternehmen entstehen immer mehr Lösungen für die Abwicklung von spezifischen Geschäftsprozessen. Dies hat eine Vielzahl von IT- Systemen zur Folge. Die Problematik in den Unternehmen besteht darin, diese Vielzahl von Systemen zu verbinden, um Daten und Prozesse integrieren zu können (vgl. [Kaib 2002]. EAI ist seit Beginn der 90er Jahre das gebräuchliche Konzept für Daten- und Prozessintegration [Kaib 2002]. Dabei dient ein einheitlicher Business Bus als Integrationsplattform. Das entscheidende Prinzip beim EAI-Ansatz ist die Tatsache, dass die bestehenden Schnittstellen nicht verändert werden. Um diese dennoch integrieren zu können, werden Adapter entwickelt, die das System mit dem Business Bus verbinden. Abbildung 2 zeigt eine schematische Darstellung des Konzeptes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Schematische Darstellung des EAI-Konzepts [Kaib 2002]

Service-orientierte Architekturen Seite 10 Die meisten EAI-Produkte liefern bereits vorgefertigte Adapater für gängige Standardsoftware an. Dadurch wird der Integrationsaufwand erheblich gesenkt [Großmann, Koschek 2005]. Des Weiteren bieten solche Produkte einheitliche Schnittstellen und eine integrierte Middleware an. Die Middleware ist in diesem Zusammenhang für den Transport komplexer Daten zwischen den Anwendungen zuständig. Zudem ermöglicht die Middleware entfernte Funktionsaufrufe zwischen den Komponenten (sogenannte Remote Procedure Calls (RPCs) [Großmann, Koschek 2005]). Das Konzept der EAI und die damit verbundenen Produkte der Hersteller unterstützen ein Unternehmen, die vorhandenen Systeme auf einer gemeinsamen technischen Ebene zu integrieren. Trotz des gemeinsamen Ziels der Integration, das sowohl der SOA- als auch der EAI-Ansatz verfolgen, sind beide Konzepte voneinander abzugrenzen. Der Unterschied liegt im Ansatz der Integration. Während das EAI-Konzept eine komplette technische Betrachtung der Unternehmensintegration ist, betrachten SOA die Integration auf Prozessebene. Dadurch wird die Thematik bei SOA auf einer höheren Ebene betrachtet. EAI kann einer SOA als Integrationsgrundlage dienen (vgl. [Richter u.a. 2005]).

Web Services

Web Services werden oft fälschlicherweise mit SOA gleichgesetzt. Service-orientierte Architekturen beschreiben ein technologieneutrales Konzept für Software-Architekturen (vgl. Kapitel 2.4.1). Web Services beschreiben eine konkrete Implementierung, um service-orientierte Architekturen umzusetzen. In der Praxis werden allerdings meistens Web Services verwendet, um SOA zu implementieren [Hauser, Löwer 2004].

Web Services basieren auf Standards, die es ermöglichen, Services anzubieten und zu nutzen. Der Unterschied zum klassischen Client/Server Prinzip liegt darin, dass nun keine „Mensch-zu-Maschine“ Kommunikation mehr vorliegt. Bei der Implementierung von Web Services und damit der Umsetzung SOA geht es um die reine „Maschine-zu-Maschine“ Kommunikation [Hauser, Löwer 2004]. Mit Maschine sind damit Anwendungen gemeint, die Daten untereinander austauschen. Dieses Prinzip ist nicht neu, das Austauschen von Daten zwischen Anwendungen kann auch ohne Web Services realisiert werden. Dafür gibt es Middleware wie beispielsweise CORBA oder DCOM. Allerdings sind der Umgang mit diesen Techniken und der Einsatz bei verteilten Systemen relativ komplex und aufwändig [Heinzl und Mathes 2005]. Zudem ergeben sich aufgrund der Sicherheitseinstellungen der einzelnen Systeme häufig Probleme bei der Kommunikation zwischen den Anwendungen [Posch u.a. 2004]. Web Services bieten auf diesem Bereich einen entscheidenden Vorteil gegenüber der zuvor verwendeten Middleware, da sie auf dem Hypertext Transfer Protocol (http) basieren [Hauser, Löwer 2004]. Die Kommunikation ist somit für Intranet- und Extranet-Umgebungen geeignet, da Firewalls kein Problem mehr bei der Unternehmenskommunikation darstellen. Es ist mit Web Services möglich, umfangreiche B2B-Applikationen über Unternehmensgrenzen hinweg zu realisieren. Web Services sind dabei keine einheitliche Technologie, sondern basieren auf verschiedenen Standards und Definitionen. Diese Standards adressieren verschiedene Bereiche, wie beispielsweise die Übermittlung, die Beschreibung von Services, oder den Verzeichnisdienst (vgl. [WC3 2006_d]). Eine detailliertere Betrachtung der einzelnen Komponenten von Web Services findet sich in Kapitel 2.5 „Die Implementierung service-orientierter Architekturen“. Dort wird exemplarisch gezeigt, wie SOA auf Basis von Web Services implementiert werden können. Die einzelnen Bestandteile eines Web Services werden vorgestellt und dem Prinzip service-orientierter Architekturen zugeordnet.

Enterprise Service Architecture (ESA)

Im Zusammenhang mit service-orientierten Architekturen stößt man häufig auf den Begriff der Enterprise Service Architecture, kurz ESA genannt. Bevor weitere Detailkonzepte service-orientierter Architekturen erläutert werden, soll auch dieser Begriff zunächst von SOA abgegrenzt werden.

ESA bezeichnet die Interpretation der SAP AG service-orientierter Architekturen. In dem fachlichen Konzept gibt es dabei keinen Unterschied zwischen ESA und SOA [Richter u.a. 2005]. Mit dem Produkt Netweaver hat die SAP AG eine Integrationsplattform entwickelt, die Unternehmen einsetzen können, um Ihre Daten und Prozesse zu integrieren. Diesen Vorgang bezeichnet die SAP AG als Enterprise Service Architecture (vgl. [SAP 2006_a]). Dabei wird eine eigene Strategie verfolgt, um Kunden an das Unternehmen zu binden. Als Werkzeug gibt es neben der Integrationsplattform Netweaver den Composite Application Framework. Mit diesem Framework können Kunden Anwendungen kombinieren und Services im dem beschriebenen Sinne service-orientierter Architekturen bereitstellen [Goebel, Ritthaler 2004]. Im nachfolgenden Kapitel werden aufbauend auf dem in Kapitel 2.4.1 vermittelten Grundverständnis und dieser Begriffsabgrenzung weiterführende Konzepte SOA analysiert. Eine detailliertere Betrachtung der SAP Strategie zum Thema service-orientierte Architekturen befindet sich im Kapitel 4.1 „Einführung und Überblick in die SOA-Strategie der SAP AG“.

2.4.3 Der Anspruch an SOA - Definition und Ziele

Nachdem die Grundprinzipien service-orientierter Architekturen analysiert wurden und SOA von verwandten Themenkomplexen abgegrenzt worden sind, greift dieses Kapitel noch einmal die allgemeine Definition von Architektur aus dem Kapitel 2.2 und die Ziele einer Software-Architektur aus dem Kapitel 2.3 auf. Es soll gezeigt werden, dass serviceorientierte Architekturen der angegebenen Definition entsprechen und die allgemein formulierten Ziele einer Software Architektur erfüllen können.

SOA bieten durch die gezeigten Services eine abstrakte Sicht auf das Gesamtsystem. Wird eine service-orientierte Architektur skizziert, besteht diese aus den angebotenen Services, dem Verzeichnisdienst und den Nutzern. Die Kommunikation wird durch die Verbindung zwischen Servicenutzer und Anbieter verdeutlicht. Die technische Umsetzung hängt dabei von der Art der Implementierung SOA ab. Ein Service selbst verbirgt dabei seine Implementierungsdetails. Für einen Nutzer ist das Resultat einer Anfrage entscheidend, nicht der Weg, wie der Service zu diesem Resultat kommt. Dadurch bietet dieses System eine flexible Möglichkeit, B2B Applikationen aufzubauen. Viele Unternehmen möchten ihre Geschäftsprozesse gegenüber Partnern und Lieferanten nicht offen legen. In einer gemeinsamen Geschäftsanwendung, die auf einer service- orientierten Architektur basiert, können sie die Funktionen als Service definieren. Dieser kann dann durch wohldefinierte Schnittstellen von Partnern und Lieferanten genutzt werden, ohne dass das Unternehmen seine Geschäftsprozesse offen legen muss. Dieses Prinzip ist in der Informatik nicht neu und wird als „Information-Hiding-Prinzip“ bezeichnet (vgl. Kapitel 2.4.1). Weitere Aspekte der Definition beschreiben die leichte Erweiterbarkeit und die Wiederverwendung von Software. Auch diese Anforderung wird durch den SOA- Ansatz erfüllt. Eine Software kann leicht durch das Hinzufügen von Services erweitert werden (vgl. [Dostal u.a. 2005]). Ein konkretes Beispiel ist die Erweiterung SOA um eine Anwendung. Die Aufgabe besteht darin, die Funktionalität, die diese Anwendung bietet, in einen Service umzuwandeln. (In diesem Vorgehen wird auch der unterschiedliche Ansatz der Integration zwischen SOA und EAI deutlich, vgl. Kapitel 2.4.2 Begriffsabgrenzung EAI). Ist die Anwendung als Service definiert worden, muss sie dem Verzeichnisdienst als neuer Service bekannt gemacht werden. Auf diese Weise lassen sich SOA sukzessive um ausgewählte Funktionalitäten erweitern. Die Wiederverwendung wird durch dieses Prinzip ebenfalls gefördert, da ein vorhandener Service nicht neu entwickelt werden muss, sondern dann von jedem Servicenutzer verwendet werden kann.

Somit werden auch die in Kapitel 2.3 verfolgten Ziele einer Architektur erreicht. Das System ist flexibel genug, um Services einfach ergänzen zu können, oder einzelne Services auszutauschen. Ferner wird durch die Definition aller Dienste als Service und einer exakten Beschreibung der angebotenen Dienste eine gemeinsame Kommunikationsgrundlage für alle Beteiligten gelegt.

Das Grundverständnis service-orientierter Architekturen ist damit beschrieben. Einfache Strukturen basieren exakt auf diesem Prinzip und können mit einem einheitlichen Kommunikationsprotokoll, einer Beschreibung der Services und einem Verzeichnisdienst auch genauso umgesetzt werden. Allerdings reichen diese einfachen Grundlagen für die Praxis meinst nicht aus, da die Zusammenhänge zwischen den Systemen und Prozessen sehr komplex sind. Zentrale Fragestellungen betreffen die Umsetzung von sicheren Transaktionen innerhalb SOA und der Umsetzung von Geschäftsprozessen. Das nächste Kapitel betrachtet aufbauend auf dem vermittelten Wissen die Implementierung service- orientierter Architekturen.

2.5 Die Implementierung service-orientierter Architekturen

Nachdem die Komponenten, Vorteile und theoretischen Aspekte service-orientierter Architekturen vorgestellt worden sind, widmet sich dieses Kapitel der Umsetzung. Es gibt generell verschiedene Möglichkeiten diese zu realisieren. Vorweg sei aber bemerkt, dass sich in der Praxis die Umsetzung service-orientierter Architekturen auf Basis von Web Services durchgesetzt haben [Newcomer, Lomow 2004]. Technisch gesehen ist es allerdings möglich, service-orientierte Architekturen auch anders umzusetzen, beispielsweise auf Basis von CORBA. CORBA wird oftmals als erste Umsetzung service- orientierter Architekturen beschrieben [Hauser und Löwer 2004]. Der Nachteil gegenüber der Verwendung von Web Services liegt allerdings in dem Problem der Überwindung von Unternehmensgrenzen (vgl. Kapitel 2.4.2, Definition von Web Services). Weitere Möglichkeiten liegen in der Verwendung von REST oder der direkten Verwendung von Remoting Objekten. REST steht für REpresentational State Transfer und beschreibt einen Architekturstil, der die Realisierung service-orientierter Architekturen auf Basis von URIs realisiert [Langham 2002]. REST wurde geprägt von Roy Fielding, der diese Idee in seiner Dissertation im Jahre 2000 erstmals veröffentlicht hat. REST steht in Konkurrenz zu SOAP, findet aber in der Praxis durch die weite Verbreitung von SOAP kaum Berücksichtigung [Hauser, Löwer 2004]. Für detailliertere Informationen zu REST sei auf [Fielding 2000] verwiesen. Mit der direkten Verwendung von Remoting Objekten ist der Aufruf von entfernten Methoden eines Objektes gemeint, dass zu einer anderen Anwendung gehört. Remoting-Technologien in diesem Sinne sind beispielsweise .NET Remoting von Microsoft (vgl. [Microsoft 2006]) oder Java RMI von Sun (vgl. [RMI 2006]). Der Vorteil gegenüber Web Services liegt hier in der Geschwindigkeit, da direkt Binärdaten übertragen werden können [Hauser, Löwer 2004]. Allerdings ist man dadurch auch an eine spezifische Plattform gebunden. Eine Verbindung heterogener Plattformen ist mit der direkten Verwendung von Remoting Objekten nicht möglich, weder mit .NET Technologien, noch mit Java RMI. Um heterogene Plattformen zu verbinden bieten sich Web Services an [Einhorn, Olbrich 2004]. Diese Möglichkeit ist ein wesentlicher Grund dafür, dass sich Web Services zum Standard für die Umsetzung service-orientierter Architekturen entwickelt haben [Newcomer, Lomow 2004]. Daher sind die anderen Umsetzungsmöglichkeiten lediglich der Vollständigkeit halber erwähnt und sollen nicht weiter vertieft werden.

Im nachfolgenden Kapitel werden die elementaren Bausteine von Web Services vorgestellt und gezeigt, welche Aufgaben sie bei der Umsetzung service-orientierter Architekturen erfüllen. Web Services sind dabei nicht als eigenständige Technologie zu sehen, sondern basieren auf Standards und Spezifikationen, die im Zusammenspiel miteinander eine eigene Technologie bilden. Um SOA auf Basis von Web Services umzusetzen, müssen drei wesentliche Elemente spezifiziert werden:

1. Die Übertragung

Zwischen dem Service-Nutzer, dem Service-Anbieter und dem Verzeichnisdienst einer SOA (vgl. Abbildung 1) müssen Daten übertragen werden. Durch eine Spezifikation des Web Services wird geregelt, wie diese Daten übertragen werden.

2. Die Beschreibung

Der angebotene Service und seine Methoden müssen exakt beschrieben werden, damit der Service-Nutzer erkennt, was dieser Service ihm bieten kann und wie er zu verwenden ist.

3. Der Verzeichnisdienst

Damit ein Service-Nutzer einen bestimmten Service finden kann, sind alle verfügbaren Services in einem Verzeichnisdienst registriert.

Diese drei Spezifikationen bilden die Basis von Web Services und werden in den folgenden Kapiteln detailliert beschrieben. Darüber hinaus gibt es noch weitere Standards im Web Service Bereich für verschiedene Anwendungsbereiche wie beispielsweise Sicherheit, Transaktions- oder Prozessmanagement (vgl. [Hauser, Löwer 2004]). Diese Standards werden im Rahmen der Diplomarbeit allerdings nicht weiter erläutert.

2.5.1 SOAP

SOAP ist ein Protokoll mit dessen Hilfe Daten zwischen Systemen ausgetauscht werden können und adressiert den ersten Aufzählungspunkt in der vorangegangen Liste der Standards von Web Services. SOAP hat sich gegenüber XML-RPC (XML Remote Procedure Call) als Standardprotokoll für Web Services durchgesetzt. In vielen Publikationen wird es oft schon als Synonym für Web Services verwendet [Hauser, Löwer 2004]. Dies ist zwar nicht korrekt, zeigt aber zugleich die Bedeutung, die SOAP mittlerweile erlangt hat. SOAP stand früher für Simple Object Access Protocol, seit der Version 1.2 ist dieser Name aber mittlerweile kein Akronym mehr, sondern steht für sich [W3C 2006_a].

SOAP spezifiziert wie eine Nachricht für die Übertragung aufgebaut werden muss und garantiert damit, dass die Gegenstelle diese Nachricht verstehen kann. Im Bereich der Web Services wird SOAP verwendet, damit der Service-Anbieter den Service-Aufruf des Nutzers verstehen und dessen übergebene Parameter eindeutig zuordnen kann. Dasselbe Prinzip gilt für die Antwort des Service-Anbieters. Durch die Einhaltung der SOAP-Spezifikation kann der Empfänger die Antwort korrekt auswerten. Dabei liefert das Protokoll zwei wesentliche Dienste. Zum einen können in SOAP Remote Procedure Calls (RPCs) eingebettet werden, die das Aufrufen einer entfernten Methode ermöglichen, zum anderen kann SOAP für die Übermittlung von asynchronen Nachrichten verwendet werden. Letzterer Punkt ist der entscheidende Vorteil von SOAP gegenüber XML-RPC, mit dem lediglich entfernte Funktionsaufrufe realisiert werden können [Hauser, Löwer 2004].

Dabei baut SOAP genau wie XML-RPC auf XML auf. Die einzelnen SOAP-Anweisungen werden in XML-Tags beschrieben und haben denselben hierarchischen Aufbau wie eine normale XML-Datei. Eine SOAP-Nachricht besteht dabei aus drei Teilen: Dem SOAPEnvelope, einem umfassenden Tag, das den SOAP-Header und den SOAP-Body umschließt. Abbildung 3 verdeutlicht diesen Aufbau:

Abbildung 3: Aufbau einer SOAP-Nachricht [Dostal u.a. 2005]

Abbildung in dieser Leseprobe nicht enthalten

Diese SOAP-Nachricht kann dann mit Hilfe eines Übertragungsprotokolls zwischen Service-Anbieter und Service-Nutzer ausgetauscht werden. In der Praxis hat sich dabei HTTP als Standardweg für die Übertragung von SOAP-Nachrichten durchgesetzt [Knuth 2003]. Diese Kombination erklärt die verbreitete Formel SOAP = XML over HTTP, die in der Literatur häufig zu finden ist.

Für detailliertere Informationen zum Aufbau von SOAP-Nachrichten und dem Ablauf der Kommunikation befindet sich im Anhang ein ausführliches Beispiel. Dabei wird ein Web Service vorausgesetzt, der die Gültigkeit einer Kreditkarte anhand der Kartennummer und dem Gültigkeitsdatum prüfen kann. Das Beispiel zeigt sowohl den Aufbau der SOAPNachricht die ein Client sendet, um eine bestimmte Kreditkarte zu prüfen, als auch die SOAP-Nachricht, die der Service als Antwort zurückliefert.

2.5.2 Web Service Description Language (WSDL)

Der zweite wesentliche Baustein von Web Services ist die exakte Beschreibung des angebotenen Services. Für die reine Kommunikation zwischen Service-Nutzer und Service-Anbieter ist ein Protokoll wie SOAP und die Übertragung über http ausreichend. Diese beiden Standards realisieren die eigentliche Kommunikation zwischen Anbieter und Nutzer. Voraussetzung dafür ist allerdings, dass der Service-Nutzer die exakten Methoden(namen) des gewünschten Services kennt, damit diese Aufrufe in der SOAP- Nachricht korrekt verwendet werden können. Wenn man ein Software Projekt auf Basis von Web Services realisiert, kann man jedoch nicht davon ausgehen, dass jeder Service- Nutzer eine komplette Übersicht über alle Methoden der Services besitzt, die er nutzen möchte. Um dieses Problem zu lösen, hat man eine Beschreibungssprache eingeführt, deren Aufgabe es ist, die Funktion und die Methoden eines Web Services zu beschreiben. Im Bereich der Beschreibungssprachen hat sich die Web Service Definition Language (WSDL) durchgesetzt und alle anderen Beschreibungssprachen vom Markt verdrängt [Knuth 2003]. WSDL gilt somit als Standard für die Beschreibung von Web Services und wird im diesem Kapitel kurz vorgestellt.

Ein WSDL-Beschreibungsdokument ist, genauso wie eine SOAP-Nachricht, ein XMLDokument. Innerhalb einer WSDL-Beschreibungsdatei sind definierte Elemente vorgegeben, um den Web Service zu beschreiben. Abbildung 4 gibt einen Überblick über die Standardelemente:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Dokumentenstruktur eines WSDL-Dokuments [Hauser, Löwer 2004]

Gemäss der XML Spezifikation benötigt jede XML-Datei ein Wurzelelement [W3C 2006_b]. Dies ist im Fall von WSDL das Element „ definitions “ (s. Abbildung 4). Dieses Element beinhaltet den Namen des Services und die benötigten Namespaces. Das Element „ types “ beinhaltet die verwendeten Datentypen. Werden keine eigenen Datentypen definiert, können standardmäßig die Datentypen aus der XML-Schema- Spezifikation verwendet werden. Mit dem „ message “-Tag werden die Datenelemente einer Methode des Web Services beschrieben [Dostal u.a. 2005]. Dadurch weiss der Client, welche Datentypen eine bestimmte Methode des Web Services als Eingabeparameter erwartet und welchen Datentyp diese Methode als Rückgabewert liefert. Der „ portType “ eines WSDL-Beschreibungsdokuments beschreibt die konkreten Methoden, die der Web Service zur Verfügung stellt [Dostal u.a. 2005]. Dadurch ist dieser das zentrale Element einer WSDL-Beschreibungsdatei und kann mit den Bibliotheken einer traditionellen Programmiersprache verglichen werden. Das „ binding “-Tag gibt an, mit welchem Protokoll und in welchem Format die in einem portType definierten Methoden abgearbeitet werden. An dieser Stelle wird im Dokument die Beschreibungssprache WSDL mit dem Protokoll SOAP verbunden, daher der Name „binding“ (engl. verbinden). Der letzte elementare Tag ist der „ service “-Tag. In diesem wird der konkrete Endpunkt des Dienstes beschrieben. Für die Angabe des Endpunktes wird in einem untergeordneten Port-Element ein direkter URI (Unified Ressource Identifier) vergeben. Darüber hinaus gibt es noch optionale Elemente wie documentation und import, die aber hier nicht weiter betrachtet werden sollen.

Diese sechs kurz vorgestellten XML-Tags werden in einem WSDL-Dokument benötigt, um einen Web Service einheitlich zu beschreiben (vgl. [Dostal u.a. 2005]). Jedem Service- Nutzer, der in der Lage ist, diese Datei zu lesen, ist es somit möglich, den angebotenen Web Service (automatisch) zu nutzen. Für die Erstellung einer solchen Beschreibungsdatei gibt es bereits eine Vielzahl an WSDL-Generatoren, die aufbauend auf einem Web Service und den benötigten Meta-Daten eine WSDL-Datei nach dem aktuellen WSDL-Standard generieren können (aktuell ist die WSDL-Version 2.0, siehe [W3C 2006_c]). Für detailliertere Informationen zu dem Aufbau einer WSDL- Beschreibungsdatei mit den in diesem Kapitel vorgestellten Tags, befindet sich im Anhang dieser Diplomarbeit ein konkretes Beispiel.

2.5.3 Universal Description, Discovery and Integration (UDDI)

Der dritte und letzte Baustein im Bereich von Web Services ist der Verzeichnisdienst. Ein Verzeichnisdienst unterstützt den Service-Nutzer bei der Suche nach einem geeigneten Service (s. Abbildung 1). Dabei gibt es in service-orientierten Architekturen einen zentralen Verzeichnisdienst, in dem alle zur Verfügung stehenden Web Services gelistet sind. Der Verzeichnisdienst kann mit den gelben Seiten im alltäglichen Leben verglichen werden. Benötigt ein Nutzer einen bestimmten Dienst, stellt er eine Anfrage an den Verzeichnisdienst. Dieser liefert ihm entsprechend seiner Suchanfrage den passenden Service. Wird die Anwendung um einen weiteren Service ergänzt, wird dieser Service dem Verzeichnisdienst hinzugefügt. Dadurch kann jeder Service-Nutzer dieser Architektur den neu hinzugekommenen Service direkt verwenden.

Durchgesetzt im Bereich der Verzeichnisdienste hat sich UDDI [Hauser, Löwer 2004]. Diese Abkürzung steht für Universal Description, Discovery and Integration. Entstanden ist UDDI aus dem so genannten UDDI-Projekt, dass am 6.September 2000 gegründet wurde [Hauser und Löwer 2004]. Bei der Entwicklung dieses Verzeichnisdienstes haben, wie auch schon bei WSDL, unter anderem Firmen wie IBM oder Microsoft mitgearbeitet. Bei diesen Firmen war es bis vor kurzem noch möglich, einen öffentlichen UDDI Verzeichnisdienst zu nutzen. Unter den Adressen http://uddi.sap.com, http://uddi.ibm.com, oder http://uddi.microsoft.com konnte man seinen eigenen Web Service per WSDL-Datei veröffentlichen oder per Stichwortsuche nach bereits veröffentlichten Web Services suchen, um diese dann in Anspruch zu nehmen. Dieser öffentliche Service ist nach einer Betriebszeit von fünf Jahren von allen großen Firmen am 12. Januar 2006 eingestellt worden. [IBM 2006].

Auch wenn dieser Dienst über die Web Interfaces dieser Firmen einen praktischen Einblick in den Arbeitsablauf mit UDDI gegeben hat, geht diese Demonstration an dem grundlegenden Prinzip der Web Services vorbei. Web Services basieren auf „Maschine- zu-Maschine“ Kommunikation (s. Kapitel 2.4.2 Begriffsabgrenzung Web Service) und das elementare Ziel eines UDDI Servers ist die automatische Verbindung zwischen Service Nutzer und Service Anbieter, ohne dass ein manueller Eingriff erfolgen muss [Hauser, Löwer 2004]. Die einzige wirklich benötigte Säule der drei Web Service Säulen ist SOAP, weil dieses Protokoll für die Kommunikation zwingend notwendig ist. Wenn die Methoden bekannt sind, ist eine Beschreibungssprache wie WSDL überflüssig (s. vorangegangenes Kapitel 2.5.2) und wenn die Services bekannt sind, ist auch kein Verzeichnisdienst notwendig. Zudem können Web Services auch über einfache Web Verzeichnisse gelistet werden, wie beispielsweise http://www.xmethods.com/ (vgl. [Dostal u.a. 2005]).

Allerdings ist es das Ziel in dem Konzept der service-orientierten Architekturen, dass Services automatisch von anderen Services aufgerufen werden können. Daher sind standardisierte Schnittstellen in Form von Beschreibungssprachen der Services (WSDL) und Verzeichnisdiensten (UDDI) nötig. Damit ein Verzeichnisdienst automatisch einen Service-Aufruf verarbeiten kann, um diesem Aufruf den passenden Service zu vermitteln, gibt es eine einheitliche Schnittstellen Spezifikation (API). Diese API wurde am 19.Juli 2002 von dem Oasis Gremium in der Version 2.04 spezifiziert [UDDI 2006]. Für weitere Informationen zu den Details sei auf die Spezifikation selbst verwiesen [UDDI 2006].

Mit Hilfe dieser Spezifikation ist es möglich, den Web Service Ansatz umzusetzen und Maschinen ohne menschliches Einwirken miteinander kommunizieren zu lassen. Trotz dieser guten Möglichkeit der Automatisierung, sind Verzeichnisdienste in der Praxis nicht so häufig im Einsatz wie beispielsweise SOAP oder WSDL (vgl. [Dostal u.a. 2005]). Ein möglicher Grund liegt darin, dass die Umsetzung service-orientierter Architekturen in Unternehmen sich immer noch in einem sehr frühen Anfangsstadium befindet. Viele Unternehmen haben sich mit diesem Thema noch gar nicht beschäftigt. Diejenigen Firmen, die schon an einer service-orientierten Architektur arbeiten, beginnen damit, ihre bestehenden Anwendungen in Services umzubauen. Diese Services können zu Beginn der Einführung SOA immer noch manuell aufgerufen werden. Die Stärke eines Verzeichnisdienstes kommt allerdings erst bei der automatischen Kommunikation zwischen Maschinen zur Geltung.

Daher wird UDDI in Zukunft an Bedeutung gewinnen, zunehmend mit dem Prinzip der Semantic Web Services. Diese haben das Ziel, dass Maschinen nicht nur Daten untereinander austauschen können, sondern zudem noch in der Lage sind, diese Daten automatisch auswerten zu können [Hauser, Löwer 2004]. Einen etwas ausführlicheren Einblick in dieses Thema wird im Kapitel 5 „Fazit und Ausblick“ gegeben.

2.6 Weiterführende Aspekte service-orientierter Architekturen

Nach den Grundlagenbetrachtungen service-orientierter Architekturen und der Darstellung einer konkreten Implementierung am Beispiel von Web Services, geht dieses Kapitel auf die Einführung SOA in einem Unternehmen ein. Die ersten beiden Unterkapitel analysieren zwei zentrale Probleme bei der Einführung service-orientierter Architekturen: Die Vorgehensweise bei der Einführung (Kapitel 2.6.1) und die fachliche Aufteilung der einzelnen Services (Kapitel 2.6.2). Das abschließende Unterkapitel 2.6.3 zeigt dann konkret, wie man mit Hilfe einer Prozessbeschreibungssprache Geschäftsprozesse in service-orientierten Architekturen umsetzen kann.

2.6.1 Top-Down Ansatz

Die Einführung service-orientierter Architekturen ist immer eine strategische Entscheidung (vgl. [Richter u.a. 2005]). Wie bereits in den vorangegangen Kapiteln verdeutlicht, handelt es sich bei service-orientierten Architekturen nicht um ein technisches, sondern um ein fachliches Konzept. Der entscheidende Vorteil SOA liegt in der Umsetzung der Geschäftsprozesse als Services. Diese Services sind in der Architektur lose gekoppelt (vgl. Kapitel 2.4.1). Wenn dieses Prinzip konsequent umgesetzt worden ist, kann ein Unternehmen durch die Flexibilität der lose gekoppelten Services sehr schnell seine Geschäftsprozesse anpassen, um so auf Änderungen im Markt zu reagieren [Richter u.a. 2005]. In diesem Prinzip liegt die entscheidende Stärke service-orientierter Architekturen. Unternehmen, die eine service-orientierte Architektur einführen, wollen diese Flexibilität nutzen, um so einen Wettbewerbsvorteil zu erlangen. Das hat zur Folge, dass service- orientierte Architekturen, um sie effizient in einem Unternehmen einführen zu können, mit einem Top-Down Ansatz eingeführt werden müssen. Dies bedeutet, dass hierfür zunächst auf fachlicher Ebene alle relevanten Geschäftsprozesse im Unternehmen definiert werden müssen. In einem zweiten Schritt werden diese Geschäftsprozesse in Services umgewandelt. Es muss gewährleistet sein, dass ein Geschäftsprozess durch eine Verbindung (Komposition) von fachlichen Services durchgehend abgebildet werden kann. Erst nach dieser ausführlichen fachlichen Analyse- und Designphase wird die technische Realisierung im Rahmen einer SOA-Umsetzung vorgenommen.

Dieser beschriebene Top-Down Ansatz, von der fachlichen Analyse bis zur technischen Realisierung der Services, ist entscheidend für den Erfolg service-orientierter Architekturen. Wird dieses Prinzip nicht verstanden, können die Vorteile service- orientierter Architekturen nicht genutzt werden und die Einführung der Architektur würde keinen langfristigen Nutzen, sondern vorrangig Kosten verursachen (vgl. [Richter u.a. 2005]). Oftmals wird die Einführung fälschlicherweise auf Softwareebene begonnen und nicht nach dem beschriebenen Top-Down Ansatz auf der fachlichen Ebene. Dies bestätigt eine Aussage von Robert Winter, Professor am Institut für Wirtschaftsinformatik der Universität St. Gallen: „[…] Ein solches Vorgehen (gemeint ist der beschriebene Top- Down Ansatz) findet sich lediglich in fünf Prozent aller F Älle “ [Ostler 2006]. Dies liegt mitunter darin begründet, dass der Begriff des „Services“ auf der Ebene der Softwareentwicklung besser verstanden wird. Auf dieser Ebene kann ein Service als Design Prinzip verstanden werden. Er kapselt die Implementierungsdetails und ist durch definierte Schnittstellen von außen aufrufbar. Dadurch wird die Einführung SOA oft auf Softwareebene begonnen und nicht mit dem beschriebenen Ansatz auf fachlicher Ebene. Dies zeigt, dass auf diesem Gebiet noch viel Lernbedarf für die Einführung service- orientierter Architekturen besteht. Dieser Abschnitt soll lediglich auf die Problematik der Einführung hinweisen und verdeutlichen, dass der beschriebene Ansatz eines der wesentlichen Kriterien für den Erfolg service-orientierter Architekturen ist.

2.6.2 Granularität

Im Kontext service-orientierter Architekturen ist ein Service somit zunächst auf fachlicher Ebene zu sehen, er ist Teil eines Geschäftsprozesses. Durch die Verbindung (Komposition) mehrerer Services können Geschäftsprozesse abgebildet werden. Das Problem liegt dabei in der Definition des einzelnen Services. Ein Service muss innerhalb eines Geschäftsprozesses fachlich exakt definiert und abgegrenzt werden. Dafür muss man festlegen, wie detailliert ein Geschäftsprozess in einzelne Services zerlegt werden soll. Man spricht dabei von der Granularit Ät eines Services. Betrachtet man diese Thematik auf der B2C-Ebene, ist die Vorstellung von einem Service recht einfach. Ein bekanntes Beispiel ist das Unternehmen Google, welches seine Suchdienste über einen Web Service kostenlos zur Verfügung stellt (vgl. [Google 2006]). Weitere Beispiele für Services in diesem Zusammenhang sind Dienste zur Wetterauskunft, Übersetzungs- oder Straßenkartendienste. Auf dieser Ebene geht es bei einem Service immer um eine einheitliche Anwendung, die dem Nutzer zur Verfügung gestellt wird. Möchte ein Unternehmen allerdings seine Geschäftsprozesse auf eine service-orientierte Architektur umstellen, ist die Wahl der Granularität eines Services ein entscheidender Faktor für den Erfolg dieser service-orientierten Architektur. Ein Service ist in diesem Fall nicht mehr eindeutig als gesamte Anwendung definiert, sondern als Teil eines Geschäftsprozesses. Wenn Geschäftsprozesse im Rahmen der Einführung einer service-orientierten Architektur in Services zerlegt werden, könnten beispielsweise die Aktionen „Kundendaten anzeigen“ oder „Auftrag anlegen“ als eigenständiger Service definiert werden. Der Vorteil bei einer feingranularen Wahl der Services liegt in der hohen Wiederverwendung. Wenn ein Unternehmen seine Geschäftsprozesse in sehr kleine Services zerlegt, dann kann jeder Service in einem anderen Kontext jederzeit wieder verwendet werden. Beispielsweise könnte der oben genannte Service „Auftrag anlegen“ sowohl im Geschäftsprozess „Kundengespräche“, als auch im Geschäftsprozess „Call Center Bestellungen“ verwendet werden. Diese Wiederverwendung fördert eines der Grundprinzipien der Architektur und hat zur Folge, dass im gesamten Unternehmen keine Funktion doppelt implementiert werden muss. Der Nachteil dieser sehr detaillierten Zerlegung in sehr viele Services liegt neben dem sehr hohen Einführungsaufwand in einem unnötig hohen Datenaufkommen. Werden service-orientierte Architekturen beispielsweise mit Web Services realisiert, wird der Serviceaufruf in einem SOAP Protokoll über HTTP übertragen. Beide Protokolle, sowohl SOAP als auch HTTP, beinhaltet jeweils einen eigenen Header (vgl. Kapitel 2.5.1). Dieser wird sowohl beim Service-Aufruf, als auch bei der Antwort des Service-Anbieters neben den eigentlichen Nutzdaten übertragen. Hinzu kommt die Tatsache, dass bei sehr feingranular gewählten Services für fast jede benötigte Aktion der aufgerufene Service den Aufruf interpretieren, verarbeiten und das Ergebnis zurückschicken muss. Bei diesem Vorgang müssen bei jedem Serviceaufruf die Daten aus dem XML-Format für die Anwendung konvertiert und die Ergebnisse wieder zurück in das XML-Format geschrieben werden. Dieser Vorgang der Datentransformation (Parsen) erfordert viel Rechenleistung [Ullenboom 2006]. Wird daher die Zerlegung der Services zu detailliert gewählt, kann keine performante Abarbeitung der Geschäftsprozesse gewährleistet werden. Wählt man die Services allerdings unnötig groß, so dass diese schon annähernd einer kompletten Anwendung entsprechen, erhält man keinen wesentlichen Vorteil durch die Einführung serviceorientierter Architekturen.

Abschließend kann zu der Problematik der Granularität keine definitive Lösung gegeben werden. Eine Universallösung für dieses Problem existiert nicht. Es muss für jedes einzelne Projekt auf Basis der Geschäftsprozesse eine individuelle Lösung gefunden werden. Die fachliche Zerlegung in geeignete Services ist eine bedeutende Aufgabe bei der Einführung service-orientierter Architekturen.

2.6.3 Umsetzung von Geschäftsprozessen in SOA

Sobald unter Berücksichtigung des Granularitätsaspekts eine Umsetzung der Geschäftsprozesse in geeignete Services erfolgt ist, gilt es, diese fachlichen Services zu realisieren. Wird die service-orientierte Architektur auf Basis von Web Services umgesetzt, besteht die Aufgabe darin, jeden fachlichen Service in einem Web Service zu realisieren. Jeder Geschäftsprozess muss am Ende aus der Komposition von neuen und alten Services dargestellt werden können (vgl. [Dostal u.a. 2005]). Um dieses Vorgehen zu realisieren, haben viele IT-Unternehmen im Hinblick auf die Umsetzung service- orientierter Architekturen geschäftsprozessbeschreibende Sprachen entwickelt. Durch diese parallele Entwicklung ist eine Vielzahl an Prozessbeschreibungssprachen in den diversen Unternehmen entstanden. Einige Beispiele hierfür sind u.a. XL, XPDL, BPEL, XLANG, WSFL, WSCI, WSCDL, BPML, ebXML oder RosettaNet. Diese Aufzählung gibt einen ersten Eindruck über die vielfältige Entwicklung der Sprachen im Bereich der Geschäftsprozessmodellierung. Die Aufgabe besteht nun nicht darin möglichst vieler dieser Prozesssprachen detailliert zu beschreiben. Dafür sei auf die Quellen [Hauser, Löwer 2004] und [Hofmann 2005] verwiesen. Im Folgenden werden die einzelnen Sprachen ausschließlich im Hinblick auf ihre zukünftige Bedeutung analysiert. Dafür werden Erfolgsfaktoren benannt, die für die Durchsetzung einer Geschäftsprozesssprache als Standard ausschlaggebend sein können, denn langfristig wird sich eine Sprache als Standard etablieren müssen. Es ist nicht möglich, dass eine solche Vielzahl an Sprachen langfristig parallel existieren wird, denn damit müssten alle Softwarehersteller von Tools zur Unterstützung von Geschäftsprozessmodellierung eine unnötige Vielzahl an Sprachen unterstützen (vgl. [Dostal u.a. 2005]).

Um Struktur in die Analyse der Geschäftsprozesssprachen zu bekommen, können diese in zwei Kategorien unterteilt werden: Orchestrationssprachen für Web Services und Choreographiesprachen für Web Services (vgl. [Hofmann 2005]). Dabei dient diese Unterteilung lediglich als ein Anhaltspunkt, denn es gibt auch Sprachen, die sowohl für die Orchestrierung, als auch für die Choreographie von Web Services verwendet werden können. Mit der Orchestrierung von Web Services bezeichnet man die Komposition von einfachen Services zu einem größeren und komplexeren Service. Dabei wird im Rahmen der Orchestrierung festgelegt, wann und zu welchen Bedingungen ein bestimmter Web Service aufgerufen wird. Um diesen Ablauf zu realisieren, gibt es eine kontrollierende Instanz, die die Aktivitäten überwacht, die zur Zielerreichung notwendig sind [Peltz 2003]. Daher ist die Idee der Web Service Orchestration mit dem Workflow Management vergleichbar (vgl. [Hofmann 2005]).

Die Choreographie von Web Services verfolgt dabei einen anderen Ansatz. Web Services Choreographie ist an dem Konzept der verteilten Aufgabenbearbeitung orientiert [Hofmann 2005]. Die Web Service Choreographie modelliert den Ablauf zwischen Service Anbieter und Service Nutzer. Sie geht im Gegensatz zu der Orchestration nicht auf den internen Aufbau eines komplexen Web Services ein. Daher gibt es bei der Choreographie auch keine kontrollierende Instanz, die den exakten Ablauf (und damit die Fachlogik) eines Web Services beschreibt. In einem Choreographie Dokument werden die Aufgaben aller Beteiligten beschrieben. Ein Choreographie Dokument übernimmt also die Kooperation (collaboration) mehrerer Partner (vgl. [Dostal u.a. 2005]). Deshalb wird das Prinzip der Choreographie Modellierung meistens im B2B Bereich eingesetzt. Dort gilt es vorrangig, Aufgaben den beteiligten Parteien zuzuordnen und die Kommunikation zwischen diversen Partnern zu regeln. Ein weiterer Unterschied zur Orchestration liegt darin, dass lediglich der Ablauf der Kommunikation modelliert wird. Dadurch wird nicht die gesamte fachliche Logik der Prozesse offengelegt.

Zusammenfassend kann man die Begriffe Orchestrierung und Choreographie dadurch voneinander abgrenzen, dass Orchestrierung die Komposition von Web Services beschreibt und sich so für die Modellierung privater Geschäftsprozesse eignet und Choreographie das Zusammenspiel zwischen Service Partnern in einer Architektur beschreibt und somit für die Modellierung öffentlicher Prozesse verwendet werden kann. In der späteren Betrachtung der Geschäftsprozessmodellierung am Beispiel von BPEL wird ausschließlich auf die Orchestrierung von Web Services eingegangen. Für detailliertere Informationen, um auch die Choreographie von Web Services mit BPEL umzusetzen, sei auf die Spezifikation der Sprache verwiesen [IBM 2006_b].

Bis zum jetzigen Zeitpunkt konnte sich noch keine der eingangs erwähnten Sprachen als eindeutiger Standard auf dem Bereich der Geschäftsprozessmodellierung durchsetzen. Es wird lediglich davon ausgegangen, dass die Sprache BPEL (in der Literatur auch als BPEL4WS, Business Process Execution Language for Web Services zu finden) sich in diesem Bereich als Standard durchsetzen wird. Gründe für diese Annahme liegen zum einen darin, dass diese Sprache von führenden IT-Firmen wie IBM und Microsoft unterstützt wird [Hauser, Löwer 2004], zum anderen darin, dass die Sprache bereits dem OASIS¹ Konsortium zur Standardisierung vorgelegt worden ist [Oasis 2006]. Wird eine Sprache von einem unabhängigen Konsortium als Standard freigegeben, dann werden langfristig auch die Softwarehersteller im Bereich der Geschäftsprozessmodellierung lediglich diesen freigegebenen Standard unterstützen. Dadurch werden andere Prozesssprachen, die sich nicht als Standard durchsetzen konnten, mit der Zeit bedeutungslos werden. Abbildung 5 gibt einen abschließenden Überblick über die zeitliche Entwicklung der Geschäftsprozesssprachen. Das darauf folgende Kapitel 2.6.3.1 erläutert dann am konkreten Beispiel von BPEL, wie man mit Hilfe dieser Sprache einen Geschäftsprozess definiert, um diesen anschließend service-orientiert umsetzen zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Entwicklung der Geschäftsprozessmodellierungssprachen [Dostal u.a. 2005]

[...]

---

¹ Organization for the Advancement of Structured Information Standards (OASIS, http://www.oasis-open.org). OASIS ist ein unabhängiges Gremium, dass im Internetbereich bestimmte Technologien als Standard verabschiedet.

• Universidad: University of Siegen (Fachbereich Wirtschaftswissenschaften)
• Calificación: 1,3
• Autor: Jens Kohne (Autor)
• Año de publicación: 2006
• Páginas: 117
• No. de catálogo: V65848
• ISBN (Ebook): 9783638583220
• Idioma: Alemán
• Etiqueta: Aspekte, Entwurfs, Implementierung, Architekturen, Beispiel, Portal-Systemen