J2EE 1.4のWebサービス最新動向

J2EE 1.4がリリースされ、JavaによるWebサービスの開発環境がほぼ完成された。本稿では2月18〜19日に開催された「Java Technology Conference 2004」から「J2SE, J2EE, J2MEを用いての実用サービス開発」と題されたセッションの内容を中心に、J2EE 1.4でのWebサービス開発のガイドラインをレポートする。（編集局）

＠IT編集局
上島 康夫
2004/2/27

主な内容 J2EE 1.4のWebサービス・アーキテクチャ JAX-RPCのサーバ・プログラミングモデル JAX-RPCのクライアント・プログラミングモデル SOAPメッセージ・ハンドラ WS-Iへの対応 Webサービスの新しい動き

　昨年末にリリースされたJ2EE 1.4はWebサービスのためのバージョンアップといわれている。その内容はどのようなものか？ JavaにおけるWebサービス・アーキテクチャの概要をまとめてみよう。

■J2EE 1.4のWebサービス・アーキテクチャ

　講演に立った米サン・マイクロシステムズ社 Javaテクノロジ・エバンジェリスト サン・シン（Sang Shin）氏は、J2EE 1.4のWebサービス・アーキテクチャはコンテナ／コンポーネント・モデルである点を強調した。サーブレットやEJBと同様に、J2EE環境で公開されるWebサービスもコンポーネントとして作成される。「Webサービスは、その内部にエンドポイント（ポート）を持ったコンポーネントである。エンドポイントとは、Webサービスを利用するクライアントに公開するサービスを指す。つまり、J2EEのWebサービスとはJ2EEコンテナ上に配置された、エンドポイントを持つコンポーネントと定義できる」（シン氏）。

　コンテナ／コンポーネント・モデルは、J2EEの経験がある読者ならおなじみだろう。Webサービスもコンポーネントとして実装されるということは、J2EEに対応したアプリケーションサーバ間で、Webサービス・アプリケーションのポータビリティが保証されるとともに、開発者は一度開発手法を身に付ければ、プラットフォームの異なる開発案件でも新たな知識を習得する必要がないというメリットをもたらす。

■JAX-RPCのサーバ・プログラミングモデル

　J2EEでは、以下の2種類のエンドポイントを定めている。

• サーブレット・ベース
• ステートレスセッションBean・ベース

　サーブレット・ベースのエンドポイントを作成するAPIとして、J2EE 1.4ではJAX-RPC 1.1が提供されている。ステートレスセッションBean・ベースでは、サーブレット・ベースに加えてEJB 2.1 APIを使用して、EJBに必要な機能を追加する。このセッションではサーブレット・ベースのJAX-RPCプログラミングモデルを中心に解説が行われた。その詳細を見ていこう。

　「JAX-RPCの主な役割は、WSDLとJavaのマッピング、XMLとJavaのマッピングを行うことである」（シン氏）。WebサービスはクライアントとエンドポイントでXMLによって記述されたSOAPメッセージを交換するわけだが、JAX-RPCを使ったプログラミングでは、XML文書を直接操作することはない。JAX-RPCがSOAPメッセージを隠ぺいしているため、DOMプログラミングなどの知識は不要である。

　シン氏はJava統合開発ツール「Sun Java Studio」を使ったデモを交えながら「JAX-RPCでの開発には、トップダウンアプローチとボトムアップアプローチがある」と紹介した。トップダウンアプローチとはあらかじめWSDLにWebサービスの内容を定義し、それに合わせたJavaプログラムを作成する。既存のWebサービスを利用するクライアント・アプリケーションを作成する場合などはトップダウンアプローチとなるだろう。ボトムアップアプローチは、あらかじめJavaプログラムを作成し、その内容を基にWSDLを生成する。こちらは、既存のWebアプリケーションをWebサービス化する場合に用いられる。

　J2EEでのWebサービス開発は、デプロイ（配置）方法がほかの環境と異なる。エンドポイントを作成するには、リモートインターフェイス（RMI）をインプリメントした「サービスインターフェイス」および「実装」「WSDL」「シリアライザ／デシリアライザ」の4つの構成物をWARファイルにパッケージ化し、アプリケーションサーバにデプロイする。Javaを使ったWebサービス開発ではApache Axisもよく利用されるが、独自のツールを使うAxisのデプロイ方法は、J2EEとは異なる点に注意が必要だ。

■JAX-RPCのクライアント・プログラミングモデル

　続いて講演を行った米サン・マイクロシステムズ社 Javaテクノロジ・エバンジェリスト ケイシー・チャン（Casey Chan）氏は、JAX-RPCによるクライアント・プログラミングには以下の3つのモデルがあると述べた。

• 静的スタブ（Static Stub）
• ダイナミック・プロキシ（Dynamic Proxy）
• DII（Dynamic Invocation Interface）

　静的スタブはリモートオブジェクトに接続するためにローカルのスタブを代理に立てる方法で、ローカルスタブはコンパイル時に生成されるため静的スタブと呼ばれる。これに対してダイナミック・プロキシは、実行時に動的に生成されるクラスを代理に立ててリモートプロシージャを呼ぶ方法だ。最後のDIIでは、ランタイムクラスを必要とせずにリモートのプロシージャを呼べる。前の2つよりもコーディングは複雑になるが、より細かな設定が可能だ。

　これらのコーディングサンプルはJWSDP 1.3（Java Web Services Developer Pack 1.3：Webサービスに必要なAPI、サンプル、ドキュメントなどが収録された開発キット）のチュートリアル（JWSDPとは別にダウンロードする）に詳しく解説されているので、詳細はそちらを参照してほしい。

■SOAPメッセージ・ハンドラ

　JAX-RPCを使ったWebサービス開発では、JavaオブジェクトでSOAPメッセージをラップしてしまうが、メッセージの検閲やログ作成、暗号化など、実際にネットワーク上を流れるSOAPメッセージを操作する必要も出てくるだろう。

　J2EEでは、SOAPメッセージ・ハンドラを使ってログ作成などの操作を実現している。SOAPメッセージ・ハンドラはステートレスなインスタンスで、JAX-RPCのリクエスト、レスポンス、例外の発生時にSOAPメッセージにアクセスできる。また、複数のハンドラをつなげるハンドラチェーンも可能だ。

　SOAPメッセージ・ハンドラに関しては、JWSDP 1.3のチュートリアルに詳しく解説されているので、詳細はそちらを参照してほしい。

■WS-Iへの対応

　WS-I（The Web Services Interoperability Organization）はWebサービスの相互運用性の向上を目指す団体で、ベンダや開発者が準拠すべき内容を定めた「Basic Profile 1.0」を2003年8月にリリースした。Basic Profile 1.0は、一連のWebサービス関連仕様の中からSOAP 1.1、WSDL 1.1、UDDI 2.0とセキュリティに関して、156の適合要求を定めている。Basic Profile 1.0の範囲内で記述されたWebサービスであれば、プログラミング言語やプラットフォーム、あるいはベンダの違いを超えて相互接続が保証されるというものだ。J2EEではバージョン1.4からBasic Profile 1.0に対応した。

　また、WS-Iからは、SOAPメッセージがBasic Profile 1.0に適合しているかどうかを検証する「Test Tool」も提供されている。Test Toolの詳細については、＠ITの記事「Webサービスの互換性を検証するテストツール」を参照してほしい。

　WS-Iではさらに、2003年12月に「Sample Application」の提供を始めた。これはWebサービス・ベンダ10社（BEA、IBM、マイクロソフト、オラクルなど）がそれぞれの開発・実行環境で、同一のWebサービスを作成するというもので、9個のWebサービスが連携するサプライチェーン・モデルを扱っている。例えば、クライアントをマイクロソフト、サービスプロバイダをIBMなどとしても、問題なく運用できる。Basic Profile 1.0が現実のアプリケーションでも実現可能なことを証明したことは、相互運用性にとって重要な成果だといえよう。

　Basic Profileの初期バージョンである1.0には、SOAPメッセージの添付ファイルに関する規定は除かれている。ただ、「添付ファイルを使いたいというニーズは強い」とチャン氏は述べた。「現時点では単純なRPCとしてしかWebサービスは利用されていないが、将来もっと複雑なビジネスを動かすときには、長文のXMLが必要になったり、あるいはパフォーマンスの観点からバイナリファイルを利用したいという声が上がっている」。WS-Iはこれを受けて、現在SOAPメッセージの添付ファイルに関するガイドラインを策定中で、Basic Profileの次期バージョン1.1で盛り込まれることになっている（執筆時点ではワーキングドラフトが公開中）。J2EEでは、SAAJ（SOAP with Attachments API for Java）がSOAPメッセージの添付ファイルを扱うAPIだ。

■Webサービスの新しい動き

　チャン氏は、J2EEによるWebサービスの将来に向けた取り組みも紹介した。その主な内容を紹介しよう。

ebXML

　ebXMLは電子商取引にXMLを利用するための標準仕様である。チャン氏は、電子商取引の標準仕様として、ebXMLのほかにEDI、RosettaNet、BizTalkなども存在するが、これらはどれもJ2EEにはふさわしくない、としてebXMLにフォーカスする姿勢を表明した。ただし、実際にWebサービスを電子商取引に活用するには、ロングラニングトランザクション、セキュリティ、メッセージ信頼性などの標準仕様が固まり、それに準拠した製品が登場しなければならない。

　Webサービスのステータスとして、チャン氏は以下の3フェイズを示した。

• フェイズ1　シンプルWebサービス（RPC的なメッセージ交換）
• フェイズ2　EAI（社内アプリケーション統合にWebサービスを利用）
• フェイズ3　BtoB（ビジネスプロセスをWebサービスで統合）

　現在はフェイズ1を達成し、徐々にフェイズ2に進んでいる段階で、BtoBにWebサービスが使われるのはまだ先になるだろうと語った。

Fast Webサービス

　「この用語はまだ一般的には知られていないもの」と前置きして、チャン氏はWebサービスのパフォーマンスの問題点を指摘した。現時点の単純なメッセージ交換であれば、通信速度やデータ量はあまり問題にならないが、Webサービスを使ったビジネスを想定すると、大量のXML文書がネットワークを流れることになり、当然パフォーマンスの問題が重要になってくる。

　使用するプロトコルに対する通信速度、データ量には、

使用するプロトコル	通信速度	データ量
JAX-RPCエンコード	遅い ↑ ↓ 速い	多い ↑ ↓ 少ない
JAX-RPCリテラル
RMI／IIOP
RMI

という関係が成り立つ。つまり、JAX-RPCは通信速度、データ量ともに劣るというのだ。これを解決するために、J2EEでは開発者に特別なコーディングを求めず、代わりにプロトコル、データバインディング、トランスポートといったレイヤでのパフォーマンス向上を進めていくとした。今後、どのようなテクノロジが登場してくるのか注目したい。

そのほか

　Webサービスをもっと簡単にコーディングするために、例えばサーブレットがJSPに進化したように、ならないものか。この回答をもたらすテクノロジがMetadataである。WebサービスをJSPのように記述し、オートデプロイされる日が訪れるかもしれない。

　これ以外にもオーケストレーションやトランザクションの動向にも触れていたが、これらは＠ITの記事「ビジネスWebサービス最新事情」でレポートしているので、詳細は上記記事を参照してほしい。

■まとめ

　J2EEの最新バージョンである1.4は、Webサービスへの拡張を主たる目的に策定された。リリースが当初の予定から大幅に遅れたのも、WS-IのBasic Profile 1.0への対応を待ったためといわれている。満を持して登場したJ2EE 1.4は、現時点で固まっているWebサービス標準仕様をほぼ取り込んだ、完成度の高いものといえよう。今後のWebサービスの開発、運用環境は、J2EE 1.4を中心に進んでいくだろう。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）