Web Services und
Service Oriented Architectures
Alfon Wenzler
Technische Universit¨ at Kaiserslautern 2. Juli 2004
Inhaltsverzeichnis
1 Motivation 2
2 Service Oriented Architecture 2
2.1 Motivation . . . 2
2.1.1 Zielsetzung . . . 3
2.2 Das Service Oriented Model . . . 3
2.2.1 Definitionen . . . 3
2.2.2 Modellformulierung . . . 4
2.2.3 Bedingungen . . . 4
3 Web Services 6 3.1 Was sind Web-Services? . . . 6
3.1.1 Das Web – Heute und Morgen . . . 6
3.1.2 Beispiele . . . 6
3.1.3 Definition . . . 6
3.1.4 Vision . . . 8
3.2 Web-Service-Architektur . . . 8
3.2.1 Web Service Roles . . . 8
3.2.2 Web Service Protocol Stack . . . 9
4 Basistechnologien 10 4.1 SOAP . . . 10
4.1.1 SOAP – ¨Uberblick . . . 10
4.1.2 SOAP – Spezifikation . . . 10
4.2 WSDL . . . 12
4.2.1 WSDL– ¨Uberblick . . . 12
4.2.2 WSDL–Spezifikation . . . 12
4.3 UDDI . . . 13
4.3.1 UDDI– ¨Uberblick . . . 13
4.3.2 UDDI–Architektur . . . 14
5 Alternative Ans¨atze f¨ur Web Service 16 5.1 XML-RPC . . . 16
5.2 REST . . . 16
6 CORBA vs. Web Services 17
6.1 Vergleich . . . 18
6.1.1 Verarbeitungsmodell . . . 18
6.1.2 Eigenschaften . . . 19
6.2 Einsatzgebiete . . . 19
7 Zusammenfassung 20 A Anhang 21 A.1 SOAP . . . 21
A.1.1 Listing SOAP Message . . . 21
A.2 WSDL . . . 21
A.2.1 Listing WSDL . . . 21
A.3 UDDI . . . 22
A.3.1 ListingbusinessEntity . . . 22
A.3.2 ListingbusinessService . . . 23
A.3.3 ListingtModel . . . 23
A.3.4 Ausschnitt aus der UDDI-API . . . 24
A.4 XML-RPC . . . 24
A.4.1 XML-RPC request . . . 24
A.4.2 XML-RPC response . . . 25
1 Motivation
Das Thema diese Seminars lautetService Oriented Architectures und Web Services – Grundlagen und Vergleich mit bestehenden Middleware-Technologien. Web Services und serviceorientierte Ar- chitekturen sind derzeit sowohl im akademischen Umfeld als auch in der Industrie sehr popul¨ar.
Bei Web Services handelt es sich um Bausteine zur L¨osung von Software-Integrationsproblemen welche auf bestehende Ans¨atze in den Bereichen verteilte Systeme, Informationssysteme und Pro- grammiersprachen aufbauen. Die Erwartungen an dieses neue Konzept und die damit verbundenen Anstrengungen auf diesem Gebiet sind sehr hoch. In Kapitel 2 wird das Konzept der serviceorien- tierten Architekturen beschrieben. Als Anwendung des SOA-Gedankens wird im Kapitel 3 auf den Begriff Web Services eingegangen. Die Basistechnologien f¨ur Web Services werden im Kapitel 4 behandelt. Abschnitt 4.1 beschreibt die SOAP-Spezifikation zum Nachrichtenaustausch. Die Be- schreibung der Web Services durch die WSDL ist Thema des Abschnitts 4.2. Abschnitt 4.3 beinhal- tet die UDDI-Spezifikation f¨ur Web-Service-Verzeichnisse. Auf alternative Ans¨atze zur Realisierung von Web Services wird in Kapitel 5 eingegangen. Behandelt werden die Ans¨atze XML-RPC sowie REST. Den Vergleich von Web Services mit der bestehenden Middleware Technologie CORBA ist Thema von Kapitel 6.
2 Service Oriented Architecture
In diesem Kapitel wird das Konzept der serviceorientierten Softwareentwicklung beschrieben. In Abschnitt 2.1 werden zun¨achst die Idee und die Zielsetzung von Service Oriented Architecture be- schrieben, und die Notwendigkeit einer solchen Architektur wird aufgezeigt. Das eigentliche Model zur Umsetzung dieser Architektur wird in Abschnitt 2.2 formuliert und erkl¨art.
2.1 Motivation
Das Ziel von Softwareentwicklung ist es zuverl¨assige Software zu entwerfen, die leicht zu warten und wiederzuverwenden ist. In der Praxis sind diese Anforderungen jedoch kaum zu erreichen. Soft- ware wird meist zu komplex, um sie sp¨ater zu warten oder weiterzuentwickeln, wenn sie zuverl¨assig
sein soll. Das Ziel des Konzepts einer serviceorientierte Architektur ist es daher, die Wiederver- wendbarkeit von Software zu erleichtern und somit zuverl¨assige Software schneller und einfacher zu entwickeln. Diese Zielsetzung wird im Folgenden n¨aher beschrieben.
2.1.1 Zielsetzung
Bei der Softwareentwicklung treten immer wieder dieselben Probleme auf, und große Teile ei- ner Software finden auch in ¨ahnlicher Form Verwendung in anderen Softwareprodukten. Daher ist es sinnvoll, nicht jede Software von Grund auf neu zu entwickeln, sondern andere, bew¨ahrte Software wiederzuverwenden. Dies reduziert den Entwicklungsaufwand erheblich, da sowohl Code wiederverwendet wird und somit nicht neu geschrieben werden muss als auch dadurch, dass die wiederverwandte Software bereits getestet und sich als zuverl¨assige erwiesen hat. Damit werden wiederholte Fehler vermieden. Um dieses Ziel zu erreichen, wurde das Konzept der Service orien- tierten Architektur entwickelt. Die Idee hierbei ist es, die Wiederverwendbarkeit von Software zu erleichtern, indem die Abh¨angigkeiten der einzelnen Softwaremodule auf das Notwendige reduziert werden.
Abh¨angigkeiten und Loose Coupling Es gibt zwei Arten von Abh¨angigkeiten, die unterschie- den werden m¨ussen. Zum einen gibt es die notwendigen Abh¨angigkeiten, welche die wiederzuver- wendenden Teile der Softwareprodukte betreffen. Diese Abh¨angigkeiten sind gewollt, da diese die Wiederverwendung von Code erm¨oglichen. Auf der anderen Seite gibt es aber auch ungewollte Ab- h¨angigkeiten zwischen den einzelnen Softwareprodukten, welche die Zusammenarbeit erschweren.
Somit ist es Ziel einer Service-orientierten Architektur, diese Abh¨angigkeiten auf ein Minimum zu reduzieren, da sich diese Abh¨angigkeiten nicht ganz vermeiden lassen.
He [11] vergleicht die Abh¨angigkeiten von Software mit der Abh¨angigkeit von Strom. Der Mensch braucht den Strom, um seine elektrischen Ger¨ate zu betreiben, egal in welchem Land er sich befindet. Dies entspricht der direkten und gewollten Abh¨angigkeit. In jedem Land gibt es Strom, der genutzt werden kann. Allerdings gibt es auch noch die ungewollte Abh¨angigkeit von ei- nem Adapter, um die Steckdosen in den einzelnen L¨andern benutzen zu k¨onnen. Dies ist l¨astig und erschwert die Nutzung des Stroms unn¨otig. Der Adapter entspricht hierbei einer unzureichenden Schnittstellenkompatibilit¨at bei Software.
Wenn alle ungewollten, k¨unstlichen Abh¨angigkeiten in einem System minimiert sind, spricht man vonLoose Coupling. Dieser Zustand soll durch Service-Oriented Architecture erreicht werden, um die Softwareentwicklung zu vereinfachen, ohne Einbußen bei der Zuverl¨assigkeit zu erhalten.
2.2 Das Service Oriented Model
In diesem Abschnitt wird das Model zur Umsetzung einer Service orientierten Architektur be- schrieben. Dazu m¨ussen zun¨achst die Grundbegriffe in Abschnitt2.2.1 definiert werden. In dem Abschnitt 2.2.3 werden die Bedingungen, welche an eine Service orientierte Architektur gestellt werden, n¨aher erl¨autert.
2.2.1 Definitionen
Zur Beschreibung der Service Oriented Architecture sind die Begriffe Aktion, Nachricht, Software- agent und Service notwendig. Diese Komponenten werden in den folgenden Abschnitten definiert.
Aktionen und Nachrichten – Die serviceorientierte Architektur fokussiert die Interaktion ver- schiedener Softwareagenten. Eine Aktion in einem Service orientierten Modell ist hierbei jede Art von T¨atigkeit, die ein Softwareagent ausf¨uhrt. In Anlehnung an das W3C [8] l¨asst sich eine Aktion in einer serviceorientierten Architektur wie folgt definieren:
• Entweder das Senden einer Nachricht
• oder das Bearbeiten einer empfangenen Nachricht
• oder auch jede Art von T¨atigkeit eines Agenten, die das System in den erw¨unschten Zielzustand ¨uberf¨uhrt.
Eine Aktion wird von einem Softwareagenten auf Wunsch eines anderen ausgef¨uhrt, um einen geforderten Service zu leisten. In der serviceorientierten Architektur liegt der Fokus hierbei auf dem Senden und Empfangen von Nachrichten, um einen Service anzufordern beziehungsweise einen Service zu leisten.
Im folgenden ist zu definieren, was genau unter einem Softwareagenten verstanden wird.
Softwareagenten – Softwareagenten sind Programme, welche zum einen Services anfordern und welche zum anderen angeforderte Services bearbeiten. Laut W3C [8] lassen sich Software- agenten im Kontext einer Service orientierten Architektur wie folgt definieren:
Softwareagenten sind Programme, welche
• einem Besitzer geh¨oren,
• einen oder mehrere Services von anderen Agenten anfordern
• einen oder mehrere Services f¨ur andere Agenten leisten.
Es ist wichtig zu beachten, dass Softwareagenten im Auftrag eines Eigners agieren, da eine Aktion durchaus mit einem Ressourcen Austausch einhergehen k¨onnen.
Service – Ein Service wird von einem Provideragenten f¨ur einen Kundenagenten bereitgestellt. Der Service ist im Besitz des Providers und wird vom Kunden angefordert. Ein Serviceleistung ist immer verbunden mit einer Aktion, die von den korrespondierenden Softwareagenten ausgef¨uhrt wird. Ein Service besteht aus einer oder mehreren Aufgaben, die von einem oder mehreren Serviceprovidern f¨ur den anfordernden Softwareagenten ausgef¨uhrt werden. Die Services werden ¨uber zuvor beschriebene Schnittstellen durch Softwareagenten ausgetauscht.
2.2.2 Modellformulierung
Das Ziel einer Service orientierten Architektur ist es Separation of Concerns im Bereich Softwa- reentwicklung zu erreichen. Das heißt, nicht jede Software wird von Grund auf neu entwickelt, sondern bereits bestehende Software wird wiederverwendet, durch die Nutzung verschiedener Ser- vices. Die Nutzung eines externen Services ist dabei sowohl billiger als auch effektiver. Der Vorteil der Servicenutzung beruht dabei auf dem Prinzip der Arbeitsteilung. Jeder Service deckt einen speziellen Bereich ab, auf den die Entwickler dieser Services spezialisiert sind. Das heißt, durch den Einsatz von Services nutzt man f¨ur die jeweiligen Teile der Software Expertenwissen aus diesem Gebiet.
Um die Wiederverwendbarkeit einfach und realisierbar zu machen, mussLoose Coupling zwi- schen den einzelnen Softwareagenten sichergestellt werden. Dazu sind die folgenden architekturellen Bedingungen notwendig:
• Einfache Schnittstellen f¨ur die Softwareagenten
• Deskriptive und erweiterbare Nachrichten
Da diese Bedingen an die Architektur sehr wichtig sind, werden sie in dem folgenden Abschnitt n¨aher erl¨autert.
2.2.3 Bedingungen
Die Anforderungen an eine Service-Oriented Architecture beziehen sich zum einen auf die Schnitt- stellenimplementierung und zum anderen auf den Aufbau der Nachrichten, die zwischen den ein- zelnen Softwareagenten ausgetauscht werden.
Interfaces – Eine gute Schnittstellenbeschreibung und -implementierung ist besonders wichtig, um k¨unstliche Abh¨angigkeiten zu vermeiden und soLoose Coupling zu erreichen. Wenn die Schnittstellen nicht einfach und von ¨uberall zu erreichen sind, erschweren diese die Zusam- menarbeit verschiedener Softwareagenten anstatt diese zu vereinfachen. Es ist daher sinnvoll, sich auf wenige generische Schnittstellen f¨ur alle Softwareprojekte zu beschr¨anken.
Messages – Da nur wenige generische Schnittstellen zur Softwareentwicklung genutzt werden, werden Nachrichten ben¨otigt, um anwendungsbezogene Semantik zu integrieren. Die Nach- richten werden von den Softwareagenten via der beschreibenden Schnittstellen ausgetauscht.
Um einen reibungslosen Ablauf zu garantieren, m¨ussen die ausgetauschten Nachrichten jedoch folgende Anforderungen erf¨ullen: Die Nachrichten m¨ussen
• deskriptiv sein,
• in einem einheitlichen Format, einer gegebenen Struktur und einem bestimmten Alpha- bet vorliegen,
• erweiterbar sein.
Nachrichten m¨ussen deskriptiv sein, denn der Einsatz von Services soll die Nutzung von Ex- pertenwissen erm¨oglichen. Enthalten die Nachrichten jedoch Angaben, wie eine bestimmte Anfrage auszuf¨uhren ist, wird die Probleml¨osung vorgegeben und der Einsatz der Services ist sinnlos. Die Probleml¨osung muss dem Service Provider ¨uberlassen werden, da dieser ¨uber spe- zialisiertes Wissen dazu verf¨ugt, welches durch Services f¨ur die Anwendung nutzbar gemacht wird. Daher d¨urfen die Nachrichten nur deskriptiv sein.
Die Nachrichten, welche zwischen den Softwareagenten ausgetauscht werden, m¨ussen so sein, dass sie von allen beteiligten Agenten verstanden werden. Dazu m¨ussen die Nachrichten in einem einheitlichen Format, einer gegebenen Struktur und einen bestimmten Alphabet sein.
Die Nachricht ist umso einfacher f¨ur alle Agenten zu verstehen, je restriktiver die Grammatik und das genutzte Alphabet ist.
Da die Softwaresysteme einem st¨andigen Wandel unterliegen, m¨ussen auch die Nachrichten erweiterbar sein. Je restriktiver jedoch die Grammatik und das benutzte Alphabet sind, desto schwieriger gestaltet sich die Erweiterbarkeit. Das Ziel eines guten Nachrichtendesigns muss es daher sein, diesenTrade-Off auszugleichen.
Eine weitere wichtige Anforderung an eine Service Oriented Architecture ist, dass der Ser- vice ¨uberhaupt nutzbar gemacht wird. Das heißt, der Servicekunde muss ¨uber M¨oglichkeiten verf¨ugen, den Serviceprovider ausfindig zu machen.
Stateless- vs. Stateful Service – Man kann zwei Arten von Services unterscheiden: Stateless- und Stateful Services.
Bei einem Stateless Service wird gefordert, dass jede Nachricht vollst¨andig ist. Das heißt, jede Nachricht muss alle notwendigen Informationen zur Bearbeitung bereitstellen. Das hat den Vorteil, dass der Service Provider keine Informationen zwischenspeichern muss, was die Skalierbarkeit erh¨oht. Auch die Fehlerbehandlung ist dadurch erheblich leichter, da keine Zwischenzust¨ande zu ber¨ucksichtigen sind.
Stateless Services sind jedoch nicht immer realisierbar. Ein Beispiel daf¨ur ist eine verschl¨us- selte Verbindung, welche die Sicherheit der Transaktion sch¨utzt, jedoch den Nachrichtenaus- tausch erschwert. In diesem Fall wird ein Stateful Service bevorzugt, um den Nachrichten- austausch zu erleichtern. Diese erh¨ohte Kopplung von den Softwareagenten reduziert jedoch die Skalierbarkeit.
3 Web Services
Die Gedanken der serviceorientierten Architektur spiegeln sich bei Web Services wieder. In diesem Kapitel wird zuerst auf den Begriff Web Services eingegangen.
3.1 Was sind Web-Services?
3.1.1 Das Web – Heute und Morgen
Die St¨arke des World Wide Web (WWW) ist heute insbesondere dadurch zu begr¨unden, dass es die M¨oglichkeit bietet, interaktiv auf Dokumente und Applikationen zuzugreifen. Ein solcher Zugriff erfolgt, durch einen Anwender gesteuert, mittels Web-Browsern, Audio-Abspielger¨aten, Peer2Peer- Clients oder anderer interaktiver Systeme. Das Web wird laut W3C [10] stark an M¨achtigkeit und Umfang zunehmen wenn es um die F¨ahigkeit der Kommunikation zwischen Applikationen erweitert wird, welche die Mensch-Maschinen- durch eine Maschine-Maschine-Kommunikation erg¨anzt. Die- sen Wandel beschreibt He [11] durch den Vergleich zwischen Web Services im B2B1mit Browsern im B2C2-Bereich.
Cerami [1] beschreibt das Web von heute als ein Human Centric Web, in dem Menschen die Hauptakteure sind, welche die meisten Web-Anfragen initiieren. Die Erweiterung um interagierende Applikationen f¨uhrt zu einemApplication Centric Web. In einem solchen Netz kommen Applikatio- nen durch Web Services als Akteure immer mehr in den Vordergrund. Das Ziel dieser Erweiterung ist es, die Kommunikation zwischen Programmen so einfach zu gestalten wie die zwischen Browsern und Servern.
3.1.2 Beispiele
Die m¨oglichen Einsatzgebiete von Web Services sind vielseitig: Zum einen gibt es die so genannten Komponentendienste.Beispiele hierf¨ur w¨aren W¨ahrungsumrechnung, ¨Ubersetzungen, ¨Uberpr¨ufung von Kreditkarten, B¨orsenkurse, Frachtverfolgung, Flug- und Bahnpl¨ane, Shopping-Bots oder Au- torisierungsdienste. Des Weiteren gibt es so genanntezusammengesetzte Dienste. Diese verbinden die Funktionalit¨at verschiedener Komponenten, um einen gr¨oßeren, zusammengesetzten Dienst zu erf¨ullen. Hierunter fallen Reklamationsbearbeitung oder Reisebuchungen.
Web Services beschr¨anken sich aber nicht nur auf reine Applikationsinteraktionen, sondern be- ziehen sich auch auf die klassische Kommunikationsform zwischen Anwendern und Servern mittels Webseiten. Web Services k¨onnen zu einer starken Entkopplung von Pr¨asentation und Inhalten auf Internetseiten f¨uhren. Eine starke Auspr¨agung dessen w¨are es, Internetseiten nur als Container zu betrachten. Die eigentlichen Seiteninhalte w¨urden von der Gesch¨aftslogik via parametrisierter Web-Service-Aufrufe angefordert. Somit k¨onnen sowohl Anwendungen als auch Anwender einen Service nutzen.
Web Services sind nichts von Grund auf Neues. Seit Jahren werden zur Interaktion zwischen Programmen z.B. CGI-Skripte oder Java Servlets eingesetzt. Hierbei handelt es sich aber laut Cerami [1] eher um Ad-hoc-L¨osungen. Web Services bieten hier eine Standardisierung, die die Integration verschiedener Applikationen erleichtert.
3.1.3 Definition
F¨ur den Begriff Web Service gibt es keine einheitliche, allgemein anerkannte Definition. Cerami [1]
versteht unter Web Services ein Paradigma zum Erstellen von verteilten Web-Applikationen. Er definiert Web Services wie folgt:
A web service is a service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language.
1Business-to-Business
2Business-to-Customer
Coyle [2] bezeichnet Web Services folgendermaßen:
Web Services is a technology and process for discovery and connection.
Eine ausf¨uhrlichere Definition von Web Service gibt IBM [13]:
Web services are a new breed of Web application. They are self-contained, self- describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes. [...] Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.
Die einzelnen Definitionsans¨atze werden im Folgenden n¨aher beschrieben und diskutiert.
Web Services sind laut der ersten Definition ¨uber das Internet nutzbar, wohingegen die dar- auf folgenden zwei Definition das Einsatzgebiet von Web Services nicht nur auf das Internet be- schr¨anken. Web Services sind danach in allen auf Internettechnologien aufbauenden Netzen, wie beispielsweise auch dem Intranet, einsetzbar. Das Internet wird, nach Vasudevan [15], bevorzugt als Kommunikationsmedium f¨ur Web Service Applikationen genutzt, was Vasudevan [15]durch Ein- fachheit und Allgegenw¨artigkeit des Webs begr¨undet. Mit Einfachheit ist hierbei die geringe Anzahl an Protokollen und deren einfacher Funktionalit¨at gemeint. Die wichtigsten Protokolle im Inter- net sindHTTP,SMTP undFTP. Der Funktionenumfang vonHTTPbeispielswise, kann durch die drei HauptfunktioneGET,POSTundPUTbeschrieben werden. Nutzt man das Internet als Plattform f¨ur den Einsatz von Web Services, kann man also eine vorhandene Infrastruktur mit bekannten und bew¨ahrten Protokollen nutzen. Der zweite große Vorteil des Internets als Kommunikationsmedi- um f¨ur Web Services bezieht sich auf die Verbreitung oder auch Allgegenw¨artigkeit des Internets.
Das Internets ist von nahezu ¨uberall zug¨anglich. Firewalls und Proxyserver, welche f¨ur gew¨ohnlich Internet-Clients von internen Servern separieren, sind f¨ur Web Services dank der zugrundeliegen- den Standard-Protokolle keine große H¨urde, weshalb auch spezielle Anforderungen an die Sicherheit von Web Services sicherzustellen sind.
Laut der ersten Definition von Web Services eignet sich XML besonders gut als Datenstruktur f¨ur Web Services aufgrund der Trennung von Struktur, Inhalt und Form sowie der Erweiterbarkeit von XML. Desweiteren ist XML weit verbreitet und bietet den Vorteil, dass sowohl die Wohl- geformtheit, als auch die Validit¨at des Dokument leicht ¨uberpr¨uft werden k¨onnen. Des weiteren gibt es bereits viele Programmiersprachen f¨ur den Einsatz von XML, wie beispielsweise XSLT zur Transformierung von XML Dokumenten oder XPath und XQuery als Abfragesprachen.
Die Unabh¨angigkeit von Betriebssystemen und Programmiersprachen ist ein wesentlicher Be- standteil f¨ur die erste Definition von Web Services. Agenten, die Web Services nutzen, k¨onnen Handys, PDAs, PCs und Legacysysteme sein, aber auch andere, exotischere Plattformen wie z.B.
Parkuhren oder Cola-Automaten. Daher ist die Forderung der Unabh¨angigkeit f¨ur Web Services unabdingbar.
Wie bereits in Abschnitt 3.1.2 beschrieben, handelt es sich bei Web Services um nichts von Grund auf Neues. Vergleichbare Funktionalit¨at der Services wurden und werden durch Middleware- Technologien wie RMI, JINI, CORBA, DCOM oder EJB zur Verf¨ugung gestellt. Ihre St¨arken liegen in einer gut administrierten aber abgeschlossenen Server-to-Server Kommunikation. Das Hauptproblem dieser Middleware-Technologien liegt an der schwer erreichbaren Interoperabilit¨at.
Hinzu kommt eine große Anzahl an Programmiersprachen, -paradigmen und Plattformen was eine Orchestrierung und Integration dieser Services weiter erschwert. Die Benutzung eines Web Service ist dagegen sehr viel transparenter und verh¨alt er sich aus Anwendersicht wie eine Black Box.
Die Definition von IBM hebt hervor, dass Web Services selbstbeschreibend sind. Die Beschrei- bung eines Web Services enth¨alt Angaben zu allen ¨offentlich verf¨ugbaren Interfaces zu einem be- stimmten Service, die damit verbundenen Datentypen, das zu verwendende Transportprotokoll sowie die Adresse, wo der Service aufrufbar ist. In der Regel erfolgt eine solche Beschreibung via WSDL (siehe Kapitel 4.2).
Nach der Definition von IBM haben Web Services einen modularen Aufbau. Dieser Aufbau hat viele Vorteile, zum Beispiel die Zusammensetzung einer Dienstleistungen aus mehreren Komponen- ten. So k¨onnte beispielsweise ein Verlag wie Springer online auf spiegel.de verschiedene Artikel oder Dossiers anbieten. Zur Authentifizierung der Benutzer sowie der Abrechnung diverser Geb¨uhren m¨usste dieser aber kein eigenes System entwickeln, sondern k¨onnte hierzu auf bereits entwickel- te und bew¨ahrte Module anderer Anbieter wie beispielsweise Microsofts Passport oder FirstGate zur¨uckgreifen. Die Vorteile eines modularen Aufbaus wie Code-Wiederverwendung, zentrale ¨Ande- rungen,Validit¨atoderSeparation of Concerns sind aus dem Bereich Software Engineering bekannt und finden hier Anwendung.
Ein weitere wichtiger Bestandteil der Web Service-Architektur sind logisch zentrale, verteilte Verzeichnisse, anhand welcher ein bestimmter Service gefunden werden kann. Ist ein passender Service gefunden, muss eine Beschreibung vorhanden sein, wie er aufzurufen ist. Dies setzt eine Registrierung des Services bei einem solchen Verzeichnis voraus. Hierf¨ur wird haupts¨achlich UDDI (siehe Kapitel 4.3) eingesetzt.
3.1.4 Vision
Die Vision von Web Services ist ein Automated Web, das die Integration von Web Services au- tomatisiert. Grundlage hierf¨ur sind leicht auffindbare, selbstbeschreibende und sich an Standards haltende Services. In der Industrie wird diese Vision auch alsJust In Time Application Integration bezeichnet.
Am Anfang der JIT-Idee steht das Abfragen von Service-Registern. Eine Automation setzt das Verstehen der Ergebnisse voraus und eine darauf aufbauende Auswahl der passenden Dienstleistun- gen. Neben einer Vielzahl von Programmen f¨ur diese Aufgabe ist immer noch ein gewisser Grad an menschlicher Interaktion n¨otig. Das automatische Aufrufen der ausgew¨ahlten Services stellt aufgrund einer großen Softwarepalette und einheitlicher Standards kein Problem dar. Auch wenn die beschriebenen Schritte v¨ollig automatisiert ablaufen, existieren noch keine Mechanismen um Gesch¨aftsprozesse v¨ollig zu automatisieren. Gegenw¨artige Servicebeschreibungen enthalten keine Aussagen ¨uber Preis, Lieferbedingungen wie zum Beispiel Zeit sowie rechtliche Aspekte, beispiels- weise bei Nichterf¨ullung der Lieferung. Auch ¨uber den Entwicklungsgrad des Services und dessen Verf¨ugbarkeit fehlen Angaben. Diese Aufgaben sind nicht einfach zu l¨osen und dadurch auch nicht einfach zu automatisieren. Cerami [1] behauptet aufgrund dieser Probleme, dass eine JIT Applica- tion Integration nie realisiert werden wird. Dennoch bringen uns Web Service Technologien einen Schritt n¨aher an die Vision des Automated Webs.
3.2 Web-Service-Architektur
Es gibt zwei Sichtweisen um die Web Service Architektur n¨aher zu betrachten: Zum einen die Web Service Roles und zum anderen den Web Service Protocol Stack.
3.2.1 Web Service Roles
Innerhalb der Web-Service-Architektur gibt es drei Hauptrollen: Service Provider, Service Reque- stor und Service Registry. In Abbildung 1 sind die beschriebenen Rollen und deren Interaktion veranschaulicht.
Service Provider – Service Provider sind die Anbieter des Services. Sie implementieren den Ser- vice und ver¨offentlichen dessen Beschreibung und dessen Schnittstellen ¨uber das Internet.
Service Requestor – Service Requestors sind alle m¨oglichen Kunden des Services. Der Kunde benutzt den Service indem er eine Netzwerkverbindung aufbaut, einen evtl. parametrisierten Request sendet und den erw¨unschten Service als Antwort darauf erh¨alt.
Abbildung 1: Web Service Rollen
Service Registry / Broker – Bei einer Service Registry handelt es sich um ein zentrales, logi- sches Verzeichnis von Services. Die Registry ist eine zentraler Punkt, via welcher Entwickler ihre Services ver¨offentlichen k¨onnen und Kunden existierende auffinden k¨onnen.
3.2.2 Web Service Protocol Stack
Die Hauptschichten des Web Service Protocol Stack sind Service Transport, XML Messaging, Service Description sowie Service Discovery (siehe Abbildung 2). Nachfolgend werden diese Begriffe kurz erl¨autert. In den nachfolgenden Abschnitten werden diese dann ausf¨uhrlicher behandelt.
Abbildung 2: Web Service Protocol Stack
Service Transport – Die Service-Transport-Schicht ist f¨ur den Transport der Nachrichten zwi- schen den Applikationen verantwortlich. Wie bereits beschrieben nutzen Web Services die vorhandene Infrastruktur des Internets. Hierbei finden Protokolle wie HTTP, SMTP und FTP, aber auch neuere Protokolle wie z.B. das Blocks Extensible Exchange Protocol (BEEP) An- wendung.
XML Messaging – In der XML-Messaging-Schicht werden die Nachrichten in ein gebr¨auchliches, von beiden Seiten verstandenes XML-Format transformiert. Die gegenw¨artigen Technologien hierf¨ur sindSOAPundXML-RPC.
Service Description – Die Beschreibung der ¨offentlichen Schnittstelle zu einem bestimmten Web Service ist Aufgabe der Service Description Schicht. Die Beschreibung erfolgt durch die Web
Service Description Language (WSDL).
Service Discovery – Die Unterst¨utzung der Ver¨offentlichung und des Auffindens von Web Ser- vices innerhalb eines zentralen Verzeichnisses ist Aufgabe der Service- Discovery-Schicht. Das hier am verbreitetsten Protokoll ist Universal Description, Discovery and Integration Protocol (UDDI).
Im folgenden Kapitel wird auf die Basistechnologien f¨ur Web Services eingegangen. In Ab- schnitt 4.1 wird auf die SOAP Paradigma n¨aher beschrieben. Die Service-Beschreibung anhand von WSDL ist Thema von Abschnitt 4.2. UDDI als logisch zentrales, verteiltes Verzeichnis f¨ur Web Services wird in Abschnitt 4.3 behandelt.
4 Basistechnologien
Ziel diese Kapitels ist es die Basistechnologien f¨ur Web Services n¨aher zu beschreiben. Es behandelt SOAP (4.1) als Austauschformat f¨ur Nachrichten, WSDL (4.2) zur Schnittstellenbeschreibung und UDDI (4.3) als logisch zentrales, verteiltes Verzeichnis f¨ur Web Services. Im Anhang (A) sind fernen einige Beispiellistings zu den einzelnen Abschnitten vorhanden.
4.1 SOAP
In diesem Abschnitt wird SOAP n¨aher betrachtet. Er ist gegliedert in einen kurzen ¨Uberblick und die Spezifikation. Im Anhang ist ferner ein Beispiellisting einer SOAP-Nachricht ¨uberHTTP beige- f¨ugt. Die Darstellung dieses Abschnitts erfolgt in Anlehnung an das SOAP-Primer des W3C [9], Coyle [2], Deßloch [3] sowie Cerami [1].
4.1.1 SOAP – ¨Uberblick
Die SOAP3-Spezifikation [9], welche momentan in der Version 1.2 vorliegt, beschreibt abstrakt gese- hen eine auf XML basierende, strukturierte und typisierte Information. Diese kann zum Austausch zwischen Teilnehmern in einer dezentralen, verteilten Umgebung benutzt werden. Bei SOAP han- delt es sich eigentlich um ein zustandsloses, One-way-Paradigma zum Nachrichtenaustausch. Kom- plexere Interaktionsformen, wie zum Beispiel request-response oder request-multiple-responses, k¨onnen durch eine Kombination der einfachen Nachrichten mit protokollspezifischen Eigenheiten bzw. Anwendungslogik erreicht werden. Die Spezifikation macht keine Aussagen ¨uber die Semantik der zu transportierenden Daten, das Routing der Nachrichten, Verl¨asslichkeit des Transfers oder der ¨Uberwindung von Firewalls. SOAP stellt ein Framework zum Nachrichtenaustausch aufbauend auf vorhandene Protokolle wie zum Beispiel HTTP, SMTP oder FTPdar. Beschrieben werden auch die Aktionen, die ein SOAP-Knoten bei Empfang einer Nachricht auszuf¨uhren hat.
4.1.2 SOAP – Spezifikation
Nachfolgend m¨ochte ich kurz auf die Begriffe SOAP-Nachricht, SOAP Header und SOAP-Body sowie SOAP via HTTP eingehen.
SOAP-Nachrichten Das SOAP Envelope stellt das Wurzelelement einer SOAP-Nachricht dar.
Es besteht aus den beiden Teilen header und body. Die Inhalte dieser Elemente sind applikati- onsspezifisch. Es werden in der Spezifikation nur Aussagen dar¨uber gemacht, wie diese Elemente aufgebaut sind. Abbildung 3 zeigt den Aufbau einer SOAP-Nachricht.
3Die Abk¨urzung SOAP stand urspr¨unglich f¨ur Simple Object Access Protocol. Das W3C sah aufgrund des Fehlens von Objekten in der Spezifikation die Notwendigkeit zu einer Umbenennung. Aufgrund der Popularit¨at des Begriffs wurde aber darauf verzichtet; die Abk¨urzung wird aber nicht mehr als solche betrachtet: SOAP ist mittlerweile nur ein Begriff.
Abbildung 3: SOAP-Envelope – Aufbau
SOAP-Header – Dasheader-Element ist optional. Es wird haupts¨achlich dazu verwendet, Kon- trollnachrichten zu transportieren. Diese Kontrollnachrichten k¨onnen Verarbeitungshinweise oder Kontextinformationen der Nachricht beinhalten. Die einzelnen im headerenthaltenen Elemente werden alsheaderBlocksbezeichnet. Als Anwendung des header-Elements seien kurz komplexere Services zu nennen. Bei diesen Value-Added-Services gibt es neben dem ei- gentlichen Client und ersten Server mehrere Zwischenschritte. Diese Intermediaries erweitern den Service um eigene Teilservices, welche zusammengesetzt den eigentlich angeforderten Service ergeben. Die Koordination dieser Intermediaries wird ¨uber dasheader-Element ge- steuert, indem die Knoten headerBlocks interpretieren, hinzuf¨ugen oder l¨oschen. F¨ur den headergibt die Spezifikation noch zwei Attribute an: Dasactor-Attribut legt den Empf¨an- ger der Nachricht innerhalb einer Verarbeitungskette fest. Ob einheader-Element verstanden und verarbeitet werden muß legt dasmustUnderstandAttribut fest
SOAP-Body – Dasbody-Element hingegen ist Pflicht. Es enth¨alt die eigentlichen Nachrichten f¨ur die Ende-zu-Ende-Kommunikation meist in Form eines RPC request oder response, verpackt in eine XML-Syntax. Diese Inhalte sind wiederum Anwendungsspezifisch und werden deshalb nicht weiter von der SOAP-Spezifikation festgelegt. Als Erweiterung derbody-Elemente k¨on- nen Fault-Elemente angegeben werden. Diese regeln, wie von wem auf Fehler zu reagieren ist.
SOAP via HTTP Wie bereits weiter oben in diesem Kapitel erw¨ahnt ist SOAP nicht an ein spezielles Transportprotokoll gebunden. Am verbreitetsten ist wohl die Kombination von SOAP undHTTP; es sind aber auch Kombinationen mitSMTP,FTP,XMPP, IBMsMQSeriesoderMSMQvon Microsoft m¨oglich. Im Folgenden m¨ochte ich kurz auf SOAP viaHTTPeingehen.
SOAP requests werden via einesHTTPrequests und die SOAP responses entsprechend mit einer HTTP response ¨ubertragen. Hierbei k¨onnen sowohl HTTP GETals auchHTTP POST verwendet wer- den. Aufgrund der Beschr¨ankung der Zeichenanzahl bei der GET-Variante wird von den meisten Servern POST bevorzugt. Clients m¨ussen (Version 1.1) bzw. k¨onnen (Version 1.2) einen zus¨atzli- chen SOAP Action Header angeben. Dabei handelt es sich um eine serverspezifische URI. Damit ist es m¨oglich schnell und einfach die Absicht des requests zu ermitteln, ohne die SOAP-Nachricht zu untersuchen. In der Praxis wird es dazu verwendet, SOAP request abzublocken bzw. an den richtigen Server intern weiterzuleiten.
Um den Aufbau einer SOAP-Nachricht viaHTTP zu verdeutlichen habe ich im Anhang A.1.1 ein ausf¨uhrliches Listing beigef¨ugt.
4.2 WSDL
Im folgenden Abschnitt wird ein kurzer ¨Uberblick ¨uber die Web Service Description Language in Anlehnung an Cerami [1], Coyle [2], Deßloch [3], Vasudevan [15] sowie der WSDL-Spezifikation [7]
gegeben .
4.2.1 WSDL– ¨Uberblick
WSDL steht f¨ur Web Service Description Language. Es ist eine Spezifikation, in welcher festgelegt ist wie ein Web Service in einer XML Grammatik zu beschreiben ist. Zusammenfassend gesehen beinhaltet eine solche Beschreibung Angaben zu allen ¨offentlich verf¨ugbaren Schnittstellen zu einem bestimmten Service, zu den damit verbundenen Datentypen, zum verwendende Transportprotokoll sowie zur Adresse, unter welcher der Service aufrufbar ist. Cerami [1] vergleicht WSDL-Elemente mit Java Interfaces. Der Vorteil der WSDL-Elemente liegt in ihrer Plattform- und Sprachunab- h¨angigkeit. WSDL ist eine Plattform zur Beschreibung von Services und deren damit verbunden (eventuell vollautomatischen) Integration und stellt damit einen wesentlichen Eckpunkt der Web- Service-Architektur dar.
4.2.2 WSDL–Spezifikation
In der WSDL-Spezifikation werden sechs Hauptelemente beschrieben:definitions,types,messa- ge,portType,bindingundservice. Erg¨anzend werden die Elementedocumentationundimport genannt. Abbildung 4 gibt einen groben ¨Uberblick ¨uber deren Zusammenhang.
Abbildung 4: WSDL Spezifikation
Nachfolgend werden diese Elemente kurz beschrieben.
definitions –Root WSDL Element– Dasdefinitions-Element ist das Wurzelelement eines jeden WSDL-Dokuments. Es beinhaltet den Namen des Web Services, alle verwendetenNamespaces und enth¨alt die folgenden Elemente:
types –What data types will be transmitted? – Anhand dertypes-Elemente werden alle Datenty- pen, die beim Austausch zwischen dem Client und dem Server verwendet werden, beschrie- ben. Hierbei ist WSDL nicht an ein bestimmtes Typensystem gebunden. Alsdefault wird das Typensystem des W3C XML Schema verwendet.
message –What messages will be transmitted? – Diemessage-Elemente beschreiben eine einfache Nachricht, also entweder ein einzelnerrequest oder eine einzelneresponse.Sie beinhalten den Namen der Nachricht als auch Parameter bzw. R¨uckgabewerte (jeweils Name und Typ).
portType –What operations (functions) will be supported? –portType-Elemente verbinden meh- rere message-Elemente und bilden somit eine bestimmte Operationen oder Funktion. Ein portTypekann mehrere Operation beinhalten. WSDL unterst¨utzt hierbei vier Basis-Patterns
f¨ur die Kommunikation:one-way,request-response,solicit-responseundnotificati- on. Bei der one-way-Kommunikation handelt es sich um eine Nachricht von einem Client an einen Server. Dem gegen¨uber steht dienotificationals Nachricht von einem Server an einen Client. request-response beinhaltet eine Anfrage eines Clients sowie eine entspre- chende Antwort eines Servers. Beisolicit-responsesind die Rollen vertauscht. Die letzten beiden Pattern unterst¨utzten auch eine fault-Nachricht, um auf Fehler zu reagieren.
binding – How will the messages be transmitted on the wire? What SOAP-specific details are there? – Wie die Informationen im Netz ¨ubermittelt werden, wird imbinding-Element be- schrieben. M¨ogliche bindings w¨aren HTTP-PUT, HTTP-POST oder SOAP. F¨ur eine portType k¨onnen mehrerebindingsangegeben werden. Diebindings selber sind protokollspezifisch, sie sind also nicht mehr Bestandteil von WSDL.
service – Where is the service located? – Das service-Element beschreibt, wo der Service auf- gerufen werden kann. Diese Informationen sind in port-Elementen gekapselt. Jedes port- Element beschreibt die Netzwerkadresse des Endpunktes, wo der Service angeboten wird.
Das service-Element stellt somit eine Sammlung der m¨oglichen Netzwerkendpunkte f¨ur einen bestimmten Service dar.
documentation – Anhand des documentation-Elements soll eine Beschreibung in einem men- schenlesbaren Format zur Verf¨ugung gestellt werden. Dieses Element kann in jedem der an- deren beschriebenen Elemente verwendet werden.
import – Anhand des import-Elements k¨onnen andere WSDL-Dokumente oder XML-Schemata eingebunden werden. Mit ihrer Hilfe lassen sich modulare WSDL-Dokumente erstellen.
Im Anhang A.2.1 ist zur Veranschaulichung der aufgelisteten Element ein Beispiel abgebildet.
4.3 UDDI
Dieser Abschnitt soll einen kurzen ¨Uberblick ¨uber UDDI liefern. Behandelt werden der konzep- tionelle Aufbau sowie die Architektur von UDDI. Im Anhang sind ferner mehrere Beispiellistings zur Veranschaulichung beigef¨ugt. Die Darstellung dieses Abschnitts erfolgt in Anlehnung an die Texte von Vasudevan [15], Cerami [1], Coyle [2], Deßloch [3], JavaMagazin [14] sowie der UDDI- Spezifikation [4].
4.3.1 UDDI– ¨Uberblick
Die Abk¨urzung UDDI steht f¨ur Universal Description, Discovery and Integration. UDDI besteht im Grunde aus zwei Teilen: Zum einen ist UDDI eine technische Spezifikation eines verteilten Verzeich- nisses f¨ur Web Services. Die Daten sind hierzu in einem bestimmten XML-Format abzuspeichern.
F¨ur das Ver¨offentlichen und Suchen enth¨alt die UDDI-Spezifikation eine API. Zum anderen ist die UDDI Business Registry, auch unter dem Namen Cloud Service bekannt, eine voll funktionsf¨ahige Implementierung der UDDI-Spezifikation. Die UDDI Business Registry wurde von IBM und Micro- soft im Mai 2001 gestartet. Hierbei handelt es sich um ein globales, ¨offentliches Onlineverzeichnis zur Beschreibung des Services und dessen Schnittstelle als auch zum Auffinden bestimmter Web Services. Die Hauptfunktionen, die UDDI anbietet sindpublish, findund bind. Vasudevan [15]
vergleichtUDDImitCorba Tradern oder einemDNSService f¨ur Gesch¨aftsanwendungen.
Die f¨ur UDDI relevanten Daten lassen sich in drei Kategorien einteilen:
White Pages – Who am I? – Diese Kategorie enth¨alt allgemeine Informationen ¨uber ein be- stimmtes Unternehmen. Darin k¨onnen zum Beispiel Name, Anschrift, Telefonnummern, In- ternetadresse und weitere Kontaktinformationen sowie eine kurze, evtuell mehrsprachige Be- schreibung der Unternehmung und deren Ziele enthalten sein. Diese Informationen werden in einembusinessEntity-Objekt (siehe Abschnitt 4.3.2) abgespeichert.
Yellow Pages – What do I offer? – Yellow Pages stellen einen Klassifikation der Unternehmen oder der angebotenen Services dar. Dabei k¨onnen Informationen wie die Branche, Produkte oder geographische Codes enthalten sein. Auch hierf¨ur existiert eine Datenstruktur, n¨amlich diebusinessService-Objekte (siehe Abschnitt 4.3.2).
Green Pages – How to do business with me? – Hierbei handelt es sich um die technischen In- formationen eines Web Services. Enthalten sind ein Verweis auf eine (externe) Spezifikation sowie eine Adresse ¨uber welche der Service aufgerufen werden kann. Die Details der Service Spezifikation k¨onnen ¨uber tModels(siehe Abschnitt 4.3.2) abgefragt werden. Dies sind Me- tadaten ¨uber die verschiedenen Web Services. N¨ahere Informationen ¨uber die Adresse enth¨alt dasbindingTemplate(siehe Abschnitt 4.3.2).
UDDI ist nicht auf Web Services beschr¨ankt, die auf SOAP basieren. Es kann dazu benutzt werden, jegliche Art von Service, angefangen von einer einfachen Webseite oder eMail Adresse bis hin zu CORBA und Java RMI Services zu erfassen.
4.3.2 UDDI–Architektur
Die UDDI-Architektur besteht aus den drei Teilen UDDI Data Model, UDDI API und UDDI Cloud Service.
UDDI-Datenmodell UDDI beinhaltet ein XML-Schema welches die vier Kernklassen an In- formation beschreibt: businessEntity, businessService, bindingTemplate und tModel. Ab- bildung 5 gibt einen ¨Uberblick ¨uber das UDDI Data Model. Die einzelnen Elemente werden im Folgenden kurz erl¨autert.
Abbildung 5: UDDI Data Mode
businessEntity – DasbusinessEntityElement enth¨alt Informationen ¨uber ein bestimmtes Un- ternehmen. Die beinhalteten Informationen fallen unter die Kategorie White Pages (siehe Abschnitt 4.3.1). Diese beinhalten den Namen der Unternehmung, eine Beschreibung, Adres- se und weitere Kontaktinformationen wie Telefon, eMail oder URLs.
JedesbusinessEntity-Objekt erh¨alt eine eindeutige ID, denbusinessKey. Dadurch werden verschiedene Services an eine Unternehmung gebunden. Zus¨atzlich zu den oben genannten, normalen Identifikatoren kann einbusinessEntity-Objekt weitere Elemente zur Identifika- tion wie zum Beispiel eine Dun-&-Bradstreet-Nummer4oder eine Thomas Registry Supplier ID5 enthalten. Eine Unternehmung kann sich auch in verschiedene Gesch¨aftskategorien ein- ordnen. Hierbei werden Standardklassifikationen wie NAICS6, UNSPSC7und ISO 31668von UDDI unterst¨utzt.
Im Anhang A.3.1 ist exemplarisch ein solchesbusinessEntityaufgelistet.
businessService – Das businessService-Object repr¨asentiert Daten eines einzelnen oder einer Gruppe verwandter Web Services aus den Yellow Pages (siehe Abschnitt 4.3.1). Sie beinhalten den Namen des Services, eine Beschreibung und eine Liste vonbindingTemplatessowie zur Zuordnung zu dem anbietenden Unternehmen die ID des entsprechendenbusinessEntities.
Wie diebusinessEntity-Objekte haben auch diese eine eindeutige ID.
Auch f¨ur die businessService-Objekte ist im Anhang A.3.2 ein Beispiel aufgef¨uhrt.
bindingTemplate – Die Informationen wo und wie man einen bestimmten Web Service Aufru- fen kann erh¨alt man ¨uber bindingTemplate-Objekte. Sie sind Teil der businessService- Objekte. Diese bindings sind nicht auf HTTP-basierte Services beschr¨ankt, sondern unter- st¨utzten auch eMail-, Fax-, FTP- und Telefonbasierte Services oder einfach eine Homepage.
Das Wie wird durch die referenziertentModelsn¨aher spezifiziert.
tModel – Die tModels(technical Model) werden als Zeiger auf externe technische Spezifikatio- nen eingesetzt. Diese Spezifikationen enthalten haupts¨achlich die Details, wie man mit einem bestimmten Web Service kommuniziert. Meistens dient hierf¨ur eine WSDL Datei (siehe Ka- pitel 4.2), aber auch eine normale Homepage als Anleitung ist ausreichend. Die Formulierung haupts¨achlich deshalb, weiltModelsneben den Kommunikationsdetails auf jegliche externe Spezifikationen und auf sich selbst verweisen k¨onnen. Darunter f¨allt zum Beispiel auch die weiter oben beschriebene Duns-&-Bradstreet-Nummer.
Ein Beispiel f¨ur ein solchestModelist im Anhang A.3.3 abgebildet.
UDDI-API Die UDDI-API deckt die Funktionalit¨at zum Ver¨offentlichen und Suchen von Ein- tr¨agen ab. Sie ist SOAP-basiert (siehe Kapitel 4.1) und kann ¨uber Web-Interfaces9 10 oder Pro- gramme11 12 13 benutzt werden. Die Tabelle 1 im Anhang gibt einen kurzen ¨Uberblick ¨uber die zur Verf¨ugung gestellten Funktionen.
UDDI Cloud Service Bei den UDDI Cloud Services handelt es sich um Vermittlungsseiten als Implementierung der UDDI-Spezifikation. Sie werden von Microsoft und IBM angeboten. Die Cloud Services stellen ein logisch zentrales aber physisch verteiltes Verzeichnis f¨ur Web Services dar. Dies bedeutet, dass Daten die bei einem Knoten registriert werden in regelm¨aßigen Abst¨anden auf allen weiteren Knoten repliziert werden.
Unternehmen haben intern die M¨oglichkeit, ein privates UDDI Verzeichnis mit firmeninternen Web Services aufzubauen. Diese werden nicht mit den ¨Offentlichen synchronisiert und sind somit nicht Teil der UDDI Cloud.
4Dun & Bradstreet D-U-N-S Nummer (Data Universal Numbering System). Verzeichnis mit ¨uber 62 Millionen registrierten Unternehmen (und Filialen).http://www.dnb.com/US/duns update/index.html
5Eindeutige ID f¨ur US Amerikanische und Kanadische Unternehmen.http://www.thomasregister.com
6North American Industry Classification System.http://www.naics.com
7Universal Standard Products and Service Classification. ECCMA Standard.http://www.unspsc.org
8International Organization for Standardization.http://www.din.de/gremien/nas/nabd/iso3166ma/index.html
9Microsoft UDDI site:http://uddi.microsoft.com
10IBM UDDI site:http://www-3.ibm.com/services/uddi
11Java: uddi4j.http://oss.software.ibm.com/developerworks/projects/uddi4j
12Microsoft.com:http://uddi.microsoft.com/developer/
13Perl:http://www.soaplite.com
5 Alternative Ans¨ atze f¨ ur Web Service
Bisher wurden Web Services auf Basis von SOAP, WSDL und UDDI vorgestellt. In diesem Kapitel m¨ochte ich kurz auf zwei alternative Ans¨atze f¨ur Web Services eingehen: XML-RPC und REST.
5.1 XML-RPC
In diesem Abschnitt wird, in Anlehnung an die XML-RPC Spezifikation [16], das XML-RPC- Konzept vorgestellt. Im Anhang A.4 ist ein Listing eines kompletten Beispiels aufgef¨uhrt.
XML-RPC erm¨oglicht Programmen einen Funktions- oder Methodenaufruf ¨uber ein Netzwerk auszuf¨uhren. Als Transportprotokoll zwischen Client und Server wird dasHTTP Protokoll verwen- det. Die Anfragen und Antworten werden mit Hilfe eines kleinen XML-Vokabulars kodiert. Die Clients geben lediglich einen Methodennamen und eine Liste mit Parametern an. Die Antwort des Servers ist entweder eine Liste von Ergebniswerten im Erfolgsfall oder ansonsten eine Fehler- nachricht. Bei den Parametern bzw. Ergebniswerten handelt es sich um einfache Typ-Wert-Paare.
Die unterst¨utzten Typen sind beschr¨ankt auf int,double,boolean, string,dateTime.iso8601 sowiebase6414. Des weiteren k¨onnen diese Basistypen instructs15undarrays16angeordnet wer- den. XML-RPC unterst¨utzt weder Objekte noch ist eine Erweiterung des Vokabulars um weitere Informationen m¨oglich.
Bei XML-RPC handelt es sich um ein einfaches Konzept mit beschr¨ankten M¨oglichkeiten. Diese Einfachheit und Beschr¨anktheit machen jedoch die Attraktivit¨at von XML-RPC aus. Die Verwen- dung von XML-RPC erlaubt es den Programmierern, sich auf die Schnittstellenimplementierung zu konzentrieren und nicht auf das zu verwendende Protokoll. Auch der Aufwand f¨ur Testen und Dokumentation l¨asst sich dadurch reduzieren.
5.2 REST
Neben SOAP und XML-RPC gibt es eine weitere Alternative f¨ur die Realisierung von Web Services.
Thomas Roy Fielding beschreibt in seiner Dissertation [5] einen Architekturstil, den er REpresen- tational State Transfer oder kurz REST nennt. In diesem Abschnitt wird REST kurz in Anlehnung an OIO [12] dargestellt.
Bei REST handelt es sich nicht um ein Produkt oder einen Standard, sondern um einen Archi- tekturstiel f¨ur Web Services. Hierbei orientiert sich REST an den Prinzipien des World Wide Web.
Im Grunde stellt das WWW selbst eine gigantische REST-Anwendung dar.
Die so genannte Welt von REST besteht aus Ressourcen, Repr¨asentationen, Methoden und Nachrichten, welche im folgenden beschrieben werden:
Ressourcen – Ressourcen k¨onnen zum Beispiel Webseiten, Bilder oder Servlets sein und werden
¨
uber URIs adressiert und angesprochen. Eine Webanwendung wird hierbei als eine Ansamm- lung von Ressourcen gesehen. Mit HTTP k¨onnen Nachrichten an die Ressourcen gesendet werden. Ressourcen k¨onnen nur indirekt ¨uber deren URI manipuliert werden.
Repr¨asentationen – Unter der Repr¨asentation einer Ressource versteht man die Form, in welcher sie vom Server bereit gestellt wird. Hierbei kann es sich um Webseiten, Bilder oder um strukturierten Text in Form von XML handeln. Sie kann auf weitere Ressourcen verweisen.
Folgt ein Client einem Link in einer Repr¨asentation, so gelangt er von einem Zustand in einen anderen.
Methoden – Die Semantik der HTTP-Methoden GET, PUT, POST und DELETE wurden von REST
¨ubernommen. Sie stellen die Verben dar, die auf dieHauptw¨orter bzw. die Ressourcen an- gewandt werden k¨onnen. Durch diese vier Methoden besitzt jede REST-Ressource eine ge- nerische Schnittstelle, mit welcher alle Anwendungsf¨alle abgedeckt werden m¨ussen. Durch
14Bin¨arinformation, siehe RFC 2045
15structssind Name-Typ-Werte-Paare und somit vergleichbar mit HashTables
16hierbei werden auch gemischte und mehrdimensionale Arrays unterst¨utzt.
dieses generische Schnittstelle m¨ussen bei REST keine Protokoll-Konventionen bekannt sein, damit Client und Server sich verst¨andigen k¨onnen. Die Bedeutung der einzelnen Methoden soll folgend kurz beschrieben werden:
• GETfragt die Repr¨asentation einer Ressource ab. Solche Anfragen sind frei von Seiten- effekten.
• POSTf¨ugt einer Ressource etwas hinzu. Im Gegensatz zuPUTistPOSTmit Seiteneffekten behaftet.
• PUTerzeugt neue Ressourcen bzw. ersetzt den Inhalt bereits bestehender Ressourcen.
• DELETEl¨oscht Ressourcen.
Diese Schnittstelle ist mit den aus SQL bekannten generischen Methoden SELECT, INSERT, UPDATEundDELETEvergleichbar.
Nachrichten – F¨ur die Anwendung von REST muss kein neues Nachrichtenformat erlernt wer- den: via REST k¨onnen s¨amtliche Datenformate ¨ubertragen werden. F¨ur die Interpretation einer REST-Nachricht ist serverseitig kein Kontext n¨otig. Alle vom Server ben¨otigten In- formationen zur Verarbeitung einer Nachricht m¨ussen in dieser enthalten sein. Dies h¨angt damit zusammen, dass der Server nur seinen eigenen Zustand kennt. Auch Sessions werden vom Server nicht unterst¨utzt. Somit ist der Client selber f¨ur seinen Status und die Reihen- folge seiner Funktionsaufrufe verantwortlich. Geht es um die Authentifizierung von Clients bei einem Server, so wird auf bereits vorhandene Webtechnologien wie HTTP oder HTTPS zur¨uckgegriffen.
Abschließend wird zur Veranschaulichung ein kurzes, vereinfachtes Beispiel einer REST basier- ten Online-Buchhandlung aus Sicht eines Kunden gegeben.
Unser Kunde interessiert sich f¨ur Java B¨ucher des Verlags Prentice Hall. Die Suchanfrage k¨onnte lauten:
GET /book/byPublisher/PrenticeHall
Als Ergebnis erh¨alt er eine XML-Nachricht aller Java-B¨ucher des Verlags. Sein Interesse gilt dem Buch Java - Volume II Advanced Features mit der Artikelnummer 0-13-092738-4. Durch die An- frage
GET /book/byID/0-13-092738-4
erh¨alt er die Details. Er ist begeistert und m¨ochte sich das Buch sofort bestellen. Dazu muss er sich zun¨achst einen Warenkorb einrichten:
PUT /Warenkorb
Die Antwort enth¨alt die ID seines Warenkorbs, in unserem Beispiel die 78554. Als n¨achstes muss das Buch in den Warenkorb gelegt werden:
POST /Warenkorb/78554 book/0-13-092738-4
Zu guter letzt fehlt nur noch die Bestellung:
PUT /order/78554
6 CORBA vs. Web Services
Im letzten Kapitel werden Web Services (SOAP, WSDL, UDDI) mit der verbreiteten Middlewa- retechnologie CORBA17verglichen. Der Vergleich ist an das PaperReinventing the Wheel? Corba vs. Web Services[6] angelehnt. In dem Abschnitt Vergleich sollen sowohl die Gemeinsamkeiten und Unterschiede im Verarbeitungsmodell als auch die Eigenschaften der einzelnen Technologien vor- gestellt werden. Im Abschnitt Einsatzgebiete 6.2 werden die St¨arken und Schw¨achen der einzelnen Technologien in Bezug auf bestimmte Einsatzgebiete vorgestellt.
17CORBA – Commen Object Request Brocker Architecture
6.1 Vergleich
Der Hauptunterschied zwischen beiden Ans¨atzen ist, dass CORBA eine objektorientierte Kompo- nentenarchitektur zur Verf¨ugung stellt wohingegen SOAP in erster Linie nachrichtenbasiert ist.
Des Weiteren ist CORBA von Haus aus mit Services wie Events, Naming oder Tradern ausge- stattet, was den Entwicklern erm¨oglicht, sich mehr auf die Gesch¨aftslogik als auf die Details der Kommunikationsinfrastruktur zu konzentrieren. Die weiteren Unterschiede oder ¨Ahnlichkeiten sind im Folgenden untergliedert in das Verarbeitungsmodell und die Eigenschaften der Technologien.
Anhand von Abbildung 6 soll ein kurzer Vergleich zwischen den beiden Technologien gegeben werden.
Abbildung 6: CORBA und Web Service Technologie Stack
6.1.1 Verarbeitungsmodell
Datenmodell – CORBA und Web Services unterscheiden sich hierbei in der Kopplung zwischen Kommunikationspartnern sowie der Verbindung. Bei CORBA besteht eine enge Kopplung zwischen Client und Server. Beide Seiten verf¨ugen ¨uber die gleichen Schnittstellen (auf der Clientseite ein Stub und auf der Serverseite ein entsprechendes Skeleton) und auf beiden Seiten muss eine ORB18 am Laufen sein. Was Verbindungen zwischen CORBA Knoten be- trifft, so m¨ussen nach der ersten Nachricht f¨ur alle flgenden keine neuen Verbindungen mehr aufgebaut werden. Im Gegensatz dazu handelt es sich bei Web Services um einen entkoppel- ten Ansatz. Es werden hier keine Objekte, sondern nur Nachrichten ¨ubermittelt. F¨ur jede Nachricht ist eine neue Vermittlung notwendig.
Aufruf-Semantik – Um Datenintegrit¨at zu gew¨ahrleisten, sollte ein Server die At-most-once- Semantik unterst¨utzen. Dies verhindert die mehrmalige Verarbeitung einer Anfrage eines Clients. CORBA ORBs unterst¨utzen eine solche Semantik. Bei Web Services h¨angt eine sol- che Semantik vom zugrundeliegenden Protokoll ab. Im Fall vonHTTP wird dies nicht unter- st¨utzt und erfordert somit einen zustandsorientierten Service, bei welchem der Anwendungs- server diese Funktionalit¨at ¨ubernehmen muss. Ein weiterer Kritikpunkt bei Web Services ist die Fehlerbehandlung. Im Falle eines Fehlers kann eine SOAP Error Message versendet werden, welche aber gleichzeitig einenHTTP-500-Fehlerstatus enthalten muss. Hierbei wird das Schichtenmodell verletzt.
Skalierbarkeit – CORBA ist durch seine Lastbalancierung skalierbar. Bei Web Services ist dies wiederum nicht Bestandteil des Standards und wird somit den implementierenden Anwen- dungsservern ¨uberlassen.
Uberpr¨¨ ufungen zur Compile- oder Laufzeit – Von CORBA werden zwei Arten an Schnitt- stellen zur Verf¨ugung gestellt: IDL19und DII20. Bei ersterem handelt es sich um eine getypte
18Object Request Broker
19Interface Description Language
20Dynamic Invocation Interface
Schnittstelle, welche gewisse statische ¨Uberpr¨ufungen erlaubt, das dynamische DII erlaubt diese hingegen nicht. Bei der Laufzeitunterst¨utzung kann CORBA auf F¨ahigkeiten der Ziel- sprache zur¨uckgreifen. Zur Zeit wird bei Web Services keine standardisierte Infrastruktur zur statischen ¨Uberpr¨ufung zur Verf¨ugung gestellt. Zur Laufzeit wird nur die Wohlgeformtheit der XML-Nachricht sichergestellt. F¨ur die Zukunft w¨are allerdings eine WSDL Anbindung zu verschiedenen Programmiersprachen denkbar, wodurch ¨Uberpr¨ufungen zur Compilerzeit erm¨oglicht w¨urden. Die ¨Uberpr¨ufung der Validit¨at beim Verarbeiten der SOAP-Nachricht hingegen ist feiner im Vergleich zu IDL, da XML-Schemata ausdrucksst¨arker sind (z.B. re- gul¨are Ausdr¨ucke und Wertebereiche).
6.1.2 Eigenschaften
Firewall – Die ¨Uberwindung vonFirewallsstellt f¨ur CORBA noch eine Herausforderung dar. Die CORBA Firewall Traversal Specification wurde im M¨arz 2004 verabschiedet, sie wird biswei- len aber nur von wenigen Anbieter unterst¨utzt. Das f¨ur Web Services am meisten angewandte Protokoll ist HTTP. Firewalls sind f¨ur gew¨ohnlich so konfiguriert, dass sie sowohl eingehen- de als auch ausgehendeHTTP-Nachrichten problemlos passieren lassen. Somit er¨ubrigen sich jegliche ¨Anderungen in der Konfiguration der Firewall.
Sicherheit – Sicherheit in verteilten Umgebungen umfasst Aspekte wie Authentifizierung, Au- torisierung, Verschl¨usselung oder Datenintegrit¨at. All diese Anforderungen werden von dem CORBA Security Service unterst¨utzt. Bei Web Services fehlt eine solche Standardisierung.
Allerdings lassen sich aufbauend auf Internettechnologien wie SSL oder XML-Signaturen
¨ahnliche Sicherheitsmechanismen realisieren.
Persistenz – Wiederum bietet CORBA durch die CORBA Persistent State Services einen Mecha- nismus zur Persistenz an. Web Services ¨uberlassen Persitenzangelegenheiten den jeweiligen Anwendungen.
Plattforunabh¨angigkeit – Sowohl CORBA als auch Web Services sind Plattform- und Program- miersprachenunabh¨angig.
Minimalanforderungen – Mobile Endger¨ate oder Thin Clients stellen Anforderungen an eine schlanke Technologie. F¨ur eingebettete Systeme bietet CORBA eine Minimalspezifikation. An der Spezifikation f¨ur drahtlose Ger¨ate wird momentan noch gearbeitet. Sie wird den Namen Mobile Agent Facilitytragen und liegt zur Zeit in der Version 1.0 vor. Dennoch ben¨otigen sol- che Ans¨atze eine minimale Infrastruktur in Form einesORB-lite. Die Minimalanforderungen f¨ur Web Services sind abh¨angig von der Komplexit¨at der Clients und Server. Im Extremfall k¨onnte ein Client sogar ohne vollst¨andigen XML-Parser auskommen.
6.2 Einsatzgebiete
Die beiden gegen¨ubergestellten Technologien CORBA und Web Services haben unterschiedliche St¨arken und Schw¨achen. Die Frage, welche Technologie verwendet werden soll h¨angt vom Einsatz- gebiet ab. Im Folgenden wird eine ¨Ubersicht ¨uber die verschiedenen Anwendungsgebiete und die daf¨ur zu bevorzugende Technologie gegeben:
Web Interfaces – F¨ur Gesch¨aftsanwendungen, die auf Web Schnittstellen basieren ist SOAP aufgrund der Verkn¨upfung mit XML undHTTPdie erste Wahl. XML kann via XSLT einfach in eine (x)HTML-Darstellung transferiert werden. Web Schnittstellen mit CORBA zu realisieren ist erheblich aufwendiger.
Interaktion mit Legacy-Systemen – Ein Vorteil von CORBA ist die einfache Kommunikation mit bestehenden Middlewaretechnologien wie zum Beispiel EJB oder COM/DCOM. Einige Legacy-Systeme sind bereits mit CORBA-Schnittstellen ausgestattet. Allerdings existieren CORBA-SOAP-Gateways, um diese L¨ucke zu ¨uberwinden.
Mobile Endger¨ate – In einem solchen Anwendungsfall sind die Clients oder die Server mobil. Die Herausforderung besteht in sich ¨andernden Netzwerkadressen, dem Weiterleiten von Nach- richten sowie unzuverl¨assigen Verbindungen. Zur Zeit ist CORBA f¨ur solche Anforderungen schlecht ausger¨ustet. Arbeiten der OMG21 anWireless CORBAsind noch nicht abgeschlos- sen, das Dokument liegt momentan in Version 1.1 (unabgeschlossen) vor. Web Services haben dank Proxys kaum Probleme mit diesen Anforderungen.
Thin Clients – Die im Abschnitt ‘Minimalanforderungen’ erw¨ahnte minimale Infrastruktur f¨ur auf CORBA basierende Anwendungen f¨uhrt zu h¨oheren Kosten, verursacht durch gr¨oßeren Speicher oder schnellere Prozessoren. Web Services hingegen sind hier sehr gen¨ugsam. Die Aufgabe besteht lediglich im Senden und Empfangen von SOAP-Nachrichten. Ein XML- Parser k¨onnte auf die Anwendungsdom¨ane beschr¨ankt sein.
Zustandsorientierte Anwendungen – Bei CORBA wird ein Zustand durch Objekte repr¨a- sentiert. Zustandsver¨anderungen k¨onnen via Methodenaufrufen erreicht werden. SOAP ist hingegen ein zustandsloses Protokoll. Um einen Status ¨uber mehrere Nachrichten zu erhal- ten, ist das wiederholte Versenden aller Informationen notwendig. In zustandsorientierten Anwendungen ist CORBA durch seinen objektorientierten Ansatz Web Services ¨uberlegen.
Bei der Auswahl einer Technologie f¨ur eine Anwendungsdom¨ane spielen noch weitere zwei Faktoren eine entscheidende Rolle. Zum Einen betrifft dies die Entwickler. Hierbei spielen die Vertrautheit mit den Technologien, die Lernkurve, aber auch die Anzahl der ben¨otigten Entwickler zur Imple- mentierung eine wichtige Rolle. Hier haben Web Services aufgrund der bekannten und verbreiteten Protokolle und Formate einen Vorteil. Zum Anderen betrifft dies die Anwendbarkeit der einzel- nen Technologien. Die Anwendbarkeit h¨angt sowohl vom Grad der Standardisierung als auch von der Verf¨ugbarkeit der Werkzeugen ab. Hier hingegen kann CORBA gegen¨uber Web Services einen Vorteil aufweisen, da bereits viel Entwicklungsaufwand in CORBA investiert wurde.
7 Zusammenfassung
Der Begriff Web Services erfreut sich sowohl in der Industrie als auch im akademischen Umfeld großer Popularit¨at. Wie bei vielenHype-Begriffen ist auch bei Web Services mit dieser Popularit¨at eine verschwommene Abgrenzung des Begriffs verbunden. Eines der Ziele dieses Seminars war es, die Begriffe Web Service und serviceorientierte Architektur genauer zu beschreiben.
Einige der Technologien und Standards als auch Werkzeuge f¨ur Web Services sind momentan noch in der Entwicklungsphase. Trotz positiver Erfahrungsberichte ist es deshalb unklar, ob Web Service die an sie gesetzten Erwartungen erf¨ullen werden. Die wichtigsten Vorteile von Web Services liegen in ihrer Struktur. Sie bauen auf vertraute und etablierte Protokolle und Standards wie httpoder XML auf, sind plattform- und programmiersprachenunabh¨angig, haben einen modularen Aufbau und sind selbstenthaltend sowie selbstbeschreibend. Sie stellen einen kleinen gemeinsamen Nenner f¨ur den Nachrichtenaustausch zwischen Programmen ¨uber Netzwerke dar. Ein weiterer Punkt, warum sich Web Services durchsetzen werden, liegt in der starken Unterst¨utzung durch die Industrie. Firmen wie IBM, Microsoft und BEA sind die treibenden Kr¨afte hinter Web Services. Die Basistechnologien stellen die in diesem Aufsatz n¨aher beschriebenen Technologien SOAP, WSDL und UDDI dar. Alternative Ans¨atze wie XML-RPC oder REST werden sich nicht durchsetzen.
Beide sind durch ihre Einfachheit was den Aufbau betrifft nicht m¨achtig genug, um mit SOAP konkurrieren zu k¨onnen.
21Object Management Group
A Anhang
A.1 SOAP
A.1.1 Listing SOAP Message
Das Listing der SOAP Message ist an Vasudevan [15] angelehnt.
1 POST / p e r l / s o a p l i t e . c g i HTTP/ 1 . 0 2 H o s t : h t t p : // t h i r d p a r t y . exampl e . o r g 3 o n t e n t−T y pe : t e x t / xml ; c h a r s e t=u t f−8
4 SOAPAction: ” ”
5
6 <?xml v e r s i o n= ’ 1 . 0 ’ ?>
7 <e n v : E n v e l o p e x m l n s : e n v=” h t t p : //www. w3 . o r g / 2 0 0 3 / 0 5 / soap−e n v e l o p e ”>
8 <e n v : H e a d e r>
9 <t : t r a n s a c t i o n
10 x m l n s : t=” h t t p : // t h i r d p a r t y . exa mple . o r g / t r a n s a c t i o n ” 11 e n v : e n c o d i n g S t y l e=” h t t p : // ex ample . com/ e n c o d i n g ” 12 e n v : m u s t U n d e r s t a n d=” t r u e ”>
13 </ t : t r a n s a c t i o n>
14 </e n v : H e a d e r>
15 <env:Body>
16 <m : c h a r g e R e s e r v a t i o n
17 e n v : e n c o d i n g S t y l e=” h t t p : //www. w3 . o r g / 2 0 0 3 / 0 5 / soap−e n c o d i n g ” 18 xmlns:m=” h t t p : // t r a v e l c o m p a n y . example . o r g / ”>
19 <m : r e s e r v a t i o n xmlns:m=” h t t p : // t r a v e l c o m p a n y . example . o r g / r e s e r v a t i o n ”>
20 <m:code>
21 FT35ZBQ
22 </m:code>
23 </ m : r e s e r v a t i o n>
24 <o : c r e d i t C a r d x m l n s : o=” h t t p : // mycompany . ex ample . com/ f i n a n c i a l ”>
25 <n:name x m l n s : n=” h t t p : // mycompany . exam ple . com/ e m p l o y e e s ”>
26 Thomas Mustermann
27 </n:name>
28 <o:number>
29 1 2 3 4 5 6 7 8 9 0 9 9 9 9 9
30 <o:number>
31 <o : e x p i r a t i o n>
32 2005−02
33 </ o : e x p i r a t i o n>
34 </ o : c r e d i t C a r d>
35 </ m : c h a r g e R e s e r v a t i o n>
36 </env:Body>
37 </ e n v : E n v e l o p e>
A.2 WSDL
A.2.1 Listing WSDL
Das Listing WSDL erfolgt in Anlehnung an Cerami [1] (Seite 122f).
1 <?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8”?>
2 <d e f i n i t i o n s name=” H e l l o S e r v i c e ”
3 t a r g e t N a m e s p a c e=” h t t p : //www. w e n z l e r . i n f o / w s d l / H e l l o S e r v i c e . w s d l ” 4 x m l n s : s o a p=” h t t p : // s c h e m a s . xmlsoap . o r g / w s d l / s o a p / ”
5 x m l n s : t n s=” h t t p : //www. w e n z l e r . i n f o / w s d l / H e l l o S e r v i c e . w s d l ” 6 x m l n s : x s d=” h t t p : //www. w3 . o r g / 2 0 0 1 /XMLSchema ”>
7
8 <m e s s a g e name=” S a y H e l l o R e q u e s t ”>
9 <p a r t name=” f i r s t N a m e ” t y p e=” x s d : s t r i n g ” />
10 </message>
11 <m e s s a g e name=” S a y H e l l o R e s p o n s e ”>
12 <p a r t name=” g r e e t i n g s ” t y p e=” x s d : s t r i n g ” />
13 </message>
14
15 <p o r t T y p e name=” H e l l o P o r t T y p e ”>
16 <o p e r a t i o n name=” s a y H e l l o ”>
17 <i n p u t m e s s a g e=” t n s : S a y H e l l o R e q u e s t ” />
18 <o u t p u t m e s s a g e=” t n s : S a y H e l l o R e s p o n s e ” />
19 </ o p e r a t i o n>
20 </portType>
21
22 <b i n d i n g name=” H e l l o B i n d i n g ” t y p e=” t n s : H e l l o P o r t T y p e ”>
23 <s o a p : b i n d i n g s t y l e=” r p c ”
