S2Axis2でのサービス定義(ServiceDef)

Axis2のservice.xmlの定義内容を元に、S2Axis2でのサービス定義を考えてみる。サービス定義を保持するのがServiceDefクラス。
Annotationでサービスとして公開するクラスに設定しようかな、とも考えたんだけど、まずはS2Axisと同じ形式で、diconで指定できるようにしてみる(でもそれって、設定ファイルをできるだけ書かない、というS2の思想に反している!?)。


ひとまず、diconはこんな感じ。

<component name="Echo" class="examples.impl.EchoImpl">
    <meta name="axis-service">
        <component class="org.seasar.remoting.axis2.ServiceDef">
            <property name="serviceType">@examples.Echo@class</property>
            <property name="scope">"Request"</property>
            <property name="targetNamespace">"http://ws.apache.org/axis2"</property>
            <property name="schemaNamespace">"http://examples/xsd"</property>
            <property name="excludeOperations">{"method1", "method2"}</property>

            <initMethod name="addMessageReceiver">
                <arg>"http://www.w3.org/2004/08/wsdl/in-out"</arg>
                <arg>@org.apache.axis2.rpc.receivers.RPCMessageReceiver@class</arg>
            </initMethod>
            <initMethod name="addMessageReceiver">
                <arg>"http://www.w3.org/2004/08/wsdl/in-only"</arg>
                <arg>@org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver@class</arg>
            </initMethod>
        </component>
    </meta>
</component>

service.xml の定義内容と比較すると、

    • name(サービスの名前)は、componentタグのname属性で指定できるので不要。
    • serviceType は、ServiceClass の代わり。
    • description は、Web管理ツールを利用しないため不要。
    • transports は、ひとまずHTTPに固定。
    • operation は、定義が複雑化しそうなので別途考えることにしよう。


serviceType としたのは、S2Axisと同じ考え。サービスの実装クラスは、WSDLファイルを生成する対象となるので、interface を指定できる方がうれしい。
また、デフォルトの設定だと、名前空間がパッケージ名から生成されるため、インタフェースで呼び出すクライアントと、実装クラスを公開するサーバ側で、名前空間が食い違ってしまうのも防げる(こっちが本命だったりする)。


追記

  • scopeは、diconのcomponent定義で、instance属性を指定することにします。S2コンテナにライフサイクル管理を任せます。
  • addMessageReceiverは、Class型ではなく、インスタンスを指定することにします。Kijimunaで型チェックができるため。