| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1) E69914-01 |
|
 前 |
 次 |
この章では、UDDI (Universal Description, Discovery, and Integration)レジストリでService Busを使用する方法について説明します。
この章の構成は、次のとおりです。
UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。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は、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。
レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。特定のプロパティは、各レジストリのエントリと関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。Service Busは、バージョン3.0に準拠したUDDIレジストリと相互作用します。
図46-1は、Service BusとUDDIレジストリの統合を示しています。
Service BusのWebベース・インタフェースにより、レジストリにアクセスして簡単に利用できます。Service BusをUDDIと組み合せて使用することにより、規格準拠のWebサービスの再利用が促進されます。この方法で、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サービスを呼び出すために必要なパラメータ、および必要なトランスポート・プロトコルとセキュリティ・プロトコルを構成できます。
UDDIは、規格準拠のWebサービスの使用およびビジネス・アプリケーションでのビジネス・サービスの開発を促進し、Webサービス開発者にリソース・ライブラリへのリンクを提供します。これにより、開発時間が短縮され、生産性が向上します。また、規格準拠のリソースを共有することで、ビジネス・アプリケーション間の相互運用性の実現の可能性が増加します。
UDDIは、Webサービスの検索と検出のためのユーザー・フレンドリなインタフェースを提供します。
UDDIは、特定のデータ・モデルを使用して、組織とサービスを定義するエンティティを表します。図46-2に、様々なUDDIエンティティの間の関係を示します。
表46-1に、UDDIエンティティの概要を示します。
表46-1 UDDIエンティティの概要
| UDDIエンティティ | 説明 |
|---|---|
ビジネス・エンティティ |
サービスを所有および提供する組織またはグループ。ビジネス・エンティティは、サービス提供者の名前、説明、および連絡先詳細のセット、ビジネス・エンティティの特徴を表すカテゴリ、ユニークな識別子、および検出URLのセットで記述できます。 |
ビジネス・サービス |
ビジネス・エンティティが提供する機能またはリソースの説明。ビジネス・サービスは、名前、説明、およびサービスの機能を表す一連のカテゴリで記述されます。UDDIレジストリのビジネス・サービスは、必ずしもWebサービスを表すわけではありません。UDDIレジストリでは、EJBやCORBAなどの任意のサービスを登録できます。 |
バインディング・テンプレート |
ビジネス・サービスを呼び出す方法の技術的な詳細。ビジネス・サービスには、1つまたは複数のバインディング・テンプレートを含めることができます。バインディング・テンプレートは、サービス・エンドポイントを表すアクセス・ポイント(エンドポイントURIとプロトコル仕様)、tModelインスタンス情報、およびバインディング・テンプレートの特定の機能を参照するカテゴリで記述されます。 |
tModel |
UDDIレジストリでのサービスの表現方法を記述する技術仕様(通常は仕様のポインタまたは仕様ドキュメントに関するメタデータ)。サービスの記述には、名前、説明、概要ドキュメント(tModelの目的を示すドキュメントへの参照)、カテゴリおよび(tModelを一意に識別する)識別子が含まれます。 |
Service Busは、UDDIのバージョン3.0実装に準拠する任意のUDDIレジストリを使用します。Service BusをUDDIレジストリとともに使用することによって、次の処理を実行できます。
1つまたは複数のV3.0準拠のUDDIレジストリを使用するようにService Busを構成します。
ユーザーがサービスをパブリッシュおよびインポートできるように、レジストリを構成します。
プロキシ・サービスに関する情報をレジストリにパブリッシュします。
レジストリで特定のサービスを検索します。また、使用可能なすべてのサービスのリストを表示します。ビジネス・エンティティ、サービス名のパターン、またはこの両方で検索できます。
レジストリからビジネス・サービスをインポートします。
Service BusでUDDIレジストリを構成するとき、様々なタイプのUDDIレジストリのアクセスにいくつかのAPIエンドポイントURLを指定します。これらのURLには次のものが含まれます。
照会URL: サービスの検索とインポートで使用される照会APIエンドポイントのURL。
パブリッシュURL: サービスのパブリッシュで使用されるパブリッシュAPIエンドポイントのURL。
セキュリティURL: レジストリへのパブリッシュを行うために必要な認証トークンの取得に使用される、セキュリティAPIエンドポイントのURL。
サブスクリプションURL: レジストリの変更へのサブスクリプション、レジストリのサブスクリプションの作成、インポート・サービスに変更がないかどうかのリスンのために使用される、サブスクリプションAPIエンドポイントのURL。
UDDIレジストリをService Busで使用できるようにするには、UDDIレジストリの接続情報を定義するUDDIレジストリ・リソースを作成します。Service Busプロキシ・サービスのレジストリに対するパブリッシュまたはプロキシ・サービスで使用するビジネス・サービスのレジストリからのインポートを実行できます。リソースでUDDI URLを指定し、セキュリティ情報をオプションで指定します。サービスをほとんどのレジストリにパブリッシュする場合、レジストリにアクセスするときの認証用に有効なユーザー名とパスワードをプロキシ・サービス構成に含める必要があります。
複数のユーザー名とパスワードを使用してレジストリを設定できるため、関連付けられたサービス・アカウントに基づいて、ユーザーごとに異なるパーミッションを使用できます。Service Busでは、ユーザー・パーミッションによってレジストリ、レジストリの内容および使用できる機能へのアクセスを管理します。
プロキシ・サービスがUDDIレジストリにパブリッシュされると、サービスはWSDLドキュメントを使用するWSビジネス・サービスに変換されます。認証の構成がある場合は、これもUDDIにエクスポートされます。WSRMポリシーを使用するWSDLベースのビジネス・サービスがUDDIレジストリからService Busにインポートされる場合は、サービスは自動的にWSトランスポートを使用するように構成されたWSビジネス・サービスとしてインポートされます。
トランスポート・レベルのカスタム認証トークンは、UDDIにパブリッシュされます。client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。「トランスポート属性」で説明されているとおり、client-authに指定可能な値はBASIC、CLIENT-CERTおよびCUSTOM-TOKENです。値がCUSTOM-TOKENの場合は、さらにtoken-headerとtoken-typeという2つのプロパティが必ず存在します。
注意:
Service Busビジネス・サービス定義は、カスタム・トークン認証をサポートしていません。client-authがCUSTOM-TOKENであるUDDIからサービスをインポートする場合、認証の構成が何もないかのようにサービスがインポートされます。
Oracle Service BusコンソールまたはJDeveloperを使用して、プロキシ・サービスをUDDIレジストリにパブリッシュし、他の組織がそのサービスを検索および使用できるようにします。Service Busで開発されたプロキシ・サービスはすべて、UDDIレジストリにパブリッシュできます。パブリッシュするサービスを含めるビジネス・エンティティを選択できます。また、複数のサービスを一度にパブリッシュできます。
これを行うには、UDDIレジストリにユーザー・アカウントを設定しておく必要があります。任意のプロキシ・サービスをUDDIレジストリにパブリッシュできます。また、サービスがパブリッシュされるビジネス・エンティティを選択できます。ビジネス・エンティティの管理(エンティティの作成、取消し、更新、削除など)は、レジストリ・ベンダーが提供する管理コンソールを使用して行います。レジストリに初めてパブリッシュするときに、そのレジストリにtModelsをロードする必要があります。これは、パブリッシュする詳細をコンソールまたはJDeveloperで構成するときに行います。UDDIレジストリにパブリッシュする方法の詳細は、「UDDIレジストリへのプロキシ・サービスのパブリッシュ」を参照してください。
注意:
UDDIレジストリからサービスをインポートする際に、このサービスのレジストリへのパブリッシュ元であるService Busクラスタで、クラスタリングされたサーバーがlocalhostアドレスを使用している場合は、エラーが発生することがあります。特に、インポート中のサービスが、他のリソース(WSDLまたはXSD)を参照するリソース(WSDLまたはXSD)を参照している場合に、このエラーが発生します。
クラスタリングされたドメインからUDDIレジストリにサービスをパブリッシュする前に、クラスタ内のいずれのサーバーもサーバー・アドレスにlocalhostを使用していないことを確認します。かわりに、マシン名かIPアドレスを使用します。
ローカル・プロキシ・サービスをService Bus汎用プロキシ・サービスに関連付けるために、サービスをUDDIレジストリにパブリッシュできます。たとえば、具体的なWSDLファイルを使用する複数のローカル・トランスポート・プロキシ・サービスに動的にルーティングする任意のSOAPまたは任意のXML汎用プロキシ・サービスを使用できます。また、ビジネス・サービスがアタッチされたService Bus2の汎用プロキシ・サービスに動的にルーティングするService Bus1の汎用プロキシ・サービスを使用することもできます。UDDIレジストリから、ローカル・プロキシ・サービスのWSDLファイルと、任意のSOAPまたは任意のXML汎用プロキシ・サービスのURLを取得できます。WSDLファイルとURLを組み合せることで、汎用プロキシ・サービスを介してローカル・プロキシ・サービスにメッセージを送信するための有効なWSDLファイルが作成されます。
UDDIレジストリにあるサービスをService Busビジネス・サービスとしてインポートできます。WSDLベースのサービスをインポートする場合、複数のUDDIバインディング・テンプレートがあると、Service Busはバインディング・テンプレートごとに異なるビジネス・サービスを作成します。
Service BusでUDDIレジストリへのアクセスに必要なセキュリティ・ロールの詳細は、『Oracle Service Busの管理』のOracle Service Busにおけるロール・ベースのアクセスに関する項を参照してください。インポート時に、使用可能なレジストリのリストから選択します。Oracle Service Busコンソールで、UDDIフォルダ定義エディタにレジストリの全リストを表示できます。レジストリからインポートすると、そのレジストリを照会してサービスを検出できます。JDeveloperで、使用可能なレジストリを「リソース」ウィンドウに表示し、リストを参照してサービスを検出できます。レジストリのエントリは一意です。
次のビジネス・サービスの種類をUDDIレジストリからService Busにインポートできます。
WSDL over HTTPバインディング。複数のUDDIバインディング・テンプレートがある場合、バインディング・テンプレートごとにビジネス・サービスが作成されます。
SOAP over HTTPバインディングまたはXML over HTTPバインディング。
Service Busサービスとして分類されたサービス。UDDIレジストリにパブリッシュされたプロキシ・サービスです。この機能は主に、あるドメインのプロキシ・サービスが別のドメインのプロキシ・サービスを検出してそこにルーティングする必要のあるマルチドメインのService Busデプロイメントで使用されます。
サービスにはドキュメントが関連付けられており、これらのドキュメントには他のいくつかのドキュメント(スキーマ、ポリシーなど)が含まれる場合があります。インポートでは、UDDIレジストリはサービスの照会URLに基づいてドキュメントの場所を示します。他のリソースを含むドキュメントまたは他のリソースを参照するドキュメントが検索された場合は、参照されているすべての情報と含まれている各項目は個別のリソースとしてService Busに追加されます。
Service Busのサービス定義とUDDIのサービス定義との同期を自動的に維持できます(双方向)。Service Busで作成または変更されたサービスを、自動的にUDDIレジストリにパブリッシュできます。また、ビジネス・サービス定義をUDDIからインポートし、元のサービスがUDDIで変更された場合に自動的に更新できます。また、サービスがUDDIレジストリで変更された場合に同期の承認を求めるメッセージを表示するよう、Oracle Service BusコンソールまたはJDeveloperを構成できます。
Oracle Service Busコンソールでプロキシ・サービスを構成するときに、デフォルトのUDDIレジストリに自動的にパブリッシュするようにプロキシ・サービスを構成できます。この機能はJDeveloperでは使用できません。まず、デフォルト・レジストリを設定し、デフォルト・レジストリに自動的にパブリッシュするようにプロキシ・サービスを構成する必要があります。これらの変更をアクティブ化すると、プロキシ・サービスはデフォルト・レジストリにパブリッシュされます。UDDIレジストリを使用できない場合は、パブリッシュ・アクションが再試行されます。プロキシ・サービスにさらに変更を加えると、再試行がリセットされます。プロキシ・サービスをUDDIレジストリにリパブリッシュすると、UDDIに定義されているプロキシ・サービスの分類がすべて保持されます。
手順は、「デフォルトのUDDIレジストリ・リソースを指定する方法」および「UDDIレジストリにプロキシ・サービスを自動的にパブリッシュする方法」を参照してください。
デフォルト・レジストリを変更すると、自動パブリッシュが有効になっているすべてのプロキシ・サービスが新しいデフォルト・レジストリにパブリッシュされます。その後、現在のデフォルト・レジストリとの同期が実行されます。プロキシ・サービスが同期されていない場合、Oracle Service Busコンソールに同期されていないことを示す非同期アイコンが表示されます。
注意:
デフォルト・レジストリを使用しているときに、インポート中に同じ論理名でデフォルト・レジストリが設定された構成JARファイルをインポートすると、ビジネス・エンティティのデフォルト・レジストリが誤った値になる可能性があります。この場合、自動パブリッシュされたプロキシ・サービスがあると、「自動パブリッシュ・ステータス」ページにエラーが表示されることがあります。これを修正するには、デフォルト・レジストリを再度選択します。
プロキシ・サービスで自動パブリッシュが有効になっている場合、Oracle Service Busコンソールの「自動パブリッシュ・ステータス」ページを使用して、サービスの同期プロセスを表示して管理できます。このページには、パブリッシュされるプロキシ・サービスおよびそのステータスが表示されます。エラーのためにサービスがレジストリを自動的にパブリッシュできない場合、このページから再試行できます。
パブリッシュされた後にプロキシ・サービスが変更された場合、Oracle Service Busコンソールの管理機能を使用して変更を同期化できます。自動パブリッシュが有効になっている場合、Service Busは、レジストリのサービスにすべての変更を自動的にパブリッシュします。また、「自動パブリッシュ・ステータス」ダイアログにこのサービスが表示され、レジストリにサービスをパブリッシュするためのオプションが提供されます。
自動インポート機能を使用すると、UDDIレジストリからインポートしたビジネス・サービスをレジストリ内の対応するサービスと同期できます。手順は、「インポートしたサービスを自動的に同期する方法」を参照してください。
注意:
自動インポートは、Oracle Service Busコンソールでのみ使用できます。JDeveloperでは使用できません。
サービスが更新された場合、UDDIレジストリ・リソースで自動インポートが有効になっていないかぎりにおいてはレジストリからサービスを再度インポートして最新バージョンを取得する必要があります。「自動インポートの有効化」オプションが選択されている場合、インポートされているサービスのUDDIレジストリとの同期が自動的に維持されます。自動同期の実行中に発生したエラーは、「自動インポート・ステータス」ページで報告されます。このページでサービスを手動で同期できます。
自動インポートが有効になっている場合、「自動インポート・ステータス」ページを使用して、サービスの同期プロセスを表示して管理できます。サービスをレジストリと同期するかまたはサービスのリンクを解除してこのページでの同期を回避できます。
UDDIレジストリからインポートしたサービスがレジストリの変更で変更された場合、Oracle Service Busコンソールの管理機能を使用してコンソールのサービスをレジストリ内のサービスと同期できます。自動インポートが有効になっていて、ビジネス・サービスがレジストリからリンク解除されていない場合、Service Busはレジストリ内のサービスへの変更を自動的にサブスクライブします。「自動インポート・ステータス」ダイアログにこのサービスが表示され、サービスを同期したり、レジストリからリンク解除したりするためのオプションが提供されます。サービスを同期すると、セマンティック検証エラーが発生し、セッションのアクティブ化が妨げられる場合があります。この場合、リンクを解除することをお薦めします。
サービスが同期されている場合、サービスはUDDIから取得されるフィールドでのみ更新されます。サービス定義の他のフィールドでは、最後のインポート以降に変更を行うと値が保持されます。たとえば、ポリシー構成などがあります。
サービスをDomain1からレジストリにパブリッシュするシナリオについて考えてみます。これらのサービスをレジストリからDomain2にインポートします(図46-3参照)。Domain1のサービスを変更し、変更したサービスをレジストリで更新します。自動インポート機能を使用して、変更したサービスをレジストリと同期することで、Domain2のサービスを更新できます。
Oracle Service Busコンソールのサービスをレジストリ内の対応するサービスと同期する必要がない場合もあります。サービスをレジストリからリンク解除すると、同期を回避できます。「インポートされたサービスをUDDIレジストリからリンク解除する方法」を参照してください。
次のドキュメントには、UDDIの詳細が記載されています。
技術ノートについては、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)
Service BusでUDDIレジストリにアクセスするためには、UDDIレジストリを記述する、UDDIレジストリ・リソースを作成して構成する必要があります。レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ・エントリには、特定のプロパティが関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。
UDDIレジストリのフォルダ定義エディタには、現在のセッションで作成したUDDIレジストリ・リソースがすべてリストされます。このページを使用して、定義したUDDIレジストリ・リソースをすばやく検索してアクセスします。
コンソールでUDDIレジストリを表示するには:
UDDIレジストリ・リソースを作成するとき、URL、セキュリティ資格証明、サービスを自動的に同期するかどうかなど、リモート・サーバーの接続情報を指定します。レジストリを作成したら、Service Busプロキシ・サービスのレジストリに対するパブリッシュまたはプロキシ・サービスで使用するビジネス・サービスのレジストリからのインポートを実行できます。
UDDIレジストリ・リソースを作成するには:
次のいずれかを行います:
JDeveloperを使用している場合、「アプリケーション・リソース」パネルを開き、「Service Busシステム・リソース」を右クリックして、「新規」を指し、「UDDIレジストリ」を選択します。
注意:
プロジェクトに直接UDDIレジストリ・リソースを作成してプロジェクト・レベルのリソースにするには、プロジェクトを右クリックし、「新規」を指し、「UDDIレジストリ」を選択します。
Oracle Service Busコンソールを使用している場合、「システム」プロジェクトを展開し、「UDDI」を右クリックし、「作成」を指し、「UDDIレジストリの作成」を選択します。
「UDDIレジストリの作成」ダイアログが表示されます。
リソースの名前と必要に応じて説明を入力し、「終了」または「作成」をクリックします。
UDDIレジストリ定義エディタが表示され、Oracle Service Busコンソールの「システム」フォルダまたはJDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダに新しいUDDIレジストリ・リソースが表示されます。
UDDIレジストリの照会URL、パブリッシュURL、サブスクリプションURLおよびセキュリティURLを入力します。
詳細は、「UDDIレジストリのURL」を参照してください。
Service Bus tModelsをレジストリにパブリッシュするには、「T-Modelsをレジストリにロード」を選択します。
このフィールドは、プロキシ・サービスをこのレジストリにパブリッシュする場合のみ必要です。
サービスをUDDIレジストリと自動的に同期するには、「自動インポートの有効化」を選択します。
このオプションを選択した状態でサービスをインポートすると、UDDIレジストリとの同期が維持されます。
注意:
自動同期はバックグラウンド・プロセスです。セッションの「取消し」機能を使用して取り消すことはできません。自動同期の変更を元に戻しても、永続的ではありません(次回の同期サイクルでサービスが再同期されるため)。インポートされたサービスがUDDIレジストリと同期されないようにするには、サービスを切り離してレジストリからの更新を避けます。「インポートされたサービスをUDDIレジストリからリンク解除する方法」を参照してください。
UDDIレジストリ・コンソールにアクセスするためにユーザー名およびパスワードが必要な場合、「ユーザー名」フィールドにユーザー名を入力して、関連するパスワードを「パスワード」および「新規パスワードの確認」フィールドに入力します。
「保存」をクリックします。
次のいずれかを実行してUDDIのURLをテストします。
JDeveloperを使用している場合、「接続のテスト」をクリックします。
Oracle Service Busコンソールを使用している場合、「UDDIレジストリをテストおよび検証します」をクリックします。
Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。
JDeveloperでは、既存のUDDIレジストリ接続からUDDIレジストリ・リソースを作成できます。逆に、UDDIレジストリ・リソースからUDDI登録の接続を作成することも可能です。
UDDI接続からUDDIレジストリ・リソースを作成するには:
UDDIレジストリ・リソースを作成すると、その説明およびUDDIプロパティのほとんどを変更できます。
UDDIレジストリ・リソースを編集するには:
編集するリソースを含むプロジェクトとフォルダを開きます。これは次の場所のいずれかになります。
JDeveloperの「アプリケーション・リソース」パネルの「Service Busシステム・リソース」フォルダ。
JDeveloperでは、UDDIレジストリ・リソースがアプリケーション・ナビゲータで配置されているService Busのプロジェクトまたはフォルダ。
Oracle Service Busコンソールでは、システム・プロジェクトのUDDIフォルダ。
UDDIレジストリ名を右クリックし、「開く」を選択します。
UDDIレジストリ定義エディタが表示されます。
フィールドの変更については、「UDDIレジストリ・リソースの作成方法」で説明しています。これらのフィールドについては、オンライン・ヘルプでさらに詳細に説明しています。
変更が終了したら、「保存」をクリックします。
次のいずれかを実行してUDDIのURLをテストします。
JDeveloperを使用している場合、「接続のテスト」をクリックします。
Oracle Service Busコンソールを使用している場合、「UDDIレジストリをテストおよび検証します」をクリックします。
Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。
ドメインのデフォルトのレジストリとしてすでに構成されてアクティブ化されているUDDIレジストリのいずれかを指定できます。自動パブリッシュ機能を使用するには、デフォルト・レジストリを設定しておく必要があります。詳細は、「プロキシ・サービスの自動パブリッシュ」を参照してください。
デフォルトのUDDIレジストリ・リソースを指定するには:
JDeveloperでは、UDDIレジストリにあるサービスからビジネス・サービスを作成できます。単にService Busプロジェクトにサービスをダウンロードすることも可能です。
JDeveloperでUDDIレジストリを操作する場合、JDeveloper UDDIレジストリ接続およびService Bus UDDIレジストリ・リソースを作成する必要があります。レジストリ接続を使用すると、「リソース」ウィンドウおよび様々なセレクタ・ダイアログでレジストリにアクセスおよび参照でき、そこでプロジェクトのアーティファクトを参照および選択できます。レジストリ・リソースによって、レジストリのAPIエンドポイントURLおよびセキュリティ情報が指定されます。
JDeveloperの「新規ギャラリ」を使用してUDDIレジストリ接続を作成するかまたは「アプリケーション・リソース」パネルで既存のUDDIレジストリ・リソースから接続を作成できます。次の手順では、リソースから接続を作成する方法を説明します。
始める前に:
JDeveloperでレジストリを操作する前に、そのレジストリのアカウントを入手しておく必要があります。Service Busは、バージョン3.0仕様に準拠するUDDIレジストリとの相互運用性をサポートしています。
JDeveloperでUDDI接続を作成するには:
JDeveloperでは、UDDIレジストリに格納されているサービスからビジネス・サービスを作成できます。JDeveloperからはUDDIレジストリにサービスをパブリッシュできません。次の手順を実行すると、現在のアプリケーションで指定した場所にビジネス・サービスが作成されます。
UDDIレジストリ・サービスからビジネス・サービスを作成するには:
Oracle Service Busコンソールには、UDDIレジストリからパブリッシュおよびインポートするためのオプション(手動手順および自動プロセスを含む)がいくつか用意されています。
注意:
レジストリからサービスをアンパブリッシュする必要がある場合、これはUDDIレジストリから行います。
始める前に:
レジストリからのパブリッシュまたはインポートを実行する前に、そのレジストリのアカウントを入手しておく必要があります。Service Busは、バージョン3.0仕様に準拠するUDDIレジストリとの相互運用性をサポートしています。
UDDIレジストリにService Busプロキシ・サービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。サービスをパブリッシュするとき、必要に応じて、サービスがパブリッシュされるビジネス・エンティティを選択できます。また、同時に複数のサービスをパブリッシュできます。Oracle Service Busコンソールからのみパブリッシュできます。JDeveloperからはパブリッシュできません。
注意:
サービスが正常にパブリッシュされていない場合は、再度パブリッシュすることができます。サービスを再度パブリッシュするには、「自動パブリッシュ・ステータス」ページでサービスを選択し、「パブリッシュ」をクリックします。
「レジストリにパブリッシュ」オプションが有効になっている場合、プロキシ・サービスは作成または編集直後にパブリッシュされ、セッションがアクティブ化されます。「レジストリにパブリッシュ」オプションは、ローカル・トランスポートを使用しているサービス以外のすべてのプロキシ・サービスで利用できます。
セッションで構成したデフォルトのUDDIレジストリにプロキシ・サービスを自動的にパブリッシュできます。自動パブリッシュを有効にするためには、サービスの自動パブリッシュを有効にし、サービスのパブリッシュ先のUDDIレジストリをService Busが認識できるようにデフォルトのUDDIレジストリを定義する必要があります。
UDDIレジストリにプロキシ・サービスを自動的にパブリッシュするには:
次のビジネス・サービスの種類をUDDIレジストリからOracle Service Busコンソールにインポートできます。
HTTPトランスポートを介したWSDLサービス。
UDDIレジストリにパブリッシュされるService Busプロキシ・サービス。この機能は主に、あるドメインのプロキシ・サービスが別のドメインのプロキシ・サービスを検出してそこにルーティングする必要のあるマルチドメインのService Busデプロイメントで使用されます。
UDDIレジストリから同時に複数のリソースをインポートできます。
始める前に:
UDDIレジストリにアクセスしてそこからリソースをインポートするには、Service BusにUDDIリソースを作成する必要があります。詳細は、「UDDIレジストリ・リソースの作成方法」を参照してください。
コンソールでUDDIレジストリからリソースをインポートするには:
「自動インポート・ステータス」ページでは、サービスに対する変更内容をレジストリの内容と同期できます。自動インポートが有効になっている間にインポートされたサービスのUDDIレジストリとの同期が維持されます。レジストリ内のサービスに変更が加えられると、Service Busにより変更が通知されて「自動インポート・ステータス」ページに同期していないすべてのサービスが表示されます。
UDDIレジストリの自動インポートを有効にするには:
自動インポートが有効になっていて、自動同期の実行中にエラーが発生した場合、エラーは「自動インポート・ステータス」ページで報告されます。エラーを修正した後、サービスを手動で同期できます。
サービスをUDDIレジストリと同期するには:
UDDIを使用する利点を明確にする2つのビジネス・シナリオの例を次に示します。
このシナリオでは、Service Busを使用してレジストリからサービスをインポートし、Service Busプロキシ・サービスをそのレジストリにパブリッシュする方法を示します。図46-4を参照してください。
Service Busに、UDDIレジストリからビジネス・サービスをインポートします。パイプラインでビジネス・サービスと通信するように、プロキシ・サービスを構成します。プロキシ・サービスを元のレジストリにパブリッシュし、他のドメインで使用できるようにすることが可能です。
このシナリオでは、Service Busを使用したドメイン間デプロイメントを示します。このシナリオでは、あるドメインのService Busアプリケーションが実行時に別のドメインのService Busサービスにアクセスする必要があります。図46-5を参照してください。
2つのドメインに、Service Busのインスタンスがそれぞれデプロイされています。ドメイン(D1)にService Busプロキシ・サービス(P1)が構成されています。ドメイン(D2)のService Busプロキシ・サービス(P2)は、プロキシ・サービス(P1)にアクセスする必要があります。ドメインは直接相互通信することができないため、D2のP2はD1のP1を使用できません。Service Busのインポート/エクスポート機能では、異なるドメインにあるサービスの実行時検出をサポートしていませんが、UDDIレジストリにサービスをパブリッシュすることで、どのドメインのサービスでも検出し使用できるようになります。P1がUDDIレジストリで使用できるようになると、実行時に呼び出したり(たとえば、株価を取得する)、他のService Busプロキシ・サービスでビジネス・サービスとしてインポートしたりできます。
別のドメインからインポートおよびエクスポートする場合は、ネットワーク接続が必要です。プロキシ・サービスが別のドメインのリポジトリにあるスキーマを参照するとします。この場合、URLを使用してインポートするために、そのドメインへのHTTPアクセスが必要となります。接続されていない場合、エラー・メッセージが返されます。
Service Busプロキシ・サービスの属性が、UDDIレジストリでサポートされるデータ・モデルにマップされる必要があります。これによって、プロキシ・サービスをUDDIビジネス・エンティティとしてパブリッシュできます。表46-2に、プロキシ・サービスのUDDIレジストリ・マッピングに関連する、サービス・タイプ、メッセージ・タイプおよびトランスポートを示します。
表46-2 プロキシ・サービスの属性とサービス・タイプ
| サービス・タイプ | メッセージ・コンテンツ・タイプ | トランスポート |
|---|---|---|
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: サービスを分類および定義するための個々の属性を提供します。
図46-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)についての記載があります。Service Busプロキシ・サービスをUDDIレジストリのエンティティとしてパブリッシュするには、Service Bus固有の構成要素の一部をサポートする標準のtModelを追加する必要があります。サービスの検索時に、プロキシ・サービスのすべての属性(サービス・タイプやトランスポートの詳細など)が役立つわけではありません。これらの属性は、サービスを分類するものではありません。tModelsは、検出されたサービスの構成の詳細です。これらの構成の詳細は、ビジネス・サービスのバインディング・テンプレートのtmodelinstanceDetailsセクションにマップされます。その他の属性は、サービスを個別に識別するものであり、サービスの検索条件として使用できます。これらの属性は、キー付き参照を使用して、バインディング・テンプレートのcategoryBagの値とともにtModelsにマップされます。
Service BusからUDDIへのマッピングの例を図46-7に示します。
Service Busプロキシ・サービスの概要情報は、次のようにビジネス・サービスにマップされます。
名前と説明は、businessService要素にマップされます。
Service Busのプロパティには、特殊なkeyedReferenceGroupがあります。uddi:bea.com:attributes:oracleservicebusはキーの一例です。
Service Busのタイプ(WSDL、SOAP、XMLおよびこれらの組合せ)とインスタンスは、サービス・カテゴリのkeyedReferencesにマップされます。uddi:bea.com:servicetypeはキーの一例です。
Service Busインスタンスは、Service Bus keyedReferenceGroup(名前 = "OracleServiceBus"、値 = Service BusインスタンスのURL)内のkeyedReferenceにマップされます。
このインスタンスは、次の2つの目的を果たします。
このサービスが実際にService Busサーバーによってホストされていることを示します。
Service BusインスタンスのURLを保持します。
次の例は、上位プロキシ・サービス情報からのビジネス・サービスへのマッピングを示します。
例 - プロキシ・サービスからビジネス・サービスへのマッピング例
<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のキーは、パブリッシュする側が割り当てたキー名です。これは、Service Busのドメイン名、プロキシ・サービスのパスおよびプロキシ・サービス名から生成されます。形式は次のようになります。
uddi:bea.com:servicebus:<domainname>:<path>:<servicename>
たとえば、Service BusドメインであるAnonESBanにProxyというプロジェクトがあるとします。このプロジェクトにAccountingというフォルダがあり、このフォルダにはPayoutProxyというプロキシ・サービスが格納されています。PayoutProxyをUDDIにパブリッシュする場合、businessServiceは次のキーで作成されます。
uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy
Service Busプロキシ・サービスの詳細情報は、次のようにバインディング・テンプレートにマップされます。
エンドポイントURIがアクセス・ポイントにマップされます。
各トランスポートのマーカーtModelがtModelInstanceDetailsにマップされます。
HTTP、JMS、ファイル、FTP、電子メールのトランスポートtModel。JMSトランスポートとファイル・トランスポートをサポートするために、新しいtModelsがService Busにパッケージ化されています。
Service Busの詳細構成情報はinstanceParmsにマップされます。
各サービス・タイプのマーカーtModelがtModelInstanceDetailsにマップされます。次のものが必要となります。
WSDL、任意のSOAP、任意のXML、およびメッセージングのtModelプロトコル。任意のSOAP、任意のXMLおよびメッセージングをサポートする新しいtModelsがService Busにパッケージ化されています。
WSDLはWSDLからUDDIへのマッピングの技術ノートを使用してマップされます。
メッセージングに含まれる詳細な構成情報はInstanceParmsにマップされます。
次の例は、バインディング・テンプレートへのマッピングの詳細情報を示します。
例 - 詳細のバインディング・テンプレートへのマッピング例
<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: *グループのトランスポートのタイプごとに、異なる詳細メタデータのセットが含まれます。表46-2を参照してください。このメタデータは、プロキシ・サービスのトランスポートの構成の詳細を示します。これは、サービスの特徴を示したりサービスを問い合せたりする場合に役立つものではありません。ただし、検出されたサービスにアクセスするときにこのデータが必要になります。メタデータはXML文字列で表され、tModelInstanceInfoのinstanceParmsフィールドに格納されます。
HTTPトランスポートを使用するプロキシ・サービスをマップし、HTTP構成の一部として、必要なクライアント認証やリクエストとレスポンスの文字エンコーディングなどの構成の詳細を記述する必要があるとします。次の例では、bindingTemplateのtModelInstanceDetailsに必要な内容の一例を示します。
例 - 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フィールドに格納されます。
client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。client-authに指定できる値は、basic、client-certおよびcustom-tokenです。値がcustom-tokenの場合は、token-headerとtoken-typeの2つのプロパティが追加されます。
このリリースでは、Service Busビジネス・サービス定義でカスタム・トークン認証がサポートされていないため、サービスのインポート元のUDDIでclient-authの値がcustom-tokenである場合、サービスは認証が構成されていないものとしてインポートされます。
表46-3は、各トランスポートで使用するtModelKeyとinstanceParmsをトランスポート・タイプ別にまとめたものです。
表46-3 トランスポート属性
| トランスポート | 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を使用 |
なし |
表46-4に、各サービス・タイプの概要を示します。
表46-4 サービス・タイプの属性
| サービス | 説明 |
|---|---|
WSDL |
WSDLベースのプロキシは、『Using WSDL in a UDDI Registry, version 2.0.2』技術ノート(URLは |
任意のSOAP |
|
任意のXML |
|
メッセージング・サービス |
bindingTemplateの
|
Service BusとUDDIのマッピングでは、Service Busのメタデータと関係を表すいくつかの標準tModelsが採用されています。このマッピングをサポートするには、これらのtModelsをUDDIレジストリに登録する必要があります。管理者IDを使用して、UDDIレジストリにtModelを作成できます。
表46-5 CategorizationGroup tModelのタイプ
| 名前 | 説明 |
|---|---|
bea-com:servicebus:properties |
Service Busサービス固有の属性を記述します。データ・モデルでは、ビジネス・サービスの |
表46-6 Categorization tModelのタイプ
| 名前 | 値 | 説明 |
|---|---|---|
bea-com:servicebus:serviceType |
WSDL、SOAP、XML、メッセージング・サービス |
Service Busサービスのサービス・タイプを記述します。 |
bea-com:servicebus:instance |
Service Bus管理コンソールのURL |
サービスをUDDIにパブリッシュするService Busのサービス・インスタンスを記述します。 |
表46-7 Transport tModelのタイプ
| 名前 | 説明 |
|---|---|
uddi-org:jms |
サービスが使用するトランスポート方式を記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。 |
uddi-org:file |
サービスの呼出しに使用するトランスポートのタイプを記述します。これは、ビジネス・サービスのバインディング・テンプレートのaccessPoint属性で参照されます。 |
表46-8 Protocol tModelのタイプ
| 名前 | 説明 |
|---|---|
bea-com:servicebus:anySoap |
サービスへのアクセスに使用するプロトコルのタイプを記述します。SOAPメッセージを含み、WSDLファイルまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
bea-com:servicebus:anyXML |
サービスへのアクセスに使用するプロトコルのタイプを記述します。XMLメッセージを含む、WSDLファイルまたはスキーマで定義されていないサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
bea-com:servicebus:messagingService |
サービスへのアクセスに使用するプロトコルのタイプを記述します。リクエスト・メッセージが任意のXML(スキーマの有無に関係なく)、テキスト、バイナリ、またはMFLで、レスポンス・メッセージがない、または前述のいずれかであるサービスを指定します。メッセージ本文のコンテンツは、アプリケーションによって動的に決まります。 |
次の例は、リクエストがスキーマを使用するXML、レスポンスがテキスト・メッセージであるJMSトランスポートで構成されたメッセージング・サービスのマッピング例です。
例 - メッセージング・サービスのマッピング例
<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>
電子メール・トランスポートのバインディング・テンプレートのaccessPointでは、mailto:name@some_server.comという標準のmailto URL形式を使用します。これは、電子メールを読み込むためのURLであり、Service Busでプロキシ・サービスに構成したURLとは異なります。サーバー名が不明の場合、このmailto URLをプロキシ・サービス定義から生成することはできません。たとえば、プロキシ・サービスがPOP3サーバーから読み込むように定義されている場合、mailfrom:pop3.bea.comのようなURLで定義されていることが考えられます。このようなプロキシ・サービスをパブリッシュすると、ダミー・サーバーが追加されます。前述の例では、パブリッシュされるURLは、mailto:some_name@some_server.comの形式になります。
