Twittern ist doch sehr trendig. Seit 2007 gibt es die Twitter API – hier soll ein kleines Script vorgestellt werden, mit welchem ihr munter von eurer Webseite loszwitschern könnt. Das alles läuft mit ein paar Zeilen PHP Code und einem Zugang zur Twitter API.

Die API von Twitter wurde 2007 veröffentlicht. Mittlerweile gibt es natürlich auch eine PHP Programmbibliothek, mit der Sie Twitter z.B. in Ihr Blog integrieren können. Auf Dr.Web.de wurde ein kleines WordPress Plugin vorgestellt, mit dem man automatisch Nachrichten an Twitter senden kann. Das ganze Skript können Sie hier herunterladen.

Es besteht aus einer Datei. Einem Script, um die Nachrichten an Twitter zu senden und einem Formular, über welches die Nachrichten eingegeben werden.

Der PHP Code für das Senden der Message ist wie folgt:

insertTwitterMsg.php
<?php
$twitter_username ='yourTwitterUserName';
$twitter_psw ='yourTwitterPassword';
require('twitterAPI.php');
if(isset($_POST['twitter_msg']))
{
$twitter_message=$_POST['twitter_msg'];
if(strlen($twitter_message)<1){
$error=1;
} else {
$twitter_status=postToTwitter($twitter_username, $twitter_psw, $twitter_message);
}
}
?>

Hier müssen Sie lediglich ihren Twitter-Benutzername sowie ihr Twitter Passwort anpassen. In der ersten Zeile wird die Twitter API eingefügt. Diese ist ebenfalls in der ZIP Datei enthalten. Daraufhin folgt eine Überprüfung ob die Message auch mindestens ein Zeichen enthält. Wenn nicht, spuckt das Skript eine Fehlermeldung us.

Ansonsten wird die Nachricht an Twitter über die Funktion postToTwitter() gesendet; diese steckt in der Twitter API. Das Formular, über welches die Messages eingegeben werden ist ebenfalls in der insertTwitterMsg.php implementiert.

<!-- Send message to Twitter -->
<?php
if(isset($_POST['twitter_msg']) && !isset($error)){?>
<div><?php echo $twitter_status ?></div>
<?php } else if(isset($error)){?>
<div>Error: please insert a message!</div>
<?php }?>
<p><strong>What are you doing?</strong></p>
<form action="insertTwitterMsg.php" method="post">
<input name="twitter_msg" type="text" id="twitter_msg" size="40" maxlength="140"/>
<input type="submit" name="button" id="button" value="post" />
</form>

Sofern in der Umgebungsvariable $_POST[''] die Message noch nicht definiert ist, oder ein Fehler entstanden ist – etwa weil die Nachricht weniger als ein Zeichen hatte, so wird die Fehlermeldung ausgegeben. Ansonsten wird der Twitter Status ausgegeben, welcher besagt, ob die Message erfolgreich übertragen wurde. Daruner wird das Formular ausgegeben. So einfach gehts!

Weiterführende Links:

1. Diese Seite weiterempfehlen…

Schon der Begriff "Webservices" enthält eine eigentliche Definition. Webservices sind Dienste, die über das Internet bereitgestellt werden. Trotz dieser scheinbar recht einfachen Definition, haben sich die "Großen", Microsoft, IBM, Hewlett Packard, Sun etc. noch nicht auf eine einheitliche Definition geeinigt. Unter http://www.jeckle.de/webServices/ finden Sie eine Auflistung der verschiedensten Definitionen von, was Webservices eigentlich sind.
Als kleinster gemeinsamer Nenner kann man sagen, dass über Webservices dem Client (das ist der Nutzer) Funktionen, Daten und Anwendungen bereitgestellt werden können.
Dabei ist der Client nicht mehr der vor seinem Computer sitzende Surfer – es sind eigenständige Anwendungen, welche Webservices für die eigene Programmfunktion nutzen.
Ein einfaches Beispiel dafür sind die Google Webservices. Dabei kann ein Programmierer über Webservices auf die mächtige Google Suchfunktionen zurückgreifen, und diese in die eigene Anwendung integrieren. So können z.B. siteinterne Suchmaschinen ohne viel Aufwand erstellt werden; dies soll im dritten Teil dieses Workshops beleuchtet werden.
Über Webservices kann man folglich ganze Anwendungen modellieren. Doch wie funktioniert die Kommunikation zwischen den verschiedenen Anwendungen? Die Daten müssen ja in irgendeiner Form von einem Programm zum anderen geschickt werden.
Das versenden der Daten wird über das http Protokoll bewerkstelligt. Die Anfragen und Antworten werden in Form von XML gesendet. Man hat sich auf diese beiden Standards geeinigt, da sie quasi überall "verstanden" werden. Sie sind plattform- und insbesondere programmiertechnisch unabhängig.
Die Anfragen an den Webservice werden folglich in XML verpackt und über http versendet. Die XML Nachricht wird vom Webservice interpretiert und wiederum in Form von XML beantwortet.
Da Webservices für die Integration von Programmfunktionen in anderen Anwendungen gedacht sind, musste man sich auch hier auf eine einheitliche Form der Datenübertragung zum Nutzen aller einigen. So entstand SOAP, das Simple Object Access Protocol, basierend auf XML. Dadurch wurde erreicht, dass alle Webservice Anfragen und Antworten eine einheitliche Form haben. Zwar gibt es auch Webservices, die nicht auf SOAP zurückgreifen, jedoch wird sich SOAP in Zukunft durchsetzen, da nur durch eine einheitliche Datenübertragung die Nutzung von Webservices eine allgemeine Bedeutung erlangen kann.
Ein Anfrage besteht, wie man im folgenden Diagramm sehen kann aus einem festen Grundgerüst.


Struktur einer SOAP Nachricht

Das Grundgerüst ähnelt sehr dem einer HTML Seite, bestehend aus einem Head- und einem Body-Bereich, in welchem die Antwort- bzw. Anfragedaten abgelegt sind.

In der folgenden Abbildung ist ein einfaches Schema für den Datenfluss bei der Nutzung von Webservices abgebildet. Dabei besitzt die Anwendung welche auf den Webservice zurückgreift ebenfalls einen XML Interpreter, über welchen die XML Daten in ein Format überführt werden, in welchem sie weiterverarbeitet werden können. Die SOAP Antwort muss folglich von der Anwendung verarbeitet werden. Auf diese Weise wird die Nutzung von Webservices nicht nur auf einzelne Programmiersprachen beschränkt. Man kann Webservices über jede Programmiersprache verwenden, die eine XML bzw. SOAP Schnittstelle besitzt.


Einfaches Datenflussdiagramm für die Nutzung von Webservices

Man kann dieses einfache Modell noch erweitern, indem man sich den Webservice auf welchen man zurückgreift selbst als eine Anwendung betrachtet welche auf verschiedene andere Webservices zurückgreift.

Man kann sich das an einem einfachen Beispiel veranschaulichen. Bei einer Buchbestellung möchten Sie den Status ihrer Bestellung verfolgen. So können sie bei dem Verkäufer den Status bis zum versenden betrachten. Bei dem Zusteller (z.B. der Post) können sie den weiteren Verlauf verfolgen.
Durch Webservices ist es nun möglich, dass der Verkäufer den Status der Bestellung auch über die eigenen Systemgrenzen verfolgen kann, indem er auf einen Webservice des Zustellers zurückgreift und dort den Status des Versandes ermitteln kann und diesen an den Käufer weitergeben kann.

Das ist nur ein einfaches Beispiel der Integration von Webservices in andere Anwendungen.

Nachdem die grundlegende Funktion von Webservices geklärt ist, müssen noch weitere Aspekte in Betracht gezogen werden, die sich insbesondere für den Programmierer ergeben, der von Webservices gebrauch machen möchte.
Den woher weiß der Programmierer auf welche Funktionen er bei der Nutzung von Webservices zurückgreifen kann, bzw. welche Parameter diese brauchen.
Hierzu wurde von IBM und Microsoft gemeinsam die Webservice Description Language, kurz WSDL, entwickelt. Sie basiert auf XML und ermöglicht die standarisierte Beschreibung von Webservices – sie wird auch vom W3C als möglicher Standard diskutiert.

Ein weiteres Problem, welches Auftritt ist, dass bei einer Vielzahl von Webservices unklar ist, wer überhaupt was anbietet. Die Webservices müssen irgendwo verzeichnet sein. Idealerweise sollte der Webservicenutzer nur noch eine Anfrage an das Webserviceverzeichnis machen müssen; dieses leitet ihn dann direkt weiter an den für die Anfrage passenden Webservice. Ein solches "Telefonbuch" für Webservices wurde durch UDDI (Universal Description, Discovery and Integration) geschaffen. In ihm sind die Webservice Anbieter und die von ihnen angebotenen Webservices verzeichnet. Bereits viele Anbieter haben UDDI implementiert.

Doch was für Chancen oder Zukunftsaussichten liegen in Webservices? Der Nutzen für Unternehmen ist eindeutig, da sie bei ihren Anwendungen einfach gesagt, nicht mehr alles selbst programmieren müssen. Die einzelnen Firmen werden sich durch ihre Webservices stärker als bisher vernetzen und so insbesondere in den Beziehungen zu den Kunden verbessern.

Doch was bedeutet das für den Internetnutzer?

Eine Vision ist, dass man über Webservices eine Personalisierung des ganzen Internets einführen kann. So hat Microsoft bereits über ihr .NET Passport einen ersten Schritt dahingehend getan. Über einen .NET Passport kann man auf die verschiedensten Angebote von Microsoft zugreifen ohne jedes Mal ein neuen Account anlegen zu müssen. Das heißt man müsste seine persönlichen Daten nur noch in einem virtuellen Pass hinterlegen, über welchen man dann auf die verschiedensten Internetdienste zurückgreifen kann.
Dies wird jedoch auch heftig diskutiert, da damit erhebliche Sicherheitsbedenken verbunden sind.

Webworker selbst können Webservices bisher nur in beschränkten Maße nutzen. Bei den in diesem Workshop betrachteten Webservices von Google und Amazon können Webworker auf die Produktpalette von Amazon bzw. auf die Suchfunktion von Google zurückgreifen und diese in die eigene Webseite integrieren. Es bleibt also noch zu erwarten in wie weit Webservices das Leben eines Webworkers beeinflussen wird – im Rahmen dieses Workshops soll der Nutzen der beiden betrachteten Webservices für den Webworker in den Vordergrund gestellt werden.

(tf)

No related posts.

Eigene Web Services mit PHP5 bereitstellen? Kein Problem! Bietet PHP5 doch das nötige Rüstzeug, um bequem und schnell den eigenen Web Service auf die Beine zu stellen. Doch was, wenn der Client nicht in PHP geschrieben sein soll? Soll Ihr Firefox Plugin auf Webservices zugreifen können oder Sie möchten Ihren Kunden ein ansprechendes Administrationsfrontend zu Ihrem CMS anbieten? Dieses Tutorial erklärt die Erstellung eines Soap Servers mit PHP5 und des dazugehörigen Clients in Javascript.

Was ist Soap?

Soap (Simple Object Access Protocol) ist ein einfaches XML basiertes Protokoll, mit der Anwendungen Informationen über HTTP austauschen können. Das interessante an Soap ist, dass Sprachübergreifend Objekte und deren sichtbare Eigenschaften über das WWW übertragen und individuell aufbereitet werden können (Stichwort WebServices). Ein berühmter Vertreter, der eine Soap Schnittstelle zur Verfügung stellt, ist Amazon. Mit Amazon’s Soap-Schnittstelle kann man z.B. auf der eigenen Homepage Amazon Angebote nach eigenem Gutdünken platzieren. Es gibt jedoch eine Vielzahl weiterer Verwendungsmöglichkeiten, nicht nur im Bereich der Content-Syndication, die dem blossen Inkludieren von Fremden Seiten oder RSS-Feeds haushoch überlegen sind.

PHP5 bietet nun eine eingebaute Extension, um beliebig Soap Server oder Clients zu erstellen. Es gibt noch weitere Soap Implementationen für PHP (z.B. über PEAR), jedoch sind diese meist in PHP verfasst und somit von der Performance her einer in C geschriebenen Extension unterlegen.

Was brauche ich denn so?

Zunächst empfiehlt sich das PHP5 "Rundum-Sorglos-Paket" XAMPP.

Mit XAMPP kann man sich unter Windows und Linux im Handumdrehen eine PHP5 Testumgebung schaffen und die hier bereitgestellten Code-Beispiele ausprobieren. Nach der Installation von XAMPP muss die Soap-Extension in der php.ini aktiviert werden. Falls Sie kein XAMPP verwenden und nicht wissen, welche php.ini gerade benutzt wird, dann erstellen Sie eine PHP Datei mit untenstehendem Inhalt, kopieren diese in Ihr Document Root und öffnen die Datei im Browser. Falls Sie XAMPP verwenden, können Sie im XAMPP Menu den Punkt "phpinfo()" auswählen. Dort steht in der Zeile "Configuration File (php.ini) Path" der Pfad zur php.ini, die Sie anpassen müssen.

In der php.ini suchen Sie dann nach der Zeile ";extension=php_soap.dll", entfernen das ";", speichern ab und starten den Apachen neu. Als nächstes benötigen wir noch Firefox, um unseren Client zu testen (alternativ funktioniert natürlich auch die Mozilla-Suite). Ein einfacher ASCII-Text Editor reicht für die Beispiele vollkommen aus.

Der Soap Server

Um einen Soap Server mit PHP5 zu erstellen, haben wir zwei Möglichkeiten. Einmal einen Soap Server mit WSDL Defintionsdatei und einmal einen Server ohne. Eine WSDL Datei (Web Services Description Language) ist eine von XML abgeleitete Beschreibungssprache, um Funktions- bzw. Methodenaufrufe und Datentypen zu definieren. Für den Soap Server ist eine WSDL Datei nicht zwingend notwendig, sollte aber bei steigender Komplexität der Webservices auf jeden Fall eingesetzt werden. Nötig wird eine WSDL Datei spätestens dann, wenn die Datenübertragung mit SSL verschlüsselt werden soll. Denn diese Angabe muss explizit in der WSDL Datei vorhanden sein. Ausserdem gibt es Tools, z.B. für Java, die aus WSDL Dateien Programmcode erzeugen. Dies ist für das Rapid-Prototyping eine äusserst nützliche Hilfe. Ein gutes Tool, um WSDL Dateien On-The-Fly zu erzeugen ist der SOA-Editor.

Wir werden in diesem Teil die Möglichkeit ohne WSDL Dateien behandeln.

Öffnen Sie eine leere Datei und speichern Sie diese als "soap_server.php" in Ihrem Document Root ab. Kopieren Sie nun folgenden Code in die Datei und speichern:

Öffnen Sie eine leere Datei und speichern Sie diese als "MySoapClass.php" im selben Ordner des Documents Roots ab, indem Sie die "soap_server.php" abgespeichert haben. Kopieren Sie nun folgenden Code in die Datei und speichern:

In der "soap_server.php" haben wir nun festgelegt, dass keine WSDL Datei verwendet wird und dass die Funktionen der Klasse MySoapClass dem Client zur Verfügung stehen sollen. Die Klasse MySoapClass in "MySoapClass.php" stellt den eigentlichen Service dar. Hier werden dem Client die Funktionen MySoapClass::getAttributesClass() und MySoapClass::putSomethingToServer($something) bereit gestellt. Erstere Funktion übergibt dem Client eine Instanz der Klasse MyAttributesClass. Alle öffentlichen Eigenschaften, werden dann vom Client weiterbehandelt. Die zweite Funktion zeigt, dass selbstverständlich auch Parameter an eine Soap Funktion übergeben werden können.

Der Soap Client

Um den Rahmen dieses Tutorials nicht zu sprengen, liegt Ihnen eine vorgefertigte und einfach zu verwendende Javascript Klasse zur Steuerung des Soap Clients vor. Diese Klasse habe ich im Rahmen meines CM Frameworks erstellt, um bequemer Anfragen an den Soap Server stellen zu können.

Öffnen Sie eine leere Datei und speichern Sie diese als "BlasterSoapClient.js" ab. Allerdings brauchen Sie dies nicht im Document Root zu tun. Sie erfahren später wieso. Kopieren Sie folgenden Code in die Datei und speichern:

/**
* The SoapClient Class
*/
function BlasterSoapClient() {
        this.transportURI = '';
        this.urn = 'urn:noxmethods';    
        this.enablePrivilege = 'UniversalBrowserRead';
}  

/*
*    Method BlasterSoapClient::asyncInvoke() does not halt script when receiving result!
*/
BlasterSoapClient.prototype.asyncInvoke = function (method,args,callback){
    try {
        netscape.security.PrivilegeManager.enablePrivilege(this.enablePrivilege);
    } catch (e) {
        alert(e);
        return false;
    }
    
    var soapCall = new SOAPCall();
    var prot = BlasterSoapClient.prototype;
    
    soapCall.transportURI = this.transportURI;
    
    var params = new Array(args.length);
    for(i=0;i<args.length;i++){
        params[i] = new SOAPParameter(args[i],'')
    }
    
    soapCall.encode(0, method, this.urn, 0, null, params.length, params);
    
    soapCall.asyncInvoke(
      function (response, soapcall, error)
       {
          var r = prot.handleSOAPResponse(response,soapcall,error);
          callback(r);
        }
    );
};

/*
*    Response handler for BlasterSoapClient::asyncInvoke()
*/
BlasterSoapClient.prototype.handleSOAPResponse = function (response,call,error)
{
    if (error != 0)
    {
        throw "Service failure";
    } else
    {
        var fault = response.fault;
        if (fault != null) {
            var code = fault.faultCode;
            var msg = fault.faultString;
            throw "SOAP Fault:\n\n" +
                "Code: "  + code +
                "\n\nMessage: " + msg
        } else
        {
            return response;
        }
    }
    
    throw "Failure";
};

/*
* When using this, all scripts will halt until result could be retrieved
*/
BlasterSoapClient.prototype.invoke = function (func, args)
{
      try {
          netscape.security.PrivilegeManager.enablePrivilege(this.enablePrivilege);
       } catch (e) {
           throw e;
    }
    
       var soap_call = new SOAPCall();
       soap_call.transportURI = this.transportURI;
       
       var p = new Array(args.length);
       for(i=0;i<args.length;i++){
           p[i] = new SOAPParameter(args[i],'');
       }
        
       soap_call.encode(0, func, this.urn, 0, null, p.length, p);
       
       var temp = soap_call.invoke();
       
       if (temp.fault) {
           throw 'Code: ' + temp.fault.faultCode + '\n String: ' + temp.fault.faultString;
       } else {
           var response = new Array();
           response = temp.getParameters(false, {});
           return response[0].value;
       }
}

/*
* User defineable method to handle result when asyncInvoke() is called. add it as third param there!
*/
BlasterSoapClient.prototype.showResults = function (results)
{
    if (!results)
    {
      return;
    }
    
    var params = results.getParameters(false,{});
      alert(params[0].value);
};

Öffnen Sie eine leere Datei und speichern Sie diese als "soap_client_getattrib.html" im selben Ordner ab, indem Sie die Datei "BlasterSoapClient.js" abgespeichert haben. Kopieren Sie folgenden Code in die Datei und speichern:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Ein Soap Client in Javascript</title>
<!-- Die Soap Klasse einbinden -->
<script type="text/javascript" src="BlasterSoapClient.js"></script>
</head>
<body>
<script>
// neue Instanz des Soap Clients erzeugen
var soapClient = new BlasterSoapClient();

// Webpfad zum SoapServer
soapClient.transportURI = 'http://localhost/soap_server.php';
   
try{
    // Parameter Array erzeugen. Da wir keine Parameter in der Funkion des Soap Servers erwarten, hat das Array die länge null.
    var p = new Array(0);
    
    // Aufruf (invoke) der Funktion MySoapClass::getAttributesClass() auf dem SoapServer
    var attributesClass = soapClient.invoke('getAttributesClass',p);
    
    // die Ausgabe sollte [object SOAPPropertyBag] lauten
    document.writeln(attributesClass+'<br /><br />');
    
    // ausgabe der eigenschaften des Objekts MyAttributesClass
    document.writeln('Empfangen:<br />');
    document.writeln(attributesClass.attrib1+'<br />');
    document.writeln(attributesClass.attrib2+'<br />');
    document.writeln(attributesClass.attrib3+'<br />');
    document.writeln(attributesClass.attrib4+'<br />');
    document.writeln(attributesClass.attrib5+'<br />');
    
    
} catch(e) {
    alert(e);
}
</script>
</body>
</html>

Öffnen Sie nun die Datei "soap_client_getattrib.html" mit dem Mozilla Firefox Browser über "Datei öffnen". Sie werden dann darum gebeten, Ihr Einverständnis für die Ausführung des Soap Aufrufs zu erteilen. Warten Sie ein paar Sekunden und klicken Sie dann auf "Allow". Nun müssten Sie folgendes als Ausgabe erhalten:

[object SOAPPropertyBag]    
Empfangen:  
Inhalt 1  
Inhalt 2  
Inhalt 3  
Inhalt 4  
Inhalt 5  

Wenn wir nun die Datei nicht über die "Datei öffnen" Funktion des Browsers, sondern über http://localhost/... aufgerufen hätten, dann wären die Sicherheitseinstellungen von Mozilla Firefox auf den Plan gerufen worden und der Client hätte keine Antwort vom Soap Server erhalten. Das ist auch vollkommen in Ordnung, denn ein Webserver soll dem Client keinen Soap Code unterjubeln können, der dann beliebig Daten nachlädt.

Der Aufruf "BlasterSoapClient.invoke('getAttributesClass',new Array(0));" bewirkt, dass der Client (sprich Mozilla Firefox) wartet, bis vom Server eine Rückmeldung kam. Daher ist die Verwendung von invoke auch nur dann zu empfehlen, wenn nicht viele Daten hin und her transportiert werden sollen (z.B. Login Prozeduren). Für grössere Datenmengen empfiehlt sich der Aufruf der Funktion "BlasterSoapClient.asyncInvoke(funktion,argumente,callbackfunktion)". Der asynchrone Aufruf bewirkt, dass das Skript normal weiterläuft. Zur Behandlung der empfangenen Daten wird jedoch eine Callback Funktion benötigt, die dem Funktionsaufruf mitgegeben wird. Da bei Javascript Funktionen bereits Objekte sind, können wir die Funktione direkt als Parameter an "BlasterSoapClient.asyncInvoke" übergeben.

Für das Beispiel des asynchronen übertragens von Daten mit Soap öffnen Sie eine leere Datei und speichern Sie diese als "soap_client_getattrib_async.html" ab (im gleichen Ordner wie "soap_client_getattrib.html"). Kopieren Sie folgenden Code in die Datei und speichern:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Ein Soap Client in Javascript</title>

<!-- Die Soap Klasse einbinden -->
<script type="text/javascript" src="BlasterSoapClient.js"></script>

</head>
<body>

<script>
// neue Instanz des Soap Clients erzeugen
var soapClient = new BlasterSoapClient();

// Webpfad zum SoapServer
soapClient.transportURI = 'http://localhost/soap_server.php';
   
try{
    // Parameter Array erzeugen. Da wir keine Parameter in der Funkion des Soap Servers erwarten, hat das Array die länge null.
    var p = new Array(0);
    
    // Aufruf (invoke) der Funktion MySoapClass::getAttributesClass() auf dem SoapServer (asynchron)
    soapClient.asyncInvoke('getAttributesClass',p,callbackHandler);
} catch(e) {
    alert(e);
}

// der Rückruf Handler für asyncInvoke
function callbackHandler (results)
{
    if (!results)
    {
      return;
    }
    
    var params = results.getParameters(false,{});
      var attributesClass = params[0].value;
      
    alert(attributesClass+'\n'
     + 'Empfangen:\n'
     + attributesClass.attrib1+'\n'
     + attributesClass.attrib2+'\n'
     + attributesClass.attrib3+'\n'
     + attributesClass.attrib4+'\n'
     + attributesClass.attrib5+'\n');
};
</script>
</body>
</html>

Wenn Sie nun das Beispiel im Browser öffnen, dann sehen Sie, dass es im Grunde nur eine Änderung gab. Statt das Ergebnis das Aufrufs der Soap Funktion direkt in die Variable "attributesClass" zu speichern, geschieht dies beim asynchronen Aufruf erst in der Callback Funktion. Man kann bei grösseren Datenmengen leicht einen Ladebalken einbauen, damit der Benutzer sieht, dass im Hintergrund etwas passiert. Im folgenden werden wir der einfachheit halber mit der synchronen Variante fortfahren.

Nun wollen wir auf unserem Soap Server die Funktion "MySoapClass::putSomethingToServer($something)" ausführen und einen Parameter mitübergeben. Öffnen Sie eine leere Datei und speichern Sie diese als "soap_client_putargs.html" im selben Ordner ab, indem Sie die Datei "BlasterSoapClient.js" abgespeichert haben. Kopieren Sie folgenden Code in die Datei und speichern:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Ein Soap Client in Javascript</title>
<!-- Die Soap Klasse einbinden -->
<script type="text/javascript" src="BlasterSoapClient.js"></script>
</head>
<body>
<script>
// neue Instanz des Soap Clients erzeugen
var soapClient = new BlasterSoapClient();

// Webpfad zum SoapServer
soapClient.transportURI = 'http://localhost/soap_server.php';
   
try{
    // Parameter Array erzeugen. Die Funktion des Soap Server, die wir weiter unten aufrufen erwartet genau einen Parameter.
    var p = ['Irgendein String'];
    
    // Aufruf (invoke) der Funktion MySoapClass::putSomethingToServer($something) auf dem SoapServer
    soapClient.invoke('putSomethingToServer',p);
    
} catch(e) {
    alert(e);
}
</script>
</body>
</html>

Der Parameter mit dem Inhalt "Irgendein String" wurde nun an "MySoapClass::putSomethingToServer($something)" übergeben und es wurde ein SoapFault Objekt an den Client zurückgeschickt mit dem Inhalt der Nachricht. SoapFaults sind wichtig, um Fehler, die auf dem Server passiert sind (z.B. Eingabefehler, Exceptions etc.) dem Client mitzuteilen. Das heisst, der Client braucht nicht auf die Antwort warten und man kann sich Tests sparen, in denen geprüft wird ob alle Values auch wirklich angekommen sind.

Ich hoffe, Ihnen hat meine kleine Einführung in PHP5/Javascript SOAP gefallen. Im zweiten Teil werden wir sehen, wie die über den Client empfangenen Daten mit XUL verwendet werden können und beschäftigen uns näher mit WSDL.

Weiterführende Links:

1. Wikipedia für die eigene Webseite – Teil 1
2. Wikipedia für die eigene Webseite – Teil 2
3. Komprimierte HTML Dateien mit PHP