Web Services und XML

Web Services und XML
Lehrstuhl für Softwaretechnologie
Fakultät Informatik
TU Dresden
Sven Klemm
26. Juni 2003
ii
Inhaltsverzeichnis
1 Definition und Inhalt von Web
1.1 Einleitung . . . . . . . . . . .
1.2 Begriffsdefinition nach . . . . .
1.2.1 Intel . . . . . . . . . .
1.2.2 Microsoft . . . . . . .
1.2.3 W3C . . . . . . . . . .
1.2.4 SUN . . . . . . . . . .
1.2.5 IBM . . . . . . . . . .
1.2.6 Zusammenfassung . .
1.3 Inhalte . . . . . . . . . . . . .
Services
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
1
2
2
2
3
3
2 Die Rolle von XML
2.1 XML-Technologien zur Datenpräsentation . . . . . . . . . . . . . . . . . . . . .
2.2 Technologien zur Darstellung und Verarbeitung von XML repräsentierten Daten
und Wissens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Baumorientiert - DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Ereignisorientiert - SAX . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
5
5
.
.
.
5
5
6
3 Architekturschema für Web Services
3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . .
3.2 SOAP - Simple Object Access Protocol . . . . . . .
3.3 WSDL - Web Service Description Language . . . . .
3.4 UDDI - Universal Service Description, Discovery and
3.5 ebXML - eBussiness XML . . . . . . . . . . . . . . .
3.6 Architektur im Ablauf . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Integration
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
. 7
. 7
. 9
. 10
. 11
. 11
4 Beispiel für einen Web Service
4.1 Übersicht . . . . . . . . . . .
4.2 Der Quellcode . . . . . . . . .
4.2.1 Dienst - Web Service .
4.2.2 Client . . . . . . . . .
4.3 Das Ergebnis . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
13
14
15
5 Epilog
17
5.1 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Verwendete Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Wichtige Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
iv
INHALTSVERZEICHNIS
Kapitel 1
Definition und Inhalt von Web
Services
1.1
Einleitung
Was sind Web Services? Dies sollte eine einfach zubeantwortende Frage sein, eigentlich beantworten die zwei Wörter “Web“ und “Service“ diese Frage doch schon, oder?
Also sind “Web Services“ Dienste, die über das Netz, oder auch Internet genannt, angeboten
werden? Grob gesagt ist das richtig, aber d.h. nun nicht, dass z.B. die Fahrplanauskunft der
Deutschen Bahn via HTTP sofort ein Web Service ist. Warum? Weil für diesen “Dienst“ bestimmte Kriterien erfüllt sein müssen, welche das sind wird in den folgenden Kapiteln erläutert.
Allein die Tatsache, das mehr als 50 verschiedene Definitionen [7] von dem Begriff des “Web
Services“ 1 existieren, zeigt dass es keineswegs ohne weiteres möglich ist ihn zu fassen.
Der nächste Abschnitt beleuchtet daher eine Auswahl an Definitionen und gibt eine eigene, zusammenfassende Definition. Der Begriffklärung folgt die Beschreibung der Inhalte von Web Services. Im Anschluß daran wird der Zusammenhang zu der Auszeichnungssprache XML erläutert.
Der Aufbau und die Architektur von Web Services zeigt das dritte Kapitel, an das sich ein kleines
Beispiel knüpft. Den Abschluß bilden die Zusammenfassung, der Ausblick und die Auflistung
der wichtigsten Begriffe und Abkürzungen.
1.2
1.2.1
Begriffsdefinition nach . . .
Intel
Web services encompass a vision of a fully integrated computing network that include PCs,
servers, handheld devices, programs, applications and network equipment, all working together.
This network can perform distributed computation with the best-matched device for the task and
deliver the information on a timely basis in the form needed by the user.
Intel beschränkt sich hier auf die Definition der Funktionalität von Web Services, was leider
zu einer unzureichenden Trennung zu anderen Diensten/Protokollen (die ähnliche Funktionen
bieten) führt. Denn hier ist ein Web Service: eine Technik zur Kommunikation zwischen heterogenen Geräten.
1.2.2
Microsoft
A Web Service is a unit of application logic providing data and services to other applications.
Applications access Web Services via ubiquitous Web protocols and data formats such as HTTP,
1 Mehr noch, sogar bei der Schreibweise gibt es weitere, unterschiedliche Vorstellungen: “Webservices“ oder
“Web-Services“
2
KAPITEL 1. DEFINITION UND INHALT VON WEB SERVICES
XML, and SOAP, with no need to worry about how each Web Service is implemented. Web
Services combine the best aspects of component-based development and the Web, and are a
cornerstone of the Microsoft .NET programming model.
Die Definition, die Microsoft liefert, ist da schon konkreter (als die von Intel) und spricht auch
die z.Zt. gebräuchlichen Standards an, dazu gehören XML, SOAP. ⇒ Ein Web Service ist einen
über das Internet auslieferbare Softwarelösung auf der Basis von XML [8].
1.2.3
W3C
The same way programmatic interfaces have been been available since the early days of the
World Wide Web via HTML forms, programs are now accessible by exchanging XML data
through an interface, e.g. by using SOAP Version 1.2, the XML-based protocol produced by the
XML Protocol Working Group. The services provided by those programs are called Web services.
Das World Wide Web Consortium liefert die Definition über den Vergleich zu den frühen HTMLFormularen und erweitert dies in Festlegung auf bestimmte Protokolle und Sprachen(SOAP und
XML). Damit ist auch hier ein Web Service wieder eine Art Programm/Dienst, welches/welcher
über das Netz genutzt wird.
1.2.4
SUN
A Web service is, simply put, application functionality made available on the World Wide Web.
A Web service consists of a network-accessible service, plus a formal description of how to
connect to and use the service. The language for formal description of a Web service is an
application of XML. A Web service description defines a contract for how another system can
access the service for data, or in order to get something done. Development tools, or even autonomous software agents, can automatically discover and bind existing Web services into new
applications, based on the description of the service.
Noch weiter als Microsoft geht SUN, da hier noch eine Beschreibung der gelieferten Funktionalität gefodert wird. Außerdem sollen Entwicklungstools bzw. Software automatisch auf diese
Funktionen zugreifen können.
1.2.5
IBM
Web services are self-describing, self-contained, modular applications that can be mixed and
matched with other Web services to create innovative products, processes, and value chains.
Web services are Internet applications that fulfill a specific task or a set of tasks that work
with many other web services in a manner to carry out their part of a complex work flow or a
business transaction. In essence, they enable just-in-time application integration and these web
applications can be dynamically changed by the creation of new web services.
Wie auch SUN fodert IBM eine Beschreibung, aber zusätzlich noch Modularität der Applikation. Durch die Kappselung der Funktionaltät sieht IBM die Möglichkeit diese dynamisch
zu verändern durch Schaffung neuer Dienste. Mit anderen Worten: Web Services können auf
andere Web Services zurück greifen, um neue Funktionen bereit zustellen (vgl. Definition nach
SUN).
1.3. INHALTE
1.2.6
3
Zusammenfassung
Was ist nun ein Web Service? Ein breites Spektrum an Möglichkeiten, wie es die Definition
c -Technologie von Microsoft? Die Schnittmenge aller
nach Intel zuläßt oder gar nur die .NET
vorangegangen Begriffserklärungen trifft es wohl am besten. In Anlehnung an die Beschreibung
des Begriffs nach Mario Jeckle [7] sind Web Services Dienstleistungen, die
1. über Verzeichnisse (z.B. UDDI) zu finden,
2. in einer bestimmten Form beschrieben (z.B. WSDL) sind,
3. über Protokolle (z.B. SOAP) transportiert werden und
4. in ihre Inhaltsdarstellung (z.B. XML) festgelegt sind.
Durch diese Forderungen gelingt es Dienste zu schaffen, die zwischen unterschiedlichen Systemen
geliefert oder ausgetauscht werden (Interoperabilität).
Abbildung 1.1: Zwiebelschalenmodell nach Jeckle - Definition von Web Services
1.3
Inhalte
Web Services beinhalten verschiedene Funktionen, das kann B2B-Funktionalität sein, sprich
z.B. das Speichern von Kundendaten für verschiedene Versandhäuser oder auch mathematischer
Natur (z.B. Berechnungsroutinen - siehe Kapitel 4). Hier einige mögliche Szenarien [13]:
• Reisebüro:
Weil Reisebüros die Services vieler Anbieter in ihrem Angebot bündeln, macht es Sinn,
Web Services in ihre internen und externen web-basierten Systeme aufzunehmen. Agenten eines Reisebüros könnten Informationen über die günstigsten Angebote für ihre Kunden in einer Intranet-Anwendung nachschlagen, die Web Services nutzt, um EchtzeitPreisinformationen von Flugtickets, Mietwagen, Hotelzimmern und Pauschalangeboten
zu suchen und zu finden. Das gleiche Büro könnte diese Funktion direkt seinen Kunden
verfügbar machen, indem es diese Web Services in eine externe Web-Site einbaut.
• Anwendungen im B2B- und B2C-Bereich:
Den größten Nutzen werden Web Services im B2B-Bereich bringen. Die Abwicklung von
Bestell-, Liefer- und anderen Abwicklungsvorgängen lässt sich mit Hilfe von Web Services
deutlich vereinfachen. Der Vorteil für den Lieferanten liegt hier darin, dass eine Anwendungsintegration über Web Services im Regelfall deutlich einfacher zu implementieren ist
als über eventuell bereits bestehende EDI-Schnittstellen. Im B2C-Bereich hingegen wird
man sehen müssen, ob es dort gelingt, kommerziell erfolgreiche Web Services zu etablieren.
Externe Anwendungen und Datenbanken im Business-to-Business-Bereich können unabhängig von der Datenquelle und Plattform in interne Prozesse eingebunden werden.
4
KAPITEL 1. DEFINITION UND INHALT VON WEB SERVICES
Bestellungen wirken sich nicht nur auf die interne Buch- bzw. Lagerhaltung, sondern unmittelbar auch auf die Verwaltungssysteme und die Warenhaltung des externen Dienstleisters bzw. Lieferanten aus. Software-Ressourcen externer Dienstleister wie z.B. Zahlungsdienste können in eigene Ressourcen integriert werden. Allmählich entstehen dabei
Warenwirtschaftssysteme mit plattformübergreifender und globaler Datenhaltung auf der
Basis der Web-Service-Technologie, die einen echten Integrationsschub und viele Einsparungen bei B2B-Geschäftsprozessen bewirken.
Ein wesentlicher Anwendungsbereich werden neue Formen des Customer Relationship
Management (CRM) sowie Marketing und Vertrieb sein. Ausgeklügelte After-Sales-Tools
und neue Kundenservices werden zur Kundenbindung auch im Internet beitragen.
• Private Anwendungen:
Für private Anwender erreicht die Internetnutzung durch die Integration der Web Services
neuen Komfort und Vielfalt. Wer z.B. Tickets oder Veranstaltungskarten bestellt, bezahlt
unmittelbar online und kann sich die geeignete Wegbeschreibung auf einer Karte anzeigen
lassen und könnte dann noch nach günstigen Hotels in der Nähe fragen.
Kapitel 2
Die Rolle von XML
2.1
XML-Technologien zur Datenpräsentation
Wozu dann aber XML, wenn es in einem proprietären Datenformat kompakter gespeichert
werden kann? Ganz einfach weil es nicht austauschbar ist. Das in XML nicht nur Dokumenteninhalte repräsentiert werden können soll dieses Beispiel (Integer-Variablen zahl mit Wert 123)
verdeutlichen:
<datatype name="integer" variablename="zahl">
123
</datatype
Wenn die Datenhaltung in XML erfolgt ist es ein leichtes diese eigene Darstellung (z.B. eigne DTD/XSD) in die des Partners umzuformen, indem man sich Zwecks Interaktion auf eine
DTD/XSD einigt. Man also weiterhin sein eigenes Format verwenden (bzgl. Logik) und dennoch
mit anderen Daten austauschen.
2.2
2.2.1
Technologien zur Darstellung und Verarbeitung von
XML repräsentierten Daten und Wissens
Baumorientiert - DOM
Das Document Object Model, überführt eine XML-Datei in ein baumstrukturiertes Objekt.
Dabei werden die einzelnen Tags auf Knoten abgebildet und entsprechend der Tag-Struktur
folgt die Baumstruktur. DOM ist also hierachieerhaltend, was in zum Bearbeiten der Daten
und das spätere “Zurückschreiben“ notwendig ist. Dazu ein kleiner Java-Code-Auszug:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse("priceList.xml");
Node rootNode = document.getDocumentElement();
NodeList list = document.getElementsByTagName("coffee");
Wenn in der Preisliste also nach Kaffee gesucht wird, dann hier eine Liste zurückgegeben, die
die Tag-Elemente des Tags “coffee“ enthalten. Bei folgender XML-Datei: <priceList>
<coffee>
<name>Mocha Java</name>
<price>11.95</price>
</coffee> [..]
bestünde nun die Möglichkeit die Liste nach Namen und Preisen, der einzelnen Kaffeesorten zu
durchsuchen.
DOM parst dabei immer das komplette XML-Dokument und ist dadurch auch entsprechend
aufwendig, entsprechende Abhilfe versucht JDOM zu schaffen. Die Java Erweiterung JDOM,
6
KAPITEL 2. DIE ROLLE VON XML
die gleichermaßen auf SAX (2.2.2) und DOM zurückgreift, versucht die Komplexität des DOM
Parsers mit SAX zu “umschiffen“ und stellt damit eine Alternative zu DOM dar.
2.2.2
Ereignisorientiert - SAX
Im Gegensatz zu DOM ist die Simple API for XML eine Datenrepräsentation für XML, die
ereignisorientiert ist. Ein Ereignis ist ein öffnendes oder ein schließendes Tag. Über die Behandlung dieser Ereignisse können Daten aus der XML ausgewählt werden. Da aber nach der
Ereignisbehandlung die durchlaufenen Knoten “vergessen“ werden, sprich in SAX keine Hierachie angelegt wird, ist eine Änderung der XML mittels SAX nicht möglich.
Im Beispiel bedeutet das:
public void startElement(..., String elementName, ...){
if(elementName.equals("name")){
inName = true;
} else if(elementName.equals("price") && inMochaJava ){
inPrice = true;
inName = false;
}
}
public void characters(char [] buf, int offset, int len) {
String s = new String(buf, offset, len);
if (inName && s.equals("Mocha Java")) {
inMochaJava = true;
inName = false;
} else if (inPrice) {
System.out.println("The price of Mocha Java is: " + s);
inMochaJava = false;
inPrice = false;
}
}
Sobald ein Auftreten von dem Tag “name“ gefunden wird befindet man sich “inName“, die
Methode characters gibt dann gegebenenfalls den Preis für “Mocha Java“ aus.
Kapitel 3
Architekturschema für Web
Services
3.1
Architektur
In der Architektur von Web Services finden sich die Forderungen der Definition sichtbar wieder.
Bei Web Services geht natürlich nichts ohne das Netz, so fusst das Ganze auf der Netzwerkschicht, also TC/IP (was nach OSI1 Schichtenmodell eigentlich zwei Schichten sind). Darüber
sind Protokolle aus der OSI-Anwendungsschicht zu finden: HTTP und Sendmail, sowie die
Auszeichnungssprache XML. Unter anderen Umständen würden die beiden Komponenten auf
unterschiedlichen Ebenen dargestellt werden hier aber verdeutlich es, dass die sie zusammen
Dienste für die darüberliegenden Schicht erbringen. Dies ist das Simple Object Access Protocol,
der Datenaustauschdienst für Web Services - siehe 3.2. Daran schließen sich WSDL (3.3) und
UDDI (3.4) an. Den Abschluß bildet die eigentliche Anwendung, der angebotene Dienst. Alles
in allem umfasst die Web Service Architektur Protokolle (wie SOAP), Standards (wie XML,
WSDL und UDDI) und den “beliebigen“ offerierten Dienst.
Web Service
UDDI
WSDL
SOAP
HTTP, Sendmail
Netzwerk
XML
TC/IP
Abbildung 3.1: Architektur von Web Services
3.2
SOAP - Simple Object Access Protocol
SOAP ist in erste Linie ein Protokoll, veröffentlicht unter http://www.w3.org/2000/xp/Group/
als offener Standard. Es gibt also nicht eine definiertes SOAP, sondern mehrere Implementationen, stellvertretend sei hier Apache-SOAP erwähnt (welches auch dem Beispiel im folgenden
1 International
Standards Organisation
8
KAPITEL 3. ARCHITEKTURSCHEMA FÜR WEB SERVICES
Kapitel zugrundeliegt). Die Grundidee hinter SOAP ist interoperabler und entfernter Methodenaufruf und Nachrichtenaustausch. Diese Interoperabilität stellt das Datenaustauschformat
XML in SOAP sicher und die fehlende Festlegung (aber: Empfehlung HTTP) auf ein bestimmtes Transportprotokoll. SOAP Messages sind also leicht von Mensch beziehungsweise Maschine
lesbar beziehungsweise interpretierbar. SOAP definiert, welches Format die XML Nachricht hat,
die dann zum Austausch und RPC genutzt wird: die Nachricht kommt in einem “Umschlag“,
den SOAP-Envelope. Die Nachricht selbst ist in Header und Body gegliedert. Ein kleines Beispiel [5]:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<t:TransactionCode xmlns:t="my-URI" xsi:type="xsd:int"
mustUnderstand="1" actor="http://schemas.xmlsoap.org/soap/actor/next">
156533245
</t:TransactionCode>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<method:getNextViLiS xmlns:method="my-URI2">
<xCoord>15</xCoord><yCoord>124</yCoord>
</method:getNextViLiS>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Der optionale Header enthält Zusatzinformationen und ist dezentral erweiterbar (d.h. der andere
Kommunikationspartner muß darüber nichts wissen). Der Header kann wiederum eine beliebige
Anzahl von Subelementen enthalten, die sogenannten Header-Einträge. Jeder Header-Eintrag
muß durch eine Namespace-Angabe qualifiziert sein und kann neben beliebigen proprietären
Attributen auch noch zwei durch SOAP spezifizierte Attribute besitzen, die Aufschluß darüber
geben, für wen die SOAP-Nachricht bestimmt ist:
• Das actor-Attribut gibt an, für wen diese Nachricht alles bestimmt ist. Dieses Attribut ist
deswegen interessant, da eine SOAP-Nachricht auf ihrem Weg zum endgültigen Empfänger
mehrere - durch das actor-Attribut angegebene - Zwischenstationen passieren kann, bei
denen die Nachricht gelesen und geändert werden kann. Bei dem actor-Attribut wird die
Zwischenstation, für die die Nachricht bestimmt ist durch eine URI spezifiziert. Wird
kein actor-Attribut angegeben, so ist festgelegt, daß dieser Teil der Nachricht nur für den
endgültigen Empfänger von Interesse ist.
• Das mustUnderstand-Attribut legt fest, ob dieses Element vom Actor verarbeitet werden
muß oder nicht. Ist die Verarbeitung durch das mustUnderstand-Attribut vorgeschrieben
und der Actor kann es nicht, so muß er eine SOAP-Fehlermeldung (Fehlercode: MustUnderstand) zurückschicken. Der Default-Wert für dieses Attribut ist 0, d.h. ein Actor muß
dieses Element nicht verarbeiten können.
Im Body (nicht optional!) finden sich die eigentlichen Nutzdaten, z.B. Parameter für den
RPC. Das Body-Element muß im Namespace SOAP-ENV (genauer: in der zugehörigen URI
http://schemas.xmlsoap.org/soap/envelope/) enthalten sein. Innerhalb des Body-Elements
wird in diesem Beispiel über die URI my-URI2 die zugehörige Schnittstelle beschrieben, zu der
die aufzurufende Methode getNextViLiS gehört. Die Tags innerhalb des Methodentags (xCoord
und yCoord) stehen jeweils für einen Parameter, wobei der Tagname mit dem Parametername
identisch sein muß. Innerhalb eines Parametertags steht der Wert, der als Parameter übergeben
wird.
Mit SOAP ist das sozusagen das “WIE“ (kommuniziert ein Web Service) definiert, widmen
wir uns nun dem “WAS“ (beinhaltet ein Web Service).
3.3. WSDL - WEB SERVICE DESCRIPTION LANGUAGE
3.3
9
WSDL - Web Service Description Language
Um Dienste im Netz anzubieten muss gesagt werden was angeboten wird (analog der berühmten “Katze im Sack“: denn wenn nicht bekannt ist welche Parameter man übergeben muss,
dann man hinreichend schlecht überhaupt welche übergeben). Dies geschieht durch die Web
Service Description Language, welche durch Microsoft und IBM gemeinsam entwickelt wurde.
Die Beschreibung wird, wie sollte es anders sein, auch in einem XML-Dokument festgehalten.
Eine besonderer Rolle spielt hier der XML Schema Standard, der eingebettet, Typdefinitionen
liefert. Die einzelnen Teile auf einen Blick:
• <definitions>: Hier werden Namensräume und ähnliches definiert.
• <types>: Definiert die benutzten Datentypen (in XML Schema).
• <message>: Teilt die Nachrichten (Grundlage für die später ausgeführten Operationen) in
logische Einheiten ein.
• <portType>: Abstrakte Definition eines Ports: Definition möglicher Operationen und die
damit verbundenen Nachrichten.
• <binding>: Ordnet dem PortType ein konkretes Protokoll zu.
• <service>: Faßt die einzelnen (“gebundenen“) Ports zu einem Service zusammen.
• <documentation>: Beinhaltet Dokumentationstext.
Beispiel:
<?xml version="1.0"?>
<definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace=http://example.com/stockquote.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
10
KAPITEL 3. ARCHITEKTURSCHEMA FÜR WEB SERVICES
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
Dieses WSDL-Dokument beschreibt einen Dienst (StockQuoteService), der den letzte (aktuelle) Handelspreis von Aktien liefert. Dabei wird der Operation GetLastTradePrice eine
SOAP-Message zugeordnet, die als Input die Nachricht GetLastTradePriceInput führt, welche als Parameter den Typ TradePriceRequest2 hat und als Output Message den TradePrice
beinhaltet.
Abschließend sei hier JWSDL angeführt, welche, wie der Name schon vermuten läßt, die zugehörige Java API ist.
3.4
UDDI - Universal Service Description, Discovery and
Integration
Um zu wissen “WO“ ein Web Service genutzt werden kann, bedarf es einer Art Verzeichnis/Telefonbuch, wo diese registriert sind. Genau das hat sich UDDI zum Ziel gesetzt, und
gliedert sich dabei in drei Teile:
• den white pages - Namensregister, sortiert nach Namen, Auflistung der Anbieter mit allen
Detailangaben und Kontaktinformationen (Telefon,. . . )
• den yellow pages - Branchenverzeichnis, Spezifische Suche, gemäß verschiedener Taxonomien (Ort, Dienstart, Branche) Verweist auf White Pages
• den green pages - Informationen über Geschäftsmodell des Unternehmens, Technische
Details zu angebotenen Web Services, Auskunft über Geschäftsprozesse
UDDI nutzt SOAP-Nachtichten zur Kommunikation und beinhaltet auch einige XML Schema
Definitionen für Datentypen die zur Registrierung gesendet bzw. empfangen werden. So könnte
eine solche Nachricht z.B.:
2 das
ist nicht anderes als ein Identifier für die jeweilige Aktie
3.5. EBXML - EBUSSINESS XML
11
<find_business generic="2.0" xmlns="urn:uddiorg:api_v2">
<findQualifiers>
<findQualifier>caseSensitiveMatch</findQualifier>
<findQualifier>sortByNameAsc</findQualifier>
</findQualifiers>
<name>Siemens%</name>
</find_business> als Anfrage (nach aufsteigend alphabetisch geordneten Services der Firma
“Siemens“ - unter Beachtung der Groß- und Kleinschreibung) enthalten.
3.5
ebXML - eBussiness XML
Ein nebenläufiger (von SOAP bis UDDI) Standard ist ebXML, welcher einige zuvor genannten
Standards nutzt, teilweise aber auch eigne Lösung bietet, dazu gehört: [10]
• Collaboration Protocol Profile (CPP) - beschreibt die Dienste in einen standardisierten,
übertragbaren Art, wobei nicht nur bereitgestellten Prozesse beschrieben werden, sondern
auch die der Interaktionspartner. (vgl. WSDL)
• Collaboration Protocol Agreement (CPA) - beschreibt die genauen Vorraussetzungen und
Mechanismen zur Interaktion, eine Art “Vertrag“, zwischen den Kommunikationspartnern.
• Bussiness Process and Information Modeling - von ebXML bereitgestellte Beschreibungsmodell für Bussiness Prozesse (z.B. Transaktionen, Workflow, aber auch Datenhaltungsformate usw.).
• Core Components - Menge an XML Schemas, welche Formate für Bussinessdaten (z.B.
Datum, Steuer, Anzahl etc.) enthalten.
• Messaging - nutzt SOAP unter fügt Unterstützung für Anhänge, Sicherheit und gesicherter
Übertragung (⇒ wichtig in eBussiness)
• Registry/Repository - speichert CPP, CPA und Core Components, wobei diese Registry
ein lokaler Container sein kann, welcher durch ein CPP (das selbst via UDDI registriert
ist) referenziert wird.
3.6
Architektur im Ablauf
Zum Schluß hier eine kleine Übersicht, wie die einzelnen Architekturkomponten zusammen
spielen:
Abbildung 3.2: Rollen in der Architektur von Web Services - [6]
Von der Requestor-Seite ist es wichtig einen Dienst zufinden (Service Broker) und aufzurufen
12
KAPITEL 3. ARCHITEKTURSCHEMA FÜR WEB SERVICES
(interact). Der Dienstprovider hat großes Interesse dem potentiellen Kunden den gewünschten
Dienst aufzuzeigen. Der Dienstanbieter sieht seinen Nutzen darin den Dienst möglichst gut
frequentiert zu wissen (ergo: auch gut registriert). In allen drei Fällen wird deutlich, dass auf
UDDI, WSDL und SOAP zurück gegriffen wird.
Das Zusammenspiel unter der Java API for XML:
Abbildung 3.3: JAX bietet auch die Möglichkeit Web Services zu entwickeln - [10]
Kapitel 4
Beispiel für einen Web Service
4.1
Übersicht
Das hier gezeigt Beispiel ist der Apache-SOAP 2.3 Implementation entnommen. Es handelt sich
um einen Dienst, der die Funktionen plus(x,y), minus(x,y), divide(x,y) und times(x,y)
zur Verfügung stellt. Auf der Client-Seite fungiert ein stackbasierter Taschenrechner mit grafischer Oberfläche.
Um die Funktionen bereit zu stellen müssen diese registriert werden, dies realisiert der sogenannte Deployment-Descriptor. Im Deployment-Descriptor, einer XML-Datei, wird beschrieben
unter welcher id der Dienst erreichbar ist und welche Funktionen ausgeführt werden. In unserem Fall handelt es sich um ein Java-Skript, welches direkt in den Deployment-Descriptor
eingebettet ist. Natürlich können auch Java-Klassen diese Funktionen bereitstellen, das wird
dann anders vermerkt (siehe [5]). Darüberhinaus ist es möglich einen Dienst per HTTP über
das SOAP-Admin-Tool zu registrieren.
Der Client kann diese Methoden dann aufrufen indem er in seiner Java-Klasse den SOAP-Call
implementiert (und die benötigten SOAP-Klassen importiert) und dann den (RP)Call mit den
Parametern losschickt.
Genug der Vorrede, so sieht das ganze dann im Quellcode aus:
4.2
4.2.1
Der Quellcode
Dienst - Web Service
Als XML File sieht die Registrierung des Dienstes folgendermaßen aus:
<?xml version="1.0"?>
<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:xml-soap-demo-calculator">
<isd:provider type="script" scope="Application"
methods="plus minus times divide">
<isd:script language="javascript">
function plus (x, y) {
return x + y;
}
function minus (x, y) {
return x - y;
}
function times (x, y) {
return x * y;
}
function divide (x, y) {
14
KAPITEL 4. BEISPIEL FÜR EINEN WEB SERVICE
return x / y;
}
</isd:script>
</isd:provider>
<isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
</isd:service>
Übergeben wird diese Deployment-Descriptor mit dem Befehl java org.apache.soap.server.
ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter deploy
DeploymentDescriptor.xml (die Classpath sollte den Zugriff auf soap.jar;mail.jar; activation.jar;
xercesImpl.jar; xml-apis.jar; xmlParserAPIs.jar ermöglichen). Hier wird eine Java-Klasse
aufgerufen (per Kommandozeile), die dann den Dienst registriert.
4.2.2
Client
Hier nur der Auszug der relevanten Methode, die den Web Service kontaktiert:
private double doOp (String op, double arg1, double arg2) throws SOAPException {
// Build the call.
Call call = new Call ();
call.setTargetObjectURI ("urn:xml-soap-demo-calculator");
call.setMethodName (op);
call.setEncodingStyleURI(encodingStyleURI);
Vector params = new Vector ();
params.addElement (new Parameter("arg1", double.class, new Double (arg1), null));
params.addElement (new Parameter("arg2", double.class, new Double (arg2), null));
call.setParams (params);
// make the call: note that the action URI is empty because the
// XML-SOAP rpc router does not need this. This may change in the
// future.
Response resp = call.invoke (/* router URL */ url, /* actionURI */ "" );
// Check the response.
if (resp.generatedFault ()) {
Fault fault = resp.getFault ();
System.err.println("Generated fault: " + fault);
return Double.NaN;
} else {
Parameter result = resp.getReturnValue ();
return ((Double)result.getValue ()).doubleValue ();
}
}
Anmerkung: encodingStyleURI ist ein String der beim Aufruf der Client-Java-Klasse mit übergeben wird (genutzt wurde: “http://localhost:8080/soap/servlet/rpcrouter“). Der gesamte Quelltext ist dem Apache-SOAP-2.3-Download (http://apache.org)zu entnehmen.
4.3. DAS ERGEBNIS
4.3
15
Das Ergebnis
Das Ergebnis ist, dass es funktioniert und das es zur Nachahmung animieren soll. Anbei nur
ein kleiner Screenshot (4.1) der den Rechner und das SOAP-Admintool zeigt.
Abbildung 4.1: Das Apache-SOAP-Admin-Tool im Hintergrund und die Client-Anwendung, der
Rechner, im Vordergrund
16
KAPITEL 4. BEISPIEL FÜR EINEN WEB SERVICE
Kapitel 5
Epilog
5.1
Zusammenfassung und Ausblick
“Was sind Web Services?“, diese am Anfang gestellte Frage ist nun sicher beantwortet, aber
“Wohin bringen uns Web Services?“ ist die jetzt aufkommende Frage.
Im Internet der Zukunft wird sich sicher das fortsetzen und feste Formen annehmen, was zur
Zeit noch im Fluß ist: Standards. Das XML auf Grund seiner einfachen und doch ausdrucksstarken Gestalt die Entwicklung neuer Netztechniken prägt und prägen wird ist sicher keine Frage.
SOAP wird durch XMLP (XML Protocols) weiterentwickelt und die JAX∗ ist z.Zt. schon als
Download unter “Java Web Services Developer Pack v1.1“ erhältlich. Was die weiteren Standards betrifft: so wird die Microsoft .NET-Technologie wird ihren Platz im Netz einnehmen,
aber auch die offenen Architekturen, wie (zuvor genannt) Java, IBM und den ganzen Apache
Projekten. Eingesparte Kosten sind auch hier kein zuvernachlässigender Punkt, wobei es sicher
noch an der Benutzerfreundlichkeit der freien Tools mangelt (was in jedoch nur noch eine Zeitfrage ist, bis dieses Manko beseitigt wird ⇒ [10]).
Web Services werden verstärkt im Bereich Marketing und Vertrieb zum Einsatz kommen [2], da
sie leichte Erweiterbarkeit schaffen und die Heterogenität des Internets überbrücken. Man wird
mehr zusammen arbeitet und gemeinsam Dienste und Dienstleistungen nutzen. Zum Einem,
so die Hoffnung, wird dadurch eBussiness stark vorangebracht und die Anzahl der verfügbaren
Anwendungen steigt und zum Anderen: es spart Ressourcen und damit auch Kosten.
5.2
Verwendete Literatur
• [10] - Anleitung zur Erstellung von XML basierten Web Services mit der Java 2 Platform.
• [4] - SUN Artikel stellt (ähnlich zu [10]) XML Web Services vor.
• [3] - Stellt zwei Programme zur Entwicklung von Web Services vor.
• [7] - Die HTML Seiten von Mario Jeckle zum Thema Web Services.
• [6] - Vortrag zu Web Services.
• [9] - Vortrag zu Architektur von Web Services.
• [8] - Vortrag zum Thema: Web Services - Vision, Standards und Potential.
• [12] - Allgemeines zu XML.
• [5] - Vortrag zum Thema XML und SOAP (sehr verständliche, durchdachte Folien).
• [13] - Leichte (einfacher) Zugang zu Web Services.
18
KAPITEL 5. EPILOG
• [1] - Standardwerk für XML (“and Related“).
• [2] - Eine Studie über Web Services.
• [11] - Weiterer Vortrag über XML.
5.3
Wichtige Begriffe
UDDI Universal Service Description, Discovery and Integration - der zu den Web Service
gehörende Verzeichnisdienst.
WSDL Web Service Description Language - Beschreibungssprache zur Definition der angebotenen Schnittstellen, z.B. Aufrufkonventionen, Übergabeparameter etc.
SOAP Simple Object Access Protocol - definiert (und standardisiert) Kommunikationmechanismen, sowie das Übertragungsformat.
DOM Document Object Model - baumorientiertes Interface zum Zugriff auf XML-Dokumente
(W3C-Norm).
SAX Simple API for XML - im Gegensatz zu DOM eine ereignisorierentierte Schnittstelle.
JAXP Java API for XML Processing - vereint SAX, DOM und XSLT als einheitliche XMLParser-API für Java.
JAXR Java API for XML Registry - kommende Unterstützung von UDDI für die Java Platform
(nicht zwingend notwendig um Web Services zu bauen, wird es aber erleichtern). Der
Schwerpunkt liegt bei B2B-Anwendungen. Die Registry-Operationen sind selbst wieder
Web Services.
JAX/RPC Java API for XML / Remote Procedure Call - Schnittstelle für entfernten Methodenaufruf, basierend auf XML-Protokollen wie SOAP.
JAXM Java API for XML Messaging - API zur Nutzung bestimmter Nachrichtenstandards, wie
SOAP- und ebXML-Messaging.
JAXB Java API for XML Binding - konvertiert XML Dokumente in Java Objekte.
ebXML electronic bussiness XML - stellt einen Satz an XML Spezifikationen und Prozessen für
B2B-Zusammenarbeit und Integration zur Verfügung.
Literaturverzeichnis
[1] Behme, Henning und Mintert, Stefan: XML in der Praxis. Addison-Wesley, 2000.
[2] Cap
Gemini
Ernst
&
Young:
Der
Markt
für
Web-Services.
http://www.ch.cgey.com/servlet/PB/show/1004690/07.16.02ces G.pdf, 2002.
[3] Dyck, Timothy: Next-Gen Web Services. http://www.eweek.com, 31.03.2003.
[4] Fisher, Maydene: Introduction to Web Services.
http://java.sun.com/webservices/docs/1.0/tutorial/doc/IntroWS.html, 2002.
[5] Geiger, Jan: XML Schema und SOAP in verteilten Anwendungen.
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/edudoc/WebTut/5 SOAP XMLSchema/
XMLSchema SOAP-Dateien/frame.htm, 01.06.2001.
[6] Jeckle, Mario: Web Services. http://www.jeckle.de, 05.12.2002.
[7] Jeckle, Mario: Web Services - HTML-Seiten. http://www.jeckle.de, 17.04.2003.
[8] Jeckle, Mario: Web Services - Vision, Potential und Standards. http://www.jeckle.de,
18.11.2002.
[9] Jeckle, Mario: Web Services Architecture. http://www.jeckle.de, 29.11.2002.
[10] Kao, James: Developer’s Guide to Building XML-based Web Services with the Java 2
Platform, Enterprise Edition (J2EE). http://www.theserverside.com, 2001.
[11] Mattern, Prof. Dr. F.: Web Services.
http://www.inf.ethz.ch/vs/edu/SS2002/DS/slides/01 WebServices.pdf, April 2002.
[12] Tolksdorf, Robert: XML und darauf basierende Standards: Die neuen Auszeichnungssprachen des Web.
http://link.springer.de/link/service/journals/00287/papers/9022006/90220407.pdf,
22.12.1999.
[13] Wolf,
Ilse
und
Wolf,
Rudolf:
Was
sind
http://www.monitor.co.at/index.cfm?issueid=158&rubid=180, 2003.
Web
Services?