| Oracle® Fusion Middleware Oracle Service Bus管理者ガイド 11g リリース1(11.1.1.5.0) B61436-03 |
|
 前 |
 次 |
ここででは次のトピックについて説明します。
UDDIは、Universal Description, Discovery, and Integrationの略です。UDDIプロジェクトは、企業間取引を迅速、容易、かつ動的に検索および実施できるようにすることを目指す業界イニシアティブです。
設定されるUDDIレジストリには、企業、企業が提供するサービス、および取引を行なう際に使用する通信標準とインタフェースに関する情報がカタログ化されて格納されます。UDDIレジストリは、サービスの検索、サービスの呼び出し、およびサービスのメタデータ(セキュリティ、トランスポート、またはサービスの品質)の管理のための標準ベースの基盤インフラストラクチャです。UDDIレジストリでは、任意のカテゴリ化によってこれらのメタデータを格納し提供します。これらのカテゴリ化を分類法と呼びます。
UDDIレジストリは、企業でWebサービスを共有するために使用されます。UDDIレジストリを使用することで、企業はこれらの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を提供しています。
図41-1は、Oracle Service BusとUDDIレジストリの統合を示しています。
Oracle Service Busで、Oracle Service RegistryとのWebベース・インタフェースを使用して、レジストリに簡単にアクセスして利用できます。Oracle Service BusをUDDIと組み合せて使用することにより、規格準拠のWebサービスの再利用が促進されます。このように、Oracle Service Busレジストリ・エントリは、複数のドメインで検索、検出、および使用できます。WebサービスとUDDIは一連の規格に基づいて構築されるため、再利用により、テストされ条件を満たしたWebサービスやアプリケーション開発規格の使用が企業全体で促進されます。Webサービスとインタフェースは、タイプ、機能、または分類に応じてカタログ化すると、検索や管理がさらに容易になります。
UDDIは、HTTP、XML、XSD (XMLスキーマ定義)、SOAP、WSDLなど、確立された複数の業界標準に基づいています。UDDI仕様には、Webサービスのレジストリとそのプログラムのインタフェースが記述されています。UDDI自体が、Webサービスのセットです。UDDI仕様は、以下に関する記述と検出をサポートするサービスを定義しています。
ビジネスや組織などのWebサービス提供者
これらのWebサービス提供者が公開するWebサービス
これらのサービスのアクセスと管理に使用できる技術的なインタフェース
UDDIレジストリには、ビジネス・サービスに関するデータとメタデータが格納されます。UDDIレジストリは、他のアプリケーションがWebサービスを検出して使用できるように、Webサービスを分類、カタログ化、および管理する標準ベースのメカニズムを提供します。UDDIは、設計時と実行時の両方において、IT管理者と開発者に次のような利点をもたらします。
サービスに関する情報をレジストリにパブリッシュし、検出用にサービスを分類することで、インフラストラクチャの管理が向上します。UDDIでは、増加し続けるサービスのポートフォリオを分類できるため、サービスを管理しやすくなるだけでなく、コンポーネント間の関係を理解する上でも役立ちます。さらに、バージョン管理をサポートし、依存関係を管理することができます。
UDDIサービスをレジストリからインポートして、Webサービスを呼び出すために必要なパラメータ、および必要な転送プロトコルとセキュリティ・プロトコルを構成できます。
規格準拠のWebサービスの使用およびビジネス・アプリケーションでのビジネス・サービスの開発を促進し、Webサービス開発者にリソース・ライブラリへのリンクを提供します。これにより、開発時間が短縮され、生産性が向上します。また、規格準拠のリソースを共有することで、ビジネス・アプリケーション間の相互運用性の実現の可能性が増加します。
UDDIは、Webサービスの検索と検出のためのユーザー・フレンドリなインタフェースを提供します。
UDDIは、特定のデータ・モデルを使用して、組織とサービスを定義するエンティティを表します。図41-2は、様々なUDDIエンティティ間の関係を示しています。
表41-1に、UDDIエンティティの概要を示します。
表41-1 UDDIエンティティの概要
| UDDIエンティティ | 説明 |
|---|---|
|
ビジネス・エンティティ |
サービスを所有および提供する組織またはグループ。ビジネス・エンティティは、サービス提供者の名前、説明、および連絡先詳細のセット、ビジネス・エンティティの特徴を表すカテゴリ、ユニークな識別子、および検出URLのセットで記述できます。 |
|
ビジネス・サービス |
ビジネス・エンティティが提供する機能またはリソースを表します。ビジネス・サービスは、名前、説明、およびサービスの機能を表す一連のカテゴリで記述されます。UDDIレジストリのビジネス・サービスは、必ずしもWebサービスを表すわけではありません。UDDIレジストリでは、EJBやCORBAなどの任意のサービスを登録できます。 |
|
バインディング・テンプレート |
ビジネス・サービスを呼び出す方法の技術的な詳細を表します。ビジネス・サービスには、1つまたは複数のバインディング・テンプレートを含めることができます。バインディング・テンプレートは、サービス・エンドポイントを表すアクセス・ポイント(エンドポイントURIとプロトコル仕様)、tModelインスタンス情報、およびバインディング・テンプレートの特定の機能を参照するカテゴリで記述されます。 |
|
tModel |
UDDIレジストリでのサービスの表現方法を記述する技術仕様(通常は仕様のポインタ、または仕様ドキュメントに関するメタデータ)を表します。サービスの記述には、名前、説明、概要ドキュメント( |
UDDIで使用されるUDDIデータ・モデルとエンティティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』のUDDIを使用したWebサービスのパブリッシュと検索に関する項を参照してください。
UDDIを使用する利点を明確にする2つのビジネス・シナリオの例を以下に示します。
このシナリオでは、Oracle Service Busを使用してレジストリからサービスをインポートし、Oracle Service Busプロキシ・サービスをそのレジストリにパブリッシュする方法を示します。図41-3を参照してください。
Oracle Service Busに、UDDIレジストリからビジネス・サービスをインポートします。プロキシ・サービスのメッセージ・フローでビジネス・サービスと通信するように、プロキシ・サービスを構成します。プロキシ・サービスを元のレジストリにパブリッシュし、他のドメインで使用できるようにすることが可能です。
このシナリオでは、Oracle Service Busを使用したドメイン間デプロイメントを示します。このシナリオでは、あるドメインのOracle Service Busアプリケーションが実行時に別のドメインのOracle Service Busサービスにアクセスする必要があります。図41-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のバージョン3.0実装に準拠する任意のUDDIレジストリを使用します。Oracle Service Registryは、V 3.0準拠のUDDIレジストリであり、Oracle Service Busで機能することが保証されています。
Oracle Service Bus管理コンソールまたはEclipseを使用して、次のことができます。
1つまたは複数のV3.0準拠のUDDIレジストリを使用するようにOracle Service Busを構成します。
ユーザーがサービスをパブリッシュおよびインポートできるように、レジストリを構成します。
プロキシ・サービス(サービス・タイプは、WSDL、メッセージング、任意のSOAP、および任意のXML)に関する情報をレジストリにパブリッシュします。
レジストリで特定のサービスを検索します。また、使用可能なすべてのサービスのリストを表示します。ビジネス・エンティティ、サービス名のパターン、またはこの両方で検索できます。
レジストリからビジネス・サービスをインポートします。
詳細は、次を参照してください。
Oracle Service BusでUDDIレジストリを使用する際の一般的なワークフローは次のとおりです。
Oracle Enterprise Repositoryをインストールします
Oracle Service RegistryまたはV3.0準拠のUDDIレジストリをインストールします。
|
注意: Oracle Enterprise RepositoryとOracle Service Registryは、Oracle Service Busに含まれていません。これらの製品を使用するには、別途ライセンスを購入する必要があります。Oracle Enterprise Repositoryの詳細は、Oracle Enterprise Repositoryに関するOracle Fusion Middlewareのドキュメントを参照してください。 |
Oracle Service Bus IDEで、19.1.2項「Oracle Enterprise Repositoryからのビジネス・サービスの生成」の説明のとおり、Oracle Enterprise Repositoryのサービス・アセットからビジネス・サービスを生成します。
Oracle Enterprise Repositoryからのビジネス・サービスの生成の一環として、新規UDDIレジストリ・リソースを作成しない場合、サービス・レジストリをOracle Service Bus管理コンソールまたはEclipseで構成します。次を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のUDDIレジストリの操作に関する項
Oracle Service Bus管理コンソールでデフォルト・レジストリを設定します。30.3項「デフォルトUDDI構成の設定」を参照してください。
UDDIレジストリを構成し、Oracle Service Busで使用できるようにしたら、Oracle Service Busプロキシ・サービスをパブリッシュしたり、レジストリからビジネス・サービスをインポートして、プロキシ・サービスで使用したりできます。レジストリの構成は、Oracle Service Bus管理コンソールのアクティブ・セッションで行う必要があります。詳細については、以下を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のUDDIレジストリの操作に関する項。
サービスをOracle Service Registryにパブリッシュする場合、レジストリにアクセスするときの認証用に有効なユーザー名とパスワードが必要です。ユーザー名とパスワードの組合せは、サービス・アカウント・リソースとしてOracle Service Busに実装されます。プロキシ・サービスを構成する前に、サービス・アカウントを定義しておく必要があります。17.1項「サービス・アカウントの指定」を参照してください。
複数のユーザー名とパスワードを使用してレジストリを設定できるため、関連付けられたサービス・アカウントに基づいて、ユーザーごとに異なるパーミッションを使用できます。Oracle Service Registryでは、管理者がユーザー特権を管理し、様々なユーザーのニーズに固有のビューをレジストリに作成します。Oracle Service Busでは、ユーザー・パーミッションによってレジストリ、レジストリの内容、および使用できる機能へのアクセスを管理します。
Oracle Service Bus管理コンソールまたはIDEを使用して、Oracle Service Registryにプロキシ・サービスをパブリッシュできます。これを行うには、Oracle Service Registryにユーザー・アカウントを設定しておく必要があります。UDDIレジストリには、どのプロキシ・サービスでもパブリッシュできます。使用できるサービス・タイプとトランスポートを表41-2に示します。
表41-2 プロキシ・サービスのサービス・タイプとトランスポート
| サービス・タイプ | トランスポート |
|---|---|
|
WSDL |
HTTP、JMS、ローカル、SB、WS |
|
トランスポート・タイプ |
JEJB |
|
任意の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など)を使用して行います。レジストリに初めてパブリッシュするときに、そのレジストリにtModelsをロードする必要があります。これは、Oracle Service Bus管理コンソールまたはEclipse用Oracle Service Busプラグインでパブリッシュの詳細を構成するときに行います。UDDIレジストリにパブリッシュする方法の詳細は、30.7項「UDDIレジストリへのプロキシ・サービスのパブリッシュ」を参照してください。
|
注意: UDDIレジストリからサービスをインポートする際に、このサービスのレジストリへのパブリッシュ元であるOracle Service Busクラスタで、クラスタリングされたサーバーがlocalhostアドレスを使用している場合は、エラーが発生することがあります。特に、インポート中のサービスが、他のリソース(WSDLまたはXSD)を参照するリソース(WSDLまたはXSD)を参照している場合に、このエラーが発生します。クラスタリングされたドメインからUDDIレジストリにサービスをパブリッシュする前に、クラスタ内のいずれのサーバーもサーバー・アドレスにlocalhostを使用していないことを確認します。かわりに、マシン名かIPアドレスを使用します。 |
UDDIにローカル・プロキシ・サービスをパブリッシュできたら、サービスをOracle Service Bus汎用プロキシ・サービスに関連付けることができます。たとえば、具体的なWSDLを使用する複数のローカル・トランスポート・プロキシ・サービスに動的にルーティングする任意のSOAPまたは任意のXML汎用プロキシ・サービスを使用できます。また、ビジネス・サービスがアタッチされたエンタープライズ・サービス・バス(ESB)2の汎用プロキシ・サービスに動的にルーティングするESB 1の汎用プロキシ・サービスを使用することもできます。UDDIレジストリから、ローカル・プロキシ・サービスのWSDLと、任意のSOAPまたは任意のXML汎用プロキシ・サービスのURLを取得できます。WSDLとURLを組み合せることで、汎用プロキシ・サービスを介してローカル・プロキシ・サービスにメッセージを送信するための有効なWSDLが作成されます。
プロキシ・サービスを作成するときに、デフォルトのUDDIレジストリに自動的にパブリッシュするようにプロキシ・サービスを構成できます。まず、デフォルト・レジストリを設定しておく必要があります。30.3項「デフォルトUDDI構成の設定」を参照してください。
個々のプロキシ・サービスの自動パブリッシュ機能を有効にするには、「プロキシ・サービスの作成 - 全般的な構成」ページで「レジストリにパブリッシュ」チェックボックスを選択します。「レジストリにパブリッシュ」オプションを有効にすると、セッションをアクティブ化したときにプロキシ・サービスがデフォルト・レジストリにパブリッシュされます。UDDIレジストリを使用できない場合は、パブリッシュ・アクションが再試行されます。プロキシ・サービスにさらに変更を加えると、再試行がリセットされます。プロキシ・サービスをUDDIレジストリにリパブリッシュすると、UDDIに定義されているプロキシ・サービスの分類がすべて保持されます。
デフォルト・レジストリを変更すると、自動パブリッシュが有効になっているすべてのプロキシ・サービスが新しいデフォルト・レジストリにパブリッシュされます。その後、現在のデフォルト・レジストリとの同期が実行されます。プロキシ・サービスが同期されていない場合、Oracle Service Bus管理コンソールに同期されていないことを示す非同期アイコンが表示されます。
|
注意: デフォルト・レジストリを使用しているときにsbconfig.jarをインポートすると、インポート中にsbconfig.jarのデフォルト・レジストリに同じ論理名が設定されるため、ビジネス・エンティティのデフォルト・レジストリが誤った値になる可能性があります。この場合、自動パブリッシュされたプロキシ・サービスがあると、「自動パブリッシュ状態」ページにエラーが表示されることがあります。これを修正するには、デフォルト・レジストリを再度選択します。 |
UDDIレジストリにあるサービスをOracle Service Busビジネス・サービスとしてインポートできます。WSDLベースのサービスをインポートする場合、複数のUDDIバインディング・テンプレートがあると、Oracle Service Busはバインディング・テンプレートごとに異なるビジネス・サービスを作成します。
Oracle Service BusでUDDIレジストリにアクセスするには、Oracle Service BusのIntegrationAdmin特権またはIntegrationDeployer特権が必要です。Oracle Fusion Middleware Oracle Service Bus開発者ガイドのOracle Service Bus管理コンソールでのロール・ベースのアクセス権に関する説明を参照してください。レジストリ・エントリは、Oracle Service Bus管理コンソールの「システム管理」→「UDDIからインポート」ページにあります。インポート時に、使用可能なレジストリのリストから選択します。レジストリのサービスを検出するには、特定のレジストリに問合せを行う必要があります。レジストリのエントリは一意です。サービスのインポートに使用するレジストリを指定するときに、この問合せを実行します。
UDDIレジストリからの直接インポートにかわるベスト・プラクティスとして、Oracle Enterprise Repositoryに格納されているサービス・アセットからビジネス・サービスを生成することもできます。これがOracle Service Registryのサービスに関連付けられます。
以下のビジネス・サービスの種類をUDDIレジストリからOracle Service Busにインポートできます。
WSDL over HTTPバインディング。複数のUDDIバインディング・テンプレートがある場合、バインディング・テンプレートごとにビジネス・サービスが作成されます。
SOAP over HTTPバインディングまたはXML over HTTPバインディング。
Oracle Service Busサービスとして分類されたサービス。UDDIレジストリにパブリッシュされたOracle Service Busプロキシ・サービスです。この機能は主に、あるドメインのプロキシ・サービスが別のドメインのプロキシ・サービスを検出してそこにルーティングする必要のあるマルチ・ドメインのOracle Service Busデプロイメントで使用されます。
UDDIレジストリからのサービスのインポートの詳細は、次を参照してください。
サービスが更新された場合、最新バージョンを取得するには、レジストリからサービスを再度インポートする必要があります。ただし、「自動インポートの有効化」オプションを選択して、インポートしたサービスをUDDIレジストリと自動的に同期する場合を除きます。このオプションを選択した状態でサービスをインポートすると、UDDIレジストリとの同期が維持されます。41.9項「UDDIを使用したサービスの自動同期」を参照してください。自動同期の実行中にエラーが発生した場合、エラーは「自動インポート・ステータス」ページで報告されます。このページでサービスを手動で更新できます。
サービスにはドキュメントが関連付けられており、これらのドキュメントには他のいくつかのドキュメント(スキーマ、ポリシーなど)が含まれる場合があります。インポートでは、UDDIレジストリはサービスの照会URLに基づいてドキュメントの場所を示します。他のリソースを含むドキュメント、または他のリソースを参照するドキュメントが検索された場合は、参照されているすべての情報と含まれている各項目は個別のリソースとしてOracle Service Busに追加されます。
レジストリのサービスを検索する条件として、ビジネス・エンティティとパターンを使用します。たとえば、サービスを検索する場合、「foo%」と入力できます。Oracle Service Busによってパブリッシュされたサービスには、サービスを識別する固有のtmodelキーがあり、レジストリのサービスを検索するときに使用されます。
ビジネス・エンティティがレジストリの構成の最上位ですが、ビジネス、アプリケーション・タイプなどの他の検索条件を使用できます。認証が必要な場合は、システム管理者からユーザー名とパスワードを入手する必要があります。
関連情報については、次を参照してください。
技術ノートについては、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmを参照してください。『Using WSDL in a UDDI Registry』の注記が重要です。
UDDI製品および開発ツールの情報については、http://uddi.org/solutions.htmlのOASIS UDDIソリューションのページを参照してください。
UDDI仕様(http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm)
この仕様では、以下が定義されています。
アプリケーションがUDDIレジストリに対して情報の照会やパブリッシュを行うために使用するSOAP API
レジストリ・データ・モデルのXMLスキーマとSOAPメッセージ・フォーマット
SOAP APIのWSDL定義
UDDI登録の識別や分類に使用できる様々な識別子とカテゴリ・システムのUDDIレジストリ定義(tModels)
自動インポート機能を使用すると、Oracle Service Registryからインポートしたビジネス・サービスをレジストリ内の対応するサービスと同期できます。30.5項「自動インポート状態の使用」を参照してください。
|
注意: 自動インポートは、Oracle Service Bus管理コンソールでのみ使用でき、Eclipse用Oracle Service Busプラグインでは使用できません。 |
「自動インポート・ステータス」ページでは、次の操作を実行できます。
レジストリからインポートしたサービスを同期できます。レジストリ内のサービスが変更された場合に、Oracle Service Bus管理コンソールのサービスをレジストリ内のサービスと同期できます。次の使用例で、同期のプロセスを説明します。ビジネス・サービスがレジストリからデタッチされていない場合、Oracle Service Busはレジストリ内のサービスへの変更を自動的にサブスクライブします。サービスが変更された場合、リソース・ブラウザとプロジェクト・エクスプローラに非同期アイコンが表示され、サービスを同期する必要があることが示されます。また、「自動インポート・ステータス」ページにこのサービスが表示され、サービスを同期したり、レジストリから切り離したりするためのオプションが提供されます。サービスを同期すると、セマンティクス検証エラーが発生し、「競合の表示」ページにエラーが表示される場合があります。セッションをアクティブ化する前に、これらのエラーを修正する必要があります。
サービスが同期されている場合、サービスはUDDIから取得されるフィールドでのみ更新されます。サービス定義の他のフィールドでは、最後のインポート以降に変更を行うと値が保持されます。
サービスをDomain1からレジストリにパブリッシュするシナリオについて考えてみます(図41-5を参照)。これらのサービスをレジストリからDomain2にインポートします。Domain1のサービスを変更し、変更したサービスをレジストリで更新します。自動インポート機能を使用して、変更したサービスをレジストリと同期することで、Domain2のサービスを更新できます。
Oracle Service Bus管理コンソールのサービスをレジストリ内の対応するサービスと同期する必要がない場合もあります。サービスをレジストリからデタッチすると、同期を回避できます。30.6項「サービスのデタッチ」を参照してください。
Oracle Service Busのサービス定義とUDDIのサービス定義との同期を自動的に維持することができます(双方向)。
Oracle Service Busで作成または変更されたサービスを、自動的にUDDIレジストリにパブリッシュできます。また、ビジネス・サービス定義をUDDIからインポートし、元のサービスがUDDIで変更された場合に自動的に更新できます。あるいは、サービスがUDDIレジストリで変更された場合に同期の承認を求めるようOracle Service Bus管理コンソールまたはEclipse用Oracle Service Busプラグインを構成できます。
レジストリを構成するときに、「自動インポートの有効化」オプションを選択すると、インポートしたサービスがUDDIレジストリと自動的に同期されます。このオプションが有効になっている状態でサービスをインポートすると、UDDIレジストリとの同期が自動的に維持されます。自動同期の実行中にエラーが発生した場合、エラーは「自動インポート・ステータス」ページで報告されます。このページでサービスを手動で更新できます。30.2項「UDDIレジストリの構成」を参照してください。
Oracle Service Busプロキシ・サービスの属性が、UDDIレジストリでサポートされるデータ・モデルにマップされる必要があります。これによって、プロキシ・サービスをUDDIビジネス・エンティティとしてパブリッシュできます。表41-3に、Oracle Service Busプロキシ・サービスのUDDIレジストリ・マッピングに関連する、サービス・タイプ、メッセージ・タイプおよびトランスポートを示します。
表41-3 プロキシ・サービスの属性とサービス・タイプ
| サービス・タイプ | メッセージ・コンテンツ・タイプ | トランスポート |
|---|---|---|
|
WSDL |
SOAPまたはXML (添付ファイル付き) |
HTTP、JMS、ローカル、SB、WS |
|
トランスポート・タイプ |
SOAPまたはXML |
JEJB |
|
任意の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の主要な関連エンティティは次のとおりです。
businessService: サービス全体を表し、サービスの一般的な概要情報が含まれます。
bindingTemplate: サービスにアクセスするための情報が含まれます。
tModels: サービスを分類および定義するための個々の属性を提供します。
図41-6に、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へのマッピングの例を図41-7に示します。
Oracle Service Busプロキシ・サービスの概要情報は、以下のようにビジネス・サービスにマップされます。
名前と説明は、businessService elements要素にマップされます。
Oracle Service Busのプロパティには、特殊なkeyedReferenceGroupがありますuddi:bea.com:attributes:oracleservicebusはキーの一例です。
Oracle Service Busのタイプ(WSDL、SOAP、XML、およびこれらの組合せ)とインスタンスは、サービス・カテゴリのkeyedReferencesにマップされます。uddi:bea.com:servicetypeはキーの一例です。
Oracle Service Busインスタンスは、Oracle Service Bus keyedReferenceGroup(名前 = "OracleServiceBus"、値 = Oracle Service BusインスタンスのURL)内のkeyedReferenceにマップされます。
このインスタンスは、次の2つの目的を果たします。
このサービスが実際にOracle Service Busサーバーによってホストされていることを示します。
Oracle Service BusインスタンスのURLを保持します。
例41-1に、プロキシ・サービスの概要情報のビジネス・サービスへのマッピングを示します。
例41-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プロキシ・サービスの詳細情報は、以下のようにバインディング・テンプレートにマップされます。
エンドポイントURIがアクセス・ポイントにマップされます。
各トランスポートのマーカーtModelがtModelInstanceDetailsにマップされます。
HTTP、JMS、ファイル、FTP、電子メールのトランスポートtModel。JMSトランスポートとファイル・トランスポートをサポートするために、新しいtModelsがOracle Service Busにパッケージ化されています。
Oracle Service Busの詳細構成情報はinstanceParmsにマップされます。
各サービス・タイプのマーカーtModelがtModelInstanceDetailsにマップされます。これには、以下が含まれます。
WSDL、任意のSOAP、任意のXML、およびメッセージングのtModelプロトコル。任意のSOAP、任意のXML、およびメッセージングをサポートする新しいtModelsがOracle Service Busにパッケージ化されています。
WSDLはWSDLからUDDIへのマッピングの技術ノートを使用してマップされます。
メッセージングに含まれる詳細な構成情報はInstanceParmsにマップされます。
例41-2に、詳細情報のバインディング・テンプレートへのマップを示します。
例41-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: *グループのトランスポートのタイプごとに、異なる詳細メタデータのセットが含まれます。表41-3を参照してください。このメタデータは、プロキシ・サービスの転送のコンフィグレーションの詳細を示します。これは、サービスの特徴を示したりサービスを問い合せたりする場合に役立つものではありません。ただし、検出されたサービスにアクセスするときにこのデータが必要になります。メタデータはXML文字列で表され、tModelInstanceInfoのinstanceParmsフィールドに格納されます。
HTTPトランスポートを使用するプロキシ・サービスをマップし、HTTP構成の一部として、必要なクライアント認証やリクエストとレスポンスの文字エンコーディングなどの構成の詳細を記述する必要があるとします。例41-3に、bindingTemplateのtModelInstanceDetailsに必要な内容の一例を示します。
例41-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に指定できる値は、basic、client-certおよびcustom-tokenです。値がcustom-tokenの場合は、token-headerとtoken-typeの2つのプロパティが追加されます。
このリリースでは、Oracle Service Busビジネス・サービス定義でカスタム・トークン認証がサポートされていないため、サービスのインポート元のUDDIでclient-authの値がcustom-tokenである場合、サービスは認証が構成されていないものとしてインポートされます。
表41-4は、各トランスポートで使用するtModelKeyとinstanceParmsをトランスポート・タイプ別にまとめたものです。
表41-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 |
|
|
JEJB |
uddi:uddi.org:transport:jejb |
|
|
JMS |
uddi:uddi.org:transport:jms |
|
|
ローカル |
uddi:uddi.org:transport:local |
なし |
|
MQ |
uddi:bea.org:transport:mq |
|
|
SB |
uddi:bea.org:transport:sb URIスキームは、 |
なし |
|
SFTP |
uddi:bea.org:transport:sftp |
|
|
Tuxedo |
uddi:bea.org:transport:tuxedo |
|
|
WS |
uddi:uddi.org:transport:http WSはHTTP tModelKeyを使用 |
なし |
脚注 1 電子メール・トランスポートのバインディング・テンプレートのaccessPointでは、mailto:name@some_server.comという標準のmailto URL形式を使用します。これは、電子メールを読み込むためのURLであり、Oracle Service Busでプロキシ・サービスに構成したURLとは異なります。サーバー名が不明の場合、このmailto URLをプロキシ・サービス定義から生成することはできません。たとえば、プロキシ・サービスがPOP3サーバーから読み込むように定義されている場合、mailfrom:pop3.bea.comのようなURLで定義されていることが考えられます。このようなプロキシ・サービスをパブリッシュすると、ダミー・サーバーが追加されます。前述の例では、パブリッシュされるURLは、mailto:some_name@some_server.comの形式になります。
表41-5に、各サービス・タイプの概要を示します。
表41-5 サービス・タイプの属性
| サービス | 説明 |
|---|---|
|
WSDL |
WSDLベースのプロキシは、『Using WSDL in a UDDI Registry, version 2.0.2』技術ノート( |
|
任意のSOAP |
|
|
任意のXML |
|
|
メッセージング・サービス |
bindingTemplateの
|
Oracle Service BusとUDDIのマッピングでは、Oracle Service Busのメタデータと関係を表すいくつかの新しい標準tModelsが採用されています。このマッピングをサポートするには、これらのtModelsをUDDIレジストリに登録する必要があります。管理者IDを使用して、Oracle Service RegistryにこれらのtModelsを作成できます。
表41-6から表41-9に、tModelsの概要を示します。
表41-6 CategorizationGroup tModelのタイプ
| 名前 | 説明 |
|---|---|
|
bea-com:servicebus:properties |
Oracle Service Busサービス固有の属性を記述します。データ・モデルでは、ビジネス・サービスの |
表41-7 Categorization tModelのタイプ
| 名前 | 値 | 説明 |
|---|---|---|
|
bea-com:servicebus:serviceType |
WSDL、SOAP、XML、メッセージング・サービス |
Oracle Service Busサービスのサービス・タイプを記述します。 |
|
bea-com:servicebus:instance |
Oracle Service Bus管理コンソールのURL |
サービスをUDDIにパブリッシュするOracle Service Busのサービス・インスタンスを記述します。 |
表41-8 Transport tModelのタイプ
| 名前 | 説明 |
|---|---|
|
uddi-org:jms |
サービスが使用するトランスポート方式を記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。 |
|
uddi-org:file |
サービスの呼出しに使用するトランスポートのタイプを記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。 |
表41-9 Protocol tModelのタイプ
| 名前 | 説明 |
|---|---|
|
bea-com:servicebus:anySoap |
サービスへのアクセスに使用するプロトコルのタイプを記述します。SOAPメッセージを含み、WSDLまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
|
bea-com:servicebus:anyXML |
サービスへのアクセスに使用するプロトコルのタイプを記述します。XMLメッセージを含む、WSDLまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
|
bea-com:servicebus:messagingService |
サービスへのアクセスに使用するプロトコルのタイプを記述します。リクエスト・メッセージが任意のXML(スキーマの有無に関係なく)、テキスト、バイナリ、またはMFLで、レスポンス・メッセージがない、または前述のいずれかであるサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
例41-4は、リクエストがスキーマを使用するXML、レスポンスがテキスト・メッセージであるJMSトランスポートで構成されたメッセージング・サービスのマッピング例です。
例41-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>
