PHP 4 Grundlagen und Profiwissen

Transkript

1 PHP 4 Grundlagen und Profiwissen von Jörg Krause überarbeitet PHP 4 Grundlagen und Profiwissen Krause schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Hanser München 2003 Verlag C.H. Beck im Internet: ISBN Inhaltsverzeichnis: PHP 4 Grundlagen und Profiwissen Krause

2 CARL HANSER VERLAG Jörg Krause PHP 4 Grundlagen und Profiwissen Webserverprogrammierung unter Windows und Linux

3 750 9 Kommunikation und Datenaustausch Dann erfolgt die Verarbeitung in einem Zug, anschließend wird der Parser wieder freigegeben. Die Fehlerausgabe sollte bei der automatischen Erzeugung von WDDX-Paketen nicht reagieren: if (!xml_parse($xml_parser, $packet)) { die(sprintf("xml-fehler: %s auf Zeile %d", xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser))); } xml_parser_free($xml_parser); 9.7 XML-Webservices XML-Webservices sind seit einiger Zeit ein heißes Thema in der IT- Welt und nichts destotrotz für viele Entwickler noch blanke Theorie. Dieser Abschnitt stellt zwei Anwendungfälle vor. Zum einen wird die Konsumierung eines öffentlichen Webservices gezeigt. Als Gegenstück dazu soll ein Projekt zeigen, wie man selbst einen Webservice implementiert und praktisch nutzt. Grundlagen Die Protokolle Einführung in Webservices Ein Grundverständnis für Webservices erhält man, wenn die Kommunikationswege bekannt sind. So findet die Kommunikation zwischen dem Anbieter des Webservice und dem Client (Consumer genannt) auf Serverebene statt. Es geht also nicht unbedingt darum, Benutzern einen Webservice zur Verfügung zu stellen, sondern bestenfalls darum, diesen die Leistungen mit einem Webinterface zugänglich zu machen. Aber auch das dürfte eher ein Ausnahmefall sein. Wenn Server miteinander reden können ohne menschliches zutun ist das ein wenig Science Fiction und für die Zukunft ein interessantes Geschäft. Denn die Kommunikation wird durch die zugrunde liegenden Technologien XML, SOAP, HTTP, WSDL usw. so billig und einfach, dass sie in der Breite zur Anwendung gelangen können. Das ist der Unterschied zu früher, wo es Serverkommunikation auch schon gab, diese sich aber auf wenige Anwendungen beschränkte. Denkbar sind vor allem Partnernetzwerke, von der Bannerschaltung über einen gemeinsamen Ad-Server bis hin zu den beliebten Webringen. Egal, ob Sie Artikel verkaufen und Subunternehmer suchen oder als Sammelshop auf mehrere Lieferanten zugreifen möchten, Webservices sind die ideale Kommunikationslösung. Es gibt aber weitergehende Leistungen. So könnten Websites einen Aktualisierungsdienst anbieten, der auf Anfrage (eines anderen Servers) alle geänderten, gelöschten oder hinzugefügten Links zu einem vereinbarten Thema liefert. Eine intelligente Linkliste reorganisiert sich dann selbstständig. Auf eben

4 9.7 XML-Webservices 751 diesem Wege lassen sich auch Nachrichten des Tages oder Sportergebnisse liefern. Der Vorteil all dieser Vorgänge basiert auf den genannten Technologien, die eine nähere Betrachtung Wert sind. Die hier beschriebenen Grundlagen zu den verwendeten Protokolle sind stark vereinfacht und stellen nur den Teil dar, der zum Verständnis der vorgestellten Programme notwendig ist. Tatsächlich sind alle Spezifikationen außerordentlich umfangreich. Es ist zu allen Themen eine Reihe von Spezialliteratur verfügbar. Die Protokolle Mit XML, SOAP, HTTP und WSDL stehen gleich mehrere Protokolle, Normen und Verfahren bereit, Entwicklern und Anwendern den Weg zu Webservices zu erleichtern. Die Vielfalt klingt kompliziert, intern betrachtet sind es jedoch nur noch zwei Protokolle, die wichtig sind: XML und HTTP. Für Webprogrammierer dürften beides alte Bekannte sein. SOAP und WSDL sind XML und das als Transportprotokoll HTTP zum Einsatz kommt, erleichtert die Programmierung ungemein. Ausführung Funktionsaufruf Transport PHP-Programm SOAP HTTP, SMTP Auch wenn hier nicht weiter darauf eingegangen wird, sollten Sie wissen, dass SOAP nicht zwingend mit HTTP verknüpft ist. Als Transportprotokolle können auch HTTPS (verschlüsseltes HTTP) und SMTP ( ) auftreten. Prinzipiell schreibt der Standard überhaupt kein Protokoll vor. Es muss nur in der Lage sein, XML-Daten zu übertragen. Mehr Informationen zu XML-Protokollen, kurz als XP bezeichnet, finden Sie unter folgender Adresse: Als Geheimnis der Webservices wird an erster Stelle SOAP (Simple Object Access Protocol) angeführt. SOAP definiert ein XML-Protokoll, dass im Körper einer HTTP-Nachricht versendet wird. Das ist der eigentlich Knüller, denn HTTP geht durch vermutlich jede Firewall der Welt und ist damit der ideale Weg, wirklich jeden Server in das Netzwerk der Webservice-Teilnehmer einzubinden. Ganz nebenbei ist XML der zweite Knüller. Denn die in allen Plattformen und Sprachen verfügbaren Parser können dieses Format leicht lesen und die Daten so einfach zur Verfügung stellen, dass nur geringer Programmierauf- Abbildung 9.18: Ablauf des entfernten Funktionsaufrufs aus Sicht der Protokollschichten SOAP (Simple Object Access Protocol) V S I A B C D E

5 752 9 Kommunikation und Datenaustausch Abbildung 9.19: Prinzipieller Aufbau einer SOAP- Nachricht wand anfällt. Der Prozess der Datenannahme und auch der Datenerzeugung lässt sich gut automatisieren. Das muss auch so sein, den ohne eine automatische Weiterverarbeitung ist eine automatischen Kommunikation sinnlos. Aus Sicht der PHP-Entwickler ist die Dominanz von SOAP nicht uneingeschränkt zu befürworten. Denn es gibt Alternativen: RPC (Remote Procedure Protocol) beispielsweise. Dieses Protokoll ist einfacher als SOAP und damit auch schneller. Dafür ist die Verwendbarkeit in einigen Fällen eingeschränkt. SOAP ist durch das W3C standardisiert worden. Die Spezifikation der aktuellen Version 1.1 finden Sie unter folgender Adresse: Die folgende Abbildung zeigt den prinzipiellen Aufbau einer SOAP- Nachricht. Die Anzahl der Blöcke mit den Daten der Anfrage oder der Antwort ist beliebig. Listing 9.44:»Gitter«eines SOAP-Envelope Da es sich bei SOAP um XML handelt, gibt es eine gut lesbare Darstellung des prinzipiellen Aufbaus der Nachrichten: <SOAP-ENV:Envelope xmlns:soap-env= xmlns:xsd= xmlns:xsi=" <SOAP-ENV:Header> : : : </SOAP-ENV:Header> <SOAP-ENV:Body> : : : </SOAP-ENV:Body> </SOAP-ENV:Envelope>

6 9.7 XML-Webservices 753 Hier wird bereits deutlich, dass als zusätzlicher Namensraum unter anderem»xsd«verwendet wird, die XML Schema Definition Language (XSD). Die dort definierten Datentypen bilden damit das Rückgrat der typstrengen Übermittlung von Daten zwischen den Kommunikationspartnern. Das Wurzelelement bildet der so genannte SOAP- Envelope, auf deutsch der Umschlag. Der URI des Namensraumes lautet immer wie folgt: Der Präfix ist frei wählbar, wird jedoch standardmäßig auf SOAP-ENV. Die beiden Namensräume für die Schema-Definition und Schema- Instanz sollten hinzugefügt werden und müssen vorhanden sein, wenn die entsprechenden Datentypen verwendet werden. Die Schema- Instanz definiert komplexe Typen und Null als nil in dieser Definition. Der Kopf (SOAP-Header) der Nachricht ist optional, der Körper (SOAP-Body) muss immer vorhanden sein. DTD-Deklarationen als Alternative zu XSD sind grundsätzlich nicht zulässig. Der SOAP-Body enthält das eigentliche Dokument, das für sich genommen wohlgeformt nach den XML-Regeln sein muss. Sonderzeichen oder binäre Daten sind durch <[CDATA[...]>-Abschnitte zu schützen. Das ist schon die einzige Regel, SOAP selbst beachtet den Inhalt der Nachricht nicht weiter. Es ist Sache der beteiligten Prozessoren, die Daten auszuwerten, mithin also Ihrem eigenen Programm. Abschließend ein Blick auf eine vollständige SOAP-Nachricht: <SOAP-ENV:Envelope xmlns:soap- ENV=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:dogooglesearch xmlns:ns1="urn:googlesearch" SOAP-ENV:encodingStyle = " <key xsi:type="xsd:string"> </key> <q xsi:type="xsd:string">shrdlu winograd maclisp teletype</q> <start xsi:type="xsd:int">0</start> <maxresults xsi:type="xsd:int">10</maxresults> <filter xsi:type="xsd:boolean">true</filter> <restrict xsi:type="xsd:string"></restrict> <safesearch xsi:type="xsd:boolean">false</safesearch> <lr xsi:type="xsd:string"></lr> <ie xsi:type="xsd:string">latin1</ie> <oe xsi:type="xsd:string">latin1</oe> </ns1:dogooglesearch> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Datentypen SOAP-Nachricht Listing 9.45: Eine SOAP- Nachricht, hier eine Anfrage an den Suchdienst Google (aus dem Google- API-Paket) V S I A B C D E

7 754 9 Kommunikation und Datenaustausch Antworten Listing 9.46: Eine SOAP-Antwort, die <item>-elemente würden sich in der Praxis wiederholen Antworten werden ebenso in SOAP formuliert. Das folgende Beispiel zeigt die Antwort auf die zuvor gezeigte Anfrage, ebenfalls dem Google-API-Paket entnommen: <SOAP-ENV:Envelope xmlns:soap- ENV=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:dogooglesearchresponse xmlns:ns1="urn:googlesearch" SOAP-ENV:encodingStyle =" <return xsi:type="ns1:googlesearchresult"> <documentfiltering xsi:type="xsd:boolean"> false</documentfiltering> <estimatedtotalresultscount xsi:type="xsd:int"> 3</estimatedTotalResultsCount> <directorycategories xmlns:ns2=" xsi:type="ns2:array" ns2:arraytype="ns1:directorycategory[0]"> </directorycategories> <searchtime xsi:type="xsd:double"> </searchTime> <resultelements xmlns:ns3=" xsi:type="ns3:array" ns3:arraytype="ns1:resultelement[3]"> <item xsi:type="ns1:resultelement"> <cachedsize xsi:type="xsd:string"> 12k</cachedSize> <hostname xsi:type="xsd:string"></hostname> <snippet xsi:type="xsd:string">... Hier steht der Antworttext dieser Abfrage... </snippet> <directorycategory xsi:type="ns1:directorycategory"> <specialencoding xsi:type="xsd:string"> </specialencoding> <fullviewablename xsi:type="xsd:string"> </fullviewablename> </directorycategory> <relatedinformationpresent xsi:type="xsd:boolean"> true </relatedinformationpresent> <directorytitle xsi:type="xsd:string"></directorytitle> <summary xsi:type="xsd:string"></summary> <URL xsi:type="xsd:string">...

8 9.7 XML-Webservices 755 </URL> <title xsi:type="xsd:string">...titel...</title> </item> <item>...</item> </resultelements> <endindex xsi:type="xsd:int">3</endindex> <searchtips xsi:type="xsd:string"></searchtips> <searchcomments xsi:type="xsd:string"> </searchcomments> <startindex xsi:type="xsd:int">1</startindex> <estimateisexact xsi:type="xsd:boolean"> true</estimateisexact> <searchquery xsi:type="xsd:string"> shrdlu winograd maclisp teletype</searchquery> </return> </ns1:dogooglesearchresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ]]></listingcode> </listing> Nun erscheint der Umgang mit SOAP nicht besonders einfach. Trotz leistungsfähiger XML-Funktionen in PHP wäre einiger Programmieraufwand nötig, die Nachrichten in jeder Situation exakt zu formulieren und die Antwort entsprechend auszuwerten. Vor allem dann, wenn der Anbieter die Struktur seines Dienstes ändert, wird es problematisch, denn dann muss das eigene Programm geändert oder schlimmstenfalls neu geschrieben werden. Da sich Anbieter und Konsument eines Webservices nicht kennen müssen und vermutlich oft geografisch weit auseinander sitzen, sind weitere Schritte hin zur praktischen Nutzbarkeit notwendig. Das Problem wird noch verschärft, wenn Anbieter und Konsument mit verschiedenen Systemen arbeiten, beispielsweise auf der Serverseite mit PHP und auf der Clientseite mit ASP oder auch umgekehrt. Damit die fremde Umgebung die richtigen Funktionen aufrufen kann, wird eine Dienstbeschreibungssprache eingesetzt WSDL. Natürlich ist auch das XML. WSDL (Web Services Description Language) Als nächstes soll die Beschreibungssprache WSDL (Web Services Description Language) vorgestellt werden. Mit WSDL wird die Struktur eines Webservice beschrieben, also die verfügbaren Funktionen, deren Parameter und die Art und Weise der Anforderungsgestaltung. Damit ist auch der Dienst selbst automatisierbar, denn der anfragende Server kann seine Anfrage entsprechend dem aktuellen Entwicklungsstand des Dienstes modifizieren. Insofern sind die Kommunikationswege über eine gewisse Zeit hinweg änderungsresistent oder wenigstens wartungsfreundlich. Das Geheimnis der Webservices ist also weit SOAP-Praxis V S I A B C D E

9 756 9 Kommunikation und Datenaustausch Abbildung 9.20: Prinzipieller Aufbau einer WSDL-Datei mehr als nur SOAP; und es ist auch etwas komplizierter. Die gesamte Kommunikation kann nämlich auch die Suche nach einem Dienst selbst einschließen. WSDL ist ebenso wie SOAP beim W3C, derzeit als Version 1.1, standardisiert: WSDL basiert ebenso wie SOAP auf XML. Die prinzipielle Struktur und die Abhängigkeiten der Elemente zeigt in vereinfachter Form die nächste Abbildung. Der Anbieter eines Dienstes definiert als zuerst ein Element <service> dass die Basisdienste deklariert. Erreichbar sind diese jeweils über Ports (<porttype>), die Bindungen (<binding>) beschreiben die geforderte Kodierung des Datenstromes. Auf die Portdefinition folgt die Beschreibung einer oder mehrere Operationen, die jeweils eine Einund Ausgabenachricht (<Message>) definieren. Die Nachrichten können mehrere Parameter aufnehmen, die auf nativen XSD-Datentypen ba-

10 9.7 XML-Webservices 757 sieren oder denen komplexe Definitionen zugrundeliegen. Ist das der Fall, kommt noch der Abschnitt <types> zur Anwendung, wo XSD- Typdefinitionen untergebracht sind. <definitions name="urn:googlesearch" targetnamespace="urn:googlesearch" xmlns:typens="urn:googlesearch" xmlns:xsd=" xmlns:soap=" xmlns:soapenc =" xmlns:wsdl=" xmlns=" <types> </types> <message name="messagename"> <part name="parameter" <part name="parameter" </message> <porttype name="portname"> <operation name="operation"> <input message="typens:typdefinition"/> <output message="typens:typdefinition"/> </operation> </porttype> <binding name="bindingname" type="typens:portname"> <soap:binding style="rpc" transport=" <operation name="operationname"> <soap:operation soapaction="urn:actionname"/> <input> <soap:body use="encoded" namespace="urn:actionname" encodingstyle =" </input> <output> <soap:body use="encoded" namespace="urn:actionname" encodingstyle =" </output> </operation> </binding> <service name="servicename"> <port name="portname" binding="typens:bindingname"> <soap:address location=" </port> Listing 9.47: WSDL-Datei des Google-Webservice V S I A B C D E

11 758 9 Kommunikation und Datenaustausch </service> </definitions> Diese Struktur lässt sich gut in einer Klasse abbilden, die dann im Programm verwendet wird. Eine solche Klasse wird als Proxy-Klasse bezeichnet. Leider ist PHP an dieser Stelle noch nicht ganz soweit und die automatisierte Erstellung von Proxy-Klassen ist eher ein Wunschtraum. Für den Anbieter eines Webservice ist WSDL dagegen zwingend erforderlich, denn viele Clients basieren auf der Analyse dieser Datei. Im Praxisteil wird gezeigt, wie WSDL mit PHP erzeugt wird. Universal Description, Discovery and Integration Noch zu wenig für die Praxis UDDI Universal Description, Discovery and Integration Als letztes bleibt noch der Weg zu klären, auf dem Sie an die WSDL- Dateien gelangen. Es gibt hier drei Möglichkeiten: 1. Sie haben die Adresse der WSDL-Datei von Ihrem Geschäftspartner erhalten. 2. Sie besuchen ein öffentliches Verzeichnis von Webdiensten. 3. Sie verwenden UDDI. Das Zentrum der UDDI-Welt ist Mehr als 80 führende Technologie- und Business- Unternehmungen haben sich zusammengerauft und das Projekt UDDI in Gang gesetzt. UDDI-Server (Universal Description, Discovery and Integration) werden verwendet, um die URL vermutlich passender Dienste zu finden. Anhand einer von diesen gesendeten Discovery-Datei kann der eigene Server herausfinden, welcher Dienst am besten passt und wo die WSDL-Datei zu finden ist. Die Discovery-Datei informiert nicht wie WSDL über technische Parameter, sondern beispielsweise über Zugriffsbedingungen, unter denen der Dienst genutzt werden darf. Vorerst gibt es aber zuwenig Dienste, um derartigen Verzeichnissen etwas abgewinnen zu können. Der gesamte Ablauf, insbesondere die hinter UDDI stehenden Protokolle, sind sehr komplex. Auch wenn sie auf XML aufbauen, zeigt allein das Anforderungsprofil, dass die automatisierte Erkennung und Nutzung von Diensten nicht trivial werden kann Webservices und PHP PHP ist leider keine besonders einfache Programmierumgebung, wenn man Webservices anbieten will. Derzeit sind zwei halbwegs brauchbare Lösungen verfügbar, die beide selbst in PHP geschrieben sind:

12 9.7 XML-Webservices 759 PEAR::SOAP Dieses Paket stammt aus dem PEAR-Verzeichnis und stellt damit quasi die offizielle PHP-Erweiterung für SOAP-Dienste dar. Eingesetzt werden kann dieses Paket ab PHP 4.1. Anfang 2003 war die Version verfügbar. NuSOAP NuSOAP wurde von Dietrich Ayala entwickelt und gilt als derzeit bestes SOAP-Paket. Die neueste Version kann sogar WSDL»onthe-fly«erzeugen, eine unabdingbare Voraussetzung für die Kommunikation mit anderen Servern, die nicht auf PHP setzen. Es werden in beiden Fällen keine speziellen Erweiterungen benötigt, sodass die Anwendung auch im Webspace möglich ist. Das ist nicht weiter verwunderlich, denn die PEAR-Implementierung ist eine für PEAR angepasste Version eines früheren Entwicklungsstadiums von NuSOAP (SOAPx4). Insofern sind die Kernfunktionen beider Pakete identisch. PEAR::SOAP PEAR::SOAP können Sie von folgender Adresse laden: Die SOAP-Erweiterung bietet sowohl Client- als auch Serverfunktionen und einen Generator für die Erstellung einer Proxyklasse aus der WSDL-Datei. NuSOAP Der Verzicht auf PEAR macht NuSOAP in der Anwendung etwas einfacher. Vor allem in den Fällen, wo nur Basisfunktionen benötigt werden und weitere PEAR-Pakete nicht zum Einsatz kommen, dürfte NuSOAP eher zu empfehlen sein. Beschaffen können Sie sich das Paket über folgende Website: Webservices-Praxis: Einen Dienst konsumieren Das Verwenden eines Webservices, allgemein als»konsumieren«bezeichnet, setzt die Kenntnis eines URL voraus, unter der der Dienst erreicht werden kann, bzw. unter der weitere Informationen darüber zu finden sind. Über den Umgang mit öffentlichen Diensten Neben den beiden bekanntesten Angeboten Google und Amazon gibt es inzwischen viele kleinere Server, die Webservices anbieten. Ein V S I A B C D E

13 760 9 Kommunikation und Datenaustausch guter Ausgangspunkt sind frei zugängliche Listen, die vor allem die ersten Schritte erleichtern. Im Gegensatz zu UDDI ist der Anspruch an die Anbieter, sich im Verzeichnis einzutragen, sehr viel geringer. Auch deshalb sind diese Listen beliebt und für Experimente gut geeignet. Hier eine Auswahl: SANTRA Technology's ion service XMethods' directory of Web services Sal Services Web services brokerage Die Wahl für dieses Buch fiel auf Google, die als eine der größeren Anbieter vermutlich längere Zeit stabilen Betrieb garantieren können. Die Methodik ist aber exemplarisch auf alle anderen Dienste übertragbar. Bevor Sie mit Google arbeiten, müssen Sie sich einen Lizenzschlüssel beschaffen. Derzeit kann Google bis Mal pro Tag abgefragt werden. Pro Anfrage sind maximal zehn Antworten möglich. Die Nutzung ist kostenlos, Informationen über ein kommerzielles Modell, dass eine intensivere oder kommerzielle Nutzung erlaubt, waren Anfang 2003 noch nicht verfügbar. Ein einfaches Programm am Beispiel Google WSDL analysieren Im Fall von Google lohnt zuerst ein Blick in die WSDL-Datei. Im API- Paket, das Sie auch auf der Website finden, liegt die Datei als Google- Search.wsdl. Es ist sinnvoll, immer die aktuelle Version zu verwenden. Ein Blick in GoogleSearch.wsdl zeigt eine Zusammenfassung der Dienste im Zweig <porttype>, wo derzeit drei Elemente <operation> existieren, die für die Nachrichten die Ein- und Ausgabefunktionen definieren. Hier ein kleiner Ausschnitt: <porttype name="googlesearchport"> <operation name="dogetcachedpage"> <input message="typens:dogetcachedpage"/> <output message="typens:dogetcachedpageresponse"/> </operation> <! > </porttype> Die korrespondierenden Elemente <input> bzw. <output> enthalten wiederum die Anweisung, wie die Nachricht in Abfrage- bzw. Antwortrichtung aufzubauen ist. Für die im Beispielprogramm verwendete Funktion dogooglesearch sieht dies folgendermaßen aus: <message name="dogooglesearch"> <part name="key"

14 9.7 XML-Webservices 761 <part name="q" <part name="start" <part name="maxresults" <part name="filter" <part name="restrict" <part name="safesearch" <part name="lr" <part name="ie" <part name="oe" </message> type="xsd:int"/> type="xsd:int"/> type="xsd:boolean"/> type="xsd:boolean"/> Definiert werden die Namen der Parameter und ihr Datentyp. Der Parameter key kommt in allen Abfragen vor und enthält den von Google übermittelten Lizenzschlüssel. Die Definition der Rückgabe erfolgt ähnlich, denn der Transport der Daten vom Server zum Client läuft ebenfalls via SOAP: <message name="dogooglesearchresponse"> <part name="return" type="typens:googlesearchresult"/> </message> Der Attributwert typens:googlesearchresult deutet auf einen eigenen Datentyp hin, da die Rückgabewerte komplex sein können. Im Abschnitt <types> der WSDL-Datei sind diese Typen definiert. Clients können daraus die Schnittstelle ableiten. Dank der in WSDL verwendeten XSD-Datentypen ist die Schnittstelle typstreng. Es ist jedoch einiges Know-How nötig, um damit tatsächlich universelle SOAP- Clients zu erstellen. Die Google-Funktionen auf einen Blick Bevor Sie richtig loslegen können, den Webservice zu nutzen, müssen Sie die bereitgestellten Funktionen auch kennen. Zuerst ein Blick auf die derzeit angebotenen Dienste: Dienstname dogooglesearch dospellingsuggestion Einsatzzweck Standardsuche, benötigt die in Tabelle 9.7 gezeigten Parameter Korrekturvorschlag für Schreibfehler anfordern. Parameter: key und code. dogetcachedpage Suche im Google-Cache. Parameter: key und url. Die Parameter der Standardsuchfunktion sind etwas umfangreicher: Parameter Bedeutung Datentyp key Lizenzschlüssel xsd:string, Zeichenkette q Die Abfrage xsd:string, Zeichenkette Tabelle 9.6: Derzeit verfügbare Funktionen des Webservices Google Tabelle 9.7: Parameter der Funktion dogooglesearch V S I A B C D E

15 762 9 Kommunikation und Datenaustausch Parameter Bedeutung Datentyp Tabelle 9.8: Die Suchoptionen einer Anfrage start maxresults Start der Suche in der Ergebnisliste (beispielsweise gibt 30 die Ergebnisse 30 bis 35 aus, wenn maxresults 5 ist) Anzahl der Ergebnisse pro Seite (derzeit maximal zehn) xsd:int, Ganzzahl xsd:int, Ganzzahl filter Filtert den Text xsd:boolean, Ja/Nein restrict Generelle Einschränkung xsd:boolean, Ja/Nein safesearch Unterdrückt jugendgefährdende Inhalte xsd:boolean, Ja/Nein lr Sprache (lr=language xsd:string, Zeichenkette Restriction), beispielsweise "lang_de" Im Falle von GoogleSearch beschreibt die WSDL-Datei lapidar einen Parameter»q«mit dem Datentyp»xsd:string«. Echte Freude kommt aber nur auf, wenn man»q«(steht für»query«) mit den passenden Suchzeichen füllen kann: Suchform +wort -wort "Eine Phrase" Wort1 OR Wort2 site: Beschreibung Wort muss vorkommen Wort darf nicht vorkommen Exakte Übereinstimmung Wort1 oder Wort2 müssen vorkommen. Die UND-Verknüpfung wird standardmäßig verwendet Die angegebene URL wird durchsucht Einen Webservice konsumieren Nach der Beschaffung der nötigen Kenntnisse über den Dienst können Sie mit der Realisierung der Skripte beginnen. Dieser Abschnitt zeigt nun, wie Sie mit PHP auf Google zugreifen können. Dazu werden die bereits gegebenen Informationen genutzt. Vorbereitungen Neben dem SOAP-Paket muss auch das PEAR-Basissystem vorhanden sein. Das folgende Skript enthält am Anfang die Definition einer Konstanten, die den Pfad zu PEAR festlegt: define('pearpath', 'D:\Inetpub\cgi\pear;.');