Serviceorientierte Architekturen - SOA

Transkript

1 Serviceorientierte Architekturen - SOA Benjamin Vikum 5. Juli

2 Inhaltsverzeichnis 1 Einleitung 3 2 Begriffsdefinitionen SOA (Serviceorientierte Architekturen) Dienste Webservices Einordnung von Diensten 4 4 Beispiel- Geschäftsprozess 5 5 SOA - Dreieck 6 6 SOA und ihre Implementierungen SOA und Webservices SOA, CORBA und weitere Technologien SOA anhand von Webservices Publish Web Service Description Language Find UDDI (Universal Description, Discovery and Integration) Datenstruktur von UDDI Bind SOAP (Simple Object Access Protocol) Orchestrierung mit WS-BPEL 11 9 Fazit 13 2

3 1 Einleitung In der heutigen IT-Welt ändern sich Gegebenheiten, und Strukturen sehr schnell. Gerade kleine Unternehmen haben es schwer sich in dieser großen IT-Welt zurechtzufinden und sich dem wachsendem Markt anzupassen um den großen in nichts nachzustehen, konkurrenzfähig zu bleiben und zu sein. Beispielsweise ist es bei der Herstellung von Software wichtig, sie möglichst Modular zu halten, um diese dann gegebenenfalls um weitere Softwarefragmente, welche möglicherweise von anderen Firmen angeboten werden, zu erweitern. Diese Angebotenen Funktionalitäten, welche sich das Unternehmen zu nutze machen will, müssen natürlich auch erst einmal gefunden werden. Weis man, wo sie ist, muss man sie nur noch erreichen. Hier gibt es im heutigen IT-Markt keine grundlegenden Standardisierungen. Die eine Lösung wird beispielsweise nur von proprietären Protokollen unterstützt, die andere ist plattformgebunden (RMI). In dieser Ausarbeitung befasse ich mich mit dem Thema Serviceorientierte Architekturen (SOA), welche den ganzen Zyklus des Anbieten, Finden und Ausführen von Funktionalitäten als einheitliches Ganzes darstellen. Später werde ich genauer auf SOA anhand von Webservices eingehen. 2 Begriffsdefinitionen 2.1 SOA (Serviceorientierte Architekturen) Zu aller erst ist zu sagen, dass es bis heute noch keine einheitliche Definition über den Begriff SOA gibt. Ich zitiere an dieser Stelle Herrn Dr. Ulf Rerrer-Brusch (2007). Serviceorientierte Architektur (SOA) ist eine Anwendungsarchitektur, in der alle Funktionen als unabhängige Services mit wohldefinierten, aufrufbaren Schnittstellen vorliegen, so dass eine Auswahl - in einer sinnvollen Reihenfolge aufgerufen - einen Geschäftsprozess abdecken. [RB] Anhand dieser Definition können wir sehen, dass sich SOA lediglich um einen Architekturstil handelt. Denn viele Leute bringen den Begriff SOA sehr nahe mit den Webservices in Verbindung bzw. können nicht richtig zwischen ihnen unterscheiden. Hierbei muss aber ganz klar unterschieden werden, denn Webservices stelle nur eine Möglichkeit dar, SOAs aufzubauen und zu nutzen. 2.2 Dienste In dieser Definition verwendet Brush den Begriff Service als wesentlichen Bestandteil einer SOA. Dienste (Services) in einer SOA haben auch spezielle Richtlinien: Dienste sind in sich abgeschlossen Dienste können eigenständig genutzt werden Dienste sind in einem Netzwerk verfügbar Dienste müssen eine veröffentlichte Schnittstelle haben Dienste müssen Pattformunabhängig sein ( Anbieter und Nutzer können unterschiedliche Betriebssysteme nutzen und unterschiedliche Sprachen in ihren Programmen ) Dienste müssen in einem Verzeichnis registriert sein 3

4 Dienste werden erst dynamisch bei der Ausführung gebunden Im dienste einer SOA sollten die verwendeten Dienste alle diese Richtlinien erfüllen. Es ist natürlich immer noch abhängig in welcher Technologie man diese SOA aufbaut. Hier kann es beispielsweise passieren, dass die eine oder andere Eigenschaft, die wir von einem Dienst erwarten nicht zu 100% erfüllen können. Beispielsweise die Plattformunabhängigkeit mit JAVA RMI. 2.3 Webservices Im Teil 7 werde ich SOA anhand von Webservices erläutern. Um eine einheitliche Vorstellung von Webservices zu haben werde ich den Begriff kurz anhand der Definition, welche wir auf w3.org finden erläutern. A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machineprocessable 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 Webrelated standards. [w308a] Kurz gesagt bieten uns Webservices eine standardisierte direkte Interaktion mit anderer Software unter der Verwendung von XML basierten Nachrichten. Der Transport selbst erfolgt über das HTTP-Protokoll. Zur Kommunikation wird SOAP als Protokoll genutzt. Die Schnittstellen, welche wir ansprechen müssen um mit dem Webservice kommunizieren zu können sind in einer WSDL - Datei spezifiziert, auf welche ich später noch genau eingehen werde. Das heißt, durch diese Beschreibung wissen wir genau, wie wir die Dienste ansprechen können. 3 Einordnung von Diensten Nun stellt sich die Frage, an welcher Stelle sich die Dienste einordnen lassen. Dies lässt sich anhand der Abbildung 1 gut erklären. Auf der Linken Seite finden wir das Application Layer. Dies stellt unsere eigentliche Applikation dar, beispielsweise ein Java Programm. Von dieser Applikation wird ein Prozess gestartet, welcher im Business Process Layer zu finden ist. Hier ist die eigentliche Programmlogik zu finden. Wenn wir jetzt mal bei einem kleinen Java Programm bleiben, werden hier Objekte erzeugt, Methoden aufgerufen etc.. Auch die Interaktion mit Prozessen von anderen Applikationen ist möglich (beispielsweise über Sockets), wie der Grafik zu entnehmen ist. Nehmen wir an, unser Java Programm soll uns Information darüber liefern, welche Hotels auf Mallorca noch zur Verfügung stehen. So wird nun, um dies herauszufinden möglicherweise ein Webservice genutzt. Im Service Layer sind nun diese Dienste, welche wir nutzen möchten zu finden. Sie befinden sich vor dem Component Layer, die über die nötigen Informationen verfügt, mit denen wir arbeiten wollen. Die Datenhaltung im Komponenten Layer könnte in EJB realisiert sein. Tatsache ist jedoch, dass es den Prozess nicht interessiert, wie das Komponenten Layer aussieht. Der Prozess bedient lediglich die Schnittstelle, den Service, um an die Daten heranzukommen. Wie man der Grafik ebenfalls entnehmen kann, gibt es auch Dienste, 4

5 Abbildung 1: Layers welche selbst andere Dienste nutzen. Ein mögliches Beispiel wäre die Buchung einer Reise, welche sich um die Buchung eines Hotels und die eines Mietwagens kümmern muss. 4 Beispiel- Geschäftsprozess Schauen wir uns nun einmal einen Geschäftsprozess, wie wir ihn in der SOA Definition gefunden haben, etwas genauer an einem Beispiel an. In Abbildung 2 geht es um eine Bestellung beim Onlineshop Amazon. Bevor wir die Bestellung abgeben können, müssen wir uns natürlich ins Shopsystem einloggen und unsere gewünschten Artikel auswählen. Geben wir die Bestellung ab, so beginnt der Geschäftsprozess von Amazon. Die Pfeile, die man in der Prozessgrafik zwischen den grauen Kästen findet sind Abhängigkeiten. Ähnlich zu vergleichen wie, wenn wir einen Hauptprozess in einem Programm haben und dort mehrere Threads starten, welche parallel arbeiten können, aber sie zu bestimmten Zeitpunkten wieder joinen - fertig werden mit der Bearbeitung - müssen, damit der eigentliche Prozess weiter fortgesetzt werden kann. Die Elemente in dem Prozess mit Ausnahme von OK? sind alle als separate Dienste zu verstehen. Sobald die Bestellung abgegeben wurde, kann die Verfügbarkeitsprüfung der bestellten Artikel beginnen. Unabhängig davon, kann zur gleichen Zeit die Bonitätsprüfung des Kunden durchgeführt werden. Für die nächsten Schritte im Geschäftsprozess ist es notwendig, dass die Verfügbarkeitsprüfung, sowie die Bonitätsprüfung erfolgreich abliefen. Ist dies der Fall, so kann mit der Kommissionierung der Artikel begonnen werden. Wieder unabhängig von der Kommissionierung, kann die Rechnungsstellung angestoßen werden. Der Versand und der Zahlungseingang sind jedoch wieder abhängig von ihrem jeweiligen Vorgänger. Dies ist ein typischer Geschäftsprozess, welchen wir sehr oft in der Wirtschaft vorfinden. Solche Prozesse lassen sich sehr gut mit einer SOA verwirklichen. Nehmen wir uns beispielsweise die Bonitätsprüfung heraus. Sie kann möglicherweise durch Dienste einer Bank realisiert werden. Ändern sich Gegebenheiten im 5

6 Abbildung 2: Geschäftsprozess (Bestellung bei Amazon) Unternehmen, welche es erfordern nun von einer anderen Bank diese Prüfung vornehmen zu lassen, ist es kein größeres Problem im Geschäftsprozess einfach diesen einen Dienst auszuwechseln. Der Rest des Prozesses funktioniert nach wie vor. Dies ist ein sehr schönes Beispiel, wie SOAs auf die wirtschaftlichen Änderungen sehr effizient reagieren können. 5 SOA - Dreieck Wenn man bei SOA von einer Architektur spricht, ist es natürlich wichtig, die Bestandteile dieser Architektur zu kennen. Diese werde ich anhand des so genannten SOA - Dreiecks (Abbildung 3) erläutern. Die drei Bestandteile der Architektur sind der Service Provider, Broker und Consumer. Der Service Provider stellt den Teil der Architektur dar, welcher uns den Dienst bereitstellt. Der Service Consumer, welcher den Dienst des Providers in Anspruch nehmen möchte, weis in erster Linie nicht, wo er diesen Dienst finden kann, speziell wenn es ein Unternehmen ist, dass er nicht kennt. Hier kommt der Service Broker ins Spiel. Bei ihm registriert der Provider seinen Dienst und hinterlegt dort Informationen zu seinem Dienst ( Beschreibung des Dienstes, wie und wo er den Dienst erreicht ). Als Service Consumer kann man dann in diesem Verzeichnis nachfragen, welche Dienste zur Verfügung stehen und sich dort die nötigen Informationen für die Verbindung des Dienstes holen. 6 SOA und ihre Implementierungen 6.1 SOA und Webservices Serviceorientierte Architekturen werden meist im Zusammenhang mit Webservices erwähnt. Aber warum? Webservices bauen auf dem etablierten Transportprotokoll HTTP auf. Sie bringen somit recht wenige Probleme im Bereich der Interoperabilität mit sich. Firewalls 6

7 Abbildung 3: SOA - Dreieck müssen nicht speziell konfiguriert werde, da der Standardport 80 verwendet wird. Des Weiteren erfüllen sie die wichtigsten Merkmale, welche wir von einem Dienst erwarten. Er ist lose gekoppelt und kann separat genutzt werden. Sie bieten mit der WSDL (Web Service Description Language) - auf welche ich später noch genauer eingehen werde - eine standardisierte Schnittstellenbeschreibung. Anhand dieser Tatsachen lässt sich ableiten, dass Webservices hervorragend für die Implementierung einer SOA geeignet sind. Mit Vorsicht ist jedoch zu beachten, dass nicht das alleinige Verwenden von Webservices zu einer SOA führt (beachte Definition 2.1). 6.2 SOA, CORBA und weitere Technologien Warum sollte man nicht CORBA als Technologie für die Erstellung einer SOA nutzen? Wir können in CORBA problemlos einen Service-Provider, - Requestor, - Broker realisieren. Ebenso gibt es die IDL (Interface Description Language), welche der WSDL ebenbürtig ist. Auch ein Verzeichnis für die Dienste könnte sich mit dem Interface Repository, dass uns CORBA bietet anbieten. Es waren vielmehr viele kleine Gründe, die CORBA daran hinderten wirklich beliebt für die Implementierung einer SOA zu werden. So war zum einen ein Knackpunkt das frühere Protokoll IIOP, welches es erforderte die Firewall ein wenig anzupassen um die Kommunikation zu ermöglichen. Gerade wenn Dienste von anderen Unternehmen genutzt werden wollten, gab es viele Konfigurationsprobleme. Hinzu kam, dass früher der Basic Object Adapter nicht ausreichend spezifiziert war. Hier entstanden meist herstellerspezifische Implementierungen, die die Kooperation mit dem Partner doch erschwerte. Diese Nachteile wurden erkannt und man hat in CORBA auch stark nachgebessert. Nichts desto trotz, lässt sich in CORBA problemlos eine SOA aufbauen. Gerade wenn die Kommunikation innerhalb eines Unternehmens bleibt, wird vermehrt wert auf CORBA anstatt von Webservices gelegt, da die Kommunikation in CORBA doch um einiges performanter ist. Sobald jedoch Interoperabilität gefragt ist, wird in der Industrie in den meisten fällen doch lieber zu den Webservices gegriffen. Zu guter letzt möchte ich noch einen kleinen überblick über die Vor- und Nachteile von anderen Technologien im Vergleich aufzeigen (Abbildung 4). Hier kann man auch sehr gut die Nachteile der unzureichenden Standardisierung in CORBA sehen. 7

8 Abbildung 4: Technologien für SOAs 7 SOA anhand von Webservices In diesem Teil der Ausarbeitung werde ich genauer darauf eingehen, wie sich eine SOA mit Hilfe von Webservices realisieren lässt. In Abbildung 5 können wir das SOA Dreieck sehen, welches auf die Webservicetechnologie angepasst wurde. 7.1 Publish Stellen wir uns vor, wir haben jetzt einen Webservice implementiert. Wir wollen ihn der Öffentlichkeit zur Verfügung stellen. Bloß wie machen wir das? Wir registrieren den Dienst in einem Verzeichnis, das der Öffentlichkeit als zentralen Anhaltspunkt dient. Auf das Verzeichnis werde ich später noch genauer eingehen. In diesem Verzeichnis müssen wir nun alle nötigen Informationen für unseren Dienst hinterlegen. Dies geschieht mit einer WSDL - Datei Web Service Description Language Die WSDL ist XML basiert und bietet uns die Möglichkeit unseren Webservice standardisiert zu beschreiben. Sie enthält alle nötigen Informationen, um den Dienst zu nutzen. Folgende Tags beschreiben die WSDL - Datei: types (Definition der Datentypen, welche im message-tag genutzt werden) message (beschreibt den Aufbau der Nachrichten) porttype (angebotene Funktionen mit ihren Eingabe und Rückgabewerten) binding (Protokoll und Datenformat der Funktionalitäten wird festgelegt) port (gibt die Adresse (meist URI) für eine Bindung an) service (fasst miteinander verwandte Ports zusammen) 8

9 Abbildung 5: SOA - Dreieck auf WS angepasst WSDL Dateien selbst müssen nicht von hand geschrieben werden. Es gibt Tools, die diese automatisch aus einem Service generieren können. Meistens jedoch werden sie automatisch vom Server erzeugt, wenn man einen Webservice deployed. 7.2 Find Wie in 7.1 erwähnt, werden die Dienste in einem Verzeichnis registriert, worin man nach ihnen suchen kann. Üblicherweise ist dieses ein UDDI - Verzeichnis UDDI (Universal Description, Discovery and Integration) UDDI stellt ein Verzeichnis dar, in dem Nutzer nach angebotenen Diensten, beispielsweise nach Schlagwörtern, suchen können. Dort werden unter anderem die WSDL - Dateien zu den angebotenen Diensten verwahrt. In der UDDI werden die Informationen von Anbieter und Service in drei Kategorien unterteilt: White Pages: Namensregister Informationen über Serviceanbieter Kontaktinformationen Yellow Pages: Branchenverzeichnis Suche nach diversen Argumenten (Ort des Dienstes, Art des Dienstes etc.) Verweise auf White Pages Klassifizierung von Services nach Standards (mit UNSPSC) 9

10 Abbildung 6: UDDI - Datenstruktur Green Pages: Geschäftsmodelle der Serviceanbieter Technische Information zum Webservice (WSDL Datei) Geschäftsprozesse der Serviceanbieter UDDI wurde schon als großes öffentliches Register implementiert. Große Konzerne wie Microsoft, IBM, SUN und SAP entwickelten ein UBR (UDDI Business Register), welches ca. 5 Jahre im Rahmen eines Projekts lief. Zu der Zeit waren über Services dort registriert. Das UBR wurde jedoch wieder abgeschaltet, als das Projekt vorbei war Datenstruktur von UDDI Die Datenstruktur der UDDI ist in vier größere Teile getrennt, was wir in Abbildung 6 sehen können. In der businessentity werden Informationen über den Anbieter des Service gehalten (Name, Beschreibung). Dieser kann auf mehrere Dienste verweisen, die im Teil business- Service vorgehalten werden. Dort sind Metadaten (Name, Beschreibung) über den Dienst festgehalten. Der businessservice kann nun auch wiederum auf mehrere bindingtemplates verweisen. Hier findet man technische Informationen die nötig sind um Verbindung mit dem Service aufzubauen (Port etc.). Um die eigentliche Kommunikation mit dem Dienst zu ermöglichen werden weitere technische Informationen, wie z.b. Funktionsnamen oder Parameter im tmodel festgehalten, auf welches ein bindingtemplate verweist. Wie der Grafik zu entnehmen ist, verweisen das bindingtemplate und das tmodel auf die jeweils dafür zuständigen stellen in der für den Service hinterlegten WSDL - Datei. 10

11 7.3 Bind Wir haben nun unseren Service im Verzeichnis gefunden und wissen auch wo er sich befindet und können ihn nun nutzen. Die Kommunikation mit dem Webservice erfolgt über das SOAP Protokoll SOAP (Simple Object Access Protocol) Mit Hilfe des Netzwerkprotokolls SOAP können wir mit einem Webservice auf entfernten Webservern kommunizieren. Die Abkürzung wird heutzutage nur noch als reines Akronym verwendet, da sich der Datenaustausch nicht mehr nur rein auf Objekte bezieht. Eine SOAP Nachricht lässt sich in 3 Teile untergliedern: Envelope Der Envelope ist der so genannte Umschlag. Er dient als Container für die Anfrage und die Antwort. Er kann unter anderem optional Angaben zur Codierung der Nachricht enthalten. Im Envelope enthalten sind Header und Body. Header Der Header ist optional und kann Angaben wie Athentifizierugen (Login,Passwort) oder Routing enthalten Body Der Body stellt die eigentliche Nachricht dar, die übermittel werden soll. Folgender Code stellt den Body einer SOAP Nachricht dar. In dem Code-Beispiel ist zu sehen, wie eine Suchanfrage an die Suchmaschine Google geschickt wird. Die Methode, welche aufgerufen wird, heißt dogooglesearch (Zeile 2). Darauf folgen nun Hinweise, wie die Daten zu decodieren sind (hier: XML-Schema) und die Bedienung der einzelnen Parameter, welche die Methode zu Verfügung stellt. Im key -Tag, der unseren Suchstring darstellt, können wir sehen, dass der zu übergebende Parameter vom Typ String ist (hier: abcd ). Weiterhin gibt es den Parameter maxresults vom Typ Integer, der die maximale Anzahl an Ergebnissen einschränken kann (hier: 10). <SOAP-ENV:Body> <m:dogooglesearch xmlns:m="urn:googlesearch" <SOAP-ENV:encodingStyle= <key xsi:type="xsd:string">abcd</key> <maxresults xsi:type="xsd:int">10</maxresults> <filter xsi:type="xsd:boolean">1</filter> </m:dogooglesearch> </SOAP-ENV:Body> 8 Orchestrierung mit WS-BPEL Was nützen uns nun die einzelnen Dienste, wenn man sie doch kombinieren könnte um etwas Komplexeres herzustellen? WS - BPEL gibt uns die Möglichkeit Webservices zu orchestrieren. Orchestrieren bedeutet, dass wir bestehende Webservices so kombinieren, dass sie zusammen einen Geschäftsprozess wie unter Kapitel 3 darstellen. Man definiert sich in der Orchestrierung 11

12 das Zusammenspiel der einzelnen Dienste, wann welcher Dienst in Abhängigkeit von einem anderen Dienst aufgerufen wird. Nicht nur sequenzielle, auch parallele Workflows werden hiermit festgelegt. BPEL ist die Busines Process Execution Language, welche in der aktuellen Version 2.0 von OASIS standardisiert ist. BPEL ist eine XML basierte Sprache mit typischen Schlüsselworten, wie wir sie auch aus anderen imperativen Programmiersprachen kennen. assign - Variable ändern invoke - Aufruf eines Web Service receive/reply - Anbieten einer synchronen oder asynchronen Web Service Schnittstelle throw - Fehler werfen wait - Warten auf Zeitpunkt oder für Zeitspanne empty - Nichts tun Strukturelemente sequence - sequenzieller Prozessbereich while - genauso wie in JAVA switch - genauso wie in JAVA flow - paralleler Prozessbereich pick - nichtdeterministische Auswahl Ein BPEL Programm könnte beispielsweise wie folgt aussehen: <process name="purchaseorderprocess"> <variables> <variable name="po" messagetype="pomessage"/>... </variables> <faulthandlers> <catch faultname="cannotcompleteorder" faultvariable="pofault"> <reply </catch> </faulthandlers>!!! --> EIGENTLICHER PROZESS <--!!! </process> partner="customer" porttype="purchaseorderpt" operation="sendpurchaseorder" variable="pofault" faultname="cannotcompleteorder"/> Innerhalb des Prozesses (gekennzeichnet durch das process-tag) werden zuerst verschiedene Sachen wie Variablen oder Fehlerbehandlungsroutinen festgelegt. Im Beispiel sind genau diese zu sehen. Es werden weiterhin die nötigen Schnittestellen definiert (z.b. Webservices oder der Aufrufer des Prozesses), über welche wir kommunizieren. Im Code-Beispiel sehen wir im Tag faulthandlers eine Fehlerbehandlungsroutine, die ausgeführt wird, wenn aus irgendeinem Grund der Bestellprozess nicht abgeschlossen werden kann. Im reply-tag wird dann der customer - der Aufrufer - über den Fehler informiert, dass seine Bestellung fehlgeschlagen ist. Nachdem alle nötigen werte Gesetzt wurden, können wir den eigentlichen Prozess spezifizieren. In Abbildung 7 können wir einen Ansatz eines solchen Prozesses gut erkennen. 12

13 Abbildung 7: BPEL - Prozess Wir können sehen, dass der receive-tag der Eintrittspunkt in den Prozess darstellt. Dies geschieht, wie der Grafik zu entnehmen ist, wenn die Bestellung abgeschickt wird und vom System bearbeitet werden muss. Wir können sehen, dass der Eigentliche Prozess von dem Strukturelement sequence umschlossen ist, was bedeutet, dass die Bearbeitung des Prozesses von außen gesehen nacheinander erfolgen muss. Dies ist nur sehr logisch, da es unsinnig wäre, im gleichen Moment, wo wir einen Aufruf im receive-tag festellen, eine Antwort im reply- Tag zu versenden. Innerhalb des Prozesses, kann es jedoch möglich sein, dass wir einzelne Dienste parallel laufen lassen können, weil sie unabhängig von einander sind. Dies wird mit dem flow-tag gekennzeichnet. 9 Fazit Serviceorientierte Architekturen bieten einem Unternehmen in der heutigen IT-Welt sicher viele Vorteile. Sie können sich sehr viel Implementierungsarbeit sparen, wenn sie auf vorhandene Services zurückgreifen, anstatt sie selbst zu implementieren. Hier könnte, gerade bei jungen Unternehmen häufig Kosten gesenkt werden. Am Anfang habe ich erwähnt, dass es nötig ist, sich auf gegebene Änderungen schnell einzustellen. Dies ist dank des Architekturstils leicht zu verwirklichen, da die einzelnen Bestandteile, wenn sie auf Dienste zurückgreifen, sehr leicht auszutauschen sind ohne den restlichen Prozess zu beeinflussen. Gerade wenn man sich für die Webservice-Technologie entscheidet wird man schnell Erfolge sehen, denn diese werden momentan sehr stark von der Industrie angenommen und unterstützt, wohl nicht zuletzt dank ihrer guten Standardisierung und Plattformunabhängigkeit im Sinne des Betriebssystems und der Implementierungssprache. Jedoch bringt eine Serviceorientierte Architektur nicht nur Vorteile, sondern auch Nachteile. Speziell bei Webservices ist die Performance meist nicht die Beste. Hier schneiden andere Technologien wie CORBA besser ab. Auch der Aspekt der Qualitätssicherung hat zwei Seiten. Einerseits könnte man sich sicher sein, wenn man be- 13

14 reits implementierte Dienste verwendet, dass diese fehlerfrei sind und man nicht selber Fehler begehen kann. Andererseits wissen wir nicht, ob der Qualitätsanspruch, welchen wir an den Dienst stellen, erfüllt ist. Wer versichert uns, dass die Daten, die wir bekommen, auch gültig sind? Mit Vorsicht ist jedoch genießen, wenn Firmen damit werben, dass sie mit einer SOA arbeiten. Die SOA im eigentlichen Sinne erfordert laut dem Architekturmodell ein UDDI Verzeichnis. Gerade dieses wird in der Öffentlichkeit nicht mehr unterstützt und auch nicht in vielen Unternehmen, zumindest im kleinen Rahmen, aufgesetzt. 14

15 Literatur [b4w08] Einführung in BPEL4WS [hok] [Rau] [RB] Odej Kao, Prof. Dr. habil. Raush, Till: Service Orientierte Architektur Übersicht und Einordnung. Rerrer-Brusch, Dr. Ulf. [tec08] Tecchannel [w308a] W3.org [w3:08b] W3.org-WS [wik08a] Wikipedia-BPEL [wik08b] Wikipedia-SOA. A rchitektur, [wik08c] Wikipedia-UDDI