SOAP, WSDL und XPath

Transkript

1 SOAP, WSDL und XPath Hauptseminar Grid Computing Tammo van Lessen, Universität Stuttgart WS 2003/2004 Zusammenfassung Grid-Computing soll Rechenleistung und andere Ressourcen transparent und ondemand zur Verfügung stellen. Die Open Grid Services Architecture (OGSA) stellt sich dieser Herausforderung und definiert Mechanismen zum Erstellen, Finden und Benutzen von Services. Der Zugriff auf die Services soll plattformunabhängig und lokationstransparent sein. Dazu stützt sich OGSA auf Web Service-Technologien, insbesondere WSDL und SOAP. Diese beiden Standards sowie die XML-Abfragesprache XPath sind das Thema dieses Artikels. Inhaltsverzeichnis 1 Einleitung 2 2 SOAP Struktur einer SOAP Nachricht Header-Attribut env:actor Header-Attribut env:mustunderstand SOAP-RPC Transport WSDL Aufbau eines WSDL-Dokuments Das types-element Das message-element Das porttype-element Das binding-element Das service-element

2 1 Einleitung 4 XPath Aufbau eines Ausdrucks Achsen Knotentests Prädikate Beispiel Zusammenfassung 14 A Literatur 15 1 Einleitung Ähnlich wie das World Wide Web, getragen durch Standards wie HTTP, HTML oder XML, den weltweiten Zugriff auf Informationen jeglicher Art ermöglicht, könnte man auch einen weltweiten Zugriff auf Ressourcen wie Datenbanken, Großrechner oder technische Instrumente realisieren. Die Vorteile eines solchen Grids 1 liegen auf der Hand: lokale Kosten ließen sich reduzieren und eine optimale Hardwareausnutzung wäre möglich, würde man seine Ressourcen in einem nahezu unendlich skalierbaren Netz teilen. Doch ohne eine standardisierte Architektur ist das nicht möglich. Um eine solche zu schaffen, formuliert Ian Forster drei Kernanforderungen an ein Grid (vgl. Foster 2002): Koordination von Ressourcen in einem Peer-to-Peer-Netzwerk, also ohne zentrale Kontrollinstanz Verwendung von offenen, standardisierten Protokollen und Schnittstellen Bereitstellung von nicht-trivialen Metadaten, anhand derer die Eignung der Services bewertet werden kann Die Open Grid Service Architecture definiert das Rahmenwerk um diese Anforderungen unter Verwendung von bereits bestehenden standardisierten Technologien zu erfüllen. Web Services definieren Techniken, um den Zugriff auf Software Komponenten zu beschreiben, ihn auszuführen und ermöglichen die Suche nach relevanten Service Providern. Sie sind Programmiersprachen-unabhängig und Programmierparadigmen-neutral Um diese Eigenschaften für sich nutzen zu können, stützt sich OGSA auf die Web Service Standards SOAP, WSDL und WS-Inspection (vgl. Foster u. a. 2002). SOAP und WSDL werden in diesem Artikel näher erklärt. 2 SOAP Um Verbindung zu Grid Services aufnehmen zu können, muss man Datenübertragung und entfernte Methodenaufrufe über das Internet realisieren. Die Daten müssen dabei so ver- 1 Die Energieversorger haben die Machbarkeit eines Grids eindrucksvoll demonstriert. Mehrere Kraftwerke sind zu einem Powergrid zusammen geschlossen und können so flexibel auf schwankenden Strombedarf reagieren. Das Grid Computing bezieht daher auch seinen Namen. 2

3 2 SOAP packt sein, dass sie von dem Empfänger verstanden werden können. Hindernisse wie Firewalls müssen überwunden werden können. Eine Antwort zur Lösung dieser Probleme ist SOAP. Im Jahre 1999 begann Microsoft zusammen mit Dave Winner die Spezifikation der ersten Version von SOAP, dem Simple Object Access Protocol. Zusammen mit IBM reichte man die folgende Version 1.1 im Mai 2000 als Note beim World Wide Web Consortium (W3C) zum Standardisieren ein. Dabei versuchte man eine Arbeitsgruppe zu gründen, die die Entwicklung von SOAP weiter voran bringen sollte. Aus dieser Arbeitsgruppe ging im Juni 2003 die derzeit aktuelle Version 1.2 hervor. Seit dieser Version ist SOAP keine Abkürzung mehr, da sämtliche Deutungen wie Simple Object Access Protocol oder Service Oriented Architecture Protocol den Sinn von SOAP nicht richtig treffen. SOAP bietet ein leichtgewichtiges XML-basiertes Protokoll zum Verpacken von Nachrichten, die zwischen Applikationen ausgetauscht werden. Bei der Entwicklung legte man großen Wert auf Erweiterbarkeit, Offenheit und Heterogenität des Protokolls. SOAP besteht im Wesentlichen aus vier Teilen: der Spezifikation für einen Umschlag (Envelope). Für ihn ist definiert, was in einer Nachricht enthalten ist, von wem es wie verarbeitet werden soll und ob einzelne Daten optional sind oder enthalten sein müssen. ein Satz von Regeln, die vorschreiben, wie Daten in dem Umschlag repräsentiert werden sollen (Serialisierung) eine Konvention, um Remote Procedure Calls und eventuelle Antworten auf diese zu repräsentieren eine Vorschrift, wie SOAP via HTTP übertragen werden soll. Dank des erweiterbaren Entwurfs können aber beliebige Transportprotokolle verwendet werden. Eine SOAP-Nachricht muss nicht zwangsläufig direkt vom Sender (initial sender) an den Empfänger (ultimate receiver) geschickt werden, sondern kann über mehrere Relay-Stationen (intermediaries) geleitet werden. Den Weg, dem sie dabei folgt, nennt man Message Path. SOAP macht jedoch keine Angaben dazu, in welcher Reihenfolge die Stationen abgearbeitet werden. Es gibt aber einige SOAP-Erweiterungen, die diese Lücke zu füllen versuchen. Der SOAP-spezifische Teil einer Nachricht wird über die Zuordnung zu bestimmten Namensräumen erkennbar. Wichtige Namensräume für den Umschlag. für die Serialisierungs-Vorschriften. für die Untersützung von Remote Procedure Calls. 2.1 Struktur einer SOAP Nachricht Eine SOAP-Nachricht ist ein XML-Dokument, das nach dem Header-Body-Pattern strukturiert ist (siehe Abb. 1). 3

4 2 SOAP Abbildung 1: Aufbau einer SOAP-Nachricht Der Header ist optional und enthält meist Metadaten zum Body. Diese werden in mehreren Headerblöcken unterhalb des Header-Elements untergebracht. Daten zur Authentifizierung oder zum Transaktionsmanagement würden beispielsweise im Header untergebracht. Läuft die Nachricht über mehrere Stationen, können die Headerblöcke von den Zwischenstationen untersucht, verändert oder gelöscht werden. Nach der Verarbeitung muss der Header entfernt werden. Da Headerblöcke aber auch hinzugefügt werden können, steht es der Station frei, den Block (un)verändert wieder einzufügen. Der Body kann jeden wohlgeformten und Namensraum-qualifizierten XML-Code enthalten. Das ist die eigentliche Fracht der Nachricht und in der Regel nur für den End-Empfänger bestimmt. Beispiel: 1 <env:envelope xmlns:env=" 2 <env:header> 3 <xr:authentication xmlns:xr=" env: mustunderstand="1"> 4 <xr:userid>username</xr:userid> 5 <xr:passwd>encryptedpassword</xr:passwd> 6 </xr:authentication> 7 </env:header> 8 <env:body> 9 <xm:message xmlns:xm=" </xm:message> 12 </env:body> 13 </env:envelope> Tritt beim Verarbeiten der Nachricht ein Fehler auf, so wird eine speziell kodierte Nachricht zurück an den Empfänger gesendet. Deren Aufbau zeigt das folgende Listing: 1 <env:envelope xmlns:env=" env: encodingstyle=" 4

5 2 SOAP 2 <env:body> 3 <env:fault> 4 <env:code> 5 <env:value>env:mustunderstand</value> 6 </env:code> 7 <env:reason> 8 <env:text>soap Must Understand Error</env:Text> 9 </env:reason> 10 </env:fault> 11 </env:body> 12 </env:envelope> Das Fault-Element ist also optionaler Bestandteil des Body-Elements. Die Angabe eines Fehler-Codes und des //Reason/Texts sind obligatorisch und sollen mensch- bzw. maschinenverständlich den aufgetretenen Fehler beschreiben. Optional kann eine Role angegeben werden, die den Verursacher identifiziert wenn der Fehler auf dem Weg zum Empfänger aufgetreten ist. Das Feld Detail sollte gefüllt werden, wenn der Body nicht fehlerfrei bearbeitet werden konnte Header-Attribut env:actor SOAP stellt drei Standard-Rollen (role) vor none, next und ultimatereceiver die einem Header zugewiesen werden können. Dazu wird dem env:actor-attribut eine entsprechende URI zugewiesen. Man kann daher auch eigene Rollen definieren. An Hand dieser Rolle kann die Station, die die Nachricht gerade bearbeitet, erkennen, ob sie den Header verarbeiten soll. Die Rolle next fordert, dass die Station den Header verarbeiten soll. none bedeutet, dass der Header nicht verarbeitet werden muss. Seine Informationen können jedoch zur Verarbeitung anderer Header benutzt werden. Hat ein Header die Rolle ultimatereceiver, so darf er ausschließlich von dem End-Empfänger verarbeitet werden. Das Attribut ist optional. Wird es nicht explizit angegeben, ist der Header nur für den End- Empfänger bestimmt. Beispiel: 1 <env:envelope xmlns:env=" 2 <env:header> 3 <xr:authentication xmlns:xr=" env: mustunderstand="1" env:role=" role/next"> </xr:authentication> 6 <xl:log xmlns:xr=" 7 env:role=" </xr:log> 10 </env:header> 11 <env:body>...</env:body> 12 </env:envelope> 5

6 2 SOAP Das Beispiel zeigt zwei Headerblöcke. Der Erste soll den Absender authentifizieren, der Zweite einen Log-Eintrag erzeugen. Da beide die Rolle next haben, wird jede Zwischenstation, die mit dem Namensraum xr bzw. xl vertraut ist, den Header verarbeiten Header-Attribut env:mustunderstand Die Informationen im Header können unterschiedlich wichtig sein. Daher ist es wichtig, angeben zu können, ob eine Zwischenstation den Header erfolgreich verarbeiten muss. Mit dem obigen Beispiel kann man das schön verdeutlichen. Die Authentifizierung des Absenders ist wichtig. Schlägt sie fehl, muss die Nachricht nicht mehr an den End-Empfänger weitergeleitet, sondern eine Fehlermeldung an den Absender geschickt werden. Bei dem Logging-Header ist das anders. Schlägt dieser fehl, kann ruhig fortgefahren werden. Deshalb ist bei dem ersten Header auch das mustunderstand-attribut gesetzt. Falls ein Knoten einen erforderlichen Block nicht verarbeiten kann, muss er einen env:fault erzeugen und zurückschicken. Die Weiterverarbeitung der Nachricht wird beendet und die Nachricht nicht an den nächsten Knoten im Nachrichtenpfad weitergeleitet. 2.2 SOAP-RPC Soll mit SOAP eine entfernte Methode aufgerufen werden, so schreibt der Standard eine bestimmte Struktur für den Call- und den Response-Body vor. In der Regel übernimmt die SOAP Middleware das Erstellen solcher Nachrichten und das Mapping auf die tatsächliche Methode. Dazu muss der Methodenname sowie die -Parameter in XML umgewandelt werden und im SOAP-Body verpackt werden. Die Antwortnachricht enthält den Rückgabewert und die Rückgabeparameter. Um die Interoperabilität zwischen heterogenen Systemen sicherstellen zu können, müssen beide Systeme die gleiche Sprache sprechen. Es muss geregelt sein, wie ein String oder Integer in der SOAP-Nachricht dargestellt wird. Über das encodingstyle-attribut der RPC-Nachricht kann man beliebige Encoding- Vorschriften benennen (z.b. XML Schema). In Gudgin u. a. (2003b) wird das SOAP Encoding beschrieben 2, also auf welche Weise Primitive, Arrays und ADTs zu XML serialisiert werden sollen. 2.3 Transport Am häufigsten werden SOAP-Nachrichten über HTTP versendet. HTTP als Übertragungsprotokoll ist weltweit verbreitet und verfügbar. HTTP-Server sind weit entwickelt und auch unter großen Lasten nutzbar. Es lässt sich mittels GET für eine asynchrone und via POST für eine synchrone Kommunikation nutzen. Wegen dieser Vorteile ist der Transport über HTTP der einzige, der direkt in der SOAP-Spezifikation standardisiert ist. Unabhängig von dem Standard ist der Transport über beliebige Protokolle (z.b. FTP, TCP, SMTP, JMS, XMPP) denkbar. 2 Setzt man das encodingstyle-attribut auf wird das SOAP Encoding verwendet 6

7 3 WSDL 3 WSDL Nachdem mit SOAP die Kommunikation zu Services standardisiert wurde, fehlte ein Standard zur Beschreibung der Service-Schnittstellen. So entstand durch das Zusammenlegen von IBMs Network Accessible Services Specification Language und Microsofts SOAP Contract Language die Sprache WSDL. Diese Abkürzung steht für Web Service Description Language, gesprochen whistle. Sie ist eine XML-basierte Metasprache, mit deren Hilfe die Funktionalität eines Web Services beschrieben werden kann. Sie gilt Vertrag zwischen Service Provider und Service Requestor. An WSDL wurden hohe Anforderungen geknüpft. Es soll die Service-Schnittstellen Programmiersprachen- und Programmierparadigmen-neutral definieren, darüber hinaus abstrakt und erweiterbar sein. Damit scheiden klassische Schnittstellen- Beschreibungsprachen wie CORBA IDL, DCOM IDL und Java als direkte Vorbilder aus (Jeckle 2002). Insgesamt waren 25 Firmen an der Entwicklung beteiligt. Seit März 2001 ist die Version 1.1 aktuell. Auch hier wurde eine Arbeitsgruppe im W3C zur Weiterentwicklung gegründet, WSDL 1.2 und 2.0 sind in Arbeit. Während im Globus Toolkit 3 noch eine Abwandlung von WSDL, nämlich GWSDL, verwendet wurde, stützt sich die Version 4 auf das Standard-WSDL mit WS-ResourceProperties. WSDL beschreibt die auszutauschenden Nachrichten, das dazu verwendete Protokoll und gibt an, unter welcher Adresse der Web Service zu erreichen ist. 3.1 Aufbau eines WSDL-Dokuments Damit das Format hinsichtlich zukünftiger Nachrichtenformate und Transportprotokolle erweiterbar ist, gliedert es sich in zwei Teile. Eine abstrakte und eine konkrete Definition. Die abstrakte Definition beschreibt die Datentypen, die Operationen und Nachrichten. Diese werden zu so genannten porttypes zusammen gefasst. Die konkrete Definition bindet die porttypes an ein Transportprotokoll und fasst diese ports zu services zusammen. Struktur eines WSDL-Dokuments 1 <definitions> 2 <types>...</types> 3 <message> 4 <part>...</part> </message> 7 <porttype> 8 <operation> 9 <input>...</input> 10 <output>...</output> 11 </operation> </porttype> 7

8 3 WSDL 14 <binding>...</binding> 15 <service> 16 <port>...</port> </service> 19 </definitions> Bis auf types können alle Elemente mehrfach in einem WSDL-Dokument vorkommen. Dadurch ist es möglich, unterschiedliche Services mit unterschiedlicher Funktionalität und unterschiedlichen Protokollen anzubieten. Ebenso kann man aber auch die gleiche Funktionalität über verschiedene Kanäle bereitstellen. Mit dem Element documentation kann man die einzelnen Elemente mit Fließtext kommentieren. Um die Wartbarkeit und Wiederverwendbarkeit von WSDL-Dokumenten zu verbessern, hat man mit dem import-element die Möglichkeit geschaffen, mehrere WSDL-Fragmente zusammen zu führen. Jedes der aufgelisteten Elemente hat ein name-attribut, über das das Element eindeutig identifiziert werden kann Das types-element Zur Definition von Datentypen stützt sich WSDL auf XML Schema. Dessen primitive Datentypen kann man direkt verwenden. Möchte man komplexe Datentypen definieren, so ist das types-element der richtige Ort dafür Das message-element Das message-element beschreibt die Nachrichten, die zwischen Requestor und Provider ausgetauscht werden können. Die Richtung ist hier zunächst unerheblich. Ein Message-Element kann aus keinem, einem oder mehreren part-elementen bestehen. Diese bilden ein 2-Tupel aus Name und Typ, sind also ähnlich einer Variablendeklaration in gängigen Programmiersprachen. Als Datentypen stehen einem die XML-Schema-Primitiven sowie die unter types definierten Typen zur Verfügung. Beispiel: 1 <message name="gettermrequest"> 2 <part name="term" type="xs:string"/> 3 </message> 4 <message name="gettermresponse"> 5 <part name="term" type="xs:string"/> 6 </message> Das Beispiel deklariert zwei Nachrichten, die jeweils eine Variable namens term vom Typ String enthalten. 8

9 3 WSDL Das porttype-element Der porttype beschreibt die Schnittstelle des Services. In ihm werden eine oder mehrere Operationen zusammen gefasst, ähnlich wie ein Java Interface. Diese ordnen der Operation die Ein- und Ausgabeparameter zu. Über diese Zuordnung wird das sogenannte Message Exchange Pattern der Schnittstelle festgelegt. Abbildung 2: Message Exchange Patterns in WSDL 1.1 Beispiel: 1 <porttype name="glossaryterms"> 2 <operation name="getterm"> 3 <input message="tns:gettermrequest"/> 4 <output message="tns:gettermresponse"/> 5 </operation> 6 </porttype> Das Beispiel definiert ein Interface names glossaryterms. Es enthält eine Methodensignatur getterm, die als Eingabe eine gettermrequest-nachricht akzeptiert. Nach der Ausführung kommt von der Methode eine Nachricht gettermresponse zurück Das binding-element Das Binding beschreibt die konkrete Anbindung eines porttypes an eine Serialisierungsvorschrift und ein Transportprotokoll (z.b. SOAP, MIME, HTTP GET/POST). Beispiel: 1 <binding type="tns:glossaryterms" name="glossarytermsbinding"> 2 <soap:binding style="document" transport=" http" /> 3 <operation> 4 <soap:operation soapaction=" 5 <input> 6 <soap:body use="literal"/> 7 </input> 8 <output> 9 <soap:body use="literal"/> 9

10 4 XPath 10 </output> 11 </operation> 12 </soap:binding> 13 </binding> Das Beispiel bindet den oben definierten porttype glossaryterms an das SOAP über HTTP- Protokoll. Dabei soll nicht der RPC-style, sondern der document-style verwendet werden, die Parameter der getterm-methode werden entsprechend einem XML-Schema serialisiert Das service-element Das service-element stellt aus einem oder mehreren ports einen Dienst zusammen. Ein port ordnet dem Binding einen bestimmten Endpunkt zu. Wie dieser definiert wird, hängt von dem verwendeten Transportprotokoll ab. Bei SOAP über HTTP ist dies beispielsweise die URL, über die der Service Provider erreichbar ist. Beispiel: 1 <service name="glossarytermservice"> 2 <port name="glossarytermport" binding="tns:glossarytermbinding"> 3 <soap:address location=" 4 </port> 5 </service> Das Beispiel definiert einen Service mit einem Port. Dieser Service soll den glossaryterm- PortType via SOAP über HTTP an der angegeben URL bereit stellen. 4 XPath Die zentrale Anlaufstelle für die Nutzer eines Grids ist die Registry. Sie dient beispielsweise zum Auffinden von Grid Services. Dazu setzt man eine Anfrage, die bestimmte Anforderungen an den Service beschreibt. Eine der vom Globus Toolkit 3 unterstützten Abfragesprachen ist XPath. XPath steht für XML Path Language und wurde 1999 vom W3C Konsortium standardisiert. Das Ziel von XPath ist die einfache und kompakte Adressierung von Teilen eines XML- Dokuments. Der Verwendung der in URLs genutzten Pfad-Notation, mit der sich durch die hierarchische Struktur des XML-Dokuments navigieren lässt, verdankt XPath seinen Namen. Die Sprache selbst verwendet aber keine XML-Syntax. Die aktuelle Version von XPath ist 1.0, die Folgeversion wird 2.0 heißen und soll mehr Rücksicht auf Typsicherheit nehmen. XPath operiert nicht auf der äußerlichen Syntax des XML-Dokuments sondern auf der abstrakten, das XML-Dokument repräsentierenden, Baumstruktur. Es gibt sieben Knotentypen: 3 Das Globus Toolkit ist eine Open Source Referenzimplementierung von OGSA/OGSI. Es wird von der Globus Alliance entwickelt. 10

11 4 XPath Wurzelknoten Elementknoten Textknoten Attributknoten Namensraumknoten Processing-Instruction-Knoten Kommentarknoten Der Baum ist logisch so aufgebaut, dass nur Elementknoten Kinder haben können, die anderen Knotentypen gehören also immer zu einem Elementknoten. Dabei wird die Reihenfolge im XML-Dokument beibehalten. 4.1 Aufbau eines Ausdrucks Ein XPath Ausdruck setzt sich aus einem oder mehreren Location Steps zusammen. Diese sind äquivalent zu einem Pfadelement in URIs und werden auch mit dem Zeichen / getrennt. Ein solcher Lokationsschritt besteht aus einer Achse (axis) und einem Knotentest (node-test), gefolgt von einem oder mehreren optionalen Prädikaten (predicates). Syntax: axis::node-test[predicate]/axis::node-test[predicate]/... Ein Lokationsschritt ist zunächst relativ zu dem aktuellen Kontextknoten. Durch das Anführen eines /-Zeichens beginnt er bei dem Wurzelelement. Um mehrere XPath-Ausdrücke miteinander zu verbinden benutzt man das -Zeichen. Die Auswertung eines XPath-Ausdrucks ergibt ein Objekt, dass zu einem von vier Datentypen gehört: node-set eine ungeordnete duplikatfreie Menge von Knoten boolean wahr oder falsch number eine 64-bit Gleitkommazahl string eine Zeichenkette 4.2 Achsen Durch den XML-Baum kann man auf unterschiedliche Weisen navigieren. Die Achsen bestimmen ausgehend vom aktuellen Kontextknoten, welche Knoten in die Ergebnismenge aufgenommen werden (siehe Tabelle 1). Wird keine Achse angegeben, wird die child- Achse verwendet. 11

12 4 XPath preceding-sibling Achse selektierte Knoten Abkürzung child direkt untergeordnete durch weglassen parent direkt übergeordnete.. self der Referenzknoten selbst. ancestor übergeordnete ancestor-or-self übergeordnete, oder der Knoten selbst descendant untergeordnete descendant-or-self untergeordnete, oder der Knoten selbst // following gleiche Ebene der Baumstruktur, nachfolgend im XML-Dokument following-sibling wie following, und vom gleichen parent stammend preceding gleiche Ebene der Baumstruktur, vorhergehend im XML-Dokument wie preceding, und vom gleichen parent stammend attribute Attribute des namespace Namensräume des Kontextknotens Tabelle 1: XPath-Achsen Abbildung 3 veranschaulicht, welche Pfade im XML-Baum von welchen Achsen selektiert werden. Jede Achse besitzt einen Hauptknotentyp. Alle Achsen, die Element-Knoten selektieren, haben den Elementtyp als Hauptknotentyp. Für die anderen Achsen gilt: Für die Attributachse ist der Hauptknotentyp der Attributtyp. Für die Namensraumachse ist der Hauptknotentyp der Namensraum-Typ. 4.3 Knotentests Knotentests helfen, die durch die Achse selektierte Knotenmenge einzuschränken. Um einen Knoten in der Ergebnismenge zu behalten, muss der Knotentest-Wert identisch mit dem qualifizierten Namen des Knotens sein. Dabei orientiert man sich am Hauptknotentyp der Achse. Beispiel: child::para selektiert alle para-kindelemente des Kontextknotens. attribute::href selektiert das href-attribut des Kontextknotens. Ein Knotentest * ist für jeden Knoten des Hauptknotentyps erfüllt. Beispielsweise wählt child::* alle Kindelemente und attribute::* alle Attributknoten des Kontextknotens aus. Um bestimmte Knotentypen zu selektieren, gibt es die Knotentests text(), comment() und processing-instruction(). 12

13 4 XPath Abbildung 3: XPath-Achsen 4.4 Prädikate Mit den in eckigen Klammern eingeschlossenen Prädikaten kann das Ergebnis weiter eingeschränkt werden. Es lassen sich beliebig viele solcher Prädikate hintereinander schreiben, dabei ist die Reihenfolge von Bedeutung. Ist das Ergebnis der Prädikatsauswertung logisch wahr, so wird der Knoten in die neue Ergebnismenge aufgenommen. Um die Prädikate zu formulieren stehen neben den Wahrheits- und Grundrechenfunktionen auch Zeichenkettenund Knotenfunktionen zur Verfügung. 4.5 Beispiel Gegen sei das folgende XML-Dokument. 1 <?xml version="1.0"?> 2 <library> 3 <compact-disc id="monk1"> 4 <title>straight, No Chaser</title> 5 <artist>thelonious Monk</artist> 6 <price currency="eur">10</price> 7 </compact-disc> 13

14 5 Zusammenfassung 8 <compact-disc id="monk2"> 9 <title>monk</title> 10 <artist>thelonious Monk</artist> 11 <price currency="eur">12</price> 12 </compact-disc> 13 <compact-disc id="peterson1"> 14 <title>ben Webster meets Oscar Peterson</title> 15 <artist>oscar Peterson</artist> 16 <price currency="usd">10</price> 17 </compact-disc> 18 </library> Beispiel: /library selektiert das Wurzel-Element library. /library/compact-disc selektiert alle compact-disc-elemente. descendant-or-self::compact-disk - wie oben. /library/compact-disc[1] selektiert das erste compact-disc-element. /library/compact-disc[@id= monk2 ] selektiert das compact-disc-element mit dem id-attribut monk2. /library/compact-disc[@id= monk2 ] selektiert das compact-disc-element mit dem id-attribut monk2. //compact-disc[price <= 12 and price/@currency= EUR ] selektiert alle compact-disc-elemente, deren Preis kleiner gleich 12 und deren Währung EUR ist. //compact-disc[starts-with(./artist, Oscar )] selektiert alle compact-disc-elemente, deren Artist mit der Zeichenkette Oscar beginnt. 5 Zusammenfassung In dieser Ausarbeitung wurde deutlich, dass die Web Service-Technologien durchgängig von XML Gebrauch machen. Das trifft sowohl auf die Beschreibungssprachen als auch auf die Datenübertragung zu. Durch klar definierte Regeln zum Umwandeln von Datenobjekten zu solchen XML-Datenströmen ist ein transparenter Zugriff auf heterogene Services möglich. Grid Computing benötigt genau die dadurch geschaffene Unabhängigkeit von Betriebssystemen, Programmiersprachen und Programmierparadigmen. Die Offenheit und Flexibilität dieser Technologien, macht sie zur idealen Basistechnologie in der Grid-Architektur. Wenn durchgängig XML zur Repräsentation von Daten und Metainformation benutzt wird, kann man mit XPath auch komplexe Abfragen realisieren. Dadurch ist es recht einfach möglich, den am besten passenden Service zu finden. 14

15 A Literatur A Literatur Alonso u. a ALONSO, Gustavo ; CASATI, Fabio ; KUNO, Harumi: Web Services. Springer, Berlin, 2003 Christensen u. a CHRISTENSEN, Erik ; CURBERA, Francisco ; MEREDITH, Greg ; WEERAWARANA, Sanjiva: Web Services Description Language (WSDL) Version: Clark u. DeRose 1999 CLARK, James ; DEROSE, Steve: XML Path Language (XPath) Version 1.0. W3C Recommendation, Foster 2002 FOSTER, Ian: What is the Grid? A Three Point Checklist. Grid Today, gridtoday.com/02/0722/ html, 2002 Foster u. a FOSTER, Ian ; KESSELMAN, Carl ; NICK, Jeffrey M. ; TUECKE, Steven: The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Globus Project, Gudgin u. a. 2003a GUDGIN, Martin ; HADLEY, Marc ; MENDELSOHN, Noah ; MOREAU, Jean-Jacques ; NIELSEN, Henrik F.: SOAP Version 1.2 Part 1: Messaging Framework. org/tr/soap12-part1/. Version: 24. Juni 2003 Gudgin u. a. 2003b GUDGIN, Martin ; HADLEY, Marc ; MENDELSOHN, Noah ; MOREAU, Jean-Jacques ; NIELSEN, Henrik F.: SOAP Version 1.2 Part 2: Adjuncts. soap12-part2/. Version: 24. Juni 2003 Jeckle 2002 JECKLE, Mario: Die nächste WSDL-Generation. WSDL2002.pdf, Juni 2002 Mitra 2003 MITRA, Nilo: SOAP Version 1.2 Part 0: Primer. soap12-part0/. Version: 24. Juni 2003 W3 Schools a W3 SCHOOLS: SOAP Tutorial. W3 Schools b W3 SCHOOLS: WSDL Tutorial. W3 Schools c W3 SCHOOLS: XPath Tutorial. 15