Web Servicesインサイダー: 第3回 ApacheとMicrosoft -見事に一体化

SOAP相互運用性の到来

James Snell氏は「Web Servicesインサイダー」の今回の記事で、ApacheとMicrosoftが見事に一体となって作動できることを示してくれます。同氏は、このためにMicrosoft SOAPツール・キットBeta 2を使って、ApacheのSOAPベースのWeb Servicesを、簡単に利用できることを見せてくれています。

James Snell (jasnell@us.ibm.com), Software Engineer, Emerging Technologies, IBM

James Snellは、IBMのEmerging Technologies Toolkitチームの一員です。過去2年間は、新興のWebサービス技術や標準などに焦点を当てており、またAtom 1.0仕様にも貢献しました。新興技術に焦点を当てたウェブログ、http://www.ibm.com/developerworks/blogs/page/jasnellを維持管理しています。



2001年 5月

このWeb Servicesの概念は、ようやく定着し始めています。しかし、実装で経験すれば分かるように、クロス・プラットフォームにおけるシームレスな相互運用性が、このテクノロジーの原動力となっていることを忘れてはなりません。これは、開発プラットフォームやプログラム言語に関係なく言えることです。相互運用性の課題に決着を付けなければ、様々なSOAPやWeb Servicesの実装は、通信面で行き詰まります。そうなれば、Web Servicesは、失敗例の一つに数えられることになるでしょう。

IBM、MicrosoftおよびApache

ご存じの方も多いと思いますが、昨年春に、IBMとMicrosoftの両社は、SOAP実装の最初のバージョンをリリースしました。(IBMは、後に、現在のApache SOAPプロジェクトを始めるためApacheにソースを無償で提供しました。) SOAPに関するマーケティング資料では、クロス・プラットフォームにおける相互運用性を確約していますが、ツール・レベルでは実現されていません。SOAPを実装する方法には、数々のバグや微妙な差異があり、2つのツール間で交信を行うことは、ほとんど不可能でした。しかし、これは変り始めています。Apache SOAPプロジェクトとMicrosoftのメンバーの共同の尽力のおかげで、相互運用性が議論の中心となってきました。初期の問題の多くは解決され、懸案だったいくつかの非互換性に関する問題も、間もなく解決される予定です。

ここで示す2つのサンプルを用いて実験を行うには、Apache SOAP (バージョン2.1)およびMicrosoft SOAPツールキットの最新のバージョン (Beta 2またはそれ以降) をダウンロードする必要があります。参考文献をご覧ください。


相互運用性 -- xsi:type属性の問題

Webアーキテクチャーを論ずるdeveloperWorksの他の記事にお読みになった方なら、以下のダイアグラムや、ダイアグラムが何を示しているかを当然熟知しておられるでしょう(これらの記事を読んでおられなければ、ライブラリーに是非目を通されてください。)

図1: Web Servicesアーキテクチャーの基本的なコンポーネント
図1: Web Servicesアーキテクチャーの基本的なコンポーネント

図1 では、Web Servicesアーキテクチャーの基本的な3つのコンポーネントによって達成される3つの基本的なオペレーションを示しています。

  • サービス提供者は、サービスをサービス・ブローカーに登録することによって、サービスを展開し、パブリッシュします。
  • サービスを要求者は、公開されたサービスのサービス・ブローカーのレジストリーを探してサービスを見つけます。
  • サービス要求者は、サービス提供者とバインドし、利用可能なサービスを消費 (使用) します。

Web Servicesの世界では、3つの各オペレーションは、互いに補足するが異なるテクノロジーを持っています。

  • パブリッシング・サービスは、Universal Description, Discovery and Integration (UDDI) APIを使用します。
  • ロケーティング・サービスは、UDDIおよびWeb Services Description Language (WSDL)を組み合わせて使用します。
  • サービスをバインドすることによりWSDLおよびSimple Object Access Protocol (SOAP)が強化されます。

最も基本的なレベルでは、バインド・オペレーションが3つの内で最も重要になります。これには、実際のサービスの消費 (使用) ということがかかわってきます。相互運用性に関する大多数の問題が発生するのは、この局面です。簡単に言えば、サービス提供者とサービス要求者の両方が、SOAP仕様を完全にサポートすれば、このような問題は解決され、シームレスな相互運用性が可能になるのです。

残念ながら、この単純なソリューションは、現実に起きている諸々の問題を通り越して、実装が簡単であると受け取られてしまいます。多数のオプション・コンポーネントを介してSOAPに組み込まれている柔軟性と、固有の複合した単純性のため、このソリューションを実装するのは、容易ではありません。MicrosoftやApache SOAPツールキットの間で起きたxsi:type 属性の問題を取り挙げてみましょう。この問題のためツール間の相互運用性が、一時期完全に失われました。

SOAPの仕様によれば、エンベロープに入っている各種エレメントは、そのエレメントに入っているデータ型を識別するため、オプションとして、xsi:type 属性を利用することがあります。提供者と要求者にとって、この情報をやり取りする手段が他にあれば、エンベロープにこの情報が入っている必要はありません。xsi:type 属性は、このデータ型が、他のどの手段を用いても通信できない場合に限って使われます。

この問題を解決するため、Microsoftは、外部サービスを記述する文書に依存関係を作り上げました。これによれば、データ型は要求者と提供者の両方からアクセスできました。Apacheでは、常にxsi:type 属性が含まれている必要がありました。

このアプローチの両方とも、「正当的なSOAP」ですが、(Apacheの実装で採られたアプローチは、正直なところ、正当的過ぎて柔軟性に欠けますが) 互いに互換性はありませんでした。Microsoftが 使用しているService Description Languageを、Apache SOAPは理解しなかったし、いまだにしていないことを付け加えておきます。なお、SDLは3回反復して検討されています。最初、この言語は、「Service Description Language」すなわちSDLと呼ばれましたが、後に「Service Contract Language」すなわちSCLと代わり、現在は 「Web Services Description Language」すなわちWSDLとなっています。

また、Microsoftは、ツールが生成したSOAPエンベロープにxsi:type 属性を簡単に追加するメカニズムを何も備えていませんでした。しかし、幸いなことに、何事も変るものです。現在、Microsoftには、新しく、かつ柔軟性に富むSOAP実装があります。これは、SOAPエンベロープの合成に対して、より良いサポートと、低レベルの制御を行います。Apacheは、xsi:type属性の存在を必要とする制約を取り除きました。その成果が、互いに自由に交信できる2つのツールとなって現れたのです。


拡張株式取引サービス、バージョン1

私たちが作成するサンプルは、無料のNASDAQ InfoQuotes Serviceに対するSOAPベースのインターフェースです。このサービスは、http://quotes.nasdaq.com で利用できます。この簡単なサービスは、HTMLまたはHTTP-GET要求を通じてXML形式の拡張された株式取引価格を提供します。このプロジェクトで使用するJavaおよびXMLソース・ファイルは、すべて参考文献の項にあります。図2 の画面例は、取引サービスから戻されたXMLデータを示しています。

図2: NasdaqQuotesからのXMLデータの画面例
図2: NasdaqQuotesからのXMLデータの画面例

NasdaqQuotes Web Servicesのバージョン1では、1つのgetQuotes メソッドを公開する簡単なJavaクラスを使います。これは、HTTP-GET要求の出力を文字として戻します。リスト1 にコードの抜粋を示します。


Web Servicesの展開

このJavaクラスをWeb Servicesとして展開するには、これをコンパイルし、Javaサーバーのクラス・パスにあることを確かめてください (ここでは、Apache SOAP 2.1が、既にインストールされ、構成済みであると想定しています)。以下のステップでは、サービスの展開方法と、これをMicrosoft SOAPから起動する方法を説明します。

ステップ1. Apache配置ディスクリプタの作成。Apache SOAP Service Managerは、展開されたサービスに関する情報を収集するため、配置ディスクリプタ (単純なXML文書) を使用します。リスト2 のNasdaqQuotesバージョン1.0サービスの配置ディスクリプタをご覧ください。

リスト2: XML配置ディスクリプタ
<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
                   id="urn:NasdaqQuotes">
  <isd:provider type="java"
                     scope="Application"
                     methods="getQuote">
        <isd:java class="NasdaqQuotes" static="false"/>
  </isd:provider>
  <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
  <isd:mappings>
    <isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
         xmlns:x="" qname="x:symbol"
         xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>    
  </isd:mappings>
</isd:service>

配置ディスクリプタXMLの構造に関する説明の詳細は、Apache SOAPの資料を調べてください。この例の<isd:mappings> の項に注意してください。Apache SOAPのxsi:type の制約が削除されています。ここで、私たちは、StringDeserializer クラスにマップするため、XMLエレメントsymbol を宣言しました。このクラスは、XMLエレメントの内容を、java.lang.String のインスタンスに変換します。この種の明示的なマッピングを使用すれば、Apache SOAPがマッピング情報を提供するためxsi:type を探さなくても済みます。すべてのXMLsymbol エレメントのインスタンスはStringsなので、それを非直列化します。

ステップ2. いったん配置ディスクリプタを作成したら、NasdaqQuotesサービスをサービス・レジストリーに展開するために、それを使用する必要があります。これを行うには、 このコマンド行命令を実行してください。

http://acme.com/soap/servlet/rpcrouter は、SOAP RPC ROUTERサーブレットのインストールに対応しています。NasdaqQuotesサービス・サーブレットは、展開されて、使用する準備ができているはずです。本稿に付属するzipパッケージで提供されたJavaベースのクライアントを起動すれば、このサービスをテストできます。readme.txtの説明を読んでください。

ステップ3. Microsoftのツールでは、サービスのインターフェースと場所を記述するWSDL文書が必要になります。Apache SOAPには、WSDLに対するサポートは、何も含まれていないので、2つの選択肢があります。特定のJavaクラス用のWSDLを生成するためIBM alphaWorksのWSDLツールキットを使用するか、ご自分でWSDLファイルを記述するかのどちらかです。私は、WSDLをご自分の手で記述する方をお薦めします。(リスト3 を参照) -- ご自分で書いてみればWSDLの構造や関数についてより深く知ることができるからです。良いXMLエディターをお求めなら、商用のXML-Spy製品を強くお薦めしますが、どのエディターでも構いません。

NasdaqQuotes.wsdl ファイルを修正したら、Microsoftツールの出番です。本稿が提供するZip内の、samp1e ディレクトリーに、nq.vbs およびvq.bat という2つのファイルがあります。 ファイルnq.vbs (リスト4 を参照) には、Microsoft SOAPツールキットを使用してNasdaqQuotesサービスを起動するためのコードが入っています。スクリプトには、43行のコードがありますが、最初の6行の中で (この6行の内4行は基本的な可変初期化コードからなります) SOAPが実際に起動します。見て分かるように、Microsoftは、これらのツールを簡単に使えるよううまく設計しています。

リスト4: Microsoft SOAPツールキットのnq.bvs
Set SC = CreateObject("MSSOAP.SoapClient")
SC.mssoapinit "D:\Services\NasdaqQuotesClient.wsdl", "", "", ""
Res = SC.getQuote(WScript.Arguments(0))

ユーザーは、nq.bat ファイルを実行し、問い合わせしたいシンボルをコマンド行パラメーターとして渡せばNasdaqQuotesサービスを起動できます (図3を参照)。

図3: コマンド行からNasdaqQuotesを実行する。
図3: コマンド行からNasdaqQuotesを実行する。

課題: NasdaqQuotesバージョン2

NasdaqQuotesサービス、バージョン1.0は、MicrosoftとApacheが互いに容易に交信できる能力を持っていることを示しています。しかし、Quoteサービスから戻る情報が、ストリング形式であるということは、サービス改善のため、さらなる作業が行われることを意味します。たとえば、SOAPエンベロープの本体が、Query結果をストリング形式でなくXMLフォームで戻すようにしたい場合もあるかもしれません。Zip形式のダウンロード・ファイルに入っている、NasdaqQuotes2サービスの例には、正しい方向へ踏み出すためにの第一歩が示されています。この例を詳細に調べて、何が行われているのか調べるのが、残された課題です。例によって、何らかの問題があったらお知らせください。お手伝できるかどうか見てみます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=242287
ArticleTitle=Web Servicesインサイダー: 第3回 ApacheとMicrosoft -見事に一体化
publish-date=052001