Zend_XmlRpc_Server

正如我自己和Davey之前指出的那样，我已经在Zend_XmlRpc_Server上工作了几个月。在过去的几周里，我重构了它以将类/函数反射推送到Zend_Server_Reflection中，并且在这样做的过程中，我注意到还有更多的领域可以重构到额外的辅助类中。目前，它现在有用于请求、响应和故障的类，所有实际的XML争论都在这些类中完成，使服务器基本上与XML无关。

这种重构的一个好处是，它让我能够更快、更轻松地编写测试。我不再需要担心向服务器添加辅助方法以确定它是否正确解析请求以获取方法调用和参数；我可以简单地测试公共API以实际处理请求。而且我不再需要创建XML来测试服务器；我可以简单地填充一个请求对象以传递请求，并检查响应对象以查看我是否收到了适当的值。没有XML争论！

因此，举个例子，高级案例的用法和花里胡哨的东西：

<?php
require_once 'Zend/XmlRpc/Server.php';
require_once 'Zend/XmlRpc/Server/Fault.php';
require_once 'Zend/XmlRpc/Server/Cache.php';
require_once 'Services/Request.php';
require_once 'Services/Response.php';
require_once 'Services/Exception.php';

require_once 'Services/Comb.php';
require_once 'Services/Brush.php';
require_once 'Services/Pick.php';

// Specify a cache file
$cacheFile = dirname(__FILE__) . '/xmlrpc.cache';

// Allow Services_Exceptions to report as fault responses
Zend_XmlRpc_Server_Fault::attachFaultException('Services_Exception');

$server = new Zend_XmlRpc_Server();

// Attempt to retrieve server definition from cache
if (!Zend_XmlRpc_Server_Cache::get($cacheFile, $server)) {
    $server->setClass('Services_Comb', 'comb');   // methods called as comb.*
    $server->setClass('Services_Brush', 'brush'); // methods called as brush.*
    $server->setClass('Services_Pick', 'pick');   // methods called as pick.*

    // Save cache
    Zend_XmlRpc_Server_Cache::save($cacheFile, $server));
}

// Create a request object
$request = new Services_Request();

// Utilize a custom response
$server->setResponseClass('Services_Response');

echo $server->handle($request);

事后想想，当我写完Request、Response和Fault类时，让我印象深刻的是，由于服务器不需要对XML做任何事情，所以也不能说这些类确实需要。这意味着从理论上讲，它可以用作其他类型的RPC网络服务的支架——例如，使用压缩或ssl编码事务、YAML、JSON等。这将是另一天的主题。

如果您有兴趣测试XML-RPC服务器，此阶段大部分已完成（此阶段的@todo项仅包括验证请求中收到的参数是否与其中一个签名匹配并且该反射将签名参数和返回类型转换为XML-RPC类型），您可以从孵化器树中的ZendFramework颠覆存储库中获取它。