Question

I’m writing a PHP application which uses a number of SOAP web services to gather data.

I’m getting significant overheads in instantiating all those objects: in some cases a single line of code $object = new SoapClient($wsdl); can take over three seconds. It obviously only takes a few of those to make a web page feel really slow.

To speed things up a bit, I figured I’d serialise the objects and store them in the session (or somewhere similar), so I wrote the following function:

function soap_client($name,$wsdl) {
    if (!isset($_SESSION['soapobjects'][$name])) {
        $client = new SoapClient($wsdl, array('trace' => 1));
            $_SESSION['soapobjects'][$name]=serialize($client);
        } else {
            $client = unserialize($_SESSION['soapobjects'][$name]);
        }
    return $client;
}

That certainly seems to be the way PHP recommends to do it.

…and then calling it like this…

$client = soap_client('servicename',$wsdl);
$client->MethodName($parameters);

However, it doesn’t seem to work.

The first time you run it, it works (ie the object is created and a serialised copy is made, and the method call works fine). However the second time you run it, it fails.

The object appears to serialise and de-serialise correctly, but when you try to execute a SOAP call on the de-serialised object, it throws the following error:

Fatal error: Uncaught SoapFault exception: [Client] Error finding "uri" property

Clearly the de-serialised object is not the same as the original object, which is at odds with how object serialisation is supposed to work.

Can anyone explain why I’m getting this error? Can you suggest a way to get it working, or an alternative strategy that I could be persuing?

Thank you.

ps – I’ve tried to work around the problem, but no joy.

I’ve tried specifying the URI in the options parameter (as specified in the PHP SOAP Client manual), but it didn’t make any difference. But it shouldn’t be necessary anyway, as I’m using a WSDL.

I’ve also tried simply copying the object to $_SESSION, without using serialize() and deserialize(), but that has exactly the same effect.

Answer 1

The built-in SOAP extension is an undebuggable binary blob of horrors. It’s very likely that it was not built with serialization in mind. For example, it could contain an internal filehandle that won’t survive the serialize/unserialize process. I urge you to use some other SOAP client, such as:

• Zend_Soap, part of the Zend Framework. You don’t need to use the Framework in any other area of your code, and can probably remove most of the other components. However, it seems to use the existing SOAP extension under the covers, so it’s probably not a good candidate for serialization.
• PEAR’s SOAP is frequently referenced, though it’s a bit old.
• NuSOAP has recently been brought back from the dead, though all of the online documentation appears to have disappeared into zip files.

If none of these are suitable, consider caching the WSDL file locally, as I somehow expect that’s where the delay is.