従来、ソフトウェア・システム間の通信、中でも複数の異なる組織間の通信は、しばしば各種の一時しのぎで作ったメソッドやプロプラエタリー・プロトコルによる継ぎはぎ細工で行われました。このようなソフトウェア統合方法は、しばしば困難で高コストになり、また時間も掛かります。特に、企業のサポートを必要とする接続の数が多くなればこれが顕著になります。

Web Services展開の主たる目標の1つは、従来よりもはるかに大規模なシステム間通信を「パチンとつなぐ」ことができるような万能型のプロトコルを開発することです。SOAPはそのようなプロトコルの1つです。つまり、システム間通信のためのXMLベースのエンコードおよびエンベロープ標準を定義するプロトコルです。

このプロトコルの仕様が初めて紹介されてから、これまでに50種類を超えるSOAPツールキットが出現し、その数は今も増え続けています。これらのツールキットの数の多さと多様性を見れば、コンピューター社会がいかに迅速にSOAPを受け入れてきたかが分かります。しかし、SOAPの価値を完全に実現できるのは、これらのツールキット間のインターオペラビリティーが保証される場合だけです。

この記事では、ツールキットのインプリメンターがSOAPインターオペラビリティーの最前部で遭遇する課題のいくつかを提示し、これらの課題のいくつかを克服するためにこのコミュニティーがどのように協力し合っているかについて検討します。また、改良されたインターオペラビリティー環境が明確に示された場合のケース・スタディーも行います。

インターオペラビリティーの課題

アプリケーションはSOAPツールキット (通常、ライブラリーの形式になっている) を使用して、XMLベースのSOAPエンベロープを作成し、HTTPやSMTPなどのトランスポート・プロトコルを介してエンベロープを送信し、受信したSOAPエンベロープを処理します。エンベロープを作成し解釈する方法に関する想定が、2つのSOAPツールキット間で異なった場合は、インターオペラビリティーの問題が起こります。

たとえば、

• この2つのSOAPツールキットのいずれか、または両方が、SOAPまたはXMLの仕様の一部しか実装していない可能性があります。2つのSOAP間で、サポートされるフィーチャーに不一致があるかも知れません。この場合、一方のシステムが他方のシステムで処理できないようなSOAP文書を送信してしまいます。
• SOAP仕様では、ある種のものはオプションになっています。たとえば、エンコードされたパラメーターの型情報を送信するかはオプションです。一方のインプリメンテーションが、受け取るメッセージの中に型情報が入っていると想定している場合は、その情報を送信しない他方のインプリメンテーションとのインターオペラビリティーは不可能になります。
• 2つのインプリメンターは、SOAP仕様の言語があいまいな部分について、異なった解釈をする可能性があります。

結局、これらのインプリメンターは、スタンドアロン・テストでは検出されないバグを自分のツールキットに持つ結果となります。2つの異なるツールキットが通信しようとした場合に、こういったバグもインターオペラビリティーの問題を引き起こすことがあります。

上に戻る

ソリューション: 通信とテスト

この問題解決を手助けし、総体的なSOAPインターオペラビリティーを向上させるために、SOAPBuildersオンライン・グループが作成されました。SOAPBuildersグループの参加者は、IBMやMicrosoftといった大企業から独自のオープン・ソース・ツールキットを持った個人ユーザーにまで多岐にわたります。通信を増やし、クロス・ツールキット・テストの機会を提供するために、SOAPBuildersグループはツールキット・インプリメンター・コミュニティーに次のものを提供します。

• インプリメンテーションとインターオペラビリティーに関する問題を討議するためのフォーラムとして機能するメーリング・リスト
• インターオペラビリティー・テスト・スイート仕様
• テスト・サーバー・エンドポイントのディレクトリー
• テスト結果へのリンク

SOAPBuilders Interoperability Lab (ILAB) は、上記のようなインターオペラビリティー・テストをサポートするためのものです。ILABに関する詳しい情報は、参考文献セクションに示されているリンクから参照することができます。

上に戻る

SOAPBuildersテスト・スイート

リスト上の活動の中心にあるのは、SOAPBuildersインターオペラビリティー・テスト・スイートです。これは簡単な "エコー" SOAPリモート・プロシージャー呼び出し (RPC) の集合です。ここでは、クライアントが特定のタイプのパラメーター (整数、ストリングなど) を送信し、サーバーが同じタイプと値のパラメーターを戻します。そこでクライアントは、戻された値と自分が送信した値が一致するかどうかを調べます。図1 は、そのような1つのテストechoString の往復を示しています。

この往復を実行することにより、次のテストが行われます。

1. サーバーがクライアントのSOAPエンベロープを構文解析できるかどうか。
2. サーバーが、エンベロープに含まれているエンコード済みパラメーターを非逐次化(deserialize)できるかどうか。
3. クライアントが、サーバーから応答として送信されてきたSOAPエンベロープを構文解析できるかどうか。
4. クライアントが、サーバーから送り返されてきたエンコード済みパラメーターを非逐次化できるかどうか。

現在、エコー・メソッドは以下のデータ・タイプに対して定義されています。

• string
• integer
• float
• struct
• dateTime
• base64Binary
• stringの配列
• integerの配列
• floatの配列
• structの配列

クライアントは、サーバーと接続してテストを行うとき、各テストの成功または失敗の状況を記録します。多くのインプリメンターがそれぞれのクライアントの結果を公表しています (参考文献を参照)。テーブル1 は、ツールキット "X" で作成されたクライアントとさまざまなサーバーの間のサンプル結果を示しています。

上に戻る

テーブル1. サンプル・クライアント結果マトリックス

クライアント / サーバーのペアが1つ (または、すべて) のテストでインターオペラビリティーの失敗を経験すると、通常、問題がリスト上に報告され、コミュニティーはすぐに、その失敗の原因と訂正方法について検討します。

上に戻る

サンプル・インターオペラビリティー問題リスト

テストで見つかり、フォーラムで検討した問題の例を、下のリストに示します。これは完全なリストではありませんが、これまでに発生した問題の種類を示すサンプルにはなると思います。

1. HTTPと結合している場合に、SOAPは "SOAPAction" というHTTPヘッダーの使用を指示します。SOAP仕様に反して、一部のツールキットはSOAPAction HTTPヘッダー値を引用符で囲みません。このため、すべてのSOAPAction値は引用符で囲まれていると想定しているツールキットで問題が生じます。
2. SOAP仕様では、パラメーターの型情報をインライン(on-the-wire)で明示的に示すことを許していますが、必須ではありません。インライン型情報とは、SOAPメッセージ・エンベロープに直接型情報を入れることです。ツールキットによっては、非逐次化処理を行うために インライン型情報に頼るものもあれば、インライン型情報を送信しないものもありました。
3. SOAP仕様では、特定バージョンのXSD Schemaを使用するように指示してはいませんが、このことは、SOAP仕様の作成時点でXML Schema規格がまだ固定されていなかったことを考えれば、理解できます。あるツールキットが別のバージョンのXML Schema (たとえば、2001対1999) を使って送信したエンコード済みパラメーターを、別のツールキットが非逐次化できないことがあります。
4. 一部のツールキットは、他のツールキットから送信されたUnicodeのバイト・オーダー・マークを構文解析できませんでした。
5. 一部のツールキットは、受け取るSOAPエンベロープ内でのXML ID/HREF参照メカニズムの使用を処理できませんでした。

これらの問題とその解決の詳細については、SOAPBuildersメッセージ・アーカイブを参照してください (参考文献を参照)。

上に戻る

ケース・スタディー: SOAPインターオペラビリティーのデモンストレーション

コミュニティーの共同作業により、驚くほど短時間に、明確で具体的な結果が出ました。バグが見つかり修正されました。仕様の解釈が明確になりました。その結果、多くのツールキットに変更と修正のためのパッチが当てられ、インターオペラビリティーが改善されました。

このインターオペラビリティーの状態が改善されたことを明示するために、MicrosoftとIBMは、2001年5月のNetworld+InteropショウでSOAPインターオペラビリティー・イベントを共同で後援し、SOAPBuilderグループの作業を大きく展示し、いくつかのベンダーや個人も参加しました。このデモンストレーションでは、広範囲の各種プラットフォームからSOAPベースのクライアントとサーバーが使用されました。簡単な企業間状態を図2 に示します。

1. セラーが自分のプレゼンスをレジストリーに登録します。
2. バイヤーがすべての登録セラーのリストをレジストリーから検索します。
3. バイヤーがある品目についてセラーに見積要求を出します。
4. セラーが見積を送ります。
5. ステップ3～4は、バイヤーと他のいくつかのセラーとの間で繰り返されます。
6. バイヤーは、選択したセラーに対してその品目の購入オーダーを出します。

ビジネス・シナリオを定義した後、グループは、そのシナリオをサポートする方針に基づいたインターフェースを定義しました。次に各参加者は、このインターフェースをSOAP対応サービス・エンドポイントとして (セラーおよびレジストリー・インプリメンテーションの場合)、またはこのようなエンドポイントを使用できるクライアントとして (バイヤー・インプリメンテーションの場合) インプリメントし、バイヤー、セラー、およびレジストリーのアクティブ・ネットワークが生まれました。

このクロス・インプリメンテーション・インターオペラビリティー作業は、すでにSOAPBuildersグループで実行済みであったため、いくつかの異なるプラットフォームや言語 (Java、COM、.NET、Perl、など) をベースにした10個を超える数のツールキットを比較的容易に互いに結合することができました。

上に戻る

次のステップ

現在の形式のSOAPBuildersインターオペラビリティー・テスト・スイートは第1歩に過ぎず、今後さらに展開されていきます。今後のテスト・プロセスの展開では、以下のものが組み込まれる予定です。

• より広範囲のデータ・タイプをテストします (基本的には、現在W3C勧告状況にあるXML Schema仕様に定義されている完全な基本タイプ・セットを網羅します)。
• より興味深いSOAPのバリエーションをテストに組み入れます。
• ツールキットが標準のWSDLサービス記述に厳密に準拠できるかどうかをテストします。
• SOAPが現在 仕様の5節にあるメソッド呼び出し / パラメーター・エンコードに焦点を当てられているのに対して、より一般的な文書スタイルのSOAPを組み込みます。
• テスト参加者数の増加に伴い、テスト・プロシージャーとテスト・プロセスの自動化を追加します。

上に戻る

結論

インプリメンター間のコミュニケーションが改善され、ツールキット間テストが導入されたことにより、SOAPインターオペラビリティーの実態が大きく改善されました。SOAPインターオペラビリティー・テストは継続的に行われるプロセスです。その理由は、新規のインプリメンテーションが登場し、他の既存のインプリメンテーションが改善され、Web Servicesに関するインターオペラビリティー・テストの早期の例として役立つからです。まだ膨大な量の作業が残っていますが、コミュニティーは、SOAPインターオペラビリティーの継続した成長と改良を維持していくための堅固な基盤を築きました。

参考文献

• SOAPBuilders Yahoo Groupを訪問してアーカイブを読んでください。
  
  
• SOAPBuilders ILabページにアクセスして、テスト・エンドポイントとテスト結果へリンクしてください。
  
  
• SOAPBuildersTesting Proposal文書を読んでください。
  
  
• Paul Kulchenkoがsoaplite.comで維持しているSOAPインプリメンテーション・リストを調べてください。
  
  
• Web ServicesインサイダーからApache SOAPおよびMicrosoft SOAP Toolkitを入手する方法を学んでください。
  
  
• SOAP 1.1仕様を復習してください。
  
  
• IBM Systems Journalから抜粋したe-businessテクノロジーの傾向に関するこの記事で、R. A. Smithは、SOAPなどのテクノロジーの傾向が将来のWeb Servicesにどのような影響を与えるかについて検討しています。
  
  
• この白書Web Services Development Concepts (WSDC 1.0) は、サービス・プロバイダーやサービス・リクエスターの観点からWeb Services開発のアプローチを説明し、SOAPサービスの展開に関する情報を取り入れています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• インターオペラビリティーの課題
• ソリューション: 通信とテスト
• SOAPBuildersテスト・スイート
• テーブル1. サンプル・クライアント結果マトリックス
• サンプル・インターオペラビリティー問題リスト
• ケース・スタディー: SOAPインターオペラビリティーのデモンストレーション
• 次のステップ
• 結論
• 参考文献
• 著者について
• コメント