Serviceorientierte Architektur / Web Service

Serviceorientierte Architektur / Web Service Eine Einführung Nenad Marjanovic Institut für Verteilte Systeme Fakultät für Informatik Universität Ulm ABSTRACT Die serviceorientierte Architektur, kurz SOA (Service Orientied Architecture), stellt eine flexible und anpassbare IT-Architektur für die verteilte Datenverarbeitung dar. Das Konzept, das dahinter steht, ist die Auslagerung von Funktionen bzw. Diensten in eigene Services, die dann angesprochen werden können. Diese Seminararbeit befasst sich mit einer grundlegenden Einführung in den konzeptuellen Aufbau dieser Architektur, sowie der bereits etablierten und standardisierten Ausprägung des Web Service mit SOAP als Kommunikationsprotokoll. Stichwörter BPEL, SOAP, UDDI, Web Service, WSDL, XML 1. EINFÜHRUNG Unter serviceorientierter Architektur versteht man die Auslagerung von Funktionen oder kompletten Geschäftsprozessen auf einen internen Dienst oder externen Service eines Dienstanbieters. Es ist also keine konkrete Technik, sondern vielmehr ein Konzept, wie die Softwarearchitektur gestaltet wird. Das Kern der Idee ist dabei, die genannten ausgelagerten Geschäftsprozesse durch Dienste abwickeln zu lassen. Der Geschäftsprozess ist dabei nicht nur eine einzelne kleine Tätigkeit, sondern bezeichnet eine ganze Folge von Aktivitäten. Der Dienst kann dabei wiederum andere Dienste nutzen, um seine Tätigkeit auszuführen. 1.1 Vorteile aus Sicht des Entwicklers Um die Vorteile aus dem Blick des Entwicklers zu erkennen, muss man kurz einen kleinen Rückblick in die Entwicklung der zur Verfügungstellung von wiederverwendbaren Code machen. In der frühen Zeit der Softwareentwicklung wurden Programme meist von Grund auf neu geschrieben. Doch die Programme wurden mit der Zeit größer und komplexer. Deshalb begann man Funktionen und Prozeduren so zu schreiben, dass Sie wiederverwendbar wurden. Fand man jedoch einen Fehler in einer dieser Funktionen, so musste er in jedem Programm, das diese Funktion verwendete, behoben werden. Darum wurden häufig verwendete Funktionen in Bibliotheken mit definierten Schnittstellen gebündelt, die in den Programmen nur importiert werden mussten. Auch hier gab es den Nachteil, dass im Fehlerfall alle Bibliotheken auf verschiedenen Installationen aktualisiert werden mussten. Durch Auslagerung dieser Funktionen auf einen Dienst bekommt der Code eine zentrale Anlaufstelle. Wird der Code dort verändert, so ist diese Änderung sofort bei allen Dienstnutzern verfügbar. Dadurch spart man sich einen enormen Verwaltungsaufwand. Der Entwickler muss sich auch nicht darum kümmern, wie der Service seine Aufgabe erfüllt, sondern kann ihn einfach über fest definierte Schnittstellen nutzen. So lässt sich der Code ohne Kenntnis über die Implementierung zentral gehalten immer wieder verwenden. 1.2 Vorteile aus Sicht des Managers Durch die zentrale Speicherung des Codes wird der Aufwand für die Wartung minimiert und durch die leichte Wiederverwendbarkeit die Entwicklungszeit für neue Projekte verkürzt. Unternehmen sind meist in autonome Abteilungen gegliedert. Dies hat zur Konsequenz, dass diese meistens auch eigene IT-Infrastrukturen anlegen und nutzen. Dabei hat jede Abteilung ihren eigenen Datenbestand und Aufgaben. Die Ressourcen für gleiche Tätigkeitsbereiche in verschiedenen Abteilungen werden meist mehrfach bereitgestellt. Hier kann durch die Bereitstellung von unternehmensweiten Diensten eine Kostenersparnis und eine zentrale Verwaltung erreicht werden, ohne dass die Abteilungen ihre lokalen Strukturen und Daten preisgeben müssen. Des weiteren kann ein kompletter Geschäftsprozess mit komplexen Aufgaben, die eine große Neuentwicklung mit sich bringen würden, auf einen externen Dienstleister ausgelagert werden. Dies bringt Flexibilität und Agilität. Erschließt man neue Märkte und Geschäftspartner, so kann man dynamisch alte Services gegen evtl. kostengünstigere neue Services austauschen. Der Vorteil gegenüber erworbenen Bibliotheken liegt darin, dass man sich bei einem Dienst auch nur auf die Funktionen, die benötigt werden, beschränken kann. Bei einer Bibliothek erwirbt man gleich ein ganzes Paket, welches oft zahlreiche weitere Funktionen anbietet, die nicht benötigt werden. Außerdem muss man keine eigenen Ressourcen für die Ausführung des Services aufbringen. Doch auch wenn die Services alle intern entwickelt werden, können sich evtl. durch das Anbieten dieser an externe Kunden neue Einnahmequellen ergeben. 1.3 Nachteile von SOA Durch die Umstellung auf ein verteiltes System muss man völlig neue Sicherheitsaspekte betrachten, die bei einer lokalen Kommunikation nicht gegeben sind. So sollte man sich

über die Sicherheit beim Übertragen der Daten Gedanken machen, und evtl. verschlüsseln. Weitere Probleme ergeben sich, wenn ein Dienst ausfällt und keine Alternative verfügbar ist. Dann kann die Aufgabe nicht erfüllt werden. Die Serviceorientierte Architektur kann bei feingranularen Prozessen oder großen Nachrichten, die nur kleinere Aufgaben zu erledigen haben, zu Geschwindigkeitseinbußen führen. Das Generieren und Verarbeiten von XML-Dokumenten nimmt ebenfalls Zeit in Anspruch. 2. SERVICEORIENTIERTE ARCHITEKTUR In diesem Kapitel soll die serviceorientierte Architektur näher erläutert werden. Abbildung 1 zeigt die wesentlichen Komponenten sowie deren Interaktionen. Figure 1: Interaktionstruktur der serviceorientierten Architektur 2.1 Komponenten In der Serviceorientierten Architektur werden im Wesentlichen 3 Rollen eingenommen: Dienstanbieter der einen Service anbietet. Dienstnutzer der einen Service nutzt. Verzeichnisdienst in welchem die verfügbaren Dienste aufgelistet sind. Der Dienstanbieter veröffentlicht dabei zunächst seinen Service in einem Verzeichnisdienst. Ein Nutzer, der einen Dienst benutzen will, sucht in einem Verzeichnisdienst nach einem Dienst. Wenn er dort einen Dienst findet, der seine Anforderungen erfüllt, kann er diesen Dienst in Anspruch nehmen. Die Kommunikation erfolgt über Nachrichten, die als Anfrage an die Schnittstelle des Dienstes geschickt werden bzw. als Antwort vom Dienst an den Nutzer. Eine Schnittstelle wird durch die Schnittstellenbeschreibung, welche eine Menge von Kommunikationsregeln darstellt, beschrieben. Neben der Beschreibung, welche Funktionen verfügbar sind und wie sie genutzt werden können, gibt es zu der Schnittstellenbeschreibung auch noch einen so genannten Kontrakt, der die Semantik der einzelnen Funktionen näher beschreibt. Im Folgenden werden die einzelnen Komponenten näher erläutert. 2.2 Dienst Ein Dienst stellt eine gewisse Funktionalität bereit. In der Kommunikation repräsentiert er den Anbieter. Dabei ist die Funktionalität meist eine nicht triviale größere Aufgabe, die oft auch einen ganzen Teil in einem Geschäftsprozess übernimmt. Denn es macht keinen Sinn grundlegende Funktionen, wie z.b. die Addition zweier Zahlen als Service auszulagern. Hierbei würde der Aufwand für die Kommunikation mit dem Dienst mehr Zeit in Anspruch nehmen, als die Ausführung der Funktionalität. Dabei stellt der Anbieter eine genau definierte Schnittstelle bereit. Diese sollte plattform- und programmiersprachenunabhängig sein, um eine möglichst hohe Verwendbarkeit erzielen zu können. Wie auch bei Modulen hält der Betreiber meist die konkrete Implementierung verborgen (Geheimnisprinzip). Des weiteren sollte nicht nur der Algorithmus, sondern auch beispielsweise die Programmiersprache oder Architektur des Dienstes geheim gehalten werden, um keine Firmengeheimnisse preis zu geben. Auch sollten geeignete Sicherheitsmechanismen wie das Prüfen von Zugriffsberechtigungen den Zugriff auf den Service absichern. Dadurch, dass nur über diese definierte Schnittstelle kommuniziert wird, spielt die konkrete Implementierung des Service auch keine Rolle. Er kann in beliebiger Programmiersprache und auf beliebiger Hard- und Software realisiert werden, solange auf ihn zugegriffen werden kann und er sich an die Schnittstelle hält. Die Schnittstellen sollten sich auch, nachdem sie einmal veröffentlicht wurden, nicht ändern, damit die Nutzer des Dienstes sich nicht anpassen müssen. Geänderte Dienste werden meist als ein neuer Service angeboten. Ein Dienst kann nur benutzt werden, wenn die Möglichkeit besteht, ihn aufrufen zu können. Dies wird meist über das Netzwerk (lokal im Intranet oder auch im gesamten Internet) ermöglicht. Es gibt jedoch auch lokale Dienste, die nur auf einem einzelnen Rechner erreichbar sind. Wenn ein Zugriff auf einen Service erfolgt, geschieht dies durch Austausch von Nachrichten. Unterstützen zwei Dienste gleiche Schnittstellen, so heißen Sie kompatibel. Der Vorteil hierbei ist, dass sie beliebig gegeneinander ausgetauscht werden können. 2.3 Nutzer Als Nutzer bezeichnet man denjenigen, der einen Dienst in Anspruch nimmt. Dabei sucht sich ein Nutzer aktiv einen Dienst, den er verwenden will. Ein Nutzer kann auch ein Dienst sein. Wenn ein Dienst eine bestimmte Funktionalität zur Zeit oder generell nicht erfüllen kann, kann er die Aufgabe an einen anderen Dienst weiter delegieren. Ein Nutzer nimmt meist nicht nur einen Dienst in Anspruch, sondern gleich eine ganze Dienstkette. So lassen sich selbst komplexe Geschäftsabläufe durch Aneinanderreihung von Diensten schnell bewerkstelligen. 2.4 Verzeichnis Im Verzeichnisdienst registrieren die Dienstanbieter ihre Services. Er verwaltet diese, und teilt suchenden Nutzern die nötigen Informationen über die einzelnen Dienste mit, um diese verwenden zu können. Zu diesen notwendigen Informationen gehört die Funktionalität des Dienstes, der Ort wo der Dienst aufgerufen werden kann sowie Informationen über die angebotene Schnittstelle. Der Vorteil ist hierbei, dass dadurch der Nutzer in seiner Software den zu verwendenden Dienst erst über ein Verzeichnis zur Laufzeit suchen kann. Anstatt den Dienst zuvor fest in den Code zu integrieren,

sucht er erst beim Ausführen der benötigten Funktionalität über den Verzeichnisdienst nach einem geeigneten Service. Dadurch kann er automatisch auf evtl. günstigere Angebote ausweichen, oder im Falle des Ausfalls eines Dienstes, eine Alternative wählen. 2.5 Nachrichten Die Kommunikation zwischen Anbieter und Nutzer erfolgt über Nachrichten. Der Dienstnutzer schickt dabei dem Service eine Anfrage und erhält daraufhin vom Anbieter eine Antwort. Das Format der Nachrichten wird vom Dienstanbieter vorgegeben, und sollte nach der Veröffentlichung nicht mehr geändert werden, da dies auch fast immer eine Umstellung beim Nutzer nach sich zieht. Das Wichtigste hierbei ist das plattform- und programmiersprachenunabhängige Format der Nachricht, so dass die Nutzung bzw. auch das Anbieten eines solchen Services nicht dadurch eingeschränkt wird. In der Praxis wird XML häufig dafür verwendet, da es das Kriterium der Plattformunabhängigkeit erfüllt, relativ einfach implementiert und auch von Menschen ohne besondere Hilfen gelesen werden kann. Da XML mittlerweile weit verbreitet ist, gibt es für nahezu jede Programmiersprache eine entsprechende Bibliothek, die das Lesen und Erzeugen von XML-Dokumenten erleichtern. 2.6 Zusammenfassung Mit der serviceorientierten Architektur ist die Wiederverwendung bereits implementierter Abläufe im Vergleich zu den davor genutzten Methoden des simplen Kopierens oder Einbindens von Modulen und Bibliotheken, deutlich einfacher. Der Code wird nicht an mehreren Stellen gespeichert, sondern zentral gehalten. Dadurch minimiert sich der Verwaltungsaufwand. Zugriff zum Dienst erlangt man über das Netzwerk. Durch die Plattformunabhängigkeit der Schnittstellen und der Kommunikation wird das Zusammenführen von heterogenen Systemen im Vergleich zu vorher erleichtert. Wenn sich diese Architektur in einem Unternehmen einmal durch eine größere Anzahl von Diensten etabliert hat, lassen sich im folgenden komplexe Anwendungen durch Nutzung dieser Dienste in Dienstketten relativ einfach realisieren. Aber auch bei der Nutzung externer Dienste von anderen Unternehmen können Einsparungen durch Ressourcenschonung bei Entwicklung und Nutzung erzielt werden. Durch das Verwenden von Verzeichnisdiensten können die Dienste variabel genutzt werden und die Applikation des Nutzers kann schnell auf die Gegebenheiten reagieren. 3. XML Wie im vorangegangenen Kapitel schon angedeutet, spielt XML bei einer Serviceorientierten Architektur eine große Rolle. Doch was genau ist XML? Die Extended Markup Language - kurz XML - ist eine Metasprache, also ein Sprachkonstrukt, mit welchem Sprachen beschrieben werden können. Ursprünglich von Microsoft und IBM vorangetrieben, wird es mittlerweile vom W3C standardisiert und ist mittlerweile in der vierten Version (seit September 2006) erschienen. Die Idee hinter der Sprache ist es, die Daten von der Semantik zu trennen. Dies wurde in der Vergangeheit schon mit verschiedenen Auszeichnungssprachen versucht. So ist XML eigentlich nur eine Untermenge von SGML (Standard Generalized Markup Language), welches schon 1986 als ISO-Standard publiziert wurde. 1 <auto> 2 <marke>audi</marke> 3 < s e r i e>r8</ s e r i e> 4 <motor> 5 <hubraum e i n h e i t=" l i t e r ">4. 2</hubraum> 6 <l e i s t u n g e i n h e i t=" ps ">420</ l e i s t u n g> 7 </ motor> 8 </ auto> Figure 2: Ein geschachteltes XML-Konstrukt. 3.1 Struktur Mit XML versucht man Inhalte möglichst leicht maschinell zugänglich, erstell- und manipulierbar zu machen. Dies wird hier dadurch erreicht, dass der Inhalt über kennzeichnende Markierungen in funktionale Blöcke gegliedert wird. Diese Markierungen sind durch spitze Klammern gekennzeichnet und Tags genannt. Ein Beispiel für einen solchen Tag wäre z.b. <automarke>. Die Menge aller in einem Dokument vorkommenden Tags wird Markup genannt. Auf jedes dieser Tags muss auch ein entsprechendes schließendes Tag im Dokument folgen. Ein schließender Tag ist derselber Tag, nur das dem Tag-Namen ein / vorangestellt ist. Beim vorherigen Beispiel wäre dies also </automarke>. Der Text zwischen der Anfangs- und Endmarke entspricht dem Wert dieser Marke. In den öffnenden Tags lassen sich des weiteren auch noch Eigenschaften definieren. Eine Eigenschaft wird durch den Namen sowie dessen Wert in Anführungsstrichen nach dem Tag-Namen, aber noch innerhalb der schließenden spitzen Klammer definiert. Ein Beispiel (einheit= liter ) befindet sich in Abbildung 2. Die durch die Marken gekennzeichneten Abschnitte können ineinander geschachtelt sein. Allerdings muss man darauf achten, dass die Auszeichnungen abgeschlossen werden, bevor ein übergeordnetes Markenpaar geschlossen wird. Ein Beispiel hierfür wäre Abbildung 2. Für eine genauere Betrachtung ist die offizielle Spezifikation in [15] vom W3C zu empfehlen. 3.2 Warum XML in SOA XML liefert die geforderte Plattformunabhängigkeit. Ein XML-Dokument kann von jedem Rechner erstellt werden, welcher mindestens den ASCII-Zeichensatz unterstützt. XML ist einfach und besteht nur aus einem Satz an Regeln für die Erstellung von Textformaten zur Strukturierung von Daten. XML hat nicht die Komplexität einer Programmiersprache und man muss auch kein Entwickler sein, um es nutzen zu können. Durch sein leicht durch Maschinen lesbares Format vereinfacht XML, Daten zu generieren, zu lesen und zu modifizieren. Es sorgt durch seinen Aufbau, dass auch die Strukturierung der Daten erhalten bleibt. Es kann mit beliebigen Marken und Daten gefüllt werden. Zu guter Letzt ist XML kostenlos und wird gut unterstützt. Es gibt zahlreiche (oft kostenlose) Werkzeuge und Bibliotheken, die die Erzeugung von XML-Dokumenten unterstützen und erleichtern. Durch die Standardisierung gibt es auch Menschen, die helfen können, da allen das gleiche XML zugrunde liegt. Da die Entwicklung derzeit vom W3C vorangetrieben ist, ist es lizenzfrei, und kann beliebig in die eigene Software integriert und auch für kommerzielle Anwendungen genutzt werden, ohne jemandem etwas bezahlen zu müssen.

4. WEB SERVICE MITTELS SOAP Web Services sind derzeit sehr beliebt. Sie bieten eine Vielzahl von Unternehmen über Web Services eine Schnittstelle zu ihren Dienstleistungen an. Darunter findet man auch bekannte Namen wie Amazon, ebay, Yahoo und Google. Alle genannten Unternehmen betreiben ihre Web Services über das Kommunikationsprotokoll SOAP. So können über Amazon direkt die Produkte in die eigene Infrastruktur übernommen werden [21] oder über die genannten Suchmaschinenbetreiber direkt Suchanfragen gestellt und im eigenen System ausgegeben werden[22,23]. Bei ebay haben Verkäufer über die API die Möglichkeit, Auktionen in einem eigenen Programm zu verwalten, über die SOAP-Schnittstelle direkt bei ebay zu inserieren und zu verwalten. [20] 4.1 Web Service Web Services sind eine konkrete Ausprägung der serviceorientierten Architektur. Basierend auf XML wurde es von OASIS und dem W3C standardisiert [15]. Aufbauend auf vorhandenen Internetprotokollen, kann es so relativ schnell implementiert werden. Ein Web Service besteht im Wesentlichen aus drei Komponenten: Kommunikationsprotokoll Im folgenden Unterkapitel wird SOAP vorgestellt, das entfernte Prozeduraufrufe mittels XML-Nachrichten ermöglicht. Dienstbeschreibung Eine Beschreibung der Funktionalität des Dienstes sowie dessen Benutzung. Bei SOAP wird dies in der Regel mittels einer WSDL-Datei realisiert. Verzeichnisdienst Ein Verzeichnisdienst, bei dem der Dienst registriert ist, um auch aufgefunden werden zu können. Hier wird im Folgenden UDDI vorgestellt. Im Anschluss daran soll noch kurz auf BPEL eingegangen werden. Mit BPEL ist es möglich mit einer der XML ähnlichen Beschreibungssprache Service miteinander zu koppeln, und diese automatisch ausführen zu lassen. 4.2 SOAP SOAP (ursprünglich für Simple Object Access Protocol, seit Version 1.2 jedoch keine Abkürzung mehr) wurde ursprünglich von Microsoft und später zusammen mit IBM entwickelt. Mittlerweile wird es vom W3C standardisiert [16]. SOAP ist ein Kommunikationsprotokoll, über welches entfernte Prozeduraufrufe und Dateiübertragungen durchgeführt werden können. Dabei werden Nachrichten basierend auf XML ausgetauscht. SOAP ist zwar ein Protokoll, besitzt aber keinerlei Spezifikationen zur eigentlichen Datenübertragung. Das Ziel der Entwickler war es, bereits bestehende Protokolle für die Übertragung zu nutzen. So wird SOAP meistens über das HTTP-Protokoll übertragen, aber jedes Übertragungsprotokoll wie FTP oder sogar SMTP sind möglich. 4.2.1 Nachrichten Bei SOAP gibt es drei Nachrichten-Typen: Request, Response und Fault. Mit der Reuquest-Nachricht schickt der Dienstnutzer eine Nachricht an den Service, welche Operation mit welchen Parametern ausgeführt werden soll. Dieser antwortet daraufhin mit einer Antwort- (Response) oder einer Fehler-Nachricht (Fault). Figure 3: Aufbau einer SOAP-Nachricht Alle Nachrichten an sich bestehen aus einem Umschlag (envelope), welcher einen optionalen Kopf (head) sowie den eigentlichen Rumpf (body) beinhaltet. Der Kopf enthält dabei beliebige zusätzliche, evtl. auch nicht standardisierte Elemente, die vom Dienstanbieter nicht unbedingt unterstützt werden müssen. Man kann diese aber auch mit dem Attribut mustunderstand versehen, so dass der Anbieter dieses Attribut interpretieren muss. Versteht der Anbieter dieses Element nicht, so schickt er eine Fehlermeldung mit einem Hinweis auf die unbekannten Elemente zurück. Neben den Standardinhalten können auch noch Routing-Optionen und Authentifizierungen über SOAP geregelt werden. In der Praxis wird dies jedoch über das darunter liegende Internetprotokoll (HTTP) geregelt. Als weiteres Atrribut für Header-Elemente gibt es actor, welches aussagt, für wen das Header-Element gedacht ist. So kann man z.b. eine mehrschichtige Bearbeitung von Dienstanfragen erzielen, indem man Authentifizierungen seperat behandelt und die eigentliche Nachricht erst danach an den Dienst weiterleitet. Der Body enthält das eigentliche XML-Dokument. Der Inhalt ist nicht standardisiert, sondern wird vom Nutzer selbst in Abhängigkeit vom Dienst vorgegeben. Beim Nachrichtenaustausch unterscheidet man zwischen zwei Methoden: Entfernte Prozeduraufrufe (Remote Procedure Calls, RPC) sowie ein beliebiger XML- Dokumentenaustausch. Ersteres ist dabei nur ein Spezialfall von Letzterem. Ein entfernter Prozeduraufruf enthält im Rumpf den Namen der gewählten Operation, sowie dessen mit Typbezeichnung versehenen Parameter. Die Antwort des Services liefert dann den Rückgabewert der Operation, bzw. eine Fehlermeldung bei falschen Parametern oder unbekannter Operation. Beim XML-Dokumentenaustausch kann ein beliebiges XML-Dokument ausgetauscht werden. Der Web Service fungiert hierbei dann als Transformator und liefert ebenfalls ein Dokument zurück. Abbildung 4 und 5 zeigen eine Request- sowie Response- Nachricht. Die Nachrichten wurden an den Web Service BabelFish von AltaVista geschickt. BabelFish ist ein Übersetzungsdienst, der Texte mit max. 2000 Zeichen in eine von 8 Sprachen übersetzen kann. Die Nachrichten entsprechen dem entfernten Prozeduraufruf ohne jegliche Header. Dieser Aufruf der Operation entspricht in Pseudocode BabelFish(String, String), welcher wiederum einen String zurück gibt. Die Rückgabe entspricht dabei der Übersetzung des zweiten Parameter. Die Quell- und Zielsprache wird über den ersten Parameter übergeben. Das Format ist vom Dienstanbieter vorgegeben. Im Beispiel ist der String car zu übersetzen. Mit en_de wird dem Service mitgeteilt, dass er aus dem Englischen ins Deutsche übersetzen soll. Im Response wird als Rückgabewert Auto zurück geliefert.

1 <?xml version=" 1.0 " encoding=" UTF -8 "?> 2 <SOAP:Envelope xmlns:soap=" http: // schemas. x m l s o a p. org / soap / e n v e l o p e / " x m l n s : x s i=" h t t p : // www. w3. org / 2 0 0 1 / XMLSchema - i n s t a n c e " xmlns:xsd=" h t t p : // www. w3. org / 2001/ XMLSchema "> 3 <SOAP:Body> 4 <n s 1 : B a b e l F i s h xmlns: ns1=" u r n : x m e t h o d s B a b e l F i s h " SOAP:encodingStyle=" http: // schemas. x m l s o a p. org / soap / e n c o d i n g / "> 5 <t r a n s l a t i o n m o d e x s i : t y p e=" x s d : s t r i n g "> en de</ t r a n s l a t i o n m o d e> 6 <s o u r c e d a t a x s i : t y p e=" x s d : s t r i n g ">Car</ s o u r c e d a t a> 7 </ n s 1 : B a b e l F i s h> 8 </SOAP:Body> 9 </ SOAP:Envelope> Figure 4: Beispiel einer Request-Nachricht. 1 <?xml version=" 1.0 " encoding=" UTF -8 "?> 2 <SOAP:Envelope xmlns:soap ENC=" h t t p : // s c h e m a s. x m l s o a p. org / soap / e n c o d i n g / " SOAP:encodingStyle=" http: // schemas. x m l s o a p. org / soap / e n c o d i n g / " x m l n s : x s i=" h t t p : // www. w3. org / 2 0 0 1 / XMLSchema - instance " xmlns:soap=" http: // schemas. x m l s o a p. org / soap / e n v e l o p e / " xmlns:xsd=" h t t p : // www. w3. org / 2 0 0 1 / X M L S c h e m a "> 3 <SOAP:Body> 4 <namesp1:babelfishresponse xmlns:namesp1=" u r n : x m e t h o d s B a b e l F i s h "> 5 <r e t u r n x s i : t y p e=" x s d : s t r i n g ">Auto</ r e t u r n> 6 </ namesp1:babelfishresponse> 7 </SOAP:Body> 8 </ SOAP:Envelope> Figure 5: Beispiel einer Response-Nachricht. 4.3 WSDL Um die Plattformunabhängigkeit der Dienste zu erhalten, wird auch eine plattformunabhängige Methode benötigt, die Schnittstelle der Dienste zu beschreiben. Bei Web Services hat sich der Ansatz mit WSDL durchgesetzt. WSDL steht für Web Service Description Language [17]. Sie ist eine maschinenlesbare Beschreibung, welche es ermöglicht, automatische Codeerzeugungs-Werkzeuge zu erstellen, so dass der Programmierer den Web Service als lokale Methoden behandeln kann. WSDL ist in einem XML-Format spezifiziert. Abbildung 4.3 gibt einen Überblick. Die Inhalte sollen im Folgenden erläutert werden. In <wsdl:types/> werden die in der Schnittstelle verwendeten Datentypen aufgeführt. Um die Plattformunabhängigkeit zu erhalten, werden häufig auf Datentypen der XMLSchema-Spezifikation verwendet. Hier 1 <?xml version=" 1.0 " encoding=" UTF -8 "?> 2 <w s d l : d e f i n i t i o n s> 3 <w s d l : t y p e s /> Datentypen 4 <w s d l : m e s s a g e /> Nachrichten 5 <wsdl: porttype /> Operationen 6 <w s d l : b i n d i n g /> S c h n i t t s t e l l e n 7 <w s d l : s e r v i c e /> Z u g r i f f 8 </ w s d l : d e f i n i t i o n s> Figure 6: XML-Notation einer WSDL-Datei. 1 <complextype name=" Mensch "> 2 <element name=" Name " type=" xsd: string " /> 3 <element name=" Alter " type=" xsd: int " /> 4 </ complextype> Figure 7: Definition eines komplexen Datentyps. können jedoch auch eigene Datentypen definiert werden. Ein Beispiel für einen selbstdefinierten Typ ist in Abbildung 7 zu sehen. In diesem Beispiel wird der Typ Mensch definiert. Dieser besteht aus 2 Elementen Name und Geschlecht, welche als String bzw. Integer definiert sind. Bei <wsdl:message/> wird definiert, welcher Datentyp bei einer Nachricht übertragen wird. In <wsdl:porttype/> werden die Operationen beschrieben. Dabei werden die für die Operation eingehenden Nachrichten, sowie deren ausgehende Nachrichten definiert. Für jede Operation wird dabei die zum Aufruf versendeten Nachrichten (Name) defniert sowie in der Regel je eine für Anfrage und Antwort. In <wsdl:binding/> wird die konkrete Schnittstelle, also die Operationen die aufgerufen werden können, eines Dienstes angegeben. Bei <wsdl:service/> wird der Zugriff auf die Schnittstelle, meist über eine URL, genau angegeben. Damit erhält man eine vollständige Beschreibung des Web Service. Die WSDL-Datei ist meist über das HTTP- Protokoll auf einem Webserver erreichbar. Die Inhalte werden meist beim Dienstnutzer zwischengespeichert um nicht bei jedem Aufruf die XML-Elemente neu zu parsen. Die Adresse der WSDL-Datei wird auch, falls der Service in einem Verzeichnisdienst (siehe nächstes Unterkapitel) angemeldet wird, angegeben, damit der Dienst automatisiert gefunden und benutzt werden kann. Mittlerweile ist WSDL bereits in Version 2.0 erschienen. Ursprünglich war es die Version 1.2, aber durch grundlegende Namensänderungen wurde die Versionsnummer angehoben. Neu ist vor allem die vollständige Unterstützung von HTTP als Transportprotokoll, wodurch der Inhalts-Layer überflüssig wird. Des weiteren wurden PortTypes in interfaces und Ports in endpoints umbenannt [17]. 4.4 UDDI Für Dienstnutzer von Web Services ist es häufig wichtig, dass sie die benötigten Dienste automatisiert finden können. Bei Web Services gibt es Universal Description, Discovery and Integration, kurz UDDI [18]. Es ist ein Verzeichnisdienst bei dem sich Unternehmen, die einen Service anbieten wollen, registrieren können. Er kann von Nutzern über eine SOAP- Schnittstelle angesprochen werden und enthält alle nötigen Informationen um einen dort registrierten Dienst nutzen zu können. Dabei wird in drei Verzeichnis-Kategorien eingeteilt: White, Yellow und Green Pages. White Pages können mit einem Telefonbuch verglichen werden. Sie enthalten ein nach Namen sortiertes Namensregister, in welchem alle Anbieter mit allen

Detailangaben und Kontaktinformationen, wie Telefon und Fax aufgelistet werden. Yellow Pages ähneln den uns bekannten Gelben Seiten. Dabei werden die Anbieter nach Branchen geordnet. Diese Einträge werden dann mit dem zugehörigen White Pages des Anbieters verknüpft. In den Green Pages wird das Geschäftsmodell der Anbieter definiert. Dies beinhaltet die Zusicherungen an den Nutzer, sowie die Kosten für die Benutzung und das Abrechnungsmodell. In UDDI werden die Daten in den Verzeichnissen ebenfalls in XML-Notation verwaltet. Dabei gibt es im wesentlichen folgende Elemente: Im Element businessentity werden Informationen über die Organisation, Kontaktdaten, Branche und eine Liste der angebotenen Dienste gespeichert. Im businessservice ist eine allgemeine Beschreibung eines Dienstes zu finden. Die technischen Details sowie ein Verweis auf die WSDL-Datei eines Dienstes findet man im Element bindingtemplate Noch detailliertere technische Daten werden im tmodel offengelegt. Es beschreibt die Spezifikationen der Schnittstellen, die ein Web Service verwendet. Im tmodel eines Web Services ist unter anderem ein Schlüssel enthalten, der den Dienst beschreibt. Wenn zwei Services denselben Schlüssel besitzen, bedeutet dies, dass sie zueinander kompatibel sind, und gegeneinander ausgetauscht werden können. Ein UDDI-Verzeichnis ist selbst ein Web Service und wird mittels SOAP angesprochen. Für diesen Dienst wird ebenfalls ein WSDL-Dokument, das die Schnittstelle beschreibt, bereitgestellt. Dabei wird zwischen zwei Schnittstellen unterschieden: PublishSOAP ist für den Dienstanbieter gedacht, um seine Dienste im Verzeichnis zu verwalten. Es bietet Operationen zum Anlegen, Ändern und Löschen von Diensten. InquireSOAP liefert die Suche nach Diensten sowie deren Details die zur Verwendung benötigt werden. Ein Dienstnutzer wird diese Schnittstelle nutzen, um die dynamische Bindung zu einem Web Service herzustellen. 4.5 BPEL Mit den bislang kennengelernten Methoden kann man selbst die Web Services raussuchen und ansprechen. Einen Schritt weiter geht hier BPEL, mit welcher es möglich ist, Dienste miteinander interagieren zu lassen. Die Business Process Execution Language, kurz BPEL, ist eine Sprache, die zur Beschreibung der Steuerung und Koordination (Orchestration) mehrerer Web Services in einem Geschäftsprozess dient. Die einzelnen Web Services werden durch den BPEL-Prozess zusammengefasst. Dieser Prozess ist für die gesamte Abfolge verantwortlich, um verschiedene Dienste aufzurufen, die gemeinsam einen Geschäftsprozess erledigen sollen. BPEL ist von XML abgeleitet. Zunächst wird eine BPEL Prozessbeschreibung erstellt, die verschiedene Web Service verwendet. Diese Beschreibung wird auch komponierter Web Service genannt. In der Beschreibung werden die zunächst die Nachrichten (und damit auch Daten), die verschickt werden, definiert. Danach werden die gewünschten Web Services hinzugefügt. Die Nachrichten werden nun mit den Diensten in eine zeitliche Abfolge gebracht. Diese Beschreibung wird letztendlich an eine BPEL Execution Engine (wie z.b. Twister) übergeben, die die beschriebene Abfolge ausführt als BPEL Prozess ausführt. Eine genaue Spezifikation von BPEL findet man unter [19]. 5. DISKUSSION Serviceorientierte Architekturen erlauben es, leicht bestehende Funktionalitäten wiederzuverwenden. Da dabei die Implementierung nicht vervielfältigt, sondern zentral gehalten wird, ist auch die Wartung deutlich effizienter und damit günstiger. Durch die plattform- und programmiersprachenunabhängigen Schnittstellen ist auch die Zusammenführung von heterogenen Systemlandschaften leichter als Davor zu bewerkstelligen. Wenn sich eine solche Architektur erst einmal in einem Unternehmen konsequent durchgesetzt hat, lassen sich selbst komplexe Aufgaben relativ schnell und einfach durch Kombination der geeigneten internen und evtl. externen Dienste erledigen. Dabei ist auch das leichte Austauschen von Services ein großer Vorteil, wodurch leicht Kosten eingespart werden können. Es ist sogar theoretisch möglich, die Dienste erst zur Laufzeit dynamisch über einen Verzeichnisdienst auszuwählen. SOA birgt aber auch Nachteile. Zwar sind die Dienste lose gekoppelt, doch wenn ein Dienst nicht erreichbar ist und keine Alternative besteht, kann die Aufgabe nicht ausgeführt werden. Ein weiterer neuer Aspekt bei Verwendung externer Dienste ist die evtl. Datenoffenlegung firmeninterner Geheimnisse an einen Konkurrenten. Hier muss genau begutachtet werden, welche Informationen preisgegeben werden. Auch muss der Kommunikationskanal, der erst durch die Verteilung entsteht, neu behandelt werden. Zum Einen müssen die Daten sicher übertragen werden, zum Anderen entstehen neue Fehlerquellen beim evtl. Ausfall einzelner Zwischenknoten, welche bei lokalen Programmen nicht gegeben wären. Außerdem können einige Probleme nicht sinnvoll in dienstorientierten Architekturen umgesetzt werden. So lassen sich Ereignisse nicht implementieren, da die Kommunikation immer vom Nutzer ausgeht. Dies ließe sich hier nur mit Polling, also dem ständigen Abfragen, realisieren. Einen Lösungsansatz hierfür bietet die ereignisgesteuerte Architektur (eventdriven architecture, kurz EDA), welche im nachfolgenden Unterkapitel kurz behandelt werden soll. Des weiteren soll daraufhin noch auf die Diskussion eingegangen werden, ob

SOA nicht nur ein Zugriff auf ein entferntes Objekt ist. 5.1 Ereignisgesteuerte Architektur EDA verfolgt auch das Prinzip der serviceorientierten Architektur. Ein Dienstanbieter bietet einen Service an und veröffentlicht ihn in einem Verzeichnisdienst. Ein Nutzer sucht darüber seinen Dienst, den er verwenden will. Hat er einen Dienst gefunden, wird er in Anspruch genommen. Hier kommt nun der Unterschied. Der Nutzer schickt nun keine Nachricht an den Dienst, sondern er registriert sich bei ihm, dass er kontaktiert werden möchte, wenn ein gewisses Ereignis eintritt. Ein einfaches Beispiel hierfür könnte ein Ping-Service sein. Der Nutzer registriert sich beim Service und trägt sich in die Ereignisliste ein, sobald z.b. ein bestimmter Webserver nicht mehr erreichbar ist. Er ist nun beim Dienst registriert. Der Dienst pingt diesen Webserver an. Sollte er einmal nicht erreichbar sein, kontaktiert der Dienst alle in der Liste der für dieses Event eingetragenen Nutzer. Wie sich jedoch dieser Ansatz in Zukunft im Vergleich zur serviceorientierung entwickeln wird, ist offen. 5.2 Sind Web Services nur ein Zugriff auf ein entferntes Objekt? Was unterscheidet einen Web Service eigentlich vom Zugriff auf ein entferntes Objekt? Experten sind geteilter Meinung, ob es überhaupt einen Unterschied gibt, was auch verschiedene Publikationen zeigen [1,2]. Betrachtet man zunächst die Gemeinsamkeit beider Systeme: Sowohl Web Services als auch entfernte Objektaufrufe sind eine Ausprägung verteilter Systeme. Hier enden aber bereits die Gemeinsamkeiten. Während entfernte Objektaufrufe eher für das Intranet entworfen wurden, zielen Web Services eher auf die Reichweite des Internets ab. Betrachtet man Web Services in seiner einfachsten Art: Ein Dienstnutzer schickt ein XML-Dokument an den Service. Der Service antwortet wiederum wieder mit einem XML- Dokument. Aus dieser Sicht ist der Vorgang nur ein Dokumentenaustausch, und das ist noch weit entfernt von der Instanzierung eines entfernten Objekts. Auch Dinge wie Referenzen, Lebenszyklen oder Garbage Collection gibt es in Web Services nicht. Web Services kommt ein persistenten Objekten, welches mit dem singleton-pattern nur einmal instanziert werden kann, am nächsten, ist aber immer noch weit entfernt von reinem Dokumentenaustausch eines solchen Service. Denn Web Services sind im Normalfall ständig verfügbare, direkt ansprechbare Schnittstellen. Sie werden nicht instanziert und nach Benutzung auch nicht wieder entfernt. Der Unterschied ist damit zumindest aus der Sicht der Architektur deutlich ersichtlich. Betrachtet man das ganze jedoch aus Sicht des Entwicklers, so verwischt sich der Unterschied. In beiden Fällen wird meist ein lokales Stellvertreter-Objekt erstellt, das mit dem Web Service bzw. dem entfernten Objekt interagiert. Und in beiden Fällen ist der entfernte Prozeduraufruf der eigentliche Hintergrund. Man sollte also noch nicht Web Services mit entfernten Objekten vergleichen. Alle genannten Eigenschaften, die man aus entfernten Objektaufrufen kennt, gibt es noch nicht bei Web Services. Web Services können aber durch diese Funktionalität erweitert werden. Auch hier werden die Bedürfnisse der Dienstnutzer Einfluss darauf nehmen, wie die Entwicklung voranschreitet. 6. REFERENZEN 1. Vogels, W. Web services are not distributed objects. IEEE Internet Comput. 7, 6 (Nov.-Dec. 2003), 59-66. 2. Birman, K. Like it or not, Web Services are distributed objects. Communications of the ACM. 47, 12 (Dec. 2004), 60-62. 3. Hashimi, S. Service-Oriented Architecture Explained. http://www.ondotnet.com/lpt/a/4108 4. Weller, A., Müller, T. T-Systems SOA Blog. http://www.exploresoa.de/soa/de/soablog 5. Herrmann, W. In zehn Schritten zur SOA. http://www.computerwoche.de/zone/soa/569662/. 6. Herrmann, W. Gartner nennt die zwölf SOA-Todsünden. http://www.computerwoche.de/soatrends/1849999/ 7. Snell, J., Tidwell, D., Kulchenko, P. Webservice- Programmierung mit SOAP. O Reilly. Juli 2002 8. Schmidt, T. The Enterprise Service Bus: Making service-oriented architecture real.ibm Systems Journal. VOL 44, NO 4, 2005, 781-797. 9. Japs, F. Flexibilität und Kopplung von IT-Systemen am Beispiel des Schnittstellenmanagements mit Web Services. Westfälische Wilhelms-Universität Münster. 2005. 10. Hamann, K. Diensteorientierte Architektur. Universität Hamburg. 2006. 11. Schoetzau, F. Architektur und Basiskomponenten moderner Web Services mit Schwerpunkt SOAP. Wirtschaftswissenschaften der Universität Hannover. 2002. 12. Krause, T. Service Oriented Architecture: Service Lookup & Service Repository. Hochschule für Angewandte Wissenschaften Hamburg. 2005. 13. Bender, M. Service-Oriented Architecture. Universität Koblenz. 2005. 14. W3C XML. http://www.w3.org/xml/. 2006. 15. W3C Web Service. http://www.w3.org/2002/ws/. 2002. 16. W3C SOAP. http://www.w3.org/2000/xp/group/. 2000. 17. W3C WSDL. http://www.w3.org/2002/ws/desc/. 2002/2007.

18. UDDI-Spezifikationen. http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm. 2005. 19. BPEL-Spezifikationen. http://docs.oasis-open.org/wsbpel/2.0/os/wsbpelv2.0-os.html. April 2007. 20. ebay-application Programming Interfaces. http://pages.ebay.de/entwickler/api.html. Zugriff: Dezember 2007. 21. Amazon Web Services. http://www.amazon.com/aws. Zugriff: Dezember 2007. 22. Yahoo! Search Web Services. http://developer.yahoo.com/search/. Zugriff: Dezember 2007. 23. Google SOAP Search API. http://code.google.com/apis/soapsearch/. Zugriff: Dezember 2007.