When building SOAP web services with eZ publish, there's probably two ways to approach it;

SOAP has a number of different "styles" in which is can be used.

If you've used XML-RPC before, you're used to what SOAP calls "RPC/encoded" style - the web service only has a single URL "listener" which does everything (RPC) and the messages use a format which relates to native PHP variables e.g.

<methodResponse>

  <params>

     <param>

        <value><string>South Dakota</string></value>

        </param>

     </params>

  </methodResponse>

eZ SOAP has the eZSOAPServer to make it possible to construct RPC/Encoded style SOAP servers e.g.;

<?php

// Switch off notices

error_reporting(E_ALL ^ E_NOTICE);

 

// Set the include path for eZ publish

ini_set('include_path','/home/user/ezpublish-3.0-2/');

 

// Require the necessary

require_once( "lib/ezsoap/classes/ezsoapserver.php" );

 

// Some function

function playBack($requestParam) {

   if($request == '') {

       return "This is an error - no requestParam";

   } else {

       return "You said $requestParam";

   }

}

 

// Create the SOAP server

$server = new eZSOAPServer();

 

// Register the function

$server->registerFunction('playBack');

 

// Send response

$server->processRequest();

?>

Right now I'm not sure if you can register object methods using the registerFunction() method and notice the error above - you can't return a new eZSOAPFault object (at least as far as I know). You may want to consider PEAR::SOAP for the time being (currently eZ publish 3.0.2)

The other way to go is "Document/Literal" style SOAP (AKA: "REST" based web services), which is probably a better way to publish content with eZ publish for remote clients.

Basically document literal style SOAP uses the existing URL scheme of eZ publish to determine what data is made available to the client in the same way as for a web browser and XHMTL.

For example if the XHTML version is;

http://ez.no/developer/ez_publish_3/documentation/ez_publish_3/howtos/

Then the XML version might be;

http:// xml.ez.no/developer/ez_publish_3/documentation/ez_publish_3/howtos/

or

http://ez.no/index.php/xml/developer/ez_publish_3/documentation/ez_publish_3/howtos/ (non virtual hosts)

The content itself is simply XML - no specification of data types etc.

In practical terms what this would mean (I guess) is making a new eZ publish site (or perhaps section of a site) then modifying the templates to display XML not XHTML for the content objects, leaving out the navigation.

It's probably a good idea to have a WSDL document to describe the site and this might also be generated by eZ publish using a template based on the site map.

The one issue might be handling authentication - the easiest mechanism with web services in general is HTTP authentication but that will probably need some significant modifications to eZ publish. Clients should be able to use the session based authentication though, by setting a cookie HTTP header - have a look at the code of Simon Wilson's HTTP client for examples: http://scripts.incutio.com/httpclient/

For some information on PEAR::SOAP and a quick discussion of RPC/Encoded vs. Document/Literal try http://www.phppatterns.com/index.php/article/articleview/41/1/2/.