Soapboxに関する私の前回の記事の後でもSOAPを巡る誇大宣伝が後を絶たないのは、驚くことではありません。Microsoftは .NETプラットフォームでこのプロトコルを賞賛し、Apacheは (少なくとも、私が参加したXMLサークルでは) メッセージングのために最も重要であると公言し、また、すべての人がSOAPを手に入れようとしています。SOAPのためのいろいろなサービスは、(人気のある2つのオープン・ソース・アプリケーション・サーバーである) EnhydraとjBossで、および商用アプリケーション・サーバー会社の多くで開発中です。それでは、前回の記事以降、SOAPの物語にどのような変化があったのでしょうか。正直に言って、ほとんど何も変わっていません。SOAPは、弾みを付けた巨大な岩のように、坂を転げ下りようとしています。問題は、読者がそれと一緒になって走っているのか、押しつぶされないことを願って坂の下から見上げているのかということです。私は、マーケティング用の誇大広告をすべて取り払い、SOAPが読者に適しているかどうかを明確に評価するために必要な道具立てを提供するつもりです。つまり、あの大きな岩に読者がつぶされることのないように、お手伝いをしたいと思います。

Soapboxに関する私の最初の記事では、SOAPについて、とくにそれがRPCとXML-RPCを基礎にしていることを詳しく説明しました。今回は、その続きから話を始めます。ここで、SOAPを、Java世界での通信における最大のライバルである、RMI (リモート・メソッド呼び出し) と比較してみましょう。RMIはかなり長いあいだ、Javaにおけるネットワークを介したコンポーネント間の通信に使用されていて、Enterprise JavaBeans (EJB) などのテクノロジーで使用され、依然として人気を保っています。このRMIがSOAP (その現実と将来の見込みの両方) とどのように異なるのかを検討することにします。最後に、私が「実用クラスのSOAP」と呼んでいるもの、つまり、MicrosoftおよびIBMから今すぐにダウンロードできるものに目を向けることにします。今回の記事は、概念的な内容から、開発者が本当に聞きたがっていること、つまり「SOAPは私のために、今すぐ、どのようなことができるのか」という、具体的な考察に移ります。

RMIそれともRPC

この2回シリーズの第1回の記事では、SOAPについて検討し、それがどのようなものであるのか、また同じように重要なこととして、どのようなものでないのかを述べました。特に、RPC、XML-RPC、およびSOAPについて調べて、それぞれのテクノロジーに組み込まれているものを分析しました。SOAPの多くの「フィーチャー」が実は、SOAPに固有のものではなくXML-RPCのフィーチャーであることを発見して、驚いた読者もいることでしょう。また、Userland XML-RPCサイト (参考文献を参照) にあるXML-RPCライブラリーの1つなどの、SOAPよりも単純なパッケージを使用することによって、自分のビジネス・ニーズを満たすことができると知った読者もいるのではないでしょうか。あるいは、エンベロープ・メカニズムを備えていて、アプリケーション固有のデータ型をエンコードしやすいSOAPこそが、自分の必要とするものであると決断する人もいるかもしれません。いずれにしても、私の最初のSoapbox記事で提供した情報により、SOAPおよびRPCについて、今日のプログラミングにおける主要なライバルであるRMIと比較するのに十分な知識が得られたはずです。RPCを差し置いてRMIを使用するだけの十分な理由はありますが、RMIを差し置いてRPCを使用するだけの十分な理由もあります。(こうしたことは、常に言えるのではないでしょうか)次のセクションでは、SOAP、RPC、またはRMIの3つの選択肢から選択を行うのに必要な主要な要素について説明します。

言語しだいです

SOAP、RPC、またはRMIのどれを使うのかを決定する際の基礎になるのは、使用するプログラム言語です。読者がJavaプログラマーであれば、Java APIの一部としてすでにRMIが手元にありますから、簡単にアクセスすることができ、ドキュメントも十分にそろっています。Javaプログラマーでないとしたら、RMIが自然な選択肢とはなりません。事実、Javaプログラマー以外の人にとっては、Java開発者が感じる以上に、SOAPが大変魅力的なソリューションであると思われるでしょう。SOAPは、CORBAやその他のリモート・プロトコルに比べて、メッセージングや通信をはるかに容易に行える手段を提供します。さらに、SOAPが提供するXMLのエンコードは、使いやすいものです。いくつかのCやPerlのXMLパーサーが使用可能になっていますが、一般にこれらは、同じ分野におけるJavaの努力に (開発の点で) やや後れを取っています。したがって、SOAPは、読者のツールボックスにメッセージングを追加するだけでなく、Javaのツールほど洗練されていないツールを使用してXMLを構文解析せざるを得ないという負担を取り除いてくれます。

実際には、SOAPを何らかの形で使用している人のほとんどはJavaプログラマーですから、結局は、RPCを使用するのかRMIを使用するのかという、元の問題に戻ることになります。もしも読者がJava開発者であって、Java以外のアプリケーションまたはコンポーネントと通信する必要があるとしたら、どうでしょうか。読者のアプリケーションの世界における、こうした他のプレイヤーたちは、おそらくRMI通信の送受信ができないでしょう。これらのプレイヤーはIIOPやCORBAの厄介ごとにかかわり合いたいとは思っていないと考えて間違いなさそうです。しかし、SOAPが発信する適切で単純なペイロードを受信することは、確かにできるのです。ペイロードのデコードと応答を (彼らの言語でSOAP APIを使用することによって) 同じやり方で行えるので、「プログラム言語の垣根」を越えた通信が容易になります。また、このことがSOAPを魅力的なものにしています。

それでは、これは開発者にとってどういうことを意味するのでしょうか。読者がJavaでコーディングし、Javaに話し掛け、Java以外のものは何も要らないというのであれば、SOAPはその魅力の一部を失ってしまいます。RMIのほうがSOAPよりもはるかに広く受け入れられていて、開発者にとって、習得や使用が容易だからです。SOAPには、Javaを愛好する人にとっても利点はありますが (これについては、次で採り上げます)、さほど魅力的なものではありません。Java環境で仕事をしているのでなければ、あるいはJava以外の環境と通信する必要があるのならば、SOAPは輝き出します。SOAPはXMLを使用します。XMLはベンダーや言語から中立で、Perl、C、Adaで、さらにはCOBOLでも (もっとも、なぜCOBOLを使う必要があるのかは、また別の問題ですが) 簡単に構文解析することができます。SOAPは、CORBAやRMI-IIOPなどの強力なパラダイムに対する、魅力的な代替手段を提供します。また、SOAPは現在非常に人気の高いテクノロジーであるため、他の言語用のSOAP APIがすぐに登場するようになっています。このような場合には、SOAPはメッセージングのための親友と考えてよいでしょう。しかし、SOAPが扱うのは、メッセージングだけでないことは確かですので、クライアントがSOAPとどのように対話し、RMIとどのように対話するのかを示すことにします。

「呼び出し」対「要求と応答」

RMIとRPCのどちらを使用するのかを決定する際には、この両者が利用する対話のための方法を検討することが重要です。RMIモデルの対話は、RPCで使用される対話とはまったく異なります。リモート・オブジェクトの操作方法に著しい違いがあるのです。事実、RPCおよびSOAPでは、リモート・オブジェクトが直接操作されることは、まったくないのです。この点を明らかにするために、両方のモデルを詳しく調べてみます。

RMIでは、リモート・オブジェクトはローカル・オブジェクトのように扱われます。クライアント・アプリケーションはリモート・オブジェクトのスタブでメソッドを直接呼び出します。RMIとJavaの魔法により、このスタブでのメソッド呼び出しがネットワークを経由してエンコードされて、最終的には、別のマシンのオブジェクトでメソッドが呼び出されます。次にその結果が同じようにエンコードされて、スタブに戻され、スタブが結果を戻します。これは、クライアントにとってみれば、リモート・オブジェクトが関与していないようなものです。この方法で対話を行うことの最大の利点は、型の安全性が確保されることと、メソッド名を直接使用できることです。言い換えれば、通常のJava規則が順守されることです。メソッドが呼び出され、引数に誤りがあるとコンパイル時エラーが発生します。しかし、これには欠点も1つあります。多くの例外が、java.rmi.RemoteException にラップされて終了します。したがって、RMIオブジェクトを呼び出すアプリケーションについて、ある程度の知識がなければ、RemoteException のなかにラップされた情報 (おそらくNumberFormatException) を見失ってしまいます。その結果、エラーの発生に関する情報が得られなくなります。

一方、もう1つの方法であるRPCスタイルの呼び出しは、これとはかなり異なる経路をたどります。RPCスタイルの呼び出しは、呼び出されるメソッドをRPCに関与させるのではなく、ユーザーがメッセージ (これは、本質的にはリモート・サーバーへの要求です) の発信を行います。そして、次に応答が作成されて戻されます。この場合のクライアントは、メソッドを直接呼び出すことは決して ありません。要求は一般に、リモート・サーバーで呼び出すメソッドの名前と引数からなります。ただし、これらはすべてエンコードされます。リスト1 のコード断片を見てください。これは、航空券の予約と購入を要求するものです。

SOAPに関する記事であるにもかかわらず、XML-RPCのコード・サンプルを示したのでは、読者はだまされたような気になるかもしれません。そこで、念のため、SOAPを使用した同じ呼び出しをリスト2 に示します。

さしあたり、RMIと比較した場合にXML-RPCを使用するのかSOAPを使用するのかは問題ではありません。クライアントとサーバーの間の対話は、XML-RPCでもSOAPでも同じであり、両者ともにRMIとは大幅に異なっています。これらのリストから理解できるように、メソッド名とパラメーターがJavaのストリングまたはパラメーター (使用するテクノロジーに応じて、どちらかになります) としてエンコードされます。また、検索は (RMIにおけるようにJava仮想マシン内の実際のjava.lang.reflect.Method へのハンドルを取得することによってではなく) 名前によって行われる必要があります。こうしたRPCスタイルのコーディングでは、さらにまずいことが起こる可能性があります。メソッドがサーバー内で失われたり、メソッドがクライアントで誤ってつづられたりすることがあります。そのほかに起こり得る問題として、引数が誤ったタイプになっていたり、引数名が誤って指定されていたり、サーバーが実行されていなかったりする場合があります。これらはすべて (サーバーがダウンしている場合を除き)、RPCでは実行時 の問題となり、RMIではコンパイル時 の問題となります。一般に、こうした問題は、実行時に見付けるよりもコンパイル時に見付けたほうが良いのです。つまり、RPCまたはSOAPを使用すると、Javaコンパイラーの多くの宝を持ち腐れにしてしまいます。

RPCスタイルには、確かにいくつかの利点があります。まず、クライアントとサーバーの間の独立性が非常に高くなります。RMIとは異なり、スタブ・クラスを生成してそれらをクライアント・マシンに渡す必要はありません。クライアントが知らないうちにサーバーをシャットダウンして置き換えても、問題は生じません。(RMIでもこれは可能ですが、実際に行うとなると、はるかに困難です。)事実、呼び出しと呼び出しの間でサーバーのクラスとメソッドをアップグレードして、再コンパイルしても、クライアントの処理は妨げられません。また、SOAPでは (XML-RPCだけの場合と異なり)、問題が発生した場合、APIの標準的な部分であるSOAP障害メカニズムを使用して、問題に関する詳細情報をクライアントに中継することができます。

繰り返しになりますが、読者の作業でRMI、RPC、またはSOAPのどれを使用するのかは、読者の自身の判断にまかせることにします。SOAPのほうが明らかに優れている分野もあります。SOAPは、非同期通信やクライアントとサーバーの緩やかな結合という点で、大きな長所を持っています。しかし、これらの利点が、欠点に結び付いているのです。すなわち、はるかに多くの実行時検査を行う必要があり、開発者は、メソッドやパラメーターが正しいことを確認するためにコンパイル時の多くの利点を犠牲にしてしまいます。Soapboxに関する私の最初の記事を読んだ読者は、私が「読者のビジネス・ニーズを評価してください」と言おうとしていることが分かると思います。必要なものを使って、必要でないものは放っておいてください。場合によっては、SOAP呼び出しを行ってリモート・サーバーに黙々と働いてもらうのが良いでしょうし、ある場合には、Java同士の通信を行ったりコンパイル時の型の安全性を確保したりしたいこともあるでしょう。

上に戻る

実用クラスのSOAP

ここまでにSOAPをRPC、XML-RPC、およびRMIと比較し、それらの間の相違点や得失を検討しました。まだ店仕舞いの時刻ではありませんので、SOAP自体のいくつかの問題について考える必要があります。ここまでは、SOAPに関する私の論考は、テクノロジーの「概念的な実装」に焦点を当ててきました。仕様が「そのまま」実装された場合にAPIがどのように振る舞うのかを示しました。現実には、こうした完全な実装はありえません。ツールキットが人間によって開発されたものであることを忘れないでください。これを念頭に入れて、次のセクションでは実際のSOAP実装 (いわば「実用クラスのSOAP」) について、SOAPの約束がどのように実現されているのかを調べることにします。

実践と約束: IBMとMicrosoftのSOAP

実装と仕様は、相互の期待にどのように答えているのでしょうか。2つの主要なSOAP実装版が現在開発されつつあります。1つは、ApacheからIBMのApache XMLプロジェクトの一部として開発されているもので、もう1つは、Microsoftから .NETプラットフォームの一部として開発されているものです。どちらの場合も、実装が一般にリリースされてから1年もたっていませんので、実装の成熟度という点で疑問があります。

Apache XMLからの最も期待できるリリースと思われるApache SOAPの成果は、IBMによるSOAP4Jでの作業を基に、拡張を加えたものです。ApacheのSOAPには、"2.0" というバージョン番号が付いていますが、他の多くの2.0製品と同等というわけには、到底いきません (2.0ともなれば、たいていは堅固なものです。)この仕様には、これからSOAP 2.0に追加される項目の長大なリストが含まれています。しかし、それらの多くは、ほとんどのアプリケーションでは必要のないものです。これによる不利益は、仕様に準拠するために、こうした小さな、使われないことの多い項目をサポートしなければならないということです。しかも、実装されるまでそれらが使用されることはないにもかかわらず、フィーチャーにかかわる作業が終わっていないため、SOAPツールキットのパフォーマンスをチューニングできないのです。ですから、残念なことに、利用者はめったに使用されないフィーチャーのコストを支払うことになります。

.NETプラットフォームの中核部分であるMicrosoftのSOAP実装版は、機能の点でW3Cに提案されたSOAPとほぼ同じであり、これに準拠しています。これはおそらく、今後も変わることがないでしょう。.NETプラットフォームにおける通信のほとんどはSOAPによって行われるからです。SOAPを介してコンポーネントが (開発段階でも実動段階でも) 相互に対話できる能力は、.NETの主要なフィーチャーの1つですから、MicrosoftのSOAPの実装版がつまずくことは考えられません。同時に、Microsoftの実装版に多くのプロプラエタリー・フィーチャーが組み込まれることも予想する必要があります。こうした「フック」により、Microsoft主導の製品は、.NETプラットフォームに固有のショートカットを利用できるようになることでしょう。Microsoft製品を全面的に使用している場合には、これらのフックはすばらしいものですが、基本的なSOAP実装版を使用している場合には、気を付けてください。

結局、SOAPはまだ急速に発展している段階にありますので、今日存在しているSOAPは、将来のSOAPとして約束されているものとはかなり異なるはずです。IBMおよびMicrosoftによる実装版はまだ完成途上なのです。今日 (これらのいずれかのプロジェクトを介して) SOAPを使い始め、数か月後に新規バージョンにシームレスにアップグレードできるとは期待しないでください。フィーチャーが変更されたり、機能性が変更されたり、全体的な混乱が生じたりして、読者のアプリケーションの他の部分の変更が必要になることもあります。さらに、SOAPが新規仕様としてW3Cに受け入れられても、最終的な勧告が出されるまでの間にいくつかの改訂が行われることでしょう。そしてこうした改訂によってSOAPの実装内容の追加変更が必要になります。そうなると、当然、読者の開発環境をアップグレードする必要が生じます。

とはいえ、SOAPの現行の実装版にも多くの有利な点があります。実装の細部にこだわらずに、アップグレードが行われたときに柔軟に対応するつもりであれば、IBMおよびMicrosoftから提供されている現行のSOAP実装版を使用することにより、多くのことが学べます。RPC呼び出しがどのように機能するのか、リモート・メソッドをどのようにして見付けることができるのか、またはSOAPのエンベロープおよび障害メカニズムがどのように動作するのかを、詳しく調べることができます。言い換えれば、SOAPの完全で安定した実装版が現実のもの になるときまで、ゲームの先陣を切ることができるのです。

上に戻る

XMLに関する注意: ほかには何も要らない?

SOAPプロバイダーについては、最終的な警告が用意できています。すなわち、XMLに全財産を賭けないでください、ということです。こう言うと誤解を招く恐れがありそうなので、最後までよく聞いてください。XMLは広く受け入れられています。しかし、XMLは、Javaなどのきちんとしたプログラム言語でサポートされた、より大きなアプリケーションのコンテキストで使用するのに最も適しています。「XMLで十分である」と言った人がいます。SOAP、XML-RPC、RSS (Rich Site Summary) などや、その他のXML語彙が実際のアプリケーションの領域に入り込むようになったことで、XMLはプログラム言語そのものであるという主張が行われています。Apache Cocoon、XSL、XSLT、SOAP、およびXMLデータベースを使用していると、Javaコードを1行も書かずに1つのアプリケーション全体を実行できそうに思えます。(公正を期すために言うと、Cocoonの誰もこのようなことを実際に言っているわけではありません。例えにすぎません。)

XML以外のものは不要であるという、こうした前提は、本質的に誤っています。XMLの使用には、それなりの代償があります。バイナリー・フォーマットに比べてエンコードに時間がかかり、ネットワーク間で送信するデータが多くなります。XMLの利点は、プログラム言語やプラットフォームが異なっていても理解できることです。しかし、こうした一律の機能性を必要としないのであれば、XMLにはたいした意味がありません。 たとえば、同じアプリケーション内でサーブレットとEJBとの間の通信を行うためにXMLを使用するのは、まずいアイデアです。XMLやXMLを移送するのに必要なリソースを処理するのに時間がかかるにもかかわらず、得るものはありません。

SOAPはツールです。アプリケーションによるメッセージングとデータ表記を支援するために、ツールとしてだけ使用すべきです。こうしたアプリケーションには、XML以外のものも必要です。(特に、SunがJavaに関するオープン・スタンダード・プロセスを作成する意欲に欠けることが明らかになったことで) Javaに縛り付けられるなと主張する人がいるのは理解できますがXMLによってJavaを置き換えてしまおうとするのは現実的ではありません。したがって、SOAPおよびXMLは、ツールボックスの中のもう1つのスパナーとして扱ってください。多くの用途に使える非常に強力なスパナーですが、それでも、スパナーにすぎないのです。

上に戻る

要約

この2回シリーズでは、SOAPをさまざまな角度から検討してきました。押したり、突付いたり、その祖先であるRPCやXML-RPCと対比したり、主要なライバルであるRMIと比較したりしました。また、使用可能なSOAP実装内容を、W3Cから出されている実際のSOAP注釈と見比べました。読者は、SOAPに関する態度をまだ決めていないとしても、以上の説明で、そのメリットと問題を認識できるようになったはずです。

SOAPの状態に関しては、読者自身の意見が形成されつつあると思います。しかし、SOAPに賛成または反対するような、なんらかの指図を読者が待っているのであれば、そのような指図は出てこないと申し述べておきます。はっきり言って、私も、読者にSOAPを使用すべきであるとか、使用すべきでないとかは言えません。私に言えることは、今日SOAPが開発者によって使用されている多くの事例で、SOAPの代わりにXML-RPCを使用してもプログラムを書くには十分であり、より簡単であろうということです。さらに、XML-RPCライブラリーのほうがSOAPライブラリーよりもずっと充実しています。同時に、PerlコンポーネントとCコンポーネント、およびCコンポーネントとJavaコンポーネントの間の通信で毎日頭を悩ましているプログラマーもいます。こうした開発者は、SOAPベースまたはXML-RPCベースの通信モデルに移行することにより、多くの収穫を得ることが可能です。逆に、Java言語の外に足を踏み出すことが決してないJava開発者は、SOAPではなくRMIを使用することにより、著しいパフォーマンスの向上を得ることができるのです。

「必要なものを使って、必要でないものは放っておく」という、基本的なアドバイスをもう一度繰り返しておきます。SOAPに夢中になってしまう前に、それが読者のビジネス・ニーズに適しているかどうかを確認してください。ビジネス・ニーズに適していない場合には、仲間たちと同じ「最新の」技術を使っていなくても気にすることはありません。自分のアプリケーションが単純で正常に働くということで満足が得られることのほうが、もったいぶった最新技術をアプリケーションに組み込むだけのためにSOAPなどのテクノロジーの使いこなしに苦労するよりは、はるかにありがたいことです。いずれの場合にも、developerWorks XMLゾーンにはご注目ください。私は、SOAPの動向を綿密にチェックし、新しい展開があれは記事にする予定です。そして、他の開発者たちも、Soapboxについて語り始めることでしょう。

参考文献

• SOAPについて学習するには、W3C:SOAP 1.1 Note を読んでください。
  
  
• XML Apacheからの実装版をxml.apache.org から入手できます。
  
  
• IBMによるSOAP実装版とMicrosoftによる実装版は、MS SOAP SDK vs IBM SOAP4J とMS SOAP SDK vs. IBM/Apache XML-SOAP の2つの記事で比較することができます。
  
  
• XML-RPCの内部情報は、UserlandのXML-RPC Webサイトから入手できます。ここには、XML-RPCライブラリーもいくつか掲載されています。
  
  
• XMLとその関連テクノロジーに関するBrettの考えについては、彼の著作Java and XML を読んでください。
  
  
• IBMのWeb Services概況報告には、SOAPがWeb Servicesイニシアチブにどのように適用できるかが説明され、また他のリソースへのリンクが提供されています。
  
  
• Soapboxに関する意見がおありですか。読者のアイデアまたは草稿をゾーンの編集者Nancy Dunn、ndunn@us.ibm.com にお送りください。
  
  

著者について

Brett McLaughlin氏は、Logo (小さな三角形を覚えていますか?) の時代からコンピューターの仕事をしています。現在の専門は、JavaおよびJava関連のテクノロジーを使ったアプリケーション・インフラストラクチャーの構築です。ここ数年は、Nextel Communications and Allegiance Telecom, Inc. でこれらのインフラストラクチャーの実装に携わっています。Brett氏は、Javaサーブレットを使ってWebアプリケーション開発のための再利用可能なコンポーネント・アーキテクチャーを構築するJava ApacheプロジェクトTurbineの共同設立者の1人です。同氏はまた、オープン・ソースのEJBアプリケーション・サーバーであるEJBossプロジェクトと、オープン・ソースのXML Web公開エンジンであるCocoonにも貢献しています。

この記事を評価する

コメント

上に戻る

目次

• RMIそれともRPC
• 実用クラスのSOAP
• XMLに関する注意: ほかには何も要らない?
• 要約
• 参考文献
• 著者について
• コメント