ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポート
【課題】従来技術の追加の構成の複雑さを強制し、ウェブ・サービス・インターメディアリでの改善を提供すること。
【解決手段】ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートが、通常は、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとによって提供される方法、システム、および製品を開示する。例示的実施形態に、通常は、要求−応答処理のリターン経路と、前記インターメディアリ内で前記ターゲット・サービスからの応答を受信することと、前記インターメディアリ内で、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととも含まれる。
【解決手段】ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートが、通常は、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとによって提供される方法、システム、および製品を開示する。例示的実施形態に、通常は、要求−応答処理のリターン経路と、前記インターメディアリ内で前記ターゲット・サービスからの応答を受信することと、前記インターメディアリ内で、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととも含まれる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野は、データ処理であり、より詳細には、ウェブ・サービス・インターメディアリ（intermediary）のポート・タイプ不可知プロキシ（port type agnostic proxy）サポートの方法、システム、および製品に関する。
【背景技術】
【０００２】
用語「ウェブ・サービス」は、ウェブベース・アプリケーションを統合する標準化された形を指す。ウェブ・サービスは、通常、バインディングと呼ばれる標準化されたフォーマットでのデータ通信を介する要求の際にビジネス・サービスを提供する。バインディングは、データ・エンコーディング方法およびデータ通信プロトコルの指定である。ウェブ・サービスに使用される最も一般的なバインディングは、ＳＯＡＰプロトコルによるＸＭＬでのデータ・エンコーディングおよびＨＴＴＰを用いるデータ通信である。
【０００３】
ブラウザ・クライアントからの要求に応答してＨＴＭＬ文書を供給するＨＴＴＰサーバなどの伝統的なクライアント／サーバ・モデルと異なって、ウェブ・サービスは、表示に関係しない。その代わりに、ウェブ・サービスは、ネットワークにまたがるプログラム的インターフェースを介してビジネス・ロジック、データ、およびプロセスを共用する。ウェブ・サービス・アプリケーションは、ユーザではなく、お互いとインターフェースする。ウェブ・サービスの間のすべてのデータ通信が、標準化されたバインディングに従って実行されるので、ウェブ・サービスは、１つのオペレーティング・システムまたはプログラミング言語に束縛されない。Ｗｉｎｄｏｗｓ（Microsoft Corporationの商標）プラットフォームで稼動するＪａｖａ（Sun Microsystemの商標）クライアントが、Ｐｅｒｌで記述されＵｎｉｘ（TheOpen Groupの商標）で稼動するウェブ・サービス操作を呼び出すことができる。Ｃ＋＋で記述されたＷｉｎｄｏｗｓアプリケーションが、Ｊａｖａ（SunMicrosystemの商標）サーブレットとして実装されたウェブ・サービスの動作を呼び出すことができる。
【０００４】
現在、ウェブ・サービスは、多数の産業にまたがって成長しつつある。ウェブ・サービスが重要性を増すにつれて、ウェブ・サービス・インターメディアリが、ますます、多数の付加価値サービスを提供する手段として認められる。本明細書で一般に「インターメディアリ」と称するウェブ・サービス・インターメディアリは、ウェブ・サービス・クライアントとウェブ・サービス・プロバイダの間にあるウェブ・サービス・コンポーネントである。インターメディアリは、一般に、クライアントからの要求をインターセプトし、インターメディアリ・サービスを提供し、その後、クライアント要求をウェブ・サービス・プロバイダに転送することによって動作する。同様に、ウェブ・サービス・プロバイダからの応答が、インターセプトされ、操作され、その後、クライアントに返される。ウェブ・サービス・インターメディアリを実装できる市販製品の例に、ＩＢＭ社のWeb Services Gateway（商標）およびＩＢＭ社のWeb Services Bus（商標）が含まれる。
【０００５】
インターメディアリによって提供されるサービスに、ターゲット・サービスに関する要求のソースの認証、内容およびフォームに関するメッセージ妥当性検査、ならびに監査のためのメッセージ・ログ記録が含まれる。インターメディアリは、管理報告サービス、ウェブ・サービス・ヒットの個数、個々のクライアントによって使用されたサービスの品質およびタイミングなどを提供することができる。インターメディアリを、例えば新聞記事など、頻繁に変更されるが頻繁に要求されるデータを保管することによって、改善された性能をサポートするキャッシュとして使用することができる。インターメディアリを、複数のクライアントからのサービスに関する要求を保管し、これらをオフピーク・サービス時間中にターゲット・サービスに転送することによって、負荷平衡化の意味での性能改善に使用することができる。インターメディアリは、例えば、債務勘定、売掛金勘定に関する別々のターゲット・サービスおよび一般的な台帳サービスにその後に転送されるアカウント・ポスティングに関する要求を受け入れる会計インターメディアリとして、サービスを集約することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来技術では、ウェブ・サービス・インターメディアリを実装し、その結果、これらをそのターゲット・サービスに密結合することが一般的である。すなわち、特定のインターメディアリは、特定のターゲット・ウェブ・サービスだけにインターメディアリ・サービスを提供する。これに関する必要は、例えば、インターメディアリがメッセージ妥当性検査を提供し、したがって正しいメッセージ内容およびフォームの正確な知識を有しなければならないときに、明らかである。ウェブ・サービスの用語法では、動作のグループを、「ポート・タイプ」と呼ぶ。この用語法では、密結合の制限は、一般に、従来技術で、インターメディアリ・サービスおよびそのインターメディアリ・サービスによってサービスされるすべてのターゲット・サービスが、同一のポート・タイプを有することを意味する。しかし、例えば、ポート・タイプに無関係にすべてのターゲット・サービスに向けられたメッセージに対する正確に同一の認証機能を提供すること意図されたクライアント・アイデンティティ認証機能など、インターメディアリ・サービスが、ポート・タイプにまたがって機能することが有用である状況がある。従来技術はそのような場合での追加の構成の複雑さを強制し、ウェブ・サービス・インターメディアリでの改善は引き続き必要とされている。
【課題を解決するための手段】
【０００７】
第１の態様によれば、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法であって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとを含む方法が提供される。
【０００８】
一実施形態で、前記要求が同期応答を必要とするかどうかを判定し、前記要求が同期応答を必要とする場合に、前記ターゲット・サービスからの応答を待つ。
【０００９】
通常の実施形態で、前記要求が同期応答を必要とするかどうかを判定することが、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定することによって実行される。通常の実施形態で、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成することを含む。同期応答を必要しない要求に関して、いくつかの実施形態が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信することと、応答メッセージを待たずに前記肯定応答をリクエスタに返すこととを含む。
【００１０】
同期応答を必要とする要求に関して、いくつかの実施形態が、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答をリクエスタに返すこととによって、前記ターゲット・サービスからの応答を待つことをインプリメントする。通常の実施形態で、ターゲット・サービスからの応答をインターメディアリ内で同期式に受信することが、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出すことによって実行される。
【００１１】
多くの実施形態で、作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する。例示的な実施形態は、通常、要求−応答処理のリターン・パスと、前記インターメディアリで前記ターゲット・サービスからの応答を受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととをも含む。
【００１２】
本発明の通常の実施形態は、前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別することも含む。そのような実施形態で、パラメータ情報が、しばしば、前記操作のポート・タイプを含む。さらに、操作をサポートするターゲット・サービスのエンドポイントを識別することが、しばしば、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することと、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することとをも含む。操作をサポートするターゲット・サービスの複数のエンドポイントを識別することが、ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別することによって実行されることができる。前記複数のエンドポイントから１つのエンドポイントを選択することが、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することを含むことができる。
【００１３】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求をバインディング中立インターフェースで有用なデータ構造に構成することと、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出すこととによって実行されることができる。前記ターゲット・サービスに前記ターゲット・サービス要求を発行することが、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことを含むことができる。
【００１４】
第２の態様によれば、本発明は、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのシステムであって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する手段とを含むシステムを提供する。
【００１５】
第３の態様によれば、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのコンピュータ・プログラム製品であって、記録媒体と、ウェブ・サービス・インターメディアリ内でウェブ・サービス操作の実行に関する要求を受信する前記記録媒体に記録された手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、前記記録媒体に記録された手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する前記記録媒体に記録された手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する前記記録媒体に記録された手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する前記記録媒体に記録された手段とを含むコンピュータ・プログラム製品が提供される。
【００１６】
本発明を、コンピュータ・ソフトウェアでインプリメントすることができる。
【００１７】
本発明の好ましい実施形態を、例としてのみ、添付図面を参照してこれから説明する。
【発明を実施するための最良の形態】
【００１８】
本発明を、大体において、本明細書ではウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に関して説明する。しかし、当業者は、開示される方法に従って動作する適当なプログラミング手段を含むすべてのコンピュータ・システムも、本発明の範囲に含まれることを理解するであろう。適当なプログラミング手段に、本発明の方法のステップを実行するようにコンピュータ・システムに指示するすべての手段が含まれ、これには、例えば、データおよびプログラム命令を保管するように構成された電子回路を含むコンピュータ・メモリに、処理ユニットによる実行のために本発明の方法のプログラムされたステップをコンピュータ・メモリに保管する能力を有する、コンピュータ・メモリに結合された処理ユニットおよび算術論理回路からなるシステムが含まれる。
【００１９】
本発明を、適当なデータ処理システムと共に使用される、ディスケットまたは他の記録媒体など、コンピュータ・プログラム製品で実施することもできる。コンピュータ・プログラム製品の実施形態を、磁気媒体、光媒体、または他の適当な媒体を含む機械可読情報用のすべての記録媒体の使用によってインプリメントすることができる。当業者は、適当なプログラミング手段を有するすべてのコンピュータ・システムが、プログラム製品で実施された本発明の方法のステップを実行できることを、即座に理解するであろう。当業者は、本明細書で説明される例示的実施形態のほとんどが、コンピュータ・ハードウェアにインストールされ、実行されるソフトウェアに向かうものではあるが、それでも、ファームウェアまたはハードウェアとしてインプリメントされる代替実施形態も、本発明の範囲に含まれることを即座に理解するであろう。
【００２０】
定義
本明細書で使用される用語としての「ビジネス・レジストリ」は、会社およびその会社によって提供されるウェブ・サービスのリスティングを含む、ウェブ・サービスのインターネット・ディレクトリである。ウェブ・サービスのリスティングには、サポートされる操作、ポート・タイプ、エンドポイント、バインディングなどが含まれる。ビジネス・レジストリには、ｅｂＸＭＬなどのオープン標準規格に基づくものや、ＵＤＤＩなどの産業コンソーシアムが主導する仕様に基づくものがある。会社は、レジストリにそれ自体を登録することができる。会社は、レジストリを介して共用される材料をサブミットすることができ、レジストリ・クライアントは、他者がサブミットした材料を検索することができる。ブラウザを介して手動でまたはそれ自体をウェブ・サービスとすることのできるＡＰＩを介してプログラム的に、ビジネス・レジストリにアクセスし、検索することができる。レジストリは、会社が疎結合された形で互いに動的に協力することを可能にするので、ウェブ・サービスのますます重要なコンポーネントになりつつある。
【００２１】
ＨＴＴＰは、「ハイパーテキスト転送プロトコル」すなわち、ウェブ上で最も一般的なデータ通信プロトコルを意味する。しかし、本明細書では、用語「ウェブ」が、ＨＴＴＰ通信に制限されるのではなく、ＨＤＴＰすなわちHandheld Device Transfer ProtocolまたはＷＡＰすなわちWireless Access Protocolおよび当業者が思い浮かべる他のプロトコルなど、通信の類似するモードをサポートする他のプロトコルを用いる通信も含むことができる。
【００２２】
「ＳＯＡＰ」は、「Simple Object Access Protocol」すなわち、ウェブ・サービスの要求メッセージおよび応答メッセージをネットワークを介して送信する前に、これらの情報をエンコードするのに使用される軽量ＸＭＬベース・メッセージング・プロトコルを意味する。ＳＯＡＰメッセージは、すべてのオペレーティング・システムまたはプロトコルから独立しており、ＳＭＴＰ、ＭＩＭＥ、およびＨＴＴＰを含む様々なインターネット・プロトコルを使用して転送することができる。
【００２３】
「ＵＤＤＩ」は、「Universal Description,Discoveryand Integration」すなわち、会社がインターネット上でそれ自体をリストし、お互いを発見することを可能にする、従来の職業別電話帳および個人別電話帳に似た、ウェブベース分散ディレクトリを意味する。
【００２４】
「ＷＳＤＬ」は、「Web Services Description Language」を意味する。ＷＳＤＬは、Ｍｉｃｒｏｓｏｆｔ社およびＩＢＭ社によって共同開発されたＸＭＬフォーマットの言語であり、メッセージを交換できる通信エンドポイントの集合としてウェブ・サービスの機能を記述するのに使用される。ＷＳＤＬは、ＵＤＤＩがウェブ・サービスの機能を記述するのにＷＳＤＬを使用するという点で、ＵＤＤＩの一体化された部分である。
【００２５】
「ｅｂＸＭＬ」は、「electronic business ExtensibleMarkup Language」すなわち、電子商取引の取引を容易にするための、ＸＭＬでのウェブ・サービスの記述を標準化する仕様のモジュラ・スイートである。ＵＤＤＩに似て、ｅｂＸＭＬ仕様は、ウェブ・サービスを定義し登録する標準的な方法を会社に与える。
【００２６】
本明細書では、一般に、ＷＳＤＬの用語法に似た用語法を用いてウェブ・サービスのコンポーネントを記述する。ウェブ・サービスは、メッセージを交換できるネットワーク・エンドポイントすなわちデータ通信のエンドポイントの集合として記述される。エンドポイントを、時々「ポート」と呼ぶ。しかし、本明細書では、一般に、用語「ポート・タイプ」との混乱の危険を減らすために、用語「エンドポイント」が、「ポート」より好ましい。ポート・タイプは、ポートのタイプでもエンドポイントのタイプでもない。ポート・タイプは、サービスによってサポートされる、「操作」の集合すなわちソフトウェアのアクションまたは機能の集合である。
【００２７】
あるポート・タイプに関する特定の通信プロトコルおよびデータ・フォーマットの指定が、「バインディング」を構成する。バインディングの一例が、メッセージ・データがＳＯＡＰに従ってエンコードされ、メッセージがＨＴＴＰに従ってエンドポイントの間で通信されるＳＯＡＰ／ＨＴＴＰである。バンディングのもう１つの例が、メッセージ・データがＧＥＴメッセージまたはＰＯＳＴメッセージでエンコードされ、データ通信がＨＴＴＰに従って実行されるＧＥＴ／ＰＯＳＴ／ＨＴＴＰである。
【００２８】
各ポート・タイプは、複数のバインディングを有することができる。エンドポイントは、ネットワーク・アドレスにバインディングを関連付けることによって定義され、上で述べたように、エンドポイントの集合が、サービスを定義する。ウェブ・サービスでの操作に関するデータおよび要求の通信は、「メッセージ」と呼ばれるデータ構造を介して実行され、このメッセージは、「パーツ」からなる。用語「要求」および「応答」は、一般に、メッセージ・フローの向きを示す。特定のバインディングの要求メッセージおよび応答メッセージは、同一の構造を有することができる。
【００２９】
ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポート
添付図面を参照し、図１および２から始めて、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法、システム、および製品を説明する。図１に、本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャの線画を示す。図１のアーキテクチャでは、インターメディアリ（２０２）は、あるプロトコルを介するデータ通信をリクエスタ（１０２）およびターゲット・サービス（１１８）に接続することができる。リクエスタ（１０２）の位置のウェブ・サービス・コンポーネントを、時々、クライアントと称する。同様に、インターメディアリ（２０２）の位置のコンポーネントを、特にリクエスタの観点から見たときに、時々、サーバと称する。
【００３０】
クライアント／サーバの区別は、ウェブ・サービスの文脈では注意深く使用されなければならない。例えば、図２のアーキテクチャでは、ターゲット・サービス（１１８）が、リクエスタ（１０２）からの要求に対する応答を準備する処理で、インターメディアリ（２０３）を介してターゲット・サービス（１１９）からウェブ・サービスを要求する場合がある。それを行う際に、ターゲット・サービス（１１８）は、クライアントとして働いている。要求をターゲット・サービス（１１８）に転送する際に、インターメディアリ（２０２）は、クライアントとして働いている。特定のコンポーネントが、特定のときにクライアントまたはサーバのどちらと考えられるかは、そのときにそのコンポーネントによって実行されている特定の機能に依存する。すなわち、あるウェブ・サービス・コンポーネントが、ある瞬間にクライアントであり、次の瞬間にサーバになることができる。したがって、用語法からの混乱の危険を減らすために、ウェブ・サービス・コンポーネントは、通常、本明細書で、「クライアント」または「サーバ」ではなく、用語「リクエスタ」、「インターメディアリ」、および「ターゲット・サービス」を使用することによって記述される。
【００３１】
インターメディアリ（２０２）がターゲット・サービス（１１８）の代わりにインターメディアリ・サービスを提供するためには、インターメディアリ（２０２）は、ターゲット・サービス（１１８）上のエンドポイントを知らなければならない。上で述べたように、従来技術では、インターメディアリ（２０２）で稼動する「プロキシ」と呼ばれるサービスが、ターゲット・サービス（１１８）と同一のポート・タイプをサポートし、その構成データにターゲット・サービス（１１８）のエンドポイントを有する。しかし、図１および２のアーキテクチャでは、プロキシが、「ポート・タイプ不可知」であり、これは、プロキシへの使用可能な構成データが、ターゲット・サービスのエンドポイントを記述しないことと、リクエスタ（１０２）が、インターメディアリに完全に未知のポート・タイプの操作に関する要求をサブミットできることを意味する。
【００３２】
図３に、本発明の実施形態による例示的なインターメディアリ（２０２）のブロック図の線画を示す。インターメディアリ（２０２）に、少なくとも１つの中央処理装置、コンピュータ・メモリ、システム・バスなどを含む、自動化されたコンピューティング機械すなわちコンピュータ・システムが含まれる。図３のブロック図のブロックは、インターメディアリ（２０２）のコンピュータ・システムで動作可能なソフトウェア・アプリケーション・モジュールを表す。図３の矢印は、ソフトウェア・モジュールの間のデータ・フローを表す。
【００３３】
インターメディアリ（２０２）に、ウェブ・サービス操作の実行に関する、パラメータ情報（１０７）を含む要求（１０６）をリクエスタ（１０２）から受信することができるインバウンド・エンジン（２０８）が含まれる。次は、ＳＯＡＰ−ＨＴＴＰバインディングに関するそのような要求の例である。
POST /Channel/proxy?portType=A HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。すなわち、ターゲット・サービス（１１８）で実行される操作の名前が、ｓｏａｐメッセージ内で内部的に識別されている。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、この操作をサポートするターゲット・サービス（１１８）のエンドポイントをそれから識別できるパラメータ情報（１０７）が、このＰＯＳＴの第１行のＵＲＩエンコードされたクエリ文字列の名前／値対「ｐｏｒｔＴｙｐｅ＝Ａ」に示されている。
【００３４】
第２の実施形態では、例示的要求の第１行が、次のようになる。
POST/Channel/proxy?portType=A&synchRespReqd=True HTTP/1.1
この第２の実施形態では、パラメータ情報に、名前／値対「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」が含まれ、この対から、本発明の実施形態によるポート・タイプ不可知プロキシが、この要求が同期応答を要求するかどうかを判定することができる。
【００３５】
ウェブ・サービスに関する、パラメータ情報（１０７）を含む要求（１０６）をリクエスタ（１０２）から受信することに加えて、インバウンド・エンジン（２０８）は、パラメータ・データを含む要求をポート・タイプ不可知プロキシ（２１２）に供給する能力も有する。インバウンド・エンジン操作の一例として、上で示した例示的要求を検討されたい。その例示的要求は、ＳＯＡＰ−ＨＴＴＰとしてバインドされている。したがって、この例示的要求に関して、インバウンド・エンジンを、例えばＪａｖａ（Ｒｈ）Ｂｅａｎ、Ｊａｖａ（Ｒ）サーブレット、またはＰｅｒｌで記述されたＣＧＩ（Common Gateway Interface）スクリプトを含むすべての種類のサーバタイプ・アプリケーションとしてインプリメントされた、着信要求をプロキシ（２１２）にハンド・オフするＳＯＡＰ対応ＨＴＴＰサーバとすることができる。Ｊａｖａ（Ｒ）サーブレットおよびＣＧＩスクリプトは、制限ではなく例としてのみ言及されたものである。本発明の範囲内で、当業者が思い浮かべるすべての種類のサーバサイド機能性を使用して、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ機能をインプリメントすることができる。
【００３６】
ポート・タイプ不可知プロキシ（２１２）を、排他的にポート・タイプ不可知プロキシとして動作するようにハード・コードすることができ、あるいはその代わりに、ポート・タイプ不可知プロキシ（２１２）が、構成パラメータ（２２３）に依存してモーダルに動作することができる。構成パラメータは、ポート・タイプ不可知プロキシ（２１２）が伝統的なインターメディアリ・サービスとしてまたはポート・タイプ不可知モードのどちらで動作しなければならないかを示すために提供することができる。そのような構成パラメータは、有利なことに、特に両方のモードで利用できるコード・セグメントの再利用を含む効率的なプログラム・コーディングを促進する。プログラム・コードの効率的使用をサポートするもう１つの構成パラメータが、プロキシのバインディングまたは「チャネル・タイプ」を識別するパラメータである。下で詳細に説明するように、ポート・タイプ不可知プロキシは、ウェブ・サービスがサポートするすべてのバインディングすなわち、ＳＯＡＰ、ＭＩＭＥ、ＧＥＴ／ＰＯＳＴ／ＨＴＴＰなどを用いて動作することができる。ポート・タイプ不可知プロキシを、任意のバインディングまたはチャネル・タイプを用いて動作するようにコーディングし、その後、ラン・タイム動作のバインディングまたはチャネル・タイプについてプロキシに助言するパラメータを用いて構成することができる。さらに、要求または応答メッセージの内容を解析することを必要とする、プロキシ内のインターメディアリ・サービスをオンまたはオフにするために、構成パラメータを設けることができる。そのようなパラメータは、メッセージ内容の解析がインターメディアリ性能を低下させる傾向があるので、性能を最適化するのに使用することができる。多くのポート・タイプ不可知プロキシならびに他のインターメディアリ・サービスが、インターメディアリ（２０２）内で同時に動作することができ、そのそれぞれの名前を、構成パラメータとして割り当てることができる。メッセージ・ハンドラおよびフィルタを、構成パラメータでプロキシに割り当てることができる。この段落では、制限ではなく説明として、ポート・タイプ不可知プロキシの複数の構成パラメータを説明している。当業者が思い浮かべるすべての構成パラメータの使用が、本発明の範囲に含まれる。
【００３７】
図４に、本発明の実施形態によるＳＯＡＰ−ＨＴＴＰチャネルをインプリメントする例示的なインターメディアリ（２０２）のブロック図の線画を示す。上で述べたように、ＳＯＡＰバインディングを用いる要求について、パラメータ・データを含む要求をポート・タイプ不可知プロキシ（２１２）に供給できるインバウンド・エンジン（２０８）を、ＳＯＡＰ対応ＨＴＴＰサーバとして実施することができる。そのようなインバウンド・エンジンを、プロキシに関するＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）への複数の参照を用いて構成することができ、ここで、各ＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）は、プロキシに関する要求に対するあるデータ処理タスクを提供するように構成される。そのようなインバウンド・エンジンは、通常、着信要求をパラメータ情報と共にＳＯＡＰＣｏｎｔｅｘｔオブジェクト（２０９）にカプセル化し、プロキシ用に構成されたＳＯＡＰＨａｎｄｌｅｒ（２１０）のそれぞれにＳＯＡＰＣｏｎｔｅｘｔオブジェクトへの参照を渡し、次に、ＳＯＡＰＣｏｎｔｅｘｔ（２０９）全体をプロキシ（２１２）に渡すことによって動作する。一般的な意味で、エンドポイントを識別するのは、ポート・タイプ不可知プロキシであるが、詳細なインプリメント・レベルに、ＳＯＡＰの場合のように、ハンドラ内のプロキシ機能を含めることができる。すなわち、インバウンド・エンジンが、ターゲット・サービスのエンドポイント（ＳＯＡＰ／ＨＴＴＰの場合にはＵＲＬ）をセットできるＳＯＡＰＣｏｎｔｅｘｔ内のプロパティを確立することができる。そのような実施形態で、ＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）のうちの１つを有用にプログラムして、要求からパラメータ情報を抽出し、ＳＯＡＰＣｏｎｔｅｘｔ内の名前／値対に置くことができ、その結果、プロキシが、これを使用して、要求されたウェブ・サービス操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別できるようになる。
【００３８】
その代わりに、着信要求が、ＳＯＡＰではなくＧＥＴ／ＨＴＴＰにバインドされている場合がある。そのような例では、プロキシ（図３の２１２）を、Ｊａｖａ（Ｒ）サーブレットとしてインプリメントすることができる。インバウンド・エンジン（２０８）を、パラメータ情報を含む要求をＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔオブジェクトにカプセル化し、そのＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔオブジェクトへの参照をプロキシに供給するＪａｖａ（Ｒ）対応ＨＴＴＰサーバとしてインプリメントすることができる。このプロキシは、ＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔ．ｇｅｔＱｕｅｒｙＳｔｒｉｎｇ（）への呼出しを介してパラメータ情報を入手することができ、この呼出しは、要求ＵＲＬからのクエリ文字列すなわち、要求ＵＲＬ内の疑問符の後のすべてを返す。クエリ文字列全体を有するので、そのような例示的プロキシは、クエリ文字列からパラメータ・データすなわち、この例では「ｐｏｒｔＴｙｐｅ＝Ａ」を抽出し、そのように抽出された情報を使用して、要求されたウェブ・サービス操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別するようにプログラムされる。プロキシが、要求されたウェブ・サービス操作をサポートするターゲット・サービスのエンドポイントを識別できる１つの形が、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリ（２１１）からエンドポイント記述を取り出すことである。ターゲット・サービス（１１８）は、通常、例えばＷＳＤＬ文書として表された記述を含むそのような記述を、これらをビジネス・レジストリ（２１１）に登録（２２４）することによって作る。
【００３９】
ＳＯＡＰベースのウェブ・サービスでは、ＳＯＡＰメッセージ自体に、操作の名前およびその操作のパラメータが含まれるが、これらは、エンドポイントＵＲＬに含まれない。インターメディアリが、ｐｏｒｔＴｙｐｅパラメータなどのパラメータ情報を受け取ることが有用である。そのパラメータは、ｐｏｒｔＴｙｐｅの名前のように単純なものとすることができる。その場合に、サーバ内（例えばハンドラ内、またはプロキシ機能自体の中）で稼動するある「ビジネス・ロジック」が、ポート・タイプまたは他のパラメータ情報に基づいて、ターゲット・サービス（１１８）の実際のエンドポイントＵＲＬを選択しなければならない。パラメータ情報に、実際のエンドポイントＵＲＬを含めることもできる。その場合に、「ビジネス・ロジック」は、最終的にそのＵＲＬに要求を送信する。ポート・タイプとエンドポイントＵＲＬの両方を、パラメータ情報で表すことができ、その場合に、「ビジネス・ロジック」は、エンドポイントＵＲＬの判定を試み、要求内のエンドポイントＵＲＬよりよいものが見つからない場合に、要求内のエンドポイントＵＲＬを使用することができる。本発明は、この３つのシナリオのすべてならびにビジネス・ロジックによって制御することができるすべての変形を許容する。必ず、「ビジネス・ロジック」を制御するのを助ける他のパラメータがある可能性がある。
【００４０】
本明細書では、ＳＯＡＰ／ＨＴＴＰバインディングに関しておよび時々ＧＥＴ／ＰＯＳＴ／ＨＴＴＰバインディングに関して例示的バインディングを論じる傾向があるが、これらの例示的バインディングの議論は、説明の便宜のためであって制約としてではない。本発明の様々な実施形態に従って有用な代替の例示的なバインディングに、ＭＩＭＥ／ＳＭＴＰ（Multipart Internet Mail Extensions over the Small Message TransportProtocol）およびＲＭＩ／ＩＩＯＰ（Java's Remote Method Invocation over the Common ObjectRequest Broker Architecture's Internet Inter-ORB Protocol）が含まれる。実際に、任意のＪａｖａクラスを、ネイティブＪａｖａ呼出しをアクセス・プロトコルとして用いて、ウェブ・サービスとして扱うことができ、当業者が思い浮かべるすべての他のバインディングのポート・タイプ不可知プロキシでの使用が、好ましい実施形態による本発明の範囲に含まれる。
【００４１】
図３の例示的なインターメディアリ（２０２）では、プロキシ（２１２）はポート・タイプ不可知プロキシであり、リクエスタ認証、メッセージ妥当性検査、メッセージ・ログ記録、管理報告サービスなど、それが設計されたすべてのインターメディアリ・サービスを実行し、要求された操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別し、その後、バインディング中立インターフェース（２１８）を介してターゲット・サービスに要求を送信する、ポート・タイプ不可知プロキシである。下で詳細に説明するように、バインディング中立インターフェース（２１８）は、その使用の形が要求バインディングに依存しないインターフェースである。
【００４２】
図３の例示的なインターメディアリ（２０２）では、インターフェース（２１８）が、プロバイダ（２２０）を動作させ、このプロバイダ（２２０）が、アウトバウンド・エンジン（２２２）を呼び出して、要求（１０６）をターゲット・サービス（１１８）に転送する。バインディング中立インターフェース（２１８）は、プロトコル固有のプロバイダ（２２０）内のコードによってバック・アップされるので、バインディング中立の形で動作することが可能である。プロバイダ（２２０）は、ＳＯＡＰ、ＨＴＴＰなど、特定のプロトコルの詳細に従って実際のメッセージ交換を実行する。実際のデータ通信を実行するプロバイダからバインディング中立インターフェースを切り離すことによって、新しいプロバイダの動的登録がサポートされ、その結果、インターメディアリが、再コンパイルまたは再展開を必要とせずにそのデータ通信能力を強化することができるようになる。プロバイダは、しばしばそのプロバイダのプロトコルによってサポートされるターゲット・サービスによって提供されるオブジェクトとしてインプリメントされ、プロバイダへの参照が、バインディング中立インターフェースに動的にインストールされる。アウトバウンド・エンジン（２２２）は、プロバイダ（２２０）によってインプリメントされるプロトコルのための実際のデータ通信エンジンである。プロトコルが、例えばＳＯＡＰ／ＨＴＴＰとして採用されるときに、アウトバウンド・エンジンは、ターゲット・ウェブ・サービスとの間でＳＯＡＰ／ＨＴＴＰの要求メッセージおよび応答メッセージを送信でき、受信できるＳＯＡＰ／ＨＴＴＰエンジンである。例えば、プロトコルがＨＴＴＰの場合に、アウトバウンド・エンジンは、ウェブ・ブラウザのデータ通信モジュールに似た、ＨＴＴＰデータ通信クライアント・モジュールである。
【００４３】
インターメディアリ・サービスを提供するために、インターメディアリは、有利なことに、要求のエンドポイントを識別することができる。それを行う方法を、図５に関して述べる。図５に、ウェブ・サービス操作の実行に関する要求（１０６）をウェブ・サービス・インターメディアリ内で受信すること（１０４）を含むウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図を示すが、ここで、この要求には、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が含まれる。
【００４４】
次も、ＳＯＡＰ−ＨＴＴＰバインディングのそのような要求の例である。
POST /Channel/proxy?portType=A HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOpxmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、メッセージが、ＳＯＡＰエンベロープとして解釈され、この操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が、ＨＴＴＰパラメータ「ｐｏｒｔＴｙｐｅ＝Ａ」である。この例では、ターゲット・サービスの操作の名前が、既にＳＯＡＰエンベロープにエンコードされているので、追加される唯一のパラメータ・データは、ポート・タイプ「Ａ」すなわち、ターゲット・サービスの操作を含むポート・タイプである。
【００４５】
図５の方法に、操作をサポートするターゲット・サービスのエンドポイント（１１０）を、パラメータ・データに依存して識別すること（１０８）も含まれる。このＳＯＡＰ−ＨＴＴＰの例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（１０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.com/SOAP-HTTP/servlets/のＳＯＡＰ−ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００４６】
図示の方法に、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）が含まれる。この例では、インターメディアリが、ターゲット・サービスのエンドポイントを使用して、ＨＴＴＰ ＰＯＳＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。エンドポイントを識別するパラメータ・データが、削除され、要求が、ＳＯＡＰメッセージを処理するスクリプトに向けられ、このスクリプト自体が、ＳＯＡＰエンベロープ内の操作名から操作を識別する。
【００４７】
結果のターゲット・サービス要求は、次のようになる。
POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1
Host: www.myTarget.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【００４８】
図５の方法に、ターゲット・サービス要求（１１４）をターゲット・サービス（１１８）に発行すること（１１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、そのＴＣＰ／ＩＰ接続を介してＨＴＴＰ ＰＯＳＴメッセージをターゲット・サービスに送信することが含まれる。
【００４９】
本発明の少なくともいくつかの実施形態で、図５に示されたものなどのポート・タイプ不可知プロキシ・サポートの方法で、作成され、ターゲット・サービスに発行されるターゲット・サービス要求が、ウェブ・サービス・インターメディアリで受信された要求の検査されず変更されないメッセージ内容を有することに留意することが有用である。上で説明した例では、インターメディアリのプロキシ・サービスが、メッセージ本体すなわちＳＯＡＰエンベロープにまったく手を付けず、オープンせず、検査せず、解析せず、どの形でも変更せずに、パラメータ・データ「ｐｏｒｔＴｙｐｅ＝Ａ」からターゲット・サービスのエンドポイントを識別し、そのように識別されたエンドポイントにメッセージをリダイレクトし、このＳＯＡＰエンベロープが、そのリクエスタからターゲット・サービスまでの配送の過程全体を通じて検査されず、変更されないままになる。この過程で、プロキシ・サービスは、インターメディアリ・サービス、認証、管理報告、負荷平衡化、サービス集約などのうちの１つまたは複数を提供した。
【００５０】
さらなる説明として、例示的な要求が、ＧＥＴ／ＨＴＴＰバインディングについて提示され、http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxyにあるエンドポイントに向けられる。例示的な着信要求メッセージは、次の形を有する。
GET/servlets/proxy?message=messageContentString&
operation=myOp&portType=A HTTP/1.1
また、ＵＲＩ空間では、例示的な要求を次のように示すことができる。
http://www.myIntermediary.com/servlets/
proxy?message=messageContentString&operation=myOp&portType=A
この例では、メッセージが、名前／値対としてエンコードされたＵＲＩエンコードされたクエリ・データ「ｍｅｓｓａｇｅ＝ｍｅｓｓａｇｅＣｏｎｔｅｎｔＳｔｒｉｎｇ」としてとられる。メッセージ内容は、ＵＲＩエンコードされた文字列である。この例では、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）のすべてが、メッセージ内容文字列に続くクエリ・データである。この例では、クエリ・データに、「Ａ」というポート・タイプとターゲット・サービスの操作の名前の両方が含まれる。
【００５１】
この例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（１０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.comのＧＥＴ／ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００５２】
図５の方法には、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）も含まれる。この例では、インターメディアリが、ターゲット・サービス要求のエンドポイント・アドレスに操作名およびメッセージ・パーツを連結することによって、ＨＴＴＰ ＧＥＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。ＵＲＩ空間で表現された、結果のターゲット・サービス要求は、次のようになる。
http://www.myTarget.com/servlets/myOp?message=messageContentString
【００５３】
図５の方法には、ターゲット・サービス（１１８）にターゲット・サービス要求（１１４）を発行すること（１１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、ＨＴＴＰ ＧＥＴメッセージを送信することが含まれる。
GET/servlets/myOp?message=messageContentString HTTP/1.1
【００５４】
当技術分野における技量を有する読者は、リクエスタがターゲット・サービスの操作に関する要求をどのようにしてインターメディアリに送信するかを不思議に思っている。答は、インターメディアリまたはインターメディアリの開発者が、リクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別することである。ターゲット・サービスの操作をサポートするエンドポイントとしてのインターメディアリのエンドポイントの識別は、リクエスタによるディスカバリのためにビジネス・ディレクトリに登録されるＷＳＤＬ文書でインプリメントすることができる。その代わりに、そのような識別を、インターメディアリからリクエスタにダウンロードすることができ、あるいは、リクエスタのウェブ・サービス構成データへの管理者によるインストールのために、単純にリクエスタまたはリクエスタの管理者に電子メールで送ることさえできる。
【００５５】
ターゲット・サービスがＷＳＤＬ擬似コードの次のセグメントによって記述される例を検討されたい。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location=
"http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
【００５６】
そのターゲット・サービスのインターメディアリは、次のようにターゲット・サービス記述のアドレス拡張要素の位置属性を置換することによって、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントをリクエスタに対して識別することができる。
<soap:addresslocation="http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
これによって、次のセグメントによって例示されるＷＳＤＬ文書が作成される。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="portTypeAgnosticProxy">
<portname="intermediaryEndpoint" binding="SOAPBinding">
<soap:address location=
"http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
</port>
</service>
</definitions>,
これは、ターゲット・サービスでの「ｇｅｔＱｕｏｔｅ」操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別する。レジストリ、ダウンロード、電子メールを介して、または当業者が思い浮かべる他の手段によって、この後者のセグメントによって例示される種類のＷＳＤＬをリクエスタに提供することによって、そのリクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントが識別される。
【００５７】
図５の方法では、パラメータ情報（１０７）に応じて、操作をサポートするターゲット・サービスのエンドポイントを識別すること（１０８）に、しばしば、ターゲット・サービスの１つのエンドポイントだけではなく、その操作をサポートするターゲット・サービスの複数のエンドポイントを識別することを含めることができる。本発明方法の実施形態によるポート・タイプ不可知プロキシが、操作のポート・タイプをパラメータ情報（１０７）として受信し、クエリ・パラメータとしてポート・タイプを用いてビジネス・レジストリに照会し、これによって操作をサポートするターゲット・サービスの複数のエンドポイントを識別する例を検討されたい。複数のエンドポイントのそのような識別は、例えば、ポート・タイプを用いてＵＤＤＩレジストリに照会し、それに応答して、そのポート・タイプに関するターゲット・サービスを記述した複数のＷＳＤＬ文書を受信することによって実行することができる。
【００５８】
複数のエンドポイントがそのように識別される場合に、本発明の実施形態によるウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に、通常、選択ルールに従ってエンドポイントのうちの１つを選択することが含まれる。自明な例では、選択ルールを、そのように識別された複数のエンドポイントの最初のエンドポイントを選択し、他のエンドポイントを破棄することとすることができる。選択ルールは、例えば、負荷平衡化に関する選択ルールを含む、より複雑なルールとすることができる。負荷平衡化に関するルールは、表１に示されたものに類似したデータ構造の使用によってインプリメントすることができる。
【００５９】
【表１】
【００６０】
表１の各行は、インターメディアリとターゲット・サービスの間のウェブ・サービス・データ通信の要求−応答ラウンド・トリップに関する待ち時間（latency）測定値を表す。表１には、要求および応答のラウンドごとに、ポート・タイプおよびエンドポイントＵＲＩの列が設けられている。送信時刻列は、要求メッセージが、インターメディアリからポート・タイプの操作に関するターゲット・サービスのエンドポイントに発行されたときの時刻を記録したものである。受信時刻列は、対応する応答メッセージがターゲット・サービスから受信されたときの時刻を記録したものである。トリップ待ち時間は、受信時刻と送信時刻の差である。累積待ち時間は、この表に表されたエンドポイントごとのトリップ待ち時間の現在合計（runningsum）である。表１に似た構造を用いて、要求に関する複数のエンドポイントが識別されたときに使用される選択ルールを、次の例示的なルールとしてインプリメントすることができる。
同一ポート・タイプの操作に関する複数の要求がインターメディアリに達したときには、複数の識別されたエンドポイントのそれぞれを順番に１回使用する。
そのような使用のそれぞれの待ち時間データを記録する。
同一ポート・タイプの操作に関する後続要求について、最短の累積待ち時間を有するエンドポイントを待ち時間テーブルから選択し、要求をそのエンドポイントに送信し、メッセージがターゲット・サービスに送信されるときおよび対応する応答がインターメディアリで受信されるときに、関連する待ち時間データを記録する。
【００６１】
表１の例示的データには、ポート・タイプＡについて２つのエンドポイントすなわち、URIhttp://www.ibm.com/aTargetServiceにある第１エンドポイントおよびURIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントに最近送信された要求の累積待ち時間が示されている。第１エンドポイントは、２５０ミリ秒の累積要求待ち時間を有し、第２エンドポイントは、１００ミリ秒の累積待ち時間を有する。上で示した例示的な選択ルールを使用すると、ポート・タイプＡに関する操作の現在の要求は、URIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントにルーティングされる。
【００６２】
図５の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）を、バインディング中立インターフェース内で有用なデータ構造内に要求を構成し、その要求を呼出しパラメータとして渡してバインディング中立インターフェースを呼び出すことによって実行することができる。同様に、ターゲット・サービスにターゲット・サービス要求（１１４）を発行すること（１１６）に、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことが含まれる。
【００６３】
バインディング中立インターフェースは、そのインターフェースの使用が要求またはメッセージのバインディングに依存しないインターフェースである。すなわち、このインターフェースをインプリメントし、それを介するデータ通信を実行するのに使用されるデータ構造および呼出し方法は、メッセージに使用されるデータ・エンコーディングのタイプに依存せず、メッセージに使用されるデータ通信プロトコルに依存しない。本発明の実施形態によるインターメディアリ用のポート・タイプ不可知プロキシの開発者は、しばしば、彼ら自身のバインディング中立インターフェースを作成する。しかし、「ＷＳＩＦ」すなわちWeb Service Invocation Frameworkと称する、バインディング中立インターフェースのオープン標準規格がある。ＷＳＩＦは、現在、ApacheSoftware FoundationのWeb Services Projectの一部としてサポートされている。
【００６４】
バインディング中立インターフェースの使用は、本発明の実施形態に利益をもたらす。ＳＯＡＰ−ＨＴＴＰバインディングは、現在の技術で非常に一般的なので、ユーザおよび開発者は、時々、他のバインディングが存在することを忘れる。これは、他のバインディングと共に使用されるか他のバインディングと共に使用するために適合させることが、不可能でないとしても非常にむずかしいシステムの開発をもたらす。しかし、ウェブ・サービスが成長するにつれて、他のバインディングが、より有用でより一般的になる。さらに、本発明の実施形態のバック・エンドにバインディング中立インターフェースを使用することは、使用可能なバインディングをラン・タイムに決定でき、これによって、柔軟で強力でより一般的に有用なウェブ・サービス・インターメディアリが提供されることを意味する。
【００６５】
バインディング中立インターフェースをインプリメントする形の１つが、ポート・タイプおよびエンドポイントを与えられてターゲット・サービス内のサービスを呼び出すことができるエンドポイント・オブジェクトを提供することである。そのようなエンドポイント・オブジェクトを提供する形の１つが、次の擬似コード・セグメントに例示されたものに似たエンドポイント・ファクトリを使用することによるものである。
// エンドポイント・ファクトリ・クラス
// エンドポイント・オブジェクトを作成するパラメータ化されたファクトリ・メソッドを定義する
//
class EndpointFactory
{
public static EndpointcreateEndpointObject(portType, networkAddress)
{
// 新しいエンドポイント・オブジェクトの参照を確立する
Endpoint anEndpoint = null;
if(portType == "A" &&networkAddress == "www.abc.com")
anEndpoint = new Endpoint1;
if(portType == "B" &&networkAddress == "www.def.com")
anEndpoint = new Endpoint2;
if(portType == "C" &&networkAddress == "www.ghi.com")
anEndpoint = new Endpoint3;
...
if(portType == "LAST" &&networkAddress == "www.lastSupported.com")
anEndpoint = new Endpoint465;
if anEndpoint == null) reportError();
else return anEndpoint;
}// createEndpointObject()の終り
}// クラスEndpointFactoryの終り
【００６６】
エンドポイント・クラスＥｎｄｐｏｉｎｔ１、Ｅｎｄｐｏｉｎｔ２、Ｅｎｄｐｏｉｎｔ３などは、メッセージ・パーツを含むメッセージ・オブジェクトを作成するメンバ・メソッドを提供する抽象エンドポイント・クラスを継承する（または、インターフェースとしてインプリメントする）具象クラスである。そのようなエンドポイント・ファクトリおよびそのようなバインディング中立インターフェースの他の要素を使用して、次の擬似コード・セグメントに示されているように、ターゲット・サービス要求（１１４）を作成するステップ（１１２）およびターゲット・サービスにターゲット・サービス要求（１１４）を発行するステップ（１１６）を実行することができる。
// エンドポイント・ファクトリからエンドポイント・オブジェクトを得る
Endpoint ep =endPointFactory.createEndPoint(portType, networkAddress);
// 入力メッセージを用意する
Message input = ep.createInputMessage();
// メッセージ・アクセス関数を使用してメッセージの内容を挿入する
input.setPart("symbol","IBM");
// 応答値のプレースホルダを用意する
Message output = ep.createOutputMessage();
// 操作を実行する
ep.executeRequestResponseOperation("getQuote",
input, output);
// 結果を返す
return output;
【００６７】
この例示的な擬似コード・セグメントは、エンドポイントのポート・タイプおよびネットワーク・アドレスを与えられて、エンドポイント・ファクトリを呼び出してエンドポイント・オブジェクトを作成する。次に、このセグメントは、メッセージ・パーツをエンドポイント・オブジェクトにロードすることによってターゲット・サービス要求を作成し、メンバ・メソッドｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）を呼び出すことによってターゲット・サービスにターゲット・サービス要求を発行する。図５の方法に、ターゲット・サービスからの応答（１２２）をインターメディアリ内で受信すること（１２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（１２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（１２８）が含まれる。この例示的な擬似コード・セグメントでは、ターゲット・サービスからの応答（１２２）を受信するステップ（１２０）およびインターメディアリからの応答（１２６）を作成するステップ（１２４）が、通常はターゲット・サービスからの応答を待って「ｏｕｔｐｕｔ」へのメッセージ参照を介してその応答を使用可能にするブロッキング呼出しであるｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）への呼出しによってインプリメントされる。
【００６８】
上の例の擬似コード・セグメントは、エンドポイントとして参照されるポートを有するバインディング中立インターフェースの使用を例示するものである。しかし、ＷＳＩＦインターフェース構文は、エンドポイントを参照するときに用語「ポート」を使用する。したがって、バインディング中立インターフェースの使用に関するさらなる説明として、ＷＳＩＦ標準規格をより厳守するさらなる例示的擬似コード・セグメントを示す。この例では、「ポート」が、「エンドポイント」を意味するのに使用され、説明の一貫性を保つために、ファクトリの名前が、「ｐｏｒｔＦａｃｔｏｒｙ」に変更されている。
// ファクトリからポート（エンドポイント）を得る
WSIFPort port =portFactory.getPort(portType, networkAddress);
// 入力メッセージを用意する
WSIFMessage input =port.createInputMessage();
// メッセージ内容を挿入する
input.setPart("symbol",
new WSIFＪａｖａ（Ｒ）Part(String.class, symbol));
// 応答値のプレースホルダを用意する
WSIFMessage output =port.createOutputMessage();
// 操作を実行する
port.executeRequestResponseOperation("getQuote",
input, output, null);
// 結果を抽出し、返す
return output;
【００６９】
本明細書では、主にリクエスタからターゲット・サービスへの過程での要求の処理に関して、ウェブ・サービス・インターメディアリでのポート・タイプ不可知プロキシ・サポートの例示的方法を論ずるが、本発明の実施形態によるインターメディアリが、通常、ターゲット・サービスからインターメディアリを介して最初のリクエスタに戻る応答メッセージを処理することもできることに留意することが有用である。例えば、図５の方法に、インターメディアリ内でターゲット・サービスから応答（１２２）を受信すること（１２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（１２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（１２８）が含まれる。
【００７０】
図６に、ウェブ・サービス操作の実行に関する要求（１０６）をウェブ・サービス・インターメディアリ内で受信すること（３０４）を含む、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図を示すが、ここで、この要求に、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が含まれる。
【００７１】
次も、ＳＯＡＰ−ＨＴＴＰバインディングのそのような要求の例である。
POST/Channel/proxy?portType=A&synchRespReqd=True HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、メッセージが、ＳＯＡＰエンベロープとしてとられ、この操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が、ＨＴＴＰパラメータ「ｐｏｒｔＴｙｐｅ＝Ａ」である。この例では、ターゲット・サービスの操作の名前が、既にＳＯＡＰエンベロープにエンコードされているので、追加される唯一のパラメータ・データは、ポート・タイプ「Ａ」すなわち、ターゲット・サービスの操作を含むポート・タイプである。
【００７２】
図６の方法に、操作をサポートするターゲット・サービスのエンドポイント（１１０）を、パラメータ・データに依存して識別すること（３０８）も含まれる。このＳＯＡＰ−ＨＴＴＰの例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（３０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.com/SOAP-HTTP/servlets/のＳＯＡＰ−ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００７３】
図６に示された方法に、要求（１０６）が同期応答を要求するかどうかを判定すること（３５０）も含まれる。要求（１０６）が同期応答を要求するかどうかを判定すること（３５０）は、受信された要求メッセージの最初の行のクエリ・データを検査することによって実行することができる。上に示した例示的なＰＯＳＴメッセージでは、最初の行のクエリ・データが、「？」とＨＴＴＰバージョン・コードの間のすべてのデータすなわち、
portType=A&synchRespReqd=True
である。この例では、「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」が、インターメディアリによって、同期応答が必要であることを意味すると解釈される。同様に、「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｆａｌｓｅ」は、同期応答が不要であることを示すことができる。これらは、例示的なコーディングにすぎず、もちろん、本発明の制限ではない。同期応答がインターメディアリに要求されるかどうかの表示をパラメータ情報内にエンコードするすべての手段が、好ましい実施形態による本発明の範囲に含まれる。この例では、要求が同期応答を要求するかどうかを判定すること（３５０）は、パラメータ情報（１０７）に応じてその判定を行うことによって実行され、このパラメータ情報は、名前／値対「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」である。
【００７４】
図示の方法に、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）が含まれる。この例では、インターメディアリが、ターゲット・サービスのエンドポイントを使用して、ＨＴＴＰ ＰＯＳＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。具体的に言うと、次のＰＯＳＴメッセージは、要求されたウェブ・サービス操作に関する入力メッセージまたは入力データの例を表す。パラメータ・データが、削除され、エンドポイントを識別するパラメータ・データならびに同期応答が必要であるかどうかを判定するパラメータ・データおよび要求が、ＳＯＡＰメッセージを処理するスクリプト、サーブレット、または他の機能性に向けられ、このスクリプト自体が、ＳＯＡＰエンベロープ内の操作名から操作を識別する。
【００７５】
結果のターゲット・サービス要求は、次のようになる。
POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1
Host: www.myTarget.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOpxmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【００７６】
図６の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）に、さらに、要求が同期要求を必要とするかどうかの判定（１５２）に応じてターゲット・サービス要求（１１４）を作成すること（３１２）を含めることができる。インターメディアリが、要求されるウェブ・サービス操作に関する入力データを有する入力メッセージを作成できるのと同様に、インターメディアリが、出力メッセージを作成することもできる。そのような出力メッセージは、通常、ターゲット・サービスからの応答メッセージを保管し、通信するのに使用されるプレースホールディング・オブジェクトである。同期応答を必要とする要求のために応答メッセージ・オブジェクトを作成する例示的な方法は、インターメディアリが、正しいクラスのオブジェクトを作成し、それを空のままにし、ターゲット・サービスに要求を通信する下流インターフェース（図３および４の符号（２２０）および（２２２）のプロバイダまたはアウトバウンド・エンジンなど）への１つまたは複数の呼出しのパラメータとして、そのオブジェクトへの参照を渡すことである。同期応答を必要としない要求のために応答メッセージ・オブジェクトを作成する例示的な方法は、インターメディアリが、ターゲット・サービスに要求を通信する下流インターフェースへの１つまたは複数の呼出しのパラメータとして、ヌル参照（単に空の出力オブジェクトへの参照ではなく、完全にヌルの参照）を渡すことである。そのような実施形態では、下流インターフェースが、そのようなヌル参照を、呼出し側に制御を返す前に「肯定応答」だけを待つことの表示として解釈するようにプログラムされる。
【００７７】
図６の方法に、ターゲット・サービス要求（１１４）をターゲット・サービス（１１８）に発行すること（３１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、そのＴＣＰ／ＩＰ接続を介してＨＴＴＰ ＰＯＳＴメッセージをターゲット・サービスに送信することが含まれる。
【００７８】
本発明の少なくともいくつかの実施形態で、図６に示されたものなどのポート・タイプ不可知プロキシ・サポートの方法で、作成され、ターゲット・サービスに発行されるターゲット・サービス要求が、ウェブ・サービス・インターメディアリで受信された要求の検査されず変更されないメッセージ内容を有することに留意することが有用である。上で説明した例では、インターメディアリのプロキシ・サービスが、メッセージ本体すなわちＳＯＡＰエンベロープにまったく手を付けず、オープンせず、検査せず、解析せず、どの形でも変更せずに、パラメータ・データ「ｐｏｒｔＴｙｐｅ＝Ａ」からターゲット・サービスのエンドポイントを識別し、そのように識別されたエンドポイントにメッセージをリダイレクトし、このＳＯＡＰエンベロープが、そのリクエスタからターゲット・サービスまでの配送の過程全体を通じて検査されず、変更されないままになる。この過程で、プロキシ・サービスは、インターメディアリ・サービス、認証、管理報告、負荷平衡化、サービス集約などのうちの１つまたは複数を提供した。
【００７９】
さらなる説明として、例示的な要求が、ＧＥＴ／ＨＴＴＰバインディングについて提示され、http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxyにあるエンドポイントに向けられる。例示的な着信要求メッセージは、次の形を有する。
GET/servlets/proxy?message=messageContentString&
operation=myOp&portType=A HTTP/1.1
また、ＵＲＩ空間では、例示的な要求を次のように示すことができる。
http://www.myIntermediary.com/servlets/
proxy?message=messageContentString&operation=myOp&portType=A
この例では、メッセージが、名前／値対としてエンコードされたＵＲＩエンコードされたクエリ・データ「ｍｅｓｓａｇｅ＝ｍｅｓｓａｇｅＣｏｎｔｅｎｔＳｔｒｉｎｇ」としてとられる。メッセージ内容は、ＵＲＩエンコードされた文字列である。この例では、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）のすべてが、メッセージ内容文字列に続くクエリ・データである。この例では、クエリ・データに、「Ａ」というポート・タイプとターゲット・サービスの操作の名前の両方が含まれる。
【００８０】
この例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別することは、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.comのＧＥＴ／ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００８１】
図６の方法には、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）も含まれる。この例では、インターメディアリが、ターゲット・サービス要求のエンドポイント・アドレスに操作名およびメッセージ・パーツを連結することによって、ＨＴＴＰ ＧＥＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。ＵＲＩ空間で表現された、結果のターゲット・サービス要求は、次のようになる。
http://www.myTarget.com/servlets/myOp?message=messageContentString
【００８２】
前に述べたように、図６の方法には、ターゲット・サービス（１１８）にターゲット・サービス要求（１１４）を発行すること（３１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、次のＨＴＴＰ ＧＥＴメッセージを送信することが含まれる。
GET/servlets/myOp?message=messageContentString HTTP/1.1
【００８３】
図６の方法に、要求が同期応答を必要とする場合（３６０）にターゲット・サービスからの応答を待つこと（３６１）も含まれる。図７に、ターゲット・サービスからの応答を待つ方法を示す流れ図を示すが、この方法には、インターメディアリで、ターゲット・サービスからの応答（１２２）を同期式に受信すること（３２０）と、ターゲット・サービスからの応答に応じて、インターメディアリ内で、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）をリクエスタ（１０２）に返すこと（３２８）が含まれる。図７の方法では、インターメディアリでターゲット・サービスからの応答を同期式に受信すること（３２０）を、インターメディアリとターゲット・サービスの間のデータ通信接続に対するブロッキング受信関数を呼び出すことによって実行することができる。
【００８４】
次の擬似コードのセグメントは、インターメディアリからターゲット・サービスに要求を送信し、要求が同期応答を必要とする場合にターゲット・サービスからの応答を待つ、ＨＴＴＰバインディングに関する例である。次のセグメントは、しばしば、本発明の実施形態に従って、ウェブ・サービス・インターメディアリのプロバイダを介してまたはアウトバウンド・エンジン内で（図３および４の２２０および２２２）提供されるものなどの、ＨＴＴＰバインディングに関するクライアント動作を例示するものである。
import java（Ｒ）.io.*;
import java（Ｒ）.net.*;
BufferedReader in = null;
URL url = new URL(targetURL);
URLConnection connection =(HttpURLConnection) url.openConnection();
BufferedWriter out = new BufferedWriter(new OutputStreamWriter (connection.getOutputStream()));
BufferedReader in = new BufferedReader(new InputStreamReader (
connection.getInputStream()));
out.println(request);
if(synchRespReqd == TRUE)
{
Message responseMessage = in.readLine();
return responseMessage;
}
この例示的擬似コード・セグメントは、Ｊａｖａ ＵＲＬオブジェクトを作成し、そのＵＲＬオブジェクトを使用して、ネットワーク・アドレス「ｔａｒｇｅｔＵＲＬ」を有するものとして識別されたターゲット・サービスへの、「ｃｏｎｎｅｃｔｉｏｎ」という名前のＴＣＰ／ＩＰ接続をオープンする。このセグメントは、その接続上の「ｏｕｔ」という名前のバッファリングされたストリームおよびその接続上の「ｉｎ」という名前の入力ストリームもオープンする。このセグメントは、「ｏｕｔ．ｐｒｉｎｔｌｎ（ｒｅｑｕｅｓｔ）」としてその接続を介して要求を送信し、その後、同期応答が必要な場合に、ブロッキング呼出しを行って、同一の接続を介して応答メッセージを受信し「Ｍｅｓｓａｇｅ ｒｅｓｐｏｎｓｅＭｅｓｓａｇｅ＝ｉｎ．ｒｅａｄＬｉｎｅ（）」、応答メッセージを呼出し側に返す。この例は、ＨＴＴＰバインディングに関する。
【００８５】
さらに説明するために、下で、「ＪＭＳ」バインディングすなわち、Ｊａｖａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅへのバインディングに関するもう１つの例を提示する。ＪＭＳは、ポイントツーポイント・メッセージング用およびパブリッシュ／サブスクライブ・メッセージング用の２つのメッセージ「ドメイン」を提供する。この例では、インターメディアリとターゲット・サービスの間の、ＪＭＳメッセージ・キューを使用するポイントツーポイント・メッセージングを論ずる。ＪＭＳポイントツーポイント・メッセージングでは、ソケットなどのデータ通信接続が、ＪＭＳの「ｃｏｎｎｅｃｔｉｏｎ」オブジェクトによってカプセル化される。ＪＭＳ ｃｏｎｎｅｃｔｉｏｎは、「ｃｏｎｎｅｃｔｉｏｎ ｆａｃｔｏｒｙ」と呼ばれる管理オブジェクトを介して作成される。ＪＭＳ ｃｏｎｎｅｃｔｉｏｎは、１つまたは複数のＪＭＳ「ｓｅｓｓｉｏｎ」を作成するのに使用される。ｓｅｓｓｉｏｎは、メッセージを作成し、消費する、シングルスレッドのコンテキストである。ｓｅｓｓｉｏｎは、メッセージ・プロデューサ、メッセージ・コンシューマ、およびメッセージを作成するのに使用される。メッセージ・プロデューサは、メッセージをキューに送るのに使用されるオブジェクトである。ポイントツーポイントの形のメッセージ・プロデューサが、ＪＭＳの「ｑｕｅｕｅＳｅｎｄｅｒ」インターフェースをインプリメントし、このインターフェースに、ｓｅｎｄ（）メソッドが含まれる。メッセージ・コンシューマは、キューからメッセージを受け取るのに使用されるオブジェクトである。ポイントツーポイントの形のメッセージ・コンシューマが、ＪＭＳの「ｑｕｅｕｅＲｅｃｅｉｖｅｒ」インターフェースをインプリメントし、このインターフェースに、タイムアウト期間ありまたはタイムアウト期間なしで呼び出すことができるブロッキングｒｅｃｅｉｖｅ（）メソッドが含まれる。
【００８６】
次の擬似コードのセグメントは、インターメディアリからターゲット・サービスに要求を送信し、要求が同期応答を必要とする場合にターゲット・サービスからの応答を待つ、ＪＭＳバインディングに関する例である。
// connectionを得る
QueueConnection queueConnection =
queueConnectionFactory.createQueueConnection();
// connectionを使用してsessionを確立する
// 「false」パラメータは、トランザクションなしを意味し、
// AUTO_ACKはオンである。
QueueSession queueSession =
queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
// センダを作成し、インターメディアリからの要求を
// JMSキューを介してターゲット・サービスに送信する。
QueueSender queueSender =queueSession.createSender(myQueue);
queueSender.send(requestMessage);
// 同期応答が必要な場合には、レシーバを作成し、
// レシーバに対するブロッキングreceive()を発行する。
if(synchRespReqd == TRUE)
{
QueueReceiver queueReceiver =queueSession.createReceiver(myQueue);
Message responseMessage =queueReceiver.receive();
return responseMessage;
}
この例示的なＪＭＳセグメントは、ｑｕｅｕｅＣｏｎｎｅｃｔｉｏｎという名前のｃｏｎｎｅｃｔｉｏｎを作成し、ｑｕｅｕｅＳｅｓｓｉｏｎという名前のｓｅｓｓｉｏｎを作成し、ｑｕｅｕｅＳｅｎｄｅｒという名前のセンダを作成し、ＪＭＳキューを介してターゲット・サービスに要求メッセージを送信し、同期要求が必要な場合には、ｑｕｅｕｅＲｅｃｅｉｖｅｒという名前のレシーバを作成し、応答メッセージを待つためにｑｕｅｕｅＲｅｃｅｉｖｅｒに対するブロッキングｒｅｃｅｉｖｅ（）を発行する。
【００８７】
要求が同期応答を必要としない場合（３６２）に、本発明の実施形態によるウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法に、ターゲット・サービスに要求を発行すること以外に絶対に何もしないことを含めることができる。すなわち、要求が同期応答を必要としない場合（３６２）に、肯定応答、非同期応答、および類似物に関してまったく何もしないことが、好ましい実施形態による本発明の範囲に含まれる。その代わりに、図６に示されているように、本発明の第２実施形態による方法に、ターゲット・サービス要求の肯定応答（１５６）をターゲット・サービスから受信すること（３５４）、および応答メッセージを待たずにリクエスタ（１０２）に肯定応答（１５６）を返すこと（３５８）を含めることができる。
【００８８】
次は、応答メッセージを待たずにリクエスタに肯定応答を返す例示的な擬似コード・セグメントである。
import java（Ｒ）.io.*;
import java（Ｒ）.net.*;
URL url = new URL(targetURL);
HTTPURLConnection connection =(HttpURLConnection) url.openConnection();
BufferedWriter out = new BufferedWriter(new OutputStreamWriter (connection.getOutputStream()));
BufferedReader in = new BufferedReader (
new InputStreamReader (connection.getInputStream()));
out.println(request);
int acknowledgment =connection.getResponseCode();
if(acknowledgment == 200) returnacknowledgement;
else return ERROR;
この例示的擬似コード・セグメントは、Ｊａｖａ ＵＲＬオブジェクトを作成し、そのＵＲＬオブジェクトについて、ＨＴＴＰＵＲＬＣｏｎｎｅｃｔｉｏｎオブジェクトの形で、ネットワーク・アドレス「ｔａｒｇｅｔＵＲＬ」を有するものとして識別されたターゲット・サービスへの、「ｃｏｎｎｅｃｔｉｏｎ」という名前のＴＣＰ／ＩＰ接続をオープンする。このセグメントは、その接続上の「ｏｕｔ」という名前のバッファリングされた出力ストリームおよびそのソケット上の「ｉｎ」という名前の入力ストリームもオープンする。このセグメントは、「ｏｕｔ．ｐｒｉｎｔｌｎ（ｒｅｑｕｅｓｔ）」としてその接続を介して要求を送信し、その後、ブロッキング呼出しを行って、同一の接続を介して肯定応答を受信する「ｉｎｔ ａｃｋｎｏｗｌｅｄｇｍｅｎｔ＝ｃｏｎｎｅｃｔｉｏｎ．ｇｅｔＲｅｓｐｏｎｓｅＣｏｄｅ（）」。このセグメントは、呼出し側に肯定応答（この例では、ＨＴＴＰ応答コード「２００」）を返すか、エラー・メッセージを返す。肯定応答は、要求が受信されたことの、ターゲット・サービスからの手続的肯定応答である。このセグメントは、要求に対する本質的な応答を待たない。
【００８９】
上の例示的擬似コード・セグメントは、インターメディアリからターゲット・サービスに要求を送信し、本質的な応答メッセージを待たずに肯定応答を供給する例である。このセグメントは、しばしば、本発明の実施形態に従って、ウェブ・サービス・インターメディアリのプロバイダを介してまたはアウトバウンド・エンジン内で（図３および４の２２０および２２２）提供されるものなどの、ＨＴＴＰバインディングに関するクライアント動作を例示するものである。
【００９０】
当技術分野における技量を有する読者は、ここまでに、リクエスタがターゲット・サービスの操作に関する要求をどのようにしてインターメディアリに送信するかを不思議に思っている。答は、インターメディアリまたはインターメディアリの開発者が、リクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別することである。ターゲット・サービスの操作をサポートするエンドポイントとしてインターメディアリのエンドポイントを識別することは、リクエスタによるディスカバリのためにビジネス・ディレクトリに登録されるＷＳＤＬ文書でインプリメントすることができる。その代わりに、そのような識別を、インターメディアリからリクエスタにダウンロードすることができ、あるいは、リクエスタのウェブ・サービス構成データへの管理者によるインストールのために、単純にリクエスタまたはリクエスタの管理者に電子メールで送ることさえできる。
【００９１】
ターゲット・サービスがＷＳＤＬ擬似コードの次のセグメントによって記述される例を検討されたい。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location=
"http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
【００９２】
そのターゲット・サービスのインターメディアリは、次のようにターゲット・サービス記述のアドレス拡張要素の位置属性を置換することによって、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントをリクエスタに対して識別することができる。
<soap:addresslocation="http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
これによって、次のセグメントによって例示されるＷＳＤＬ文書が作成される。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="portTypeAgnosticProxy">
<portname="intermediaryEndpoint" binding="SOAPBinding">
<soap:address location=
"http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
</port>
</service>
</definitions>,
これは、ターゲット・サービスでの「ｇｅｔＱｕｏｔｅ」操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別する。レジストリ、ダウンロード、電子メールを介して、または当業者が思い浮かべる他の手段によって、この後者のセグメントによって例示される種類のＷＳＤＬをリクエスタに提供することによって、そのリクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントが識別される。
【００９３】
図６の方法では、パラメータ情報（１０７）に応じて、操作をサポートするターゲット・サービスのエンドポイントを識別すること（３０８）に、しばしば、ターゲット・サービスの１つのエンドポイントだけではなく、操作をサポートするターゲット・サービスの２つ以上のエンドポイントを識別することを含めることができる。本発明方法の実施形態によるポート・タイプ不可知プロキシが、操作のポート・タイプをパラメータ情報（１０７）として受信し、クエリ・パラメータとしてポート・タイプを用いてビジネス・レジストリを照会し、これによって操作をサポートするターゲット・サービスの２つ以上のエンドポイントを識別する例を検討されたい。２つ以上のエンドポイントのそのような識別は、例えば、ポート・タイプを用いてＵＤＤＩレジストリに照会し、それに応答して、そのポート・タイプに関するターゲット・サービスを記述した複数のＷＳＤＬ文書を受信することによって実行することができる。
【００９４】
複数のエンドポイントがそのように識別される場合に、本発明の実施形態によるウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に、通常、選択ルールに従ってエンドポイントのうちの１つを選択することが含まれる。自明な例では、選択ルールを、そのように識別された最初のエンドポイントを選択し、他のエンドポイントを破棄することとすることができる。選択ルールは、例えば、負荷平衡化に関する選択ルールを含む、より複雑なルールとすることができる。負荷平衡化に関するルールは、表２に示されたものに類似したデータ構造の使用によってインプリメントすることができる。
【００９５】
【表２】
【００９６】
表２の各行は、インターメディアリとターゲット・サービスの間のウェブ・サービス・データ通信の要求−応答ラウンド・トリップに関する待ち時間測定値を表す。表２には、要求および応答のラウンドごとに、ポート・タイプおよびエンドポイントＵＲＩの列が設けられている。送信時刻列は、要求メッセージが、インターメディアリからポート・タイプの操作に関するターゲット・サービスのエンドポイントに発行されたときの時刻を記録したものである。受信時刻列は、対応する応答メッセージがターゲット・サービスから受信されたときの時刻を記録したものである。トリップ待ち時間は、受信時刻と送信時刻の差である。累積待ち時間は、この表に表されたエンドポイントごとのトリップ待ち時間の現在合計である。表２に似た構造を用いて、要求に関する複数のエンドポイントが識別されたときに使用される選択ルールを、次の例示的なルールとしてインプリメントすることができる。
同一ポート・タイプの操作に関する複数の要求がインターメディアリに達したときには、複数の識別されたエンドポイントのそれぞれを順番に１回使用する。
そのような使用のそれぞれの待ち時間データを記録する。
同一ポート・タイプの操作に関する後続要求について、最短の累積待ち時間を有するエンドポイントを待ち時間テーブルから選択し、要求をそのエンドポイントに送信し、メッセージがターゲット・サービスに送信されるときおよび対応する応答がインターメディアリで受信されるときに、関連する待ち時間データを記録する。
【００９７】
表２の例示的データには、ポート・タイプＡについて２つのエンドポイントすなわち、URIhttp://www.ibm.com/aTargetServiceにある第１エンドポイントおよびURIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントに最近送信された要求の累積待ち時間が示されている。第１エンドポイントは、２５０ミリ秒の累積要求待ち時間を有し、第２エンドポイントは、１００ミリ秒の累積要求待ち時間を有する。上で示した例示的な選択ルールを使用すると、ポート・タイプＡに関する操作の現在の要求は、URIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントにルーティングされる。
【００９８】
図６の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）を、バインディング中立インターフェース内で有用なデータ構造内に要求を構成し、その要求を呼出しパラメータとして渡してバインディング中立インターフェースを呼び出すことによって実行することができる。同様に、ターゲット・サービスにターゲット・サービス要求（１１４）を発行すること（３１６）に、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことが含まれる。
【００９９】
バインディング中立インターフェースは、そのインターフェースの使用が要求またはメッセージのバインディングに依存しないインターフェースである。すなわち、このインターフェースをインプリメントし、それを介するデータ通信を実行するのに使用されるデータ構造および呼出し方法は、メッセージに使用されるデータ・エンコーディングのタイプに依存せず、メッセージに使用されるデータ通信プロトコルに依存しない。本発明の実施形態によるインターメディアリ用のポート・タイプ不可知プロキシの開発者は、しばしば、彼ら自身のバインディング中立インターフェースを作成する。しかし、「ＷＳＩＦ」すなわちWeb Service Invocation Frameworkと称する、バインディング中立インターフェースのオープン標準規格がある。ＷＳＩＦは、現在、ApacheSoftware FoundationのWeb Services Projectの一部としてサポートされている。
【０１００】
バインディング中立インターフェースの使用は、本発明の実施形態に利益をもたらす。ＳＯＡＰ−ＨＴＴＰバインディングは、現在の技術で非常に一般的なので、ユーザおよび開発者は、時々、他のバインディングが存在することを忘れる。これは、他のバインディングと共に使用されるか他のバインディングと共に使用するために適合させることが、不可能でないとしても非常にむずかしいシステムの開発をもたらす。しかし、ウェブ・サービスが成長するにつれて、他のバインディングが、より有用でより一般的になる。さらに、本発明の実施形態のバック・エンドにバインディング中立インターフェースを使用することは、使用可能なバインディングをラン・タイムに決定でき、これによって、柔軟で強力でより一般的に有用なウェブ・サービス・インターメディアリが提供されることを意味する。
【０１０１】
バインディング中立インターフェースをインプリメントする形の１つが、ポート・タイプおよびエンドポイントを与えられてターゲット・サービス内のサービスを呼び出すことができるエンドポイント・オブジェクトを提供することである。そのようなエンドポイント・オブジェクトを提供する形の１つが、次の擬似コード・セグメントに例示されたものに似たエンドポイント・ファクトリを使用することによるものである。
// エンドポイント・ファクトリ・クラス
// エンドポイント・オブジェクトを作成するパラメータ化されたファクトリ・メソッドを定義する
//
class EndpointFactory
{
public static EndpointcreateEndpointObject(portType, networkAddress)
{
// 新しいエンドポイント・オブジェクトの参照を確立する
Endpoint anEndpoint = null;
if(portType == "A" &&networkAddress == "www.abc.com")
anEndpoint = new Endpoint1;
if(portType == "B" && networkAddress== "www.def.com")
anEndpoint = new Endpoint2;
if(portType == "C" &&networkAddress == "www.ghi.com")
anEndpoint = new Endpoint3;
...
if(portType == "LAST" &&networkAddress == "www.lastSupported.com")
anEndpoint = new Endpoint465;
if anEndpoint == null) reportError();
else return anEndpoint;
}// createEndpointObject()の終り
}// クラスEndpointFactoryの終り
【０１０２】
エンドポイント・クラスＥｎｄｐｏｉｎｔ１、Ｅｎｄｐｏｉｎｔ２、Ｅｎｄｐｏｉｎｔ３などは、メッセージ・パーツを含むメッセージ・オブジェクトを作成するメンバ・メソッドを提供する抽象エンドポイント・クラスを継承する（または、インターフェースとしてインプリメントする）具象クラスである。そのようなエンドポイント・ファクトリおよびそのようなバインディング中立インターフェースの他の要素を使用して、次の擬似コード・セグメントに示されているように、ターゲット・サービス要求（１１４）を作成するステップ（３１２）およびターゲット・サービスにターゲット・サービス要求（１１４）を発行するステップ（３１６）を実行することができる。
// エンドポイント・ファクトリからエンドポイント・オブジェクトを得る
Endpoint ep = endPointFactory.createEndPoint(portType,networkAddress);
// 入力メッセージを用意する
Message input = ep.createInputMessage();
// メッセージ・アクセス関数を使用してメッセージの内容を挿入する
input.setPart("symbol","IBM");
// 応答値のプレースホルダを用意する
Message output = null;
if(synchRespReqd == TRUE) output = ep.createOutputMessage();
// 操作を実行する
ep.executeRequestResponseOperation("getQuote",
input, output);
// 結果を返す
if(synchRespReqd == TRUE) return output;
else return ACK;
【０１０３】
この例示的な擬似コード・セグメントは、エンドポイントのポート・タイプおよびネットワーク・アドレスを与えられて、エンドポイント・ファクトリを呼び出してエンドポイント・オブジェクトを作成する。次に、このセグメントは、メッセージ・パーツをエンドポイント・オブジェクトにロードすることによってターゲット・サービス要求を作成し、メンバ・メソッドｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）を呼び出すことによってターゲット・サービスにターゲット・サービス要求を発行する。図７の方法に、ターゲット・サービスからの応答（１２２）をインターメディアリで受信すること（３２０）と、インターメディアリで、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（３２８）が含まれる。
【０１０４】
この例示的な擬似コード・セグメントでは、ターゲット・サービスからの応答（１２２）を受信するステップ（３２０）およびインターメディアリからの応答（１２６）を作成するステップ（３２４）が、ｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）への呼出しによってインプリメントされる。この例では、出力メッセージへの参照の値は、要求が同期応答を必要とする場合にヌルのままにされる。この種類の実施形態のヌル「ｏｕｔｐｕｔ」パラメータは、プロバイダ（図３の２２０）によって、同期応答が不要であることを意味すると解釈される。したがって、プロバイダは、要求をターゲット・サービスに発行し、応答を待たずに即座にリターンする。
【０１０５】
同様に、要求が同期応答を必要とする場合に、応答メッセージへの参照「ｏｕｔｐｕｔ」の値に、ｏｕｔｐｕｔ＝ｅｐ．ｃｒｅａｔｅＯｕｔｐｕｔＭｅｓｓａｇｅ（）によって非ヌルがセットされる。呼出し
ep.executeRequestResponseOperation("getQuote",input, output)
での、この例では「ｏｕｔｐｕｔ」という名前の応答メッセージへのパラメータ参照が非ヌルであるという事実は、プロバイダ（図３の２２０）によって、同期応答が必要であることを意味すると解釈される。そのようなプロバイダは、そのアウトバウンド・エンジン（図３の２２２）でブロッキング受信呼出しを行い、ターゲット・サービスからの対応する応答メッセージを待つようにプログラムされる。図７の方法に関して、このセグメントは、要求が同期応答を必要とするかどうかの判定（１５２）に応じて、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）の例示的方法を表す。
【０１０６】
上の例の擬似コード・セグメントは、エンドポイントとして参照されるポートを有するバインディング中立インターフェースの使用を例示するものである。しかし、ＷＳＩＦインターフェース構文は、エンドポイントを参照するときに用語「ポート」を使用する。したがって、バインディング中立インターフェースの使用に関するさらなる説明として、ＷＳＩＦ標準規格をより厳守するさらなる例示的擬似コード・セグメントを示す。この例では、「ポート」が、「エンドポイント」を意味するのに使用され、説明の一貫性を保つために、ファクトリの名前が、「ｐｏｒｔＦａｃｔｏｒｙ」に変更されている。
// ファクトリからポート（エンドポイント）を得る
WSIFPort port =portFactory.getPort(portType, networkAddress);
// 入力メッセージを用意する
WSIFMessage input =port.createInputMessage();
// メッセージ内容を挿入する
input.setPart("symbol",
new WSIFＪａｖａ（Ｒ）Part(String.class, symbol));
// 応答値のプレースホルダを用意する
WSIFMessage output = null;
if(synchRespReqd == TRUE) output = port.createOutputMessage();
// 操作を実行する
port.executeRequestResponseOperation("getQuote",
input, output, null);
// 結果を抽出し、返す
if(synchRespReqd == TRUE) return output;
else return ACK;
【０１０７】
本明細書では、主にリクエスタからターゲット・サービスへの過程での要求の処理に関して、ウェブ・サービス・インターメディアリでのポート・タイプ不可知プロキシ・サポートの例示的方法を論ずるが、本発明の実施形態によるインターメディアリが、通常、ターゲット・サービスからインターメディアリを介して最初のリクエスタに戻る応答メッセージを処理することもできることに留意することが有用である。例えば、図７の方法に、要求が同期応答を必要とする場合に、インターメディアリ内でターゲット・サービスから応答（１２２）を受信すること（３２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（３２８）が含まれる。
【０１０８】
前述の説明から、本発明の真の趣旨から外れずに、本発明の様々な実施形態で修正および変更を行うことができることを理解されたい。本明細書の説明は、例示のみを目的とし、制限的な意味で解釈されてはならない。本発明の範囲は、添付請求項の言葉だけによって制限される。
【図面の簡単な説明】
【０１０９】
【図１】本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャを示す線画である。
【図２】本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャを示す線画である。
【図３】本発明の実施形態による例示的なインターメディアリのブロック図を示す線画である。
【図４】本発明の実施形態によるＳＯＡＰ−ＨＴＴＰチャネルをインプリメントする例示的なインターメディアリ（２０２）のブロック図を示す線画である。
【図５】第１の実施形態による、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図である。
【図６】第２の実施形態による、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図である。
【図７】第２の実施形態による、要求が同期応答を必要とするときにターゲット・サービスからの応答を待つ（３６１）方法を示す流れ図である。
【技術分野】
【０００１】
本発明の分野は、データ処理であり、より詳細には、ウェブ・サービス・インターメディアリ（intermediary）のポート・タイプ不可知プロキシ（port type agnostic proxy）サポートの方法、システム、および製品に関する。
【背景技術】
【０００２】
用語「ウェブ・サービス」は、ウェブベース・アプリケーションを統合する標準化された形を指す。ウェブ・サービスは、通常、バインディングと呼ばれる標準化されたフォーマットでのデータ通信を介する要求の際にビジネス・サービスを提供する。バインディングは、データ・エンコーディング方法およびデータ通信プロトコルの指定である。ウェブ・サービスに使用される最も一般的なバインディングは、ＳＯＡＰプロトコルによるＸＭＬでのデータ・エンコーディングおよびＨＴＴＰを用いるデータ通信である。
【０００３】
ブラウザ・クライアントからの要求に応答してＨＴＭＬ文書を供給するＨＴＴＰサーバなどの伝統的なクライアント／サーバ・モデルと異なって、ウェブ・サービスは、表示に関係しない。その代わりに、ウェブ・サービスは、ネットワークにまたがるプログラム的インターフェースを介してビジネス・ロジック、データ、およびプロセスを共用する。ウェブ・サービス・アプリケーションは、ユーザではなく、お互いとインターフェースする。ウェブ・サービスの間のすべてのデータ通信が、標準化されたバインディングに従って実行されるので、ウェブ・サービスは、１つのオペレーティング・システムまたはプログラミング言語に束縛されない。Ｗｉｎｄｏｗｓ（Microsoft Corporationの商標）プラットフォームで稼動するＪａｖａ（Sun Microsystemの商標）クライアントが、Ｐｅｒｌで記述されＵｎｉｘ（TheOpen Groupの商標）で稼動するウェブ・サービス操作を呼び出すことができる。Ｃ＋＋で記述されたＷｉｎｄｏｗｓアプリケーションが、Ｊａｖａ（SunMicrosystemの商標）サーブレットとして実装されたウェブ・サービスの動作を呼び出すことができる。
【０００４】
現在、ウェブ・サービスは、多数の産業にまたがって成長しつつある。ウェブ・サービスが重要性を増すにつれて、ウェブ・サービス・インターメディアリが、ますます、多数の付加価値サービスを提供する手段として認められる。本明細書で一般に「インターメディアリ」と称するウェブ・サービス・インターメディアリは、ウェブ・サービス・クライアントとウェブ・サービス・プロバイダの間にあるウェブ・サービス・コンポーネントである。インターメディアリは、一般に、クライアントからの要求をインターセプトし、インターメディアリ・サービスを提供し、その後、クライアント要求をウェブ・サービス・プロバイダに転送することによって動作する。同様に、ウェブ・サービス・プロバイダからの応答が、インターセプトされ、操作され、その後、クライアントに返される。ウェブ・サービス・インターメディアリを実装できる市販製品の例に、ＩＢＭ社のWeb Services Gateway（商標）およびＩＢＭ社のWeb Services Bus（商標）が含まれる。
【０００５】
インターメディアリによって提供されるサービスに、ターゲット・サービスに関する要求のソースの認証、内容およびフォームに関するメッセージ妥当性検査、ならびに監査のためのメッセージ・ログ記録が含まれる。インターメディアリは、管理報告サービス、ウェブ・サービス・ヒットの個数、個々のクライアントによって使用されたサービスの品質およびタイミングなどを提供することができる。インターメディアリを、例えば新聞記事など、頻繁に変更されるが頻繁に要求されるデータを保管することによって、改善された性能をサポートするキャッシュとして使用することができる。インターメディアリを、複数のクライアントからのサービスに関する要求を保管し、これらをオフピーク・サービス時間中にターゲット・サービスに転送することによって、負荷平衡化の意味での性能改善に使用することができる。インターメディアリは、例えば、債務勘定、売掛金勘定に関する別々のターゲット・サービスおよび一般的な台帳サービスにその後に転送されるアカウント・ポスティングに関する要求を受け入れる会計インターメディアリとして、サービスを集約することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来技術では、ウェブ・サービス・インターメディアリを実装し、その結果、これらをそのターゲット・サービスに密結合することが一般的である。すなわち、特定のインターメディアリは、特定のターゲット・ウェブ・サービスだけにインターメディアリ・サービスを提供する。これに関する必要は、例えば、インターメディアリがメッセージ妥当性検査を提供し、したがって正しいメッセージ内容およびフォームの正確な知識を有しなければならないときに、明らかである。ウェブ・サービスの用語法では、動作のグループを、「ポート・タイプ」と呼ぶ。この用語法では、密結合の制限は、一般に、従来技術で、インターメディアリ・サービスおよびそのインターメディアリ・サービスによってサービスされるすべてのターゲット・サービスが、同一のポート・タイプを有することを意味する。しかし、例えば、ポート・タイプに無関係にすべてのターゲット・サービスに向けられたメッセージに対する正確に同一の認証機能を提供すること意図されたクライアント・アイデンティティ認証機能など、インターメディアリ・サービスが、ポート・タイプにまたがって機能することが有用である状況がある。従来技術はそのような場合での追加の構成の複雑さを強制し、ウェブ・サービス・インターメディアリでの改善は引き続き必要とされている。
【課題を解決するための手段】
【０００７】
第１の態様によれば、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法であって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとを含む方法が提供される。
【０００８】
一実施形態で、前記要求が同期応答を必要とするかどうかを判定し、前記要求が同期応答を必要とする場合に、前記ターゲット・サービスからの応答を待つ。
【０００９】
通常の実施形態で、前記要求が同期応答を必要とするかどうかを判定することが、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定することによって実行される。通常の実施形態で、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成することを含む。同期応答を必要しない要求に関して、いくつかの実施形態が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信することと、応答メッセージを待たずに前記肯定応答をリクエスタに返すこととを含む。
【００１０】
同期応答を必要とする要求に関して、いくつかの実施形態が、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答をリクエスタに返すこととによって、前記ターゲット・サービスからの応答を待つことをインプリメントする。通常の実施形態で、ターゲット・サービスからの応答をインターメディアリ内で同期式に受信することが、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出すことによって実行される。
【００１１】
多くの実施形態で、作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する。例示的な実施形態は、通常、要求−応答処理のリターン・パスと、前記インターメディアリで前記ターゲット・サービスからの応答を受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととをも含む。
【００１２】
本発明の通常の実施形態は、前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別することも含む。そのような実施形態で、パラメータ情報が、しばしば、前記操作のポート・タイプを含む。さらに、操作をサポートするターゲット・サービスのエンドポイントを識別することが、しばしば、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することと、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することとをも含む。操作をサポートするターゲット・サービスの複数のエンドポイントを識別することが、ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別することによって実行されることができる。前記複数のエンドポイントから１つのエンドポイントを選択することが、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することを含むことができる。
【００１３】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求をバインディング中立インターフェースで有用なデータ構造に構成することと、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出すこととによって実行されることができる。前記ターゲット・サービスに前記ターゲット・サービス要求を発行することが、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことを含むことができる。
【００１４】
第２の態様によれば、本発明は、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのシステムであって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する手段とを含むシステムを提供する。
【００１５】
第３の態様によれば、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのコンピュータ・プログラム製品であって、記録媒体と、ウェブ・サービス・インターメディアリ内でウェブ・サービス操作の実行に関する要求を受信する前記記録媒体に記録された手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、前記記録媒体に記録された手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する前記記録媒体に記録された手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する前記記録媒体に記録された手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する前記記録媒体に記録された手段とを含むコンピュータ・プログラム製品が提供される。
【００１６】
本発明を、コンピュータ・ソフトウェアでインプリメントすることができる。
【００１７】
本発明の好ましい実施形態を、例としてのみ、添付図面を参照してこれから説明する。
【発明を実施するための最良の形態】
【００１８】
本発明を、大体において、本明細書ではウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に関して説明する。しかし、当業者は、開示される方法に従って動作する適当なプログラミング手段を含むすべてのコンピュータ・システムも、本発明の範囲に含まれることを理解するであろう。適当なプログラミング手段に、本発明の方法のステップを実行するようにコンピュータ・システムに指示するすべての手段が含まれ、これには、例えば、データおよびプログラム命令を保管するように構成された電子回路を含むコンピュータ・メモリに、処理ユニットによる実行のために本発明の方法のプログラムされたステップをコンピュータ・メモリに保管する能力を有する、コンピュータ・メモリに結合された処理ユニットおよび算術論理回路からなるシステムが含まれる。
【００１９】
本発明を、適当なデータ処理システムと共に使用される、ディスケットまたは他の記録媒体など、コンピュータ・プログラム製品で実施することもできる。コンピュータ・プログラム製品の実施形態を、磁気媒体、光媒体、または他の適当な媒体を含む機械可読情報用のすべての記録媒体の使用によってインプリメントすることができる。当業者は、適当なプログラミング手段を有するすべてのコンピュータ・システムが、プログラム製品で実施された本発明の方法のステップを実行できることを、即座に理解するであろう。当業者は、本明細書で説明される例示的実施形態のほとんどが、コンピュータ・ハードウェアにインストールされ、実行されるソフトウェアに向かうものではあるが、それでも、ファームウェアまたはハードウェアとしてインプリメントされる代替実施形態も、本発明の範囲に含まれることを即座に理解するであろう。
【００２０】
定義
本明細書で使用される用語としての「ビジネス・レジストリ」は、会社およびその会社によって提供されるウェブ・サービスのリスティングを含む、ウェブ・サービスのインターネット・ディレクトリである。ウェブ・サービスのリスティングには、サポートされる操作、ポート・タイプ、エンドポイント、バインディングなどが含まれる。ビジネス・レジストリには、ｅｂＸＭＬなどのオープン標準規格に基づくものや、ＵＤＤＩなどの産業コンソーシアムが主導する仕様に基づくものがある。会社は、レジストリにそれ自体を登録することができる。会社は、レジストリを介して共用される材料をサブミットすることができ、レジストリ・クライアントは、他者がサブミットした材料を検索することができる。ブラウザを介して手動でまたはそれ自体をウェブ・サービスとすることのできるＡＰＩを介してプログラム的に、ビジネス・レジストリにアクセスし、検索することができる。レジストリは、会社が疎結合された形で互いに動的に協力することを可能にするので、ウェブ・サービスのますます重要なコンポーネントになりつつある。
【００２１】
ＨＴＴＰは、「ハイパーテキスト転送プロトコル」すなわち、ウェブ上で最も一般的なデータ通信プロトコルを意味する。しかし、本明細書では、用語「ウェブ」が、ＨＴＴＰ通信に制限されるのではなく、ＨＤＴＰすなわちHandheld Device Transfer ProtocolまたはＷＡＰすなわちWireless Access Protocolおよび当業者が思い浮かべる他のプロトコルなど、通信の類似するモードをサポートする他のプロトコルを用いる通信も含むことができる。
【００２２】
「ＳＯＡＰ」は、「Simple Object Access Protocol」すなわち、ウェブ・サービスの要求メッセージおよび応答メッセージをネットワークを介して送信する前に、これらの情報をエンコードするのに使用される軽量ＸＭＬベース・メッセージング・プロトコルを意味する。ＳＯＡＰメッセージは、すべてのオペレーティング・システムまたはプロトコルから独立しており、ＳＭＴＰ、ＭＩＭＥ、およびＨＴＴＰを含む様々なインターネット・プロトコルを使用して転送することができる。
【００２３】
「ＵＤＤＩ」は、「Universal Description,Discoveryand Integration」すなわち、会社がインターネット上でそれ自体をリストし、お互いを発見することを可能にする、従来の職業別電話帳および個人別電話帳に似た、ウェブベース分散ディレクトリを意味する。
【００２４】
「ＷＳＤＬ」は、「Web Services Description Language」を意味する。ＷＳＤＬは、Ｍｉｃｒｏｓｏｆｔ社およびＩＢＭ社によって共同開発されたＸＭＬフォーマットの言語であり、メッセージを交換できる通信エンドポイントの集合としてウェブ・サービスの機能を記述するのに使用される。ＷＳＤＬは、ＵＤＤＩがウェブ・サービスの機能を記述するのにＷＳＤＬを使用するという点で、ＵＤＤＩの一体化された部分である。
【００２５】
「ｅｂＸＭＬ」は、「electronic business ExtensibleMarkup Language」すなわち、電子商取引の取引を容易にするための、ＸＭＬでのウェブ・サービスの記述を標準化する仕様のモジュラ・スイートである。ＵＤＤＩに似て、ｅｂＸＭＬ仕様は、ウェブ・サービスを定義し登録する標準的な方法を会社に与える。
【００２６】
本明細書では、一般に、ＷＳＤＬの用語法に似た用語法を用いてウェブ・サービスのコンポーネントを記述する。ウェブ・サービスは、メッセージを交換できるネットワーク・エンドポイントすなわちデータ通信のエンドポイントの集合として記述される。エンドポイントを、時々「ポート」と呼ぶ。しかし、本明細書では、一般に、用語「ポート・タイプ」との混乱の危険を減らすために、用語「エンドポイント」が、「ポート」より好ましい。ポート・タイプは、ポートのタイプでもエンドポイントのタイプでもない。ポート・タイプは、サービスによってサポートされる、「操作」の集合すなわちソフトウェアのアクションまたは機能の集合である。
【００２７】
あるポート・タイプに関する特定の通信プロトコルおよびデータ・フォーマットの指定が、「バインディング」を構成する。バインディングの一例が、メッセージ・データがＳＯＡＰに従ってエンコードされ、メッセージがＨＴＴＰに従ってエンドポイントの間で通信されるＳＯＡＰ／ＨＴＴＰである。バンディングのもう１つの例が、メッセージ・データがＧＥＴメッセージまたはＰＯＳＴメッセージでエンコードされ、データ通信がＨＴＴＰに従って実行されるＧＥＴ／ＰＯＳＴ／ＨＴＴＰである。
【００２８】
各ポート・タイプは、複数のバインディングを有することができる。エンドポイントは、ネットワーク・アドレスにバインディングを関連付けることによって定義され、上で述べたように、エンドポイントの集合が、サービスを定義する。ウェブ・サービスでの操作に関するデータおよび要求の通信は、「メッセージ」と呼ばれるデータ構造を介して実行され、このメッセージは、「パーツ」からなる。用語「要求」および「応答」は、一般に、メッセージ・フローの向きを示す。特定のバインディングの要求メッセージおよび応答メッセージは、同一の構造を有することができる。
【００２９】
ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポート
添付図面を参照し、図１および２から始めて、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法、システム、および製品を説明する。図１に、本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャの線画を示す。図１のアーキテクチャでは、インターメディアリ（２０２）は、あるプロトコルを介するデータ通信をリクエスタ（１０２）およびターゲット・サービス（１１８）に接続することができる。リクエスタ（１０２）の位置のウェブ・サービス・コンポーネントを、時々、クライアントと称する。同様に、インターメディアリ（２０２）の位置のコンポーネントを、特にリクエスタの観点から見たときに、時々、サーバと称する。
【００３０】
クライアント／サーバの区別は、ウェブ・サービスの文脈では注意深く使用されなければならない。例えば、図２のアーキテクチャでは、ターゲット・サービス（１１８）が、リクエスタ（１０２）からの要求に対する応答を準備する処理で、インターメディアリ（２０３）を介してターゲット・サービス（１１９）からウェブ・サービスを要求する場合がある。それを行う際に、ターゲット・サービス（１１８）は、クライアントとして働いている。要求をターゲット・サービス（１１８）に転送する際に、インターメディアリ（２０２）は、クライアントとして働いている。特定のコンポーネントが、特定のときにクライアントまたはサーバのどちらと考えられるかは、そのときにそのコンポーネントによって実行されている特定の機能に依存する。すなわち、あるウェブ・サービス・コンポーネントが、ある瞬間にクライアントであり、次の瞬間にサーバになることができる。したがって、用語法からの混乱の危険を減らすために、ウェブ・サービス・コンポーネントは、通常、本明細書で、「クライアント」または「サーバ」ではなく、用語「リクエスタ」、「インターメディアリ」、および「ターゲット・サービス」を使用することによって記述される。
【００３１】
インターメディアリ（２０２）がターゲット・サービス（１１８）の代わりにインターメディアリ・サービスを提供するためには、インターメディアリ（２０２）は、ターゲット・サービス（１１８）上のエンドポイントを知らなければならない。上で述べたように、従来技術では、インターメディアリ（２０２）で稼動する「プロキシ」と呼ばれるサービスが、ターゲット・サービス（１１８）と同一のポート・タイプをサポートし、その構成データにターゲット・サービス（１１８）のエンドポイントを有する。しかし、図１および２のアーキテクチャでは、プロキシが、「ポート・タイプ不可知」であり、これは、プロキシへの使用可能な構成データが、ターゲット・サービスのエンドポイントを記述しないことと、リクエスタ（１０２）が、インターメディアリに完全に未知のポート・タイプの操作に関する要求をサブミットできることを意味する。
【００３２】
図３に、本発明の実施形態による例示的なインターメディアリ（２０２）のブロック図の線画を示す。インターメディアリ（２０２）に、少なくとも１つの中央処理装置、コンピュータ・メモリ、システム・バスなどを含む、自動化されたコンピューティング機械すなわちコンピュータ・システムが含まれる。図３のブロック図のブロックは、インターメディアリ（２０２）のコンピュータ・システムで動作可能なソフトウェア・アプリケーション・モジュールを表す。図３の矢印は、ソフトウェア・モジュールの間のデータ・フローを表す。
【００３３】
インターメディアリ（２０２）に、ウェブ・サービス操作の実行に関する、パラメータ情報（１０７）を含む要求（１０６）をリクエスタ（１０２）から受信することができるインバウンド・エンジン（２０８）が含まれる。次は、ＳＯＡＰ−ＨＴＴＰバインディングに関するそのような要求の例である。
POST /Channel/proxy?portType=A HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。すなわち、ターゲット・サービス（１１８）で実行される操作の名前が、ｓｏａｐメッセージ内で内部的に識別されている。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、この操作をサポートするターゲット・サービス（１１８）のエンドポイントをそれから識別できるパラメータ情報（１０７）が、このＰＯＳＴの第１行のＵＲＩエンコードされたクエリ文字列の名前／値対「ｐｏｒｔＴｙｐｅ＝Ａ」に示されている。
【００３４】
第２の実施形態では、例示的要求の第１行が、次のようになる。
POST/Channel/proxy?portType=A&synchRespReqd=True HTTP/1.1
この第２の実施形態では、パラメータ情報に、名前／値対「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」が含まれ、この対から、本発明の実施形態によるポート・タイプ不可知プロキシが、この要求が同期応答を要求するかどうかを判定することができる。
【００３５】
ウェブ・サービスに関する、パラメータ情報（１０７）を含む要求（１０６）をリクエスタ（１０２）から受信することに加えて、インバウンド・エンジン（２０８）は、パラメータ・データを含む要求をポート・タイプ不可知プロキシ（２１２）に供給する能力も有する。インバウンド・エンジン操作の一例として、上で示した例示的要求を検討されたい。その例示的要求は、ＳＯＡＰ−ＨＴＴＰとしてバインドされている。したがって、この例示的要求に関して、インバウンド・エンジンを、例えばＪａｖａ（Ｒｈ）Ｂｅａｎ、Ｊａｖａ（Ｒ）サーブレット、またはＰｅｒｌで記述されたＣＧＩ（Common Gateway Interface）スクリプトを含むすべての種類のサーバタイプ・アプリケーションとしてインプリメントされた、着信要求をプロキシ（２１２）にハンド・オフするＳＯＡＰ対応ＨＴＴＰサーバとすることができる。Ｊａｖａ（Ｒ）サーブレットおよびＣＧＩスクリプトは、制限ではなく例としてのみ言及されたものである。本発明の範囲内で、当業者が思い浮かべるすべての種類のサーバサイド機能性を使用して、ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ機能をインプリメントすることができる。
【００３６】
ポート・タイプ不可知プロキシ（２１２）を、排他的にポート・タイプ不可知プロキシとして動作するようにハード・コードすることができ、あるいはその代わりに、ポート・タイプ不可知プロキシ（２１２）が、構成パラメータ（２２３）に依存してモーダルに動作することができる。構成パラメータは、ポート・タイプ不可知プロキシ（２１２）が伝統的なインターメディアリ・サービスとしてまたはポート・タイプ不可知モードのどちらで動作しなければならないかを示すために提供することができる。そのような構成パラメータは、有利なことに、特に両方のモードで利用できるコード・セグメントの再利用を含む効率的なプログラム・コーディングを促進する。プログラム・コードの効率的使用をサポートするもう１つの構成パラメータが、プロキシのバインディングまたは「チャネル・タイプ」を識別するパラメータである。下で詳細に説明するように、ポート・タイプ不可知プロキシは、ウェブ・サービスがサポートするすべてのバインディングすなわち、ＳＯＡＰ、ＭＩＭＥ、ＧＥＴ／ＰＯＳＴ／ＨＴＴＰなどを用いて動作することができる。ポート・タイプ不可知プロキシを、任意のバインディングまたはチャネル・タイプを用いて動作するようにコーディングし、その後、ラン・タイム動作のバインディングまたはチャネル・タイプについてプロキシに助言するパラメータを用いて構成することができる。さらに、要求または応答メッセージの内容を解析することを必要とする、プロキシ内のインターメディアリ・サービスをオンまたはオフにするために、構成パラメータを設けることができる。そのようなパラメータは、メッセージ内容の解析がインターメディアリ性能を低下させる傾向があるので、性能を最適化するのに使用することができる。多くのポート・タイプ不可知プロキシならびに他のインターメディアリ・サービスが、インターメディアリ（２０２）内で同時に動作することができ、そのそれぞれの名前を、構成パラメータとして割り当てることができる。メッセージ・ハンドラおよびフィルタを、構成パラメータでプロキシに割り当てることができる。この段落では、制限ではなく説明として、ポート・タイプ不可知プロキシの複数の構成パラメータを説明している。当業者が思い浮かべるすべての構成パラメータの使用が、本発明の範囲に含まれる。
【００３７】
図４に、本発明の実施形態によるＳＯＡＰ−ＨＴＴＰチャネルをインプリメントする例示的なインターメディアリ（２０２）のブロック図の線画を示す。上で述べたように、ＳＯＡＰバインディングを用いる要求について、パラメータ・データを含む要求をポート・タイプ不可知プロキシ（２１２）に供給できるインバウンド・エンジン（２０８）を、ＳＯＡＰ対応ＨＴＴＰサーバとして実施することができる。そのようなインバウンド・エンジンを、プロキシに関するＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）への複数の参照を用いて構成することができ、ここで、各ＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）は、プロキシに関する要求に対するあるデータ処理タスクを提供するように構成される。そのようなインバウンド・エンジンは、通常、着信要求をパラメータ情報と共にＳＯＡＰＣｏｎｔｅｘｔオブジェクト（２０９）にカプセル化し、プロキシ用に構成されたＳＯＡＰＨａｎｄｌｅｒ（２１０）のそれぞれにＳＯＡＰＣｏｎｔｅｘｔオブジェクトへの参照を渡し、次に、ＳＯＡＰＣｏｎｔｅｘｔ（２０９）全体をプロキシ（２１２）に渡すことによって動作する。一般的な意味で、エンドポイントを識別するのは、ポート・タイプ不可知プロキシであるが、詳細なインプリメント・レベルに、ＳＯＡＰの場合のように、ハンドラ内のプロキシ機能を含めることができる。すなわち、インバウンド・エンジンが、ターゲット・サービスのエンドポイント（ＳＯＡＰ／ＨＴＴＰの場合にはＵＲＬ）をセットできるＳＯＡＰＣｏｎｔｅｘｔ内のプロパティを確立することができる。そのような実施形態で、ＳＯＡＰＨａｎｄｌｅｒオブジェクト（２１０）のうちの１つを有用にプログラムして、要求からパラメータ情報を抽出し、ＳＯＡＰＣｏｎｔｅｘｔ内の名前／値対に置くことができ、その結果、プロキシが、これを使用して、要求されたウェブ・サービス操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別できるようになる。
【００３８】
その代わりに、着信要求が、ＳＯＡＰではなくＧＥＴ／ＨＴＴＰにバインドされている場合がある。そのような例では、プロキシ（図３の２１２）を、Ｊａｖａ（Ｒ）サーブレットとしてインプリメントすることができる。インバウンド・エンジン（２０８）を、パラメータ情報を含む要求をＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔオブジェクトにカプセル化し、そのＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔオブジェクトへの参照をプロキシに供給するＪａｖａ（Ｒ）対応ＨＴＴＰサーバとしてインプリメントすることができる。このプロキシは、ＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔ．ｇｅｔＱｕｅｒｙＳｔｒｉｎｇ（）への呼出しを介してパラメータ情報を入手することができ、この呼出しは、要求ＵＲＬからのクエリ文字列すなわち、要求ＵＲＬ内の疑問符の後のすべてを返す。クエリ文字列全体を有するので、そのような例示的プロキシは、クエリ文字列からパラメータ・データすなわち、この例では「ｐｏｒｔＴｙｐｅ＝Ａ」を抽出し、そのように抽出された情報を使用して、要求されたウェブ・サービス操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別するようにプログラムされる。プロキシが、要求されたウェブ・サービス操作をサポートするターゲット・サービスのエンドポイントを識別できる１つの形が、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリ（２１１）からエンドポイント記述を取り出すことである。ターゲット・サービス（１１８）は、通常、例えばＷＳＤＬ文書として表された記述を含むそのような記述を、これらをビジネス・レジストリ（２１１）に登録（２２４）することによって作る。
【００３９】
ＳＯＡＰベースのウェブ・サービスでは、ＳＯＡＰメッセージ自体に、操作の名前およびその操作のパラメータが含まれるが、これらは、エンドポイントＵＲＬに含まれない。インターメディアリが、ｐｏｒｔＴｙｐｅパラメータなどのパラメータ情報を受け取ることが有用である。そのパラメータは、ｐｏｒｔＴｙｐｅの名前のように単純なものとすることができる。その場合に、サーバ内（例えばハンドラ内、またはプロキシ機能自体の中）で稼動するある「ビジネス・ロジック」が、ポート・タイプまたは他のパラメータ情報に基づいて、ターゲット・サービス（１１８）の実際のエンドポイントＵＲＬを選択しなければならない。パラメータ情報に、実際のエンドポイントＵＲＬを含めることもできる。その場合に、「ビジネス・ロジック」は、最終的にそのＵＲＬに要求を送信する。ポート・タイプとエンドポイントＵＲＬの両方を、パラメータ情報で表すことができ、その場合に、「ビジネス・ロジック」は、エンドポイントＵＲＬの判定を試み、要求内のエンドポイントＵＲＬよりよいものが見つからない場合に、要求内のエンドポイントＵＲＬを使用することができる。本発明は、この３つのシナリオのすべてならびにビジネス・ロジックによって制御することができるすべての変形を許容する。必ず、「ビジネス・ロジック」を制御するのを助ける他のパラメータがある可能性がある。
【００４０】
本明細書では、ＳＯＡＰ／ＨＴＴＰバインディングに関しておよび時々ＧＥＴ／ＰＯＳＴ／ＨＴＴＰバインディングに関して例示的バインディングを論じる傾向があるが、これらの例示的バインディングの議論は、説明の便宜のためであって制約としてではない。本発明の様々な実施形態に従って有用な代替の例示的なバインディングに、ＭＩＭＥ／ＳＭＴＰ（Multipart Internet Mail Extensions over the Small Message TransportProtocol）およびＲＭＩ／ＩＩＯＰ（Java's Remote Method Invocation over the Common ObjectRequest Broker Architecture's Internet Inter-ORB Protocol）が含まれる。実際に、任意のＪａｖａクラスを、ネイティブＪａｖａ呼出しをアクセス・プロトコルとして用いて、ウェブ・サービスとして扱うことができ、当業者が思い浮かべるすべての他のバインディングのポート・タイプ不可知プロキシでの使用が、好ましい実施形態による本発明の範囲に含まれる。
【００４１】
図３の例示的なインターメディアリ（２０２）では、プロキシ（２１２）はポート・タイプ不可知プロキシであり、リクエスタ認証、メッセージ妥当性検査、メッセージ・ログ記録、管理報告サービスなど、それが設計されたすべてのインターメディアリ・サービスを実行し、要求された操作をサポートするターゲット・サービス（１１８）のエンドポイントを識別し、その後、バインディング中立インターフェース（２１８）を介してターゲット・サービスに要求を送信する、ポート・タイプ不可知プロキシである。下で詳細に説明するように、バインディング中立インターフェース（２１８）は、その使用の形が要求バインディングに依存しないインターフェースである。
【００４２】
図３の例示的なインターメディアリ（２０２）では、インターフェース（２１８）が、プロバイダ（２２０）を動作させ、このプロバイダ（２２０）が、アウトバウンド・エンジン（２２２）を呼び出して、要求（１０６）をターゲット・サービス（１１８）に転送する。バインディング中立インターフェース（２１８）は、プロトコル固有のプロバイダ（２２０）内のコードによってバック・アップされるので、バインディング中立の形で動作することが可能である。プロバイダ（２２０）は、ＳＯＡＰ、ＨＴＴＰなど、特定のプロトコルの詳細に従って実際のメッセージ交換を実行する。実際のデータ通信を実行するプロバイダからバインディング中立インターフェースを切り離すことによって、新しいプロバイダの動的登録がサポートされ、その結果、インターメディアリが、再コンパイルまたは再展開を必要とせずにそのデータ通信能力を強化することができるようになる。プロバイダは、しばしばそのプロバイダのプロトコルによってサポートされるターゲット・サービスによって提供されるオブジェクトとしてインプリメントされ、プロバイダへの参照が、バインディング中立インターフェースに動的にインストールされる。アウトバウンド・エンジン（２２２）は、プロバイダ（２２０）によってインプリメントされるプロトコルのための実際のデータ通信エンジンである。プロトコルが、例えばＳＯＡＰ／ＨＴＴＰとして採用されるときに、アウトバウンド・エンジンは、ターゲット・ウェブ・サービスとの間でＳＯＡＰ／ＨＴＴＰの要求メッセージおよび応答メッセージを送信でき、受信できるＳＯＡＰ／ＨＴＴＰエンジンである。例えば、プロトコルがＨＴＴＰの場合に、アウトバウンド・エンジンは、ウェブ・ブラウザのデータ通信モジュールに似た、ＨＴＴＰデータ通信クライアント・モジュールである。
【００４３】
インターメディアリ・サービスを提供するために、インターメディアリは、有利なことに、要求のエンドポイントを識別することができる。それを行う方法を、図５に関して述べる。図５に、ウェブ・サービス操作の実行に関する要求（１０６）をウェブ・サービス・インターメディアリ内で受信すること（１０４）を含むウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図を示すが、ここで、この要求には、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が含まれる。
【００４４】
次も、ＳＯＡＰ−ＨＴＴＰバインディングのそのような要求の例である。
POST /Channel/proxy?portType=A HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOpxmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、メッセージが、ＳＯＡＰエンベロープとして解釈され、この操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が、ＨＴＴＰパラメータ「ｐｏｒｔＴｙｐｅ＝Ａ」である。この例では、ターゲット・サービスの操作の名前が、既にＳＯＡＰエンベロープにエンコードされているので、追加される唯一のパラメータ・データは、ポート・タイプ「Ａ」すなわち、ターゲット・サービスの操作を含むポート・タイプである。
【００４５】
図５の方法に、操作をサポートするターゲット・サービスのエンドポイント（１１０）を、パラメータ・データに依存して識別すること（１０８）も含まれる。このＳＯＡＰ−ＨＴＴＰの例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（１０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.com/SOAP-HTTP/servlets/のＳＯＡＰ−ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００４６】
図示の方法に、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）が含まれる。この例では、インターメディアリが、ターゲット・サービスのエンドポイントを使用して、ＨＴＴＰ ＰＯＳＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。エンドポイントを識別するパラメータ・データが、削除され、要求が、ＳＯＡＰメッセージを処理するスクリプトに向けられ、このスクリプト自体が、ＳＯＡＰエンベロープ内の操作名から操作を識別する。
【００４７】
結果のターゲット・サービス要求は、次のようになる。
POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1
Host: www.myTarget.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【００４８】
図５の方法に、ターゲット・サービス要求（１１４）をターゲット・サービス（１１８）に発行すること（１１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、そのＴＣＰ／ＩＰ接続を介してＨＴＴＰ ＰＯＳＴメッセージをターゲット・サービスに送信することが含まれる。
【００４９】
本発明の少なくともいくつかの実施形態で、図５に示されたものなどのポート・タイプ不可知プロキシ・サポートの方法で、作成され、ターゲット・サービスに発行されるターゲット・サービス要求が、ウェブ・サービス・インターメディアリで受信された要求の検査されず変更されないメッセージ内容を有することに留意することが有用である。上で説明した例では、インターメディアリのプロキシ・サービスが、メッセージ本体すなわちＳＯＡＰエンベロープにまったく手を付けず、オープンせず、検査せず、解析せず、どの形でも変更せずに、パラメータ・データ「ｐｏｒｔＴｙｐｅ＝Ａ」からターゲット・サービスのエンドポイントを識別し、そのように識別されたエンドポイントにメッセージをリダイレクトし、このＳＯＡＰエンベロープが、そのリクエスタからターゲット・サービスまでの配送の過程全体を通じて検査されず、変更されないままになる。この過程で、プロキシ・サービスは、インターメディアリ・サービス、認証、管理報告、負荷平衡化、サービス集約などのうちの１つまたは複数を提供した。
【００５０】
さらなる説明として、例示的な要求が、ＧＥＴ／ＨＴＴＰバインディングについて提示され、http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxyにあるエンドポイントに向けられる。例示的な着信要求メッセージは、次の形を有する。
GET/servlets/proxy?message=messageContentString&
operation=myOp&portType=A HTTP/1.1
また、ＵＲＩ空間では、例示的な要求を次のように示すことができる。
http://www.myIntermediary.com/servlets/
proxy?message=messageContentString&operation=myOp&portType=A
この例では、メッセージが、名前／値対としてエンコードされたＵＲＩエンコードされたクエリ・データ「ｍｅｓｓａｇｅ＝ｍｅｓｓａｇｅＣｏｎｔｅｎｔＳｔｒｉｎｇ」としてとられる。メッセージ内容は、ＵＲＩエンコードされた文字列である。この例では、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）のすべてが、メッセージ内容文字列に続くクエリ・データである。この例では、クエリ・データに、「Ａ」というポート・タイプとターゲット・サービスの操作の名前の両方が含まれる。
【００５１】
この例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（１０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.comのＧＥＴ／ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００５２】
図５の方法には、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）も含まれる。この例では、インターメディアリが、ターゲット・サービス要求のエンドポイント・アドレスに操作名およびメッセージ・パーツを連結することによって、ＨＴＴＰ ＧＥＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。ＵＲＩ空間で表現された、結果のターゲット・サービス要求は、次のようになる。
http://www.myTarget.com/servlets/myOp?message=messageContentString
【００５３】
図５の方法には、ターゲット・サービス（１１８）にターゲット・サービス要求（１１４）を発行すること（１１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、ＨＴＴＰ ＧＥＴメッセージを送信することが含まれる。
GET/servlets/myOp?message=messageContentString HTTP/1.1
【００５４】
当技術分野における技量を有する読者は、リクエスタがターゲット・サービスの操作に関する要求をどのようにしてインターメディアリに送信するかを不思議に思っている。答は、インターメディアリまたはインターメディアリの開発者が、リクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別することである。ターゲット・サービスの操作をサポートするエンドポイントとしてのインターメディアリのエンドポイントの識別は、リクエスタによるディスカバリのためにビジネス・ディレクトリに登録されるＷＳＤＬ文書でインプリメントすることができる。その代わりに、そのような識別を、インターメディアリからリクエスタにダウンロードすることができ、あるいは、リクエスタのウェブ・サービス構成データへの管理者によるインストールのために、単純にリクエスタまたはリクエスタの管理者に電子メールで送ることさえできる。
【００５５】
ターゲット・サービスがＷＳＤＬ擬似コードの次のセグメントによって記述される例を検討されたい。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location=
"http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
【００５６】
そのターゲット・サービスのインターメディアリは、次のようにターゲット・サービス記述のアドレス拡張要素の位置属性を置換することによって、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントをリクエスタに対して識別することができる。
<soap:addresslocation="http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
これによって、次のセグメントによって例示されるＷＳＤＬ文書が作成される。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="portTypeAgnosticProxy">
<portname="intermediaryEndpoint" binding="SOAPBinding">
<soap:address location=
"http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
</port>
</service>
</definitions>,
これは、ターゲット・サービスでの「ｇｅｔＱｕｏｔｅ」操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別する。レジストリ、ダウンロード、電子メールを介して、または当業者が思い浮かべる他の手段によって、この後者のセグメントによって例示される種類のＷＳＤＬをリクエスタに提供することによって、そのリクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントが識別される。
【００５７】
図５の方法では、パラメータ情報（１０７）に応じて、操作をサポートするターゲット・サービスのエンドポイントを識別すること（１０８）に、しばしば、ターゲット・サービスの１つのエンドポイントだけではなく、その操作をサポートするターゲット・サービスの複数のエンドポイントを識別することを含めることができる。本発明方法の実施形態によるポート・タイプ不可知プロキシが、操作のポート・タイプをパラメータ情報（１０７）として受信し、クエリ・パラメータとしてポート・タイプを用いてビジネス・レジストリに照会し、これによって操作をサポートするターゲット・サービスの複数のエンドポイントを識別する例を検討されたい。複数のエンドポイントのそのような識別は、例えば、ポート・タイプを用いてＵＤＤＩレジストリに照会し、それに応答して、そのポート・タイプに関するターゲット・サービスを記述した複数のＷＳＤＬ文書を受信することによって実行することができる。
【００５８】
複数のエンドポイントがそのように識別される場合に、本発明の実施形態によるウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に、通常、選択ルールに従ってエンドポイントのうちの１つを選択することが含まれる。自明な例では、選択ルールを、そのように識別された複数のエンドポイントの最初のエンドポイントを選択し、他のエンドポイントを破棄することとすることができる。選択ルールは、例えば、負荷平衡化に関する選択ルールを含む、より複雑なルールとすることができる。負荷平衡化に関するルールは、表１に示されたものに類似したデータ構造の使用によってインプリメントすることができる。
【００５９】
【表１】
【００６０】
表１の各行は、インターメディアリとターゲット・サービスの間のウェブ・サービス・データ通信の要求−応答ラウンド・トリップに関する待ち時間（latency）測定値を表す。表１には、要求および応答のラウンドごとに、ポート・タイプおよびエンドポイントＵＲＩの列が設けられている。送信時刻列は、要求メッセージが、インターメディアリからポート・タイプの操作に関するターゲット・サービスのエンドポイントに発行されたときの時刻を記録したものである。受信時刻列は、対応する応答メッセージがターゲット・サービスから受信されたときの時刻を記録したものである。トリップ待ち時間は、受信時刻と送信時刻の差である。累積待ち時間は、この表に表されたエンドポイントごとのトリップ待ち時間の現在合計（runningsum）である。表１に似た構造を用いて、要求に関する複数のエンドポイントが識別されたときに使用される選択ルールを、次の例示的なルールとしてインプリメントすることができる。
同一ポート・タイプの操作に関する複数の要求がインターメディアリに達したときには、複数の識別されたエンドポイントのそれぞれを順番に１回使用する。
そのような使用のそれぞれの待ち時間データを記録する。
同一ポート・タイプの操作に関する後続要求について、最短の累積待ち時間を有するエンドポイントを待ち時間テーブルから選択し、要求をそのエンドポイントに送信し、メッセージがターゲット・サービスに送信されるときおよび対応する応答がインターメディアリで受信されるときに、関連する待ち時間データを記録する。
【００６１】
表１の例示的データには、ポート・タイプＡについて２つのエンドポイントすなわち、URIhttp://www.ibm.com/aTargetServiceにある第１エンドポイントおよびURIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントに最近送信された要求の累積待ち時間が示されている。第１エンドポイントは、２５０ミリ秒の累積要求待ち時間を有し、第２エンドポイントは、１００ミリ秒の累積待ち時間を有する。上で示した例示的な選択ルールを使用すると、ポート・タイプＡに関する操作の現在の要求は、URIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントにルーティングされる。
【００６２】
図５の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（１１２）を、バインディング中立インターフェース内で有用なデータ構造内に要求を構成し、その要求を呼出しパラメータとして渡してバインディング中立インターフェースを呼び出すことによって実行することができる。同様に、ターゲット・サービスにターゲット・サービス要求（１１４）を発行すること（１１６）に、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことが含まれる。
【００６３】
バインディング中立インターフェースは、そのインターフェースの使用が要求またはメッセージのバインディングに依存しないインターフェースである。すなわち、このインターフェースをインプリメントし、それを介するデータ通信を実行するのに使用されるデータ構造および呼出し方法は、メッセージに使用されるデータ・エンコーディングのタイプに依存せず、メッセージに使用されるデータ通信プロトコルに依存しない。本発明の実施形態によるインターメディアリ用のポート・タイプ不可知プロキシの開発者は、しばしば、彼ら自身のバインディング中立インターフェースを作成する。しかし、「ＷＳＩＦ」すなわちWeb Service Invocation Frameworkと称する、バインディング中立インターフェースのオープン標準規格がある。ＷＳＩＦは、現在、ApacheSoftware FoundationのWeb Services Projectの一部としてサポートされている。
【００６４】
バインディング中立インターフェースの使用は、本発明の実施形態に利益をもたらす。ＳＯＡＰ−ＨＴＴＰバインディングは、現在の技術で非常に一般的なので、ユーザおよび開発者は、時々、他のバインディングが存在することを忘れる。これは、他のバインディングと共に使用されるか他のバインディングと共に使用するために適合させることが、不可能でないとしても非常にむずかしいシステムの開発をもたらす。しかし、ウェブ・サービスが成長するにつれて、他のバインディングが、より有用でより一般的になる。さらに、本発明の実施形態のバック・エンドにバインディング中立インターフェースを使用することは、使用可能なバインディングをラン・タイムに決定でき、これによって、柔軟で強力でより一般的に有用なウェブ・サービス・インターメディアリが提供されることを意味する。
【００６５】
バインディング中立インターフェースをインプリメントする形の１つが、ポート・タイプおよびエンドポイントを与えられてターゲット・サービス内のサービスを呼び出すことができるエンドポイント・オブジェクトを提供することである。そのようなエンドポイント・オブジェクトを提供する形の１つが、次の擬似コード・セグメントに例示されたものに似たエンドポイント・ファクトリを使用することによるものである。
// エンドポイント・ファクトリ・クラス
// エンドポイント・オブジェクトを作成するパラメータ化されたファクトリ・メソッドを定義する
//
class EndpointFactory
{
public static EndpointcreateEndpointObject(portType, networkAddress)
{
// 新しいエンドポイント・オブジェクトの参照を確立する
Endpoint anEndpoint = null;
if(portType == "A" &&networkAddress == "www.abc.com")
anEndpoint = new Endpoint1;
if(portType == "B" &&networkAddress == "www.def.com")
anEndpoint = new Endpoint2;
if(portType == "C" &&networkAddress == "www.ghi.com")
anEndpoint = new Endpoint3;
...
if(portType == "LAST" &&networkAddress == "www.lastSupported.com")
anEndpoint = new Endpoint465;
if anEndpoint == null) reportError();
else return anEndpoint;
}// createEndpointObject()の終り
}// クラスEndpointFactoryの終り
【００６６】
エンドポイント・クラスＥｎｄｐｏｉｎｔ１、Ｅｎｄｐｏｉｎｔ２、Ｅｎｄｐｏｉｎｔ３などは、メッセージ・パーツを含むメッセージ・オブジェクトを作成するメンバ・メソッドを提供する抽象エンドポイント・クラスを継承する（または、インターフェースとしてインプリメントする）具象クラスである。そのようなエンドポイント・ファクトリおよびそのようなバインディング中立インターフェースの他の要素を使用して、次の擬似コード・セグメントに示されているように、ターゲット・サービス要求（１１４）を作成するステップ（１１２）およびターゲット・サービスにターゲット・サービス要求（１１４）を発行するステップ（１１６）を実行することができる。
// エンドポイント・ファクトリからエンドポイント・オブジェクトを得る
Endpoint ep =endPointFactory.createEndPoint(portType, networkAddress);
// 入力メッセージを用意する
Message input = ep.createInputMessage();
// メッセージ・アクセス関数を使用してメッセージの内容を挿入する
input.setPart("symbol","IBM");
// 応答値のプレースホルダを用意する
Message output = ep.createOutputMessage();
// 操作を実行する
ep.executeRequestResponseOperation("getQuote",
input, output);
// 結果を返す
return output;
【００６７】
この例示的な擬似コード・セグメントは、エンドポイントのポート・タイプおよびネットワーク・アドレスを与えられて、エンドポイント・ファクトリを呼び出してエンドポイント・オブジェクトを作成する。次に、このセグメントは、メッセージ・パーツをエンドポイント・オブジェクトにロードすることによってターゲット・サービス要求を作成し、メンバ・メソッドｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）を呼び出すことによってターゲット・サービスにターゲット・サービス要求を発行する。図５の方法に、ターゲット・サービスからの応答（１２２）をインターメディアリ内で受信すること（１２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（１２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（１２８）が含まれる。この例示的な擬似コード・セグメントでは、ターゲット・サービスからの応答（１２２）を受信するステップ（１２０）およびインターメディアリからの応答（１２６）を作成するステップ（１２４）が、通常はターゲット・サービスからの応答を待って「ｏｕｔｐｕｔ」へのメッセージ参照を介してその応答を使用可能にするブロッキング呼出しであるｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）への呼出しによってインプリメントされる。
【００６８】
上の例の擬似コード・セグメントは、エンドポイントとして参照されるポートを有するバインディング中立インターフェースの使用を例示するものである。しかし、ＷＳＩＦインターフェース構文は、エンドポイントを参照するときに用語「ポート」を使用する。したがって、バインディング中立インターフェースの使用に関するさらなる説明として、ＷＳＩＦ標準規格をより厳守するさらなる例示的擬似コード・セグメントを示す。この例では、「ポート」が、「エンドポイント」を意味するのに使用され、説明の一貫性を保つために、ファクトリの名前が、「ｐｏｒｔＦａｃｔｏｒｙ」に変更されている。
// ファクトリからポート（エンドポイント）を得る
WSIFPort port =portFactory.getPort(portType, networkAddress);
// 入力メッセージを用意する
WSIFMessage input =port.createInputMessage();
// メッセージ内容を挿入する
input.setPart("symbol",
new WSIFＪａｖａ（Ｒ）Part(String.class, symbol));
// 応答値のプレースホルダを用意する
WSIFMessage output =port.createOutputMessage();
// 操作を実行する
port.executeRequestResponseOperation("getQuote",
input, output, null);
// 結果を抽出し、返す
return output;
【００６９】
本明細書では、主にリクエスタからターゲット・サービスへの過程での要求の処理に関して、ウェブ・サービス・インターメディアリでのポート・タイプ不可知プロキシ・サポートの例示的方法を論ずるが、本発明の実施形態によるインターメディアリが、通常、ターゲット・サービスからインターメディアリを介して最初のリクエスタに戻る応答メッセージを処理することもできることに留意することが有用である。例えば、図５の方法に、インターメディアリ内でターゲット・サービスから応答（１２２）を受信すること（１２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（１２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（１２８）が含まれる。
【００７０】
図６に、ウェブ・サービス操作の実行に関する要求（１０６）をウェブ・サービス・インターメディアリ内で受信すること（３０４）を含む、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図を示すが、ここで、この要求に、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が含まれる。
【００７１】
次も、ＳＯＡＰ−ＨＴＴＰバインディングのそのような要求の例である。
POST/Channel/proxy?portType=A&synchRespReqd=True HTTP/1.1
Host: www.myIntermediary.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この例示的なＰＯＳＴメッセージに、インターメディアリに「ｍｙＯｐ」操作を要求するＳＯＡＰエンベロープが含まれる。ｍｙＯｐ操作、そのポート・タイプ、およびそのエンドポイントのすべてが、この要求を受信する前にはインターメディアリに未知である。この例では、メッセージが、ＳＯＡＰエンベロープとしてとられ、この操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）が、ＨＴＴＰパラメータ「ｐｏｒｔＴｙｐｅ＝Ａ」である。この例では、ターゲット・サービスの操作の名前が、既にＳＯＡＰエンベロープにエンコードされているので、追加される唯一のパラメータ・データは、ポート・タイプ「Ａ」すなわち、ターゲット・サービスの操作を含むポート・タイプである。
【００７２】
図６の方法に、操作をサポートするターゲット・サービスのエンドポイント（１１０）を、パラメータ・データに依存して識別すること（３０８）も含まれる。このＳＯＡＰ−ＨＴＴＰの例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別すること（３０８）は、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.com/SOAP-HTTP/servlets/のＳＯＡＰ−ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００７３】
図６に示された方法に、要求（１０６）が同期応答を要求するかどうかを判定すること（３５０）も含まれる。要求（１０６）が同期応答を要求するかどうかを判定すること（３５０）は、受信された要求メッセージの最初の行のクエリ・データを検査することによって実行することができる。上に示した例示的なＰＯＳＴメッセージでは、最初の行のクエリ・データが、「？」とＨＴＴＰバージョン・コードの間のすべてのデータすなわち、
portType=A&synchRespReqd=True
である。この例では、「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」が、インターメディアリによって、同期応答が必要であることを意味すると解釈される。同様に、「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｆａｌｓｅ」は、同期応答が不要であることを示すことができる。これらは、例示的なコーディングにすぎず、もちろん、本発明の制限ではない。同期応答がインターメディアリに要求されるかどうかの表示をパラメータ情報内にエンコードするすべての手段が、好ましい実施形態による本発明の範囲に含まれる。この例では、要求が同期応答を要求するかどうかを判定すること（３５０）は、パラメータ情報（１０７）に応じてその判定を行うことによって実行され、このパラメータ情報は、名前／値対「ｓｙｎｃｈＲｅｓｐＲｅｑｄ＝Ｔｒｕｅ」である。
【００７４】
図示の方法に、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）が含まれる。この例では、インターメディアリが、ターゲット・サービスのエンドポイントを使用して、ＨＴＴＰ ＰＯＳＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。具体的に言うと、次のＰＯＳＴメッセージは、要求されたウェブ・サービス操作に関する入力メッセージまたは入力データの例を表す。パラメータ・データが、削除され、エンドポイントを識別するパラメータ・データならびに同期応答が必要であるかどうかを判定するパラメータ・データおよび要求が、ＳＯＡＰメッセージを処理するスクリプト、サーブレット、または他の機能性に向けられ、このスクリプト自体が、ＳＯＡＰエンベロープ内の操作名から操作を識別する。
【００７５】
結果のターゲット・サービス要求は、次のようになる。
POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1
Host: www.myTarget.com
Content-Type: text/xml;charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOpxmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【００７６】
図６の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）に、さらに、要求が同期要求を必要とするかどうかの判定（１５２）に応じてターゲット・サービス要求（１１４）を作成すること（３１２）を含めることができる。インターメディアリが、要求されるウェブ・サービス操作に関する入力データを有する入力メッセージを作成できるのと同様に、インターメディアリが、出力メッセージを作成することもできる。そのような出力メッセージは、通常、ターゲット・サービスからの応答メッセージを保管し、通信するのに使用されるプレースホールディング・オブジェクトである。同期応答を必要とする要求のために応答メッセージ・オブジェクトを作成する例示的な方法は、インターメディアリが、正しいクラスのオブジェクトを作成し、それを空のままにし、ターゲット・サービスに要求を通信する下流インターフェース（図３および４の符号（２２０）および（２２２）のプロバイダまたはアウトバウンド・エンジンなど）への１つまたは複数の呼出しのパラメータとして、そのオブジェクトへの参照を渡すことである。同期応答を必要としない要求のために応答メッセージ・オブジェクトを作成する例示的な方法は、インターメディアリが、ターゲット・サービスに要求を通信する下流インターフェースへの１つまたは複数の呼出しのパラメータとして、ヌル参照（単に空の出力オブジェクトへの参照ではなく、完全にヌルの参照）を渡すことである。そのような実施形態では、下流インターフェースが、そのようなヌル参照を、呼出し側に制御を返す前に「肯定応答」だけを待つことの表示として解釈するようにプログラムされる。
【００７７】
図６の方法に、ターゲット・サービス要求（１１４）をターゲット・サービス（１１８）に発行すること（３１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、そのＴＣＰ／ＩＰ接続を介してＨＴＴＰ ＰＯＳＴメッセージをターゲット・サービスに送信することが含まれる。
【００７８】
本発明の少なくともいくつかの実施形態で、図６に示されたものなどのポート・タイプ不可知プロキシ・サポートの方法で、作成され、ターゲット・サービスに発行されるターゲット・サービス要求が、ウェブ・サービス・インターメディアリで受信された要求の検査されず変更されないメッセージ内容を有することに留意することが有用である。上で説明した例では、インターメディアリのプロキシ・サービスが、メッセージ本体すなわちＳＯＡＰエンベロープにまったく手を付けず、オープンせず、検査せず、解析せず、どの形でも変更せずに、パラメータ・データ「ｐｏｒｔＴｙｐｅ＝Ａ」からターゲット・サービスのエンドポイントを識別し、そのように識別されたエンドポイントにメッセージをリダイレクトし、このＳＯＡＰエンベロープが、そのリクエスタからターゲット・サービスまでの配送の過程全体を通じて検査されず、変更されないままになる。この過程で、プロキシ・サービスは、インターメディアリ・サービス、認証、管理報告、負荷平衡化、サービス集約などのうちの１つまたは複数を提供した。
【００７９】
さらなる説明として、例示的な要求が、ＧＥＴ／ＨＴＴＰバインディングについて提示され、http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxyにあるエンドポイントに向けられる。例示的な着信要求メッセージは、次の形を有する。
GET/servlets/proxy?message=messageContentString&
operation=myOp&portType=A HTTP/1.1
また、ＵＲＩ空間では、例示的な要求を次のように示すことができる。
http://www.myIntermediary.com/servlets/
proxy?message=messageContentString&operation=myOp&portType=A
この例では、メッセージが、名前／値対としてエンコードされたＵＲＩエンコードされたクエリ・データ「ｍｅｓｓａｇｅ＝ｍｅｓｓａｇｅＣｏｎｔｅｎｔＳｔｒｉｎｇ」としてとられる。メッセージ内容は、ＵＲＩエンコードされた文字列である。この例では、操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報（１０７）のすべてが、メッセージ内容文字列に続くクエリ・データである。この例では、クエリ・データに、「Ａ」というポート・タイプとターゲット・サービスの操作の名前の両方が含まれる。
【００８０】
この例では、操作をサポートするターゲット・サービスのエンドポイント（１１０）を識別することは、ＵＤＤＩレジストリまたはｅｂＸＭＬレジストリなどのビジネス・レジストリからエンドポイント記述を取り出すことによって実行される。この例では、インターメディアリが、ネットワーク・アドレスhttp://www.myTarget.comのＧＥＴ／ＨＴＴＰによってバインドされたものとして記述されたポート・タイプＡのエンドポイントをレジストリから取り出す。
【００８１】
図６の方法には、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）も含まれる。この例では、インターメディアリが、ターゲット・サービス要求のエンドポイント・アドレスに操作名およびメッセージ・パーツを連結することによって、ＨＴＴＰ ＧＥＴメッセージとしてターゲット・サービス要求を作成するようにプログラムされる。ＵＲＩ空間で表現された、結果のターゲット・サービス要求は、次のようになる。
http://www.myTarget.com/servlets/myOp?message=messageContentString
【００８２】
前に述べたように、図６の方法には、ターゲット・サービス（１１８）にターゲット・サービス要求（１１４）を発行すること（３１６）も含まれる。この例では、ターゲット・サービス要求の発行に、http://www.myTarget.com/にあるターゲット・サービス・エンドポイントへのＴＣＰ／ＩＰ接続をオープンすることと、次のＨＴＴＰ ＧＥＴメッセージを送信することが含まれる。
GET/servlets/myOp?message=messageContentString HTTP/1.1
【００８３】
図６の方法に、要求が同期応答を必要とする場合（３６０）にターゲット・サービスからの応答を待つこと（３６１）も含まれる。図７に、ターゲット・サービスからの応答を待つ方法を示す流れ図を示すが、この方法には、インターメディアリで、ターゲット・サービスからの応答（１２２）を同期式に受信すること（３２０）と、ターゲット・サービスからの応答に応じて、インターメディアリ内で、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）をリクエスタ（１０２）に返すこと（３２８）が含まれる。図７の方法では、インターメディアリでターゲット・サービスからの応答を同期式に受信すること（３２０）を、インターメディアリとターゲット・サービスの間のデータ通信接続に対するブロッキング受信関数を呼び出すことによって実行することができる。
【００８４】
次の擬似コードのセグメントは、インターメディアリからターゲット・サービスに要求を送信し、要求が同期応答を必要とする場合にターゲット・サービスからの応答を待つ、ＨＴＴＰバインディングに関する例である。次のセグメントは、しばしば、本発明の実施形態に従って、ウェブ・サービス・インターメディアリのプロバイダを介してまたはアウトバウンド・エンジン内で（図３および４の２２０および２２２）提供されるものなどの、ＨＴＴＰバインディングに関するクライアント動作を例示するものである。
import java（Ｒ）.io.*;
import java（Ｒ）.net.*;
BufferedReader in = null;
URL url = new URL(targetURL);
URLConnection connection =(HttpURLConnection) url.openConnection();
BufferedWriter out = new BufferedWriter(new OutputStreamWriter (connection.getOutputStream()));
BufferedReader in = new BufferedReader(new InputStreamReader (
connection.getInputStream()));
out.println(request);
if(synchRespReqd == TRUE)
{
Message responseMessage = in.readLine();
return responseMessage;
}
この例示的擬似コード・セグメントは、Ｊａｖａ ＵＲＬオブジェクトを作成し、そのＵＲＬオブジェクトを使用して、ネットワーク・アドレス「ｔａｒｇｅｔＵＲＬ」を有するものとして識別されたターゲット・サービスへの、「ｃｏｎｎｅｃｔｉｏｎ」という名前のＴＣＰ／ＩＰ接続をオープンする。このセグメントは、その接続上の「ｏｕｔ」という名前のバッファリングされたストリームおよびその接続上の「ｉｎ」という名前の入力ストリームもオープンする。このセグメントは、「ｏｕｔ．ｐｒｉｎｔｌｎ（ｒｅｑｕｅｓｔ）」としてその接続を介して要求を送信し、その後、同期応答が必要な場合に、ブロッキング呼出しを行って、同一の接続を介して応答メッセージを受信し「Ｍｅｓｓａｇｅ ｒｅｓｐｏｎｓｅＭｅｓｓａｇｅ＝ｉｎ．ｒｅａｄＬｉｎｅ（）」、応答メッセージを呼出し側に返す。この例は、ＨＴＴＰバインディングに関する。
【００８５】
さらに説明するために、下で、「ＪＭＳ」バインディングすなわち、Ｊａｖａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅへのバインディングに関するもう１つの例を提示する。ＪＭＳは、ポイントツーポイント・メッセージング用およびパブリッシュ／サブスクライブ・メッセージング用の２つのメッセージ「ドメイン」を提供する。この例では、インターメディアリとターゲット・サービスの間の、ＪＭＳメッセージ・キューを使用するポイントツーポイント・メッセージングを論ずる。ＪＭＳポイントツーポイント・メッセージングでは、ソケットなどのデータ通信接続が、ＪＭＳの「ｃｏｎｎｅｃｔｉｏｎ」オブジェクトによってカプセル化される。ＪＭＳ ｃｏｎｎｅｃｔｉｏｎは、「ｃｏｎｎｅｃｔｉｏｎ ｆａｃｔｏｒｙ」と呼ばれる管理オブジェクトを介して作成される。ＪＭＳ ｃｏｎｎｅｃｔｉｏｎは、１つまたは複数のＪＭＳ「ｓｅｓｓｉｏｎ」を作成するのに使用される。ｓｅｓｓｉｏｎは、メッセージを作成し、消費する、シングルスレッドのコンテキストである。ｓｅｓｓｉｏｎは、メッセージ・プロデューサ、メッセージ・コンシューマ、およびメッセージを作成するのに使用される。メッセージ・プロデューサは、メッセージをキューに送るのに使用されるオブジェクトである。ポイントツーポイントの形のメッセージ・プロデューサが、ＪＭＳの「ｑｕｅｕｅＳｅｎｄｅｒ」インターフェースをインプリメントし、このインターフェースに、ｓｅｎｄ（）メソッドが含まれる。メッセージ・コンシューマは、キューからメッセージを受け取るのに使用されるオブジェクトである。ポイントツーポイントの形のメッセージ・コンシューマが、ＪＭＳの「ｑｕｅｕｅＲｅｃｅｉｖｅｒ」インターフェースをインプリメントし、このインターフェースに、タイムアウト期間ありまたはタイムアウト期間なしで呼び出すことができるブロッキングｒｅｃｅｉｖｅ（）メソッドが含まれる。
【００８６】
次の擬似コードのセグメントは、インターメディアリからターゲット・サービスに要求を送信し、要求が同期応答を必要とする場合にターゲット・サービスからの応答を待つ、ＪＭＳバインディングに関する例である。
// connectionを得る
QueueConnection queueConnection =
queueConnectionFactory.createQueueConnection();
// connectionを使用してsessionを確立する
// 「false」パラメータは、トランザクションなしを意味し、
// AUTO_ACKはオンである。
QueueSession queueSession =
queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
// センダを作成し、インターメディアリからの要求を
// JMSキューを介してターゲット・サービスに送信する。
QueueSender queueSender =queueSession.createSender(myQueue);
queueSender.send(requestMessage);
// 同期応答が必要な場合には、レシーバを作成し、
// レシーバに対するブロッキングreceive()を発行する。
if(synchRespReqd == TRUE)
{
QueueReceiver queueReceiver =queueSession.createReceiver(myQueue);
Message responseMessage =queueReceiver.receive();
return responseMessage;
}
この例示的なＪＭＳセグメントは、ｑｕｅｕｅＣｏｎｎｅｃｔｉｏｎという名前のｃｏｎｎｅｃｔｉｏｎを作成し、ｑｕｅｕｅＳｅｓｓｉｏｎという名前のｓｅｓｓｉｏｎを作成し、ｑｕｅｕｅＳｅｎｄｅｒという名前のセンダを作成し、ＪＭＳキューを介してターゲット・サービスに要求メッセージを送信し、同期要求が必要な場合には、ｑｕｅｕｅＲｅｃｅｉｖｅｒという名前のレシーバを作成し、応答メッセージを待つためにｑｕｅｕｅＲｅｃｅｉｖｅｒに対するブロッキングｒｅｃｅｉｖｅ（）を発行する。
【００８７】
要求が同期応答を必要としない場合（３６２）に、本発明の実施形態によるウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法に、ターゲット・サービスに要求を発行すること以外に絶対に何もしないことを含めることができる。すなわち、要求が同期応答を必要としない場合（３６２）に、肯定応答、非同期応答、および類似物に関してまったく何もしないことが、好ましい実施形態による本発明の範囲に含まれる。その代わりに、図６に示されているように、本発明の第２実施形態による方法に、ターゲット・サービス要求の肯定応答（１５６）をターゲット・サービスから受信すること（３５４）、および応答メッセージを待たずにリクエスタ（１０２）に肯定応答（１５６）を返すこと（３５８）を含めることができる。
【００８８】
次は、応答メッセージを待たずにリクエスタに肯定応答を返す例示的な擬似コード・セグメントである。
import java（Ｒ）.io.*;
import java（Ｒ）.net.*;
URL url = new URL(targetURL);
HTTPURLConnection connection =(HttpURLConnection) url.openConnection();
BufferedWriter out = new BufferedWriter(new OutputStreamWriter (connection.getOutputStream()));
BufferedReader in = new BufferedReader (
new InputStreamReader (connection.getInputStream()));
out.println(request);
int acknowledgment =connection.getResponseCode();
if(acknowledgment == 200) returnacknowledgement;
else return ERROR;
この例示的擬似コード・セグメントは、Ｊａｖａ ＵＲＬオブジェクトを作成し、そのＵＲＬオブジェクトについて、ＨＴＴＰＵＲＬＣｏｎｎｅｃｔｉｏｎオブジェクトの形で、ネットワーク・アドレス「ｔａｒｇｅｔＵＲＬ」を有するものとして識別されたターゲット・サービスへの、「ｃｏｎｎｅｃｔｉｏｎ」という名前のＴＣＰ／ＩＰ接続をオープンする。このセグメントは、その接続上の「ｏｕｔ」という名前のバッファリングされた出力ストリームおよびそのソケット上の「ｉｎ」という名前の入力ストリームもオープンする。このセグメントは、「ｏｕｔ．ｐｒｉｎｔｌｎ（ｒｅｑｕｅｓｔ）」としてその接続を介して要求を送信し、その後、ブロッキング呼出しを行って、同一の接続を介して肯定応答を受信する「ｉｎｔ ａｃｋｎｏｗｌｅｄｇｍｅｎｔ＝ｃｏｎｎｅｃｔｉｏｎ．ｇｅｔＲｅｓｐｏｎｓｅＣｏｄｅ（）」。このセグメントは、呼出し側に肯定応答（この例では、ＨＴＴＰ応答コード「２００」）を返すか、エラー・メッセージを返す。肯定応答は、要求が受信されたことの、ターゲット・サービスからの手続的肯定応答である。このセグメントは、要求に対する本質的な応答を待たない。
【００８９】
上の例示的擬似コード・セグメントは、インターメディアリからターゲット・サービスに要求を送信し、本質的な応答メッセージを待たずに肯定応答を供給する例である。このセグメントは、しばしば、本発明の実施形態に従って、ウェブ・サービス・インターメディアリのプロバイダを介してまたはアウトバウンド・エンジン内で（図３および４の２２０および２２２）提供されるものなどの、ＨＴＴＰバインディングに関するクライアント動作を例示するものである。
【００９０】
当技術分野における技量を有する読者は、ここまでに、リクエスタがターゲット・サービスの操作に関する要求をどのようにしてインターメディアリに送信するかを不思議に思っている。答は、インターメディアリまたはインターメディアリの開発者が、リクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別することである。ターゲット・サービスの操作をサポートするエンドポイントとしてインターメディアリのエンドポイントを識別することは、リクエスタによるディスカバリのためにビジネス・ディレクトリに登録されるＷＳＤＬ文書でインプリメントすることができる。その代わりに、そのような識別を、インターメディアリからリクエスタにダウンロードすることができ、あるいは、リクエスタのウェブ・サービス構成データへの管理者によるインストールのために、単純にリクエスタまたはリクエスタの管理者に電子メールで送ることさえできる。
【００９１】
ターゲット・サービスがＷＳＤＬ擬似コードの次のセグメントによって記述される例を検討されたい。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location=
"http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
【００９２】
そのターゲット・サービスのインターメディアリは、次のようにターゲット・サービス記述のアドレス拡張要素の位置属性を置換することによって、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントをリクエスタに対して識別することができる。
<soap:addresslocation="http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
これによって、次のセグメントによって例示されるＷＳＤＬ文書が作成される。
<definitions targetNamespace= ... >
<messagename="GetQuoteInput"> ... </message>
<messagename="GetQuoteOutput"> ... </message>
<portTypename="StockquotePT"> ... </portType>
<binding name="SOAPBinding"... >
<operationname="getQuote"> ... </operation> ...
</binding>
<servicename="portTypeAgnosticProxy">
<portname="intermediaryEndpoint" binding="SOAPBinding">
<soap:address location=
"http://www.myIntermediary.com/
Channel/SOAP/proxy?portType=StockquotePT"/>
</port>
</service>
</definitions>,
これは、ターゲット・サービスでの「ｇｅｔＱｕｏｔｅ」操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントを識別する。レジストリ、ダウンロード、電子メールを介して、または当業者が思い浮かべる他の手段によって、この後者のセグメントによって例示される種類のＷＳＤＬをリクエスタに提供することによって、そのリクエスタに対して、ターゲット・サービスの操作をサポートするエンドポイントとしてウェブ・サービス・インターメディアリのエンドポイントが識別される。
【００９３】
図６の方法では、パラメータ情報（１０７）に応じて、操作をサポートするターゲット・サービスのエンドポイントを識別すること（３０８）に、しばしば、ターゲット・サービスの１つのエンドポイントだけではなく、操作をサポートするターゲット・サービスの２つ以上のエンドポイントを識別することを含めることができる。本発明方法の実施形態によるポート・タイプ不可知プロキシが、操作のポート・タイプをパラメータ情報（１０７）として受信し、クエリ・パラメータとしてポート・タイプを用いてビジネス・レジストリを照会し、これによって操作をサポートするターゲット・サービスの２つ以上のエンドポイントを識別する例を検討されたい。２つ以上のエンドポイントのそのような識別は、例えば、ポート・タイプを用いてＵＤＤＩレジストリに照会し、それに応答して、そのポート・タイプに関するターゲット・サービスを記述した複数のＷＳＤＬ文書を受信することによって実行することができる。
【００９４】
複数のエンドポイントがそのように識別される場合に、本発明の実施形態によるウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法に、通常、選択ルールに従ってエンドポイントのうちの１つを選択することが含まれる。自明な例では、選択ルールを、そのように識別された最初のエンドポイントを選択し、他のエンドポイントを破棄することとすることができる。選択ルールは、例えば、負荷平衡化に関する選択ルールを含む、より複雑なルールとすることができる。負荷平衡化に関するルールは、表２に示されたものに類似したデータ構造の使用によってインプリメントすることができる。
【００９５】
【表２】
【００９６】
表２の各行は、インターメディアリとターゲット・サービスの間のウェブ・サービス・データ通信の要求−応答ラウンド・トリップに関する待ち時間測定値を表す。表２には、要求および応答のラウンドごとに、ポート・タイプおよびエンドポイントＵＲＩの列が設けられている。送信時刻列は、要求メッセージが、インターメディアリからポート・タイプの操作に関するターゲット・サービスのエンドポイントに発行されたときの時刻を記録したものである。受信時刻列は、対応する応答メッセージがターゲット・サービスから受信されたときの時刻を記録したものである。トリップ待ち時間は、受信時刻と送信時刻の差である。累積待ち時間は、この表に表されたエンドポイントごとのトリップ待ち時間の現在合計である。表２に似た構造を用いて、要求に関する複数のエンドポイントが識別されたときに使用される選択ルールを、次の例示的なルールとしてインプリメントすることができる。
同一ポート・タイプの操作に関する複数の要求がインターメディアリに達したときには、複数の識別されたエンドポイントのそれぞれを順番に１回使用する。
そのような使用のそれぞれの待ち時間データを記録する。
同一ポート・タイプの操作に関する後続要求について、最短の累積待ち時間を有するエンドポイントを待ち時間テーブルから選択し、要求をそのエンドポイントに送信し、メッセージがターゲット・サービスに送信されるときおよび対応する応答がインターメディアリで受信されるときに、関連する待ち時間データを記録する。
【００９７】
表２の例示的データには、ポート・タイプＡについて２つのエンドポイントすなわち、URIhttp://www.ibm.com/aTargetServiceにある第１エンドポイントおよびURIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントに最近送信された要求の累積待ち時間が示されている。第１エンドポイントは、２５０ミリ秒の累積要求待ち時間を有し、第２エンドポイントは、１００ミリ秒の累積要求待ち時間を有する。上で示した例示的な選択ルールを使用すると、ポート・タイプＡに関する操作の現在の要求は、URIhttp://www.ibm.com/anotherTargetServiceにある第２エンドポイントにルーティングされる。
【００９８】
図６の方法では、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）を、バインディング中立インターフェース内で有用なデータ構造内に要求を構成し、その要求を呼出しパラメータとして渡してバインディング中立インターフェースを呼び出すことによって実行することができる。同様に、ターゲット・サービスにターゲット・サービス要求（１１４）を発行すること（３１６）に、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことが含まれる。
【００９９】
バインディング中立インターフェースは、そのインターフェースの使用が要求またはメッセージのバインディングに依存しないインターフェースである。すなわち、このインターフェースをインプリメントし、それを介するデータ通信を実行するのに使用されるデータ構造および呼出し方法は、メッセージに使用されるデータ・エンコーディングのタイプに依存せず、メッセージに使用されるデータ通信プロトコルに依存しない。本発明の実施形態によるインターメディアリ用のポート・タイプ不可知プロキシの開発者は、しばしば、彼ら自身のバインディング中立インターフェースを作成する。しかし、「ＷＳＩＦ」すなわちWeb Service Invocation Frameworkと称する、バインディング中立インターフェースのオープン標準規格がある。ＷＳＩＦは、現在、ApacheSoftware FoundationのWeb Services Projectの一部としてサポートされている。
【０１００】
バインディング中立インターフェースの使用は、本発明の実施形態に利益をもたらす。ＳＯＡＰ−ＨＴＴＰバインディングは、現在の技術で非常に一般的なので、ユーザおよび開発者は、時々、他のバインディングが存在することを忘れる。これは、他のバインディングと共に使用されるか他のバインディングと共に使用するために適合させることが、不可能でないとしても非常にむずかしいシステムの開発をもたらす。しかし、ウェブ・サービスが成長するにつれて、他のバインディングが、より有用でより一般的になる。さらに、本発明の実施形態のバック・エンドにバインディング中立インターフェースを使用することは、使用可能なバインディングをラン・タイムに決定でき、これによって、柔軟で強力でより一般的に有用なウェブ・サービス・インターメディアリが提供されることを意味する。
【０１０１】
バインディング中立インターフェースをインプリメントする形の１つが、ポート・タイプおよびエンドポイントを与えられてターゲット・サービス内のサービスを呼び出すことができるエンドポイント・オブジェクトを提供することである。そのようなエンドポイント・オブジェクトを提供する形の１つが、次の擬似コード・セグメントに例示されたものに似たエンドポイント・ファクトリを使用することによるものである。
// エンドポイント・ファクトリ・クラス
// エンドポイント・オブジェクトを作成するパラメータ化されたファクトリ・メソッドを定義する
//
class EndpointFactory
{
public static EndpointcreateEndpointObject(portType, networkAddress)
{
// 新しいエンドポイント・オブジェクトの参照を確立する
Endpoint anEndpoint = null;
if(portType == "A" &&networkAddress == "www.abc.com")
anEndpoint = new Endpoint1;
if(portType == "B" && networkAddress== "www.def.com")
anEndpoint = new Endpoint2;
if(portType == "C" &&networkAddress == "www.ghi.com")
anEndpoint = new Endpoint3;
...
if(portType == "LAST" &&networkAddress == "www.lastSupported.com")
anEndpoint = new Endpoint465;
if anEndpoint == null) reportError();
else return anEndpoint;
}// createEndpointObject()の終り
}// クラスEndpointFactoryの終り
【０１０２】
エンドポイント・クラスＥｎｄｐｏｉｎｔ１、Ｅｎｄｐｏｉｎｔ２、Ｅｎｄｐｏｉｎｔ３などは、メッセージ・パーツを含むメッセージ・オブジェクトを作成するメンバ・メソッドを提供する抽象エンドポイント・クラスを継承する（または、インターフェースとしてインプリメントする）具象クラスである。そのようなエンドポイント・ファクトリおよびそのようなバインディング中立インターフェースの他の要素を使用して、次の擬似コード・セグメントに示されているように、ターゲット・サービス要求（１１４）を作成するステップ（３１２）およびターゲット・サービスにターゲット・サービス要求（１１４）を発行するステップ（３１６）を実行することができる。
// エンドポイント・ファクトリからエンドポイント・オブジェクトを得る
Endpoint ep = endPointFactory.createEndPoint(portType,networkAddress);
// 入力メッセージを用意する
Message input = ep.createInputMessage();
// メッセージ・アクセス関数を使用してメッセージの内容を挿入する
input.setPart("symbol","IBM");
// 応答値のプレースホルダを用意する
Message output = null;
if(synchRespReqd == TRUE) output = ep.createOutputMessage();
// 操作を実行する
ep.executeRequestResponseOperation("getQuote",
input, output);
// 結果を返す
if(synchRespReqd == TRUE) return output;
else return ACK;
【０１０３】
この例示的な擬似コード・セグメントは、エンドポイントのポート・タイプおよびネットワーク・アドレスを与えられて、エンドポイント・ファクトリを呼び出してエンドポイント・オブジェクトを作成する。次に、このセグメントは、メッセージ・パーツをエンドポイント・オブジェクトにロードすることによってターゲット・サービス要求を作成し、メンバ・メソッドｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）を呼び出すことによってターゲット・サービスにターゲット・サービス要求を発行する。図７の方法に、ターゲット・サービスからの応答（１２２）をインターメディアリで受信すること（３２０）と、インターメディアリで、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（３２８）が含まれる。
【０１０４】
この例示的な擬似コード・セグメントでは、ターゲット・サービスからの応答（１２２）を受信するステップ（３２０）およびインターメディアリからの応答（１２６）を作成するステップ（３２４）が、ｅｘｅｃｕｔｅＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅＯｐｅｒａｔｉｏｎ（）への呼出しによってインプリメントされる。この例では、出力メッセージへの参照の値は、要求が同期応答を必要とする場合にヌルのままにされる。この種類の実施形態のヌル「ｏｕｔｐｕｔ」パラメータは、プロバイダ（図３の２２０）によって、同期応答が不要であることを意味すると解釈される。したがって、プロバイダは、要求をターゲット・サービスに発行し、応答を待たずに即座にリターンする。
【０１０５】
同様に、要求が同期応答を必要とする場合に、応答メッセージへの参照「ｏｕｔｐｕｔ」の値に、ｏｕｔｐｕｔ＝ｅｐ．ｃｒｅａｔｅＯｕｔｐｕｔＭｅｓｓａｇｅ（）によって非ヌルがセットされる。呼出し
ep.executeRequestResponseOperation("getQuote",input, output)
での、この例では「ｏｕｔｐｕｔ」という名前の応答メッセージへのパラメータ参照が非ヌルであるという事実は、プロバイダ（図３の２２０）によって、同期応答が必要であることを意味すると解釈される。そのようなプロバイダは、そのアウトバウンド・エンジン（図３の２２２）でブロッキング受信呼出しを行い、ターゲット・サービスからの対応する応答メッセージを待つようにプログラムされる。図７の方法に関して、このセグメントは、要求が同期応答を必要とするかどうかの判定（１５２）に応じて、ターゲット・サービスの操作の実行に関するターゲット・サービス要求（１１４）を作成すること（３１２）の例示的方法を表す。
【０１０６】
上の例の擬似コード・セグメントは、エンドポイントとして参照されるポートを有するバインディング中立インターフェースの使用を例示するものである。しかし、ＷＳＩＦインターフェース構文は、エンドポイントを参照するときに用語「ポート」を使用する。したがって、バインディング中立インターフェースの使用に関するさらなる説明として、ＷＳＩＦ標準規格をより厳守するさらなる例示的擬似コード・セグメントを示す。この例では、「ポート」が、「エンドポイント」を意味するのに使用され、説明の一貫性を保つために、ファクトリの名前が、「ｐｏｒｔＦａｃｔｏｒｙ」に変更されている。
// ファクトリからポート（エンドポイント）を得る
WSIFPort port =portFactory.getPort(portType, networkAddress);
// 入力メッセージを用意する
WSIFMessage input =port.createInputMessage();
// メッセージ内容を挿入する
input.setPart("symbol",
new WSIFＪａｖａ（Ｒ）Part(String.class, symbol));
// 応答値のプレースホルダを用意する
WSIFMessage output = null;
if(synchRespReqd == TRUE) output = port.createOutputMessage();
// 操作を実行する
port.executeRequestResponseOperation("getQuote",
input, output, null);
// 結果を抽出し、返す
if(synchRespReqd == TRUE) return output;
else return ACK;
【０１０７】
本明細書では、主にリクエスタからターゲット・サービスへの過程での要求の処理に関して、ウェブ・サービス・インターメディアリでのポート・タイプ不可知プロキシ・サポートの例示的方法を論ずるが、本発明の実施形態によるインターメディアリが、通常、ターゲット・サービスからインターメディアリを介して最初のリクエスタに戻る応答メッセージを処理することもできることに留意することが有用である。例えば、図７の方法に、要求が同期応答を必要とする場合に、インターメディアリ内でターゲット・サービスから応答（１２２）を受信すること（３２０）と、インターメディアリ内で、ターゲット・サービスからの応答（１２２）に応じて、インターメディアリからの応答（１２６）を作成すること（３２４）と、インターメディアリからの応答（１２６）を要求するクライアントに返すこと（３２８）が含まれる。
【０１０８】
前述の説明から、本発明の真の趣旨から外れずに、本発明の様々な実施形態で修正および変更を行うことができることを理解されたい。本明細書の説明は、例示のみを目的とし、制限的な意味で解釈されてはならない。本発明の範囲は、添付請求項の言葉だけによって制限される。
【図面の簡単な説明】
【０１０９】
【図１】本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャを示す線画である。
【図２】本発明の実施形態に従ってウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートをインプリメントできる、ウェブ・サービスの例示的アーキテクチャを示す線画である。
【図３】本発明の実施形態による例示的なインターメディアリのブロック図を示す線画である。
【図４】本発明の実施形態によるＳＯＡＰ−ＨＴＴＰチャネルをインプリメントする例示的なインターメディアリ（２０２）のブロック図を示す線画である。
【図５】第１の実施形態による、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図である。
【図６】第２の実施形態による、ウェブ・サービス・インターメディアリのポート・タイプ不可知プロキシ・サポートの方法を示す流れ図である。
【図７】第２の実施形態による、要求が同期応答を必要とするときにターゲット・サービスからの応答を待つ（３６１）方法を示す流れ図である。
【特許請求の範囲】
【請求項１】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法であって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとを含む方法。
【請求項２】
前記要求が同期応答を必要とするかどうかを判定することと、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つこととをさらに含む、請求項１に記載の方法。
【請求項３】
前記要求が同期応答を必要とするかどうかを判定することが、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定することを含む、請求項２に記載の方法。
【請求項４】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成することを含む、請求項２または３に記載の方法。
【請求項５】
前記要求が、同期応答を必要とせず、前記方法が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信することと、応答メッセージを待たずに前記肯定応答をリクエスタに返すこととを含む、請求項２、３、または４に記載の方法。
【請求項６】
前記ターゲット・サービスからの応答を待つことが、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答をリクエスタに返すこととを含む、請求項２、３、４、または５に記載の方法。
【請求項７】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することが、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出すことを含む、請求項６に記載の方法。
【請求項８】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項１ないし７のいずれかに記載の方法。
【請求項９】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別することをさらに含む、請求項１ないし８のいずれかに記載の方法。
【請求項１０】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項１ないし９のいずれかに記載の方法。
【請求項１１】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することが、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することと、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することとを含む、請求項１ないし１０のいずれかに記載の方法。
【請求項１２】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することが、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別することを含む、請求項１１に記載の方法。
【請求項１３】
前記複数のエンドポイントから１つのエンドポイントを選択することが、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することを含む、請求項１１または１２に記載の方法。
【請求項１４】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求をバインディング中立インターフェースで有用なデータ構造に構成することと、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出すこととを含む、請求項１ないし１３のいずれかに記載の方法。
【請求項１５】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行することが、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことを含む、請求項１ないし１４のいずれかに記載の方法。
【請求項１６】
前記インターメディアリで前記ターゲット・サービスからの応答を受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととをさらに含む、請求項１ないし１５のいずれかに記載の方法。
【請求項１７】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのシステムであって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する手段とを含むシステム。
【請求項１８】
前記要求が同期応答を必要とするかどうかを判定する手段と、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つ手段とを含む、請求項１７に記載のシステム。
【請求項１９】
前記要求が同期応答を必要とするかどうかを判定する手段が、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定する手段を含む、請求項１８に記載のシステム。
【請求項２０】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成する手段を含む、請求項１８または１９に記載のシステム。
【請求項２１】
前記要求が、同期応答を必要とせず、前記システムが、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信する手段と、応答メッセージを待たずに前記肯定応答をリクエスタに返す手段とを含む、請求項１８、１９、または２０に記載のシステム。
【請求項２２】
前記ターゲット・サービスからの応答を待つ手段が、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する手段と、前記インターメディアリからの前記応答をリクエスタに返す手段とを含む、請求項１８、１９、２０、または２１に記載のシステム。
【請求項２３】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段が、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出す手段を含む、請求項２２に記載のシステム。
【請求項２４】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項１７ないし２３のいずれかに記載のシステム。
【請求項２５】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別する手段をさらに含む、請求項１７ないし２４のいずれかに記載のシステム。
【請求項２６】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項１７ないし２５のいずれかに記載のシステム。
【請求項２７】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段が、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段と、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する手段とを含む、請求項１７ないし２６のいずれかに記載のシステム。
【請求項２８】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段が、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別する手段を含む、請求項２７に記載のシステム。
【請求項２９】
前記複数のエンドポイントから１つのエンドポイントを選択する手段が、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する手段を含む、請求項２７または２８に記載のシステム。
【請求項３０】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、前記要求をバインディング中立インターフェースで有用なデータ構造に構成する手段と、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出す手段とを含む、請求項１７ないし２９のいずれかに記載のシステム。
【請求項３１】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行する手段が、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出す手段を含む、請求項１７ないし３０のいずれかに記載のシステム。
【請求項３２】
前記インターメディアリで前記ターゲット・サービスからの応答を受信する手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する手段と、前記インターメディアリからの前記応答を前記要求するクライアントに返す手段とをさらに含む、請求項１７ないし３１のいずれかに記載のシステム。
【請求項３３】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのコンピュータ・プログラム製品であって、記録媒体と、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する前記記録媒体に記録された手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、前記記録媒体に記録された手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する前記記録媒体に記録された手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する前記記録媒体に記録された手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する前記記録媒体に記録された手段とを含むコンピュータ・プログラム製品。
【請求項３４】
前記要求が同期応答を必要とするかどうかを判定する前記記録媒体に記録された手段と、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つ前記記録媒体に記録された手段とを含む、請求項３３に記載のコンピュータ・プログラム製品。
【請求項３５】
前記要求が同期応答を必要とするかどうかを判定する手段が、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定する前記記録媒体に記録された手段を含む、請求項３４に記載のコンピュータ・プログラム製品。
【請求項３６】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成する前記記録媒体に記録された手段を含む、請求項３４または３５に記載のコンピュータ・プログラム製品。
【請求項３７】
前記要求が、同期応答を必要とせず、前記コンピュータ・プログラム製品が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信する前記記録媒体に記録された手段と、応答メッセージを待たずに前記肯定応答をリクエスタに返す前記記録媒体に記録された手段とを含む、請求項３４、３５、または３６に記載のコンピュータ・プログラム製品。
【請求項３８】
前記ターゲット・サービスからの応答を待つ手段が、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する前記記録媒体に記録された手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する前記記録媒体に記録された手段と、前記インターメディアリからの前記応答をリクエスタに返す前記記録媒体に記録された手段とを含む、請求項３４、３５、３６、または３７に記載のコンピュータ・プログラム製品。
【請求項３９】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段が、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出す前記記録媒体に記録された手段を含む、請求項３８に記載のコンピュータ・プログラム製品。
【請求項４０】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項３３ないし３９のいずれかに記載のコンピュータ・プログラム製品。
【請求項４１】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別する前記記録媒体に記録された手段をさらに含む、請求項３３ないし４０のいずれかに記載のコンピュータ・プログラム製品。
【請求項４２】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項３３ないし４１のいずれかに記載のコンピュータ・プログラム製品。
【請求項４３】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段が、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する前記記録媒体に記録された手段と、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する前記記録媒体に記録された手段とを含む、請求項３３ないし４２のいずれかに記載のコンピュータ・プログラム製品。
【請求項４４】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段が、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別する前記記録媒体に記録された手段を含む、請求項４３に記載のコンピュータ・プログラム製品。
【請求項４５】
前記複数のエンドポイントから１つのエンドポイントを選択する手段が、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する前記記録媒体に記録された手段を含む、請求項４３または４４に記載のコンピュータ・プログラム製品。
【請求項４６】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、前記要求をバインディング中立インターフェースで有用なデータ構造に構成する前記記録媒体に記録された手段と、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出す前記記録媒体に記録された手段とを含む、請求項３３ないし４５のいずれかに記載のコンピュータ・プログラム製品。
【請求項４７】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行する手段が、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出す前記記録媒体に記録された手段を含む、請求項３３ないし４６のいずれかに記載のコンピュータ・プログラム製品。
【請求項４８】
前記インターメディアリで前記ターゲット・サービスからの応答を受信する前記記録媒体に記録された手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する前記記録媒体に記録された手段と、前記インターメディアリからの前記応答を前記要求するクライアントに返す前記記録媒体に記録された手段とをさらに含む、請求項３３ないし４７のいずれかに記載のコンピュータ・プログラム製品。
【請求項４９】
コンピュータで稼動するときに請求項１ないし１６のいずれかに記載の方法を実行するように適合されたプログラム・コード手段を含むコンピュータ・プログラム。
【請求項１】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートの方法であって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信することであって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含むことと、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することと、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することと、前記ターゲット・サービス要求を前記ターゲット・サービスに発行することとを含む方法。
【請求項２】
前記要求が同期応答を必要とするかどうかを判定することと、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つこととをさらに含む、請求項１に記載の方法。
【請求項３】
前記要求が同期応答を必要とするかどうかを判定することが、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定することを含む、請求項２に記載の方法。
【請求項４】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成することを含む、請求項２または３に記載の方法。
【請求項５】
前記要求が、同期応答を必要とせず、前記方法が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信することと、応答メッセージを待たずに前記肯定応答をリクエスタに返すこととを含む、請求項２、３、または４に記載の方法。
【請求項６】
前記ターゲット・サービスからの応答を待つことが、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答をリクエスタに返すこととを含む、請求項２、３、４、または５に記載の方法。
【請求項７】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信することが、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出すことを含む、請求項６に記載の方法。
【請求項８】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項１ないし７のいずれかに記載の方法。
【請求項９】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別することをさらに含む、請求項１ないし８のいずれかに記載の方法。
【請求項１０】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項１ないし９のいずれかに記載の方法。
【請求項１１】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別することが、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することと、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することとを含む、請求項１ないし１０のいずれかに記載の方法。
【請求項１２】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別することが、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別することを含む、請求項１１に記載の方法。
【請求項１３】
前記複数のエンドポイントから１つのエンドポイントを選択することが、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択することを含む、請求項１１または１２に記載の方法。
【請求項１４】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成することが、前記要求をバインディング中立インターフェースで有用なデータ構造に構成することと、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出すこととを含む、請求項１ないし１３のいずれかに記載の方法。
【請求項１５】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行することが、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出すことを含む、請求項１ないし１４のいずれかに記載の方法。
【請求項１６】
前記インターメディアリで前記ターゲット・サービスからの応答を受信することと、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成することと、前記インターメディアリからの前記応答を前記要求するクライアントに返すこととをさらに含む、請求項１ないし１５のいずれかに記載の方法。
【請求項１７】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのシステムであって、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する手段とを含むシステム。
【請求項１８】
前記要求が同期応答を必要とするかどうかを判定する手段と、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つ手段とを含む、請求項１７に記載のシステム。
【請求項１９】
前記要求が同期応答を必要とするかどうかを判定する手段が、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定する手段を含む、請求項１８に記載のシステム。
【請求項２０】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成する手段を含む、請求項１８または１９に記載のシステム。
【請求項２１】
前記要求が、同期応答を必要とせず、前記システムが、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信する手段と、応答メッセージを待たずに前記肯定応答をリクエスタに返す手段とを含む、請求項１８、１９、または２０に記載のシステム。
【請求項２２】
前記ターゲット・サービスからの応答を待つ手段が、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する手段と、前記インターメディアリからの前記応答をリクエスタに返す手段とを含む、請求項１８、１９、２０、または２１に記載のシステム。
【請求項２３】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段が、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出す手段を含む、請求項２２に記載のシステム。
【請求項２４】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項１７ないし２３のいずれかに記載のシステム。
【請求項２５】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別する手段をさらに含む、請求項１７ないし２４のいずれかに記載のシステム。
【請求項２６】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項１７ないし２５のいずれかに記載のシステム。
【請求項２７】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段が、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段と、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する手段とを含む、請求項１７ないし２６のいずれかに記載のシステム。
【請求項２８】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段が、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別する手段を含む、請求項２７に記載のシステム。
【請求項２９】
前記複数のエンドポイントから１つのエンドポイントを選択する手段が、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する手段を含む、請求項２７または２８に記載のシステム。
【請求項３０】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、前記要求をバインディング中立インターフェースで有用なデータ構造に構成する手段と、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出す手段とを含む、請求項１７ないし２９のいずれかに記載のシステム。
【請求項３１】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行する手段が、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出す手段を含む、請求項１７ないし３０のいずれかに記載のシステム。
【請求項３２】
前記インターメディアリで前記ターゲット・サービスからの応答を受信する手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する手段と、前記インターメディアリからの前記応答を前記要求するクライアントに返す手段とをさらに含む、請求項１７ないし３１のいずれかに記載のシステム。
【請求項３３】
ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポートのコンピュータ・プログラム製品であって、記録媒体と、ウェブ・サービス・インターメディアリでウェブ・サービス操作の実行に関する要求を受信する前記記録媒体に記録された手段であって、前記要求は、前記操作をサポートするターゲット・サービスのエンドポイントをそれから識別できるパラメータ情報を含む、前記記録媒体に記録された手段と、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する前記記録媒体に記録された手段と、前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する前記記録媒体に記録された手段と、前記ターゲット・サービス要求を前記ターゲット・サービスに発行する前記記録媒体に記録された手段とを含むコンピュータ・プログラム製品。
【請求項３４】
前記要求が同期応答を必要とするかどうかを判定する前記記録媒体に記録された手段と、前記要求が同期応答を必要とする場合に前記ターゲット・サービスからの応答を待つ前記記録媒体に記録された手段とを含む、請求項３３に記載のコンピュータ・プログラム製品。
【請求項３５】
前記要求が同期応答を必要とするかどうかを判定する手段が、前記要求が同期応答を必要とするかどうかを前記パラメータ情報に応じて判定する前記記録媒体に記録された手段を含む、請求項３４に記載のコンピュータ・プログラム製品。
【請求項３６】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、さらに、前記要求が同期応答を必要とするかどうかの判定に応じて前記ターゲット・サービス要求を作成する前記記録媒体に記録された手段を含む、請求項３４または３５に記載のコンピュータ・プログラム製品。
【請求項３７】
前記要求が、同期応答を必要とせず、前記コンピュータ・プログラム製品が、さらに、前記ターゲット・サービス要求の肯定応答を前記ターゲット・サービスから受信する前記記録媒体に記録された手段と、応答メッセージを待たずに前記肯定応答をリクエスタに返す前記記録媒体に記録された手段とを含む、請求項３４、３５、または３６に記載のコンピュータ・プログラム製品。
【請求項３８】
前記ターゲット・サービスからの応答を待つ手段が、さらに、前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する前記記録媒体に記録された手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する前記記録媒体に記録された手段と、前記インターメディアリからの前記応答をリクエスタに返す前記記録媒体に記録された手段とを含む、請求項３４、３５、３６、または３７に記載のコンピュータ・プログラム製品。
【請求項３９】
前記ターゲット・サービスからの応答を前記インターメディアリで同期式に受信する手段が、さらに、前記インターメディアリと前記ターゲット・サービスとの間のデータ通信接続に対してブロッキング受信関数を呼び出す前記記録媒体に記録された手段を含む、請求項３８に記載のコンピュータ・プログラム製品。
【請求項４０】
作成され、前記ターゲット・サービスに発行される前記ターゲット・サービス要求が、前記ウェブ・サービス・インターメディアリで受信された前記要求の検査されず変更されないメッセージ内容を有する、請求項３３ないし３９のいずれかに記載のコンピュータ・プログラム製品。
【請求項４１】
前記操作をサポートするエンドポイントとして、前記ウェブ・サービス・インターメディアリのエンドポイントをリクエスタに識別する前記記録媒体に記録された手段をさらに含む、請求項３３ないし４０のいずれかに記載のコンピュータ・プログラム製品。
【請求項４２】
前記パラメータ情報が、前記操作のポート・タイプを含む、請求項３３ないし４１のいずれかに記載のコンピュータ・プログラム製品。
【請求項４３】
前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの前記エンドポイントを識別する手段が、さらに、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する前記記録媒体に記録された手段と、選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する前記記録媒体に記録された手段とを含む、請求項３３ないし４２のいずれかに記載のコンピュータ・プログラム製品。
【請求項４４】
前記パラメータ情報が、前記操作のポート・タイプを含み、前記パラメータ情報に応じて、前記操作をサポートするターゲット・サービスの複数のエンドポイントを識別する手段が、前記ポート・タイプに応じて、前記ポート・タイプに関する複数のターゲット・サービスをレジストリから識別する前記記録媒体に記録された手段を含む、請求項４３に記載のコンピュータ・プログラム製品。
【請求項４５】
前記複数のエンドポイントから１つのエンドポイントを選択する手段が、さらに、ターゲット・サービスの間の負荷平衡化に関する選択ルールに従って前記複数のエンドポイントから１つのエンドポイントを選択する前記記録媒体に記録された手段を含む、請求項４３または４４に記載のコンピュータ・プログラム製品。
【請求項４６】
前記ターゲット・サービスの前記操作の実行に関するターゲット・サービス要求を作成する手段が、前記要求をバインディング中立インターフェースで有用なデータ構造に構成する前記記録媒体に記録された手段と、前記要求を呼出しパラメータとして渡して前記バインディング中立インターフェースを呼び出す前記記録媒体に記録された手段とを含む、請求項３３ないし４５のいずれかに記載のコンピュータ・プログラム製品。
【請求項４７】
前記ターゲット・サービスに前記ターゲット・サービス要求を発行する手段が、バインディング中立インターフェースの１つまたは複数のメンバ・メソッドを呼び出す前記記録媒体に記録された手段を含む、請求項３３ないし４６のいずれかに記載のコンピュータ・プログラム製品。
【請求項４８】
前記インターメディアリで前記ターゲット・サービスからの応答を受信する前記記録媒体に記録された手段と、前記インターメディアリで、前記ターゲット・サービスからの前記応答に応じて、前記インターメディアリからの応答を作成する前記記録媒体に記録された手段と、前記インターメディアリからの前記応答を前記要求するクライアントに返す前記記録媒体に記録された手段とをさらに含む、請求項３３ないし４７のいずれかに記載のコンピュータ・プログラム製品。
【請求項４９】
コンピュータで稼動するときに請求項１ないし１６のいずれかに記載の方法を実行するように適合されたプログラム・コード手段を含むコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００７−５１５７１６（Ｐ２００７−５１５７１６Ａ）
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００６−５４３５４９（Ｐ２００６−５４３５４９）
【出願日】平成１６年１２月９日（２００４．１２．９）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５３３８２
【国際公開番号】ＷＯ２００５／０６０２１２
【国際公開日】平成１７年６月３０日（２００５．６．３０）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１６年１２月９日（２００４．１２．９）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５３３８２
【国際公開番号】ＷＯ２００５／０６０２１２
【国際公開日】平成１７年６月３０日（２００５．６．３０）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]