JP2009032253A - クライアント・サーバ・アーキテクチャに使用するためのミドルウェア - Google Patents

Abstract

【課題】新しく確立されたプロトコル・バージョンに依存する新しいソフトウェアモジュールを実装して、実際のアプリケーションで全体的な機能性を試験および検証する方法および装置を提供する。
【解決手段】クライアントからの要求を対応するサーバに転送し、かつサーバの応答を対応するクライアントに配送するクライアント・サーバ・アーキテクチャの中で使用するためのミドルウェアであって、どのサーバがどの種類のクライアントの要求に応答する機能を提供するかを示す対応付けリストを保持するためのマッピングモジュールを調べることにより、クライアントの要求を対応するサーバに対して送るためのモジュールと、種々のサーバから同じクライアントの要求に対する応答を受け取りかつ比較するためのコンパレータモジュールと、種々のサーバからの応答の間に不一致がある場合にエラー処理を実行するためのエラー処理モジュールと、を備える。
【選択図】図３

Description

本発明は、クライアント・サーバ・アーキテクチャに使用するためのミドルウェアに関する。

サーバ用コンピュータからの遠隔サービスを要求するクライアント用プログラムを有する分散形コンピュータ環境が、データ処理においては一般的に採用されている。図１は、そのような分散形環境を概略的に例示している。この環境では、ＰＣや携帯装置などの複数の様々なクライアントは、複数のサーバに接続して様々なサービスを要求することができる。サービス指向のアーキテクチャ（Service Oriented Architecture）（ＳＯＡ）では、クライアントおよびサーバは通常、ステートレス（stateless）の要求／応答パターンを用いるコンピュータネットワークのインフラ上のハイレベル通信プロトコル（ＯＳＩ参照モデル、レイヤー７）によってアプリケーション層において通信する。これにより、新しい要求事項が現れるのに応じて、提供されたサービスの機能性を徐々に増加させることが、普通の慣行となっている。コア機能（core functionality）に対するこれらの機能拡張は、通信プロトコルの修正と協調して行われる。内部接続形アプリケーション間の互換性の無さは、通信プロトコルが変わるとき、並びに、コンピュータのインフラの一部が置き換わるおよび更新されるときに生じる。幾つかのアプリケーションが新しいプロトコルをすでに実装する一方で、他のアプリケーションがなおも古いバージョンのままであることがある。

そのような例の１つには、例えば、ＤＩＧプロトコルがある。このプロトコルは、知識表現の分野で使用されるものであり、推論（reasoning）はバージョン１．０からＤＩＧ２．０と呼ばれる新しく拡張されたバージョンに更新されたばかりである（例えば、２００６年１１月のISWC'06におけるOWL Experiences and Directions Workshopのプロシーディング、Turhan, A., Bechhofer, S., Kaplunova, A., Liebig, Th., Luther, M., Moller, R., Noppens, O., Patel-Schneider, P., Suntisrivaraporn, B., および Weithoner, T.による「DIG2.0 - towards a flexible interface for Description Logic reasoners」を参照されたい）。ＤＩＧプロトコルのようなプロトコルを更新することは、結果として多数の協同使用が可能でないクライアントおよびサーバの構成要素を生じさせ、この状態はこれらのモジュールのそれぞれが新しいインターフェース仕様に対応するように更新されるまで続く。

さらに、ＤＩＧプロトコルの具体例では、前身のバージョン１．１（例えば、いわゆるトウルド機能性（told functionality））の一部ではないＤＩＧ２．０におけるプロトコルの部分は、プロトコル・バージョン間を移行する段階の間、現行のＤＩＧ１．１の構成要素に対して有用である可能性もある。クライアントがＤＩＧ２．０でのみ対応されているこれらの機能を利用できるようにするために、ミドルウェアのアーキテクチャはＤＩＧ１．１の構成要素を、失われた機能を提供する構成要素に組み合わせる（このとき、実際のプロトコル変換も用いる）。

新しく確立されたプロトコル・バージョンに依存する新しいソフトウェアモジュールを実装して、実際のアプリケーションで全体的な機能性を試験および検証することは極めて興味あることである。本発明は、そのようなシナリオの中で試験環境を与える新しい方法および装置を提供する。

１つの実施形態によれば、クライアントからの要求を対応するサーバに転送し、かつサーバの応答を対応するクライアントに配送するクライアント・サーバ・アーキテクチャにおいて使用する装置が提供される。前記装置は、
どのサーバがどの種類のクライアントの要求に応答する機能を提供するかを示す対応付けリストを保持しているマッピングモジュールと、
正しいサーバを識別するために、前記マッピングモジュールを参照することにより、クライアントの要求を対応するサーバに対してルーティングするためのモジュールと、
同じクライアントの要求に対する応答を種々のサーバから受け取りかつ比較するためのコンパレータモジュールと、
種々のサーバからの応答の間に不一致がある場合にエラー処理を実行するためのエラー処理モジュールと
を備えており、あるクライアントの要求に対して、クライアントの要求に応答できるサーバが複数あることを前記マッピングモジュールが示す場合、前記クライアントの要求が少なくとも２つの前記サーバに転送される。

種々のサーバ、要求の分布および結果の評価をマッピングすることにより、クライアント−サーバの同一でないアーキテクチャに対して試験環境を提供することができる。この試験環境においては、種々のプロトコルを用いて実装される様々な機能があり、また残された機能もカバーする更新されたプロトコルが、正確さの面からチェックされる。試験は現場で行うことができ、一方で、２つのシステムの並列動作によりフェイルセーフ機構が設けられるため、まだ十分な試験が行われていない新しいシステムが使用される場合に通常起こりうる災難を避けることができる。

この装置は、コンピュータ上で動作すると共に、コンピュータのマイクロプロセッサおよび記憶装置と一緒に装置の機能を実行するいわゆる「ミドルウェア」に実装される。いわゆるミドルウェアは、ソフトウェアの構成要素すなわちアプリケーションを結合するコンピュータのソフトウェアである。このソフトウェアは、１つ以上の装置上で動作する複数の処理がネットワークを通じて相互作用できるようになるようにするような使用可能なサービスの集合により構成される。この技術は、分散形アーキテクチャへ整合性を保って移行するのをサポートしつつ、相互運用性を提供するように進化してきた。これらアーキテクチャは、複雑で分散したアプリケーションを支援および単純化するために極めて頻繁に使用される。その技術には、ウェブ用サーバとアプリケーション用サーバとアプリケーションの開発および配送とを支援する同様のツールが含まれる。ミドルウェアは、XML、SOAP、Webサービスおよびサービス指向のアーキテクチャに基づいた最近の情報技術にとって特に不可欠である。

マッピングモジュールは、どのサーバがクライアントの要求の種類に応答する機能を提供するかを示す対応するリストを含むテーブルを記憶する記憶手段によって実現することができる。

ルーティングするためのモジュールは、コンピュータプログラムに基づいてマッピングモジュールを調べるマイクロプロセッサによって実現することができる。このコンピュータプログラムは、マイクロプロセッサの動作を制御しかつ記憶手段の中に記憶される。

コンパレータモジュールは、マイクロプロセッサが比較できるように応答を記憶する記憶装置と一緒にマイクロプロセッサによって実現することができる。

エラー処理モジュールは、記憶装置と一緒に、マイクロプロセッサによって実現することができる。この記憶装置は、エラーが発生したことが判明した応答内の相違による比較に基づいて、どのエラーに基づいてどのエラー処理を行うべきかを例えばテーブルの中に記憶している。

１つの実施形態によれば、前記エラー処理モジュールには、エラーとなった応答に関する情報を記録する機能が含まれる。

これにより、発生したエラーを分析することができ、また新しいシステムの構成要素を改良するのに役立つ。

１つの実施形態によれば、前記サーバは少なくとも２種類のサーバを具備し、前記２種類のサーバが互いに異なるプロトコルを通じて少なくとも部分的に同じ機能を提供し、一方の種類のサーバは古いプロトコルバージョンを用いるサーバであり、もう一方の種類のサーバは新しいプロトコルバージョンを用いるサーバであり、ミドルウェアとして動作する前記装置および前記２種類のサーバが、両方の種類のサーバによって提供されるこれらの機能に対して前記第１および前記第２の種類のサーバからの応答を前記コンパレータモジュールを通じて比較することにより前記新しいプロトコルバージョンに対する試験環境として使用されるようになっている。

この方法では、完全な試験環境を設けることができる。

１つの実施形態によれば、前記装置は、
クライアントからの要求を受け取るための１つ以上のクライアント用アダプタと、
前記クライアントの要求を前記ミドルウェアの内部表現に変換するための変換フレームワーク（transformation framework）と、
前記ミドルウェアの前記内部表現からの要求を、要求が配送されるサーバが理解する言語に変換して、かつ変換されると前記要求を前記サーバに配送する１つ以上のサーバ用アダプタと
をさらに備えている。

この方法では、プロトコルの取次（mediation）および種々のプロトコルバージョンとに準拠することができる。

１つの実施形態によれば、このミドルウェアは、
新しい構成要素を用いて前記ミドルウェアの拡張を可能にするための拡張フレームワークであって、新しいサーバ用アダプタが装着される場合、新たに装着されたサーバ用アダプタを介して処理することができる種類の要求に関する新しいルートについて前記マッピングモジュールに対して自動的に通知がなされ、それに応じて新たに装備されたあらゆるクライアント用アダプタが始動するように適合されている前記拡張フレームワークを更に含んでいる。

この方法では、新しい構成要素を取り付けることによって、システムを自動的に容易に拡張し得るようにする。

１つの実施形態によれば、クライアントからの要求を対応するサーバに転送し、かつサーバの応答を対応するクライアントに配送する、クライアント・サーバ・アーキテクチャの中で使用する転送方法が提供される。前記方法には、
どのサーバがどの種類のクライアントの要求に応答する機能を与えるかを示す対応付けリストを保持するステップと、
正しいサーバを識別するために、対応付けリストを参照することにより、クライアントの要求を対応するサーバに向けてルーティングするステップと、
種々のサーバからの同じクライアントの要求に対する応答を受信および比較するステップと、
種々のサーバからの応答の間に不一致がある場合、エラー処理を実行するステップと
が含まれ、特定のクライアントの要求に対して、前記クライアントの要求に応答できるサーバが複数あることを前記リストが示す場合、前記ミドルウェアは前記クライアントの要求を少なくとも２つの前記サーバに転送する。

１つの実施形態によれば、前記エラー処理を実行するステップには、エラーが発生した応答に関する情報を記録するステップが含まれる。

１つの実施形態によれば、前記サーバは少なくとも２種類のサーバを具備し、前記２種類のサーバは互いに異なるプロトコルを通じて少なくとも部分的に同じ機能を行い、一方の種類のサーバは古いプロトコルバージョンを用いるサーバであり、もう一方の種類のサーバは新しいプロトコルバージョンを用いるサーバであり、前記ミドルウェアおよび前記２種類のサーバが、両方の種類のサーバによって提供されるこれらの機能に対して前記第１および前記第２の種類のサーバからの応答を前記コンパレータモジュールを通じて比較することにより、前記新しいプロトコルバージョンに対する試験環境として使用されるようになっている。

１つの実施形態によれば、この方法は、
１つ以上のクライアント用アダプタによってクライアントからの要求を受け取るステップと、
前記クライアントの要求を前記ミドルウェアの内部表現に変換するステップと、
前記ミドルウェアの前記内部表現からの要求を、要求が配送されるサーバが理解する言語に変換するステップと、変換されると前記要求を１つ以上のサーバ用アダプタが前記サーバに配送するステップと、をさらに含む。

１つの実施形態によれば、この方法は、
新しい構成要素を用いて前記ミドルウェアの拡張を可能にするステップをさらに含み、前記拡張フレームワークは、新しいサーバ用アダプタが装着される場合、新たに装着されたサーバ用アダプタを介して処理することができる種類の要求に関する新しいルートについて前記マッピングモジュールに対して自動的に通知がなされ、それに応じて新たに装備されたあらゆるクライアント用アダプタが始動するようになっている。

１つの実施形態によれば、実行されると前記コンピュータに本発明の１つの実施形態による方法を実行させることができるコンピュータプログラムコードを含むコンピュータプログラムが提供される。

以下に、本発明の実施形態を説明する。

本発明の１つの実施形態によれば、一方ではソフトウェアの構成要素用の種々のバージョンの通信プロトコル間の取次ぎを行い、その一方、費用効率の高い自動ソフトウェア試験に対応するミドルウェアのアーキテクチャが提供される。１つの実施形態によれば、そのようなミドルウェアのアーキテクチャは、要求されたサービスに依存する要求メッセージの分割およびルーティングを実行する。

本発明の実施形態による解決策を適用することができるシナリオの実施例は、ＤＩＧインターフェースの開発である（例えば、Bechhofer, S., Moller, R., Crowther. P.による「The DIG Description Logic Interface」、Calvanese, D. らによる Proc. of the Int. Workshop on Description Logics (DL'03)、ローマ、イタリー、２００３年、を参照されたい）。ＤＩＧインターフェースは、記述論理知識ベース（Description Logic knowledge base）の送信および取合わせを行うためのＸＭＬベースのプロトコルである。以下に、ＤＩＧインターフェースの特定のプロパティが参照されるが、これは単に例示的な目的のためになされるのであって、任意の他のプロトコルまたはインターフェースも同様に、本発明の実施形態に関連して使用できることは理解されよう。

１つの実施形態によれば、プロトコルが進化することによって生じる通信の問題は、クライアントとサーバとの間に配置される、一般的にミドルウェアである構成要素によって解決される。配列、分割および種々のプロトコルバージョンの変形といった特徴の集合に加えて、１つの実施形態によるアーキテクチャは、試験環境として動作することができる。このことは、全く同一のプロトコルまたはその部分の複数の構成要素を結合することによって実現される。要求（リクエスト）が、全ての登録された構成要素に対して渡され、戻り（リターン）となる応答が、リファレンスとなる実装形態と比較および点検される。プロトコルのセマンティクスに依存するが、ミドルウェアのアーキテクチャは、戻される応答に相違が検出されると様々な動作を行う。そのために、新しいシステムは従来のシステムと並行して動作し、これにより生成された応答が正しいことを連続的にモニタすることが可能となる。更新されたインフラは、新しいプロトコルバージョンにのみ対応することができる次世代のクライアントを含むことができる。そのような設定の中で、クライアントの要求は、１つの実施形態によれば、下記の特性を提供する取次用ミドルウェアに向けられる。
＊異なるプロトコルバージョン間の取次。
＊それぞれのサーバの構成要素に対するルーティングの要求。これによりミドルウェアは、要求されたサービスが対応されている場合、種々のシステムに要求を転送することができる。
＊１つのプロトコルバージョンにおいて、異なる機能が１つのサーバの構成要素によって与えられる場合、別のプロトコルバージョンにおいて異なるサーバの構成要素が要求されると、要求の分割や応答のリアセンブルが行われる。
＊システムは、異なるシステムからの応答を監視する。結果的に相違が検出および報告される。応答が異なる場合、１つの実施形態によれば、クライアントに送り戻される最終的な応答が、優先されたシステムから構成される。例えば、３つ以上のシステムが含まれる場合、多数決が実現可能な選択である。
＊標準的なインフラの特注の拡張に対処するために、容易に拡張できる。

上記の特徴の組合せにより、通常の動作の間に新しいインフラの試験が可能にされ、システムがその場で本物で実際のデータを用いて試験されるため、人為的な試験の状況を作り出す必要がないという付加的な利点がある。

このことは、通信プロトコルを更新するためにソフトウェアの構成要素を適合させ、および試験することを容易にすると共に、プロトコルの共通部分に対して所定のインフラを引き続き用いつつ、ソフトウェアの製造が自身の拡張部分を用いて所定のプロトコルを拡張できるようにする。

そのような解決策では、その取次機能と並行して、新しい構成要素が検証および一体化されることができる。後者は、分散されたアプリケーションフレームワークのシームレスのプロトコル更新に対して有用なサービスである。

ここで、本発明の実施形態を、図２に関連してある程度より詳細に説明する。図２は、本発明の実施形態に基づいて、ミドルウェアの構成要素を通じてサーバに接続できる幾つかのクライアントを示している。

クライアントは、要求されたサービスの位置（location）を知っているミドルウェアに全ての要求メッセージを伝える。ミドルウェアは、入力された要求メッセージを入力キューを通じて受け取り、次にルーティングコンポーネントを用いて入力された要求メッセージを個々の要求に分割し、個々の要求メッセージの中にこれらの要求を含ませて、そして対応するサーバにリダイレクト（ルーティング）する。対応するサーバが要求を処理すると、ミドルウェアは、全ての応答を再度アセンブルして、結合された応答メッセージを適当なクライアントに返送する。

さらに、ミドルウェアは、種々のプロトコルバージョンに対応するために、自動的なプロトコル変換を実行する。要求されたルーティング情報および変換器とともに新しいクライアントまたはサーバ用アダプタを加えるために、プラグイン機構（図示せず）によってミドルウェアを拡張することができる。このプラグイン機構を使用して、「ロード拡張部」として図２に例示されている新しいコンポーネントを取り付ける。

ある実施形態により示される適応性のあるプロトコル取次および試験に対するミドルウェアのアーキテクチャには、下記のコンポーネントが含まれている。
＊クライアント用アダプタ
＊変換フレームワーク
＊ミドルウェアのコアおよび試験方法
＊サーバ用アダプタ
＊拡張フレームワーク

これらのコンポーネントの動作は、下記のように説明される。

クライアントが要求を送信すると、その要求は、まず、クライアントが述べるプロトコル（例えば、ＨＴＴＰを介してＸＭＬとして直列化されたＤＩＧ１．１）に対応するクライアント用アダプタに接続される必要がある。クライアント用アダプタは変換フレームワークを使用して、入力されたメッセージをミドルウェアのコアの内部表現に変換する。次に、変換されたメッセージがミドルウェアのコアに引き渡され、ここで要求メッセージが別個の要求に分割される。次に、これらの単一の要求は、処理されるためにキューに入れられる。要求がキューの中で待機すると、ミドルウェアのコアのルーティングコンポーネントが要求をキューから取り出し、その要求に関連するルーティング情報を調査してそれぞれのサーバ用アダプタに送る。サーバ用アダプタはサーバに接続され、サーバは最終的に要求を処理する。要求を実際に送信する前に、サーバ用アダプタは、場合によっては、変換フレームワークを用いて要求を適切な目標言語に変換する必要がある。同様に、サーバから返送される応答メッセージは、ミドルウェアのコアに渡される前に変換されなければならない。

ミドルウェアのコアは受け取った全ての応答を集めて、その応答メッセージをアセンブルする。これは、本来のクライアント用アダプタに引き渡される。次に、クライアント用アダプタは、（必要な場合）それぞれのクライアントの言語への最終的な変換処理を行い、最後に完全な応答メッセージを返送する。

ある実施形態によれば、複数のサーバ用アダプタが特定の種類のサーバに対して登録される時はいつも、要求に対する特別な取扱いがなされる。そのような場合は、ミドルウェアのコアのルーティングコンポーネントは、要求を幾つかの、１つの実施形態によれば、全てのこれらのサーバ用アダプタに送る。このため、種々のサーバが、（エラーのため、または実装が異なるために）まちまちな応答を返送する可能性があるため、１つの実施形態によれば、多数決が最終的な応答を制御することができる。例えば、絶対多数のサーバによる応答が返送されない場合は、エラーメッセージが応答メッセージの中に含まれる。

１つの実施形態に基づいてそのように実装することは、古いプロトコルに基づいて動作するサーバからの応答を新しいプロトコルで動作するサーバから戻された応答と比較することにより、新しいプロトコルを実装することに対する「テスト用基盤（test bed）」としての機能を果たすことができる。相違が生じない限り、新しい（更新された）プロトコルを正しく動作すると判断することができる。しかしながら、何らかの不一致が生じると、不一致が生じている理由が何であるかを判断するために、それらの応答は記録および評価される。この方法では、新しいプロトコルでのエラーは、「実際の」動作の中で決定することができる。

以下に、図２で示されているシステムの幾つかのコンポーネントをより詳細に説明する。

［クライアント用アダプタ］
クライアント用アダプタは、図３に概略的に示されている。このクライアント用アダプタは、ミドルウェアの着信する通信の終点を示し、別個のスレッドで動作する。クライアント用アダプタの実装はコンピュータのＴＣＰ／ＩＰポート（例えば、ＨＴＴＰ通信用のポート８０）にバインドされて入力される要求があるかリスンする。

要求が受け取られるといつでも、クライアント用アダプタは、さらなる処理ステップを取り扱う新しい子スレッドを作る。最初、この子スレッドは、着信メッセージをミドルウェアのコアが話す言語に翻訳する必要がある。このため、この子スレッドは変換フレームワークの中のマッチング変換器を調べる（例えば、XML-StreamとしてＤＩＧ１．１からDocument Object ModelとしてＤＩＧ２．０まで）。ミドルウェアのコアが翻訳対象を定義する間に、クライアント用アダプタは、デフォルトの着信メッセージの言語を知る必要があるか、またはメッセージを分析することによってその言語を決定する必要がある。１つの実施形態によれば、両方の方式は対応されているが、全てのプロトコルおよび言語に対して別個のクライアント用アダプタを設けて、適当な変換器を始動時に識別できることが好ましい。この場合、全ての要求メッセージに対して、選択を繰り返す必要はない。

正しい変換器を検索した後、ミドルウェアのコアの内部表現に翻訳するために、メッセージはこの変換器に送られる。次に、翻訳されたメッセージは、処理するためにミドルウェアのコアに送られる。メッセージが処理される間に、クライアントのスレッドは実行を中止する。応答が完了すると、クライアントのスレッドは実行を続けるよう通知され、応答メッセージをコアから取得する。次に、メッセージは変換フレームワークから適合している変換器を用いて翻訳され、最終的にクライアントに送られる。

［変換フレームワーク］
図４に概略的に例示されている変換フレームワークは、十分に動作可能なインターフェースを介してアクセスすることができる変換器の容器として説明することができる。各変換器は、ある言語の入力メッセージを別の言語の出力メッセージに翻訳することができる。この変換フレームワークは、いわゆる変換器シグネチャー（transformer signature）に基づいて、全ての利用可能な変換器から特定の変換器を選択するためのインターフェースを提供する。このシグネチャーは、２つの言語識別子から構成する、すなわち１つはソースであり他の１つは対象言語に関する識別子である。１つの実施形態によれば、言語識別子は、任意に選択することができるがミドルウェアの全体にわたって明白でなければならない。

［ミドルウェアのコアおよび試験方法］
図５に示されているように、１つの実施形態によるミドルウェアのコアは、下記のコンポーネントを備えている。
＊要求メッセージ用プロセッサ
＊要求メッセージ用スプリッタを有する要求キュー
＊ルータ
＊応答用アセンブラ

ミドルウェアのコアの動作を、ここで図５を参照して説明する。

要求メッセージがクライアント用アダプタから渡されると、要求メッセージ用プロセッサは、メッセージをさらに処理する制御を受け継ぐ。最初に、メッセージは（必要な場合）要求メッセージ用スプリッタを用いて幾つかの個々の要求に分割される。次に、これらの個々の要求は、要求キューの中に入れられる。

要求用ルータは別個のスレッドとして実施される。この別個のスレッドは、最初にスリープモードになり、新しい要求が入ると、要求キューによって動作が再開することが知らされる。ルータは全ての有効な要求を次々にキューから取り出して適当なサーバ用アダプタに送る。そのため、ルータは、それぞれの要求を処理することができる特定のサーバに関連付けられた内部の種類のリストを用いて要求の種類を確認する。

複数のサーバ用アダプタが所定の要求の種類に対して登録される場合、この種類の全ての要求は全てのこれらのサーバ用アダプタに送られる。さらに、要求を複数のサーバ用アダプタに送る必要がある場合は、ルータは幾つかの子スレッドを作って、その要求を並列に処理する。

ルータは、全ての要求を応答用アセンブラに渡す。この応答用アセンブラは、要求キューから応答用アセンブラに送られる「new」によって示される要求キューで管理される実際の要求の数が通知される。全ての応答が処理されると、ルータは個々の応答から応答メッセージを作り、それぞれのクライアント用アダプタが利用できるようにする（動作を再開することをアダプタに知らせる）。

ここで、異なる応答メッセージを評価するために異なる方法を実行できる応答の評価が実施される。これは、エラーロガーをさらに含む「応答コンパレータ」モジュールによって実行される。エラーコンパレータは、複数のサーバからの応答が同一であるか否かについて比較する。応答の間に相違がある場合は、エラーコンパレータは例えば、プロトコルの更新されたバージョンを実行する場合にエラーがあると指摘する。リファレンス実装となるように動作し、エラーが発生しないことが知られているようなプロトコルのより低いバージョンがある場合には、この結論を導き出すことができる。次に、同じ機能を実現するためにサーバに対して実装される同じプロトコルのより高いバージョンが異なる応答を配送する場合、それは、より高いレベルのプロトコルでエラーが示されているものと判断することができる。この点は、この不一致が生じた理由を後で詳細に調査するために少なくとも記録される（例えば、エラーロガーを用いる）。このために、データ（例えば、応答およびエラーメッセージ、また成功した応答のログ）は、図５において「試験結果／バグレポート」として示されているデータベースの中に化に記憶される。

クライアントに応答を配送することに関しては、等価の応答を計数しそして計数が最高の応答を選択することによって、例えば、最終的な応答を応答の組から選択することができる。応答が投票の絶対多数（５０％より多い状態）とならない場合、エラーメッセージを発生することができる。

１つの実施形態によれば、（幾つかの応答がなおも欠けているため）所定の時間間隔内に応答メッセージをコンパイルすることができない場合、その欠けている部分は、対応するエラーメッセージを用いて応答用アセンブラが補完することができる。

［サーバ用アダプタ］
サーバ用アダプタは、特定の要求の種類の組を処理する機能を担うサービスへの接続を確立する。サーバ用アダプタは要求メッセージを受け取って、サーバが用いる言語に翻訳し、そのメッセージをサーバに送信し、そしてサーバから受け取った応答を返す（応答を本来のフォーマットに戻すように翻訳した後に）。ＤＩＧ１．１ＨＴＴＰ形サーバ用アダプタは、ＨＴＴＰを介してＸＭＬ直列化ＤＩＧ１．１メッセージをリーズナー（reasoner）に送り、推理結果をミドルウェアのコアに返すサーバ用アダプタの典型的な例を示す。翻訳の目的のために、１つの実施形態によるサーバ用アダプタは変換フレームワークを参照する。この変換フレームワークは、図４に関連してすでに説明されている。

［拡張フレームワーク］
拡張フレームワークは、ミドルウェアの機能を動的に拡張することができる。拡張部分は、任意の数の変換器およびクライアントおよびサーバ用アダプタを含むプログラムライブラリから構成する。各拡張部分は、指定されたインターフェース（工場インターフェース）を実装している。これにより、ミドルウェアは指定されたコンポーネントをライブラリからロードすることができる。

サーバ用アダプタがロードされる場合、ミドルウェアのコアのルーティングコンポーネントに対しては、新たにロードされたサーバ用アダプタを介して処理することができる種類の要求に対する新たなルートについて自動的に通知される。拡張部分からロードされた全てのクライアント用アダプタは、そこで始動され（別個のスレッドとして動作する）、要求を処理するためにクライアントからこのように接続されることができる。拡張部分から直接ロードされた変換器は、全てのクライアントおよびサーバ用アダプタが利用できるようになる。拡張フレームワークは、図２で「ロード拡張部」として概略的に例示されている。

［試験シナリオ］
ここで、本発明の実施形態が試験を行うために使用されるシナリオを説明する。図６は、クライアント・サーバのインフラの実際のサイクルにおける４つの典型的な段階を示している。最初（図６の１）、サーバはサービスの組（Ｆ１、Ｆ２、およびＦ３）を、これらのサービスを要求するクライアントの組に提供する。ここでは、プロトコルバージョンｖ１が通信用に使用される。そのうちに、新しい要求事項が生じると（図６の２）、サーバの機能が拡張部を用いて拡張されて、新しいサービス（Ｆ４およびＦ５）が提供される。これらの新しいサービスにアクセスするために、新しい拡張部に対応できる少しばかり豊かになった通信プロトコル（プロトコルバージョンｖ１＋）を用いて、クライアントを更新する必要がある。

一定時間の後、現行のプロトコルを新しい強化されたよりメジャーなバージョン（ｖ２）に更新する必要がある。このバージョンは、新しい機能（Ｆ６およびＦ７）を有し、かつ以前は拡張部分（Ｆ４およびＦ５）としてのみ利用可能であった機能も組み入れている（図６の３）。

新しいインフラを試験するため、機能Ｆ１〜Ｆ５に関する全ての要求を古いインフラに仕向けるために、ミドルウェアのコンポーネントが導入される。この古いインフラは、新しいシステムに加えてリファレンスシステムとして動作している。これが意味するのは、機能Ｆ１、Ｆ２またはＦ３に向けられたクライアントの要求が、サーバｖ１および付加的にサーバｖ２に向けられることである。同様に、機能Ｆ４に向けられた要求はコンポーネントの拡張部４および更にサーバｖ２に向けられ、機能Ｆ５に向けられた要求は拡張部Ｆ５およびサーバｖ２に向けられる。

このことは、「古い」または「従来の」システムＦ１〜Ｆ５の機能に向けられた要求に対しては、２つの応答、すなわち１つは古いシステムからそして１つは新しいシステムからの応答があることを意味する。

次に、ミドルウェアは戻されたメッセージに対して何らかの評価を行い、そして１つの実施形態によれば、その評価に基づいて何らかの結論を引き出す。評価を実行する場合、ミドルウェアは種々のシステムから戻された応答（例えば、サーバｖ２から得られた機能Ｆ１〜Ｆ５からの応答と「古いシステム」からの対応する応答）を比較し、そしてそれらの応答が意味的に等価であるかどうかを決定する。等価である場合、これは不一致が存在しない、またこれにより「エラー」が存在しないことを意味し、従って新しいシステムからの応答はクライアントに送られる。しかしながら、等価でない場合は、何らかのエラーが発生していると結論付けられて、エラー処理が実行される。

１つの実施形態によれば、このエラー処理は、リファレンスシステム（「古いシステム」によって形成された、例えば、Ｆ１〜Ｆ５）からの応答が、新しいプロトコルに翻訳されて（ｖ１からｖ２への取次）送られることである。そのような場合は、ミドルウェアは要求、（リファレンスシステムによって作られるような）予想される応答、および新しいシステムからの間違った応答から成るエラー報告書を作成することができる。このエラー報告書はデータベースに記録されて、後で分析してエラーの原因を特定することができる。

こういう具合に、プロトコルの新しいバージョンに対するテスト用基盤が実現される。古いバージョンは並列に動作して、新しいプロトコルが応答の間の不一致により間違った結果を発生した場合に示すフェイルセーフ機構としての機能を果たす。このことは、並列に動作している冗長な「従来の」システムが、不一致が生じた場合にシステムに通知する、またそのような場合の「新しいシステム」からの応答は「注意して取り扱われる」または廃棄されるため、生産性に対してエラーが生ずる危険なしに、試験を実際にシステムの「通常の動作」の間に実行できるという利点がある。

さらに、新しいシステムを「現実に」使用する間に試験データを得ることができ、次にこのデータを後で分析して、エラーの原因を特定することができる。こういう具合に、この試験は新しいシステムの改良に役立つ。

１つの実施形態によれば、別の方法の「エラー処理」も可能である。例えば、同じ要求に対して異なる応答がある場合、種々の別個の応答を「計数」して、応答のうちの１つが絶対多数になるかまたは数の計数の点で他の所定の基準を超える場合、この応答は「正しい応答」として扱われるように選択される。

Ｆ１〜Ｆ７などの特定の機能用に３台以上のサーバが実装されることができ、応答の評価には「多数」または正しい応答に関する他の指標を求めるような統計分析が利用されることは理解されよう。

説明された「試験環境」は、新しいシステムのコンポーネントが正しく動作するかどうかを評価するために使用することができる。

新しいシステムのコンポーネントが成功裏に試験された後で、古いモジュールの使用は停止され、全体のライフサイクルが最初から開始される（図６の４）。

すでに前述したように、本発明の実施形態に対する１つのアプリケーションのシナリオは、ＤＩＧプロトコルであるが、当業者は別のアプリケーションのシナリオを容易に想像することができる。

以下に、取次用ミドルウェアのアーキテクチャに対するサンプル・アプリケーションを説明する。ＤＩＧリファレンスミドルウェア（Reference Middleware）（ＤＩＧ ＲＭＷ）は、異なるＤＩＧ言語の間−−すなわちＤＩＧ１．１とＤＩＧ２．０との間−−を取次する。ＤＩＧは、知識表現および推論の分野で使用されるプロトコルである。ＤＩＧ１．１は、オントロジー（リーズナー）に対して推論サービス（reasoning service）を提供するオントロジーエディタ（ontology editor）およびシステムの通信に対する今日のデファクト・スタンダードである。更新されたＤＩＧ２．０規格は新しい機能を加え、かつ言語を調整して、良く適合されたウェブオントロジー言語（Web Ontology Language）（ＯＷＬ）の次のバージョンに適合する（例えば、Bechhofer, S., von Harmelen, F., Hendler, J., Horrocks, I., McGuiness, D., Patel-Schneider, P., Stein, L.による「OWL Web Ontology Language Reference」、W3C Recommendation、２００４年、を参照されたい）。

ＤＩＧ ＲＭＷに対する典型的な設定は、新しい実験的なＤＩＧ２．０、古いＤＩＧ１．１のクライアントおよびＤＩＧ１．１のリーズナーから構成する。ＤＩＧ１．１のリーズナーは、ＤＩＧ２．０トウルド・モジュール（Told Module）によって補足される。このトウルド・モジュールは、ＤＩＧ１．１では利用できないが、ＤＩＧ２．０拡張部として標準化されているトウルド公理取合わせ能力（told axiom query capabilitｙ）を実装する。この設定では、ＤＩＧ２．０のクライアントは、標準的な推論サービス（ＤＩＧ１．１のリーズナーによって提供される）および前述したトウルド機能（told functionality）にアクセスできなければならないが、古いＤＩＧ１．１のクライアントは完全に動作可能な状態にある。

この作業を達成するには、ＤＩＧ ＲＭＷは２つのクライアント用アダプタ、すなわち１つのアダプタとしてはＤＩＧ１．１用を装着し、そして他のアダプタとしてはＤＩＧ２．０用のアダプタを装着する。両方のアダプタは、ＸＭＬとして直列化されたＤＩＧ要求メッセージを含む着信するＨＴＴＰ要求を異なるＴＣＰポートでリスンしている。ＤＩＧ２．０はＤＩＧ１．１のスーパーセットであるため、このＤＩＧ２．０言語は、ＤＩＧ ＲＭＷの内部表現用に使用される。このため、ＤＩＧ１．１からＤＩＧ２．０へおよびこの逆の場合の変換器は、ＤＩＧ１．０のクライアントおよびサーバと通信することが要求され、変換器は、前述された実施形態に関連して説明された変換フレームワークまたはサーバ用アダプタによって実装される。しかしながら、いずれの場合にも、ＸＭＬストリームからおよびＸＭＬストリームへの非直列化および直列化を行う必要がある。クライアントおよびサーバ用アダプタは、ＤＩＧクライアントおよびサーバとのＨＴＴＰ接続を管理する責任がある。

ＤＩＧ２．０のクライアントが、３つの要求、すなわち（１）新しい公理の定義、（２）標準的な推論サービスへの呼出し、および（３）トウルド要求から構成する要求メッセージを提出すると仮定する。このメッセージは３つの部分に分割される。すなわち、公理の定義は（１）、ＤＩＧ１．１サーバおよびトウルド・モジュールに送信される。その理由は、両方のそれぞれのサーバ用アダプタはこの種の要求を管理するために登録されるからである。標準的な推論サービスへの呼出し（２）は、ＤＩＧ１．１のリーズナーに送られ、一方トウルド要求（３）はトウルド・モジュールに転送される。ＤＩＧ１．１のリーズナーとの通信を処理するサービス用アダプタは、内部表現とＤＩＧ１．１との間の言語の翻訳を行う必要がある。

全ての応答がサーバ用アダプタから受信されると、最終的な応答メッセージが作られる。この点で、両方のサービス用アダプタに送られた要求が同じ応答を戻すことが確実にされなければならない（この場合は、単一ＤＩＧ確認）。そうでない場合は、１つの実施形態によれば、本来の応答の代わりにエラーメッセージが含まれる。最終的に、クライアント用アダプタは応答メッセージを受け取り、ＤＩＧ２．０のクライアントに送る。

しかしながら、ＤＩＧプロトコルおよびその異なるバージョンは、本発明を適用できる環境のほんの一例に過ぎないことに注意されたい。一般に、種々のプロトコルバージョンおよび種々の機能を有するサーバが存在する環境には、本発明の実施形態を適用できる。

本発明の実施形態に関連して説明された方法、コンポーネント、ユニットおよび装置はハードウェア、ソフトウェアまたは両方の組合せによって実現できることは、当業者は容易に理解されよう。特に、本発明の実施形態およびそれに関連して説明されたモジュールのコンポーネントは、コンピュータ上で動作するコンピュータプログラムによって実現されるか、または記憶装置に記憶されかつ前記マイクロプロセッサ上で動作するコンピュータプログラムによって制御されるマイクロプロセッサによって実行されることは理解されよう。動作するために、コンピュータプログラムは、対応するリストまたは同様なものを記憶することによって、更にマッピングモジュールを実行する記憶手段にもアクセスすることができる。前述の実施形態の中で説明されたこれらの動作は、マイクロプロセッサの適当なプログラミングによって、またマイクロプロセッサに関連した記憶装置を利用することによって実現することができる。

本発明の実施形態が使用されている異種混合的な環境を概略的に例示する図である。 本発明の実施形態の構成のブロック図を概略的に例示する図である。 本発明の実施形態のクライアント用アダプタのブロック図を概略的に例示する図である。 本発明の実施形態の変換フレームワークのブロック図を概略的に例示する図である。 本発明の実施形態によるミドルウェアのコアの構成のブロック図を概略的に例示する図である。 本発明の実施形態による試験環境のブロック図を概略的に例示する図である。

Claims (11)

1. クライアントからの要求を対応するサーバに転送し、かつサーバの応答を対応するクライアントに配送するためのクライアント・サーバ・アーキテクチャにおいて使用する装置であって、
   どのサーバがどの種類のクライアントの要求に応答する機能を提供するかを示す対応付けリストを保持しているマッピングモジュールと、
   正しいサーバを識別するために、前記マッピングモジュールを参照することにより、クライアントの要求を対応するサーバに対してルーティングするためのモジュールと、
   同じクライアントの要求に対する応答を種々のサーバから受け取りかつ比較するためのコンパレータモジュールと、
   種々のサーバからの応答の間に不一致がある場合にエラー処理を実行するためのエラー処理モジュールと
   を備えており、あるクライアントの要求に対して、該クライアントの要求に応答できるサーバが複数あることを前記マッピングモジュールが示す場合、前記クライアントの要求が少なくとも２つの前記サーバに転送されることを特徴とする装置。
2. 前記エラー処理モジュールが、エラーとなった応答に関する情報を記録する機能を含むことを特徴とする請求項１に記載の装置。
3. 前記サーバが少なくとも２種類のサーバを具備し、前記２種類のサーバが互いに異なるプロトコルを通じて少なくとも部分的に同じ機能を提供し、一方の種類のサーバは古いプロトコルバージョンを用いるサーバであり、もう一方の種類のサーバは新しいプロトコルバージョンを用いるサーバであり、前記装置および前記２種類のサーバが、両方の種類のサーバによって提供されるこれらの機能に対して前記第１および前記第２の種類のサーバからの応答を前記コンパレータモジュールを通じて比較することにより前記新しいプロトコルバージョンに対する試験環境として使用されるようになっていることを特徴とする請求項１または２に記載の装置。
4. クライアントからの要求を受け取るための１つ以上のクライアント用アダプタと、
   前記クライアントの要求を前記ミドルウェアの内部表現に変換するための変換フレームワークと、
   前記ミドルウェアの前記内部表現からの要求を、該要求が配送されるサーバが理解する言語に変換し、前記要求を前記サーバに配送する１つ以上のサーバ用アダプタと
   をさらに備えることを特徴とする請求項１から３のいずれかに記載の装置。
5. 新しい構成要素を用いて前記ミドルウェアの拡張を可能にするための拡張フレームワークであって、新しいサーバ用アダプタが装着される場合、新たに装着されたサーバ用アダプタを介して処理することができる種類の要求に関する新しいルートについて前記マッピングモジュールに対して自動的に通知がなされ、それに応じて新たに装備されたあらゆるクライアント用アダプタが始動するように適合されている前記拡張フレームワークを更に具備することを特徴とする請求項１〜４のいずれかに記載の装置。
6. クライアントからの要求を対応するサーバに転送し、かつサーバの応答を対応するクライアントに配送する、クライアント・サーバ・アーキテクチャの中で使用する転送方法であって、
   どのサーバがどの種類のクライアントの要求に応答する機能を与えるかを示す対応付けリストを保持するステップと、
   正しいサーバを識別するために、対応付けリストを参照することにより、クライアントの要求を対応するサーバに向けてルーティングするステップと、
   種々のサーバからの同じクライアントの要求に対する応答を受信および比較するステップと、
   種々のサーバからの応答の間に不一致がある場合、エラー処理を実行するステップと
   を含み、特定のクライアントの要求に対して、前記クライアントの要求に応答できるサーバが複数あることを前記リストが示す場合、前記ミドルウェアは前記クライアントの要求を少なくとも２つの前記サーバに転送することを特徴とする転送方法。
7. 前記エラー処理を実行するステップが、エラーが発生した応答に関する情報を記録するステップを含むことを特徴とする請求項６に記載の方法。
8. 前記サーバは少なくとも２種類のサーバを具備し、前記２種類のサーバは互いに異なるプロトコルを通じて少なくとも部分的に同じ機能を行い、一方の種類のサーバは古いプロトコルバージョンを用いるサーバであり、もう一方の種類のサーバは新しいプロトコルバージョンを用いるサーバであり、前記ミドルウェアおよび前記２種類のサーバが、両方の種類のサーバによって提供されるこれらの機能に対して前記第１および前記第２の種類のサーバからの応答を前記コンパレータモジュールを通じて比較することにより、前記新しいプロトコルバージョンに対する試験環境として使用されるようになっていることを特徴とする請求項６または７に記載の方法。
9. １つ以上のクライアント用アダプタによってクライアントからの要求を受け取るステップと、
   前記クライアントの要求を前記ミドルウェアの内部表現に変換するステップと、
   前記ミドルウェアの前記内部表現からの要求を、要求が配送されるサーバが理解する言語に変換するステップと、
   変換されると前記要求を１つ以上のサーバ用アダプタが前記サーバに配送するステップと
   をさらに含むことを特徴とする請求項６〜８のいずれかに記載の方法。
10. 新しい構成要素を用いて前記ミドルウェアの拡張を可能にするステップをさらに含み、前記拡張フレームワークは、新しいサーバ用アダプタが装着される場合、新たに装着されたサーバ用アダプタを介して処理することができる種類の要求に関する新しいルートについて前記マッピングモジュールに対して自動的に通知がなされ、それに応じて新たに装備されたあらゆるクライアント用アダプタが始動するようになっていることを特徴とする請求項６〜９のいずれかに記載の方法。
11. 実行されると請求項６〜１０のいずれかに記載される方法を前記コンピュータに実行させることができるコンピュータプログラムコードを含むコンピュータプログラム。