Easier XML-RPC for PHP 5

  • Posted by Mike Naberezny in PHP

    A few weeks ago, I rewrote the Zend XML-RPC client as part of a customer project at Maintainable. After fixing a fair number of bugs and writing a test suite, I made some enhancements and usability improvements. You can learn more about the new XML-RPC client from its documentation. Here it is in a nutshell:

    Calling Remote Methods

    The new XML-RPC client has always functioned similarly to many existing PHP implementations, providing a call() method:

    $c = new Zend_XmlRpc_Client('http://framework.zend.com/xmlrpc');
echo $c->call('test.sayHello');

    The call() instance method accepts an optional parameter with an array of parameters to marshal to the remote method. These may be native PHP types or PHP objects representing XML-RPC types. The latter is useful for the XML-RPC datatypes that do not map directly to PHP equivalents, such as base64.

    Server Proxy Objects

    The above usage works fine for many purposes but could read easier and gets tedious after many method calls. One of the few advantages of serializing method calls with a protocol like XML-RPC or SOAP is that with a little extra work in the client libraries, the remote service can be exposed in a way that’s very close to a native PHP object. This is where the server proxy comes in.

    In the above example of test.sayHello(), the remote sayHello() method is in the XML-RPC pseudo-namespace test. We can use the new XML-RPC client’s getProxy() method to get a proxy to this remote namespace and then use it similarly to a normal PHP object.

    $c = new Zend_XmlRpc_Client('http://framework.zend.com/xmlrpc');
 
$test = $c->getProxy('test');
echo $test->sayHello();

    Namespaces may be nested to any depth so the XML-RPC method foo.bar.baz() becomes $foo->bar->baz().

    Faults

    Faults resulting from the remote method call are automatically thrown as PHP exceptions. XML-RPC fault responses are thrown as Zend_XmlRpc_FaultException and transport errors are thrown as Zend_XmlRpc_HttpException. If this is not desirable for some reason, a doRequest() method provides a way to work with request and response objects directly.

    Update: This post was featured on PHPDeveloper.org.

This entry was posted on Monday, February 19th, 2007 at 8:05 pm and is filed under PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 comments

  • comment by Gregory Beaver 19 Feb 07

    This is close to how http://pear.php.net/XML_RPC2 works and has worked for well over a year, FYI

  • comment by Markus 20 Feb 07

    You say “rewrote” .. will you enhancements make it into the ZF?

    I’ve implemented a custom RPC protocol for fun in my spare time (years ago) and the first thing I did was getting rid of such call() methods and directly propagated the methods into objects. Unfortunately this was PHP4 so it was a mess using eval(), anyway.

  • comment by Mike Naberezny 20 Feb 07

    Hi Markus,

    I committed it a few weeks ago and it has been available since version 0.7.

    Mike

  • comment by Mike Naberezny 20 Feb 07

    Hi Greg,

    You are right, both projects have been around for about the same amount of time with comparable functionality. They both made their first releases around the same time, with XML_RPC2 in November 2005 and Zend XML-RPC appearing with the first release of the framework a few months later in the following March.

    I was a PEAR XML_RPC user and contributed some bug fixes to that a while back. I have also been aware of XML_RPC2 since its beginning although I have not used it in production. It was only declared stable last month, although it had not changed much in very long time before then.

    The Zend version is a bit simpler, has excellent PHPUnit test coverage, a more dynamic server proxy object, and avoids the static functions and cURL extension requirement. Unlike XML_RPC2, ZF is not yet declared stable. PEAR XML_RPC2 client in turn has functional tests in PHPT, offers similar capabilities, and adds Cache_Light integration. Both are fine choices depending on the needs and preferences of the developer.

    Mike

  • comment by Gaetano Giunta 22 Feb 07

    FYI, the php-xmrlpc also has similar capabilities, and has had since version 2.0rc1 (dec. ’05).

    The main difference is that the interface is function based, rather than object based.

    On the downside, being php 4 compat, it cannot throw exceptions when remote invocation fails.

    On the upside, it offers the option to probe the remote server for importing its “xmlrpc namespace” either at runtime (slow, as it adds extra xmlrpc calls to system.listmethods and system.describeMethod) or at design time, in which case it works as a php code generator (works if the server api is not subject to frequent changes)

  • comment by Cimpu Emanuel 6 Aug 07

    Hi !
    Has anyone an example on how to implement system.describeMethods introspection function on a XML-RPC server ? Do I have to build up arrays with function infos (like: author, version, etc etc) in order to call system.describeMethods ?
    On EPI implementation of XML-RPC, which I see that it has this introspection method built in, there is a lack of usage examples and I can’t really call it.

Post a comment


Thanks for commenting. Please remember to be nice to others and keep your comment relevant to the discussion. I reserve the right to remove comments that don't meet these simple guidelines.