Service-orientierte Architekturen: Proof-of-Concept eines Web Service zur Integration verteilter Anwendungen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Herangehensweise
1.3 Fallstudie Business Case

2 Definitionen
2.1 Architektur
2.2 Web Service
2.3 Abgrenzung Service-orientierte Architektur und Web Services
2.4 Web Service Architektur

3 Konzeption
3.1 Vorteile von SOA in Form von Web Services
3.2 Nachteile von Web Services
3.3 Reifegrad von Web Services
3.4 Geeignete Szenarien für Web Services
3.5 Vergleich von .Net und J2EE
3.6 Lösungsszenario für die Fallstudie
3.7 Architektur
3.7.1 Architekturprinzipien
3.7.2 Design Patterns
3.7.3 Architekturoptionen
3.8 Vorgehen für die Fallstudie

4 Implementierung der Fallstudie
4.1 Auswahl der Entwicklungsumgebung
4.2 Bereitstellung von Services
4.3 Erstellung von Servicenutzern
4.4 Zugriff über WSDL
4.5 Veröffentlichung eines Services
4.6 Auffinden eines Services
4.7 Orchestrierung der Services
4.8 Erkenntnisse aus dem Proof-of-Concept

5 Zusammenfassung

Anhang A. Standards, Beispiele und Sourcecode

Anhang B. Quellenverzeichnis

Anhang C. Tabellen- und Abbildungsverzeichnis

Anhang D. Glossar

1 Einleitung

1.1 Motivation

Laut des Marktforschungsinstituts Gartner wird die Service-orientierte Architektur – kurz SOA genannt, wobei die Definition im Kapitel 2.3 erfolgt - bis zum Jahre 2008 die 40-jährige Ära der monolithischen Systeme abgelöst haben [G2003]. Das Ziel von SOA ist die Integration von Anwendungen. Unternehmensintern wird dies durch enterprise application integration Portale erreicht.

Diese Arbeit soll anhand einer Fallstudie aufzeigen, dass eine SOA mit Web Services die Integration von Anwendungen über Unternehmensgrenzen hinweg ermöglicht.

Zudem soll dargelegt werden, welche Überlegungen im Vorfeld einer Web Service Erstellung durchzuführen sind.

Die Bedeutung von Web Services kann man sich durch eine Analogie deutlich machen. Web Services haben für Applikationen die gleiche Bedeutung wie Internet-Browser für Menschen. Web Services sind ein Kommunikationsweg zwischen den Anwendungen.

1.2 Herangehensweise

In dieser Arbeit wird der Entwurf einer SOA anhand von Web Services beschrieben. Als Proof-of-Concept wird ein B2B Szenario entworfen und als Anwendung implementiert.

Für das B2B Szenario wird eine Fallstudie mit einem Geschäftsprozess eines fiktiven Handelsunternehmens abgebildet. Für die Lösung der Fallstudie wird in einem ersten Schritt der Prozess modelliert.

Anschließend wird im Kapitel 2 eine Verständnisgrundlage für die folgenden Kapitel aufgebaut. Für die Erläuterung von Basistechnologien wie XML, SOAP, WSDL und UDDI sei auf die Fachliteratur verwiesen [z.B. JWS].

Das Kapitel 3 befasst sich mit der Architektur von SOA und Web Services. Es erläutert die konkreten Schritte und Überlegungen in der Konzeption zur Fallstudie.

Das Kapitel 4 beschreibt die Schritte zur Umsetzung der Fallstudie. Im Kapitel 5 werden die aus dem Beispiel gewonnen Erkenntnisse zusammengefasst.

Das Glossar im Anhang erläutert Abkürzungen und fachliche Begriffe.

1.3 Fallstudie Business Case

Ein Business Case ist ein Geschäftsanwendungsfall, der eine in sich geschlossene Transaktion und einen Teilprozess der gesamtbetrieblichen Wertschöpfung darstellt.

Auf den folgenden beispielhaften Business Case wird im weiteren Verlauf verwiesen:

Die Handel AG ist ein imaginärer Lebensmittelgroßhändler, der eine Qualitätssicherungsabteilung unterhält. Die Qualitätssicherungsabteilung der Handel AG vergibt Untersuchungsaufträge an externe Nahrungsmittellaboratorien und erhält im Gegenzug Befundergebnisse. Je nach Befundauftrag für einen bestimmten Artikel werden spezialisierte regionale Institute beauftragt.

Diese Institute verschicken Lebensmittelbefunde als PDF Dokumente an die Qualitätssicherungsabteilung. Ein Befund enthält Daten zum geprüften Artikel, dem Prüfort – normalerweise eine Filiale – und dem Prüfergebnis. Die wichtigste Information in einem Prüfergebnis ist die Verkehrsfähigkeit bzw. einwandfreie Qualität eines Lebensmittelartikels.

Für die Handel AG besteht die gesetzliche Pflicht, einen nicht verkehrsfähigen Artikel sofort aus der Distribution zu ziehen. Bisher wurden die Befunde als PDF Datei der Handel AG per Email zugeschickt. Der Sachbearbeiter muss nach Email-Empfang diesen Befund manuell in das Laborinformationssystem eingeben.

Bei der Handel AG basiert das Laborinformationssystem der Qualitätssicherungsabteilung auf einer Standardsoftware, die keine webbasierte Verteilung ermöglicht. Um den Befundübergabeprozess zwischen den Laboratorien und der Qualitätssicherungsabteilung zu optimieren, soll eine integrierte und verteilte Lösung für heterogene Anwendungssysteme gefunden werden.

In der Abbildung unten wird der Prozess der Befundübermittlung visualisiert. Am Prozessanfang wird ein Befundauftrag vergeben, wobei der Prozess von oben nach unten verläuft. Die Kästchen sind Aktionen und repräsentieren einzelne Arbeitsschritte. Die gerichteten Kanten sind Verbindungen zwischen Arbeitsschritten. Einzelne Kanten ,abgehend von Aktionen, führen zu den Prozessobjekten „Befund“ und „Rechnung“.

Diese Bezeichnungen bedeuten, dass an dieser Stelle Dokumente zwischen den Arbeitsschritten versendet werden. Eine Rechnung wird in Papierform versendet, ein Befund dagegen elektronisch. Das auf der Kante stehende Rechteck ist eine Entscheidung der Form Ja/Nein. Wenn ein Befund ergeben hat, dass ein Artikel nicht für den Verkauf verkehrsfähig ist, wird dieser schnellstmöglichst aus dem Vertrieb gezogen. Es ist zu erkennen, dass eine Rechnung auf Korrektheit geprüft wird, während ein Befund direkt in das Handel AG System übernommen wird.

In der Analysephase hat sich zudem gezeigt, dass die Laboratorien eine Bestätigung des Befund-Empfangs wünschen, um diese Bestätigung intern als Referenz zu übernehmen. Diese Anforderung wird im Kapitel 4.2 umgesetzt.

Abbildung 1 Prozessabbildung Befundübermittlung

Abbildung in dieser Leseprobe nicht enthalten

Der Arbeitsschritt „Befund übermitteln“ wurde für die Fallstudie als Web Service Implementierung ausgewählt, da an dieser Stelle mit mehreren externen Geschäftseinheiten – Laboratorien – kommuniziert wird (siehe Kapitel 3.4 zu geeigneten Szenarien für Web Services).

2 Definitionen

2.1 Architektur

Laut Definition des àW3C ist die Software-Architektur eines Computersystems die Struktur dieses Systems [W3C-gloss]. Diese Struktur beschreibt Softwarekomponenten, sowie die wesentlichen Merkmale als auch die Beziehung zwischen den Komponenten und Einschränkungen bei der Benutzung der Komponenten. Eine Softwarearchitektur ist eine Abstraktion der Laufzeitelemente eines Softwaresystems. Ein System hat mehrere Abstraktionsebenen mit jeweils eigener Softwarearchitektur.

Die Software-Architektur strebt an, ein Informationssystem zur Unterstützung von Geschäftsprozessen aus allen Sichten und Entwicklungsphasen zu definieren [WRIG].

Verschiedene Notationssprachen existieren, um eine Architektur semi-formal zu beschreiben, wie z.B. das Semantische Objektmodell SOM [GdW], die Architektur Integrierter Informationssysteme (ARIS) oder die Notationssprache Unified Modelling Language (UML).

Eine Architektur beschreibt sowohl statische als auch dynamische Aspekte. Sie erfüllt die Aufgabe eines Bauplans und eines Ablaufplans für Software. Der Übergang von der Analysephase zu der technischen Realisierung wird über die Software-Architektur gebildet. Die Fachdomäne wird in Software umgesetzt, indem die Funktionalität der Anforderungsdefinition auf eine Struktur von Softwarekomponenten und deren Beziehungen abgebildet wird [ESA].

Architekturen dokumentieren das Zusammenwirken von Komponenten. Sie erleichtern das Verständnis eines Systems. Die Planung der Software-Architektur hat folgende Vorteile:

- Das Management kann eine Anforderungsverifikation durchführen.
- Neue Projektmitarbeiter können sich schnell mit dem System vertraut machen.
- Wartungen können einfacher durchgeführt werden, da betroffene Bestandteile gut auffindbar dokumentiert werden. Folgen von Änderungen können besser eingeschätzt werden.
- Eine Software-Architektur ist eine Basis für eine integrierte System-Architektur, die neben der Software auch Hardware und Orgware – die Organisationsstruktur umfasst.

Für die Fallstudie wird die Architektur im Kapitel 3.8 dokumentiert.

2.2 Web Service

Der W3C definiert einen Web Service folgendermaßen:

„A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards”^[1] [WS-gloss].

Der W3C charakterisiert einen Web Service folglich als eine Software-Zwischenschicht zur Verbindung von Maschinen in einem Netzwerk. Der Oberbegriff für eine derartige Zwischenschicht ist à middleware. In Kapitel 4.2 wird die Erstellung eines Web Service im Rahmen der Fallstudie beschrieben.

Fu, Bultan und Su [FBS0504] definieren das Ziel eines Web Service mit einem zusätzlichen Charakteristikum: „A fundamental goal of web services is to have a collection of network-resident software services accessible via standardized protocols, whose functionality can be automatically discovered and integrated into applications or composed to form more complex services.” Das bedeutet, daß Web Services zusammengesetzt werden können, um in einer größeren Struktur zusammen zu arbeiten. Ebenso wie Geschäftsprozesse aus Unterprozessen bestehen, können grobgranulare Web Services aus zahlreichen feineren Web Services bestehen. Zusätzlich ist das automatische Auffinden der Services möglich.

Zusammenfassend lassen sich folgende Eigenschaften von Web Services festhalten [IS27]:

- Identifizierbarkeit: Ein Web Service wird durch einen àURI lokalisiert. Die Funktionalität des Service sollte zudem durch definierte Metadaten erreichbar sein.
- Maschinenlesbarkeit: Die Schnittstelle eines Web Service ist durch Anwendungen lesbar und wird durch àWSDL beschrieben.
- Offenheit: Ein Web Service kommuniziert mit anderen Softwarekomponenten durch XML-Nachrichten. Der Nachrichtenaustausch kann – muss aber nicht – über HTTP oder SMTP stattfinden. Die offenen Schnittstellen erlauben die Verknüpfung von Services.
- Autonomie: Dies bedeutet, dass sich nicht beeinflussen lässt, wie eine Nachricht von einem Web Service verarbeitet wird. Nur durch zusätzliche Vereinbarungen lassen sich Qualitätseigenschaften wie Antwortzeiten festhalten. Ein Web Service hat zudem eine in sich geschlossene Funktionalität und sollte von anderen Services unabhängig sein [JM37].
- Technologieneutralität: Ein Web Service kann zu einem hohen Grad technologieneutral sein. Die Neutralität hängt vom Entwurf und dem Einsatz offener Spezifikationen ab.

Die Rollen in einem Web Service sind der service provider, der service requestor und die discovery agency. Die Rollen werden im Kapitel 2.4 genauer erklärt. Der service requestor und der service provider sind auf drei Ebenen miteinander verbunden:

1. Die Web Services Description Language WSDL stellt eine Schnittstelle mit zugesicherten Eigenschaften – einen contract – zur Verfügung.
2. Über das Simple Object Access Protocol àSOAP werden zur Laufzeit Aufrufe verschickt.
3. Die Ebene der à discovery agency ist ein Publizierungs- und Auffindungsmechanismus, der entweder zur build time oder Laufzeit eingesetzt wird. Implementierungen dieses Vermittlerdienstes sind die Universal Description, Discovery and Integration (àUDDI) und die Web Services Inspection Language (WSIL).

Das Kommunikationsprotokoll zwischen request or, provider und discovery agency ist SOAP. SOAP ist ein remote procedure call (àRPC) Format. Wenn ein service requestor fest codiertes Wissen über den service provider hat, besteht keine Notwendigkeit für einen Vermittlerdienst wie UDDI. In diesem Fall nennt man den Web Service statisch.

Die Web Service Beschreibungssprache WSDL ist eine vertragliche Übereinkunft, die zum einen eine abstrakte Schnittstellenbeschreibung mit Operationen und Parametern enthält sowie zum anderen die Beschreibung zum Binden und Implementieren des abstrakten Interface. Diese Beschreibung definiert die Verbindung zum konkreten Protokoll und der Netzwerk Adresse. Mehrere Bindungen (à bindings) sind möglich, in dem Fall ist der Web Service über mehrere Protokolle erhältlich.

UDDI stellt eine Struktur für einen Vermittlungsdienst, die discovery agency, zusammen mit einer Anfrage- und Publizierungsschnittstelle – dem application programming interface (àAPI) - bereit. Wenn die discovery agency zur Laufzeit genutzt wird, ist dies ein dynamischer Web Service. Der service provider meldet der discovery agency seinen Service und der service requestor fragt Dienstanbieter bei der discovery agency ab. WSIL ist eine Alternative zu dem weiter verbreiteten UDDI, die in dieser Arbeit nicht weiter betrachtet wird. Die Abbildung unten zeigt die dynamische Sequenz der Web Service Bausteine.

Abbildung 2 dynamischer Ablauf Web Service Anmeldung / Nutzung

Abbildung in dieser Leseprobe nicht enthalten

Diese Abbildung [POWS] zeigt alle Komponenten eines dynamischen Web Services zuzüglich des back-ends des providers. Sowohl Erstellungszeit- als auch Laufzeit-Abläufe werden gezeigt. In der Erstellungszeit (im Engl. build time) wird der service provider aus dem back-end eines Unternehmens mit WSDL beschrieben und bei der discovery agency angemeldet. Zur Laufzeit (im Engl. runtime) findet der service requestor den Dienst und holt sich über die WSDL Datei Zugriff auf die Anwendung des service provider s.

2.3 Abgrenzung Service-orientierte Architektur und Web Services

Eine SOA ist ein Designkonzept [CW4], sie ist keine Technologie. Ein Web Service ist eine technische Möglichkeit, eine SOA zu implementieren. Das Ziel einer SOA ist es, Prozesse und Prozessschritte zu kapseln und diese in einer abstrahierenden Sprache anderen Anwendungen bereit zu stellen. Letztendlich bedeutet dies, dass Geschäftprozesse nicht mehr auf der Ebene der Anwendungscodierung beschrieben werden, sondern eine Abstraktionsebene darüber.

Anwendungen, die Prozessschritte abbilden, werden als Services definiert und in einem Baukastensystem wiederverwendbar gestaltet. Prozessschritte und gesamte Prozesse können neu kombiniert und wiederverwendbar gestaltet werden. Die Kombination von Prozessschritten und Prozessen wird auch Choreographie von Prozessen genannt, den Aufbau der Anwendungen bzw. Prozesse bezeichnet man als Komposition [CKMTW].

Eine SOA hat Dienste bzw. Services, die von Clients bzw. service requestors abgerufen werden. Zudem liegt ein Verzeichnis vor, in dem die Services gelistet und auffindbar für die request ors sind. Ein Service kann zum request or werden und umgekehrt. Wenn beispielsweise ein Service für die Kreditkartenvalidierung auf einen Service mit Adressdaten zugreift, wird der erste Service zum request or. Es entsteht ein Dienstleistungsnetzwerk mit einem oder mehreren Geschäftsverzeichnissen. Die Dienstleistungen werden von Maschinen – den Anwendungen erbracht und von Anwendungen angefordert.

Zur Erstellung einer SOA müssen Prozesse modelliert, anschließend in einzelne Servicebausteine unterteilt und im letzten Schritt miteinander lose integriert werden. Diese Programmierung im Großen ähnelt der Aufgabe eines Architekten, der vor der eigentlichen Komposition analytisch die Anforderungen definiert, Abläufe und Zusammenhänge beschrieben und Bausteine definiert hat.

In [POWS] wird eine SOA als eine Architektur definiert, die konform zu der W3C Web Service Basis Architektur ist. Die Web Service Architektur wird im nächsten Kapitel beschrieben.

Web Services basieren auf dem Paradigma der SOA: Es liegen requestors (Anfrager bzw. clients auf einen Dienst) vor, die auf Dienste zugreifen, die wiederum in Verzeichnissen geführt werden. In anderen Worten richtet sich der Bauplan nach spezialisierten Dienstleistungsträgern in einem Verbund mit einem Geschäftsverzeichnis aus.

Ein Web Service ist folglich eine Service-orientierte Architektur, ebenso wie CORBA. Der Unterschied eines Web Service zu CORBA Objekten ist, dass ein Web Service aufeinander abgestimmte Internettechnologien bzw. vom W3C vorgeschlagene Standards benutzt und über das Internet kommuniziert. Die Web-Schnittstellen werden über das SOAP Protokoll aufgerufen und anstelle von JNDS oder X.500 Verzeichnisdiensten bei CORBA wird UDDI verwendet [ECEB].

Bei der Konzeption zur Umsetzung der Fallstudie im Kapitel 3 werden zentrale Aspekte einer SOA wie die Interoperabilität zwischen Systemen und lose Kopplung beachtet.

2.4 Web Service Architektur

Das W3C [W3C-arch] unterscheidet zwei Ebenen der Web Service Architektur:

- basic architecture: Die Rollen von Software Systemen, die unterstützten Operationen und die Technologie Stacks in der Web Service Architektur werden beschrieben. Die Grundfunktionen, die alle Web Service Architekturen erfüllen müssen, sind: Der Austausch von Nachrichten, die Beschreibung von Web Services und die Publizierung sowie das Auffinden von Web Service Beschreibungen.
- extended architecture: Auf dieser zweiten Ebene werden Erweiterungen der Basisarchitektur aufgesetzt wie z.B. asynchrones Messaging, Session Konzepte und Nachrichtensicherheit.

Gemäß der W3C Definition sind die Beschreibung von Schnittstellen und der Nachrichtenaustausch wesentliche Aufgaben der Web Service Architektur. Ein statischer Web Service kann auch ohne den Discovery-Prozess, d.h. ohne Vermittlung zwischen Service Anfrager (service requestor) und Service Bereitsteller (service provider) aufgesetzt werden. Ein dynamischer Web Service hat einen dritten Kommunikationspunkt, den Service Vermittler (discovery agency bzw. service broker).

Nur in dem Fall wenn mehrere Services und request or sich dynamisch ändern, ist der Discovery Prozess notwendig. Die Kerntechnologien sind SOAP, WSDL und UDDI, wobei UDDI bei statischen Web Services keine Rolle spielt. Alle genannten Technologien basieren auf XML. Sie können Internetprotokolle wie HTTP oder SMTP verwenden. Zur Visualisierung dieser Technologien eignet sich die Grafik unten aus [W3C-arch]:

Abbildung 3 Web Services Technologie Stack

Abbildung in dieser Leseprobe nicht enthalten

Die Basistechnologie XML ist eine Metasprache aus Sicht der Technologien WSDL, SOAP und UDDI. Diese Technologien sind schemadefinierte Sprachen auf XML-Basis.

Über die Web Services Description Language wird der jeweilige Service beschrieben und Nachrichten zwischen service provider und service requestor werden über SOAP ausgetauscht. Die Nachrichtenüberbmittlung kann über eines der Protokolle

- Internet Inter-ORB Protokoll (IIOP läuft in CORBA),
- über das Internet per HTTP oder SMTP Protokoll
- oder auch über den Java Messaging Service (JMS) erfolgen.

Sicherheitsaspekte, Qualitätsaspekte und das Service Management werden nicht in den Basistechnologien beschrieben und werden außerhalb des eigentlichen Web Service betrachtet.

Aus den drei Stacks mit discovery, Beschreibung und Nachrichten entsteht die bisher vom W3C definierte Spezifikation. Die Spezifikationen, die tiefer im Stack liegen (Nachrichtenformate wie SOAP), sind weiter entwickelt, als die Discovery Formate weiter oben im Stack. Das Niveau der Standardisierung auf dieser oberen Ebene ist geringer [CW44, POWS]. Dies hat zur Folge, dass der produktive Einsatz in Unternehmen aufgrund geringerer Technologiereife noch nicht weit verbreitet ist (siehe Kapitel 3.3).

Über XML Informationen wird der Datentyp und die Nachrichtenstruktur sowie der message exchange pattern (MEP) beschrieben. Ein MEP ist eine beliebig wiederholte Nachrichtenaustausch-Sequenz zwischen dem request or und provider. Es existieren one-way, request-response und publish-subscribe message exchange pattern s. Beim one-way MEP wird eine Nachricht versandt und keine Antwort erwartet. Beim request-response MEP wird eine Nachricht versandt und eine Antwort zurückgeschickt. Dieser MEP eignet sich u.a. für die Synchronisierung zwischen Kommunikationspartner. Beim publish-subscribe MEP wird eine Nachricht für abhörende Objekte - sogenannte listener - bereitgestellt, die sich vorher für den Dienst eingeschrieben haben.

Dieser Pattern eignet sich für das Versenden von Nachrichten an unbekannte Empfangsobjekte. Beispielsweise stellt ein CRM System Kundenaktualisierungen bereit, die dann vom Rechnungswesen aufgegriffen werden.

Das Transportprotokoll und Zugriffsinformationen sind ebenfalls Teil der W3C Web Service Architektur Beschreibung. Ein service provider Endpunkt wird mit der URL definiert sofern HTTP benutzt wird.

Ein Software System kann demnach mehrere Rollen annehmen:

- Service Anfrager (service requestor): Dieser initialisiert die Anfrage und die Ausführung des Services und agiert als Client.
- Service Bereitsteller (service provider): Er verarbeitet eine Anfrage nachdem er eine Web Service Beschreibung per WSDL veröffentlicht hat. Der service provider hat die Position des Servers inne. Der service provider kann seinerseits in zwei Rollen aufgeteilt werden. Der service interface provider stellt die Schnittstellen zu den Anwendungen bereit. Der service implementation provider ist die zweite Rolle. Dieser stellt den Anwendungsserver bereit und betreibt den Service. Beide Rollen können von ein und derselben oder unterschiedlichen Organisationseinheiten wahrgenommen werden.
- Der Vermittler (service broker oder discovery agency): Dieser optionale Vermittler für dynamische Web Services unterstützt die Veröffentlichung von mehreren Web Services und vermittelt diese an service requestor. Der Vermittler kann zentral oder verteilt sein. UDDI ist eine mögliche Technologie aber in der einfachsten Form kann dies bereits eine Art statische Gelbe-Seiten-Verzeichnis (yellow pages) mit Services sein.

Die Darstellung unten illustriert die Rollen, die im Abschnitt oben für die Basis Architektur eines Web Services erklärt wurden:

Abbildung 4 W3C Web Service Dreieck

Abbildung in dieser Leseprobe nicht enthalten

Es ist dabei zu beachten, dass der Client bzw. service requestor in einem anderen Szenario ein Server werden kann. Dies ist der Fall, wenn der Client ebenfalls eine Service Beschreibung bei der discovery agency für einen Dienst hinterlegt hat und der bisherige service provider selber zum Client wird. Ein orchestrierter Service ist sowohl ein request or als auch ein provider. Die Orchestrierung beschreibt wie Web Services auf der Nachrichtenschicht miteinander kommunzieren und mit welcher Logik und in welcher Reihenfolge die Interaktionen stattfinden.

Die Aktionen, die die Rollen durchführen sind:

- Der service provider publiziert seine Dienste bei der discovery agency.
- Der service requestor findet Dienste bei der discovery agency über die Service Beschreibung, die der service provider dort hinterlegt hat. Dies kann zur build time (Kompilierungszeit) oder run time (Laufzeit) erfolgen. Falls bereits eine Übereinkunft zwischen service provider und service requestor auf der Geschäftsebene und technischen Ebene besteht, kann ein direkter Zugang aufgebaut werden.
- Der service requestor und provider interagieren über die Schritte lokalisiere, kontaktiere und rufe auf.

Bei der erweiterten Web Service Architektur können Zusatzfunktionalitäten - sogenannte features - hinzugefügt werden. Dies erlaubt eine größere Flexibilität. Beispiele für features sind: Zusätzliche message exchange pattern s, message attachments, message routing, Client/Server Caching und langandauernde Transaktionen. Weitere Beispiele sind in [WS-arch] zu finden.

Aspekte die bisher noch nicht vom W3C formal spezifiziert wurden, sind:

- Service Identifikation via einem uniform resource identifier (URI),
- Notationen für der Service Nachrichtenaustausch, also XML, WSDL, SOAP,
- Details bezüglich der Übertragungsprotokolle wie HTTP,
- Das SOAP Prozessmodell bezüglich Intermediaries und Rollen wurde ebenfalls noch nicht spezifiziert.

Zusammenfassend lässt sich festhalten, dass die Web Service Architektur an die CORBA Struktur erinnert. Dies ist nicht verwunderlich, da beide für Service-orientierte Architekturen prädestiniert sind.

3 Konzeption

3.1 Vorteile von SOA in Form von Web Services

Plattformunabhängigkeit

Vorteilhaft bei Web Services ist die Möglichkeit, auf unterschiedlichen Plattformen Dienstleistungen anzubieten. Diese universelle Einsetzbarkeit wird durch die offenen Standards wie XML und das leicht einsetzbare Transportprotokoll HTTP gewährleistet. Flexibilität und Wiederverwendbarkeit sind wesentliche Pluspunkte bei Web Services. Durch die Plattformunabhängigkeit und Flexibilität können heterogene Anwendungen in einem Intranet kommunizieren.

Technologieunabhängigkeit

Eine SOA ist grundsätzlich technologieunabhängig. Die Technologieunabhängigkeit der Schnittstellen kann durch Web Services oder durch Technologien wie das Opensource Peer-to-Peer Protokoll JXTA (www.jxta.org) erreicht werden. Die Zusammenstellung der Services kann bei Web Services über UDDI gesteuert werden, bei reinen Java Anwendungen erlaubt die JINI Technologie eine dynamische Orchestrierung.

Komplexitätsreduktion bei der Integration

Die Vorteile einer Vermittlungsschicht zwischen vielen Service Anbietern und Service Nachfragern lässt sich anhand einer Rechnung verdeutlichen. Bereits bei acht zu verbindenden Systemen ergeben sich ohne eine Vermittlungsschicht 8x7=56 verschiedene Verbindungsmöglichkeiten. Die Darstellung verdeutlicht die Komplexität, wobei nur Anwendung 1 und 2 mit allen anderen Anwendungen verknüpft wurden. Die restlichen Verknüpfungen würden bereits diese einfache Darstellung unübersichtlich gestalten.

Abbildung 5 Komplexität ohne Vermittlungsschicht

Abbildung in dieser Leseprobe nicht enthalten

Über eine Vermittlungsschicht würden nur insgesamt acht Verbindungen anfallen.

Abbildung 6 Vereinfachung mit einer Vermittlungsschicht

Abbildung in dieser Leseprobe nicht enthalten

Interoperabilität

Die auf XML basierende Interoperabilität und Unterstützung von zwischenbetrieblichen Anwendungen ist ein weiterer Vorteil. Ein Web Service kann mit einem beliebigen anderen Web Service eines Dritt-Unternehmens über die Standards UDDI, SOAP und WSDL kommunizieren. Zudem werden diese Standards auch von den großen marktbereitenden Unternehmen Microsoft, IBM oder SAP unterstützt. Die Software Industrie stimmt sich in der WS-I.org auf den gemeinsamen Einsatz der genannten Standards ab. Letztendlich bieten Web Services die Möglichkeit, die beiden großen Sprachlager Java und Microsoft Sprachen sowohl innerhalb eines Unternehmens als auch in der zwischenbetrieblichen Geschäftskommunikation gemeinsam einzusetzen. Durch diese Interoperabilität werden Prozessgrenzen zwischen Unternehmen überwunden. Web Services fördern somit das interbetriebliche E-Business.

Prozessintegrität

Durch die applikationsübergreifende Prozessintegrität werden Prozesse nicht fragmentiert, sondern gesamtheitlich modelliert. Über remote -Aufrufe werden Funktionalitäten in verschiedenen Anwendungen adressiert. Der Kontrollfluss verbleibt bei der aufrufenden Applikation. Das Monitoring kann zudem auf Geschäftsprozessebene verbleiben [HMD-H].

Informationslogistik

Hofmann [HMD-H] gibt zudem eine verbesserte Informationslogistik als Folge einer zentralen Vorhaltung von Geschäftsprozessen an. Durch die zentrale Ablage der Geschäftsprozesse in einer Service-orientierten Umgebung werden Applikationen optimal orchestriert. Funktionen und Daten werden nur aufgrund der hinterlegten Prozesse angelegt. Nicht benötigte Informationen werden unterdrückt und reduzieren so den Verwaltungsaufwand.

Lizenzkosten

Aufgrund der Interoperabilität sind die Einstiegskosten in Form von Lizenzen in Web Services geringer, als z.B. bei der Einführung eines neuen ERP Moduls oder bei dem Einsatz einer neuen Enterprise Application Integration Plattform. Sofern organisationsinterne Anwendungen über objektorientierte Klassen definiert wurden, ist die Erstellung eines darüber aufsetzenden Web Services in kurzer Zeit möglich. Zudem werden einige kostenlose Werkzeuge bzw. Kits angeboten, die einen Großteil der Erstellungsarbeit automatisieren können. Z.B. bietet Amazon (Amazon Web Services) kostenlose Toolkits an, die über Kommandozeilen oder als Plugin in Entwicklungsumgebungen funktionieren.

Beschleunigte Softwareentwicklung

Eine Parallelisierung der Softwareentwicklung ist durch die Zerlegung der Prozesse in Services möglich. Die von unterschiedlichen Teams erstellten Services müssen im nachhinein durch die Programmierung im Großen zusammengesetzt werden. Da die Schnittstellen feststehen, so bei einer Festlegung auf bestimmte Grundsätze wie z.B. eine definierte SOAP Laufzeitumgebung, sinkt der Abstimmungsaufwand bei Änderungen. Ebenso steigt die Releaseunabhängigkeit durch diese definierten Schnittstellen [HMD-H].

Legacy Erweiterung

Durch die geringeren Einstiegskosten kann bestehende Geschäftslogik bzw. die abbildende Software durch Web Services eine Verlängerung des produktiven Einsatzes erfahren [HCNS]. Diese bestehende Software in Firmen wird unter dem Begriff Legacy System (aus dem Englischen „Vermächtnis“) zusammengefasst.

Bei der Integration von Legacy-Systemen und der Nutzung von Persistenzschichten lassen sich laut [ESA] Vorteile einer SOA nutzen. Altsysteme, die nicht webfähig sind, lassen sich schwer mit anderen Anwendungen integrieren. Zum Ausbau in Richtung Interoperabilität müsste die vorhandene Logik mit einem Wrapper ummantelt werden. Eine SOA in der Ausprägung der reifen Web Service Technologie ist ein passender Implementierungsansatz, da Web Services die Legacy Systeme mit einer interaktionsfähigen Mittlerschicht ummanteln. Die technischen Inseln der Altsysteme können so verknüpft werden.

Legacy-Systeme haben ihre eigenen Konzepte zu Transaktionsverhalten und Sicherheit. Zur Integration muss man z.B. auf die Java Connector Architecture zurückgreifen. Systeme, die funktional arbeiten, könnten hier auf Probleme mit den eher datenorientiert arbeitenden EJBs stoßen. In [ESA, S.141] wird daher eine SOA mit Sessions Beans zum Datenzugriff empfohlen.

Programmierung im Großen

Quasi-monolithische Software mit enger Kopplung bekommen durch das Paradigma der Service-Orientierung Konkurrenz. Software wird granularer und schon in kleineren Modulen einsetzbar. Diese Module können durch Modellierungswerkzeuge und Entwicklungsplattformen wie Netweaver oder .Net zusammengesetzt werden und erlauben eine flexiblere „Programmierung im Großen“ statt zahlreicher Anpassungen eines großen Softwareblockes durch „Programmierung im Kleinen“.

Nähe zum Geschäftsprozess

Ein SOA-Dienst entspricht in der Granularität einer fachlichen Komponente [JM37]. Fachliche Transaktionen oder komplette Geschäftsprozesse können als Service ausgeführt werden. Existiert bereits eine Komponentenarchitektur im Unternehmen, so kann diese direkt in eine SOA Architektur überführt werden. Die Abbildung unten erläutert das Konzept der fachlichen Komponente [SB]. Innerhalb der Komponentengrenzen gibt es die Persistenz-, Logik-, Condensation- und Decoration-Schicht. Die Persistenzschicht hält Daten vor, die in der Logikschicht verarbeitet werden. In der Condensation Schicht wird aus feingranularen Funktionen und Services grobgranulare Services. Der Abstraktionsgrad nimmt dabei zu. Die Decoration-Schicht führt Dienste zur Durchführung von Transaktionen oder besondere Sicherheitseigenschaften ein. An den Grenzen der Komponente liegt oberhalb die Publizierungsschicht mit einer Beschreibung aller Funktionen. Dies kann bei Web Services eine WSDL sein. Unterhalb der Komponente liegt beispielhaft eine Integrationsschicht. Hier werden externe Funktionen integriert, die aufgrund ihrer technischen Insellösung nicht ohne weiteres mit anderen Komponenten integrierbar sind. In der Fallstudie ist der Teilprozess der Befundübermittlung per WSDL definiert.

Abbildung 7 Schichten einer fachlichen Komponente (nach [JM37, SB])

Abbildung in dieser Leseprobe nicht enthalten

Wiederverwendung

Die Funktionalitäten der Anwendungen werden durch offene Schnittstellen sichtbar [JWS]. Dies fördert die Wiederverwendung von Komponenten und Prozessschritten. Die wiederverwendbaren Prozesse werden auf einer über der konkreten Implementierung liegenden Ebene abstrahiert. So sind mehrfach verwendbare Authentifizierungs- oder Bestellprozesse als Web Service abbildbar. Über verschiedene Kanäle können diese Funktionalitäten und Prozesse aufgrund der flexiblen Schnittstellen aufgerufen werden. So sind ein Mobil-Portal und unterschiedlichste Clients wie PCs und PDAs denkbar.

Neuartige Prozesse

Durch die Flexibilisierung und Modularisierung einer Service-orientierten Architektur können auch neue zusammenhängende Geschäftsprozesse besser abgebildet werden [HMD-M]. Denkbar ist, dass das Customer Relationship Management und Supply Chain Management in eine „Demand Chain“ integriert werden. Letztendlich entscheidet der Endkunde, welche Ressourcen ein Unternehmen für die Produktion des Konsumgutes aufnehmen muss. Im Logistikbereich ist eine zwischenbetriebliche Integration von Liefernetzwerken und Lagern denkbar, wobei ein Lager-Web Service leere Stellplätze angibt, die einzelnen Lager-Web Services über einen Directory Service über UDDI auffindbar sind und mit Radio Frequency Identification (RFID) identifizierbare Pakete den leeren Lagern zugeordnet werden. Über den Austausch von strukturierten Daten können Geschäftspartner eine optimale Lieferkette ad hoc konfigurieren.

Abstraktion

Web Services bieten einen hohen Abstraktionsgrad [JWS]. Mit Prozesssprachen wie BPEL oder ebXML nähern sich Web Services an die geschäftliche Modellierung [CSDS].

„Web services are typically at a higher level of abstraction with respect to traditional middleware objects (CORBA objects), and are often used to support business-to-business interactions^[2].” [CSDS].

Aufgrund der hohen Abstraktion sind Web Services nahe an den Geschäftsprozessen angesiedelt, was die Umsetzung von Prozessen in maschinelle Anwendungen erleichtert. Wenn die Zuständigkeiten von Prozessen und Daten in der Fachabteilung klar gegliedert sind, kann der Implementierungszeitraum von Service-orientierten Systemen verringert werden. Zudem erleichtert der hohe Abstraktionsgrad die Kommunikation zwischen der IT und der Fachabteilung. Erfahrungsgemäß scheitern Projekte auch an fehlerhafter Kommunikation zwischen technischen und geschäftsprozessorientierten Mitarbeitern. Eine SOA mit Web Services erleichtert diese Kommunikation aufgrund der Abstraktion von einer rein technischen Ebene.

Deployment

Weiterhin erlauben Web Services wie andere SOA-basierte Technologien evolutionäre und inkrementelle Deployment Möglichkeiten. Bestehende Infrastrukturen und Anwendungen müssen dabei nicht geändert werden [HCNS]. Der Grund für diese Fähigkeit liegt in der indirekten Kommunikation zwischen Client und Server bei Web Services.

Entkoppelung

Bei einer direkten Kommunikation kennt der Client seinen Server. Das bedeutet für den Software Entwurf eine Abhängigkeit dieser beiden Komponenten . Änderungen der Server Adresse ziehen Änderung an allen beteiligten Clients nach sich. Die Flexibilitätsvorteile einer indirekten Kommunikation zwischen Client und Server entstehen aus der Entkopplung von Client und Server. Services werden über Vermittler aufgerufen. Eine Änderung am Service bedeutet eine Änderung beim Vermittler während die Clients unverändert bleiben. Eine indirekte Kommunikation wie bei Web Services lohnt sich laut [ESA, S.184] folglich bei:

- Einer Kommunikation, die über Systemgrenzen hinausgeht,
- Technischen Rahmenbedingungen, die sich häufig ändern etwa bei unterschiedlichen Standorten oder Netzwerkparametern,
- Hohen Anforderungen an die Flexibilität,
- Einer erwünschten Vermeidung einer Abhängigkeit zwischen Client und Server.

Durch die Entkoppelung werden Änderungen nur lokal begrenzte Auswirkungen haben. Fehler propagieren sich dadurch nicht unbegrenzt durch das gesamte Servicesystem. Weiterhin erlauben die losen Komponenten eine einfachere Integration von Standardlösungen. Service-orientierte Architekturen in Form von Web Services nehmen bereits Einzug in Standard-ERP Systeme wie SAP Netweaver. Dies zeigt, dass Industrieakzeptanz besteht.

Entwicklungswerkzeuge

Ein weiterer Pluspunkt von Web Services ist letztendlich, dass es effiziente Entwicklungserkzeuge für die Designphase und Modellierungswerkzeuge für die Prozessaufnahme und Analysephase gibt. Über bekannte Plattformen wie das .NET Framework von Microsoft oder die J2EE Plattform von Sun können Services, service requestor s und Verzeichnisse erstellt und verwaltet werden. Es existieren auch kostenlose Entwicklungswerkzeuge [MONO]. Ein Vergleich der Plattform wird in Kapitel 3.5 vorgenommen.

[...]

---

^[1] Übersetzung: „Ein Web Service ist eine Software-System für die maschinelle Interaktion über ein Netzwerk. Die Schnittstellen haben ein maschinenlesbares Format (WSDL). Andere Systeme interagieren mit SOAP-Nachrichten, die über HTTP mit XML Serialisierung und anderen Web-Standards weitergeleitet werden.“

^[2] Übersetzung: „Web Sevices sind typischerweise auf einem höheren Abstraktionsgrad als herkömmliche Middleware-Objekte (CORBA Objekte). Sie werden oft für B2B-Interaktionen genutzt.“