JP2010511236A - ウェブ・サービス・エンドポイントを表すエンドポイント参照を変更する方法、装置およびコンピュータ・プログラム - Google Patents

Abstract

【課題】ＷＳ‐ＡｄｄｒｅｓｓｉｎｇのＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅは、ウェブ・サービス・エンドポイントを表し、ウェブ・サービス対話の一部としてＳＯＡＰエンベロープ内で伝達される。ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの伝達時に、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの特徴を、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの受信側を基にして決定する（または変更する）方法、装置およびコンピュータ・プログラムを開示する。
【解決手段】別々の受信側は、異なるＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅを受信することになる可能性もある。ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの特徴は、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの伝達のためにＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅを表すＳＯＡＰ ＸＭＬが生成されるときに、再決定される。例えば、受信側の位置が、伝達されるアドレスに影響する可能性もある。受信側がファイアウォール外にあれば、受信側にファイアウォール自体のアドレスを提供して、ファイアウォールが、データからあらゆるリクエストをウェブ・サービス・エンドポイントへ再送できるようにすることが適切な場合もある。あるいは、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ内に含まれるメタデータが、受信側に基づき変化してもよいであろう。ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ内に含まれるポリシー・メタデータは、受信側によってはより厳しいセキュリティ要件を指定することもあり得る。
【選択図】図７

Description

本発明は、データ処理システムに関し、特に、そのようなデータ処理システム内の複数のエンドポイントをアドレス指定することに関する。

インターネットは、クライアント・サーバ・モデルに基づいており、通信ネットワークを介して複数のクライアントによりアクセス可能な複数のウェブ・サーバを含む。

インターネットを介してウェブ・サービスにアクセスするという概念の普及が進んでおり、いくつかの標準が開発されてきている。

図１は、通信ネットワーク（例えばインターネット）６０でクライアント１０に接続されているホスト・コンピュータ・システム、すなわちウェブ・サーバ５０を含む、コンピュータ・ネットワーク５を示している。ウェブ・サーバ５０は、単一エンティティとしてパッケージ化され他のプログラム向けにネットワークへ公開される機能の集まりを提供するウェブ・サービス３０へのアクセスをホストし、したがって、ネットワーク上での相互運用可能なマシン同士の対話をサポートする。ウェブ・サービスは、ウェブ・サービス記述言語（ＷＳＤＬ：Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）など、マシンが処理できる形式で記述されているインターフェース４０を有する。他のシステムは、ウェブ・サービスのインターフェースにより規定される方法で、ウェブ・サービスとメッセージを用いて対話する。一般的に、これらのメッセージは、ＨＴＴＰを用いて伝えられ、通常は拡張マークアップ言語（ＸＭＬ：ｅＸｔｅｎｓｉｂｕｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）をその他のウェブ関連の標準と共に含む。

ＷＳ‐Ａｄｄｒｅｓｓｉｎｇ仕様は、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ：ワールドワイド・ウェブ・コンソーシアム）により推進された共同活動の結果である。ＷＳ‐Ａｄｄｒｅｓｓｉｎｇは、ウェブ・サービス・メッセージを適切に導くことに関係している。

ＷＳ‐Ａｄｄｒｅｓｓｉｎｇは、ウェブ・サービス・エンドポイント（何らかの可能なアプリケーション・データが関連付けられているウェブ・サービス・ポート）をアドレス指定するために必要な情報を標準のＸＭＬフォーマットで伝える、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ（ＥＰＲ：エンドポイント参照）の概念を取り入れている。

ＥＰＲには、そのアドレス（ＥＰＲが表すエンドポイントのＵＲＩ）、およびエンドポイントについてのメタデータ（エンドポイントの性能など）など、いくつかの特性がある。これらの特性の一部（アドレスＵＲＩなど）は、エンドポイントの展開情報を基に生成されることも、または、ＥＰＲを生成するアプリケーションに認識されていることもある。ＥＰＲは、ウェブ・サービス対話の一部としてＳＯＡＰエンベロープ内で伝達される。ウェブ・サービス対話におけるＥＰＲの受信側は、そのＥＰＲを、ウェブ・サービスをターゲットにするために使用すると考えられる。

第１の態様によれば、ウェブ・サービス・エンドポイントを表すＥＰＲを変更する方法が提供される。方法には、ＥＰＲが伝達されるべき受信側の少なくとも１つの属性に基づきＥＰＲを変更することと、変更されたＥＰＲをクライアントへ伝達することとが含まれる。

ＥＰＲは、受信側への伝達時に変更されることが好ましい。

「受信側」という用語は、受信側のクライアントと、受信側のウェブ・サービスとの両方を含むものとする。

上記の属性の１つには、受信側の位置が考えられ、これは、ＥＰＲのアドレス要素の変更という結果をもたらすこともある。

このような実施形態では、ＥＰＲが伝達されるべき受信側についての情報が取得され、伝達されるべきＥＰＲに対し、取得された情報がどのように影響するかを判断するために、１つ以上のルールがアクセスされる。

最終的にＥＰＲの受信側へ伝達されるＥＰＲに影響し得るルールの例は、ファイアウォール（エンドポイントがその中にある）の外の受信側は、ターゲット・エンドポイントにファイアウォールを介してアクセスするという要件である。

一実施形態では、ＥＰＲは、受信側と、ＥＰＲにより表わされるエンドポイントとのサービス・レベル・アグリーメント（ＳＬＡ：ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）を基に変更される。

例えば、ＥＰＲの受信側は、「ゴールド・サービス」のビジネス・パートナーとして分類されていてもよい。この例では、より短い応答時間を保証するサーバをアドレス指定するように、ＥＰＲが、当該の受信側へ伝達される間に変更されることもあり得る。

受信側とエンドポイントとの相対的位置も、ＥＰＲの変更をもたらし得る。相対的位置に関して判断するためには、システム・トポロジ・データがアクセスされるとよい。

ＥＰＲは、メタデータを含むとよい。これは、対象とする受信側の属性に基づき変更されるとよい。例えば、一部の受信側が常に、特定のセキュリティ・レベル（セキュリティ・ポリシー）でターゲット・エンドポイントにアクセスするよう要求されてもよい。メタデータを変更して、このようなセキュリティ・ポリシーを指定することができる。

別の態様によれば、ウェブ・サービス・エンドポイントを表すＥＰＲを変更する装置が提供される。装置には、ＥＰＲが伝達されるべき受信側の少なくとも１つの属性に基づきＥＰＲを変更する手段と、変更されたＥＰＲを受信側へ伝達する手段とが含まれる。

本発明は、コンピュータ・ソフトウェアにおいて実装されてもよい。

以下、単なる例として、次の図面を参照して本発明の好適な実施形態について説明する。

ウェブ・サービス環境のコンポーネント図である。 本発明の好適な実施形態に従ったプリント・ウェブ・サービスを示す。 本発明の好適な実施形態に従ったプリント・ウェブ・サービスを示す。 好適な実施形態に従った、本発明のコンポーネントを示す。 好適な実施形態に従った、本発明のコンポーネントを示す。 好適な実施形態に従った、本発明の処理を示す。 好適な実施形態に従った、本発明の処理を示す。

上記のように、ＷＳ‐Ａｄｄｒｅｓｓｉｎｇ仕様は、ウェブ・サービス・メッセージを正確に導くことを保証することに関し、このことを考慮してエンドポイント参照（ＥＰＲ）の概念を取り入れている。

ＥＰＲの例示的な使用を、図２および３（相互に併せて読まれるべきである）を参照して説明する。

クライアント１６０は、ステップ２００で、サービス・リクエスタ（ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔｅｒ）１７０（例えばプリント・アプリケーション）を用いて、ウェブ・サーバ１００によりホストされているプリント・カタログ・サービス（ｐｒｉｎｔ ｃａｔａｌｏｇｕｅ ｓｅｒｖｉｃｅ）１１０とコンタクトをとる。プリント・カタログ・サービス１１０には、インターフェース１２０を介してアクセス可能である。ステップ２１０で、サービス・リクエスタ１７０は、提供されたプリンタ・カタログ（ｐｒｉｎｔｅｒ ｃａｔａｌｏｇｕｅ）をブラウズし、プリンタを選択する。ステップ２２０で、ウェブ・サービスは、印刷サービス（ｐｒｉｎｔｉｎｇ ｓｅｒｖｉｃｅ）１８０へのエンドポイント参照（ＥＰＲ）を返す。このＥＰＲを介して、選択されたプリンタ１３０、１４０または１５０にアクセスすることができる。この例では、返されたＥＰＲは、別のウェブ・サーバ１７５によりホストされているウェブ・サービス１８０に対する。なお、別の例では、ＥＰＲが作成されるウェブ・サーバと参照先のウェブ・サーバとは同一であってもよい。

したがって、例示のように、ＥＰＲは一般的に、作成されると、参照先エンドポイントへアクセスを望む可能性があるクライアントに伝達される。ＥＰＲは、作成されるとエンドポイントを表すと見なされ、そのコンテンツは変更されない。

特定の状況では、要求しているクライアントすべてに、要求対象のウェブ・サービス・エンドポイントに関して同一のＥＰＲを提供するのは不適切である。代わりにＥＰＲが、伝達先に依存することが好ましいこともあるであろう。例えば、上記のＥＰＲがファイアウォール外のクライアントに渡される場合、ウェブ・サービス・エンドポイントが存在するウェブ・サーバの実際のアドレスを隠す方が適切なこともある。さらに、ＥＰＲの伝達先のクライアントに基づいて、返されるＥＰＲを変えることが適切な場合もあるであろう。

したがって、例えばＥＰＲが伝達されるべきターゲットを基にＥＰＲのアドレス部を変更する解決策が提案される。ＥＰＲに対するこのような変更は、伝達のためにＥＰＲがシリアライズされるのと同時に行われることが好ましい。

以下、図４、５、６および７を参照して、ＥＰＲの作成および変更について説明する。

図４に示されているとおり、ノードＡはエンドポイント・インスタンス２４０（ウェブ・サービス・エンドポイントを表す）を有する。ステップ４００で、そのエンドポイント・インスタンスのＥＰＲが、ノードＡにおいてＥＰＲ生成器３００により生成される（図５、６）。生成されたＥＰＲは、以下のように表わされるとよい。

＜ｗｓａ：ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞
＜ｗｓａ：Ａｄｄｒｅｓｓ＞ｔａｒｇｅｔＳｅｒｖｉｃｅＵＲＩ＜／ｗｓａ：Ａｄｄｒｅｓｓ＞
：
＜／ｗｓａ：ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞

ｗｓａプレフィックス＜ｗｓａ＞は、ｗｗｗ．ｗ３．ｏｒｇ／２００５／０８／ａｄｄｒｅｓｓｉｎｇに等しいことも考えられ、
ｔａｒｇｅｔＳｅｒｖｉｃｅＵＲＩは、ノードＡ上のターゲット・サービスのＵＲＩアドレスである。

ステップ４１０、４２０で、ＥＰＲをクライアントへ伝達する前に、ＥＰＲは、ＳＯＡＰシリアライザ３１０によってＳＯＡＰメッセージへとシリアライズされる（図５、６）。ＳＯＡＰメッセージは、ヘッダ（ｈｄｒ）およびボディを含む。次に、ＥＰＲを含んだメッセージが、伝達器３２０を用いてクライアントへ伝達される（ステップ４３０）。ＥＰＲは、次のリスト１に示されているように、ヘッダ内（例えば、ＷＳ‐Ａｄｄｒｅｓｓｉｎｇの［ｒｅｐｌｙＴｏ］ヘッダ内）で伝達されてもよい。

＜Ｓ：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：Ｓ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００３／０５／ｓｏａｐ−ｅｎｖｅｌｏｐｅ”
ｘｍｌｎｓ：ｗｓａ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００５／０８／ａｄｄｒｅｓｓｉｎｇ”＞
＜Ｓ：Ｈｅａｄｅｒ＞
：
＜ｗｓａ：ＲｅｐｌｙＴｏ＞
＜ｗｓａ：Ａｄｄｒｅｓｓ＞ｈｔｔｐ：／／ｎｏｄｅＡ／ｂｕｓｉｎｅｓｓ／ｃｌｉｅｎｔ１＜／ｗｓａ：Ａｄｄｒｅｓｓ＞
＜／ｗｓａ：ＲｅｐｌｙＴｏ＞
：
＜／Ｓ：Ｈｅａｄｅｒ＞
＜Ｓ：Ｂｏｄｙ＞
．．．
＜／Ｓ：Ｂｏｄｙ＞
＜／Ｓ：Ｅｎｖｅｌｏｐｅ＞

あるいは、ＥＰＲは次のリスト２に示されているようにＳＯＡＰボディ内で伝達されてもよい。

＜Ｓ：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：Ｓ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００３／０５／ｓｏａｐ−ｅｎｖｅｌｏｐｅ”
ｘｍｌｎｓ：ｗｓａ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００５／０８／ａｄｄｒｅｓｓｉｎｇ”＞
＜Ｓ：Ｈｅａｄｅｒ＞
：
：
＜／Ｓ：Ｈｅａｄｅｒ＞
＜Ｓ：Ｂｏｄｙ＞
：
＜ｗｓａ：ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞
＜ｗｓａ：Ａｄｄｒｅｓｓ＞ｈｔｔｐ：／／ｎｏｄｅＡ／ｂｕｓｉｎｅｓｓ／ｃｌｉｅｎｔ１＜／ｗｓａ：Ａｄｄｒｅｓｓ＞
＜／ｗｓａ：ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞
：
＜／Ｓ：Ｂｏｄｙ＞
＜／Ｓ：Ｅｎｖｅｌｏｐｅ＞

図７に示されているように、シリアライズ時に、取得器（ａｃｑｕｉｒｅｒ）３４０を用いて、ＥＰＲのターゲットとされる宛先のアドレスについて情報が取得される（ステップ５００）。リクエスト・メッセージの場合、ＥＰＲのターゲットとされる宛先のアドレスは、ｗｓａ：ｔｏ（ＳＯＡＰ宛先）フィールドから来てもよい。同期応答メッセージの場合は、応答宛先アドレスの宛先は、その対応するリクエスト・メッセージのｗｓａ：Ｆｒｏｍ ＥＰＲから、またはその他何らかのプロトコル特有情報から規定されることも考えられる。

続いて、アクセサ・コンポーネント（ａｃｃｅｓｓｏｒ ｃｏｍｐｏｎｅｎｔ）３５０は、ルール３３０にアクセスし、伝達されるべきＥＰＲに対して宛先のアドレスがどのように影響するかを判断する（ステップ５２０）。ルール３３０は、エンドポイントをターゲットとするために宛先により用いられるべきアドレスを定義する。例えば、以下のようになる。

ルール３３０は、ファイアウォール内の既知のノードすべて（内部ＩＰアドレス）を一覧にし、この一覧にないノードに伝達されるべきＥＰＲは、それらのアドレスがファイアウォールのアドレスとなるよう書き換えられるべきであると推測し得る。

または、ルールは、ＥＰＲが伝達されるべき宛先と、トポロジ内での、エンドポイントのアドレスに対するこの宛先の相対的位置とを基にＥＰＲのアドレスを書き換えるために、システム・トポロジを表すトポロジ・マッピング・テーブルを利用してもよいであろう。

次に、モディファイア・コンポーネント（ｍｏｄｉｆｉｅｒ ｃｏｍｐｏｎｅｎｔ）３６０は、ＥＰＲが伝達されるべき宛先（したがって、後の時点でそこからターゲットされる）を基にＥＰＲのアドレスを書き換える。

図３の例に関しては、ＥＰＲが（ＳＯＡＰメッセージの一部として）ノードＢへエクスポートされる場合、それはファイアウォール２５０内にあるため、ルール３３０は、エクスポートの前にＥＰＲを変更するようノードＡに要求しなくてもよい。したがって、ノードＢは、変更されていないＥＰＲを受信すると、直接ノードＡを参照することができる。

しかし、ノードＣはファイアウォール２５０の外にあり（すなわちファイアウォール境界内のノードとして認識されていない）、したがってルール３３０は、ノードＣはノードＡに直接アクセスできてはならないと指定するとよい。その結果、ノードＣに対するＳＯＡＰメッセージのシリアライズ中に、エンドポイント・インスタンスの作成時に生成されたＥＰＲアドレスがファイアウォールのアドレスで上書きされる。その結果、ファイアウォールは、クライアントからのあらゆるメッセージを適切なノードへ送る。

なお、このＥＰＲの書き換えは、ＥＰＲが直接ノードＣへ伝達される（すなわちファイアウォールが回避される）可能性もあるため、ファイアウォールで行うことはできない。

当然のことながら、上述のとおり、ＥＰＲの変更はＥＰＲの受信側の位置に依存しなくてもよい。受信側の１つ以上の他の属性が考慮されてもよい。ルール（前に例示した）は、トポロジ以外の何らかの属性を基にした、ＩＰアドレスの何らかのグループ化を利用してもよい。例えば、ＥＰＲのアドレスは、それらが伝達されるべき宛先のサービス・アグリーメントのレベルを基にして書き換えられることもあり得る。例えば、クライアントは、「ゴールド・サービス」のビジネス・パートナーとして分類されてもよく、したがって、そのクライアントへ伝達されるＥＰＲが、特定の応答時間を保証するサーバへ向けられるよう、ＥＰＲが変更されてもよいであろう。さらに、メタデータなど、アドレス以外のＥＰＲの特徴が変更されてもよい。

したがって、要約すると以下のようになる。

ＷＳ‐ＡｄｄｒｅｓｓｉｎｇのＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅは、ウェブ・サービス・エンドポイントを表し、ウェブ・サービス対話の一部としてＳＯＡＰエンベロープ内で伝達される。

ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの伝達時に、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの特徴を、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの受信側を基にして決定する（または変更する）方法、装置およびコンピュータ・プログラムが開示される。別々の受信側が、別々のＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅを受信することになる可能性もある。ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの特徴は、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅの伝達のためにＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅを表すＳＯＡＰ ＸＭＬが生成されるときに、再決定される。例えば、クライアントの位置が、伝達されるアドレスに影響する可能性もある。クライアントがファイアウォール外にあれば、クライアントにはファイアウォール自体のアドレスを提供して、ファイアウォールが、データからあらゆるリクエストをウェブ・サービス・エンドポイントへ再送できるようにすることが適切な場合もある。あるいは、ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ内に含まれるメタデータが、受信側に基づき変化してもよいであろう。ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ内に含まれるポリシー・メタデータが、受信側によってはより厳しいセキュリティ要件を指定することもあり得る。

Claims (16)

1. ウェブ・サービス・エンドポイントを表すＥＰＲを変更する方法であって、
   前記ＥＰＲが伝達されるべき受信側の少なくとも１つの属性に基づき前記ＥＰＲを変更するステップと、
   前記変更されたＥＰＲを前記受信側へ伝達するステップと、
   を含む方法。
2. 前記受信側の少なくとも１つの属性に基づき前記ＥＰＲを変更する前記ステップは、
   ＥＰＲが伝達されるべき前記受信側についての情報を取得することと、
   伝達されるべき前記ＥＰＲに対して、前記取得された情報がどのように影響するかを判断するために１つ以上のルールにアクセスすることと、
   を含む、請求項１に記載の方法。
3. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記受信側の位置を含む、請求項２に記載の方法。
4. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記ウェブ・サービス・エンドポイントと、前記受信側とのサービス・レベル・アグリーメントを含む、請求項２または３に記載の方法。
5. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記ウェブ・サービス・エンドポイントの位置に対する前記受信側のポジションを含む、請求項２、３または４に記載の方法。
6. 前記ウェブ・サービス・エンドポイントの前記位置に対する前記受信側の前記ポジションを判断するために、システム・トポロジ・データにアクセスするステップ
   を含む、請求項５に記載に方法。
7. 前記ＥＰＲ内にあり前記ウェブ・サービス・エンドポイントを表すアドレスを変更するステップ
   を含む、先行するいずれかの請求項に記載の方法。
8. 前記受信側の少なくとも１つの属性に基づき前記ＥＰＲ内のメタデータを変更するステップ
   を含む、先行するいずれかの請求項に記載の方法。
9. 前記メタデータは、前記受信側が前記エンドポイントにアクセスするときに使用する特定のセキュリティ・ポリシーを指定するよう変更される、請求項８に記載の方法。
10. ウェブ・サービス・エンドポイントを表すＥＰＲを変更する装置であって、
    前記ＥＰＲが伝達されるべき受信側の少なくとも１つの属性に基づき前記ＥＰＲを変更する手段と、
    前記変更されたＥＰＲを前記受信側へ伝達する手段と、
    を含む装置。
11. 前記受信側の少なくとも１つの属性に基づき前記ＥＰＲを変更する前記手段は、
    ＥＰＲが伝達されるべき前記受信側についての情報を取得する手段と、
    伝達されるべき前記ＥＰＲに対して、前記取得された情報がどのように影響するかを判断するために１つ以上のルールにアクセスする手段と、
    を含む、請求項１０に記載の装置。
12. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記受信側の位置を含む、請求項１１のいずれかに記載の装置。
13. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記ウェブ・サービス・エンドポイントと、前記受信側とのサービス・レベル・アグリーメントを含む、請求項１１または１２のいずれかに記載の装置。
14. 前記ＥＰＲが伝達されるべき前記受信側の少なくとも１つの属性は、前記ウェブ・サービス・エンドポイントの位置に対する前記受信側のポジションを含む、請求項１１、１２または１３のいずれかに記載の装置。
15. 前記ウェブ・サービス・エンドポイントの前記位置に対する前記受信側の前記ポジションを判断するために、システム・トポロジ・データにアクセスする手段
    を含む、請求項１４に記載に装置。
16. コンピュータ・プログラムがコンピュータ上で実行されると、請求項１〜９のいずれかに記載の方法を遂行するようになっているプログラム・コード手段を含む、前記コンピュータ・プログラム。

Images