Entwicklung eines Leitfaden zur Entwicklung einer SOA

Inhaltsverzeichnis

1. Einleitung

2. Abgrenzung Enterprise Application Integration
2.1 EAI Integrationsarten
2.2 EAI Architekturen
2.2.1 Point-to-Point
2.2.2 Hub & Spoke
2.2.3 Bus-oriented
2.2.4 Distributed Objects
2.3 Technologien einer EAI
2.3.1 J2EE mit RMI
2.3.2 CORBA
2.3.3 Web-Services
2.3.4 Microsoft .NET / DCOM
2.4 Kommunikation innerhalb verteilter Anwendungen

3. Vertiefung SOA mit Web-Services
3.1 Serviceorientierte Architektur
3.1.1 Begriffsklärung und Definitionen SOA
3.1.2 Merkmale und Funktionsweise SOA
3.2 Web-Services
3.2.1 Begriffsklärung und Definition Web-Services
3.2.2 Merkmale und Funktionsweise Web-Services
3.2.3 Beschreibungssprache und Verzeichnisdienst der Web-Services
3.2.4 SOAP-Protokoll
3.2.5 XML-RPC Protokoll
3.2.6 REST Protokoll

4. Begriffsdefinitionen der fachlichen Sicht
4.1 Vorgehensmodelle der Anwendungsentwicklung
4.1.1 Wasserfallmodell
4.1.2 Inkrementelles und iteratives Modell
4.1.3 Agile Programmierung in der Anwendungsentwicklung
4.2 Business Process Modeling Notation
4.3 Business Process Execution Language
4.4 XML Process Definition Language

5. Leitfaden zur Gestaltung einer SOA
5.1 Schritt 0: Vorbereitung – Perspektive definieren
5.2 Schritt 1: Vorhandene IT-Landschaft analysieren
5.3 Schritt 2: Geschäftsprozessanalyse
5.4 Schritt 3: Architektur-Strategie festlegen
5.4.1 Strategie einer vollständigen Umsetzung
5.4.2 Strategie einer teilweisen Umsetzung
5.5 Schritt 4: Servicemodell aufbauen
5.5.1 Services identifizieren
5.5.2 Services kategorisieren
5.6 Schritt 5: Technologiewahl
5.6.1 Entscheidungsparameter einer Technologiewahl
5.6.2 Technologie festlegen
5.6.3 Umsetzung Web-Service Technologie
5.6.4 Messaging-Infrastruktur
5.7 Schritt 6: Komponentenmodell aufbauen
5.8 Schritt 7: Testen erster Realisierung der Services
5.9 Schritt 8: Beschreibung der Services
5.10 Schritt 9: Registry einbinden
5.10.1 Perspektive des Clients: Serviceabfrage
5.10.2 Service publizieren
5.11 Schritt 10: Services orchestrieren
5.12 Schritt 11: Testen orchestrierter Services
5.13 Schritt 12: Governance planen
5.13.1 IT-Governance im Allgemeinen
5.13.2 IT-Governance in Bezug auf das SOA-Projekt
5.14 Schritt 13: Testen unter Einbeziehung des Policy-Modells

6. Schlussbemerkung und Ausblick

7. Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Erweiterte Funktionsintegration

Abbildung 2: Prozessintegration

Abbildung 3: SOA-Haus

Abbildung 4: Rollen einer Web-Services Technologie

Abbildung 5: Verständnis geschäftsorientierter Implementierung,

Abbildung 6: Aspekte und Abhängigkeiten einer Web-Service-Architektur

Abbildung 7: SOA –Schichten

Abbildung 8: Rollen eines Servicemodells,

Abbildung 9: Clientseitige Komponentengenerierung

Abbildung 10: Verteilte Objekte und Firewalls

Abbildung 11: Kombinierte Technologien

Abbildung 12: Web-Service-Technologie mit und ohne Integrationslayer

Abbildung 13: Möglicher SOA-Architekturentwurf

Abbildung 14: Schematischer Aufbau einer WSDL-Beschreibung

Abbildung 15: WSDL2UDDI-Mapping

Abbildung16: Architekturmodell Einordnung BPEL-Prozess

Abbildung 17: Service-Orchestrierung

Abbildung 18: Zugriffe auf Daten mittels Wrapper-Services

Tabellenverzeichnis

Tabelle 1: Definition des Begriffs Serviceorientierte Architektur

Tabelle 2: Definition des Begriffs Serviceorientierte Architektur

Tabelle 3: Vergleich Technologien einer verteilten Architektur

Tabelle 4: UDDI-Informationsmodell (Auszug)

Tabelle 5: UDDI-Knoten API (Auszug)

Tabelle 6: Zugriffspunkt-URLs für Anfrage

Tabelle 7: Nachrichten der UDDI-API (Auszug)

Tabelle 8: Zugriffspunkt-URLs für Veröffentlichungen

Listingverzeichnis

Listing 1: Schematischer Aufbau einer SOAP-Nachricht

Listing 2: XML-RPC Dokument

Listing 3: Erzeugung einer Implementierungsklasse mit JAX-RPC

Listing 4: WS-Addressing in SOAP-Nachricht

Listing 5: Anfrage UDDI

Listing 6: BPEL-Datei

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Seit Ende der 80er Jahre verfügen Unternehmen zunehmend über ein heterogenes und dezentralisiertes IT-Umfeld, dessen Vorteile wie Schnelligkeit und Ausfallsicherheit bezüglich der Prozessverarbeitung aber auch neuen Problemstellungen wie redundanter Datenhaltung, Datensynchronisation und Prozessintegration gegenüber standen. In der Softwareentwicklung spiegelte sich dies in neuen Abstraktionen wie Sockets, Remote Procedure/Function Calls (RPC/RFC) und CORBA zur Verteilung einer Anwendung auf heterogener

IT-Umgebung wider. Es entstand eine Vielzahl von Schnittstellen, die einen hohen Realisierungs- und Wartungsaufwand erforderten.

Anstatt weiterhin aufwendige Punkt-zu-Punkt-Lösungen zu entwickeln, ging der Trend zu MOM (Message Oriented Middleware), bei der Daten in Pakete gepackt und als Nachrichten an eine Middleware übergeben werden.

Um generische Aufgaben in einer MOM zentral zu realisieren, wurden Message Broker zur Verwaltung und zum Versand von Nachrichten eingesetzt, wodurch die Anbindung eines gegebenen Systems durch die einmalige Anbindung an einen solchen Präsentationshub durch einen Adapter gelöst werden konnte.

Der Datenaustausch zwischen Unternehmen wurde auf Basis von VANs (Value Added Network) implementiert, mit anderen Worten, jedes Unternehmen musste ein Gateway (das der Spezifikation des VAN entsprach) implementieren. Es bildeten sich branchen- und länderspezifische Standards wie EDI (Electronic Data Interface) oder auf UN-Ebene EDIFACT heraus. Mit Einzug der Internettechnologie in die Unternehmenswelt entstanden vielversprechende Möglichkeiten zur Entwicklung generischer Plattformen und Produkte (wie J2EE oder DCOM/.NET), die den Datenaustausch über die TCP/IP Infrastruktur des Internets abzuwickeln vermochten.

Auch heute noch sind serviceorientierte Architekturen im Zusammenhang mit Web-Services sowohl in der Managerwelt als auch in der IT-Welt ein ausgesprochenes Hype-Thema, was unter anderem auch an der Unschärfe des Begriffs „SOA“ liegen dürfte.^[1]

2. Abgrenzung Enterprise Application Integration

Das primäre Ziel einer Enterprise Application Integration, folgend EAI genannt, ist die Verknüpfung existierender und neuer Applikationen in einer heterogenen IT-Landschaft. Diese Verknüpfung wird auf der Basis gemeinsamer Daten, Funktionen oder auch Geschäftsprozesse realisiert. So wird ein Datenaustausch zwischen den Applikationen ohne Medienbruch ermöglicht. Ein Integrationsserver stellt dabei ein Software-Paket, also ein EAI-Produkt, zur Realisierung einer beschriebenen Komponentenverknüpfung dar.

Die möglichen Formen einer Enterprise Integration unterscheiden sich in Bezug auf die Reichweite der zu realisierenden Geschäftsprozesse:

- A2A (Application to Application) – der Geschäftsprozess wird innerhalb des Unternehmens oder der Organisation realisiert,
- B2B (Business to Business) – der Geschäftsprozess wird zwischen verschiedenen Unternehmen bzw. Organisationen umgesetzt, beispielsweise über das Internet,
- B2C (Business to Customer) – in dieser Form einer Integration wird der Endkunde in den Geschäftsprozess integriert, beispielsweise ein browserbasierter Webclient.

2.1 EAI Integrationsarten

Die Integration innerhalb eines Systems wird in verschiedene Arten der Integration unterteilt:

Innerhalb einer Datenintegration nutzen Anwendungen denselben Datenbestand und tauschen Daten über ein festgelegtes Format aus. Eine beispielhafte Umsetzung einer Datenintegration wäre eine Schnittstelle für XML oder CVS.

Eine Dialog- bzw. GUI-Integration ermöglicht durch den Einsatz der Web-Technologie eine funktionale Trennung von Benutzereingaben sowie eine Zusammenfassung der Daten in Frames. Eine beispielhafte Umsetzung einer Dialogintegration wäre die Realisierung eines Portals mit einem Portlet für Suchfunktionalität und einem weiteren Portlet für einen Blog auf einer Website.

Bei einer Funktionsintegration stellen die verschiedenen Anwendungen ein API (Application Programming Interface) zur Verfügung. Somit kann eine Anwendung die Funktion einer anderen Anwendung ausführen. Diese Art der Integration ist häufig, aber nicht zwingend, synchroner Natur, da diese auf Interaktion zwischen anfragendem Client und antwortendem Server stattfindet.

Eine Komponentenintegration stellt eine Erweiterung einer Funktionsintegration dar. Diese findet bei großen Applikationen Anwendung, wobei die Komponenten eine Bündelung von Funktionen darstellen, mit anderen Worten, die verteilte Funktionalität ist in unterschiedlichen Adressräumen (auf verschiedenen Servern) lokalisiert. Eine solche Integration kann beispielsweise auf Basis von COM/DCOM, CORBA oder EJB-Containern (J2EE) realisiert werden. Je nach Komplexität kann dies mittels eines einfachen Plug-ins, eines Integrationsservers (verwaltet alle Daten und Funktionsaufrufe, Verbindung über Scriptsprache) oder eines Containers umgesetzt werden. Eine beispielhafte Umsetzung einer Komponentenintegration wäre eine J2EE-Architektur mit EJB-Containern für die Datenverarbeitung und einem JSP-Container für die Dateneingabe/Oberfläche (verwenden EJB-Methoden).

Folgende Abbildung verdeutlicht die möglichen Technologien zur Umsetzung einer erweiterten Funktionsintegration:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Erweiterte Funktionsintegration

Quelle: in Anlehnung an [Fletscher/Waterhouse], S.43

- RMI (Remote Method Invocation) des Herstellers SUN ist eine Art Java-RPC Mechanismus, um mit entfernten Objekten zu kommunizieren und deren Methoden aufzurufen (siehe J2EE) und nutzt keine nachrichtenbasierte Kommunikation, sondern direkte Verbindungen zur Client/Server-Kommunikation,
- CORBA (Common Object Request Broker Architecture) des Herstellers OMG ist ein Framework für verteilte Software-Komponenten für unterschiedliche Programmiersprachen (siehe CORBA) und nutzt einen nachrichtenbasierten Message Broker,
- DCOM (Distributed Component Object Model) des Herstellers Microsoft macht COM-Objekte über das Netz zugänglich (siehe .NET), unter Verwendung eines binären Protokolls über TCP/IP oder SOAP,
- RPC (Remote Procedure Call) ermöglicht entfernte Methodenaufrufe innerhalb eines Netzwerks,
- Web-Services unter Verwendung von SOAP, RPC-XML oder REST (im weitesten Sinne, konkrete Untersuchung folgt in folgenden Kapiteln) können einen
nachrichtenbasierten Enterprise Service Bus, nachfolgend ESB genannt, nutzen.

Die letzte vorgestellte Art einer Integration ist die Prozessintegration. In diesem Fall durchläuft ein Prozess alle notwendigen Applikationen, die von einer Prozesssteuerung aufgerufen werden. Dabei werden Teilprozesse so gesteuert, dass die Daten und der Status des übergeordneten Prozesses an die nachfolgende Applikation weitergegeben werden. Die Steuerung wird von einer Zwischenschicht (beispielsweise einem ESB), nachfolgend als Middleware bezeichnet, übernommen, die Daten und Ablauf standardisiert und kontrolliert. Folgende Abbildung verdeutlicht das Konzept einer Prozessintegration innerhalb einer verteilten Umgebung^[2]:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Prozessintegration

Quelle: in Anlehnung an [Fletscher/Waterhouse], S.44

Kapitel 5.11 beschreibt die Aspekte der Umsetzung einer Prozessintegration innerhalb einer dienstorientierten Architektur detailliert.

2.2 EAI Architekturen

Das folgende Kapitel erläutert die geläufigsten Architekturtechnologien Point-to-Point, Hub & Spoke, Bus-oriented sowie Distributed Objects.

2.2.1 Point-to-Point

Diese Form der Architektur unterscheidet nicht zwischen Client und Server, da die beteiligten Applikationen direkt miteinander verbunden werden, um (auch wechselseitig) auf benötigte Daten zuzugreifen. Unidirektionale und bidirektionale Schnittstellen werden häufig auf Basis von XML-Dokumenten, die manuell ausgetauscht werden, implementiert. Resultierend ergibt sich ab einem gewissen Grad an Komplexität des Systems eine hohe Anzahl an zu realisierenden Schnittstellen, deren Wartungsaufwand einen eindeutigen Nachteil darstellt.

2.2.2 Hub & Spoke

Das zentrale Element dieser Architektur ist ein Message Broker – ein Hub umgeben von Speichen (Spoke) -, der die Kommunikation über Schnittstellen zwischen Message Broker und der Anwendung innerhalb des Systems verwaltet. Der Implementierungsaufwand ist für den Grad an Flexibilität des Systems überschaubar. Die Anzahl der Schnittstellen entspricht der Anzahl an beteiligten Anwendungen innerhalb des Systems. Als Nachteil gilt der so genannte Flaschenhalseffekt – die Leistungsfähigkeit des Systems ist abhängig vom Server. Diese Art der Architektur ist in der Unternehmenswelt weit verbreitet und wird in der Literatur oft als Best Practice bezeichnet.

2.2.3 Bus-oriented

Ein Bus stellt über Schnittstellen (zwischen Anwendungen und Bus) die zentrale Verbindung zwischen den beteiligten Anwendungen eines Systems dar. Hier werden durch Master/Slave-Kategorisierungen der Teilnehmer Daten und Funktionen ausgetauscht. Dies ermöglicht die Auflösung komplexer Strukturen sowie eine effiziente Lastenverteilung. Auch hier entspricht die Anzahl der Schnittstellen der Anzahl an beteiligten Anwendungen innerhalb des Systems.^[3]

2.2.4 Distributed Objects

Diese Form der Architektur im weitesten Sinne kennt kein zentrales Element, da autonome Objekte dezentral über das System verteilt werden. Diese werden ebenso autonom über Schnittstellen angesprochen. Hierzu kann eine komponentenorientierte oder nachrichtenorientierte Zwischenschicht (Middleware) verwendet werden. Komponenten-orientierte Middleware stellt ein erweitertes RPC-Konzept dar und ermöglicht den Datenaustausch mittels synchroner Kommunikation über standardisierte Schnittstellen und Protokolle. Nachrichtenorientierte Middleware stellt weniger eine Anwendungsplattform dar, sondern tauscht Daten auf Basis von Nachrichten (Datenfolge, die von Anwendung gelesen wird) aus.

Verteilte Architekturen können grob betrachtet (Aspekt der Dienstverzeichnisse mit Schnittstellenbeschreibungen nicht betrachtet) als erste Realisierungen einer SOA betrachtet werden.^[4]

2.3 Technologien einer EAI

Im folgenden Kapitel werden die möglichen Technologien zur Umsetzung einer EAI-Integration, und damit einer verteilten Architektur, vorgestellt. Die einzelnen Ausprägungen der Eigenschaften einer Technologie wie Objektorientiertheit, Interoperabilität, Kommunikation und Transport, Schnittstellenspezifikation, dynamische Stuberzeugung oder Prozessorientiertheit werden in Kapitel 5.6 ausführlich für die vorgestellten Technologien (ausgenommen .NET) untersucht. Dieses Kapitel soll einen Überblick über später untersuchte Technologien geben.

2.3.1 J2EE mit RMI

Java Enterprise Edition spezifiziert unterschiedliche Container und definiert vier verschiedene Schichtenmodelle für serverseitige Software-Komponenten. Die implementierten Systeme werden über das Intra- oder Internet verwendet. Die Datenschicht wird gewöhnlich durch eine relationale Datenbank realisiert, die über einen Message Service (JMS) oder eine datenbankunabhängige Schnittstelle mit den darüberliegenden Schichten Daten austauscht. Die Geschäftslogik der Anwendung ist innerhalb der Business Layer gekapselt. Die Methoden der Geschäftslogik werden über Protokolle (beispielsweise RMI-IIOP oder RMI-JRMP) aus der darüberliegenden Schicht (Web-Layer) aufgerufen. Der Web-Layer enthält die Präsentationslogik zur Darstellung der Geschäftslogik im Intra- oder Internet. Die oberste Schicht bildet der Client Layer – dieser realisiert die Darstellung sowie Eingabemöglichkeit der Anwendung gegenüber dem Nutzer über einen Web-Browser.

RMI steht für Remote Method Invocation und ist eine Art Java-eigenes RPC. RMI er-möglicht verteilten Java-Objekten über Methodenaufrufe miteinander zu kommunizieren. Auch hier (vgl. CORBA) kapselt der Client die Daten in Stubs und schickt eine Nachricht, die die aufzurufende Methode und benötigte Parameter enthält, an den Server bzw. das Serverobjekt. Dieses führt unter Verwendung von Skeletons die Methode aus und schickt das Ergebnis über den Stub an den Client zurück.

Wie im weiteren Verlauf der Thesis ersichtlich werden wird, muss eine J2EE-Architektur nicht unbedingt mit RMI implementiert werden, um entfernte Methoden einer Javaklasse aufzurufen. Eine Implementierung von J2EE mit Hilfe von Web-Services ist innerhalb einer verteilten Architektur ebenso denkbar.^[5]

2.3.2 CORBA

CORBA (Common Object Request Broker Architecture) ist eine plattform- und sprachunabhängige Spezifikation, die eine Interaktion zwischen verteilten Objekten beschreibt. Diese Technologie funktioniert mittels ORB (Object Request Broker), CORBA-Facilities und CORBA-Services Der ORB stellt einen Kommunikationskanal zwischen den CORBA-Objekten dar. Der Client sendet eine Anfrage, die aus einem Methodenaufruf und den benötigten Parametern besteht. CORBA benötigt spezielle Netzwerkprotokolle, d. h. Nachrichten werden zunächst codiert und an den Server übermittelt. Dieser decodiert den Datenstrom, führt die Methode aus und sendet das Ergebnis auf dem gleichen Weg zurück an den Client (vgl. hierzu 5.6.1).

Die Beschreibung der clientseitig zur Verfügung gestellten Methoden werden durch so genannte Stubs in der Beschreibungssprache IDL (Interface Definition Language) beschrieben. Analog dazu werden die serverseitig zur Verfügung gestellten Methoden als Skeletons beschrieben. CORBA verwendet das IIOP Protokoll für die Client-Server-Kommunikation. Das Interessante an CORBA ist die vergleichsweise frühe Entwicklung von – zwar noch spezifischen – aber immerhin schon rollenunabhängigen (Client/Server) Schnittstellen sowie die zentrale Registrierung verfügbarer Dienste in einem Interface Repository. Dieses Kernkonzept spielt bei Entwicklung von Web-Services eine zentrale Rolle.^[6]

2.3.3 Web-Services

Das Konzept von Web-Services liegt in der Bereitstellung autonomer, zentral verfügbarer, aber lose gekoppelter Dienste, die über das Intra- oder Internet aufgerufen werden. Der Schlüssel zur Umsetzung dieses Konzepts sind die Schnittstellen der angebotenen Dienste. Diese werden (im XML-Format) für eine Verwendung von SOAP und XML/RPC (Ausnahme bildet REST) in einer WSDL-Datei beschrieben und in einem zentralen Verzeichnisdienst UDDI registriert. Dabei ist es irrelevant, wo sich die aufrufbaren Interfaces befinden (innerhalb des Systems oder extern) oder welche Komponente hinsichtlich der Infrastruktur des Systems an der Ausführung der Methode beteiligt ist. Kapitel 2 vertieft die Untersuchung von Web-Services.

2.3.4 Microsoft .NET / DCOM

Der Vollständigkeit halber soll an dieser Stelle die Microsoft .NET-Umgebung erwähnt werden, auf die aber im weiteren Verlauf der Arbeit nicht eingegangen wird. Diese Technologie erreicht ihre Sprachunabhängigkeit (beschränkt auf die vier Programmiersprachen Visual Basic, C#,J# und C++) durch das Interpretieren des Sourcecodes für die CLR (Microsoft Common Runtime Language) in Bytecode.

Diese Umgebung besteht aus den Hauptbestandteilen Framework, Tools, Building Sockets, Enterprise Server und Mobile Device, welche Daten im XML-Fomat austauschen. Das .NET Remoting (für den Zugriff auf verteilte Objekte) basiert auf dem allgemein verwendeten RPC/RMI-Mechanismus und stellt über ein Remoting-Framework Anwen-dungsdienste bereit, welche den Lebenszyklus und den Zugriff auf Sockets (Channels) regeln. Bei einer Verbindung zwischen zwei .NET-Komponenten wird die Verbindung über ein binäres Protokoll direkt auf der Basis von TCP/IP realisiert, während bei einer Verbindung zwischen einer .NET-Komponente und einer beliebigen anderen Komponente als weitere Abstraktionsschicht SOAP zum Einsatz kommt. Mit einer .NET Anwendung lassen sich also auch (eingeschränkte) Web-Services realisieren.^[7]

2.4 Kommunikation innerhalb verteilter Anwendungen

Für einen effizienten Informationsaustausch innerhalb einer verteilten Anwendung ist es notwendig, sich auf ein Nachrichtenformat zu einigen. In den meisten Fällen wird dies durch die verwendeten Produkte (Integrationsserver bzw. Middleware) oder Technologien vorgegeben. Ein Standard, der sich mittlerweile für den Nachrichtenaustausch durchgesetzt hat, ist das XML-Format (neben binärer Datenübertragung wie beispielsweise bei CORBA oder RMI).

Auch sollte eine Anwendung unbedingt über ein Repository als Definitionsverzeichnis für Nachrichten, Nachrichtenversionen und Formate implementiert werden. Die signifikante Bedeutung eines zentral verfügbaren Repositories wird im Verlauf der Thesis im Zusammenhang mit der Registrierung der Web-Services deutlich.

Kommunikationsarten werden in synchrone und asynchrone Kommunikation unterschieden. Synchrone Kommunikation bedeutet, dass der Nachrichtensender auf eine Bestätigung oder Antwort des Nachrichtenempfängers wartet. Bei dieser Art der Kommunikation besteht die Gefahr der Blockierung des Systems im Falle eines Nichtantwortens einer beteiligten Applikation. Dieses Risiko besteht nicht bei einer asynchronen Kommunikation, da der Nachrichtensender nach dem Versenden einer Nachricht weiterarbeitet und die Antwort des Nachrichtenempfängers (zunächst einmal aus der Sicht der reinen Kommunikation) ohne Vorgabe einer Zeitvorgabe gesendet wird.^[8]

3. Vertiefung SOA mit Web-Services

Eine Alternative zur Umsetzung einer dienstorientierten verteilten Anwendung auf Basis standardisierter Schnittstellenbeschreibungen ist der Einsatz von Web-Services. Das folgende Kapitel soll theoretische Grundlagen dienstorientierter Architekturen sowie Web-Services vermitteln.

3.1 Serviceorientierte Architektur

In der Literatur scheint gegenwärtig keine einheitliche Definition bezüglich greifbarer Vorstellungen einer SOA zu existieren. Mit anderen Worten, die Anforderungen an eine dienstorientierte Architektur können, bedingt durch die Betrachtung aus verschiedenen Perspektiven, unterschiedliche Schwerpunkte setzen. Dennoch ergibt sich eine abzeichnende Schnittmenge an Anforderungen, die im Folgenden vorgestellt werden soll.

Einleitend sollte der Grundgedanke einer SOA vertieft werden. Im Zentrum dieser Architektur stehen – stärker als in anderen Architekturmodellen verteilter Anwendungen - Dienste bzw. Services. Dieser Grundgedanke sollte sowohl fachliche sowie technische Umsetzungen zu der Einnahme einer zentralen dienstorientierten Perspektive zwingen. Das bedeutet primär, bestimmte Aufgaben bzw. Abläufe der psychologischen Fähigkeit möglicherweise effizienter arbeitender Experten zu überlassen (anstatt detailliert selbst zu implementieren - Outsourcing-Prinzip), ist gefragt. Die Schlussfolgerung daraus bedeutet für die Implementierung, dass Methoden der Dienste (Programm oder Softwarekomponente - siehe hierzu Kapitel 3.2) gekapselt werden und somit der nutzenden Applikation oder dem Nutzer verborgen bleiben. Wenn der Aspekt der starren Schnittstelle oder Fassade (und der maschinellen Beschreibung dieser) bei dem Konzept der Plug-ins außer Acht gelassen wird, ist es legitim, Plug-ins als eine Weiterentwicklung von einer dienstorientierten Architektur zu bezeichnen. Mit anderen Worten, das Konzept einer komponentenbasierten oder hinsichtlich ihrer Funktionalität „zusammensteckbaren“ Systemarchitektur wurde in Plug-in-Modulen bereits bedacht.

Bevor die Frage nach einer Technologie zur Umsetzung gestellt wird, ist es hilfreich, eine SOA zunächst als eine Abstraktion der Technologien zu begreifen. Eine Technologie, wie beispielsweise Web-Services (dynamischer Aufruf zur Laufzeit), ist folglich eine konkrete Umsetzung der Abstraktion. Grundlegende Komponenten einer SOA sind Kommunikation, Dienstbeschreibung und Verzeichnisdienst^[9].

3.1.1 Begriffsklärung und Definitionen SOA

Folgende Tabelle veranschaulicht einen Auszug der Vielfalt existierender Definitionen einer serviceorientierten Architektur:

Tabelle 1: Definition des Begriffs Serviceorientierte Architektur

Abbildung in dieser Leseprobe nicht enthalten

3.1.2 Merkmale und Funktionsweise SOA

Die Funktionsweise innerhalb einer SOA ist, abstrakt betrachtet, relativ einfach - Services sind für verschiedene Applikationen (lokal oder über ein Netzwerk) über eine servicespezifische Schnittstelle zugänglich, sprechen diese an und nutzen deren Funktionalität. Zu den Eigenschaften einer SOA zählen Plattformunabhängigkeit, Herstellerunabhängigkeit sowie leichte Zusammensetzbarkeit der Komponenten. Inwiefern eine Gesamtheit dieser Merkmale praktisch umsetzbar ist, bleibt fraglich.

Ein weiteres Merkmal ist die (im Zusammenhang mit Web-Services) in einem standardisierten XML-Format vorliegende Schnittstellenbeschreibung (im Gegensatz zu einer bisher benötigten speziellen API, wie beispielsweise bei RMI). Ein als Offener Standard erklärtes Format muss von allen betreffenden Beteiligten einer Applikation akzeptiert werden.

Durch die geschaffenen systemneutralen Zugänge zu einem Service werden wichtige Grundvoraussetzungen für eine verteilte Architektur geschaffen. Dies ermöglicht eine so genannte Lose Kopplung der SOA-Komponenten, d. h. durch das bei Bedarf dynamische Suchen, Finden und Nutzen beim Kompilieren nicht bekannter Services wird ein dynamisches Binden zur Laufzeit unterstützt. Die angesprochene Lose Kopplung wird in der Literatur oft als Problematik künstlicher Abhängigkeiten bezeichnet. Hiermit sind zusätzlich zu den realen Abhängigkeiten verschiedener Softwarekomponenten innerhalb einer Applikation künstlich geschaffene Abhängigkeiten gemeint. Diese gilt es durch Kapselung der Funktionalität auf ein Minimum zu reduzieren und so den Zustand einer losen Kopplung der Komponenten zu erreichen. Des Weiteren ist die Trennung von der Schnittstelle und Implementierung eines Dienstes einzuhalten, um Abhängigkeiten zu reduzieren und Folgeanpassungen der Implementierungen möglichst zu vermeiden (wie bereits erwähnt, handelt es sich hierbei um theoretische Merkmalsausprägungen – siehe hierzu Kapitel 5).

Analog dazu sei an dieser Stelle der geforderte Aspekt der Einfachheit des Technologiekonzepts erwähnt – eine leichte Verknüpfung sowie einfache Anwendbarkeit der zusammenspielenden Komponenten kann nur theoretisch belegt werden.

Eine SOA sollte prozessorientiert sein, mit anderen Worten, komplexe Dienste werden aus einer deklarativ definierten Folge von feingranularen Diensten zusammengesetzt (siehe hierzu Kapitel 5.10).

Eine weitere Eigenschaft ist die Berücksichtigung der Sicherheitsaspekte bei Realisierung einer SOA. Zu Sicherheitsaspekten zählen Autorisierung, Authentifizierung, Nachrichtenintegrität und Vertraulichkeit von Nachrichten (siehe hierzu Kapitel 5.13.2).

Wie bereits beschrieben, zählt zu den zentralen Elementen einer dienstorientierten Architektur ein Verzeichnisdienst (Repository/Registry). Dieser Verzeichnisdienst sollte nicht nur (wie üblich für CORBA oder RMI) eine Objektreferenz der Klassen bzw. Funktionalität sondern auch alle benötigten Parameter für die Implementierung der Funktionalität beinhalten (siehe hierzu Kapitel 5.12)^[12].

Folgende Grafik veranschaulicht noch einmal zusammenfassend die geforderten Merkmale einer dienstorientierten Architektur:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: SOA-Haus

Dabei stellen geforderte Eigenschaften wie Einfachheit, Akzeptanz, Sicherheit, Skalierbarkeit etc. ein solides Fundament einer dienstorientierten Architektur dar. Eigenschaften wie Prozessorientiertheit, die Verwendung von offenen Standards bezüglich der Kommunikation innerhalb einer verteilten Anwendung, systemneutrale Zugänge zu der angebotenen Funktionalität der Anwendung (lose Kopplung) sowie dynamische Zugriffe der verteilten Anwendungskomponenten bilden die Grundbausteine einer SOA. Darauf aufsetzend präsentieren die in einem Verzeichnisdienst befindlichen Dienstbeschreibungen die angebotene Funktionalität für Dienstnutzer nach außen. Die Implementierungsbeschreibungen sind die Zugangspunkte der Dienstnutzer für die Dienste.

3.2 Web-Services

Web-Services stellen eine mögliche konkrete Technologie zur Realisierung einer SOA dar. Das folgende Kapitel stellt Definitionen des Dienstbegriffes sowie Funktionsweise, Verzeichnisdienst, Beschreibungssprache und Protokolle der Web-Services vor.

3.2.1 Begriffsklärung und Definition Web-Services

Folgende Tabelle zeigt eine Auswahl an gegenwärtigen Definitionen einer Web-Service-Technologie, hieraus wird ersichtlich, wie die Schwerpunkte voneinander abweichen, wenn Autoren aus einem technischen oder betriebswirtschaftlichen Hintergrund kommen.

Tabelle 2: Definition des Begriffs Serviceorientierte Architektur

Abbildung in dieser Leseprobe nicht enthalten

3.2.2 Merkmale und Funktionsweise Web-Services

Hinsichtlich der Funktionsweise der Web-Services innerhalb teilnehmender Applikationen bildet das Finden, Binden sowie der Datenaustausch die drei gewichtigsten Bestandteile der Zusammenarbeit zwischen Client und Server ab.

Folgende Grafik veranschaulicht die drei teilnehmenden Rollen innerhalb einer Web-Service-Technologie - Service Client (Dienstnutzer), Service Server/Provider (Dienstanbieter) und Service Directory (Verzeichnisdienst).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Rollen einer Web-Services Technologie

Quelle: [Messer], S.5

Die Interaktion der beteiligten Rollen beinhaltet einen bestimmten Ablauf von Aktionen. Im ersten Schritt muss die Signatur des Dienstes veröffentlicht werden, um den Dienstnutzern verfügbar zu sein. Eine Veröffentlichung hat die Installation des Dienstes (in entsprechender Umgebung) als Grundvoraussetzung für den Eintrag und die Anmeldung des Dienstes in einem Dienstverzeichnis (Registry/Repository, siehe hierzu Kapitel 5.10). Die Aufgabe der Veröffentlichung des Dienstes übernimmt der Dienstanbieter bzw. Serviceserver. Somit wird der registrierte Dienst für andere Dienstnutzer (Serverclients) verfügbar, d. h. zunächst einmal such- und auffindbar. Die Suche des Dienstes wird üblicherweise von der Rolle des Dienstnutzers ausgeführt. Verzeichnis- bzw. Namensdienste, üblicherweise UDDI, verfügen über eine vorgegebene Schnittstelle über die Methoden zur Findung von Diensten (siehe hierzu Kapitel 5.10.2). Alternativ zu der Suche des Dienstnutzers können Verzeichnisdienste mittels WS-Inspection selbstständig nach Diensten suchen und diese registrieren^[13]. Im Falle von zusammengesetzten Diensten innerhalb eines Prozessablaufs (siehe hierzu Kapitel 5.11) ist eine explizite Suche der einzelnen Dienste nicht nötig. Im nächsten Schritt fragt der Dienstnutzer die Schnittstellenbeschreibung und die Voraussetzungen zur Nutzung dieses Dienstes (Zertifikate, Authentifizierung) ab. Schnittstellenbeschreibungen werden üblicherweise in einer WSDL-Datei gespeichert. Diese Dateien sind über einen Verzeichnisdienst verfügbar oder werden lokal (beispielsweise innerhalb des Intranets auf einem verfügbaren Dienstserver) abgelegt. Nach Erhalt der Dienstbeschreibung kann der Serviceclient bzw. Dienstnutzer eine Software erstellen, die mit dem Dienst interagiert.

Web-Services sind über einen URI (Uniform Resource Identifier) eindeutig identifizierbar.

Die Web-Service Architecture Working Group innerhalb des W3C Web gibt vor, für die direkte Interaktion der Services XML-basiertere Nachrichten zu verwenden. Dieser Kommunikationsaustausch findet über (internetbasierte) Protokolle wie HTTP, SMTP, FTP oder die Verwendung eines JMS (Java Message Service)statt. Dabei werden die Vorgaben hinsichtlich Nachrichten- oder Datenstrukturen, mit anderen Worten die Grammatik, in einem DTD (Data Type Definition) oder einem XML-Schema beschrieben.

Durch die Verwendung plattformunabhängiger sowie allgemeingültiger Standards wird ein weiteres Kriterium einer verteilten Architektur erfüllt - entfernte Methodenaufrufe beliebiger Plattformen werden dekodiert und an die entsprechende ausführende Komponente weitergeleitet. (FZ: implementierender Provider ist natürlich abhängig von Plattform und Umgebung)

Nichtfunktionale Anforderungen an Services, wie etwa Beschränkungen hinsichtlich der Antwortzeiten, Kosten der Nutzung sowie Verfügbarkeit werden in SLAs (Service Level Agreements) beschrieben (Verweis Kapitel 5.13.2)^[14].

3.2.3 Beschreibungssprache und Verzeichnisdienst der Web-Services

WSDL steht für Web Services Description Language und stellt eine XML-Grammatik zur Beschreibung von Diensten dar. Dabei beschreibt ein WSDL-Dokument die für einen syntaktisch korrekten Aufruf benötigten Informationen. Fachliche Informationen über den Dienst werden nicht innerhalb von WSDL-Dokumenten, sondern ausgelagert in einem Verzeichnisdienst beschrieben (siehe hierzu Kapitel 5.9 sowie 5.10).

Die Beschreibung der Funktionalität (Operation), der Kommunikationsmuster sowie der Schnittstellen zählt zu der abstrakten Beschreibungsebene eines WSDL-Dokuments. Auf der konkreten Ebene eines WSDL-Dokuments werden die erforderliche Bindung an einen Dienst, die Endpunkte eines Dienstes sowie die Parameter eines Dienstes detailliert für eine Implementierung beschrieben. Kapitel 5.9 behandelt den Beschreibungsprozess sowie die Abfrage der Dienstinformationen ausführlich. Wie gezeigt, wird innerhalb eines WSDL-Dokuments die Beschreibung der Funktionalität von den technischen Details getrennt, um so eine unabhängige Nutzung der Dienste und damit eine mögliche Wiederverwendbarkeit sicherzustellen. Der Zugriff auf die angebotene Funktionalität wird innerhalb der konkreten Definition der Schnittstelle beschrieben, mit anderen Worten, die Nachrichten, die gesendet und empfangen werden, sind die eigentlichen Beschreibungen des Dienstes, die für Dienstnutzer interessant sind.

UDDI steht für Universal Description, Discovery and Integration und wird von Dienstnutzern verwendet, um Services zu finden sowie von Dienstanbietern, um Services zu publizieren. Gegenwärtig ist UDDI in der Version 3.0 verfügbar und wird von OASIS standardisiert.

Wie bereits vorgestellt, stellt eine UDDI eine Verzeichnisstruktur für die Verwaltung von Metadaten der Dienste dar. Damit liefert UDDI eine semantische Beschreibung der Dienste (die in einer WSDL-Beschreibung fehlt). Registries können öffentlich, d. h. zuvor authentifizierte Nutzer können Services eintragen und jeder darf suchen, oder privat (beispielsweise nur verfügbar innerhalb des Firmenintranets) sein.

UDDI besitzt eine Informationsstruktur, die in White Pages, Yellow Pages und Green Pages unterteilt wird. Dabei stellen White Pages so genannte Business Enitities dar, die allgemeine Informationen des Dienstanbieters beinhalten (wie beispielsweise eine Liste von Anbietern mit deren Kontaktinformation und verfügbaren Services). Serviceleistungen werden fachlich innerhalb der Yellow Pages durch Business Services beschrieben (beispielsweise ein Zugriff auf Services bestimmter Art). Informationen bezüglich der technischen Implementierung der Services stellen die zu den Green Pages gehörenden Binding Templates bereit, beispielsweise durch Verweis auf Zusatzdokumente wie eine WSDL-Datei. Ein UDDI-Verzeichnisdienst stellt also WSDL-Dokumente bereit, bzw. Referenzen auf diese. Mit anderen Worten, um einen Service in einer UDDI-Registry zu publizieren oder zu suchen, muss der Service in einem WSDL-Dokument beschrieben sein. Kapitel 5.10 beschreibt den Aufbau eines UDDI-Verzeichnisdienstes im Zusammenhang mit WSDL-Dokumenten detailliert.

Der Zugriff auf die Verzeichnisdienste kann automatisiert über die von UDDI bereitgestellte Service-Schnittstelle oder per Hand über einen Web-Browser erfolgen. Der Verzeichnisdienst stellt im zweiten Fall wichtige UDDI-Funktionen wie Suche, Registrierung oder Login über eine Internetpräsenz bereit.

UDDI arbeitet eng mit SOAP-Protokollen zusammen, mit anderen Worten, UDDI-Objekte werden oft als SOAP-Nachricht verschickt.

Eine Alternative zu WSDL ist das bereits kurz (in Kapitel 3.2.2) angesprochene WS-Inspection-Modell. Dieses Modell bietet ein einfaches Konzept zum Auffinden von Diensten. Dabei arbeitet WS-Inspektion im Gegensatz zu UDDI mit vielen dezentralisierten Verzeichnissen und versucht so, die oft auftretende Unzuverlässigkeit der Suchergebnisse eines Clients zu vermeiden. Serviceprovider bieten auf ihrer Web-Site ein Dokument an, das die verfügbaren Dienste und dazugehörige WSDL-Beschreibungen enthält und für zukünftige Serviceclients mittels HTTP-Protokoll zu-greifbar ist.

Es gibt eine weitere Alternative zu WSDL – so zum Beispiel die ebenfalls XML-basierte Beschreibungssprache WADL. WADL steht für Web Application Description Language und beschreibt Dienste, die mit REST (siehe hierzu Kapitel 3.2.6) implementiert werden. REST-basierte Web-Anwendungen werden stark vereinfacht beschrieben und benötigen zudem keinen Verzeichnisdienst.

In den folgenden Unterkapiteln sollen nun drei verschiedene Möglichkeiten einer Web-Service-Implementierung vorgestellt werden^[15].

3.2.4 SOAP-Protokoll

SOAP steht für Simple Object Access Protocol und wurde im Jahr 2003 in der Spezifikationsversion 1.2 vom Web-Konsortium W3C verabschiedet. Das W3C (World Wide Web Consortium) ist ein von Wirtschaftsunternehmen weitestgehend unabhängiges Gremium, welches Standards zu den Themen XML, SOAP, WSDL und Web-Services definiert.

Dabei stellt SOAP eine Art Nachrichtendienst dar, der WSDL als Kommunikationsinterface nutzt. Dabei gibt SOAP das XML-basierte Nachrichtenformat der Kommunikation vor und beschreibt gleichzeitig die Einbettung der Nachrichten in ein Transportprotokoll. Mit anderen Worten, RPCs erhalten ihre Funktionsparameter über eine SOAP-Nachricht. Eine SOAP-Nachricht ist ein XML-Dokument. Analog dazu geben RPCs ihre Rückgabewerte über SOAP-Nachrichten zurück.

Eine SOAP-Nachricht besteht aus den folgenden drei Teilen:

- Envelope – stellt das Wurzelelement des XML-Dokuments dar und enthält die eigentliche Nachricht,
- Header – ist ein optionales, erstes Kindelement des Envelopes. Die Inhalte sind von der SOAP-Spezifikation nicht vorgegeben. Mögliche Inhalte sind sicherheitsrelevante Informationen (Authentifizierung) oder Adressieren von Zwischenstationen der Nachricht (Routing). Ein Header enthält somit detaillierte Informationen der Adressaten sowie der Reihenfolge, wie eine SOAP-XML-Datei abzuarbeiten ist, d. h. der Header definiert einen Workflow für das SOAP-XML-Dokument. Des Weiteren können im Header Mechanismen zur Fehleridentifikation platziert werden, wie beispielsweise mustUnderstand bezüglich der Auswertbarkeit der Nachricht mit Rückgabewerten true oder false,
- Body- ist das zweite Kindelement des Envelopes und der Inhalt des Bodys variiert anwendungsbezogen. Hier werden die eigentlichen Nutzdaten (payload) einer Nachricht übertragen. Hier müssen zwar keine XML-Namensräume streng eingehalten werden, aber eine Einigung zwischen den Kommunikationspartnern bezüglich der Inhaltsstruktur einer Nachricht stattfinden, d. h. SOAP macht keine Aussagen zur Interpretation der XML–Dokumente, aber RPCs selbst geben einen Standard vor, wie Aufrufe von Methoden auf anderen System stattfinden sollen. Ein RPC-Aufruf kann aus den drei Kommunikationsarten Request (clientseitiger Aufruf einer Service-Methode mit Übergabe der Parameter in richtiger Reihenfolge), Response (serverseitige fehlerfreie Antwort einer Servi-ce-Methode mit Übergabe der Ergebnisse) und Fault (Fehlermeldung an einer Stelle des RPC-Aufrufs wird an Client zur Fehlerbehandlung weitergegeben) bestehen.

Folgendes Codebeispiel zeigt noch einmal den schematischen Aufbau einer SOAP-Nachricht:

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“>

<soapenv:Header></soapenv:Header>

<soapenv:Body></soapenv:Body>

</soapenv:Envelope>

Listing 1: Schematischer Aufbau einer SOAP-Nachricht

SOAP erlaubt einen beliebigen Austausch von XML-Dokumenten, wie beispielsweise von HTML-Seiten, PDF-Dokumenten, Formularen oder Verträgen und unterstützt 40 elementare Datentypen.

SOAP definiert spezielle Bindings für die Protokolle HTTP und SMTP, erlaubt aber gleichzeitig nahezu beliebige Bindings an andere Protokolle (FTP, JMS, RMI etc), d. h. SOAP ist nicht an ein Transportprotokoll gebunden.

Eine Kommunikation mittels SOAP kann synchron sowie asynchron implementiert werden (siehe hierzu Kapitel 5.6.4 des praktischen Teils).

3.2.5 XML-RPC Protokoll

XML-RPC ist ein Protokoll, das entfernte Methodenaufrufe mittels XML-Nachrichten unterstützt. Die Kommunikation erfolgt synchron und ist an das Transportprotokoll HTTP gebunden. Daraus ergeben sich viele Vorteile gegenüber nachrichtenbasierter Middleware hinsichtlich einer Plattformunabhängigkeit.

Im Gegensatz zu SOAP ist das XML-RPC-Protokoll unkomplizierter, da es kürzere Elementnamen verwendet und auf XML-Namensräume verzichtet.

XML-RPC-Nachrichten bestehen aus zwei Textblöcken; der erste Block definiert Pflichtfelder bezüglich eines Formats (Content-Type) und einer Länge (Content-Length) der Nutzdaten (ähnlich wie in SOAP), der zweite Block enthält die den RPC-Aufruf beschreibende XML-Syntax.

Wie folgendes Code-Beispiel zeigt, besteht ein XML-RPC-Dokument aus einem Pflichtelement methodCall, welches den Namen (methodName) und die dazugehörigen Parameter (params) der aufzurufenden Methode angibt:

POST /RPC2 HTTP/1.1

Host: Wetterserver.de

User-Agent: Telnet/1.0

Content-Type: text/xml

Content-lengh: nnn

<?xml version=“1.0“ ?>

<methodCall>

<methodName>wetterReport.getTemperaturByZip</methodName>

<params>

<param>

<value><int>4711</value></int>

</param>

</params>

</methodCall>

Listing 2: XML-RPC Dokument

Die Antwortnachricht eines Servers gibt analog zur Anfrage eine Nachricht zurück, die aus einem Element der Methode methodResponse und deren Kindelementen params besteht.

Vergleichbar mit der Fehlermeldung von SOAP im Fall eines Kommunikationsfehlers, definiert XML-RPC ein Fault-Element zur Anzeige des Fehlers innerhalb eines Methodenaufrufs.

XML-RPC unterstützt sechs elementare Datentypen (String, int, double, boolean, ISO8601 Datumsangaben und BASE64-kodierte Binärwerte) sowie zwei komplexe Datentypen (Structs).

XML-RPC kann ebenso wie SOAP die Beschreibungssprache WSDL unterstützen und damit einen Verzeichnisdienst wie UDDI nutzen.

3.2.6 REST Protokoll

REST steht für Representational State Transfer und wurde von Roy Fielding im Jahr 2000 in einer Dissertation entwickelt. REST definiert im Gegensatz zu SOAP oder XML-RPC kein Protokoll, sondern einen Architekturstil für den Einsatz existierender Web-Protokolle. Der Schwerpunkt dieser Architektur liegt auf der Interaktion von zustandsbehafteten Ressourcen, d. h. der Client ändert seinen Zustand, indem er einer URL (in einer Repräsentation der URL) folgt.

Anwendungen, die diesem Architekturstil entsprechen, werden als RESTful bezeichnet. Dabei wird das Interface auf eine Menge definierter, an HTTP angelehnte Standard-Methoden (GET, POST, PUT, DELETE) beschränkt. Innerhalb des REST-Architekturstils können Web-Services über einen Link auf beliebigen Web-Sites repräsentiert werden (nicht möglich für SOAP und XML-RPC). Ein Serviceanbieter kann seine Funktionen über die GET-Methode zugreifbar machen.

Anstatt der Verwendung eines XML-Dokuments, wird bei REST zur Anfrage eine URL mittels einer HTTP-Methode an den Server übermittelt. Der Server liefert eine Repräsentation einer Ressource als Antwort. Dabei wird das Rückgabe-Format nicht festgelegt, mit anderen Worten, REST definiert keine speziellen Datentypen oder Elementnamen. Das bedeutet einen höheren Verarbeitungsaufwand für serverseitig gelieferte Daten, die hinsichtlich ihrer Struktur mittels entwickelter Methoden, Skripte oder XML-Stylesheets in eine HTML-Seite transformiert werden müssen.

Wie bereits erwähnt, nutzt REST die XML-basierte Sprache WADL (vgl. hierzu 3.2.3) zur Beschreibung der Dienste. Ein Verzeichnisdienst ist bisher nicht bekannt, Anbieter wie amazon.com stellen ihre Dienste über Web-Sites wie
amazon.com/webservices bereit.^[16]

[...]

---

^[1] Vgl. [Channabasavaiah/ibm 2003 ], [Möller 2006] S.35ff, [jeckele.de], [service-architecture.com],[Melzer,Dostal,Jeckle,Zengler 2005]

^[2] [Müller 2005], S.5, S.35ff, [Fletcher/Waterhouse], S.42ff.

^[3] [Müller 2005],S.53 ff., [Arier/Schönherr],S.6

^[4] [Melzer,Dostal,Jeckle,Zengler 2005], S.37 ff, [Downdeswell/Lutteroth 2005],S.57 ff

^[5] Vgl. [informatik.uni-tuebingen],[galileocomputing.de],[Chapell/Jewell],S.193ff.,[Topley],S.447

^[6] [Channabasavaiah/ibm 2003 ], [Müller 2005],S. 71 ff.

^[7] Vgl [Fletcher/Waterhouse]S.47 , [Müller 2005],S.75 ff.

^[8] [Müller 2005],S. 45 ff.

^[9] Vgl.[Melzer,Dostal,Jeckle,Zengler 2005],S.27ff., [Hae Ho 2003]

^[10] Vgl. [Melzer,Dostal,Jeckle,Zengler 2005],S.7

^[11] CIO der Deutschen Post, SOA-Pionier

^[12] Vgl. [Melzer,Dostal,Jeckle,Zengler 2005], S.8 ff., [jeckle],[Messer], S.5ff.,[Hao He 2003]

^[13] Dieser Mechanismus wird von IBM und Microsoft stark vorangetrieben, ist aber noch nicht standardisiert

^[14] [Benatallah 2005] S.33 ff., [Melzer,Dostal,Jeckle,Zengler 2005],S.13/17 ff, [Messer 2]S.5ff., [Eberhart,Fischer 2003], S.71ff, [Fröschle 2003], S.5

^[15] vgl. [ibm/Zimmermann 2004],[Eberhart/Fischer 2003], S.301ff., [Melzer], S.78ff., http://uddi.org

^[16] Vgl. [Melzer,Dostal,Jeckle,Zengler 2005],S.67ff., [oio.de],[ ics.uci.edu/~fielding]