オープンソース の Java 対応 WS スタック ? 設計の目標と理念

はじめに

民間ベンダー各社が提供しているオプション以外にも、Web サービスを実現できるオープンソースの Java フレームワークの選択肢は数多く存在する。Java スペースにおいて SOAP/WS-* をベースとしたソリューションを実現できるオープンソースのスタックの中で、特に人気が高いのは Apache Axis2(サイト・英語)、Apache CXF(サイト・英語)、Spring Web Services(サイト・英語)、JBossWS(サイト・英語)、Sun の Metro(サイト・英語) である。このようなスタックを開発している主要なベンダーに、さまざまな質問を投げかけてみた。設計の目標、Java や Web サービス標準に対するアプローチ、データバインディング、XML へのアクセス、相互運用性、REST のサポート、フレームワークの成熟度に関する質問である。その結果、当然のことながら、さまざまな類似点や注目に値する相違点があることがわかった。

この記事は 2 つのパートに分かれている。まず、まず質問の概略を示し、開発担当者の回答の中で重要なものを紹介する。この概略には偏見が入らないように努めたが、参考までに（詳細を知りたい人のために）、2 つめのパートに開発担当者の回答をそのまま記載した。

インタビューを行なった開発担当者は、Paul Fremantle 氏（Axis2）、Dan Diephouse 氏（CXF）、Arjen Poutsma氏（Spring Web Services）、Thomas Diesler 氏（JBossWS）、カワグチ コウスケ 氏（Metro）である。

Paul Fremantle 氏は、数多くの Apache プロジェクトを推進している WSO2 社の共同創立者であり、同社の技術営業部の部長を務めている。IBM に在職中、Web Service Gateway を作り、WebSphere Application Server に Web Service Gateway を組み込むプロジェクトにおいて、開発や出荷を担当するチームのリーダーを務めた。また、Service Integration Bus テクノロジーを WebSphere Application Server 6 に組み込むチームのメンバーでもあった。また、Web Services Invocation Framework（WSIF）を共同制作し、JSR 110 のサブリーダーと OASIS WS-RX TC の副議長も努めた。

Dan Diephouse 氏は、オープンソースの Mule ESB を背後で支える企業 MuleSource でソフトウェアの設計を担当し、オープンソースの Web サービスや SOA ソリューションの構築サポートを中心とした業務を同社で行なっている。Web サービスフレームワーク Apache CXF の共同創始者であり、XFire、SXC、Jettison などさまざまなプロジェクトの創始者でもある。可能なかぎり、ほかのプロジェクトにも参加している。

Arjen Poutsma 氏は、エンタープライズアプリケーションの設計管理者であり、Spring Web サービスの創始者、プロジェクトリーダーでもある。Spring プロジェクトは、文書駆動の Web サービスの開発を容易にすることを目的としたものである。Spring プロジェクト以外にも、XFire、NEO など、さまざまなオープンソースプロジェクトにも寄与している。2005 年の初めから、オランダの Interface21（Spring を背後で支える企業）のコンサルタントも務めている。

Thomas Diesler 氏は、JBoss で Web サービスプロジェクトのリーダーを務め、技術担当役員として、JBoss の技術的な方向性の設定を全般的にサポートしている。JCP のメンバーとして、さまざまな Web サービスの仕様（JAX-WS など）の策定をサポートした。

カワグチ コウスケ 氏は、Sun Microsystems の技術者として、2001 年から XML 言語や XML スキーマ言語に取り組んでいる。また、RELAX NG や W3C XML Schema の仕様策定作業、JAXB や JAXP といった関連 Java アーチファクトの実装などにも携わってきた。Java Web サービスや XML コミュニティの最初のリーダーとして、java.net で積極的に活動している。

パート I: 概要

設計目標

設計目標の項目としては、拡張性、モジュール性、パフォーマンスなど、すべてのスタックに共通するものもある。Axis2 は、AXIOM と呼ばれる XML オブジェクトモデルを基盤に設計されている。AXIOM は、ストリーミングとツリーベースの電子通信を組み合わせたものであり、プラガブルデータバインディングのサポートを実現するものである。CXF は、プラガブルトランスポート、データバインディングをサポートしており、さらに JSON などの代替フォーマットもサポート可能である。Spring-WS も、DOM、SAX、StAX といった、XPath をベースにした API へのアクセスから JAXB、Castor、XStream などのデータバインディングアプローチにいたるまで、さまざまな XML 処理方法をサポートしている。Metro も、プラガブルトランスポートやエンコーディングの機能を有している。これらのアプローチがすべてすでに実行され、実際に予期したとおりに機能すると仮定すると、これに関して大きな違いを見つけ出すことは困難である。

Paul Fremantle 氏は、Axis2 のアーキテクチャは C でも Java でも実装できるようになっていると言う。同氏は、関連するハンドラーの集合を 1 つのユニットとして、ライブラリやデータファイルと一緒に運用できる Axis2 のモジュールコンセプトについても強調した。Dan Diephouse 氏は、CXF の最も重要な特長は組み込みが可能なことであることを示し、開発担当者の使い勝手を重視していることにも言及した。Arjen Poutsma 氏は、WS 開発の「Contract First（コントラクトファースト）」というスタイルを Spring-WS がサポートしていることを非常に強調した。Thomas Diesler 氏は、JBossWS は独自のネイティブスタックをサポートできるだけでなく、CXF や Metro など、ほかのスタックとも統合できる点を挙げた。Sun のカワグチ コウスケ氏は、Metro の設計目標として相互運用性を挙げた。

JCP 標準

JCP で XML や Web サービスを処理するための標準は数多くある。非常によく知られているものとしては、JAX-RPC、JAXM およびその後継バージョン、JAX-WS、JAXB（XML データバインディングの JCP 標準）がある。異なるフレームワーク内でこのような標準をサポートすることについては、意見が分かれる。

Axis2 チームは明確な決意の下、「最小限かつクリーンな API」の上位層として JAX-WS をサポートすることにした。この API は、フレームワークを「クール」なものにするものという独自のビジョンと一致していた。JAXB は、単独および JAX-WS との組み合わせの両方によって支えられている。Paul Fremantle 氏は、旧式であるという理由で JAX-RPC を、使用頻度が決して高くなかったという理由で JAXM を放棄する。Dan Diephouse 氏（および CXF フレームワーク）は、JAX-RPC と JAXM に関して同じ見解をしており、CXF も JAXB と JAX-WS をサポートしている。興味深い点は、Diephouse 氏は JAXB を「高速できわめて堅牢」であると考えており、これまで経験したスキーマの 99.999% を処理できるということを突き止めたということである。また、同氏自身の SXC project(source)は JAXB を大幅に高速化する方法であるとしている。JBossWS は、JAX-RPC、JAX-WS、JAXB をサポートしている。

明白な理由により、JCP 標準をサポートすることは Sun の Metro の最も重要な目標の 1 つである。カワグチ コウスケ氏が指摘しているように、Metro には JAXB と JAX-WS の両方の参照が実装されている。Spring-WS によって公表されたプログラミングモデルは、「JAX-RPC や JAX-WS といった RPC ライクなモデル」ではなく、メッセージを基盤としたプログラミングモデルであるという点で、JAXM のプログラミングモデルとよく似ていると Arjen Poutsma 氏は言う。したがって、JAXB 1 と JAXB 2 はサポートされているが、（設計に関する明確な決定として[もしくはそうであると思われる]）JAX-WS はサポートされていない。Axis2 と Spring-WS のどちらも JAX-WS を高く評価していないようであるが、JAX-WS のサポートを排除するまでに徹底しているのは Spring-WS のみである。

Web サービス標準

すべてのフレームワークが、SOAP 1.1/1.2、WSDL 1.1、MTOM/XOP、WS-Security といった一般的な各種のWeb サービス標準をサポートしていることを謳い文句としている。WSDL 2.0 をサポートしているスタックは Axis2 だけである（WSO2 の共同創始者Sanjiva Weerawarana氏 が WSDL のエディターのひとりであることを考えると、驚くことではないだろう）。Spring-WS と JBossWS 以外は、すべて WS-Addressing と WS-Reliable Messaging を実装している（Spring-WS も JBossWS も、将来のバージョンでは、WSDL 2.0 と WS-Addressing の両方をサポートする予定である）。WS-AtomicTransaction と WS-Coordinationをサポートしているスタックは Metro だけである（WS-AtomicTransaction と WS-Coordination は、J2EE/Java EE トランザクションに接続されている）。

データバインディング

データバインディング（つまり XML からオブジェクトへのマッピングとその逆）については、Web サービスや XML の実践者たちの間で、激しい議論が交わされることが多い。Arjen Poutsma 氏の見解（「データバインディング [・・・]は非常に便利なものかもしれないが、相互運用性の問題全般を受け入れるものである」）に対しては、インタビューを実施したほかの多くの開発担当者も同意している。しかし、同氏 の Spring-WS を含めたすべてのスタックは、ユーザーが要望するからという単純な理由でデータバインディングをサポートしている。ダイレクト XML アクセスもすべてのスタックがサポートしている。ダイレクト XML アクセスは通常、SAX、StAX、DOM を利用して実現しているが、これ以外にも選択肢はある。たとえば、Axis2 は AXIOM を、CXF は Aegis を、Spring-WS は XPath を利用している。

相互運用性（特に .NET/WCF との相互運用性）

Paul Fremantle 氏は、Axis2 は最も相互運用性が高いスタックの 1 つであると信じている。その理由として、Axis2 のチームが数多くの相互運用性イベントに参加していること、そして個々の標準や全側面に対応した相互運用性テストを実施していることを挙げている。Dan Diephouse 氏は、相互運用性に関するテストを 3 つの分野に分けている。3 つの分野とは、データバインディング（CXF は、実績のある JAXB や Aegis の実装に依存している）、WS-I Basic Profile、WS-* 相互運用性である。CXF ファイルは、WS-I BPへの準拠、WSS4J(Axis2 でも利用されている)といったセキュリティを実現するためのフレームワークの利用、相互運用性テストを利用することによって相互運用性を実現している。Arjen Poutsma 氏は、Spring-WS の「Contract First」手法は、相互運用性に関する問題を早期に発見し、解決するための最善の方法であると考えている。カワグチ コウスケ氏によると、Sun の Metro プロジェクトにおいて経営陣が非常に注目した話題の 1 つは、マクロソフト製品との相互運用性であったとのことである。Thomas Diesler 氏によると、JBossWS の開発担当者も相互運用性のイベントに参加したとのことである。

REST のサポート

スタックが REST をサポートしているかどうかという質問に対してあたふたする開発担当者はいなかったが、回答は担当者によって大きく異なっていた。Paul Fremantle 氏によると、Axis2 は シンプルな XML over HTTP シナリオ（一般的には RESTful ではない）と WSDL 2.0 の HTTP バインディングによる「本当の」REST の両方をサポートしているとのことである。Axis2 がまだサポートしていない分野はハイパーメディアである（個人的には、このような主張に対しては懐疑的になっている。WSDL 2 は現在でも操作という概念を基盤としており、私の見解では、これは REST にとってはいまいましいことのように思えるからである）。Dan Diephouse 氏は、CXF は POX（Plain XML over HTTP）と REST の両方をサポートしていると言う。後者はコメントによって実現されており、JSR 311 のアプローチと似ている。Arjen Poutsma 氏は、REST は SOAP、WS-*、POX に取って代わるものとしておもしろい存在であることを認めたが、Spring-WS はまだ REST をサポートしていない。将来 Spring-WS が REST をサポートすることになれば、Spring Web フレームワークを基盤としたものになるだろう。カワグチ コウスケ氏は、REST のファンであるとはっきり言ったが、REST をサポートすることは Metro の範囲外のことであると考えており、Sun の JSR 311 の実装である Jerseyについて言及した。Thomas Diesler 氏は、JBossWS における REST のサポートに関する質問を受けた際、Metro について言及したことは非常に興味深いことである。

フレームワークの成熟度

驚くことではないが、すべての開発担当者が、自社のフレームワークの成熟度と生産容易性の高さを主張する。Axis2 と CXF はほかの数多くオープンソースプロジェクトでも使われている。Axis2 のほうがその傾向は強い（IBM WebSphere など、一部の市販製品でも使われている）。Arjen Poutsma 氏によると、Spring-WS の バージョン 1.0 を開発するのに 2 年の歳月を要した理由は、Interface 21 の品質基準が高かったからであるという。カワグチ コウスケ氏（Sun の Metro）も Dan Diephouse 氏（CFX）も、それぞれ JWSDP と XFire をルーツとする自社のフレームワークの歴史について言及した。Thomas Diesler 氏は、調査によって JBoss の顧客の 60% 以上が JBossWS を使っていることが判明したことに言及した。Metro のコンポーネントを Java 6 JDK に組み込むことによって、最も幅広くインストールされたツールキットになるとカワグチ氏は断言する。

結論

さまざまなスタック開発担当者の回答を単に眺めるだけで明確な助言を導き出すことは困難である。少なくとも目標に関しては、違いよりも共通点のほうが絶対に多いと思われる。つまり、目標において共通する項目とは、効率とパフォーマンス、拡張性とプラガビリティ、デベロッパーの選択である。Axis2 と Metro は、CXF、Spring-WS、JBossWS よりも多くの WS-* 標準をサポートしている。Axis2 では、「古典的な」WS-* スタイルや REST スタイルを統一化しようとしているが、ほかのスタックでは、別のプログラミングモデルでサポートするか、まったくサポートしないかのどちらかである。間違いなく、JCP 標準の影響を最も強く受けているのは Metro である。

これを幸運ととらえるのか不運ととらえるのかは別にして、Java WS コミュニティは今後しばらくの間は、選択を迫られ続けられることになりそうである。

パート II: 詳細

以下に、私が投じた質問の原文とそれに対するフレームワーク担当者の回答を示す。

(1) 「貴社」のフレームワークの主な設計目標について教えてください。主な強みと他に例をみない特長は何だと思いますか。

Paul Fremantle 氏 (Axis2): Axis2 の第一の設計目標は、XML を基盤としたクリーンな設計のフレームワーク、非常にパフォーマンス性が高く、さまざまな WS-* プロトコルを容易にサポートできるような拡張性を備えたフレームワークを構築することでした。XML を非常に重視した設計を採択することが 1 つの目標でした。つまり、ほかの WS スタックとは異なり、Axis2 のアーキテクチャでは、できるだけすばやくオブジェクトに変換しなければならないやっかいなものとして XML を処理しないということです。

もっと正確に言うと、Axis2 では実行対象の自然のデータモデルとして XML が処理され、データバインディングを最良のオープンソースプロジェクトに「外注」することができます。プラガブルデータバインディングとは、JAXB、XmlBeans、独自のシンプルなモデル（ADB）、すべてのサードパーティ製のパッケージを処理できるということです。

AXIOM、つまり当社の XML API によって、信じられないくらい高速で柔軟な（ストリーミングとツリーベースを組み合わせた）メッセージ処理が実現します。

当社の「モジュール」アーキテクチャは、Axis1 のハンドラーベースのモデルやほかのシステムを大幅に向上します。関連するハンドラーの集合を単一のユニットとして、ライブラリやデータファイルと一緒に運用することができるからです。モジュール制約システムによって、手動でハンドラー管理する必要がなくなります。モジュールは、ユーザー設定またはポリシー処理によって連結されます。そして、ディストリビューションは新しいファイルを取り入れて、「裸」の状態から「WS-* 完全対応」の状態に変わることができます。

サービスもモジュールも、アーカイブファイルや展開ディレクトリとして簡単に利用できるようになります。構成と制御は、「範囲付き」コンテキストモデルによって強化されています。設定は、メッセージ、操作、サービス、セッション、システムから全体として生じ、きわめて簡単に処理できます。

当社のプラガブルバックエンドは、JavaScript、EJB、データベースといった実装に対応したサービスアダプターを簡単に実装できることを意味します。

Java と C のどちらでも実装できるようなアーキテクチャを設計したことも重要な設計ポイントです。私たちが知るかぎりでは、ネイティブ C を完全に実装しているのは当社だけです。すでに、C スタックの PHP バインディングは完了しており、現在は Perl と Ruby のバインディングに取り組んでいます。また、Python のバインディングも行なう予定です。.

Dan Diephouse 氏 (CXF): まず、Apache プロジェクトとして、私たちはコミュニティモデルをベースとしています。つまり、このプロジェクトに携わっているすべての開発担当者や組織の見解を私が代弁することはできないということです。したがって、これから話すことは私個人の意見です。

特に順番が決まっているわけではありませんが、私たちのフレームワークでは、以下のことを目標としています。:

Web サービス標準のサポート（ここでは、Web サービス標準とは SOAP/WS-* を意味します）。コメントを必要としない単純なコードファーストサービスから WSDL First サービスにいたるまで、JAX-WS API プロバイダーや Dispatch API に対するさまざまなサービス開発シナリオをサポートしています。

人間工学: 私たちは人間工学に対して完全ではありませんが、CXF をできるだけ使いやすいものにしようと努力しています。当社の API は、単純な用途を簡単なものにし、難しい用途を可能にするように設計されています。また、Maven や Ant のプラグインなど、各種のすばらしいツールの作成にも取り組みました。

組み込み性: CXF は、アプリケーションに組み込むコンポーネントとして設計されています。対象となるアプリケーションは、自分が使っているビジネスアプリケーション、ESB、アプリケーションサーバーのいずれでもかまいません。一般的に使われているものとしては、Mule、ServiceMix、Geronimo、JBossWS などが好例です。

Spring の統合: 当社の Spring 統合によって、クライアント、サーバー、ApplicationContext 内のトランスポートを簡単に設定できるようになります。

パフォーマンス: CXF の SOAP/XML の部分は、ストリーミング XML メッセージモデルをベースにしており、これによって超高速な XML 処理とメモリーの低消費を実現しています。

柔軟性と拡張性: CXF が誕生した理由の 1 つとして、非常に柔軟で拡張性が高いフレームワークを必要としていたということが挙げられます。新しいトランスポートを簡単に記述することができます。さまざまなバインディングをあとからサポートすることができます。私たちは、JSON や Corba といった非 XML フォーマットをサポートしています。CXF は、プラガビリティと拡張性に非常に優れています。

Arjen Poutsma 氏 (Spring-WS): Spring Web サービスの重要な設計目標は、「ベストプラクティスを簡単なプラクティスにすること」です。Contract First の運用（つまり、WSDL と XSD から始めること）は、従来から厄介な問題でした。Spring Web サービスは、XSD スキーマから WSDL を生成するなどの方法によって、この問題を簡単にすることを目的としています。

Spring-WS のもう 1 つのユニークな特徴は選択性です。これは、Spring シリーズのすべての製品に共通する特徴です。受信する XML メッセージを好きな方法で処理することができます。DOM、JDOM、dom4j、XOM、SAX、StAX といった低レベルの API を使っても、XPath 表現を使ってもかまいません。また、JAXB 1/2、Castor、XMLBeans、JiBX、XStream など、サポートされている XML マーシャリングメカニズムを使うことも可能です。

Thomas Diesler 氏 (JBossWS): JBossWS は、jboss アプリケーションサーバー上のプラガブル Web サービススタックに対応したフレームワークです。現在は、当社のネイティブスタック、Sun Metro、Apache CXF をサポートしています。こちら(source)を参照してください。

Kohsuke Kawaguchi 氏 (Metro): Metro の重要な設計目標の 1 つとして、パフォーマンスが挙げられます。Web 分散テクノロジー（特に、CORBA、JAX-RPC 1.0、JAXB 1.0）の最初のバージョンをすでに完了しているので、これらの製品の速度を低下させる要因とその対処方法については、身をもって知っていました。Metro の設計には、このようなノウハウや経験が盛り込まれており、これが成果だと思います(source)。パフォーマンス面の目標のもう 1 つの側面は、API から本当に最大の成果を上げる必要がある数少ない人たち（一般的には、開発担当者）に、別の独自開発 API を提供することです。これの好例は、当社の非同期実装でしょう。一般的な開発担当者にはそれほど簡単なことではありませんが、OpenESB に携わっている開発担当者であれば、非同期実装を利用してすばらしい拡張性を実現できます。

Metro のもう 1 つの設計目標は拡張性です。この分野においても、私たちは前世代のテクノロジーで経験を積んでいるので、どのような場所で付加的な抽象化が役に立つのかを知っていました。これは、トランスポートやエンコーディング抽象化なども含みます。私たちは抽象化を利用して、FastInfoset(source) や JSON のサポートを実現しました。このようなサポートは、Metro だけでなく、JMS、SMTP、in-JVM ローカルトランスポートなど、さまざまなトランスポートの適用範囲を広げます。さまざまな場所で、独自の抽象を設計することによって、パフォーマンスの向上を促進することもできました。このような拡張性は、私たちが数多くの WS-* スペックをモジュラー方式で実装する際のキーポイントとなるものでした。

相互運用性も重要な目標です。これも実際には、設計作業というよりも、困難で念入りなテスト作業に関係するものです。私たちはさまざまなベンダーと一緒に数多くの相互運用性セミナーを行ない、自社の技術者や Microsoft の技術者と定期的にミーティングを開いてさまざまな問題について話し合いました。また、Microsoft の社員を JavaOne の基調方針の発表会に招待し、当社の相互運用性を示すこともしました。私たちは、相互運用性テストを毎夜実施し、結果をモニターしています。私たちは相互運用性に対して、ここまで真剣に取り組んでいます。

大切なことを 1 つ言い忘れていました。使い勝手も私たちの重要な目標です。これも、設計作業というよりも、細かい点への注意に関係したものです。生産性が低下すると、一部の問題に対処するのが困難になることが多いと感じています。たとえば、特定の問題の解決策を求めて何時間も Google で検索を行なったことがある人はどれくらいいるでしょうか。そこで、私たちは優れたエラー診断とレポートを行なうことに多大な努力を注ぎ、デバッグとログ記録の切り替えを設置することによって、現在発生していることなどをユーザーや当社が理解できるようにしました。使い勝手のもう 1 つの柱は、優れたユーザーサポート経験とマニュアルです。複数のチャネルを利用した Metro の有料サポートを提供しています。

これら 1 つ 1 つが他に例をみないものであるかどうかはわかりませんが、それが組み合わされることによって、Metro が堅固な Web サービススタックになっていると思います。

(2) JAX-WS, JAX-RPC, JAXM, JAXB といった JCP 標準について、またフレームワークがそのような標準をサポートすることについてどのように考えていますか。サポートしている、またはサポートしていない理由を教えてください。

Paul Fremantle 氏 (Axis2): Axis2 は最初から、最低限のクリーンな API を組み込んだ設計となっていました。この API は、私たちのフレームワークをクールにする特殊なものを実際に利用します。具体的には、範囲付きコンテキスト、AXIOM ストリーミング XML モデル、モジュールを基盤とした拡張性などです。Java 1.4 との互換性も確保したいと考えていました。また、TCK 認可に関する速度低下や遅延に関しても多少の経験がありました。そこで、JAX-WS（1.5 が必要）をサポートすることにしましたが、ベースの上位のプラグイン層としてサポートすることとしました。また、JAXB についても、単独または JAX-WS との併用という形で、プラガブルデータバインディングとして完全にサポートしています。これによって、両方の標準をサポートでき、独自の API を別個に進展させることができます。JAX-RPC にはサポートする価値がないと判断しました。JAX-RPC は JAX-WS に取って変わられ、JAXM はほとんど使われていなかったからです。JVM が単に Java だけのものではないことも理解しています。私たちはすでに、JavaScript サービスのサポートに多大な労力を費やしており、JRuby や Groovy など、ほかの JVM 言語へのバインディングにも取り組むつもりです。

Dan Diephouse 氏 (CXF): JAX-WS: JAX-WS 2.0 標準をサポートしており、現在は 2.1 標準の実装作業に追われています。JAX-WS はきわめて重要だと思いますが、その理由は 2 つあります。1 つ目の理由は、Web サービスやクライアントを比較的簡単に構築できるからです。2 つ目の理由は、標準であるため、開発担当者が使い方に関する知識を蓄積し、膨大な知識を有しているからです。つまり、開発担当者は、自社開発の API や新しいフレームワークの（多くの）入出力を覚えるのに時間を費やす必要がないということです。

JAXB: JAXB も重要な JCP 標準です。同じ理由で、JAX-WS も重要です。JAXB によって、サービスの構築が容易になるだけでなく、使い方に関しても膨大な知識ベースがあります。おまけの特典として、現場で唯一の JAXB 実装は非常に優れたものです。高速なだけでなく非常に堅牢で、これまでに経験したスキーマの 99.999% を処理できます。この最後のポイントについては、おそらく XMLBeans を除くほかのどのフレームワークと比べても、JAXB が勝っています。

ただし、JAXB には厄介な問題があることも事実です。一般的には jaxb.index ファイルを作成する必要があります。JAXB は、デフォルトでデフォルトのネーム空間に要素を作成し、本来可能であるべき速度を実現していません。最後のポイントについては、JAXB Bean にコンパイル済みのリーダーやライターを提供する　SXC (http://sxc.codehaus.org) プロジェクトでこの問題に取り組みました。これによって、JAXB に大幅なパフォーマンスの向上がもたらされます。

JAX-RPC: JAX-RPC はサポートしていません。新しいサービスを開発する場合には、JAX-RPC は時代遅れの標準であり、ほとんど使われていません。旧式のフレームワークからの移行を容易にするために、JAX-RPC をサポートすべきかどうかについて議論を交わしましたが、当社サイドで膨大な作業が必要になるのに対して、取るに足らないメリットしか得られません。

JAXM: JAXM もサポートしていません。JAXM は、現在ではほとんど誰も使っていない旧式の標準です。また、現在では、JAXM は JAX-WSに取って代わられたようです。

Arjen Poutsma 氏 (Spring-WS): Spring Web サービスによって実現するプログラミングモデルは、JAXM のプログラミングモデルと非常によく似ています。つまり、JAX-RPC や JAX-WS といった RPC ライクなモデルではなく、メッセージベースのプログラミングモデルであるということです。さらに、Spring-WS は SAAJ（バージョン 1.4 から J2EE に組み込まれている SOAP メッセージ抽象化）をサポートしていますが、開発担当者がより使いやすいものになっています。たとえば、SAAJ が投入するチェック済みの SOAPException は、ランタイム例外にラップされます。

最後に、JAXB 1 と 2 は、オブジェクト・XML マッピング抽象化がサポートしています。

Thomas Diesler 氏　(JBossWS): 私たちは、JAX-WS, JAX-RPC, JAXB をサポートしています。JAX-WS は JAXM に取って代わるものであるというのが私たちの見解です。したがって、JAXM はサポートしていません。

Kohsuke Kawaguchi 氏 (Metro): 一般的には、単なる Web サービスよりも適用範囲が広いため、Metro は個別に利用できます。個別に利用できる Metro としては、JAXB RI, JAX-WS RI, and SAAJ RI などがあります。JCP の用語に詳しくない人のために説明すると、RI 状態とは、JCP スペックの終了基準の 1 つとして使われているということであり、すべての適合性テスト（TCK と呼ばれる）に合格しないと私たちは出荷できません。通常は、このプロセスによってRI が最も適合したスペック実装になります。したがって、ご存知のように、Metro では互換性を非常に重視しています。私たちは、TCK テストも少なくとも毎夜実施していますが、場合によっては連続的にテストを行ない、適合性退化がないかどうかをチェックします。したがって、私たちにとって、これは開発プロセスの一部であり、単に発売サイクルの最終段階で実施することではないのです。

ほかの Web サービスのツールキットの中には、当社ほど JCP 標準を重視していないものもありますが、さまざまな点で互換性はユーザーにとってメリットが大きいものであると思います。たとえば、互換性によって同等のフィールドで競合することができます。また、ベンダーのロックインを回避することもできます（したがって、あるツールキットを購入し、それに固執するリスクを低減します）。しかし、私にとってもっと重要なことは、大規模なユーザーベースのおかげで、より大規模なエコシステムが生まれるということです。大規模なエコシステムによって、ほかの方法では不可能な多くのことが経済的に実現可能になります。これは、本や記事からトレーニングやツールにいたるまで、すべてのことが対象になります。

私たちは現在でも、さまざまな場所で自社開発の API を提供していますが、このような理由から、意味があるのであれば、標準にこだわり続けていきます。

(3) どのような Web サービス標準をサポートしていますか。また、現在サポートしていない標準がサポートされていない理由を教えてください（現在サポートしていない標準は将来サポートするつもりである。まったくその予定はない。など）

Paul Fremantle 氏 (Axis2): Axis2 自体は主に XML や SOAP メッセージの処理に関するものであり、SOAP 1.1 と SOAP 1.2 をサポートしています。また、さまざまなトランスポート（非ブロッキング IO、JMS、TCP SMTP/POP、XMPP を含む HTTP/S）を実装しています。MTOM は、WSDL 1.1 と 2.0、WS-Addressing、WS-Policy と同様に、即座に利用できる状態でサポートされています。また、FastInfoset や JSON などのプラガブルエンコーディングもサポートしています。プラガビリティによって、上位のスペックもすべてサポートされており、すべてのスペックが必要とされない組み込みアプリケーションの場合、これは特に重要なことだと考えています。私たちは、WS-Security（1.0/1.1）、WS-SecureConversation and Trust、WS-ReliableMessaging (1.0/1.1)、WS-Transactions、WS-MetaDataExchange、WS-Transfer、BPEL (Apache Ode)、WS-Eventing、WS-RF/Notification (Apache Muse) のプラグインを用意しています。ほかのスペックのサポートについては、必要に応じて当社のチームまたは他社が簡単に追加することができます。

Dan Diephouse (CXF): 私たちは、:

• SOAP 1.1, 1.2
• WSDL 1.1
• WS-I BasicProfile 1.1
• WS-Addressing 2004/08, 1.0
• WS-Policy
• WS-ReliableMessaging 1.0
• WS-Security 1.0, 1.1

WS-SecureConversation と WS-Trust も近いうちにサポートしたいと考えています。

もちろん、世の中にはほかにも多くの仕様があります。その多くは、重要性が低かったり価値がなかったり（すべてのものがそうだと思われるかもしれませんが、それはまた別の話です）するため、ユーザーから要望があったものを重視しました。重要な仕様がポートされていないと思われる方は、私たちにメール(http://incubator.apache.org/cxf/mailing-lists.html) を送ってください。将来のバージョンでサポートするかどうかを検討します。

Arjen Poutsma 氏 (Spring-WS): Web サービスは主に相互運用性に関するものでなければならないことは明らかですが、これらの驚くほど多くの仕様には、相互運用性がまったくありません。つまり、Java やおそらく .NET による実装はあっても、Ruby、Python、Perl などの記述言語による実装はないということです。したがって、WS-* 仕様の実装については、きわめて現実的な方法を採用することに努め、価値を付加するものやユーザーから十分な要望があるものだけを実装します。

つまり、Spring-WS は現在、SOAP 1.1 と 1.2、WSDL 1.1、MTOM をサポートしており、Spring Security と融合する WS-Security を実装しているということです。次期バージョンの 1.1 では、WS-Addressing と WSDL 2.0 を実装するつもりです。

Thomas Diesler 氏 (JBossWS): こちら(source)を参照してください。Metro や CXF との統合によって、さらに多くの WS-* 標準をサポートするつもりです。また、現在ネイティブな WS-RM のサポートに取り組んでいます。

カワグチ コウスケ氏 (Metro):
Web サービスに関して私が大嫌いなことは、あまりにも多くの仕様が絡んでいるということです。しかし、とにかく、基本的で簡単なものから始めることにします。私たちは、 ベースラインとして WS-I Basic Profile 1.1 を使っています。したがって、私たちが発行、消費する WSDL は、WS-I BP に準拠しています。大容量のバイナリデータや添付ファイルを処理するために、WS-I attachments profile 1.0 と MTOM/XOP をサポートしています。また、WS-Addressing 1.0 も全面的にサポートしています。WS-Addressing を利用した改良型のプログラミングモデルも提供しています。Metro には、WS-MetadataExchange のサポートや WS-Policy も組み込まれています。これは、ある程度はトランスペアレントに機能しますが、それでもなお社員をトランスペアレントに作業させるためには重要な要素です。

Metro では、WS-ReliableMessaging をサポートすることによって、媒介物がかかわっている場合に、確実に順番どおりにメッセージが配信されます。Metro は、WS-AtomicTransaction とWS-Coordination をサポートしています。これらは JavaEE トランザクションとつながっているため、これを使うことによって、複数の JavaEE システムや .NET システム間で、これらの接続上のプロトコルの面倒な詳細を知らなくても、宣言分散トランザクションを実行することができます。

セキュリティ面について言えば、Metro には WS-Security、WS-Trust、WS-SecureConversation が実装されています。これらの仕様は、シンプルなメッセージレベルのセキュリティから、さまざまな組織にまたがるようなもっと複雑な統合認証にいたるまで、さまざまなニーズに対応しています。すべてのセキュリティ機能、トランザクション機能、信頼性機能は、当社が多大なリソースを投入した WSIT（AKA Tango プロジェクト）の名前の下で実行されています。

当社は、これらの仕様をすべて実装し、それはすべて出来合いのものですが、特別な注意を払っていることもいくつかあります。まず、NetBeans チームと綿密に連携しているので、付随する NetBeans プラグインが常にあり、優れた GUI でこれらのモジュールを設定することができます。したがって、基盤となるシステムがこれらのスペックをどのように設定しているのかに関して、やっかいな詳細を知っている必要はありません。次に、このすべての仕組みは従量制モデルです。つまり、使用しない機能については、パフォーマンス、複雑性、認識といった犠牲を払わなくてもよいということです。

最後に、モジュール性が同じであれば、ほかの WS-* スペックや将来の WS-* スペックも実装できます。ユーザーが希望するのであれば、取り組む価値はあります。このリストが適切でないと思われる場合は、どのような仕様をサポートしてほしいのか教えてください。

(4) データバインディングおよび多くの人がデータバインディングと関連性があると思っている問題についてどのように考えていますか。XML メッセージへのネイティブアクセスと XML やオブジェクトのマッピングのいずれか、または両方をサポートしていますか。

Paul Fremantle 氏 (Axis2): Axis2 は、メッセージに対するネイティブアクセスを含めた柔軟性の高いデータバインディングモデルをサポートできることを考慮して設計されました。JAXB、XMLBeans、JIBX、ADB（組み込みデータバインディング）など、さまざまなデータバインディングツールキットをサポートしており、特にツールキットが StAX 標準をサポートしている場合は、任意のデータバインディングツールキットに合わせて手法を拡張することができます。ユーザーが XML へのダイレクトアクセスを選んだ場合、Axis2 ではツリー風のモデル（Axiom）と StAX ストリームが利用でき、シンプルなユーティリティクラスによって、DOM や SAX のインターフェイスも利用できます。データバインディングの用途は非常に重要であると私たちは考えています。また、Java モデルで Web サービスを利用したい場合は、Java コーダーにその機能が備わっている必要があり、そして XML に対して高速で効率的なアクセスを行ないたい場合は、XML コーダーにその機能が備わっている必要があると考えています。Axis2 で Java 派と XML 派の両方を成功させることができるすばらしい中庸を私たちは見つけたと思っています。

Dan Diephouse 氏 (CXF): データバインディングとは、単に XML を抽出して POJO を生成することであると考えられていますが、私はこの定義を拡大して、「元の XML 情報セットを隠したり、削除したりするすべてのタイプの処理」と定義したいと思います。アプリケーションの 99.999% はこのような処理を行なう必要があるでしょう。JAXB を使っているかどうか、手動で XML DOM にアクセスするかどうか、XPath のようなものを使っているかどうかに関係なく、データを抽出して、そのデータに何らかのビジネスロジックを施す必要があると思います。このような処理を行なわなくてもよいアプリケーションは、唯一のデータモデルとして最終的には XML を処理するアプリケーションだけです。

このような見方をすると、「使い勝手と xml 情報セットの維持の間のバランスは、どのような状態がベストなのか」という質問に対する答えを、データバインディングの選択基準にすることができます。その答えは、「状況によって異なる」です。ほとんどのアプリケーションの場合、ずばり JAXB が最適だと私は感じています。JAXB は、非常にシンプルな POJO を作成するので、きわめて簡単に使えます。日常的な XML 処理作業やエラーが発生しやすい XML 処理作業をユーザーから見えなくします。すべてのスキーマとまではいかないまでも、ほとんどのスキーマを処理できます。そして、適切なスキーマバージョン作成慣習に従えば、契約に準拠した、非常に堅牢で長期間にわたって有効なサービスを作ることができます。

それでも私たちは、ほかにもいくつかのデータバインディング方法を実際にサポートしています。「StAX データバインディング」によって、生の XML ストリームにアクセスすることも可能です。XFire から受け継いだ Aegis データバインディングもあり、ほぼすべてのコードからスキーマや WSDL を簡単に構築できるようになります。Map や java.sql.Date といった代替データ型の多くをサポートしています。JAX-WS プロバイダーをサポートしているので、XML メッセージを Source オブジェクトとして処理することができます。次期バージョンでは、XMLBeans や JiBX もサポートしたいと思っています。.

Arjen Poutsma 氏 (Spring-WS): データバインディング（オブジェクト・XML マッピングとも呼ばれており、私はこの呼称のほうが好きです）は、とても便利なものかもしれませんが、相互運用性に関するさまざまな問題を受け入れるものでもあります。実情では、Java 言語と XML 言語はまったく別のものであり、この 2 つの言語の間で変換が行なわれると、何らかの問題が発生する可能性があります。たとえば、XSD の日付と java.util.Calendar との違いについて考えてみます。一般的には、「2007-09-14」という XSD の日付は、現地時間帯の 9 月 14 日深夜 0 時を表す Calendar に変換されます。この Calendar を XML に再変換すると、最初の SXD 日付ではなく、おそらく dateTime になります。

しかし、すでに申し上げたように、OXM がとても便利かもしれません。したがって、Spring-WS では、JAXB 1 と 2、Castor、XMLBeans、JibX、XStream という形式で OXM をサポートしていますが、必要に応じて生の XML メッセージへのアクセスも可能です。

Thomas Diesler 氏 (JBossWS): 私たちは、SOAP コンテンツ要素という考え方をしています。これは、データバインディングに関係するメッセージ部分を抽象的に表示することです。クライアントコードは、XML (DOM)、Java (JAXB) または SAAJ としてコンテンツをネイティブに取得することができます。

カワグチ コウスケ氏 (Metro): さまざまな状況においてデータバインディングが役に立つという意見に異議を唱える人は誰もいないと思います。したがって、Metro にももちろん、データバインディングソリューションが備わっています。同様に、そのほかのさまざまな状況において、生の情報セットにアクセスできることの便利さを否定する人も誰もいないと思います。したがって、Metro ではこれももちろん提供しています。それでは、まずデータバイディングについて話します。Metro では、JAXB をデータバインディングソリューションとして使っています。JAXB は、今日にいたるまで、唯一のコメント駆動型の POJO データバイディングソリューションです。コメントを使うことによって、1 つのデータバインディングソリューションで、Contract First のデータバイディングと Code First のデータバインディングの両方をサポートすることができます。これは、すべてのデータバインディング技術に当てはまることではありません。JAXB に的を絞ることによって、プロジェクトのリソースを効率的に使うことができます。しかし、データバインディング技術ごとに、開発担当者やユーザーをさまざまなサイロに分割する方法では、そうはいきません。

現在、JAXB などのデータバインディング技術の問題点は、XML 情報セットにアクセスできなくなるということです。これは、状況によってはすばらしい機能になりますが、処理対象のコードが階層構造になっている場合、Web サービスが実際は単なるトランスポート層として使われている場合、ドメインに固有の独自のデータバインディング手法がある場合などは問題になります。

したがって、このような問題を解決するために、Metro では、JAX-WS を使って XML 情報セットにアクセスできるようにしています。SOAP メッセージ全体にアクセスすることも、ペイロード部分のみにアクセスすることもできます（後者は、Metro に別のデータバインディング技術をプラグする場合に便利です）。SAAJ を使って、DOM のようなツリー構造でアクセスしたり、SAX イベントとしてアクセスしたりできます。また、StAX パーサーでアクセスすることも可能です。

生の情報セットへのアクセスについては、当社の内部 SOAP メッセージ抽象化をユーザーに公表することにも取り組んでいます。したがって、さらに便利で効率的な方法で SOAP メッセージにアクセスができます。

ほかにも触れておかなければならないことがあります。それは、ハンドラーと呼ばれるメカニズムで、両方を組み合わせることができるようにしているということです。つまり、情報セットとしてまず SOAP メッセージにアクセスして、いくつかの作業を行ない、そのあとでデータバインディングを行なってほかのことをすることができるということです。

(5) ほかの WS 製品との相互運用性はどの程度サポートしていますか。特に .NET/WCF との相互運用性について教えてください。

Paul Fremantle 氏 (Axis2): 当社のチームは、W3C、OASIS、Microsoft の相互運用性イベントに参加し、相互運用性テストにおいてすばらしい結果を残していることに誇りを感じました。私たちは、当社のバグを修正したり、ほかの製品の発売済みのバージョンのバグを修正したりすることによって、相互運用性に関するすべての問題をできるだけ迅速に解決しようとしています。特定の標準に対する個々の相互運用性だけでなく、Binary での Secure Reliable（MTOM、WSRM、WSSecurity を一緒に）を中心に、いくつかの特定のプロファイルに関する .NET/WCF との相互運用性についても一生懸命取り組んできました。当社のテスト結果から、私たちは最も相互運用性が高いスタックの 1 つであると思っています。

Dan Diephouse 氏 (CXF): ユーザーにとって重要な相互運用性テストには、以下の 3 つのレベルがあります。:

データバインディング: JAXB と Aegis の実装については、長い年月をかけて、.NET/WCF に対するテストを十分に実施してきました。どちらも 4 年くらい経過していると思います。.

BasicProfile/SOAP: このレベルでは、BasicProfile 標準で定めている表明とベストプラクティスへの準拠を徹底することに取り組んでいます。このガイドラインに従うと、.NET/WCF など、ほかのフレームワークとの相互運用性が十分に保証されます。しかし、私たちは、ATOM のような困難な相互運用性分野を中心に、.NET/WCF に対する私たちのサービスに対してもテストを行ないます。

WS-: それぞれの WS- 仕様には、固有の特質があります。したがって、これから話す内容は、仕様、年数、複雑さによって異なってきます。たとえば、WS-Security の場合、Apache WSS4J フレームワークを使っています。Apache WSS4J フレームワークには、.NET との相互運用性に関して、広範囲なテストが行なわれています。これは、コミュニティや .NET を使って製品を構築したさまざまな組織が行なっています。コミュニティのメンバー、特に IONA も、発売サイクルにおいて、WCF を使って統合テストを実施しています。このテストは、WS-* レベルだけでなく、すべての下位レベルに対しても行なわれます。

Arjen Poutsma 氏 (Spring-WS): Spring Web サービスの Contract First アプローチの利点の 1 つとして、ほかのプラットフォームとの相互運用性に関する問題を、サービスの開発担当者が直接解決できるということが挙げられます。つまり、SOAP エンジンには .NET との相互運用性がないので、ほかの構造体の代わりに 1 つの特定の XSD 構造体を使うように、SOAP エンジンを「説得」する必要がないということです。もっと正確に言うと、相互運用が可能な構造体を直接選べるということです。

このアプローチは、Spring-WS に同梱されているサンプルアプリケーションで示されています。これらのサンプルから、Microsoft .NET 1.1、WSE 2.0、WCF と相互運用性があることがわかります。

Thomas Diesler 氏 (JBossWS): 定期的に、MSFT 相互運用性セミナーに出席し、多くの相互運用エンドポイントを積極的に維持しています(http://jbossws.demo.jboss.com:8080/interop/ and http://jbossws.demo.jboss.com:8080/jbossws/services)

カワグチ コウスケ氏(Metro):
Metro には、.NET との相互運用性を実現することのみに専念している専任スタッフで構成された大規模なチームがあります。すでに述べたように、相互運用性とは、正しく設計することだけで実現できるものではないのです。むしろ、テスト担当者の根気強く熱心な努力によって実現するものです。もう一度言います。作業のほとんどは、WSIT への取り組みの一環として行なわれるものであり、Metro にとって必要不可欠なものになっています。

したがって、WS-* モジュールごとに一連のテストを設定し、Microsoft のエンドポイントを使って、相互運用性テストを常時行なっています。このテストを必ず毎夜行なうことによって、退行が起こらないようにしています。そして、これが私たちの発売基準の 1 つになっています。すべてのテストに合格するまで、Metro は出荷されません。

私たちは、Microsoft ときわめて綿密に連携してきました。毎週、マネージャーレベルのミーティングを行なって、さまざまな問題について話し合いました。それと平行して、技術者レベルのありとあらゆるミーティングを行ない、問題点について徹底的に議論を交わし、問題を解決しました。多くの社員が、レドモンドに何度も行き、相互運用性セミナーに参加しています。また、Microsoft 社の社員を当社の JavaOne の基本方針セッションに招き、当社の相互運用性のデモンストレーションを行ないました。

また、その他の Java ツールキットや Java 以外のツールキットの相互運用性に関連する問題にも特別な注意を払っていますし、そのような問題について、聞き漏らしたことがあるとは考えていません。また、分割入力を認めることに関しても、私たちはとても寛大な傾向にあり、自分たちが作るものに対してはより厳しい態度で臨んでいます。そうすることによって、スムーズな相互運用性の可能性も向上します。

全体としては、私たちは相互運用性を実現するために真の取り組みを行なったと言ってもよいと思います。そして、W3C や WS-I のあらゆる懸命な努力およびすべての Web サービスツールキットのおかげで、Web サービスの全体的な相互運用状況は大きく向上し、すばらしい成果を上げています。

(6) REST についてはどのように考えていますか。何らかの形で REST をサポートしていますか。

Paul Fremantle 氏 (Axis2): REST のサポートにはさまざまなレベルがあります。まず、HTTP GET や POST といった任意のトランスポート上で、開発担当者が「平易な旧式の XML」を実行できるようなシンプルなアプローチがあります。このアプローチは、そのままの状態で POJO を処理できるため、シンプルな XML/HTTP シナリオは簡単です。次に、WSDL 2.0 HTTP バインディングをフルサポートしている WS ツールキットは当社だけです。そのバインディングを利用すると、すべての RESTful サービスを完全に記述することができます。たとえば、バインディングを使って、私たちは Atom Publishing Protocol を完全に記述しました。したがって、URI の処理、URI のデータの出し入れ、すべての HTTP 操作のサポート、ペイロードのデータの出し入れといったレベルでは、現在 REST に完全に準拠しています。

REST において、私たちがまだ取り組んでいない分野が 1 つあります。それは、「アプリケーション状態のエンジンとしてのハイパーメディア」と呼ばれる分野です。つまり、リンクが記載されたメッセージの作成を処理したり、記載されたリンクを適切に処理したりするためのフレームワークは、現在時点ではサポートしていないということです。この問題（間違いなく難しい問題）については、アプリケーションの作成者に一任されています。これについては、さまざまな議論が交わされてきましたが、今後は REST 的な方向で多くの経験を積みたいと思っています。

Dan Diephouse 氏 (CXF): REST は、サービスを構築するためのすばらしい方法だと思います。アーキテクチャとして、さまざまな能力を有していますが、残念ながら、一般的には誤解されたり、まったく理解されていなかったりします。

CXF には、RESTful サービスの構築を容易にするさまざまなツールが備わっています。私たちは、XML over HTTP バインディングを行なっており、これによって SOAP の Web サービスをシンプルな平易な旧式の XML サービスに変換することができます。コメントや @HttpResource(“/foo/{bar}”) のような URI テンプレートの使用による、リソースへのサービス操作のマッピングをサポートしています。また、規約をベースとしたメカニズムもサポートしています。このメカニズムによってサービスが内視され、インテリジェントにリソースに変換されます。たとえば、getPurchaseOrder (long id) というメソッドの場合、/purchaseOrders/{id} というリソース上で、GET リクエストにインテリジェントにマッピングされます。JSR 311 の仕様に関しては、作業や議論も行なわれています。

Arjen Poutsma 氏 (Spring-WS): REST は、SOAP、WS-*、平易な旧式の XML に取って代わるものとして、おもしろい存在だと思います。テクノロジーとして実績のある HTTP を基盤としているため、WS-* スペースのさまざまな問題を解決できます。しかし、REST は SOAP と同じくらい、もしくはそれ以上に制限的だと思います。REST サービスを記述する際、どのリソースを公表するのか、リソースに対してどのデータフォーマットをサポートするのか（REST はほとんど XML ではない）、リソース上でどの HTTP メソッドをサポートするのか、そしてリソースが何を意味するのか、このような事項に関してはっきりした考えを持っている必要があります。このような考え方はすべて文書に記録する必要もあります。このような目的においては、HTTP 仕様は十分ではありません。WADL がその答えとなるのかどうかは私にはわかりません。

Spring Web サービスは、現時点では REST プログラミングモデルをサポートしていませんが、来年の初めにリリース予定のバージョン 2.0 ではサポートする予定です。REST は、SOAP や POX とは大きく異なります。たとえば、XML メッセージは常に着信しません。私たちは、HTTP リクエストから XML メッセージを作成し、それをパイプラインに発射し 3 ミリ秒後に再度解析する方法によって、REST をサポートしたくありません。この方法では、単にコストがあまりにも高くなります。その代わり、REST のサポート基盤を Spring Web フレームワークに置きます。

Thomas Diesler 氏 (JBossWS): 私たちは JSR 311(source) に積極的に参加し、Metro の統合によって REST をサポートしています。

カワグチ コウスケ氏(Metro): 個人的に、私は REST の大ファンです。私が携わっているほかのプロジェクト（Hudson など）の中には、全面的に REST をベースにしているものもあります。しかし、私が REST に関して抱えている問題は、すべての新しいテクノロジーに共通することですが、ユーザーによって REST に対する理解が異なることが多いということです。したがって、ユーザーに「REST しますか」と聞かれた場合、どのように答えるか注意する必要があります（ぴったりな例として、誰かが「自分の RESTful な ～ を実行した」と言い、それに対してほかの人が、それは REST ではないと叫んでいるのを耳にしたことがある人がどれくらいいるでしょうか）。

私たちは、REST は発展途上のテクノロジーだと考えているので、現在の REST サポート作業は、当社の姉妹プロジェクト Jersey (サイト・英語)で進めています。たとえそれが Metro の従来のプログラミングモデルからかけ離れることになるとしても、Jersey では REST を中心のコンテンツに採用しています。私は、これは正しいことだと思います。REST を論理的な結果に導いたとしても、実際には別のプログラミングモデルになってしまうからです。既存の SOAP プログラミングモデルに、REST 風の機能（URI テンプレート作成など）をいくつか断片的に付加するだけでは、うまくいきません。これは、REST の最大の魅力が SOAP の複雑性から開放されることであるユーザーにとってもすばらしい働きをします。

話を先に進めます。しかし、私たちは今後 Jersey を Metro に組み込む作業に取り込むと私は思っています。SOAP と REST のプログラミングモデルに対して、私たちがある種の統合や統一性をもたらすことができるかどうか、それともこの 2 つは実際には大きく異なっている状態のままなのかを確認することは興味深いことだと思います。

(7) 貴社のフレームワークではどのような点で成熟度が高いと言えますか。提示できるケーススタディはありますか。その成熟度に依存している市販製品やオープンソース製品はありますか。

Paul Fremantle 氏 (Axis2): Axis2 は確実に生産の準備が整っています。私たちは、定期的に浸漬テスト、メモリー消費テスト、パフォーマンステストを実施しています。このようなテストの一部は、 http://wso2.org/library/588　で紹介しています。

Axis2 は、Eclipse WebTools Project、Apache Geronimo、Apache Tuscany、Apache ODE、IBM WebSphere 6.01、SoapKnox、Apache Synapse、WSO2 Web Services Application Server、WSO2 ESB、Intalio BPMS など、数多くのフレームワークや製品で使用されています。

Dan Diephouse 氏 (CXF): CXF には、長い歴史があります。4 年前に開始された XFire や数年前に開始された Celtix にも組み込まれています。この 2 つのプロジェクトから数多くのコードが受け継がれているため、安定的で十分に練られたプロジェクトを設定するのに役立ちました。まだバグがありますが、バージョンアップを繰り返し、ユーザーの意見を注意深く聞いていきたいと考えています。7 月にバージョン 2.0 をリリースしたところですが、間もなく 2.0.2 をリリースする予定です。

これまで、いくつかのシステムに CXF が組み込まれてきました（極秘事項であるため、残念ながら詳細はお話できません）。また、CXF を組み込んだオープンソースプロジェクトも数多くあります。Mule（http://mule.codehaus.org）には、MuleSource が商業ベースでサポートしている CXF コネクターが組み込まれています。ServiceMix（http://incubator.apache.org/servicemix）にも、CXF が統合されています。これは、FUSE と呼ばれる ServiceMix/CXF をバンドリングすることによって IONA がサポートしています。Guillaume Alleon は、Groovy Web サービス（http://docs.codehaus.org/display/GROOVY/GroovyWS）プロジェクトを立ち上げました。これは、Groovy を利用してサービスを構築し、WSDL->Code 手順を使わずにサービスを呼び出せるようにするプロジェクトです。Enunciate（http://enunciate.codehaus.org）など、これ以外にも複数のプロジェクトでも、XFire から CXF への移行に追われていると思います。

Arjen Poutsma 氏 (Spring-WS): 8 月に、Spring Web Services 1.0 をリリースしました。このバージョンがリリースされる前は、多くの人が画期的な製品を使い、そのあとリリース候補製品を使っていましたが、その安定性に大いに満足していました。バージョン 1.0 をリリースするのに 2 年を要したのは、Interface21 の品質水準が高かったからです。年末には、バージョン 1.1 をリリースする予定です。このバージョンでは、ほかのトランスポート（JMS、E メールなど）もサポートされ、WS-Addressing も新たにサポートされます。Spring-WS 2.0 では、REST サービスがサポートされます。

Thomas Diesler 氏 (JBossWS): JBossWS はきわめて成熟度が高い製品であり、2 年半に渡って開発を続けています。ある調査によると、JBoss ユーザーの 60% 以上が JBossWS を使っているようです。

カワグチ コウスケ氏　(Metro): 名称を変えましたが、2001 年までさかのぼるコード日付の大部分およびServices Developer Pack（JWSDP）は変えていません。JWSDP は、2005 年の「最も優れた Web サービスおよびその関連ツール」や 2006 年 JDJ 読者大賞など、いくつかの賞を受賞しています。受賞したチームは、そのとき以来ショウを運営しているチームと基本的に同じチームです。したがって、実世界で何年も使われている実績があり、豊富な経験を有する人たちによって整備されているコードが数多くあります。Metro の心臓部である JAX-WS の仕様にも、前身の JAX-RPC を入れると、かなりの歴史があります。スタートは 2001 年ですが、この業界で 5 年は、本当に長い年月です。したがって、ベンダーやユーザーからのフィードバックに基づいて構築した、定評のあるテクノロジーです。

次に、JAXB です。私はこれまで、RI に関する多くの作業を行ない、現在は仕様に関する作業も行なっています。したがって、JAXB がユビキタスになったことについて、いろいろなことをお話できます。ここで議論したそのほかのすべての Web サービスツールキットが JAXB RI をサポートしていることが好例だと思います。当社の JAXB 2.0 以降、10 バージョン以上でそのレベルの採択をしている場合は、コードは岩のように強固になります。

成熟度に関しては、JAXB に対して実施するテストの量について話したいと思います。これは、プロジェクトをサポートする Sun のような大規模な組織を有することの強みの 1 つです。まず、Metro の各コンポーネントに対して一連のテスト（通常は、ユニットテスト、SQE テスト、TCK テストと呼ばれる 3 つのテスト）を実施します。たとえば JAXB では、1500 以上のユニットテスト、220 以上の SQE テスト、5,700 以上の TCK テストを行ないます。コンポーネントを Metro に組み込んだら、全体に対してさらにテストを行ないます。具体的には、80 種類以上のプラットフォーム構成に対して、相互運用性テスト、エンドツーエンドコンテナーテストなどを行ないます。また、Metro 専用の機器も多数有しています。JDK や GlassFish に組み込む際、彼らも Metro に対して独自のテストを実施します。

これだけの規模のテストは、1 日で実現したものではありません。長い歴史を有する私たちのプロジェクト、そして、繰り返し自動的にテストを記述、実施する専任の技術スタッフで構成された複数のチームがあればこそ実現したことです。これも、Metro のユーザーが知らないところで行なわれていることであり、高品質のソフトウェアを提供するために舞台裏で行なわれていることです。

採用に関しては、Metro はほかのさまざまプロジェクトでも使われています。Metro のサブセットは現在、GlassFish、WebLogic、WebSphere、さらに Geronimo といったほとんどのアプリケーショサーバーで使われています。Open ESB およびその市販製品 Java Composite Application Platform Suite では、トランスポートコンポーネントの 1 つとして使われています。Metro の同様のサブセットは、Sun、BEA、IBM の主要な Java6 JDK でも使われています。このことだけでも、Metro が最も広範にわたって（採用数は軽く 1 桁違う）インストールされているツールキットだと言えます。