 SOAP-PHP mit einem Beispiel

(1)

Inhalt:

 Begriff und Eigenschaften von Web-Services

 Protokolle: SOAP und REST

 SOAP-PHP mit einem Beispiel

 Ein Beispiel für einen REST-basierten Webservice

Peter Sobe Internettechnologien 1

6. Web Services

(2)

Web Services stellen wohl definierte Dienste dar, die von Web- Applikationen im Internet von den Dienste-Anbietern abgerufen werden können.

Definitionen:

Die Web Services Architecture Arbeitsgruppe vom W3C definiert Web Services als

"ein durch eine URI (nach RFC2396) identifiziertes Softwaresystem, dessen öffentliche Schnittstellen und

Protokollbindungen durch XML definiert und beschrieben sind."

Was sind Web Services?

(3)

Im Unternehmen Daimler-Chrysler wird meistens folgende Definition verwendet:

"`A Web Service is a piece of server-side software that provides a certain functionality (as a black box) and is accessible through Internet protocols using XML/SOAP messages with a described and published interface

(typically by means of WSDL).

Those interface descriptions should be registered in a (global) registry such as UDDI."'

Was sind Web Services?

(4)

Im Software-Engineering sieht man darin eine Entwicklungs- richtung, die so genannte Service Orientierte Architektur (SOA).

Im Gegensatz zu bisherigen Entwicklungen bei Web-

Applikationen, wie die so genannte Middleware bei verteilten

Systemen, z.B. Unix-RPC, RMI, CORBA oder DCOM, aber auch bei Browsern , HTML – Versionen usw. ist der Bereich Web

Services gegenwärtig noch durch eine relativ konstruktive und offene Kooperation führender IT-Firmen (Microsoft / IBM / SUN/

Oracle / HP / SAP / Software AG / ... ) geprägt.

Die bislang definierten Entwürfe und Standards basieren generell auf den Web-Basistechnologien (TCP/IP, http , XML) und sind offen für alle Anwender.

Service orientierte Software-Architektur (SOA)

(5)

Bislang existierten Middleware-Lösungen, oder auch an Sprachen angebundene verteilte Softwarelösungen.

Es wurden nun Standards entwickelt, deren Architektur nicht mehr von verwendeter Middleware abhängt.

Das Bild unten zeigt ein Anwendungsbeispiel mit Hauptkomponenten

Komponenten in einer SOA

Quelle:

S.Kühn, Skript zur Lehrveranstaltung Informations- und Kommunikations- systeme

(6)

Webservice-Anbieter für eine Anwendung

(hier Flug buchen, Hotel buchen, Auto buchen), die auf Rechnerknoten im Internet entsprechende SOAP-Server jeweils für einen konkreten Service zur Verfügung stellen. SOAP steht für Simple Object Access

Protocol.

Anwendung (im Sinne eines Programms, hier das

Reisebuchungssystem) als Nutzer eines WS

Als Nutzer eines WS treten hier immer Programme, also Software auf und keine Personen. Die Software kann natürlich eine Web- Anwendung sein, die auf der serverseitigen Skriptschicht einen entsprechenden SOAP-Client integriert hat. Der SOAP-Client schickt dann seine Anforderungen (Daten in XML-Dokument) an den SOAP-Server, der seine Antwortdaten dann ebenfalls als XML-

Komponenten in einer SOA

(7)

Beschreibung des Webservice über WSDL.

WSDL steht für Web Service Description Language. Die

WSDL-Datei ist eine XML-Datei, die den Webservice mit seiner Funktionsweise beschreibt. Sowohl der SOAP-Server als auch der SOAP-Client können sich über eine URL auf diese

Beschreibung beziehen. Diese Variante muss nicht unbedingt benutzt werden.

Es existieren für SOAP-Server und SOAP-Client die beiden Arbeitsregime:

- non-WSDL-Mode und - WSDL-Mode.

Im non-WSDL-Mode wird weder eine WSDL-Datei noch eine WS-Registratur (UDDI) genutzt. In diesem Fall müssen alle notwendigen Angaben im Client und Server vorhanden sein.

Komponenten in einer SOA

(8)

Protokoll zur Web-Service- Interaktion:

 Pures HTTP mit Request und

Response mittel GET oder POST

 SOAP – Simple Object Access Protocol

 REST – Representational State Transfer

Komponenten in einer SOA

zählt eigentlich noch nicht zur Web-Service-Schicht. Man kann so aber schon Services für HTTP- Clients programmieren.

Ein Großteil der älteren SOA -Anwendungen benutzen SOAP.

Alternative zu SOAP.

Einfacher und kürzer, favorisiert zustandslose

(9)

Transport-Protokolle

Protokolle zur Web-Service-Interaktion

XML über HTTP SOAP REST

HTTP

HTTPS SSL

TCP

IP

(10)

AJAX-Client ruft auf …

req.send( “xml=“+xmlstring );

AJAX-Client wertet Ergebnis des Request aus …

XML über HTTP

XML über HTTP:

Der HTTP-Post-Request kann XML-Daten im Body transportieren.

Beispiel:

AJAX-Server-Webseite

(PHP und SimpleXML) ruft auf …

$dom = new DOMDocument;

$dom->loadXML($_POST[xml]);

// danach wird $dom ausgewertet // und ein neues Objekt $resultxml // aufgebaut

$resultxml->saveXML();

(11)

SOAP ist ein standardisiertes Protokoll, das über ein festgelegtes XML-Dateiformat (Envelope-Element) die Daten (Anforderungen an den Webservice, Ergebnisdaten vom Server) zwischen Client und Webservice-Server austauscht. Als Transportprotokoll wird dabei im Internet http bzw. https benutzt.

Da der SOAP-Client in der serverseitigen Skriptschicht integriert ist, müssen die jeweiligen SOAP-Implementierungen der benutzten Skriptsprachen, wie PHP, Perl usw. beachtet werden.

SOAP (1)

(12)

SOAP-WSDL (1)

Verfügbare Web-Services werden in der Web Service Description Language (WSDL) beschrieben, die auf XML aufbaut.

Ein WSDL-Dokument definiert:

 die Nachrichten, die ausgetauscht werden

 wie sie ausgetauscht werden

 wo der Service zu erreichen ist

 mit welchem Protokoll die Nachrichten ausgetauscht werden

Bestandteile einer WSDL-Definition sind:

 Datentypdefinitionen für den Datenaustausch (<types>)

 Nachrichtendefinitionen (<message>)

 Porttypes zur Beschreibung der abstrakten Kommunikationsart (one-way, request-response, solicit response, notification)

 Bindings zur konkreten Definition des Austauschprotokolls(<bindings>)

(13)

P.Sobe/R.Großmann 13

SOAP-WSDL (2)

Der prinzipielle Aufbau eines WSDL-Dokuments definitions

service port

binding

<

portType message types

Adresse unter der die Operation erreichbar ist Realisierung der Operation (Protokoll)

Abstrakte Operation Abstrakte Nachricht

Datentyp

Internettechnologien

(14)

Beispiel:

Ein Thermometer-Service, der für verschiedene angfragte Positionen Temperaturwerte für innen und außen (inside/outside) zurückgibt.

Client / Service – Interaktion:

Beispiel-Anwendung

Temperatursensor

„Nordseite“

Temperatursensor

„Suedseite“

Temperatursensor „Eingang“

(15)

SOAP-WSDL (3)

WSDL:

<definitions name="TemperatureService"

targetNamespace="http://myhome.net/temperatureservice.wsdl" ...>

<types>

<schema targetNamespace="http://myhome.net/temperatureservice.xsd xmlns="http://www.w3.org/2001/XMLSchema">

<element name="TemperatureRequest">

<complexType>

<all> <element name="position" type="string"/> </all>

</complexType>

</element>

<element name="TemperatureResponse">

<complexType> <all>

<element name="inside" type="float"/>

<element name="outside" type="float"/>

</all> </complexType>

</element>

</schema>

</types>

(16)

SOAP-WSDL (4)

WSDL Fortsetzung:

</message>

</message>

</operation>

</portType>

(17)

SOAP-WSDL (5)

WSDL Fortsetzung:

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<soap:operation soapAction="http://myhome.net/GetTemperature"/>

</binding>

<documentation> A thermometer at position returns inside and outside value</documentation>

<soap:address location="http://myhome.net/temperaturservice"\>

</port>

</service>

<\definitions>

(18)

SOAP-WSDL (6)

Nachrichtenaustauschmuster (MEP, message exchange patterns), die folgenden 4 verschiedenen MEPs sind in WSDL 1.1 definiert Einweg (one way):

<wsdl:operation name=“…“>

<wsdl:input message=“…“/>

</wsdl:operation>

Anfrage-Antwort (request response):

<wsdl:output message=“…“/>

</wsdl:operation>

Benachrichtigung (notification):

</wsdl:operation>

Benachrichtigung-Antwort (notification-response):

</wsdl:operation>

(19)

Peter Sobe 19

SOAP-WSDL (7)

Ein Beispiel für eine nicht erlaubte Interaktion:

→ Buchungsanfrage an eine Hotelvermittlung

← Bestätigung der Anfrage

← Rückgabe von Hotelnamen (Benachrichtigung)

Keine komplexen Interaktionsmuster

Internettechnologien

(20)

SOAP-Nachrichten (1)

SOAP Nachrichten bestehen aus

 einem Gesamtumschlag (Container) kodiert durch das Tag <Envelope>

 den Kerninformationen im Tagbereich <Body>

 Zusatzinformationen in <Header>

 und möglicherweise Fehlerinformationen über das Tag <Fault>

SOAP-Grundgerüst:

<soap:Envelope

soap:message=“http://www.w3.org/2001/12/soap-envelope“

soap:encodingStyle=“http://www.w3.org/2001/12/soap-encoding“>

<soap:Header>

…

</soap:Header>

<soap:Body>

…

<soap:Fault> … </soap:Fault>

(21)

SOAP-Nachrichten (2)

Request via SOAP (mit SOAP-Envelope)

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>

<TemperatureRequest xmlns="http://myhome.net/temperatureservice.xsd">

<Authorization>1D9F7DD3</Authorization>

<position> “Eingang" </position>

</TemperatureRequest>

</soap:Body>

</soap:Envelope>

(22)

SOAP – Nachrichten (3)

Response via SOAP

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>

<TemperatureResponse

xmlns="http://myhome.net/temperatureservice.xsd">

<inside>23.1</inside>

<outside>17.6</outside>

<Signature>Iuv33HeZ73</Signature>

</TemperatureResponse>

(23)

REST - Representational state transfer

 Bei REST werden die Daten ohne eine zusätzliches Transportformat (vgl. SOAP) via HTTP transportiert

 REST ist das favorisierte Transportprotokoll für s.g. RESTful Services

 “RESTful web services” sind zustandslos, d.h. Services speichern nicht den Zustand des Clients

 der Client kann aber nach jeder Interaktion in eine neuen Zustand versetzt

 Ressourcen können den Zustand ändern

 Protokoll arbeitet stets nach gleichem Interaktionsmuster:

Request, Response, Ende

 Jeder Request muss alle notwendigen Informationen beinhalten

 Eine Authentifizierung wird bei jedem Request immer wieder neu benötigt.

REST (1)

(24)

REST -Fortsetzung

 RESTful ist ein „architectural constraint“, es muss nicht zwingend eingehalten werden

 RESTful bezieht sich auf Ressourcen - diese Ressourcen werden durch s.g. idempotente Operationen manipuliert

 Ressourcen-orientierte Operationen:

GET selektiere eine Ressource, Lesen und Rückgabe von Daten POST Ändern einer Ressource

PUT Zufügen einer neuen Ressource DELETE Löschen einer Ressource

REST (2)

(25)

Request via REST

GET http://myhome.net/temperatureservice?position=Eingang HTTP/1.1 Host: ...

Date: ...

Authorization: 1D9F7DD3 Response via REST/XML

<?xml version=1.0 encoding="UTF-8"?>

<temperatureresponse xmlns="http://myhome.net/temperatureservice.xsd">

<inside> 23.1 </inside>

<outside> 17.6</outside>

</temperatureresponse>

REST (3)

(26)

REST (4)

Idempotente Operationen … solche Operationen, die unabhängig wie oft sie mit den gleichen Daten wiederholt werden, immer zu den gleichen Ergebnissen führen.

REST-Operationen:

GET … holt eine Ressource,

muss ohne Seiteneffekte funktionieren, kann im Cache gehalten werden.

POST … erzeugt eine neue Ressource, potentiell unsicher

PUT … verändert eine existierende Ressource,

wird auch zum Erzeugen einer Ressource verwendet, mehrfacher Aufruf hat gleiches Ergebnis

wie ein einmaliger Aufruf (idempotent) DELETE … löscht eine Ressource,

(27)

REST (5)

Beispiel für einen ressourcenorientierten Thermometer-Service:

GET /temperaturservice/

Host: myhome.net/

… liefert Werte aller Temperatursensoren

<temperatureresponse>

<position>

<id>Eingang</id>

</position>

<position>

<id>Nordseite</id>

</position>

…

(28)

REST (6)

Ressourcen-orientierter Thermometer-Service (Fortsetzung):

GET /temperaturservice/Eingang Host: myhome.net/

… liefert Wert der Ressource „Eingang“

<position>

<id>Eingang</id>

</position>

(29)

REST (7)

Ressourcenorientierter Thermometer-Service (Fortsetzung):

DELETE /temperaturservice/Eingang Host: myhome.net/

… löscht Ressource „Eingang“

GET /temperaturservice/Eingang Host: myhome.net/

<position>

<id>Eingang</id>

<error> ressource does not exist </error>

</position>

(30)

REST (8)

Ressourcen-orientierter Thermometer-Service (Fortsetzung):

POST /temperaturservice/

Host: myhome.net/

<position>

<id/>

<desc>Dach, Sued</desc>

</position>

… erzeugt eine neue Ressource „Dach-Suedseite“

Antwort:

<position>

<id>Dach-Suedseite</id>

<desc>Dach, Sued</desc>

</position>

…

(31)

SOAP-PHP ist ein Modul, das innerhalb von PHP-Webseiten verschiedene SOAP-Server und SOAP-Clients ermöglicht. Das Zusammenstellen der SOAP-Envelope-Nachrichten ist dabei automatisiert und wird in den Methoden der SOAP-PHP-Klassen erledigt.

Diese Implementierung stützt sich auf folgende Klassen:

- SoapClient - SoapServer - SoapFault - SoapHeader - SoapParam - SoapVar

Eine SOAP-PHP-Klassenbeschreibung findet man unter www.php.net/manual/de/book.soap.php

P. Sobe/ R. Großmann Internettechnologien 31

SOAP-PHP (1)

(32)

www.php.net/manual/de/book.soap.php

SOAP-PHP (2)

(33)

Ein SOAP-Beispiel im non-WSDL-Mode

 ein Minimalbeispiel, das schrittweise weiter ausgebaut werden kann.

 eine Demonstration der beiden wichtigsten Klassen SoapServer und SoapClient mit ihren wichtigsten Methoden

Funktionen des Servers:

1. auf die Client-Anforderung "Start" soll der Server die Antwort

"Der WS arbeitet!" senden

2. auf die Client-Anforderung "Ende" soll der Server die Antwort

"Der WS beendet den Dienst!" senden

Für den SOAP-Server muss eine Instanz der Klasse SoapServer erzeugt werden:

SoapServer( mixed $wsdl [, array $options ] )

Der Konstruktor erlaubt das Erzeugen eines SoapServer-Objekts in WSDL- oder nicht

33 Internettechnologien

SOAP-PHP (3)

P. Sobe/ R. Grossmann

(34)

SoapServer( mixed $wsdl [, array $options ] )

Der Konstruktor gibt ein Handle (Zeiger) des Objektes zurück.

Parameter:

wsdl: Wenn der WSDL-Modus verwendet werden soll, muss der Parameter auf eine WSDL-Datei verweisen. Ansonsten wird NULL gesetzt und die uri in Options angegeben.

options: Im non-WSDL-Mode muss die uri verwendet werden.

“uri“ ist die Bezeichung für ein Element des assoziativen Arrays, dessen Wert auf den Namensraum verweist.

Das PHP-Skript unseres Beispiels muss deshalb die Anweisung enthalten:

SOAP-PHP (4)

(35)

Außerdem muss eine Funktion definiert werden, die die Daten für eine Antwort des Servers bereitstellt. Unter Benutzung eines assoziativen arrays für die Antworttexte könnte das wie folgt aussehen:

$Anwort = array("Start" => "the webservice is working",

"End" => "the webservice is stopped");

Die Funktion für die Antworttexte sei "Kontakt":

function Kontakt($befehl){global $Antwort; return $Antwort[$befehl];};

Über den Parameter $befehl wird die Anforderung des Clients übergeben.

Der SOAP-Server muss mit Hilfe der Methode addFunction() die gewünschte Funktion registrieren und durch Aufruf der Methode handle() die Bearbeitung einer Anforderung auslösen, also:

$server-> addFunction("Kontakt");

$server-> handle();

SOAP-PHP (5)

(36)

Gesamter Quelltext des SOAP-Servers (server1-1.php):

<?php

//globales assoziatives Array mit den Antworten

$Antwort = array( "Start" => "the webservice is working",

"End" => "the webservice is stopped");

function Kontakt($befehl) { global $Antwort;

return $Antwort[$befehl];

}

/*SOAP Server Konstruktor im non-WSDL-Mode, 1.Param. NULL, die uri des Nutzernamespaces muss angegeben werden */

$server = new SoapServer(NULL,array('uri' => "http://localhost/SOAP/"));

$server->addFunction("Kontakt");

SOAP-PHP (6)

(37)

Entwicklung des SOAP-Clients

Für den Client muss eine Instanz der Klasse SoapClient erzeugt werden:

SoapClient ( mixed $wsdl [, array $options ] )

Der Konstruktor erlaubt das Erzeugen eines SoapClient-Objekts in

WSDL- oder nicht-WSDL-Modus. Der Konstruktor gibt ein Handle (Zeiger) des Objektes zurück.

Parameter:

wsdl: Im WSDL-Modus muss die URI auf eine WSDL-Datei verweisen.

Sonst muss er auf NULL gesetzt werden, und mindestens die Optionen location und uri verwendet werden.

options: Im non-WSDL-Mode müssen folgende beiden Optionen

verwendet werden. Die Option location enthält den URL des angesprochenen Webservices. Die Option uri enthält den Zielnamensraum des SOAP-Services.

SOAP-PHP (7)

(38)

SoapClient ( mixed $wsdl [, array $options ] ) Beachte:

Sollen die SoapClient-Methoden __getLastRequest(),

__getLastResonse(),

__getLastRequestHeaders() oder __getLastResonseHeaders()

zur Ausgabe der http-Header bzw.

der XML-Dokumente (Envelope) für die SOAP-Datenübertragung ermittelt werden, so muss unbedingt die Option trace mit dem Wert 1 angegeben werden!

SOAP-PHP (8)

(39)

Das PHP-Skript unseres Beispiels muss deshalb die Anweisung

$client = new SoapClient(NULL,

array("location" => "http://localhost/SOAP/server1-1.php"

"uri" => "urn:D1"));

enthalten. Sever1-1.php ist der Dateiname unseres SOAP-Servers. D1 ist die von uns festgelegte Bezeichnung für den Namensraum.

Mit der Methode __soapCall() kann jetzt eine Funktion des SOAP-Servers aufgerufen werden. Dabei sind unbedingt der Name der Funktion und die für die Funktion notwendigen Argumente anzugeben.

Möglicherweise können auch noch Optionen, wie uri oder soapaction angegeben werden.

SOAP-PHP (9)

(40)

Ein einzelner Rückkehrwert wird entsprechend seinem Typ

zurückgegeben. Werden mehrere Werte durch die Funktion erzeugt, wird ein assoziatives Array zurückgegeben. Die Werte können dann über print oder echo zur Clientseite ausgegeben werden.

public mixed __soapCall ( string $function_name , array $arguments [, array $options [, mixed $input_headers [, array &$output_headers ]]] ) Das PHP-Skript unseres Beispiels (client1-1s.php) muss deshalb die Anweisung

print ($client-> __SoapCall("Kontakt", array("befehl" => "Start")));

enthalten. "Kontakt" ist der Funktionsname unseres SOAP-Servers.

SOAP-PHP (10)

(41)

Quelltext des SOAP-Clients (client1-1s.php):

<?php

$client = new SoapClient(NULL,

array( "location" => "http://localhost/SOAP/server1-1.php",

"uri" => "urn:D1"));

print($client->__soapCall( "Kontakt", array("befehl" => "Start" ) ). "\n");

?>

Internettechnologien 41

SOAP-PHP (11)

Erster Parameter NULL bewirkt non-WSDL-Mode.

Im zweiten Parameter wird ein assoziatives Array

angegeben: die URL des Servers und Namespace D1

Erster Parameter: Name der SOAP-Operation Zweiter Parameter: Name der Parameter und deren Werte in einem assoziativen Array

Die Methode __soapCall() gibt den Antwortwert „the webservice is working" als Rückkehrwert an die print-Funktion von PHP weiter.

(42)

Aufruf des SOAP-Clients zur Nutzung des Web Service

Es kann jetzt ein Browser gestartet werden, der die Datei unseres SOAP- Clients (client1-1s.php - mit der Anforderung "Start" an der Server) über http aufruft.

Der SOAP-Client stellt eine Anforderung "Start" an der WS (SOAP-Server server1-1.php). Der Webservice antwortet mit „the web service is working".

Bei der Anforderung "End" würde der Webservice mit „the web service is

SOAP-PHP (12)

(43)

SOAP-PHP:

Zugriff auf übertragene XML-Dokumente (1)

Das SOAP-Protokoll kodiert die eigentliche Nutzdaten, sowohl der

Anforderung als auch der Antwort, als wohldefinierte XML-Dokumente.

Die Klasse SoapClient stellt vier Methoden bereit, die den Zugriff auf übertragene XML-Dokumente sowie die http-Header ermöglichen.

Methode Beschreibung

__getLastRequest XML-Dokument der Anforderung __getLastResponse XML-Dokument der Antwort

__getLastRequestHeaders http – Header der Anforderung __getLastResponseHeaders http – Header der Antwort

Bei Aufruf dieser Methoden muss der SOAP-Client als Objekt mit der Option trace = 1 erzeugt werden.

(44)

$client = new SoapClient(NULL,

array( "location" => "http://localhost/SOAP/server1-1.php",

"uri" => "urn:D1", "style" => SOAP_RPC,

"use" => SOAP_ENCODED, "trace" => 1 ));

print($client->__soapCall("Kontakt", array("befehl" => "Start"),

array( "uri" => "urn:D1", "soapaction" => "urn:D1#Kontakt")). "\n");

print "<pre>\n";

print "Anforderung:\n".htmlspecialchars($client->__getLastRequest())."\n";

print "Antwort:\n".htmlspecialchars( $client->__getLastResponse() )."\n";

print "</pre>";

print "<pre>\n";

print "Anforderung-Header:\n".

htmlspecialchars( $client->__getLastRequestHeaders() ) ."\n";

print "Antwort-Header:\n".

htmlspecialchars( $client->__getLastResponseHeaders() )."\n";

SOAP-PHP:

Zugriff auf übertragene XML-Dokumente (2)

(45)

XML-Anforderung als Ausgabe (nachträglich formatiert):

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:ns1="urn:D1" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<ns1:Kontakt>

<param0 xsi:type="xsd:string">Start</param0>

</ns1:Kontakt>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

XML-Antwort, Anforderungs- und Antwort-Header als Demonstration …

SOAP-PHP:

Zugriff auf übertragene XML-Dokumente

(46)

Man kann im SOAP-Client das SoapFault-Element auswerten. Das Auslösen der Anforderung mit der __soapCall-Methode muss dann in einer try {…}

catch(…){…} – Anweisung erfolgen. In unserem Beispiel haben wir deshalb die folgende Skriptpassage aufgenommen:

try { echo "\n<pre>";

print($client->__soapCall("Kontakt", array("befehl" => "Start")).

"\n</pre>\n");

} catch (SoapFault $exception) {

echo "\n</pre>";echo"<h3>Fehler</h3>"; echo "\n<pre>\n";

echo $exception; echo "\n\n</pre>";

}

Tritt jetzt ein Fehler auf, so wird der Inhalt eines Fehlerelementes als Zeichenkette auf die Variable $exception übernommen und ausgegeben. Der Client nutzt, wie

SOAP-PHP: SoapFault-Object

(47)

SoapHeader – Eine Klasse für Objekte, die die Header der SOAP-XML- Nachrichten überscheiben können.

Die Methode der Klasse Soap-Client dazu ist

bool SoapClient::__setSoapHeaders ([ mixed $soapheaders ] ) SoapParam – Objekte, die Parameter für SoapClient::__Call()

aufnehmen können, z.B. $param = new SoapParam(“Start“,$befehl);

SoapVar – eine Klasse, die zur Übergabe einer Variable oder eines Objekts dient

SOAP-PHP: weitere Objekte

(48)

REST nutzt direkt die HTTP-Operationen

Daher ist es (vgl. SOAP) einfacher, einen REST-basierten Webservice direkt mit PHP zu implementieren.

Einige PHP-Frameworks, oder s.g. Micro-Frameworks existieren:

Slim, TONIC, Zend, Phalcon…

Beispiel Slim … path_to_ws/index.php:

<?php

require 'Slim/Slim.php';

\Slim\Slim::registerAutoloader();

$app->get('/hello/:name',

function ($name) { echo "Hello, $name"; });

$app->run();

?>

REST-basierte Web-Services mit PHP (1)

GET path_to_ws/hello/FRITZ HTTP /1.1

…

Hello FRITZ

(49)

Fortsetzung des Beispiels Slim … path_to_ws/index.php:

<?php

require 'Slim/Slim.php';

\Slim\Slim::registerAutoloader();

$app->get('/hello/:name',

function ($name) { echo "Hello, $name"; });

$app->post('/eintragen/:name',

function ($name) { // auslesen $app->request->getBody();

// Eintrag in Datei oder Datenbank anlegen echo „eingetragen: $name";

});

$app->get ('/anzeigen/:name',

function ($name) { // auffinden $name in Datei oder Datenbank // Inhalt $daten erzeugen

echo „anzeigen: $name, $daten";

});

$app->run();

?>

49

REST-basierte Web-Services mit PHP (2)

Peter Sobe Internettechnologien

(50)

Ein PHP-Client kann Web-Services wie folgt aufrufen:

Möglichkeit 1:

Per AJAX, d.h. per XMLHttpRequest var req = new XMLHttpRequest();

req.open("GET", "rest_server-1.php/anzeigen/ISOLDE", true);

req.onreadystatechange = function () { if (req.readyState == 4) {

if (req.status == 200) {

d1.innerHTML = " Request erfolgreich";

d2.innerHTML = req.responseText;

// hier auch Zugriff auf req.responseXML oder // json_decode(req.responseText)

} }

Aufruf REST-basierter Web-Services

(51)

Ein PHP-Client kann Web-Services wie folgt aufrufen:

Möglichkeit 2:

PHP-Funktion file_get_contents() mit URL am Beispiel der Mercator- Koordinatentransformation:

// $xpos und $ypos aus $gbr_ziel und $gln_ziel berechnen // Koordinatentransformation durch Webservice

$uri=sprintf('http://localhost/REST/koordtransform?gln=%f&gbr=%f',$gln_ziel,$gbr_ziel);

$xypos=json_decode( file_get_contents($uri) );

$xposziel=$xypos[0];

$yposziel=$xypos[1];

51

Aufruf REST-basierter Web-Services

(52)

Web Services sind ein Paradigma für kooperative Anwendungen im Client/Server-Stil

 Die offene Web-Standards und Web-Protokolle zur Kommunikation benutzen

 Die Service-Beschreibung und die Nachrichten sind in XML kodiert

 Zur Erzeugung und Verarbeitung der Nachrichten können XML- Verarbeitungs-Tools benutzt werden, z.B. innerhalb PHP

 Typisch ist die Nutzung vorgefertigter Plattformen zur Interaktion via SOAP-Web-Services, z.B. PHP-SOAP. Alle XML-Nachrichten werden hinter einem Interface versteckt. Die Nutzung erfolgt als RPC.

Zusammenfassung - Web Services (1)

(53)

Fortsetzung:

 Plattformen für REST-Web-Services sind eher auf Behandlung der einzelnen Operationen ausgelegt. Eine Operation kann sich auf eine oder alle Ressourcen beziehen.

Web-Services sind eine Technologie für eine neue Generation komplexer und verteilter Softwaresysteme, den s.g. serviceorientierten Architekturen Web-Services sind ein Teil der Cloud-Computing-Technologie

53