ユーザーズ ガイド

     前  次    目次     
ここから内容

UDDI

この節では、以下のトピックを取り上げます。

 


UDDI、UDDI レジストリ、および Web サービス

UDDI は、Universal Description, Discovery, and Integration の略です。UDDI プロジェクトは、企業間取引を迅速、容易、かつ動的に検索および実施できるようにすることを目指す業界イニシアティブです。

設定される UDDI レジストリには、企業、企業が提供するサービス、および取引を行なう際に使用する通信標準とインタフェースに関する情報がカタログ化されて格納されます。UDDI レジストリは、サービスの検索、サービスの呼び出し、およびサービスのメタデータ (セキュリティ、転送、またはサービスの品質) の管理のための標準ベースの基盤インフラストラクチャです。UDDI レジストリでは、任意のカテゴリ化によってこれらのメタデータを格納し提供します。これらのカテゴリ化を分類法と呼びます。

UDDI レジストリは、企業で Web サービスを共有するために使用されます。UDDI レジストリを使用することで、企業は Web サービスを整理しカタログ化できるため、Web サービスを社内または信頼できる外部パートナと共有し、再利用することができます。UDDI バージョン 3.0 仕様は、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3 (英文) で入手できます。UDDI レジストリは、この仕様に基づいています。この仕様には、UDDI を使用して Web サービスの情報をパブリッシュおよび検索する方法の詳細が記載されています。サービスの実行時の仕様は定義されません (単なるサービスのディレクトリです)。UDDI は、企業のビジネス、ビジネス サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。

レジストリへサービスをパブリッシュするには、サービス タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ エントリには、特定のプロパティが関連付けられ、これらのプロパティ タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。Oracle Service Bus で開発されたプロキシ サービスは、UDDI レジストリにパブリッシュできます。Oracle Service Bus は任意の UDDI バージョン 3.0 に適合したレジストリと相互作用します。Oracle では、Oracle Service Registry を提供しています。

図 7-1 は、Oracle Service Bus と UDDI レジストリの統合を示しています。

図 7-1 Oracle Service Bus と UDDI の統合

Oracle Service Bus と UDDI の統合

Oracle Service Bus で、Oracle Service Registry との Web ベース インタフェースを使用して、レジストリに簡単にアクセスして利用できます。Oracle Service Bus を UDDI と組み合わせて使用することにより、規格準拠の Web サービスの再利用が促進されます。このように、Oracle Service Bus レジストリ エントリは、複数のドメインで検索、検出、および使用できます。Web サービスと UDDI は一連の規格に基づいて構築されるため、再利用により、テストされ条件を満たした Web サービスやアプリケーション開発規格の使用が企業全体で促進されます。Web サービスとインタフェースは、タイプ、機能、または分類に応じてカタログ化すると、検索や管理がさらに容易になります。

UDDI 仕様の基本概念

UDDI は、HTTP、XML、XSD (XML スキーマ定義)、SOAP、WSDL など、確立された複数の業界標準に基づいています。UDDI 仕様には、Web サービスのレジストリとそのプログラムのインタフェースが記述されています。UDDI 自体が、Web サービスのセットです。UDDI 仕様は、以下に関する記述と検出をサポートするサービスを定義しています。

Oracle Service Bus で UDDI レジストリを使用する利点

UDDI レジストリには、ビジネス サービスに関するデータとメタデータが格納されます。UDDI レジストリは、他のアプリケーションが Web サービスを検出して使用できるように、Web サービスを分類、カタログ化、および管理する標準ベースのメカニズムを提供します。UDDI は、設計時と実行時の両方において、IT 管理者と開発者に次のような利点をもたらします。

UDDI エンティティの概要

UDDI は、特定のデータ モデルを使用して、組織とサービスを定義するエンティティを表します。図 7-2 は、さまざまな UDDI エンティティ間の関係を示しています。

図 7-2 組織とサービスを表す UDDI エンティティ

組織とサービスを表す UDDI エンティティ

UDDI エンティティの概要を表 7-1 に示します。

表 7-1 UDDI エンティティの概要
ビジネス エンティティ
サービスを所有および提供する組織またはグループ。ビジネス エンティティは、サービス提供者の名前、説明、および連絡先詳細のセット、ビジネス エンティティの特徴を表すカテゴリ、ユニークな識別子、および検出 URL のセットで記述できます。
ビジネス サービス
ビジネス エンティティが提供する機能またはリソースを表します。ビジネス サービスは、名前、説明、およびサービスの機能を表す一連のカテゴリで記述されます。UDDI レジストリのビジネス サービスは、必ずしも Web サービスを表すわけではありません。UDDI レジストリでは、EJB や CORBA などの任意のサービスを登録できます。
バインディング テンプレート
ビジネス サービスを呼び出す方法の技術的な詳細を表します。ビジネス サービスには、1 つまたは複数のバインディング テンプレートを含めることができます。バインディング テンプレートは、サービス エンドポイントを表すアクセス ポイント (エンドポイント URI とプロトコル仕様)、tModel インスタンス情報、およびバインディング テンプレートの特定の機能を参照するカテゴリで記述されます。
tModel
UDDI レジストリでのサービスの表現方法を記述する技術仕様 (通常は仕様のポインタ、または仕様ドキュメントに関するメタデータ) を表します。サービスの記述には、名前、説明、概要ドキュメント (tModel の目的を示すドキュメントへの参照)、カテゴリ、および (tModel をユニークに識別する) 識別子が含まれます。

UDDI データ モデルと UDDI で使用されるエンティティの詳細については、『AquaLogic Service Registry 3.0 のユーザーズ ガイド』の「AquaLogic Service Registry の紹介」を参照してください。また、『WebLogic Web サービス プログラマーズ ガイド (応用編) 』の「UDDI を使用した Web サービスのパブリッシュと検索」も参照してください

 


Oracle Service Bus と UDDI のビジネス シナリオの例

UDDI を使用する利点を明確にする 2 つのビジネス シナリオの例を以下に示します。

プロキシ サービスと UDDI レジストリの基本的な通信

このシナリオでは、Oracle Service Bus を使用してレジストリからサービスをインポートし、Oracle Service Bus プロキシ サービスをそのレジストリにパブリッシュする方法を示します。図 7-3 を参照してください。

図 7-3 プロキシ サービスと UDDI レジストリの通信

プロキシ サービスと UDDI レジストリの通信

Oracle Service Bus に、UDDI レジストリからビジネス サービスをインポートします。プロキシ サービスのメッセージ フローでビジネス サービスと通信するように、プロキシ サービスをコンフィグレーションします。プロキシ サービスを元のレジストリにパブリッシュし、他のドメインで使用できるようにすることが可能です。

Oracle Service Bus のドメイン間デプロイメント

このシナリオでは、Oracle Service Bus を使用したドメイン間デプロイメントを示します。このシナリオでは、あるドメインの Oracle Service Bus アプリケーションが実行時に別のドメインの Oracle Service Bus サービスにアクセスする必要があります。図 7-4 を参照してください。

図 7-4 ドメイン間デプロイメントのビジネス ケース例

ドメイン間デプロイメントのビジネス ケース例

2 つのドメインに、Oracle Service Bus のインスタンスがそれぞれデプロイされています。ドメイン (D1) に Oracle Service Bus プロキシ サービス (P1) がコンフィグレーションされています。ドメイン (D2) の Oracle Service Bus プロキシ サービス (P2) は、プロキシ サービス (P1) にアクセスする必要があります。ドメインは直接相互通信することができないため、D2 の P2 は D1 の P1 を使用できません。Oracle Service Bus のインポート/エクスポート機能では、別のドメインにあるサービスの実行時検出をサポートしていませんが、UDDI レジストリにサービスをパブリッシュすることで、どのドメインのサービスでも検出し使用できるようになります。P1 が UDDI レジストリに公開されると、実行時に呼び出したり (たとえば、株価を取得する)、他の Oracle Service Bus プロキシ サービスでビジネス サービスとしてインポートしたりできます。

別のドメインからインポートおよびエクスポートする場合は、ネットワーク接続が必要です。プロキシ サービスが別のドメインのリポジトリにあるスキーマを参照するとします。この場合、URL を使用してインポートするために、そのドメインへの HTTP アクセスが必要となります。接続されていない場合、エラー メッセージが返されます。

 


Oracle Service Bus と UDDI の使用

Oracle Service Bus は、UDDI のバージョン 3.0 実装に準拠する任意の UDDI レジストリを使用します。Oracle Service Registry は、V 3.0 準拠の UDDI レジストリであり、Oracle Service Bus で機能することが保証されています。

Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインを使用して、以下を行うことができます。

手順の詳細については、『Oracle Service Bus Console の使い方』の以下のトピックを参照してください

UDDI のワークフロー

Oracle Service Bus で UDDI レジストリを使用する際の一般的なワークフローは次のとおりです。

 


レジストリのコンフィグレーション

UDDI レジストリをコンフィグレーションし、Oracle Service Bus で使用できるようにしたら、Oracle Service Bus プロキシ サービスをパブリッシュしたり、レジストリからビジネス サービスをインポートして、プロキシ サービスで使用したりできます。レジストリのコンフィグレーションは、Oracle Service Bus Console のアクティブ セッションで行う必要があります。詳細については、以下を参照してください。

サービスを Oracle Service Registry にパブリッシュする場合、レジストリにアクセスするときの認証用に有効なユーザ名とパスワードが必要です。ユーザ名とパスワードの組み合わせは、サービス アカウント リソースとして Oracle Service Bus に実装されます。プロキシ サービスをコンフィグレーションする前に、サービス アカウントを定義しておく必要があります。詳細については、『Oracle Service Bus Console の使い方』の「サービス アカウントの指定」を参照してください。

複数のユーザ名とパスワードを使用してレジストリを設定できるため、関連付けられたサービス アカウントに基づいて、ユーザごとに異なるパーミッションを使用できます。Oracle Service Registry では、管理者がユーザ特権を管理し、さまざまなユーザのニーズに固有のビューをレジストリに作成します。Oracle Service Bus では、ユーザ パーミッションによってレジストリ、レジストリの内容、および使用できる機能へのアクセスを管理します。

 


UDDI レジストリへのプロキシ サービスのパブリッシュ

Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインを使用して、Oracle Service Registry にプロキシ サービスをパブリッシュできます。これを行うには、Oracle Service Registry にユーザ アカウントを設定しておく必要があります。UDDI レジストリには、どのプロキシ サービスでもパブリッシュできます。使用できるサービス タイプと転送方式を表 7-2 に示します。

表 7-2 プロキシ サービスのサービス タイプと転送方式 
サービスのタイプ
転送方式
WSDL
HTTP、JMS、ローカル、SB、WS
任意の SOAP
HTTP、JMS、ローカル、SB
任意の XML
電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SB、SFTP、Tuxedo
メッセージング
電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SFTP、Tuxedo

注意 : メッセージング サービスでは、要求と応答のコンテンツが異なる場合や、応答がない場合 (一方向のメッセージ) があります。電子メール、ファイル、SFTP、および FTP は一方向であることが必要です。

サービスをパブリッシュするビジネス エンティティを選択できます。ビジネス エンティティの管理 (エンティティの作成、取り消し、更新、削除など) は、レジストリ ベンダが提供する管理コンソール (Oracle Service Registry の Business Service Console など) を使用して行います。レジストリに初めてパブリッシュするときに、そのレジストリに tModel をロードする必要があります。これは、Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインでパブリッシュの詳細をコンフィグレーションするときに行います。UDDI レジストリにパブリッシュする方法の詳細については、『Oracle Service Bus Console の使い方』の「UDDI レジストリへのプロキシ サービスのパブリッシュ」を参照してください

注意 : UDDI レジストリからサービスをインポートする際に、このサービスのレジストリへのパブリッシュ元である Oracle Service Bus クラスタで、クラスタ化されたサーバが localhost アドレスを使用している場合は、エラーが発生することがあります。特に、インポート中のサービスが、他のリソース (WSDL または XSD) を参照するリソース (WSDL または XSD) を参照している場合に、このエラーが発生します。
注意 : クラスタ化されたドメインから UDDI レジストリにサービスをパブリッシュする前に、クラスタ内のいずれのサーバもサーバ アドレスに localhost を使用していないことを確認します。localhost の代わりに、マシン名か IP アドレスを使用します。

UDDI へのローカル プロキシ サービスのパブリッシュ

UDDI レジストリにローカル プロキシ サービスをパブリッシュできたら、サービスを Oracle Service Bus 汎用プロキシ サービスに関連付けることができます。たとえば、具体的な WSDL を使用する複数のローカル転送プロキシ サービスに動的にルーティングする任意の SOAP または任意の XML 汎用プロキシ サービスを使用できます。また、ビジネス サービスがアタッチされた Enterprise Service Bus (ESB) 2 の汎用プロキシ サービスに動的にルーティングする ESB 1 の汎用プロキシ サービスを使用することもできます。UDDI レジストリから、ローカル プロキシ サービスの WSDL と、任意の SOAP または任意の XML 汎用プロキシ サービスの URL を取得できます。WSDL と URL を組み合わせることで、汎用プロキシ サービスを介してローカル プロキシ サービスにメッセージを送信するための有効な WSDL が作成されます。

 


自動パブリッシュの使用

プロキシ サービスを作成するときに、デフォルトの UDDI レジストリに自動的にパブリッシュするようにプロキシ サービスをコンフィグレーションできます。まず、デフォルト レジストリを設定しておく必要があります。『Oracle Service Bus Console の使い方』の「デフォルト UDDI レジストリの設定」を参照してください。

個々のプロキシ サービスの自動パブリッシュ機能を有効にするには、[プロキシ サービスの作成 - 全般的なコンフィグレーション] ページで [レジストリにパブリッシュ] チェックボックスを選択します。[レジストリにパブリッシュ] オプションを有効にすると、セッションをアクティブ化したときにプロキシ サービスがデフォルト レジストリにパブリッシュされます。UDDI レジストリを使用できない場合は、パブリッシュ アクションが再試行されます。プロキシ サービスにさらに変更を加えると、再試行がリセットされます。プロキシ サービスを UDDI レジストリにリパブリッシュすると、UDDI に定義されているプロキシ サービスの分類がすべて保持されます。

デフォルト レジストリを変更すると、自動パブリッシュが有効になっているすべてのプロキシ サービスが新しいデフォルト レジストリにパブリッシュされます。その後、現在のデフォルト レジストリとの同期が実行されます。プロキシ サービスが同期されていない場合、Oracle Service Bus Console に同期されていないことを示す ドメイン間デプロイメントのビジネス ケース例 アイコンが表示されます

注意 : デフォルト レジストリを使用しているときに sbconfig.jar をインポートすると、インポート中に sbconfig.jar のデフォルト レジストリに同じ論理名が設定されるため、ビジネス エンティティのデフォルト レジストリが誤った値になる可能性があります。この場合、自動パブリッシュされたプロキシ サービスがあると、[自動パブリッシュ状態] ページにエラーが表示されることがあります。これを修正するには、デフォルト レジストリを再度選択します。

 


レジストリからのサービスのインポート

レジストリにあるサービスを Oracle Service Bus ビジネス サービスとしてインポートできます。WSDL ベースのサービスをインポートする場合、複数の UDDI バインディング テンプレートがあると、Oracle Service Bus はバインディング テンプレートごとに異なるビジネス サービスを作成します。

Oracle Service Bus で UDDI レジストリにアクセスするには、Oracle Service Bus の IntegrationAdmin 特権または IntegrationDeployer 特権が必要です。『Oracle Service Bus セキュリティ ガイド』の「Oracle Service Bus Console でのロールベースのアクセス権」を参照してください。レジストリ エントリは、Oracle Service Bus Console の [システムの管理|UDDI からインポート] ページにあります。インポート時に、使用可能なレジストリのリストから選択します。レジストリのサービスを検出するには、特定のレジストリに問い合わせを行う必要があります。レジストリのエントリはユニークです。サービスのインポートに使用するレジストリを指定するときに、このクエリを実行します。

以下のビジネス サービスの種類を UDDI レジストリから Oracle Service Bus にインポートできます。

Oracle Service Bus Console を使用して UDDI レジストリからサービスをインポートする方法については、以下を参照してください。

サービスが更新された場合、最新バージョンを取得するには、レジストリからサービスを再度インポートする必要があります。ただし、[自動インポートを有効化] オプションを選択して、インポートしたサービスを UDDI レジストリと自動的に同期する場合を除きます。このオプションを選択した状態でサービスをインポートすると、UDDI レジストリとの同期が維持されます。「UDDI を使用したサービスの自動同期」を参照してください。自動同期の実行中にエラーが発生した場合、エラーは [自動インポートの状態] ページで報告されます。このページでサービスを手動で更新できます。

サービスにはドキュメントが関連付けられており、これらのドキュメントには他のいくつかのドキュメント (スキーマ、ポリシーなど) が含まれる場合があります。インポートでは、UDDI レジストリはサービスの照会 URL に基づいてドキュメントの場所を示します。他のリソースを含むドキュメント、または他のリソースを参照するドキュメントが検索された場合は、参照されているすべての情報と含まれている各項目は個別のリソースとして Oracle Service Bus に追加されます。

レジストリのサービスを検索する条件として、ビジネス エンティティとパターンを使用します。たとえば、サービスを検索する場合、「foo%」と入力できます。Oracle Service Bus によってパブリッシュされたサービスには、サービスを識別する固有の tmodel キーがあり、レジストリのサービスを検索するときに使用されます。

ビジネス エンティティがレジストリの構成の最上位ですが、ビジネス、アプリケーション タイプなどの他の検索条件を使用できます。認証が必要な場合は、システム管理者からユーザ名とパスワードを入手する必要があります。

関連リファレンス

 


自動インポートの使用

自動インポート機能を使用すると、Oracle Service Registry からインポートしたビジネス サービスをレジストリ内の対応するサービスと同期できます。『Oracle Service Bus Console の使い方』の「 [自動インポートの状態] の使用」を参照してください。

注意 : 自動インポートは、Oracle Service Bus Console でのみ使用できます。Workshop for WebLogic 用 Oracle Service Bus プラグインでは使用できません。

[自動インポートの状態] ページでは、次の操作を実行できます。

同期

レジストリからインポートしたサービスを同期できます。レジストリ内のサービスが変更された場合に、Oracle Service Bus Console のサービスをレジストリ内のサービスと同期できます。次の使用例で、同期のプロセスを説明します。ビジネス サービスがレジストリから切り離されていない場合、Oracle Service Bus はレジストリ内のサービスへの変更を自動的にサブスクライブします。サービスが変更された場合、[リソース ブラウザ] と [プロジェクト エクスプローラ] に同期されていないことを示す ドメイン間デプロイメントのビジネス ケース例 アイコンが表示され、サービスを同期する必要があることが示されます。また、[自動インポートの状態] ページにこのサービスが表示され、サービスを同期したり、レジストリから切り離したりするためのオプションが提供されます。サービスを同期すると、セマンティクス検証エラーが発生し、[衝突の表示] ページにエラーが表示される場合があります。セッションをアクティブ化する前に、これらのエラーを修正する必要があります。

サービスが同期されている場合、サービスは UDDI から取得されるフィールドでのみ更新されます。サービス定義の他のフィールドでは、最後のインポート以降に変更を行うと値が保持されます。

サービスを Domain1 からレジストリにパブリッシュするシナリオについて考えてみます (図 7-5 を参照)。これらのサービスをレジストリから Domain2 にインポートします。Domain1 のサービスを変更し、変更したサービスをレジストリで更新します。自動インポート機能を使用して、変更したサービスをレジストリと同期することで、Domain2 のサービスを更新できます。

図 7-5 ドメイン間デプロイメントのビジネス ケース例

ドメイン間デプロイメントのビジネス ケース例

切り離し

Oracle Service Bus Console のサービスをレジストリ内の対応するサービスと同期する必要がない場合もあります。サービスをレジストリから切り離すと、同期を回避できます。『Oracle Service Bus Console の使い方』の「サービスの切り離し」を参照してください。

 


UDDI を使用したサービスの自動同期

Oracle Service Bus のサービス定義と UDDI のサービス定義との同期を自動的に維持することができます (双方向)。

Oracle Service Bus で作成または変更されたサービスを、自動的に UDDI レジストリにパブリッシュすることができます。また、ビジネス サービス定義を UDDI からインポートし、元のサービスが UDDI で変更された場合に自動的に更新できます。また、UDDI レジストリでサービスが変更されたときに、同期の承認をユーザに求めるメッセージを表示するように、 Oracle Service Bus Console または Workshop for WebLogic 用 Oracle Service Bus プラグインをコンフィグレーションすることもできます。

レジストリをコンフィグレーションするときに、[自動インポートを有効化] オプションを選択すると、インポートしたサービスが UDDI レジストリと自動的に同期されます。このオプションが有効になっている状態でサービスをインポートすると、UDDI レジストリとの同期が自動的に維持されます。自動同期の実行中にエラーが発生した場合、エラーは [自動インポートの状態] ページで報告されます。このページでサービスを手動で更新できます。『Oracle Service Bus Console の使い方』の「UDDI レジストリのコンフィグレーション」を参照してください。

 


Oracle Service Bus プロキシ サービスから UDDI エンティティへのマッピング

Oracle Service Bus プロキシ サービスの属性が、UDDI レジストリでサポートされるデータ モデルにマップされる必要があります。これによって、プロキシ サービスを UDDI ビジネス エンティティとしてパブリッシュできます。次の表は、Oracle Service Bus プロキシ サービスの UDDI レジストリ マッピングに関連する、サービス タイプ、メッセージ タイプ、および転送方式を示します。

表 7-3 プロキシ サービスの属性とサービス タイプ
サービスのタイプ
メッセージのコンテンツ タイプ
転送方式
WSDL
SOAP または XML (添付ファイル付き)
HTTP、JMS、ローカル、SB、WS
任意の SOAP
型なしの SOAP (添付ファイル付き)
HTTP、JMS、ローカル、SB
任意の XML
型なしの XML (添付ファイル付き)
電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SB、SFTP、Tuxedo
メッセージング
バイナリ、テキスト、MFL、XML (スキーマ)
電子メール、ファイル、FTP、HTTP、JMS、ローカル、MQ、SFTP、Tuxedo

注意 : 括弧内の部分はオプションです。メッセージング サービスでは、要求と応答のコンテンツが異なる場合や、応答がない場合 (一方向のメッセージ) があります。電子メール、ファイル、SFTP、および FTP は一方向であることが必要です。

プロキシ サービスは共通の属性を持ちます。また、サービスやサービスのタイプで使用される転送プロトコルによって固有に定義される属性もあります。各プロキシ サービスは、特定のタイプのメッセージを配信できます。

UDDI の主要な関連エンティティは次のとおりです。

図 7-6 は、WSDL ベースのサービスが UDDI ビジネス エンティティにマップされるしくみを示しています。

図 7-6 WSDL サービスから UDDI へのマッピング

WSDL サービスから UDDI へのマッピング

WSDL ベースのプロキシ サービスを UDDI レジストリにパブリッシュするためのベースとして、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm (英文) にある技術ノート「Using WSDL in a UDDI Registry, Version 2.0.2」が使用されています。このドキュメントは、WSDL ベース以外のサービスをパブリッシュするための基準としても使用されます。このドキュメントと、ベースとなる UDDI 仕様は、UDDI エンティティの記述に使用される標準技術モデル (tModels) を記述しています。Oracle Service Bus プロキシ サービスを UDDI レジストリのエンティティとしてパブリッシュするには、Oracle Service Bus 固有の構成要素の一部をサポートする標準の tModel を追加する必要があります。サービスの検索時に、Oracle Service Bus プロキシ サービスのすべての属性 (サービス タイプや転送の詳細など) が役立つわけではありません。これらの属性は、サービスを分類するものではありません。tmodels は、検出されたサービスのコンフィグレーションの詳細です。これらのコンフィグレーションの詳細は、ビジネス サービスのバインディング テンプレートの tmodelinstanceDetails セクションにマップされます。その他の属性は、サービスを個別に識別するものであり、サービスの検索条件として使用できます。これらの属性は、キー付き参照を使用して、バインディング テンプレートの categoryBag の値と共に tModels にマップされます。

Oracle Service Bus から UDDI へのマッピングの例を図 7-7 に示します。

図 7-7 Oracle Service Bus から UDDI へのマッピング

Oracle Service Bus から UDDI へのマッピング

Oracle Service Bus プロキシ サービスの UDDI マッピングの詳細

Oracle Service Bus プロキシ サービスの概要情報は、以下のようにビジネス サービスにマップされます。

コード リスト 7-1 では、プロキシ サービスの概要情報をビジネス サービスにマップしています。

コード リスト 7-1 プロキシ サービスからビジネス サービスへのマッピング例
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
  <keyedReference  tModelKey="uddi:bea.com:servicebus:servicetype"
    keyName="Service Type"
    keyValue="SOAP"/>
  <keyedReference  tModelKey="uddi:bea.com:servicebus:instance"
    keyName="Service Bus Instance"
    keyValue="http://FOO02.amer.bea.com:7001"/>
</keyedReferenceGroup>
注意 : プロキシ サービスをパブリッシュするときに作成される businessService のキーは、パブリッシュする側が割り当てたキー名です。これは、Oracle Service Bus のドメイン名、プロキシ サービスのパス、およびプロキシ サービス名から生成されます。形式は次のようになります。
注意 : uddi:bea.com:servicebus:<domainname>:<path>:<servicename>.
注意 : たとえば、Oracle Service Bus ドメインである AnonESBan に Proxy というプロジェクトがあるとします。このプロジェクトに Accounting というフォルダがあり、このフォルダには PayoutProxy というプロキシ サービスが格納されています。PayoutProxy を UDDI にパブリッシュする場合、businessService は次のキーで作成されます。
注意 : uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy.

Oracle Service Bus プロキシ サービスの詳細情報は、以下のようにバインディング テンプレートにマップされます。

コード リスト 7-2 では、詳細情報をバインディング テンプレートにマップしています。

コード リスト 7-2 バインディング テンプレートへの詳細情報のマッピングの例
<bindingTemplate bindingKey="uddi:" serviceKey="uddi:">
  <accessPoint useType="endPoint">file:///c:/temp/in3</accessPoint>
  <tModelInstanceDetails>
    <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:file">
      <InstanceDetails>
      <InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
        <property name="fileMask" value="*.*"/>
        <property name="sortByArrival" value="false"/> </ALSBInstanceParms>
      </InstanceParms>
      </InstanceDetails>
    </tModelInstanceInfo>
    <tModelInstanceInfo tModelKey="uddi:bea.com:servicebus:protocol:
        messagingservice">
      <InstanceDetails>
      <InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
        <property name="requestType" value="XML"/>
        <property name="RequestSchema" value="http://domain.com:7001
          /sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
        <property name="RequestSchemaElement"
              value="PROCESS_PO"/>
        <property name="responseType" value="None"/></ALSBInstanceParms>
    </InstanceParms>
    </InstanceDetails>
  </tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>

転送属性

uddi:uddi.org:transport: * グループの転送のタイプごとに、異なる詳細メタデータのセットが含まれます 表 7-3 を参照してください。このメタデータは、プロキシ サービスの転送のコンフィグレーションの詳細を示します。これは、サービスの特徴を示したりサービスを問い合わせたりする場合に役立つものではありませんが検出されたサービスにアクセスするときにこのデータが必要になります。メタデータは XML 文字列で表され、tModelInstanceInfoinstanceParms フィールドに格納されます。

HTTP 転送を使用するプロキシ サービスをマップし、HTTP コンフィグレーションの一部として、必要なクライアント認証や要求と応答の文字エンコーディングなどのコンフィグレーションの詳細を記述する必要があるとします。コード リスト 7-3 は、bindingTemplate の tModelInstanceDetails に必要な内容の一例を示しています。

コード リスト 7-3 tModelInstanceDetails の例
<tModelInstanceDetails>
  <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http">
    <instanceDetails>
      <instanceParms>
        <ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
          <property name="client-auth" value="basic"/>
          <property name="request-encoding" value="iso-8859-1"/>
          <property name="response-encoding" value="utf-8"/>
          <property name="Scheme" value="http"/>
        </ALSBInstanceParms>
      </instanceParms>
    </instanceDetails>
  </tModelInstanceInfo>
</tModelInstanceDetails>
注意 : 各転送方式のサービス エンドポイントは、常に bindingTemplate の accessPoint フィールドに格納されます。

認証をコンフィグレーションすると、HTTP 転送属性または HTTPS 転送属性の instanceParms client-auth プロパティが表示されます。client-auth に指定できる値は、basicclient-cert、および custom-token です。値が custom-token の場合は、token-headertoken-type の 2 つのプロパティが追加されます。

このリリースでは、Oracle Service Bus ビジネス サービス定義でカスタム トークン認証がサポートされていないため、サービスのインポート元の UDDI で client-auth の値が custom-token である場合、サービスは認証がコンフィグレーションされていないものとしてインポートされます。

表 7-4 は、各転送方式で使用する tModelKeyinstanceParms を転送タイプ別にまとめたものです。

表 7-4 転送属性 
転送
tModelKey
InstanceParms
電子メール1
uddi:uddi.org:transport:smtp
  • 添付ファイルのサポート [ブール値]
  • 要求エンコーディング
ファイル
uddi:uddi.org:transport:file
  • ファイル マスク
  • 到着順にソート [ブール値]
  • 要求エンコーディング
FTP
uddi:uddi.org:transport:ftp
  • ファイル マスク
  • 到着順にソート [ブール値]
  • 転送モード [テキスト、バイナリ]
  • 要求エンコーディング
HTTP
uddi:uddi.org:transport:http
  • クライアント認証 [なし、基本、クライアント証明書 (HTTP のみ)、およびカスタム トークン]
  • 要求エンコーディング
  • 応答エンコーディング
JMS
uddi:uddi.org:transport:jms
  • 送り先のタイプ [キュー、トピック]
  • 応答が必要、応答 URI
  • 応答メッセージ タイプ [バイト、テキスト]
  • 要求エンコーディング
  • 応答エンコーディング
ローカル
uddi:uddi.org:transport:local
  • なし
MQ
uddi:bea.org:transport:mq
  • 応答が必要
  • 応答 URI
  • 応答相関パターン
SB
uddi:bea.org:transport:sb
URI スキームは、use ssl が false の場合は sbuse ssl が true の場合は sbs
  • なし
SFTP
uddi:bea.org:transport:sftp
  • ファイル マスク
  • 到着順にソート [ブール値]
  • 要求エンコーディング
  • 認証モード
Tuxedo
uddi:bea.org:transport:tuxedo
  • 応答が必要
  • アクセス ポイント ID
  • バッファ タイプ
  • バッファ サブタイプ
  • クラス Jar
  • フィールド テーブル クラス
  • View クラス
WS
uddi:uddi.org:transport:http
WS は HTTP tModelKey を使用
  • なし

1電子メール転送のバインディング テンプレートの accessPoint では、次のような標準の mailto URL 形式を使用します。
mailto:name@some_server.com
これは、電子メールを読み込むための URL であり、Oracle Service Bus でプロキシ サービスにコンフィグレーションした URL とは異なります。サーバ名が不明の場合、この mailto URL をプロキシ サービス定義から生成することはできません。たとえば、プロキシ サービスが POP3 サーバから読み込むように定義されている場合、mailfrom:pop3.bea.com のような URL で定義されていることが考えられます。このようなプロキシ サービスをパブリッシュすると、ダミー サーバが追加されます。上記の例では、パブリッシュされる URL は、mailto:some_name@some_server.com の形式になります。

サービス タイプ属性

各サービス タイプの概要を表 7-5 に示します。

表 7-5 サービス タイプの属性
サービス
説明
WSDL

WSDL ベースのプロキシは、次の URL にある技術ノート「Using WSDL in a UDDI Registry, Version 2.0.2」に基づいて UDDI にマップされる

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm (英文)

任意の SOAP
bindingTemplate の tModelInstanceDetailscategoryBag に含まれる簡易マーカ プロトコル tModel により、任意の SOAP の属性が定義される。
任意の XML
bindingTemplate の tModelInstanceDetailscategoryBag に含まれる簡易マーカ プロトコル tModel により、任意の XML の属性が定義される。これは、新しい詳細な tModel である。
メッセージング サービス
bindingTemplate の tModelInstanceDetails に含まれる簡易マーカ プロトコル tModel により、メッセージング サービスの属性が定義される。これは、新しい詳細な tModel である。他のサービス タイプとは異なり、メッセージング サービスには、要求メッセージと応答メッセージの詳細を示す追加のコンフィグレーション情報が関連付けられている。コンフィグレーション詳細は、tModelInstanceInfo 内の次の tModel 参照の InstanceParms データに、XML データとして表される。
  • 入力メッセージ フォーマット (XML、テキスト、バイナリ、MFL)
  • Oracle Service Bus の入力メッセージ スキーマの URL (入力メッセージが XML の場合は省略可能)
  • Oracle Service Bus の入力メッセージ MFL の URL (入力メッセージが MFL の場合)
  • 出力メッセージ フォーマット (なし、XML、テキスト、バイナリ、MFL)
  • Oracle Service Bus の出力メッセージ スキーマの URL (出力メッセージが XML の場合は省略可能)
  • Oracle Service Bus の出力メッセージ MFL の URL (出力メッセージが MFL の場合)

 


Oracle Service Bus サービスをサポートする標準 tModel

Oracle Service Bus と UDDI のマッピングでは、Oracle Service Bus のメタデータと関係を表すいくつかの新しい標準 tModel が採用されています。このマッピングをサポートするには、これらの tModel を UDDI レジストリに登録する必要があります。管理者 ID を使用して、Oracle Service Registry にこれらの tModel を作成できます。

新しい tModels の概要を表 7-6 に示します。

表 7-6 Oracle Service Bus の tModel
名前
説明
CategorizationGroup tModel のタイプ
bea-com:servicebus:properties
 
Oracle Service Bus サービス固有の属性を記述します。データ モデルでは、ビジネス サービスの categoryBag で使用される。
Categorization tModel のタイプ
bea-com:servicebus:serviceType
WSDL、SOAP、XML、メッセージング サービス
Oracle Service Bus サービスのサービス タイプを記述します。
bea-com:servicebus:instance
Oracle Service Bus Console の URL
サービスを UDDI にパブリッシュする Oracle Service Bus のサービス インスタンスを記述する。
Transport tModel のタイプ
uddi-org:jms
 
サービスが使用する転送方式を記述する。これは、ビジネス サービスのバインディング テンプレートの accessPoint 属性で参照される。
uddi-org:file
 
サービスの呼び出しに使用する転送のタイプを記述する。これは、ビジネス サービスのバインディング テンプレートの accessPoint 属性で参照される。
Protocol tModel のタイプ
bea-com:servicebus:anySoap
 
サービスへのアクセスに使用するプロトコルのタイプを記述する。SOAP メッセージを含み、WSDL またはスキーマで定義されていないサービスを指定する。メッセージ本文のコンテンツは、アプリケーションによって動的に決まる。
bea-com:servicebus:anyXML
 
サービスへのアクセスに使用するプロトコルのタイプを記述する。XML メッセージを含む、WSDL またはスキーマで定義されていないサービスを指定する。メッセージ本文のコンテンツは、アプリケーションによって動的に決まる。
bea-com:servicebus:messagingService
 
サービスへのアクセスに使用するプロトコルのタイプを記述する。要求メッセージが任意の XML (スキーマの有無に関係なく)、テキスト、バイナリ、または MFL で、応答メッセージがない、またはこれらのいずれかであるサービスを指定する。メッセージ本文のコンテンツは、アプリケーションによって動的に決まる。

 


コードリスト 7-4 は、要求がスキーマを使用する XML、応答がテキスト メッセージである JMS 転送でコンフィグレーションされたメッセージング サービスのマッピング例です。

コード リスト 7-4 メッセージング サービスのマッピング例
<businessService 
serviceKey="uddi:bea.com:servicebus:Domain:Project:JMSMessaging"
businessKey="uddi:9cb77770-57fe-11da-9fac-6cc880409fac"
xmlns="urn:uddi-org:api_v3">
<name>JMSMessagingProxy</name>
<bindingTemplates>
<bindingTemplate
bindingKey="uddi:4c401620-5ac0-11da-9faf-6cc880409fac"
serviceKey="uddi:bea.com:servicebus:
Domain:Project:JMSMessaging">
<accessPoint useType="endPoint">
jms://server.com:7001/weblogic.jms.XAConnectionFactory/
ReqQueue
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:jms">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms
xmlns="http://www.bea.com/wli/sb/uddi">
<property name="is-queue" value="true"/>
<property name="request-encoding"
value="iso-8859-1"/>
<property name="response-encoding"
value="utf-8"/>
<property name="response-required"
value="true"/>
<property name="response-URI"
value="jms://server.com:7001/
.jms.XAConnectionFactory/
RespQueue"/>
<property name="response-message-type"
value="Text"/>
<property name="Scheme" value="jms"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo
tModelKey="uddi:bea.com:servicebus:
protocol:messagingservice">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns=
"http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema"
value="http://server.com:7001/
sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO_007"/>
<property name="responseType" value="Text"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="Mixed" />
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://cyberfish.bea.com:7001" />
</keyedReferenceGroup>
</categoryBag>
</businessService>

  ページの先頭       前  次