UDDI バージョン 3 レジストリーの照会 API
照会 API は、レジストリーで従来使用されているソフトウェアのニーズに合致する、広範囲に使用されている規則に従う、4 つの照会形式を提供します。
- 参照パターン
- ドリルダウン・パターン
- 呼び出しパターン
- 照会 API の機能
UDDI レジストリーの参照パターン
データ (特に階層データ) を探して検査するために使用するソフトウェアには、参照機能が必須です。 参照パターンではその性質上、いくつかの広範囲の情報から開始して、検索を実行し、おおよその結果セットを検出し、 続いてドリルダウンのためにさらに限定的な情報を選択することが必要です。
UDDI API 仕様は、find_xx API 呼び出しを使用して参照パターンを提供します。 これらの呼び出しによって、API の提供する検索機能が形成されます。 これらの呼び出しと、要約戻りメッセージ (照会メッセージ・タイプおよび照会内で指定された検索基準に関連付けられた登録済み情報に関する概略情報を戻す) との突き合わせが行われます。
標準的な参照シーケンスでは、既知のビジネスに登録済み情報があるかどうかを検索する場合があります。 このシーケンスは、find_business への呼び出しから始まり、おそらく既知のビジネス名の最初の数文字を渡すことになります。このアクションは、businessList 結果を戻します。この結果は、キー、名前、および説明など、登録済みの businessEntity 情報から派生した概略情報であり、入力した名前のフラグメントに一致します。探しているビジネスがこのリスト内にある場合は、find_service API 呼び出しを使用して、対応する businessService 情報までドリルダウンし、購入や出荷など特定のテクニカル・モデルを検索できます。 同様に、特定のソフトウェア・インターフェースの技術的な指紋、すなわち tModel シグニチャーを知っており、探しているビジネスが、そのインターフェースをサポートする Web サービスを提供しているかどうかを確認する場合は、find_binding 照会メッセージを使用できます。
UDDI レジストリーのドリルダウン・パターン
UDDI レジストリーが管理する主要な 4 つのデータ型のいずれかのキーがわかっている場合は、そのキーを使用して、特定のデータ・インスタンスの登録済みの全詳細にアクセスできます。 UDDI のデータ型は businessEntity、businessService、bindingTemplate、および tModel です。 get_xx API 呼び出しのいずれかに関係のあるキーを渡すと、 これらの構造すべてに対する登録済みの完全な情報にアクセスできます。
前のセクションからの続きの例では、すべての find_x 戻りセットによって戻されるデータ項目の 1 つは、キー情報です。 これまで検討してきたビジネスの場合、businessList 構造体に入れて戻される businessKey 値を get_businessDetail メッセージに引数として渡すことができます。正常な場合には、このメッセージに対しては、渡されたキー値を持つエンティティーに関する完全な登録済み情報を含む businessDetail メッセージが戻されます。 この情報は完全な businessEntity 構造体です。
UDDI レジストリーの呼び出しパターン
他のビジネスまたはエンティティーによって UDDI レジストリーに登録されたリモート Web サービスをアプリケーションが有効に利用するためには、呼び出される特定のサービスのレジストリー内で検出された情報を使用するよう、そのアプリケーションを作成する必要があります。
UDDI レジストリーから取得される bindingTemplate データは、所定のインターフェース・タイプのインスタンスに関する特定の詳細 (プログラムがサービスとの対話を開始するロケーションを含む) を表します。 呼び出し側のアプリケーションやプログラムは、この情報をキャッシュに入れ、それを使用して、呼び出し側アプリケーションが サービス・インスタンスとの通信を必要とするときに登録済みアドレスにあるサービスとの連絡を行う必要があります。
従来一般的であったリモート・プロシージャー・テクノロジーでは、キャッシング、ハードコーディング、ロケーション情報に関連するタスクがツールによって自動化されていました。 ただし、リモート・サービスが移動し、呼び出し元がその移動を認識していない場合に問題が発生しました。 リモート・サービスの移動には、サーバーのアップグレード、災害時回復、サービス取得、業務名の変更など、さまざまな理由があります。
以前に UDDI レジストリーから取得され キャッシュされていた情報を使用した呼び出しが失敗した場合の適切な動作は、UDDI レジストリーで新しい bindingTemplate 情報を 照会することです。戻されるデータがキャッシュされている情報と異なる場合、サービス呼び出しは、新しい情報を使用して、呼び出しを自動的に再試行します。 この再試行が正常に実行できた場合、キャッシュされている情報が新しい情報に置き換えられます。
このパターンを Web サービスで使用すると、UDDI レジストリーを使用するビジネスで、通信や調整に不要なコストを費やすことなく、多数のパートナーのリカバリーを自動化することができます。例えば、ビジネスが災害時回復サイトを活動化した場合、障害が発生したサイトでサービスの呼び出しを試みた場合、大部分のパートナーからの呼び出しは失敗します。 UDDI 情報をサービスの新規のアドレスで更新すると、 この呼び出しパターンを使用するパートナーは自動的に新規のサービス情報を見つけ、 それ以上の管理アクションを行うことなくリカバリーします。