連載

スキルアップのための分散オブジェクト入門

第6回　現実モデルはWebサービスとの共存

日本アイオナテクノロジーズ 主席 コンサルタント 小野沢 博文 2002/10/4

本連載について

今回は、本連載の最終回にふさわしく、分散オブジェクト技術とWebサービスが共存する将来のコンピューティング・モデルについて解説します。Webサービスの基礎解説は、Java Solutionフォーラムの「連載：パソコンで試してわかるWebサービス」に譲ることにして、ここでは、Webサービスに関する基礎知識を前提に、前半でWebサービスと分散オブジェクト技術のかかわりを概観し、後半ではそれらが共存する分散コンピューティング環境を解説していきます。

Webサービスと分散オブジェクト技術のかかわり

■分散オブジェクト技術はなくならない

　さすがに最近では少なくなってきましたが、分散オブジェクト技術とWebサービスを単純に比較して、その優劣をつけようという記事をしばしば見掛けます。既存技術の技術者に新技術を紹介する場合には、そうしたアプローチもまったく無意味ではありませんが、そもそも異なる設計思想に基づく2つの技術を、単純な○×式の比較表に収めようとすると少々無理が出てきます。

　最近、Webサービス関連のさまざまなパネルディスカッションで各分野の専門家の方と同席する機会がありますが、そこで必ず意見が一致するのは、「こうした単純な比較は意味をなさない」という点と、もう1つは「Webサービスが普及しても分散オブジェクト技術はなくならない」という点です。

　これからの分散システムを構築していくうえで、Webサービスと分散オブジェクト技術はどちらも重要で、それぞれのアーキテクチャや特性を理解したうえで使い分けていくことが成功への鍵になります。そのための技術比較は大いに行うべきです。

■Webサービスは分散オブジェクト技術を継承

　Webサービスは、分散オブジェクト技術で培われてきた要素技術の多くを継承しています。もっとも、Webサービスが継承してきた技術分野は分散オブジェクト技術だけではなく、EDI（Electronic Data Interchange）、Web技術、メッセージング・ミドルウェアなど、多岐にわたります。

　第2回で、分散オブジェクト技術の仕組みとしてインターフェイス定義やスタブとスケルトンについて解説しましたが、これらはそっくりそのままWebサービスの仕組みにも当てはまります。

　サーバが提供するサービスのインターフェイスをきちんと決めておかなければならないのは、分散オブジェクト技術でもWebサービスでも同じです。Webサービスでは、このためにWSDL（Web Services Description Language）を使用します。CORBAやCOM+のインターフェイス定義では、サービスの抽象的なインターフェイスだけを記述し、通信プロトコルやサーバのエンドポイント情報はオブジェクト・リファレンスにカプセル化されます。Webサービスではこの点が少し異なり、これらすべての情報がWSDLに記述されます。この点は、Webサービスと分散オブジェクト技術の設計思想の違いに起因するので、TIPS2で再度触れます。

■SOAPはオブジェクト・アクセスのためのプロトコル？

　 Webサービスの主要プロトコルであるSOAPは、Simple Object Access Protocolの略です。Webサービスを勉強された方はご存じだと思いますが、SOAPはオブジェクトにアクセスするためのプロトコルというよりは、むしろRPC（リモート手続き呼び出し）やドキュメント転送を実現するためのプロトコルです。にもかかわらず、なぜこのような紛らわしい名前が付けられたのでしょうか。これは、SOAPがもともとはCOMオブジェクトをインターネット越しに呼び出すために開発されたことに由来しています。少し乱暴ないい方をすると、COMのオブジェクト呼び出しメッセージをXMLで記述し、それをファイアウォール・フレンドリなHTTPで運んだのがSOAPの始まりでした。

■Webサービスはインターネットワイドでの統合を実現する

　 インターネット越しに分散オブジェクトを呼び出すことは従来でも不可能ではありませんでした（TIPS1）が、SOAPを使用することでこれをより簡単に実現することができるようになりました。EJBやCORBAオブジェクトをWebサービスとしてラッピングしたり、クライアント／サーバ間の通信プロトコルとしてSOAPを選択可能にするCORBA実装がすでに登場または予定されています。もちろん、既存のEJBやCORBAオブジェクトの粒度は、そのままWebサービスとして公開するのには不適切な場合が多々あります。オブジェクトやサービスの粒度についてはTIPS3で詳しく説明します。

TIPS1　分散オブジェクトへのインターネット越しのアクセス

インターネット越しにオブジェクトを呼び出す場合に問題になるのが、ファイアウォールやNAT（Network Address Translation）の存在です。特に、ファイアウォールは特定のプロトコル、IPアドレス、またはポート番号でパケットをフィルタリングすることができるため、その設定によってはオブジェクト呼び出しのパケットがファイアウォールを通過できなくなってしまいます。 　 OMGでは、IIOPメッセージが効率的にファイアウォールを越えられるようにするための標準化作業を行っていますが、これを待たなくても、既存の多くの製品でファイアウォールを越えることができます。 　 現行のCORBA製品では、ポート番号の固定とHTTPトネリングの2つの手法が一般的に使われています。1つ目の方法では、サーバがリッスンするポート番号を固定し、ファイアウォール側ではこのポートを開放してIIOPメッセージを通過させます。この方法はIIOPの標準に完全に従っているため、異なる製品間の相互運用性が保証されます。この方法を使った場合には、サーバの自動起動ができなくなるといったデメリットもありますが、最初からアプリケーションをそのように設計しておけば問題ないはずです。 　 2つ目のHTTPトンネリングでは、製品固有の方法でIIOPメッセージをHTTPのGETやPOSTメッセージのURL部やボディ部に格納して送ります。クライアントおよびサーバ・アプリケーションに直接HTTPトンネリングを処理させるか、または専用のプロキシ・サーバにIIOPとHTTPトンネリングの変換を行わせます。

　ファイアウォール・フレンドリという点に加えて、Webサービスのもう1つの特徴は、特定の実装技術やOSプラットフォームに依存していないという点です。標準仕様さえ順守していれば、Webサービスをサーブレットで実装してもASP .NETで実装してもCORBAで実装しても構いません。OSやプログラミング言語も問いません。ネットワークの一方にいるクライアントは、サーバの実装手段を意識する必要がありませんし、逆にサーバもクライアントの実装手段をまったく意識しません。

　これは別の見方をすると、Webサービスを通じて、J2EE、.NET、そしてCORBAをシームレスに接続できることを意味します。しかも、インターネットを越えて接続できるのです。さらに、J2EE、.NET、CORBAに限らず、近い将来にはERPをはじめとするさまざまなパッケージ・ソフトがWebサービスに対応するようになるでしょう。また、既存のアプリケーションをWebサービスでラッピングするためのアダプタ製品も登場してきています。このように、Webサービスはあらゆるアプリケーションをインターネットワイドに統合するための共通基盤になろうとしています。

図1　Webサービスはインターネットワイドでの統合を実現する

■SOAPそれともIIOP？

　もちろん、第1回で紹介したように、IIOPを介して異なる分散オブジェクト技術を相互に接続する方法も引き続き有効です。それでは、基盤プロトコルとしてIIOPを使用すべきなのでしょうか、それともSOAPを使用すべきなのでしょうか。これは、単純には答えの出せない質問です。また、必ずしもどちらか一方に決める必要もありません。1つの企業内でも、システム環境と用途に合わせてこの両者を使い分けることができます。SOAPを使用する場合にも、その下位プロトコルとしてHTTPを使用するのか、JMS（Java Message Service）＊1 を使用するのか、といった選択肢があります。

　例えば、既存のCORBAサーバをExcelから利用したいとしましょう。この場合、COM-CORBAゲートウェイを介してIIOPで通信することも可能ですし、CORBAオブジェクトをWebサービス化してSOAPで通信することも可能です。将来的にCORBAやCOM以外の多種多様なクライアントからのアクセスを許したい場合には、この機会にCORBAサーバをWebサービス化しておくのが得策かもしれません。しかし、CORBAクライアント並みの性能が要求される場合には、バイナリ・プロトコルであるIIOPを使い続ける必要があるでしょう。

＊1：JMSはAPIを規定しているだけで、通信プロトコルまでは規定していません。ここで「下位プロトコルとしてJMSを使用する」といっているのは、SOAPのエンベロープをJMSのメッセージとして運ぶという意味です。従って、通信プロトコルはJMS製品に依存することになります。

■オブジェクト指向それともサービス指向？

　 分散オブジェクト技術とWebサービスの大きな違いは、その設計思想にあります。この違いを一言でいうと、オブジェクト指向とサービス指向の違いということになります。これを、商品の検索システムを例に具体的に説明しましょう。

　オブジェクト指向的な設計では、商品名、価格、在庫数量などの属性を持った商品クラスを定義し、商品の種類ごとにそのクラスのインスタンスを作成することになるでしょう。そして、クライアントは、ファクトリ・オブジェクトに対して商品オブジェクトの作成や検索を依頼することになります。その場合、検索メソッドは、商品の検索結果をオブジェクト・リファレンスの配列としてクライアントに返却するかもしれません。このようなオブジェクト指向的な設計では、商品情報を取り出すためのメソッド呼び出しの回数は、検索結果の商品数に比例して増加していきます。このため、クライアントとサーバ間の通信速度が遅いと途端に性能上の問題が発生してしまいます。また、このモデルでは検索結果がオブジェクト・リファレンスとして返却されるため、クライアントがサーバと同じオブジェクト技術を採用していることが前提になっています。従って、このモデルをそのままインターネットワイドな環境や異なる実装技術を採用する組織間に適用しようとすると、たちまち破たんしてしまいます。

図2　オブジェクト指向的なアプローチ

　同じシステムにサービス指向を適用すると、個々の商品オブジェクトの存在は一切外部から隠ぺいされ、クライアントには「商品情報提供」というサービスだけが公開されることになります。この場合、クライアントは商品情報提供サービス内の検索メソッドを呼び出し、その結果として商品情報の一覧を直接取得することになります。メソッド呼び出しの回数は1回だけで済みますし、何よりもオブジェクト・リファレンスのような実装上の制約を受けません。

　サービス指向アーキテクチャという用語が一般的に使われ始めたのはごく最近ですが、この考え方自体は目新しいものではありません。オブジェクト指向のデザインパターンにファサード・パターンというのがあります。このデザインパターンはサービス指向の考え方と共通しており、システム内部の複雑な構造を隠ぺいして、利用者には単純なサービス・インターフェイスだけを提供しようという考え方に立っています。

図3　サービス指向的なアプローチ

TIPS2　オブジェクト・リファレンスとWSDL

先ほど、WSDLではサービスの抽象的なインターフェイスだけでなく、通信プロトコルやエンドポイント情報まで記述する、という話をしました。CORBAやCOM+のIDLに慣れている者にとっては少し違和感がありますが、よくよく考えるとここにもサービス指向の考えが表れているようです。 　オブジェクト指向的なアプローチでは、比較的粒度の小さなオブジェクトをサーバ側にインスタンス化し、これらのインスタンスへのオブジェクト・リファレンスを実行時に必要に応じてクライアントに配布します。CORBAでは、このオブジェクト・リファレンスにプロトコルやエンドポイントの情報が格納されています。これらのオブジェクトは一般的に実行時に動的に作成されるため、そのエンドポイント情報は静的な定義情報としてあらかじめクライアントに配布するのには適していません。 　これに対してサービス指向的なアプローチでは、粒度の大きな少数のサービス・インスタンスをクライアントに公開することになります。そして、これら少数のインスタンスのプロトコルやエンドポイント情報を最初からWSDLに含めてクライアントに配布してしまうことで、オブジェクト・リファレンスのような実装技術に依存した情報を、メソッド呼び出しのパラメタとしてやりとりするのを避けているわけです。 　念のために申し上げておきますが、CORBAでもオブジェクトURLや文字列形式のオブジェクト・リファレンスを使用することで、以前からこのようなサービス指向的なアプローチが広く採用されてきました。

TIPS3　オブジェクトとサービスの粒度

オブジェクトやサービスの細かさを粒度（granularity）と呼んでいます。例えば、商品種別ごとに商品オブジェクトをインスタンス化するオブジェクト指向的アプローチと、個々の商品オブジェクトを隠ぺいして、単一の商品情報サービスを提供するサービス指向的アプローチを比べると、オブジェクト指向的なアプローチの方がオブジェクト（またはサービス）の粒度が小さいということになります。 　オブジェクトやサービスの粒度の決定においては、次の2つの要素を考慮することが重要です。 性能 性能を見積もる場合、ローカルなJavaメソッド呼び出し、CORBAなどの分散オブジェクト呼び出し、SOAPによるリモート呼び出しのそれぞれのレスポンス時間の目安を頭に入れておく必要があります。当然環境や条件によって異なりますが、大まかな目安は、ローカルなJavaメソッド呼び出しは数ナノ秒程度、ローカルLAN環境でのCORBAのリモート呼び出しは0.1〜数ミリ秒程度、SOAP（over HTTP）の呼び出しは、ローカルLAN環境で数十ミリ秒程度、インターネット環境で数十〜数百ミリ秒程度です。従って、ローカルJavaと同じようなオブジェクトの粒度で分散オブジェクト技術を設計したり、分散オブジェクト技術と同じような粒度でインターネット越しのWebサービスを設計してしまうと、性能的に使い物にならないものになってしまいます。 再利用性 複雑で粒度の小さいオブジェクトやサービスをそのまま利用者に公開してしまうと、システムの利用が困難になってしまいます。また、システムの内部実装を変更したい場合、その影響が利用者に及んでしまうため、メンテナンス性や再利用性の低下を招いてしまいます。こうした状況を避けるためには、粒度が大きく、内部構造と実装の詳細を隠ぺいした抽象度の高いサービスを公開する必要があります。

1/2

第6回 現実モデルはWebサービスとの共存
	Page1 Webサービスと分散オブジェクト技術のかかわり
	Page2 Webサービスと分散オブジェクト技術が共存する分散環境

INDEX
スキルアップのための分散オブジェクト入門
	第1回　分散オブジェクト技術が必要なわけ（2002/3/19)
	第2回　分散オブジェクトのしくみを理解する（2002/4/4）
	第3回　開発手順からCORBAを理解する（2002/4/25）
	第4回　開発手順から分かるEJBとJavaRMI（2002/6/25）
	第5回　分散オブジェクト技術としてのHORBとCOM+（2002/8/21）
	第6回　現実モデルはWebサービスとの共存（2002/10/4）

Java Solution全記事一覧

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