InfoQのStefan Tilkov氏は、Spring WebサービスクリエータであるArjen Poutsma氏(ブログ・英語)と一般的なWebサービスについて、とりわけSpringサポートについて話をする機会を得ました。
InfoQ: 簡単に自己紹介していただけますか。
Arjen Poutsma (AP氏): 私は、Interface21のシニアコンサルタントです。これまで約13年間、企業向けのアプリケーション開発を行ってきました。最初はC++、次にJavaで、2年間ほどはいくつかの.NET開発をしました。約4年前にWebサービスに興味を持ち始め、いくつかの大企業でこれらの実装方法について教えてきました。
ここ1年半の間、コントラクト第一の作成に焦点を当てているSpring製品ラインの製品であり、文書方式Webサービスである、Spring Webサービス(サイト･英語)プロジェクトに取り組んできました。最近、Spring WebサービスのMilestone 3を発売しました。2007年の第2四半期には1.0を発表する予定です。
InfoQ: Spring Webサービスを構築しようとした主な動機は何だったのでしょうか。Javaに対してすでに十分のWebサービスフレームワークがあるのではないのでしょうか。
AP氏: コンサルタントとして仕事をしていると、Webサービスに重大な問題を抱えているユーザに直面します。たとえば、ユーザは、サービスコントラクトの複数のバージョンを維持する、あるいは、最初にオブジェクトへ変換すること無く受信するXMLを直接扱いたいと考えていました。当時、既存のSOAPスタックは、正当な方法で実行するよりもむしろ、既存のJavaクラスの"SOAP化"を簡単にすることに重点を置いていました。つまり、サービスコントラクトを書くことから始め、受信するXMLを扱えるクラスを書くことです。コントラクト第一のWebサービスを設計するのは可能でしたが、簡単ではありませんでした。ところがSpring製品ライン全体の効果が出始めると、Spring Webサービスによる正攻法が簡単になり、Webサービスを既存のアーキテクチャに適合させる方法が明らかにされました。
InfoQ: XMLをオブジェクトに変換したり戻したりすることが、まさしくWebサービススタックに期待されていた機能だと、多くの人々が主張していると思われます。意見を異にされるようですが、詳しく説明してもらえますか。
AP氏: 開発者は、彼らが望む何らかの方法で、受信したXMLの処理を選ぶ権利を持つべきで、XML変換は（使いやすい）一つの方法です。
ただし、XML変換にはいくつか問題があります。その一つは、いくつかの変換エンジンがかなり脆弱であることです。つまり、実際にポステルの法則（自ら送るものには保守的であれ、受け取るものには寛容であれ）に適合しない、未知のXMLに出会ったときに、変換エンジンが壊れてしまうからです。
もう一つは、オブジェクト指向言語のJavaあるいはC#言語や、階層ベースのXMLなどの間に、かなり構造的な違いがあることです。たとえば、オブジェクトのグラフを取り上げてみると、配偶者特性をもつPersonクラスがあるとすると、配偶者の配偶者は同じオブジェクトを示すことになります。そのような関係をXMLで表す標準的な方法はなく、個別の手段に頼るしかありません。この他にも、データの型に関する問題があります。Javaの場合、java.util.Mapと、2つのベースの実装（HashMapとTreeMap）があります。XMLスキーマ（XSD）は、辞書構造用のデータ型を持っていません。となると、HashMapをXMLに変換すると何が起きるでしょうか。
うまくいけば、変換結果からある種のXMLは得られるでしょうが、その結果を再び復元すると、おそらく初めと同じHashMapにはならないでしょう。
ですから、トランスペアレントにオブジェクトが持続することがないのと同様、トランスペアレントな変換というようなことはありません。SQLとオブジェクト間の変換のためにObject Relational Mapperを指示するのとほとんど同じように、オブジェクトをXMLに変換する方法を変換エンジンに指示する必要があるでしょう。変換エンジンをmarshallingと呼ぶ代わりに、Object/XMLマッピングと呼ぶことを私が好む理由はこれなのです。つまり、管理すべきObject/XMLインピーダンスの不適当な組み合わせもあることがはっきりしているからです。
InfoQ: JAX-RPC/JAX-WSについて何かご意見はありますか。
AP氏: JAX-RPCが発表されたとき、人々は、Webサービスを遠隔手続呼び出しするまったく別の方法として考えていました。仕様の名前がこのことをはっきりと暗示しています。数年経ち、これは、振る舞い駆動式のRPCのようなWebサービスを実行する方法を推し進める最良の方法ではないと分かりました。これによって、クライアントとサーバとの間の結合がより緊密になり、しかも、待ち時間や障害、不十分な共有メモリアクセスなどが完全に無視されています。その代わり、データ駆動式のメッセージのような技法はよく適合します。
JAX-WSはJAX-RPCを改善したものです。特に私が好きなのは、Provider APIです。これは、受信するSOAPリクエストを処理するために、メッセージに焦点を合わせた方法を提供しています。残念な点は、他の仕様がまだRPCにほとんど重点を置いていることや、申し分のないほど品質の高いJava1.4の代替品があるときでも、Java5の機能に強く依存している事実があることです。最近発表されたすべてのJSRには、2～3個の注釈が明示される必要があるように思えます。世の中には、まだ多くのJava1.4ユーザや、あるいは、1.3ユーザすらいます。これらのユーザは、汎用体やenum、注釈を利用することができません。この3つすべては、前に述べたProvider APIを利用するときに必要になります。
InfoQ: Spring Webサービスがほかと異なるところは何でしょうか。なぜ、AxisやXFire、あるいは、ActiveSOAPではなくSpring Webサービスを使うのでしょうか。
AP氏: Spring Webサービスにはいくつかのユニークな特徴があります。第一に、完全にコントラクト第一のWebサービス設計に重点を置いていることです。つまり、XMLメッセージを定義する独自のXSDスキーマを書き込む必要がある、と言う意味です。WSDLのXDSスキーマを参照することができ（Spring Webサービスは、そのXSDからWSDLを生成することもできます）、多分、妥当性確認の目的でそれを利用することもできます。興味深い点は、Webサービスで経験する多くの相互運用性の問題が、コントラクト第一の開発スタイルを利用すると解消されることです。これは、コントラクト第一が一般的に最良の実施例であると考えられるからです。分かりやすく言うと、あなたはXML APIを設計しています。つまり、Javaを使ってそのAPIを実施するということは、クライアントが気にかけることもないような細部を実行することです。
次に、Spring Webサービスは、コントラクトと実装の間を柔軟結合にしています。つまり、コントラクトをクラスに直接結びつけるwsdl2javaツールはなく、代わりにあらゆる方法で（DOMやSAX、StAX、あるいは、JAXBやCastor、JIBX、または、XMLBeansなどのXML変換技術でも）、受信するXMLを扱うエンドポイントを実行します。エンドポイントに受信したリクエストを対応付けする方法は、完全にあなた次第です。初期設定では、メッセージコンテンツ、あるいは、SOAPActionヘッダに基づいた対応付けが提供されています。本来の趣旨は、メソッド呼び出しを扱わないということですが、むしろXMLがメッセージを送るということです。
最後に、以下に示すように、Springプロジェクトに期待できる特徴がいくつかあります。
- WS-Securityの実装は、Acegi Securityと一体化する
- JMSサポートはSpring2のメッセージ駆動POJOを用いる
- 主なユーザークラス（WebServiceTemplate）は、JdbcTemplateと同様のAPIを提示している
- XML変換サポートは、完全にWebサービスと無関係（そのため、他の設定に利用できる）
- JDK1.4以上で動作する（ただし、Java5-用の限定的な特性もある）
InfoQ: それでは、初期設定で、私のアプリケーションにメッセージからXMLが渡されますか。それはどんな形ですか、DOMツリーのよう、ストリームのよう、リーダー、それとも、何か他のものですか。
AP氏: アプリケーションに、（javax.xml.transform.Sourceから）読み込むためのXML入力抽象構造と（javax.xml.transform.Result）に書き込むための出力抽象構造がそれぞれ渡されます。このように、コードは、APIを扱ういかなる特定のXMLにも結びつけられません。実際には、このメカニズムの実装は、利用のために選ばれるメッセージ要因に依存します。SOAPに対して2つのことが提供されていす。つまり、初期値はSAAJ（javax.xml.soap、J2EE 1.4の一部）に基づき、下のDOMを利用し、大規模なメッセージに対しては、StAXストリームを利用する、Axis2のAXIOMがサポートされます。
InfoQ: Spring Webサービスは、どのようにしてWS-* standardsをハンドリングするのでしょう。箱の外でこれらのサポートを行っているのでしょうか。
AP氏: Spring Webサービスは、SOAPの1.1と1.2や、WS-Securityと、XSDスキーマから1.1WSDLを生成するための対応をサポートしています。WS-Addressingは、次の1.0タイムフレームに計画されています。基本的に、私は、十分にユーザの要求がでるまで、標準を実装して待つ傾向にあります。今までのところ、皆さん大変満足しておられるようです。
InfoQ: WS-*を展望するに当たって何か包括的なご意見はございますか。
AP氏: そうですね、好きなところと嫌いなところがあります。SOAPは好きです。転送全般にわたってXMLメッセージを送信することは、良い方法だと考えます。WDSLはそんなに好きではありません。演算やインターフェースなどを備えたWebサービスのオブジェクト指向モデルをほとんどが持っているからで、WDSLはSOAPにうまく適合しません。SOAPには、演算がありませんし、ただのXMLメッセージです。その点では、SSDL（SOAPサービス記述言語）の方がもっと好きです。
SOAPヘッダーにアドレス指定情報を置くWS-Addressingの概念は好きですが、使用するときに5つの異なる互換性のないバージョンがあると言う事実は好きになれません。つまり、誰かがWS-Addressingサポートのサービスを提供しますといえば、「2004年3月バージョンや2004年8月バージョン、他のどのバージョンでもサポートしますか」と、訪ねることになるでしょうね。
最後に、WS-Securityは非常に役に立つと考えています。これは、分かりきったことをやり直そうとはしませんが、つじつまが合えば必ずXML-DSigとXML-Encを用います。
InfoQ: RESTについてどう思われますか。そして、Spring Webサービスは、いつかこれをサポートすると思われますか。
AP氏: RESTは気に入っています。実績のある技術であるHTTPにREST自体の基礎を置いて、WS-*が直面する多くの問題を解決している方法は面白いと思います。とは言っても、RESTは、ほとんどSOAPのようであるか、あるいは、それよりも制限されていると思います。RESTサービスを書き込むときは、何がリソースであるか、サポートするデータフォーマットはどれか（RESTはまったくXMLではありません）、どのHTTPの方法でそれらをサポートするのか、何を意味しているかについてはっきりとした考えを持つ必要があります。さらに、このすべてが明確に文書化されなければなりません。この点では、HTTP仕様は十分ではありません。
多くの人がRESTをやってみると言っていますが、実際にすることは、Don Box氏がPOX（平凡で古いXML）と名づけたぐらいのことです。POXは、XMLメッセージングプロトコルのことで、この場合、メッセージを取り囲むSOAPの封筒なしで、XMLメッセージを簡単に送れます。Spring Webサービスでは、すでにこれがサポートされています。
"正当な"RESTのサポートについては、将来サポートするつもりですが、Spring Webサービスの1.0バージョンではサポートしません。これは、SOAPやPOXとはかなり異なっています。たとえば、常に必要となるXMLメッセージがありません。我々は、0.003秒後に再び構文化されるパイプラインにHTTPリクエストを移動させて、これからXMLメッセージを作成してRESTをサポートしたいとは思いません。これには、とにかく費用がかかりすぎます。その代わりに、SpringのWebフレームワークであるSpring-MVCにRESTサポートの基礎を置くつもりです。
InfoQ: お時間を頂きありがとうございました。
原文はこちらです：http://www.infoq.com/articles/arjen-poutsma-spring-ws
（このArticleは2007年1月31日にリリースされました）