Client/Server-Programmierung WS 2007/2008 Web Services: Schritt

Transcrição

Client/Server-Programmierung
WS 2007/2008
Web Services: Schritt-für-Schritt Anleitung
(Sitzungsverwaltung mit Hilfe von HTTP Cookies)
Version 1.1, 26.09.07
Eingesetzte Software:
- Apache Tomcat 5.5.9
- Axis 1.2.1
Hinweis:
Bevor mit Axis/Tomcat im Labor H-A 4111 das erste Mal gearbeitet werden kann, ist das
Installationsskript /opt/dist/tools/tomcat_install.sh auszuführen und die entsprechenden Umgebungsvariablen zu setzen, siehe Abschnitte 4.4.1 und 10.3.1 des Vorlesungsskripts.
Web Services
I. Erstellung eines Web Services (die Börsenanwendung als Web Service)
Die Erstellung eines Web Services (die Serverseite) mit Axis unter Verwendung von Axis-Tools
benötigt mehrere Schritte.
Nehmen wir an Sie haben die vorherigen Implementierungen im ToyDax Verzeichnis realisiert. Als
Demonstrationsbeispiel wird der Web Service ToyDaxServCache entwickelt, der Clients die
Möglichkeit bietet, die elf bekannten Methoden aufzurufen.
Schritt 1: Erstellung eines Java-Interface
Am Anfang müssen Sie die vom Web Service zur Verfügung gestellten Methoden in einem JavaInterface definieren. Z.B. können Sie das verwendete RMI-Interface anpassen. Die Abbildung zeigt die
Position des Java-Interfaces (Dax.java) innerhalb des Dateisystem:
ToyDax/
|---wscookie/
|--- Dax.java
Abbildung 1. Java-Interface Datei innerhalb des Dateisystems
Hinweis: Verwenden Sie die package Java-Direktive.
Übersetzen Sie die Interface-Datei mit:
javac Dax.java
Schritt 2: Erzeugung einer WSDL-Datei
Das zuvor entwickelte Java-Interface Dax.java wird dem Axis-Tool Java2WSDL übergeben. Daraus
wird ein WSDL-Dokument generiert und alle Methoden des Interface ToyDax.wscookie.Dax
aufgenommen werden. Die Erzeugung erfolgt durch den folgenden Komandoaufruf:
java org.apache.axis.wsdl.Java2WSDL \
-o ToyDax/wscookie/Dax.wsdl \
-l "http://localhost:8080/axis/services/ToyDaxServCookie" \
-n "services:Dax" \
ToyDax.wscookie.Dax
Der Aufruf bewirkt, dass die WSDL-Datei Dax.wsdl erzeugt wird (Voraussetzung: Sie arbeiten mit
dem Paket ToyDax.wscookie und Tomcat verwendet Portnummer 8080) . Die hierbei verwendeten
Optionen werden in Tabelle 1 erläutert. Für andere Optionen siehe Vorlesung und Referenzlisten.
Option
-o
-l
-n
Beschreibung/Auswirkung
Gibt den Dateinamen (hier Dax.wsdl) des zu erstellenden WSDL-Dokumentes an.
Gibt den URL des Web Service an, der in der WSDL-Datei beschrieben wird. Dieser URL
wird später von der Clientseite verwendet (hier wird der Web Service unter dem Namen
ToyDaxServCookie bekannt sein).
Beschreibt den Namespace des Services. In der WSDL-Datei findet sich dann der
Parameterwert des Namespaces in der folgenden Zeile wieder:
<wsdl:definitions targetNamespace="services:Dax"
xmlns:impl="services:Dax" xmlns:intf="services:Dax"
-s
...>
Gibt den Namen des Service an. Falls diese Option nicht verwendet wird, wird implizit der
Name, des mit -l spezifizierten URL, genommen.
Tabelle 1. Befehlsoptionen von Java2WSDL
Schritt 3: Übersetzung der WSDL-Datei in Java-Klassen
Die zuvor erzeugte WSDL-Datei wird durch den Einsatz eines weiteren WSDL-Tool von Axis, namens
WSDL2Java, übersetzt. Dieser Schritt erzeugt Java-Code für die Client- und Serverseite. Dieses
Vorgehen wird auch bei Middleware wie z.B. CORBA (Übersetzung der CORBA-IDL) verwendet. Die
Erzeugung erfolgt durch den folgenden Komandoaufruf:
java org.apache.axis.wsdl.WSDL2Java \
-d Session -s -S true \
-p ToyDax.wscookie.Dax_PKGwsdl ToyDax/wscookie/Dax.wsdl
Wie Sie merken, wurde für den Deployment Descriptor der Typ “Session“ gewählt, weil hier das
Session-Management von Axis verwendet werden soll. Axis bietet mehrere Möglichkeiten, Sessions zu
erzeugen. Der einfachste (und klar nicht der beste) Weg ist Cookies zu verwenden. Axis bietet dem
Entwickler an, durch das Setzen von Cookies seine Sessions zu verwalten. Deshalb soll die Clientseite
diese Vorgehensweise auch technisch unterstützen (siehe Erstellung eines Clients).
Die Java-Quellcodes werden in dem Zielverzeichnis ToyDax/wscookie/Dax_PKGwsdl erzeugt.
Wofür die einzelnen von WSDL2Java generierten Klassen zuständig sind ist in Kapitel 10.3.3 der
Vorlesungsfolien beschrieben. Die erzeugten Java-Quelldateien sind hier mit einer kurzen
Beschreibung aufgelistet:
• Dax.java (Java-Interface des Dienstes)
• DaxServiceLocator.java (Lokalisierung des Dienstes)
• DaxService.java (Hilfsklasse für Lokalisierung)
• ToyDaxServCookieSoapBindingImpl.java (Gerüst für die Dienst-Implementierung)
• ToyDaxServCookieSoapBindingSkeleton.java (Server-Skeleton – nicht unbedingt
nötig, wenn die Option -S true nicht verwendet wird!)
• ToyDaxServCookieSoapBindingStub.java (Client-Stub)
Zusätzlich werden die Deployment-Deskriptoren
• deploy.wsdd (Deployment-Descriptor für AdminClient)
• undeploy.wsdd (Deployment-Descriptor für AdminClient)
generiert.
Die hierbei verwendeten Optionen von WSDL2Java finden Sie in Tabelle 2:
Option
Beschreibung/Auswirkung
Erwartet als arg den Deployment-Zusatz Session, Application oder Request. Wird
-d arg
Session gewählt, wird für jeden neu anfragenden Client eine Session erstellt.
Erzeugt die Java-Klassen, die auf der Serverseite ausgeführt werden sollen:
- eine Skeleton-Klasse namens ToyDaxServCookieSoapBindingSkeleton.java
-s
- eine Implementierungsklasse ToyDaxServCookieSoapBindingImpl.java
Zusätzlich werden die Deployment-Descriptoren deploy.wsdd und undeploy.wsdd
erzeugt. Damit können Sie später den Service “aktivieren“ und “deaktivieren“.
Wenn diese Option angegeben ist, wird die Skeleton-Klasse deployt, ansonsten wird die
-S
Implementierungsklasse deployt.
Dies bewirkt, dass der übergebene Parameter als Paketname für die Java-Quelldateien
-p
verwendet wird.
Tabelle 2. Befehloptionen von WSDL2Java
Schritt 4: Einfügen der Programmlogik
Wie in Abbildung 2 dargestellt, wurde durch den Einsatz von WSDL2Java u.a. auch die Implementierungsklasse ToyDaxServCookieSoapBindingImpl erzeugt.
ToyDax/
|---wscookie/
|--- Dax.java
|--- Dax.wsdl
|--- Dax_PKGwsdl/
|--- Dax.java
|--- DaxServiceLocator.java
|--- DaxService.java
|--- ToyDaxServCookieSoapBindingImpl.java
|--- ToyDaxServCookieSoapBindingSkeleton.java
|--- ToyDaxServCookieSoapBindingStub.java
Abbildung 2. Die Anwendung von WSDL2Java auf das erzeugte WSDL-Dokument
Diese Klasse ist nur ein Gerüst, die Methoden haben nur einen Rumpf, weil Axis noch keine
Programmlogik eingefügt hat. Hier müssen Sie zwei wichtige Ergänzungen durchführen. Erstens
müssen Sie alle Methoden implementieren und zweitens den Konstruktor ergänzen.
Nehmen wir als Beispiel zwei Methoden. Für die Methoden AGs() und Buy() wurde der folgende
Code erzeugt:
public class ToyDaxServCookieSoapBindingImpl
implements ToyDax.wscookie.Dax_PKGwsdl.Dax
{
...
public java.lang.String[] AGs() throws java.rmi.RemoteException {
return null;
}
...
public boolean Buy(java.lang.String in0, int in1)
throws java.rmi.RemoteException {
return false;
}
}
Tipp: Es ist durchaus möglich, dass Axis den ursprünglichen Methodennamen, so wie die in die Interface-Datei
vorkommen, verändert hat. Wenn dieses Phänomen passiert, müssen Sie auf der Clientseite die Aufrufe anpassen.
Die Klasse muss nun für die eigenen Zwecke umprogrammiert werden. Die einfachste Variante ist
wrapper-Klassen bzw. -Methoden zu verwenden (genau wie bei der RMI Implementierung). In der
Methode AGs() müssen Sie z.B. die wrapper-Methode der statischen Klasse (oder des ersten Objektes,
wenn Sie eine Instanz der Klasse erzeugt haben), im Beispiel DaxServer genannt (siehe Übungsblatt
1), aufrufen:
public java.lang.String[] AGs() throws java.rmi.RemoteException
{
return DaxServer._AGs();
}
Für die Buy() Methode müssen Sie die wrapper-Methode des zweiten Objekts aufrufen:
public boolean Buy(java.lang.String AG, int Menge)
throws java.rmi.RemoteException
{
return (depot.Buy(AG, Menge));
}
Der Konstruktor sollte eine Instanz des Depot-Objekts (oben depot genannt) erzeugen:
public ToyDaxServCacheSoapBindingImpl() {
depot = new Depot();
...
}
Durch Hinzufügen von Programmlogik und die nötigen import-Anweisungen entsteht die
Applikationsklasse, die im letzten Schritt deployt werden kann.
Schritt 5: Kopieren der nötigen class-Dateien in das Axis-Verzeichnis
Falls Tomcat gestartet ist, müssen Sie ihn stoppen. Nachdem Sie die Java Dateien mit dem Befehl:
javac ToyDax/wscookie/Dax_PKGwsdl/*.java
übersetzt haben, müssen Sie die class-Dateien in das Axis-Verzeichnis $CATALINA_BASE/
webapps/axis/WEB-INF/classes kopieren:
cp --parents -uv ToyDax/wscookie/Dax_PKGwsdl/*.class \
$CATALINA_BASE/webapps/axis/WEB-INF/classes
Sie können jetzt den Tomcat neu starten (cd /tmp; $CATALINA_HOME/bin/catalina.sh run).
Schritt 6: Das Deployment des Web Service
In Schritt 3 wurde von WSDL2Java u.a. auch der Deployment Deskriptor deploy.wsdd für den Web
Service erstellt. Um zu erklären, was beim Depoyment passiert, sollten Sie den Deployment Deskriptor
näher unter die Lupe nehmen. Wie dem Inhalt dieser Datei zu entnehmen ist, wurde die Skeleton
Klasse als Aufrufer des Dienstes ausgewählt. In dem Code der Skeleton-Klasse wird dem anfragenden
Client ein neues Objekt der Implementationsklasse zur Verfügung gestellt. Bezogen auf diese Aufgabe
lässt sich in der Klasse ToyDaxServCookieSoapBindingSkeleton der folgende Code finden, aus
dem hervorgeht, weshalb im Deployment Deskriptor die Skeleton-Klasse statt der ImplementierungsKlasse angegeben wird:
public ToyDaxServCookieSoapBindingSkeleton()
{
impl = new
ToyDax.wscookie.Dax_PKGwsdl.ToyDaxServCookieSoapBindingImpl();
}
Das Deployment erfolgt durch den folgenden Aufruf:
java org.apache.axis.client.AdminClient –p <port> \
ToyDax/wscookie/Dax_PKGwsdl/deploy.wsdd
Jetzt ist der Web Service unter Axis registriert. Die Option –p <port> ist immer dann erforderlich,
wenn Tomcat einen anderen Port als 8080 nutzt. Im Labor H-A 4111 müssen Sie für <port> die
Ihnen zugewiesene Port-Nummer angeben, die Tomcat auch beim Start ausgibt.
Hinweise:
a) Testen Sie, ob der Web Service wirklich erfolgreich deployt ist: Starten Sie einen Browser mit der
URL http://localhost:8080/axis (natürlich müssen Sie ggf. auch hier die 8080 durch die
Port-Nummer Ihres Tomcat ersetzen!) und klicken Sie auf den Link List auf der linken Seite. Sie
müssen den neuen Dienst jetzt sehen. Der Service ist nun in Betrieb.
b) Da Axis auch HTTP-GET Requests unterstützt, können Sie ihren Web Service mit einem Browser
direkt ausprobieren:
http://localhost:8080/axis/services/ToyDaxServCookie?method=AGs
sollte das gewünschte Ergebnis liefern.
c) Wenn Sie die Klassen des Web Service neu kompilieren (und auf den Server laden) sollten Sie den
Tomcat neu starten. Alternativ können Sie über den Tomcat Web Application Manager (unter der
URL http://localhost:8080/manager/html) auch nur Axis neu laden (Reload-Kommando
unter der Rubrik Applications). Oder Sie können mit dem Axis Admin-Tool den Service redeployen (undeploy, deploy). Das Undeployment erfolgt dabei durch den folgenden Aufruf:
java org.apache.axis.client.AdminClient –p <port> \
ToyDax/wscookie/Dax_PKGwsdl/undeploy.wsdd
d) Wie Sie bemerkt haben, ist es eine müsahme Arbeit, alle diese Schritte auszuführen. Hier könnte
man eine Skript-Datei einsetzen. Dafür sind eigentlich die Skript-Dateien gedacht. Schreiben Sie ein
Skript für das Erzeugung des Web Services mit Optionen für Deployment und Undeployment.
II. Erstellung eines Clients
Die Erstellung eines Clients setzt nicht zwangsweise voraus, dass der Web Service, mit dem
kommuniziert werden soll, mit Java programmiert ist. Es ist schlichtweg egal, welche Entwicklungstechnologie auf der Serverseite zum Einsatz kam. Wichtig ist nur, dass die Serverseite ein WSDLDokument zur Verfügung stellt.
Schritt 1: Übersetzung der WSDL-Datei in Java-Klassen
Beschaffen Sie das WSDL-Dokument (z.B. über die URL http://localhost:8080/axis/
services/ToyDaxServCookie?wsdl) und übergeben Sie es dem Axis-Tool WSDL2Java auf dem
Clientrechner zur Übersetzung. Genauso wie beim Server, generiert WSDL2Java dann die JavaQuelldateien für die Clientseite.
java org.apache.axis.wsdl.WSDL2Java -d Session \
-p ToyDax.wscookie.Dax_PKGwsdl Dax.wsdl
Die Beschreibung der verwendeten Optionen finden Sie in Tabelle 2. Die Client-Applikation benötigt
die folgenden Dateien:
•
•
•
•
Dax.java (Java-Interface des Dienstes)
DaxService.java (Hilfsklasse für Lokalisierung)
DaxServiceLocator.java (Lokalisierung des Dienstes)
ToyDaxServCookieSoapBindingStub.java (Client-Stub)
Schritt 2: Client-Code erstellen und übersetzen
Der Client-Code baut die Verbindung zum Web Service über den Service-Locator auf. Auf der
Serverseite wurde bei der Erzeugung des WSDL-Dokuments (Schritt 2 auf Serverseite) die URL
spezifiziert, unter der der erstellte Web Service erreichbar ist. Genau diese URL wurde von
WSDL2Java in die Service-Locator Klasse hineincodiert. Die serviceLocator Instanz dient dazu,
eine Referenz auf den Service zu erzeugen:
// Verbindung zum Web Service aufbauen
DaxServiceLocator serviceLocator = new DaxServiceLocator();
Der Service-Locator liefert nun eine Referenz auf den Service, die noch auf die Stub-Klasse gecastet
werden muß:
ToyDaxServCookieSoapBindingStub daxServer =
(ToyDaxServCookieSoapBindingStub)ServiceLocator.getToyDaxServCookie();
Durch den Aufruf der Methode setMaintainSession() in der Stub-Klasse wird Axis mitgeteilt,
dass der Client im Begriff ist, eine Session zu erzeugen und die nachfolgende Kommunikation über
dieses Session-Objekt ablaufen soll:
// Axis informieren, dass eine Session angelegt werden soll
daxServer.setMaintainSession(true);
Von diesem Punkt an können die Methoden des Web Service aufgerufen werden. Z.B. für die Methode
Buy():
System.out.print("Geben Sie den Namen der AG ein> ");
inAG = inputStream.readLine();
System.out.print("Geben Sie die Menge an Aktien ein> ");
inMenge = Integer.parseInt(inputStream.readLine());
if (daxServer.bBuy(inAG,inMenge))
{
// "Kauf von "+inMenge+" Aktien von "+ inAG+" war erfolgreich.";
}
else
{
// "Kauf von "+inMenge+" Aktien von "+inAG+" ist fehlgeschlagen!";
}
Durch das Hinzufügen der Client-Programmlogik und der nötigen import-Anweisungen entsteht die
Client Applikationsklasse (DaxWSClient gennant), die im letzten Schritt übersetzt werden kann:
javac
DaxWSClient.java
Nun können Sie den neu entwickelte Web Service mit der Client Applikation testen:
java
DaxWSClient
Die nötigen Kommandos können in einem Skript zusammengefasst werden:
----------------------------------------------------# Client (Session Management with Cookies!)
# Voraussetzung: die Datei Dax.wsdl ist vorhanden.
#
java org.apache.axis.wsdl.WSDL2Java -d Session \
-p ToyDax.wscookie.Dax_PKGwsdl Dax.wsdl
javac ToyDax/wscookie/Dax_PKGwsdl/*.java
javac DaxWSClient.java
III. Der TCP-Monitor
Der TCP-Monitor von Axis bietet die Möglichkeit, die an einen Web-Service gesendeten und vom
Web Service empfangenen SOAP Nachrichten im Klartext einzusehen. Deshalb ist dieses Tool
(Protokoll-Sniffer) sehr gut für die Fehlerbehebung geeignet. Der TCP-Monitor schaltet sich zwischen
den Dienstbenutzer und den Dienstanbieter und ist somit in der Lage, ein- und ausgehende Nachrichten
zu protokollieren. Der TCP-Monitor wirkt dabei, wie in Abbildung 4 angedeutet, als Brücke zwischen
Client und Server.
Abbildung 4. Arbeitsweise des TCP-Monitor
Der Client darf nun nicht mehr direkt den Web-Service ansprechen, sondern den zwischengeschalteten
TCP-Monitor, welcher die Anfrage an den Web-Service weiterleitet. Er darf also nicht mehr den Port
von Tomcat ansprechen, sondern den Port des TCP-Monitors (listenport in Abbildung 4). Um das zu
erreichen, können Sie entweder bei der Erzeugung des WSDL-Dokuments diese Port-Nummer
spezifizieren, oder (einfacher) im Client statt der Anweisung
(ToyDaxServCookieSoapBindingStub)ServiceLocator.getToyDaxServCookie();
die Anweisung
(ToyDaxServCookieSoapBindingStub)ServiceLocator.getToyDaxServCookie(
new java.net.URL(
"http://localhost:7117/axis/services/ToyDaxServCookie"));
verwenden, d.h. im Client den zu benutzenden Endpunkt direkt angeben (die 7117 sei hier der vom
TCP-Monitor verwendete Port).
Der TCP-Monitor visualisiert dann anschließend die Daten, bevor er sie an den Server übergibt. Sobald
der Server eine Antwort an seinen Client (jetzt den TCP-Monitor) sendet, werden die Informationen
wiederum visualisiert, bevor der TCP-Monitor diese wieder an den eigentlichen Client zurücksendet.
Das Tool soll folgendermaßen gestartet werden:
java org.apache.axis.utils.tcpmon [<listenport> [<targetHost>
<targetPort>]]
In unserem Fall sind die Parameter so zu setzen:
ein beliebiger freier Port z. B. 7<UserID>7
<targetHost>: localhost (oder Hostname des Tomcat Servers)
<targetPort>: 8080
(bzw. Ihr Tomcat-Port)
<listenport>:
wobei <UserID> die letzten beiden Ziffern ihres Logins sind (z.B. Login csp056 --> Portnummer 7567).
Verwenden Sie immer diese Portnummer, damit keine Kollisionen mit anderen Übungsteilnehmern
auftreten.
Nachfolgend ist der mit dem TCP-Monitor aufgezeichnete Kommunikationverlauf zwischen Client und
Web Service (Server) dargestellt,. wenn die Operationen 1,2 und 7 ausgeführt werden. Es wird angenommen, daß der Client-Code die folgenden wählbaren Operationen hat:
0 - Exit
1 - All AGs
2 - Value
3,4 - BigWinnerAG/BigWinnerGain
5 - Variance
6 - Tendence
7 - Buy
8 - Sell
9 - StockAmount
10 - StockValue
11 - CashBalance
==========================================================
Select an option: 1
==========================================================
Request:
POST /axis/services/ToyDaxServCookie HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.2.1
Host: localhost:7567
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 362
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:AGs
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="services:Dax"/>
</soapenv:Body>
</soapenv:Envelope>
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=66CFAABA5FA9BD105F6D29CBC5FF58D8; Path=/axis
Content-Type: text/xml;charset=utf-8
Date: Tue, 24 Jan 2006 17:59:07 GMT
Connection: close
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
<soapenv:Body>
<ns1:AGsResponse
xmlns:ns1="services:Dax">
<AGsReturn
soapenc:arrayType="soapenc:string[29]"
xsi:type="soapenc:Array"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<AGsReturn xsi:type="soapenc:string">ADIDAS-SALOMON AG</AGsReturn>
<AGsReturn
xsi:type="soapenc:string">ALLIANZ AG VNA O.N</AGsReturn>
<AGsReturn
xsi:type="soapenc:string">ALTANA AG O.N.</AGsReturn>
<AGsReturn
xsi:type="soapenc:string">BASF AG O.N.</AGsReturn>
...
<AGsReturn
xsi:type="soapenc:string">TUI</AGsReturn>
<AGsReturn
xsi:type="soapenc:string">Volkswagen</AGsReturn>
</AGsReturn>
</ns1:AGsResponse>
</soapenv:Body>
</soapenv:Envelope>
==========================================================
Select an option: 2
Geben Sie den Namen der AG ein> BMW
Geben Sie den Tag ein> 7
==========================================================
Request:
Pragma: no-cache
SOAPAction: ""
Content-Length: 682
Cookie: JSESSIONID=66CFAABA5FA9BD105F6D29CBC5FF58D8
<soapenv:Envelope
<soapenv:Body>
<ns1:Value
<in0 href="#id0"/>
<in1
xsi:type="soapenc:string"
BMW
</in1>
</ns1:Value>
<multiRef
id="id0"
soapenc:root="0"
xsi:type="xsd:int"
7
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
Response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=CA26F55338B2FCDC28C20401360A325A; Path=/axis
Date: Tue, 24 Jan 2006 18:10:20 GMT
Connection: close
<soapenv:Envelope
<soapenv:Body>
<ns1:ValueResponse
<ValueReturn href="#id0"/>
</ns1:ValueResponse>
<multiRef
id="id0"
soapenc:root="0"
xsi:type="xsd:double"
21.49
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
===============================================================
Select an option: 7
Geben Sie den Namen der AG ein> BMW
Geben Sie die Menge an Aktien ein> 100
--------------Response------------------7. Kauf 100 Aktien von BMW war erfolgreich.
----------------------------------------===============================================================
Request:
Pragma: no-cache
SOAPAction: ""
Content-Length: 680
Cookie: JSESSIONID=CA26F55338B2FCDC28C20401360A325A
<soapenv:Envelope
<soapenv:Body>
<ns1:Buy
<in0
xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>
BMW
</in0>
<in1 href="#id0"/>
</ns1:Buy>
<multiRef
id="id0"
soapenc:root="0"
xsi:type="xsd:int"
>
100
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
Response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=9D64F3C9FEE850973FB5B07B14A3F178; Path=/axis
Date: Tue, 24 Jan 2006 18:17:12 GMT
Connection: close
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
<soapenv:Body>
<ns1:BuyResponse
<BuyReturn href="#id0"/>
</ns1:BuyResponse>
<multiRef
id="id0"
soapenc:root="0"
xsi:type="xsd:boolean"
>
true
</multiRef>
</soapenv:Body></soapenv:Envelope>
Die Session-Informationen werden nicht in die SOAP-Nachrichten eingefügt, sondern in die HTTPInformationen. Weil der Axis-Laufzeitumgebung beim Deployment mitgeteilt wurde, dass dieser Web
Service als Session behandelt werden soll, fügt das Axis-Servlet bei Erzeugung der SOAP-Antwort die
HTTP-Information ein:
Set-Cookie: JSESSIONID=66CFAABA5FA9BD105F6D29CBC5FF58D8; Path=/axis
Diese Information wird von der Stub-Klasse auf Clientseite erkannt, ausgewertet und bei jedem
nachfolgenden RPC (dem Aufruf einer neuen Methode) an den Server übergeben:
Cookie: JSESSIONID=66CFAABA5FA9BD105F6D29CBC5FF58D8
Begriff: Cookies sind kleine Textdateien, die auf dem Clientrechner abgelegt werden. Sie erhalten
Informationen, die bei der nächsten Anfrage des Clients mit übertragen werden, um auf der Serverseite
festzustellen zu können, welcher Client gerade anfragt.

Client/Server-Programmierung WS 2007/2008 Web Services: Schritt

Transcrição

Documentos relacionados

Dax - Multi-Asset-Strategie - Trust-Wi

DAX und Dow Jones IA weekly - übergeordnete

Geldanlage: Future Beschreibung Im Unterschied zu Optionen, die

AXIS P1204 BULK 10 PCS

Parkhaus - aber SIcHer.

Inhaltsverzeichnis des Buches "Java für Windows"

JAVA – Installation und Einrichtung des Java

PDF öffnen

AXIS 214 PTZ

Übungen zur Softwaretechnik - Software and Systems Engineering

Anleitung - Die Post