repo_zf1/documentation/manual/ja/module_specs/Zend_XmlRpc_Server.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<!-- EN-Revision: 24249 -->
<sect1 id="zend.xmlrpc.server">
    <title>Zend_XmlRpc_Server(日本語)</title>

    <sect2 id="zend.xmlrpc.server.introduction">
        <title>導入</title>

        <para>
            <classname>Zend_XmlRpc_Server</classname> は、完全な機能を有した <acronym>XML-RPC</acronym> サーバです。
            <ulink url="http://www.xmlrpc.com/spec">
            www.xmlrpc.com で提示されている仕様</ulink> に準拠しています。
            さらに <command>system.multicall()</command> メソッドを実装しており、
            リクエストをまとめる (boxcarring of requests) ことができます。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.usage">
        <title>基本的な使用法</title>

        <para>
            もっとも基本的な使用例は次のとおりです。
        </para>

        <programlisting language="php"><![CDATA[
$server = new Zend_XmlRpc_Server();
$server->setClass('My_Service_Class');
echo $server->handle();
]]></programlisting>
    </sect2>

    <sect2 id="zend.xmlrpc.server.structure">
        <title>サーバの構造</title>

        <para>
            <classname>Zend_XmlRpc_Server</classname> はさまざまなコンポーネントで構成されています。
            サーバ自身からリクエスト、レスポンス、fault
            オブジェクトなど広範囲に広がっています。
        </para>

        <para>
            <classname>Zend_XmlRpc_Server</classname> を起動するには、
            まずサーバにひとつ以上のクラスか関数をアタッチする必要があります。
            アタッチするには <methodname>setClass()</methodname> メソッドおよび
            <methodname>addFunction()</methodname> メソッドを使用します。
        </para>

        <para>
            起動させたら、次に <classname>Zend_XmlRpc_Request</classname> オブジェクトを
            <methodname>Zend_XmlRpc_Server::handle()</methodname> に渡します。
            もし渡さなかった場合は、<classname>Zend_XmlRpc_Request_Http</classname>
            のインスタンスを作成して <filename>php://input</filename>
            からの入力を受け取ります。
        </para>

        <para>
            <methodname>Zend_XmlRpc_Server::handle()</methodname> は、
            リクエストメソッドに応じて適切なハンドラに処理を振り分けます。
            そして、
            <classname>Zend_XmlRpc_Response</classname> を継承したオブジェクトか
            <classname>Zend_XmlRpc_Server_Fault</classname> オブジェクトを返します。
            これらのオブジェクトはどちらも <methodname>__toString()</methodname>
            メソッドを実装しており、妥当な <acronym>XML-RPC</acronym> <acronym>XML</acronym> レスポンスを直接出力できます。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.anatomy">
        <title>Web サービスの解剖図</title>

        <sect3 id="zend.xmlrpc.server.anatomy.general">
            <title>一般的な考慮点</title>

            <!-- TODO : to be translation -->
            <para>
                For maximum performance it is recommended to use a simple
                bootstrap file for the server component. Using
                <classname>Zend_XmlRpc_Server</classname> inside a
                <link linkend="zend.controller"><classname>Zend_Controller</classname></link>
                is strongly discouraged to avoid the overhead.
            </para>

            <para>
                Services change over time and while webservices are generally
                less change intense as code-native <acronym>APIs</acronym>, it
                is recommended to version your service. Do so to lay grounds to
                provide compatibility for clients using older versions of your
                service and manage your service lifecycle including deprecation
                timeframes.To do so just include a version number into your
                <acronym>URI</acronym>. It is also recommended to include the
                remote protocol name in the <acronym>URI</acronym> to allow easy
                integration of upcoming remoting technologies.
                http://myservice.ws/<emphasis>1.0/XMLRPC/</emphasis>.
            </para>
        </sect3>

        <sect3 id="zend.xmlrpc.server.anatomy.expose">
            <title>What to expose?</title>

            <para>
                Most of the time it is not sensible to expose business objects
                directly. Business objects are usually small and under heavy
                change, because change is cheap in this layer of your
                application. Once deployed and adopted, web services are hard to
                change. Another concern is <acronym>I/O</acronym> and latency:
                the best webservice calls are those not happening. Therefore
                service calls need to be more coarse-grained than usual business
                logic is. Often an additional layer in front of your business
                objects makes sense. This layer is sometimes referred to as <ulink
                    url="http://martinfowler.com/eaaCatalog/remoteFacade.html">Remote
                    Facade</ulink>.
                Such a service layer adds a coarse grained interface on top of
                your business logic and groups verbose operations into smaller
                ones.
            </para>
        </sect3>
    </sect2>

    <sect2 id="zend.xmlrpc.server.conventions">
        <title>規約</title>

        <para>
            <classname>Zend_XmlRpc_Server</classname> では、開発者が関数やクラスメソッドを
            <acronym>XML-RPC</acronym> メソッドとしてアタッチできるようになっています。
            アタッチされるメソッドの情報は <classname>Zend_Server_Reflection</classname>
            を使用して取得し、関数やメソッドのコメントブロックから
            メソッドのヘルプ文とシグネチャを取得します。
        </para>

        <para>
            <acronym>XML-RPC</acronym> の型は必ずしも <acronym>PHP</acronym> の型と一対一対応しているわけではありません。
            しかし、@param や @return の行をもとに、できるだけ適切な型を推測しようとします。
            <acronym>XML-RPC</acronym> の型の中には、直接対応する <acronym>PHP</acronym> の型がないものもありますが、
            その場合は PHPDoc の中で <acronym>XML-RPC</acronym> の型のヒントを指定します。
            たとえば次のような型が該当します。
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <emphasis><property>dateTime.iso8601</property></emphasis> ...
                    '<command>YYYYMMDDTHH:mm:ss</command>' 形式の文字列
                </para>
            </listitem>

            <listitem><para><emphasis>base64</emphasis> ... base64 エンコードされたデータ</para></listitem>

            <listitem><para><emphasis>struct</emphasis> ... 任意の連想配列</para></listitem>
        </itemizedlist>

        <para>
            ヒントを指定するには、次のようにします。
        </para>

        <programlisting language="php"><![CDATA[
/**
* これはサンプル関数です
*
* @param base64 $val1 Base64 エンコードされたデータ
* @param dateTime.iso8601 $val2 ISO 日付
* @param struct $val3 連想配列
* @return struct
*/
function myFunc($val1, $val2, $val3)
{
}
]]></programlisting>

        <para>
            PhpDocumentor はパラメータや返り値の型を検証しません。
            そのため、これが <acronym>API</acronym> ドキュメントに影響を及ぼすことはありません。
            しかし、このヒントは必須です。メソッドがコールされた際に、
            この情報をもとにサーバで検証を行うからです。
        </para>

        <para>
            パラメータや返り値で複数の型を指定してもかまいません。
            <acronym>XML-RPC</acronym> の仕様では、system.methodSignature は
            すべてのメソッドシグネチャ
            (すなわちパラメータと返り値の組み合わせ) の配列を返すことになっています。
            複数指定する方法は、通常の PhpDocumentor の場合と同様に
            '|' 演算子を使用します。
        </para>

        <programlisting language="php"><![CDATA[
/**
* This is a sample function
*
* @param string|base64 $val1 文字列あるいは base64 エンコードされたデータ
* @param string|dateTime.iso8601 $val2 文字列あるいは ISO 日付
* @param array|struct $val3 Normal 数値添字配列あるいは連想配列
* @return boolean|struct
*/
function myFunc($val1, $val2, $val3)
{
}
]]></programlisting>

        <note>
            <para>
                複数のシグネチャを定義すると、それを利用する開発者を混乱させてしまいます。
                物事を簡単にするために、 <acronym>XML-RPC</acronym> サービスのメソッドは単純なシグネチャだけを持つべきでしょう。
            </para>
        </note>
    </sect2>

    <sect2 id="zend.xmlrpc.server.namespaces">
        <title>名前空間の活用</title>

        <para>
            <acronym>XML-RPC</acronym> には名前空間の概念があります。基本的に、これは
            複数の <acronym>XML-RPC</acronym> メソッドをドット区切りの名前空間でまとめるものです。
            これにより、さまざまなクラスで提供されるメソッド名の衝突を避けることができます。
            例として、<acronym>XML-RPC</acronym> サーバは 'system'
            名前空間でこれらのメソッドを提供することが期待されています。
        </para>

        <itemizedlist>
            <listitem><para>system.listMethods</para></listitem>
            <listitem><para>system.methodHelp</para></listitem>
            <listitem><para>system.methodSignature</para></listitem>
        </itemizedlist>

        <para>
            内部的には、これらは
            <classname>Zend_XmlRpc_Server</classname> の同名のメソッドに対応しています。
        </para>

        <para>
            自分が提供するメソッドに名前空間を追加したい場合は、
            関数やクラスをアタッチする際のメソッドで名前空間を指定します。
        </para>

        <programlisting language="php"><![CDATA[
// My_Service_Class のパブリックメソッドは、すべて
// myservice.メソッド名 でアクセスできるようになります
$server->setClass('My_Service_Class', 'myservice');

// 関数 'somefunc' は funcs.somefunc としてアクセスするようにします
$server->addFunction('somefunc', 'funcs');
]]></programlisting>
    </sect2>

    <sect2 id="zend.xmlrpc.server.request">
        <title>独自のリクエストオブジェクト</title>

        <para>
            ほとんどの場合は、
            <classname>Zend_XmlRpc_Server</classname> や <classname>Zend_XmlRpc_Request_Http</classname>
            に含まれるデフォルトのリクエスト型を使用するでしょう。
            しかし、<acronym>XML-RPC</acronym> を <acronym>CLI</acronym> や
            <acronym>GUI</acronym> 環境などで動かしたい場合もあるでしょうし、
            リクエストの内容をログに記録したい場合もあるでしょう。
            そのような場合には、<classname>Zend_XmlRpc_Request</classname>
            を継承した独自のリクエストオブジェクトを作成します。
            注意すべき点は、<methodname>getMethod()</methodname> メソッドと <methodname>getParams()</methodname>
            メソッドを必ず実装しなければならないということです。
            これらは、<acronym>XML-RPC</acronym> サーバがリクエストを処理する際に必要となります。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.response">
        <title>独自のレスポンス</title>

        <para>
            リクエストオブジェクトと同様、<classname>Zend_XmlRpc_Server</classname>
            は独自のレスポンスオブジェクトを返すこともできます。
            デフォルトでは <classname>Zend_XmlRpc_Response_Http</classname> オブジェクトが返されます。
            これは、<acronym>XML-RPC</acronym> で使用される適切な Content-Type <acronym>HTTP</acronym>
            ヘッダを送信します。独自のオブジェクトを使用する場面としては、
            レスポンスをログに記録したり、
            あるいはレスポンスを標準出力に返したりといったことが考えられます。
        </para>

        <para>
            独自のレスポンスクラスを使用するには、<methodname>handle()</methodname> をコールする前に
            <methodname>Zend_XmlRpc_Server::setResponseClass()</methodname> を使用します。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.fault">
        <title>Fault による例外の処理</title>

        <para>
            <classname>Zend_XmlRpc_Server</classname> は、配送先のメソッドで発生した例外を捕捉します。
            例外を捕捉した場合は、<acronym>XML-RPC</acronym> の fault レスポンスを生成します。
            しかし、デフォルトでは、例外メッセージとコードは fault
            レスポンスで用いられません。これは、
            あなたのコードを守るための判断によるものです。
            たいていの例外は、コードや環境に関する情報を必要以上にさらけ出してしまいます
            (わかりやすい例だと、データベースの抽象化レイヤの例外を想像してみてください)。
        </para>

        <para>
            しかし、例外クラスをホワイトリストに登録することで、
            fault レスポンス内で例外を使用することもできます。
            そうするには、
            <methodname>Zend_XmlRpc_Server_Fault::attachFaultException()</methodname>
            を使用して例外クラスをホワイトリストに渡します。
        </para>

        <programlisting language="php"><![CDATA[
Zend_XmlRpc_Server_Fault::attachFaultException('My_Project_Exception');
]]></programlisting>

        <para>
            他のプロジェクトの例外を継承した例外クラスを利用するのなら、
            一連のクラス群を一度にホワイトリストに登録することもできます。
            <classname>Zend_XmlRpc_Server_Exceptions</classname> は常にホワイトリストに登録されており、
            固有の内部エラー (メソッドが未定義であるなど) を報告できます。
        </para>

        <para>
            ホワイトリストに登録されていない例外が発生した場合は、
            コード '404'、メッセージ 'Unknown error' の falut
            レスポンスを生成します。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.caching">
        <title>リクエスト間でのサーバ定義のキャッシュ</title>
        <para>
            たくさんのクラスを <acronym>XML-RPC</acronym> サーバインスタンスにアタッチすると、
            リソースを大量に消費してしまいます。各クラスを調べるために
            リフレクション <acronym>API</acronym> を (<classname>Zend_Server_Reflection</classname> 経由で) 使用する必要があり、
            使用できるすべてのメソッドのシグネチャをサーバクラスに提供します。
        </para>
        <para>
            使用するリソースの量を軽減するために、<classname>Zend_XmlRpc_Server_Cache</classname>
            を用いてリクエスト間でサーバ定義をキャッシュできます。
            <methodname>__autoload()</methodname> と組み合わせることで、これはパフォーマンスを劇的に向上させます。
        </para>
        <para>
            使用例は次のようになります。
        </para>
        <programlisting language="php"><![CDATA[
function __autoload($class)
{
    Zend_Loader::loadClass($class);
}

$cacheFile = dirname(__FILE__) . '/xmlrpc.cache';
$server = new Zend_XmlRpc_Server();

if (!Zend_XmlRpc_Server_Cache::get($cacheFile, $server)) {
    require_once 'My/Services/Glue.php';
    require_once 'My/Services/Paste.php';
    require_once 'My/Services/Tape.php';

    $server->setClass('My_Services_Glue', 'glue');   // glue. 名前空間
    $server->setClass('My_Services_Paste', 'paste'); // paste. 名前空間
    $server->setClass('My_Services_Tape', 'tape');   // tape. 名前空間

    Zend_XmlRpc_Server_Cache::save($cacheFile, $server);
}

echo $server->handle();
]]></programlisting>
        <para>
            この例では、スクリプトと同じディレクトリにある <property>xmlrpc.cache</property>
            からサーバの定義を取得しようとします。取得できなかった場合は、
            必要なサービスクラスを読み込み、
            それをサーバのインスタンスにアタッチし、
            そしてその定義を新しいキャッシュファイルに記録します。
        </para>
    </sect2>

    <sect2 id="zend.xmlrpc.server.use">
        <title>使用例</title>
        <para>
            以下のいくつかの使用例で、開発者が使用できるオプションを説明します。
            各使用例は、それまでに紹介した例に追加していく形式になります。
        </para>

        <example id="zend.xmlrpc.server.use.attach-function">
            <title>基本的な使用法</title>

            <para>
                次の例は関数を <acronym>XML-RPC</acronym> メソッドとしてアタッチし、
                受け取ったコールを処理します。
            </para>

            <programlisting language="php"><![CDATA[
/**
 * 値の MD5 合計を返します
 *
 * @param string $value md5sum を計算する値
 * @return string 値の MD5 合計
 */
function md5Value($value)
{
    return md5($value);
}

$server = new Zend_XmlRpc_Server();
$server->addFunction('md5Value');
echo $server->handle();
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.attach-class">
            <title>クラスのアタッチ</title>

            <para>
                次の例は、クラスのパブリックメソッドを
                <acronym>XML-RPC</acronym> メソッドとしてアタッチします。
            </para>

            <programlisting language="php"><![CDATA[
require_once 'Services/Comb.php';

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_Comb');
echo $server->handle();
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.attach-class-with-arguments">
            <title>引数にクラスを添付</title>

            <!-- TODO : to be translated -->
            <para>
                The following example illustrates how to attach a class' public
                methods and passing arguments to its methods. This can be used to specify certain
                defaults when registering service classes.
            </para>

            <programlisting language="php"><![CDATA[
class Services_PricingService
{
    /**
     * Calculate current price of product with $productId
     *
     * @param ProductRepository $productRepository
     * @param PurchaseRepository $purchaseRepository
     * @param integer $productId
     */
    public function calculate(ProductRepository $productRepository,
                              PurchaseRepository $purchaseRepository,
                              $productId)
    {
        ...
    }
}

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_PricingService',
                  'pricing',
                  new ProductRepository(),
                  new PurchaseRepository());
]]></programlisting>

            <para>
                The arguments passed at <methodname>setClass()</methodname> at server construction
                time are injected into the method call <command>pricing.calculate()</command> on
                remote invokation. In the example above, only the argument <varname>$purchaseId</varname>
                is expected from the client.
            </para>
        </example>

        <example id="zend.xmlrpc.server.use.attach-class-with-arguments-constructor">
            <title>Passing arguments only to constructor</title>

            <para>
                <classname>Zend_XmlRpc_Server</classname> allows to restrict argument passing to
                constructors only. This can be used for constructor dependency injection.
                To limit injection to constructors, call <methodname>sendArgumentsToAllMethods</methodname>
                and pass <constant>FALSE</constant> as an argument. This disables the default behavior of all arguments
                being injected into the remote method. In the example below the instance of
                <classname>ProductRepository</classname> and <classname>PurchaseRepository</classname> is only
                injected into the constructor of <classname>Services_PricingService2</classname>.
            </para>

            <programlisting language="php"><![CDATA[
class Services_PricingService2
{
    /**
     * @param ProductRepository $productRepository
     * @param PurchaseRepository $purchaseRepository
     */
    public function __construct(ProductRepository $productRepository,
                                PurchaseRepository $purchaseRepository)
    {
        ...
    }

    /**
     * Calculate current price of product with $productId
     *
     * @param integer $productId
     * @return double
     */
    public function calculate($productId)
    {
        ...
    }
}

$server = new Zend_XmlRpc_Server();
$server->sendArgumentsToAllMethods(false);
$server->setClass('Services_PricingService2',
                  'pricing',
                  new ProductRepository(),
                  new PurchaseRepository());
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.attach-instance">
            <title>Attaching a class instance</title>

            <para>
                <methodname>setClass()</methodname> allows to register a previously instantiated
                object at the server. Just pass an instance instead of the class name. Obviously
                passing arguments to the constructor is not possible with pre-instantiated
                objects.
            </para>
        </example>

        <example id="zend.xmlrpc.server.use.attach-several-classes-namespaces">
            <title>名前空間を用いた複数のクラスのアタッチ</title>

            <para>
                次の例は、複数のクラスをそれぞれの名前空間でアタッチします。
            </para>

            <programlisting language="php"><![CDATA[
require_once 'Services/Comb.php';
require_once 'Services/Brush.php';
require_once 'Services/Pick.php';

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_Comb', 'comb');   // メソッドをコールするには comb.* とします
$server->setClass('Services_Brush', 'brush'); // メソッドをコールするには brush.* とします
$server->setClass('Services_Pick', 'pick');   // メソッドをコールするには pick.* とします
echo $server->handle();
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.exceptions-faults">
            <title>fault レスポンス用に使用する例外の指定</title>

            <para>
                次の例は、<classname>Services_Exception</classname> の派生クラスに対して
                そのコードとメッセージを falut レスポンスで報告させるようにします。
            </para>

            <programlisting language="php"><![CDATA[
require_once 'Services/Exception.php';
require_once 'Services/Comb.php';
require_once 'Services/Brush.php';
require_once 'Services/Pick.php';

// Services_Exceptions を fault レスポンスで報告させるようにします
Zend_XmlRpc_Server_Fault::attachFaultException('Services_Exception');

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_Comb', 'comb');   // メソッドをコールするには comb.* とします
$server->setClass('Services_Brush', 'brush'); // メソッドをコールするには brush.* とします
$server->setClass('Services_Pick', 'pick');   // メソッドをコールするには pick.* とします
echo $server->handle();
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.custom-request-object">
            <title>独自のリクエスト及びレスポンスオブジェクトの利用</title>

            <!-- TODO : to be translated -->
            <para>
                Some use cases require to utilize a custom request object.
                For example, <acronym>XML/RPC</acronym> is not bound to
                <acronym>HTTP</acronym> as a transfer protocol. It is possible to use
                other transfer protocols like <acronym>SSH</acronym> or telnet to send
                the request and response data over the wire. Another use case is
                authentication and authorization. In case of a different transfer
                protocol, one need to change the implementation to read request data.
            </para>
            
            <para>
                次の例は、独自のリクエストオブジェクトを作成し、
                それをサーバに渡して処理します。
            </para>

            <programlisting language="php"><![CDATA[
require_once 'Services/Request.php';
require_once 'Services/Exception.php';
require_once 'Services/Comb.php';
require_once 'Services/Brush.php';
require_once 'Services/Pick.php';

// Services_Exceptions を fault レスポンスで報告させるようにします
Zend_XmlRpc_Server_Fault::attachFaultException('Services_Exception');

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_Comb', 'comb');   // メソッドをコールするには comb.* とします
$server->setClass('Services_Brush', 'brush'); // メソッドをコールするには brush.* とします
$server->setClass('Services_Pick', 'pick');   // メソッドをコールするには pick.* とします

// リクエストオブジェクトを作成します
$request = new Services_Request();

echo $server->handle($request);
]]></programlisting>
        </example>

        <example id="zend.xmlrpc.server.use.custom-response-object">
            <title>独自のレスポンスクラスの指定</title>

            <para>
                次の例は、独自のレスポンスクラスを作成し、
                それをレスポンスとして返します。
            </para>

            <programlisting language="php"><![CDATA[
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';

// Services_Exceptions を fault レスポンスで報告させるようにします
Zend_XmlRpc_Server_Fault::attachFaultException('Services_Exception');

$server = new Zend_XmlRpc_Server();
$server->setClass('Services_Comb', 'comb');   // メソッドをコールするには comb.* とします
$server->setClass('Services_Brush', 'brush'); // メソッドをコールするには brush.* とします
$server->setClass('Services_Pick', 'pick');   // メソッドをコールするには pick.* とします

// リクエストオブジェクトを作成します
$request = new Services_Request();

// 独自のレスポンスを使用します
$server->setResponseClass('Services_Response');

echo $server->handle($request);
]]></programlisting>
        </example>
    </sect2>

    <sect2 id="zend.xmlrpc.server.performance">
        <title>パフォーマンスの最適化</title>

        <example id="zend.xmlrpc.server.performance.caching">
            <title>リクエスト間でのサーバ定義のキャッシュ</title>

            <para>
                次の例は、リクエスト間でサーバ定義をキャッシュします。
            </para>

            <programlisting language="php"><![CDATA[
// キャッシュファイルを指定します
$cacheFile = dirname(__FILE__) . '/xmlrpc.cache';

// Services_Exceptions を fault レスポンスで報告させるようにします
Zend_XmlRpc_Server_Fault::attachFaultException('Services_Exception');

$server = new Zend_XmlRpc_Server();

// サーバ定義をキャッシュから取得しようとします
if (!Zend_XmlRpc_Server_Cache::get($cacheFile, $server)) {
    $server->setClass('Services_Comb', 'comb');   // メソッドをコールするには comb.* とします
    $server->setClass('Services_Brush', 'brush'); // メソッドをコールするには brush.* とします
    $server->setClass('Services_Pick', 'pick');   // メソッドをコールするには pick.* とします

    // キャッシュに保存します
    Zend_XmlRpc_Server_Cache::save($cacheFile, $server);
}

// リクエストオブジェクトを作成します
$request = new Services_Request();

// 独自のレスポンスを使用します
$server->setResponseClass('Services_Response');

echo $server->handle($request);
]]></programlisting>
        </example>

        <note>
            <para>
                サーバーのキャッシュファイルは、ドキュメントルートの外部に配置されるべきです。
            </para>
        </note>

        <example id="zend.xmlrpc.server.performance.xmlgen">
            <title>XML 生成を最適化</title>

            <!-- TODO : to be translated -->
            <para>
                <classname>Zend_XmlRpc_Server</classname> uses
                <classname>DOMDocument</classname> of <acronym>PHP</acronym>
                extension <emphasis>ext/dom</emphasis> to generate it's
                <acronym>XML</acronym> output. While <emphasis>ext/dom</emphasis> is
                available on a lot of hosts it is not exactly the fastest.
                Benchmarks have shown, that <classname>XmlWriter</classname>
                from <emphasis>ext/xmlwriter</emphasis> performs better.
            </para>

            <para>
                If <emphasis>ext/xmlwriter</emphasis> is available on your host, you can
                select a the <classname>XmlWriter</classname>-based generator
                to leaverage the performance differences.
            </para>

            <programlisting language="php"><![CDATA[
require_once 'Zend/XmlRpc/Server.php';
require_once 'Zend/XmlRpc/Generator/XmlWriter.php';

Zend_XmlRpc_Value::setGenerator(new Zend_XmlRpc_Generator_XmlWriter());

$server = new Zend_XmlRpc_Server();
...
]]></programlisting>
        </example>

        <note>
            <title>Benchmark your application</title>

            <para>
                Performance is determined by a lot of parameters and
                benchmarks only apply for the specific test case. Differences
                come from <acronym>PHP</acronym> version, installed extensions, webserver and
                operating system just to name a few. Please make sure to
                benchmark your application on your own and decide which
                generator to use based on <emphasis>your</emphasis> numbers.
            </para>
        </note>

        <note>
            <title>Benchmark your client</title>

            <para>
                This optimization makes sense for the client side too. Just
                select the alternate <acronym>XML</acronym> generator before
                doing any work with <classname>Zend_XmlRpc_Client</classname>.
            </para>
        </note>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->