| Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド 11g リリース1 (11.1.1.7) E59381-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド 11g リリース1 (11.1.1.7) E59381-01 |
|
前 |
次 |
この章では、Oracle Service Registryとメタデータを交換するためにOracle Enterprise Repositoryを構成する方法について説明します。
この章には、次のセクションがあります。
この項では、Oracle Registry Repository Exchange Utilityの使用を開始する方法と、このユーティリティを使用したユースケース例について説明します。
この項には次のトピックが含まれます:
Oracle Registry Repository Exchange Utilityでは、Oracle Enterprise RepositoryとOracle Service Registryを双方向に同期し、これらの両方の製品のメタデータがこのユーティリティを介してどちらかの方向に流れることができるようにします。このユーティリティで処理されるメタデータ・エンティティを次に示します。
Oracle Registry Repository Exchange Utilityで可能な処理は次のとおりです。
UDDIを使用して、設計時環境から実行時環境にサービスとエンドポイントを公開します。
新しく検出された実行時サービスとエンドポイントをリポジトリに発行し、それらを管理および制御できるようにします。
UDDIレジストリに格納されたサービス・パフォーマンス情報をリポジトリに戻し、予期されるサービス・コンシューマとポートフォリオ・マネージャにより適切に通知します。
Oracle Business Process Managementワークフローによってトリガーされることにより、Oracle Service Registryにアセットを自動的に公開します。
Oracle Registry Repository Exchange Utilityでは、次のメタデータ・エンティティが処理されます。
すべてのUDDI対応サービスとSCAサービス・タイプ、およびエンド・ユーザーが開発するOracle Enterprise Repositoryアセット・タイプのカスタム・サービス。
ビジネス・サービスを提供するビジネス・エンティティ。
Oracle Registry Repository Exchange Utilityがビジネス・エンティティに到達する方法の詳細は、10.3.2.1項「Oracle Enterprise RepositoryからOracle Service Registryに公開されるメタデータの同期」および10.3.2.2項「Oracle Service RegistryからOracle Enterprise Repositoryに移動するメタデータの同期」を参照してください。
サービスへのアクセス・ポイントを提供するサービスにリンクされるエンドポイント・アセット。たとえば、ステージングまたは本番としてタグ付けされ、UDDIバインディング・テンプレートに適切にマップされる複数のエンドポイントが存在する可能性があります。
Oracle Enterprise Repositoryのカテゴリ分けは、UDDIのt-modelにマップされます。カテゴリ分けがサービス・アセットに適用される場合は、適切なエントリがUDDIカテゴリ・バッグに追加され、適切な分類t-modelにリンクされます。これらのt-modelは初回の検出時に自動的にOracle Service Registryにロードされるか、またはOracle Enterprise Repository Exchange Utilityによって手動でロードできます。
詳細は、表10-4の-publish_tmodelを参照してください。
サービスがOracle Service Registryにプッシュされるときに、サービス登録ステータスと「アクティブ・ステータス」がOracle Service Registryのビジネス・サービスのカテゴリ・バッグに項目として追加されます。
非WSDLベースのサービスはUDDIレジストリに公開されます。
HTTPトランスポートのないサービスはUDDIレジストリに公開されません。
サービス・キー - Oracle Enterprise Repositoryによってサービスが複数のサービス・レジストリに昇格される場合、サービス・キーの一貫性が保たれ、同じサービス・キーが各サービス・レジストリに表示されます。サービスがOracle Service RegistryからOracle Enterprise Repositoryに公開される場合、Oracle Enterprise Repositoryでは常にこのサービス・キーを使用してサービスを他のサービス・レジストリに昇格します。
Oracle Registry Repository Exchange Utilityは双方向であるため、次のユースケースをサポートできます。
Oracle Service Registry内のサービスが変更される(たとえば、ステージング環境や本番環境でエンドポイントが追加される)場合、Oracle Registry Repository Exchange Utilityでは、そのサービスをOracle Enterprise Repository内の1つ以上のエンドポイントに関連付けることができます。サービスおよびアセットが複数のUDDIレジストリ環境に公開される場合、単一のUDDIサービス・キーが各レジストリ内に保持されます。
アセットのリレーションシップを使用してビジネス・サービスがOracle Enterprise Repository内の別のビジネス・エンティティに移動される場合、サービスが再同期されると、新しいリレーションシップがOracle Service Registryにも反映されます。
Oracle Enterprise RepositoryメタデータをOracle Service Registryと同期する場合、Oracle Registry Repository Exchange Utilityでは、すべての変更をマージしてエンドポイントの変更が保持されるようにします。
Exchange Utilityでは、特定の種類の非WSDLサービスをOracle Enterprise RepositoryからOracle Service Registryに公開します。これらのサービスは双方向ではありません。つまり、Exchange Utilityでは、Oracle Service RegistryからOracle Enterprise Repositoryに公開し戻すことはできません。
エンドポイントの指定されたアセット・ライフサイクルに基づいて、一致するサービスのエンドポイントをフィルタ処理できるため、一致するエンドポイントのみがリポジトリに公開されます。この問合せは、ステージングされたエンドポイントをリストするレジストリと本番エンドポイントをリストするレジストリという2つのレジストリが存在する場合に役立ちます。
|
注意: Oracle Registry Repository Exchange UtilityはOracle Enterprise Repositoryワークフローで呼び出すことができます。たとえば、アセット・ライフサイクル・ステージの変更または他のイベント・トリガーによってOracle Enterprise RepositoryとOracle Service Registryとの同期をトリガーできる場合などです。 詳細は、A.2.2項「自動ワークフロー」を参照してください。 |
Exchange Utilityは、SAPなどのサード・パーティのUDDIレジストリからサービスを導入できます。SAPとの統合の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repository統合ガイド』の「SAPとの統合」を参照してください。
Exchange Utilityはまた、Oracle Service Registryからメトリックを受け取ることもでき、これらのメトリックはOracle Service RegistryからOracle Business Transaction Management 10gに公開されます。詳細は、『Oracle Fusion Middleware Oracle Enterprise Repository統合ガイド』の「Amberpointとの統合」を参照してください。
この項では、Oracle Registry Repository Exchange Utilityをインストールおよび構成する方法について説明します。
この項には次のトピックが含まれます:
10.2.1項「Oracle Registry Repository Exchange Utilityのインストールおよび構成」
10.2.3項「Oracle Registry Repository Exchange Utilityの構成ファイルの構成」
10.2.4項「UDDIマッピング・ファイル内のOracle Enterprise Repositoryカテゴリ分けの構成」
10.2.6項「Oracle Registry Repository Exchange Utilityのプロパティ・ファイルの理解」
Oracle Registry Repository Exchange Utilityを使用してOracle Enterprise RepositoryメタデータをOracle Service Registryとの間で公開したり受け取る前に、次に示す構成の手順を完了しておく必要があります。
デフォルトでは、Oracle Enterprise Repositoryをインストールすると、Oracle Registry Repository Exchange Utilityファイルは次の場所にあります。
<Oracle_HOME>\repositoryXXX\core\tools\solutions
Oracle Enterprise Repository 11g用のOracle Registry Repository Exchange Utilityファイルは、次のとおりです。
11.1.1.x.x-RR-ExchangeUtility.zip: Exchange Utilityのパッケージが含まれています。
11.1.1.x.x-RR-ExchangeUtility.zipファイルは、Oracle Enterprise Repositoryをインストールしたファイル・システム上のディレクトリ(通常は、Oracle_HOME\repositoryXXX)に解凍できます。Oracle Registry Repository Exchange Utilityが含まれるzipファイルをファイル・システムに解凍すると、次の構造が作成されます。
orrxu <ExchangeUtility Tool Home>
| lib
<ExchangeUtility Tool Home>ディレクトリ内には、Oracle Registry Repository Exchange Utilityファイル(orrxu.xml、UDDIMappings.xml、orrxu.properties、orrxu.batおよびencrypt.batファイルなど)があります。
ソリューション・パックとは異なるUUIDを持つ既存のアセット・タイプが含まれるシステムにソリューション・パックをインポートすると、これらのアセット・タイプが作成され、バージョニングされます。orrxu.propertiesファイルでは、名前別にアセット・タイプが指定されますが、この結果、処理結果が不正確になります。これは、新しいソリューション・パックに含まれていたアセット・タイプではなく、すでに存在していたアセット・タイプを使用しようとすることが原因です。
Oracle Enterprise Repositoryの以前のバージョンでは、一部のアセット・タイプはソリューション・パックによってではなく、手動で作成されており、この結果、ランダムなUUIDが生成されました。
データパックと同じ名前を持つ既存のアセットが存在する場合の回避策としては、新しいデータパックをインポートする前に、システム内のアセットの名前を変更します。
Oracle Service Registryをインストールし、UDDI問合せURL (http://host:port/registry/uddi/inquiryなど)を取得できます。
Oracle Service Registryのインストールの詳細は、http://download.oracle.com/otndocs/tech/soa/OSR11gR1ProductDocumentation.pdfを参照してください。
この項では、Oracle Registry Repository Exchange Utilityの構成ファイルを環境にあわせて構成する方法について説明します。内容は次のとおりです。
<ExchangeUtility Tool Home>にあるorrxu.xmlファイルを開き、次のXMLセクションを変更して、適切な資格証明でOracle Enterprise Repositoryインスタンスを参照するようにします。
<repository>
<uri>http://localhost:7101/oer</uri>
<credentials>
<user>admin</user>
<password>*****</password>
//To ensure security, the password must be encrypted.
//The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
</credentials>
</repository>
ここで、URIにはOracle Enterprise Repository URIを次の形式で指定します。
http://<host>:<port>/<Oracle Enterprise Repository web app name>
|
注意: アセットの表示、編集、受入れおよび登録を行うための基本的なアクセス権が設定されたユーザーとしてExchange Utilityを実行することをお薦めします。 |
パスワードの暗号化の詳細は、第5章「診断およびパスワードの暗号化」を参照してください。
Oracle Registry Repository Exchange Utilityでは、1つ以上のレジストリに公開したり、複数のレジストリから読み取ることができます(各レジストリからの読取りには個別のトランザクションが必要です)。最初の手順は、次に示すように、接続情報を格納する<registry>ノードを1つ以上作成することです。
<registries>
<registry name="osr">
<inquiryURI>http://localhost:7001/registry/uddi/inquiry</inquiryURI>
<publishURI>http://localhost:7001/registry/uddi/publishing</publishURI>
<securityURI>http://localhost:7001/registry/uddi/security</securityURI>
<credentials>
<user>admin</user>
<password>*****</password>
//To ensure security, the password must be encrypted.
//The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
</credentials>
</registry>
<registry name="osr2">
<inquiryURI>http://localhost:7201/registry/uddi/inquiry</inquiryURI>
<publishURI>http://localhost:7201/registry/uddi/publishing</publishURI>
<securityURI>http://localhost:7201/registry/uddi/security</securityURI>
<credentials>
<user>admin</user>
<password>*****</password>
//To ensure security, the password must be encrypted.
//The password encryption tool (encrypt.bat/encrypt.sh), which is located in
<Oracle_home>/repositoryXXX/core/tools/solutions/11.1.1.x.x-OER-PasswordTools.zip,
allows you to encrypt
// the passwords that are stored in the Oracle Registry Repository Exchange Utility configuration (orrxu.xml) file.
</credentials>
</registry>
</registries>
次の構成スニペットは、Oracle Enterprise Repositoryに対して実行する問合せを作成し、Oracle Service Registryに公開する必要のあるサービスのリストを受け取る方法を示しています。これにより、Oracle Service Registryにプッシュされるサービスが問合せの形式でフィルタ処理されます。サービスに対して問合せを実行する方法はいくつか存在するため、1つ以上の問合せを作成できます。サービスに対して問合せを実行する方法をいくつか次に示します。
<services>要素を構成すると、指定されたサービス名がOracle Service Registryに公開されます。ただし、Oracle Enterprise Repository REX APIでの制限により、追加できる<services>要素は1つのみです。
<query>
<repositoryQuery>
<services>
<service name="HelloWorld" />
</services>
<registrationStatus></registrationStatus>
<serviceCategorizations type="AssetLifecycleStage" value=""/>
名前による問合せはまた、一致するサービス名を検索するワイルドカード文字%もサポートしています。たとえば、問合せに<Service name="Hello%">が含まれる場合、名前の先頭が「Hello」であるすべてのサービスが検索されます。また、<Service name="%">の場合は、OER内のすべてのサービスが返されます。
<registrationStatus>要素を構成すると、指定された登録ステータスのサービスのみ公開されます。たとえば、このフィールドをRegisteredに設定すると、登録済のサービスのみがOracle Service Registryに公開されます。一致するその他のサービスのうち、それ以外の状態のものはすべて無視されます。
<registrationStatus>Registered</registrationStatus>
登録ステータスで許容される値(大/小文字は区別されません)は、次のとおりです。
registered
rejected
under_review
pending_review
submitted
unsubmitted
undefined
<serviceCategorizations>要素を構成すると、指定されたカテゴリ分けのサービスのみ公開されます。たとえば、次のカテゴリ分けを使用すると、リリース済サービスのみがOracle Service Registryに公開されます。
<serviceCategorizations type="AssetLifecycleStage" value="Stage 4 - Release"/>
|
注意: serviceCategorizationタイプは、サービス・アセットの分類で見つかったすべてのカテゴリ分けがサポートされます。次に例を示します。 <serviceCategorizations type="Classification" value="Approved"/> <serviceCategorizations type="AssetFuntion" value="Governance"/> |
Oracle Enterprise RepositoryからUDDIレジストリに昇格されるサービスの種類を制限できます。フィルタ要素を使用すると、サービスのタイプの他に、登録ステータス、サービス・カテゴリ分け、およびエンドポイント・アセット・ライフサイクルに基づいて選択内容を絞り込むことができます。構成した場合、指定した基準を満たすサービスのみが公開されます。各<filter>要素には、type、excludeおよびvalueという3つの属性があります。
type (必須フィールド): metadataとwsdllocationという2つのタイプのフィルタがあります。
metadata: Oracle Enterprise Repositoryでは、サービス・アセットには複数のタイプのメタデータがあります。このデータは、メタデータ・タイプ名とフィールドのXPathに基づいてフィルタ処理できます。
1つの例としてサービス・タイプがあります。これは、ハーベスタによって作成されるすべてのサービスに適用されるメタデータの一部です。メタデータ・タイプはinternal.introspectorであり、フィールドのXPathは/sync/Service_Typeです。
フィルタのフォーマットは、次のとおりです(先頭に"metadata"が付いています)。
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />
wsdllocation: サービスをOracle Enterprise Repositoryに収集する場合、WSDLの場所はリモート・サーバーに格納することも、ローカル・ファイル情報としてOracle Enterprise Repositoryに格納することもできます。
|
注意: ローカル・ファイル情報を持つサービスが公開された場合、このWSDLに関する情報はOracle Service Registryに追加されず、サービスのメタデータのみが追加されます。 |
value (必須フィールド): 各タイプには独自の使用可能な値セットがあります。この値が、フィルタ処理するサービスを決定するために使用されます。
metadata値: 許容値は、フィルタ処理するメタデータ・タイプによって異なります。次に例を示します。
Service_Type: Proxy ServiceまたはSplit-Join Service
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />
Scope: globalまたはlocal
<filter type="metadata.internal.introspector.store/sync/Scope" value="global" />
localは、使用不可能なサービスを示します。
Deployment_Status: run-timeまたはdesign-time
<filter type="metadata.internal.introspector.store/sync/Deployment_Status" value="run-time" />
wsdllocation values: remote、local。次の場合、リモートWSDLを持つサービスが公開されます。
<filter type="wsdllocation" value="remote" />
exclude (オプションのフィールド): excludeフラグの値をtrueに設定すると、フィルタの基準を満たすサービスを除くすべてのサービスが公開されます。次の場合、ローカル・ファイル情報に格納されているWSDLを持つサービスを除くすべてのサービスが公開されます。
<filter exclude="true" type="wsdllocation" value="local" />
excludeフラグが設定されている場合、同じタイプのフィルタが複数存在できます。つまり、サービスのタイプがBusiness ServiceまたはSplit-Join Serviceである場合に検索を実行できます。ただし、excludeフラグが設定されていない場合、同じタイプの複数のフィルタが機能しません。つまり、サービスのタイプがBusiness ServiceまたはSplit-Join Serviceである場合に検索を実行することはできません。
複数のFILTER基準を結合できるのは、検索結果から基準を除外する場合のみです。EXCLUDE Business ServiceとEXCLUDE Proxy Serviceは機能します。ただし、INCLUDE Business ServiceとINCLUDE Proxy Serviceは機能しません。
例
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" /> or <filter exclude="true" type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" /> <filter exclude="true" type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />
次の例は機能しません。
<filter type="metadata.internal.introspector.store/sync/Service_Type" value="Business Service" /> <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />
例1
次の例は、Exchange Utilityのデフォルトの構成です。この場合、サービス・タイプがProxy Serviceでないサービス、およびリモートWSDLを持つサービスのみがOracle Service Busから公開されます。
<repositoryQuery>
<services>
<service name=" "/>
</services>
<!--Search criteria for the registration status of the service in
Oracle Enterprise Repository -->
<registrationStatus></registrationStatus>
!--Search criteria for a categorization assigned to the service in
Oracle Enterprise Repository -->
<serviceCategorizations type="AssetLifecycleStage" value=""/>
<!--Name of UDDI Registries to publish to. This name corresponds with
UDDI Registry definitions -->
<!--below under the <registries> section -->
<destinationRegistries>
<destinationRegistry name="TEST_UDDI">
<endpointAssetLifecycleStatus></endpointAssetLifecycleStatus>
</destinationRegistry>
</destinationRegistries>
<!--Filter: identify metadata to apply filter on services to
publish-->
<filters>
<filter type="wsdllocation" value="remote" />
<filter type="metadata.internal.introspector.store/sync/Scope"
value="global" />
<filter exclude="true"
type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy
Service" />
</filters>
</repositoryQuery>
例2
次の例では、リモートおよびローカルの両方で格納されたWSDLを持つサービス、およびProxy Serviceタイプのサービスのみが公開されます。
<filters> <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" /> </filters>
例3
次の場合、Webサービスのみが公開され、Business Service、Proxy ServiceおよびSplit-Join Serviceは除外されます。
<filters> <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Web Service" /> </filters>
次の構成スニペットは、<destinationRegistries>要素を使用して、一致するOracle Enterprise Repositoryサービスを格納する1つ以上の宛先レジストリを構成する方法を示しています。各宛先レジストリには、endpointAssetLifecycleStatusプロパティが含まれる場合があります。これには、このレジストリに公開される特定のアセット・ライフサイクル・ステージ・カテゴリ分けタイプのサービス・エンドポイントをフィルタ処理する機能があります。つまり、特定のアセット・ライフサイクル・ステージ・カテゴリ分けを持つエンドポイントのみが、そのように定義されたレジストリに公開されます。endpointAssetLifecycleStatusプロパティは、オプションのプロパティです。
これらのレジストリは、Oracle Enterprise Repositoryからサービスが選択されてOracle Service Registryに移動されるとき(たとえば、Oracle Enterprise Repository > Oracle Service Registry)に使用されます。
<services>
<service name="%"/>
</services>
<destinationRegistries>
<destinationRegistry name="DEV">
<endpointAssetLifecycleStatus>Stage3- Build</endpointAssetLifecycleStatus>
</destinationRegistry>
<destinationRegistry name="PROD">
<endpointAssetLifecycleStatus>Stage4-Release</endpointAssetLifecycleStatus>
</destinationRegistry>
</destinationRegistries>
宛先レジストリを変更し、これらにendpointLifecycleStatus要素を追加します。
次の構成スニペットは、<registryQuery>要素を使用して、Oracle Service Registryに対して実行する問合せを作成し、Oracle Service RegistryからフェッチしてOracle Enterprise Repositoryに配置する必要のあるサービスのリストを受け取る方法を示しています。
<registryQuery>
<businessEntities>
<businessEntity name="Account Services"/>
</businessEntities>
<services>
<service name="AddCustomerService%" />
</services>
<qualifiers>
<qualifier>approximateMatch</qualifier>
</qualifiers>
<sourceRegistry>osr</sourceRegistry>
</registryQuery>
次の構成のガイドラインに従ってください。
businessEntities nameまたはservice nameの値が空でないことを確認します。
businessEntities nameには、正確な名前を指定する必要があります。
service nameには、少なくとも1つのワイルドカード文字を使用する必要があります。たとえば、すべてのサービスを取得するには、「%」を指定します。
Oracle Service Registry問合せの検索基準では大/小文字が区別されます。
サービスは、次の方法で検索できます。
1つ以上のサービス名で検索します。修飾子が不確定な場合は、サービス名をワイルドカードにすることができます。たとえば、サービス名が「Google%」の場合は、名前が「Google」で始まるサービスがフェッチされ、Oracle Enterprise Repositoryに配置されます。
1つ以上のビジネス・エンティティを選択します。これにより、これらのビジネス・エンティティ内のすべてのサービスがフェッチされ、Oracle Enterprise Repositoryに配置されます。ビジネス・エンティティ名には正確な名前を指定する必要があります。ワイルドカードがサポートされるのはサービスの場合のみです。ビジネス・エンティティの場合はサポートされません。
|
警告: ビジネス・エンティティ問合せとサービス問合せの両方が指定される場合は、ビジネス・エンティティ問合せによってサービス問合せがオーバーライドされます。 |
次のXMLスニペットに示すように、アセットをOracle Service Registryに公開する前に、<ExchangeUtility Tool Home>ディレクトリに格納されているUDDIマッピング・ファイル(UDDIMappings.xml)にOracle Enterprise Repositoryのカテゴリ分けがマップされます。
<uddi:uddiSettings xmlns:uddi="http://www.bea.com/aler/integration/config/uddi">
<categorizationMappings>
<categorizationType alerCategorizationTypeName="AssetLifecycleStage"
alerCategorizationTypeId="112"
uddiCategoryTModelKey="uddi:bea.com:aler:categorization:AssetLifecycleStage">
<categorization alerCategorization="Stage 1 - Propose" uddiKeyName="Stage 1
- Propose" uddiKeyValue="Stage 1 - Propose" />
<categorization alerCategorization="Stage 2 - Plan" uddiKeyName="Stage 2 -
Plan" uddiKeyValue="Stage 2 - Plan" />
<categorization alerCategorization="Stage 3 - Build" uddiKeyName="Stage 3 -
Build" uddiKeyValue="Stage 3 - Build" />
<categorization alerCategorization="Stage 4 - Release" uddiKeyName="Stage 4
- Release" uddiKeyValue="Stage 4 - Release" />
<categorization alerCategorization="Stage 5 - Target For Retirement"
uddiKeyName="Stage 5 - Target For Retirement" uddiKeyValue="Stage 5 - Target For
Retirement" />
<categorization alerCategorization="Stage 6 - Retirement" uddiKeyName="Stage
6 - Retirement" uddiKeyValue="Stage 6 - Retirement" />
Oracle Enterprise Repositoryのカテゴリ分けは、対応するマッピングがUDDIマッピング・ファイルに存在する場合にのみOracle Service Registryで受け付けられます。それ以外の場合、カテゴリ分けは単純に無視されます。そのため、Oracle Enterprise Repositoryで新しいアセット・カテゴリ分けが作成される場合は、UDDIマッピング・ファイルを再生成して、そのカテゴリ分けがOracle Service Registryで受け付けられるようにする必要があります。
この項では、Oracle Enterprise Repositoryで新しいカテゴリ分けタイプを作成する際にtModelKey UDDI設定を構成する手順について説明します。
Oracle Service Registryによって公開された一部のサービスには、Oracle Enterprise Repositoryにプルする必要があるカテゴリ分けの形式の追加メタデータが含まれます。これにより、Oracle Enterprise Repositoryでカスタム・カテゴリ分けタイプを作成し、これらをこれらのカスタム・カテゴリ分けにバインドできます。
現在、Oracle Registry Repository Exchange Utilityでは、図10-1に示すように、Oracle Enterprise Repositoryでカテゴリ分けタイプを作成する際にtModelキーv3オプションを使用して、Oracle Service Registryのカスタム・カテゴリ分けをOracle Enterprise Repositoryのカスタム・カテゴリ分けにバインドできます。このフィールドに入力するキーは、関連するOracle Service Registryカテゴリ分けのtModelキーである必要があります。
tModelKey UDDI設定の構成手順は、次のとおりです。
アセット・エディタ・ウィンドウで、「アクション」、カテゴリ分けの構成の順に選択します。「カテゴリ分けの構成」ダイアログが表示されます。これにより、Oracle Service Registryカテゴリ分けをミラー化するカスタム・カテゴリ分けタイプを作成します。
|
注意: tModelキーv3フィールドは |
「追加」をクリックし、カテゴリ分けを追加します。「カテゴリ分けの追加」ダイアログが表示されます。たとえば、AIA-LifeCylceStatusカテゴリ分け設定を追加します。
図10-2に示すように、「カテゴリ分けの追加」ダイアログに値を入力します。
tModelキーv3フィールドの下のペインで「AIA-LifeCycleStatus」を選択し、「追加」をクリックします。「カテゴリ分けの追加」ダイアログが表示されます。
図10-3に示すように、「名前」フィールドに「Active」と入力します。
「OK」をクリックします。
同様に、図10-4に示すように、カテゴリ分けとして「非推奨」、「不要」および「計画済」の各値を追加します。
「OK」をクリックします。
アセット・エディタ・ウィンドウで、「アクション」、「タイプの管理」の順にクリックします。タイプ・マネージャ・ウィンドウが表示されます。
「サービス」アセット・タイプを選択します。右側のペインに、「サービス」アセット・タイプの詳細が表示されます。
「タブ」ペインで、分類を選択します。分類に対応する要素が「要素」ペインに表示されます。
「要素」ペインに隣接する「追加」ボタンをクリックします。「追加する要素タイプの選択」ダイアログが表示されます。
図10-5に示すように、「要素タイプ」リストから「カテゴリ分け: AIA-LifeCycleStatus」を選択します。
「OK」をクリックします。「カテゴリ分けの編集: AIA-LifeCycleStatus」ダイアログが表示されます。
「OK」をクリックします。
「ビューア」タブをクリックします。
非表示要素ペインで、「AIA-LifeCycleStatus」を選択し、グループで表示を選択します。「要素の移動」ダイアログが表示されます。
図10-6に示すように、「AIA-LifeCycleStatusの移動先」フィールドで分類を選択します。
Exchange Utilityツールで、UDDIMappings.xmlファイルを生成します。orrxu.xmlファイルでOracle Enterprise Repositoryインスタンスへの接続情報を指定します。
Exchange Utilityツールから、orrxu.bat -mapをインストールします。
新しく作成したOracle Enterprise Repositoryカテゴリ分けがUDDIMappings.xmlファイルに含まれることを確認します。
Oracle Service RegistryサービスがOracle Enterprise Repositoryで受け取られたら、Oracle Enterprise Repositoryサービス・アセットは、このカテゴリ分け値が設定され、Oracle Enterprise RepositoryのWeb UIに表示されるようになります。
この項では、<ExchangeUtility Tool Home>ディレクトリに格納されているファイルである、プロパティ・ファイルorrxu.properties内のプロパティについて説明します。一部のプロパティはすでにOracle Enterprise Repositoryの「システム設定」に存在します。また、Oracle Registry Repository Exchange Utility用の新しいプロパティもあります。
cmee.uddi.service.endpoint.relationship=Deployment-Deployed - サービスとエンドポイントのリレーションシップ。
cmee.import.uddi.business.assettype=SOA - Business Entity - ビジネス・エンティティのアセット・タイプ。
cmee.import.uddi.accesspoint.assettype=Endpoint - エンドポイントのアセット・タイプ。
cmee.import.uddi.artifactwsdl.relationship=Sync-Defines - サービスとWSDLアーティファクトのリレーションシップ。
cmee.import.uddi.receiver.batch.size=100 - Oracle Service Registryから受け取る場合のみ、これによってバッチ・サイズが決まります。
cmee.import.uddi.publish.ifendpointmissing: デフォルトでは、Oracle Enterprise Repository内のサービスに1つ以上のエンドポイントがないか、既存のエンドポイントにアクセス・ポイントが無効である場合、このサービスは公開されません。この設定がtrueに設定されている場合、エンドポイントのないサービスはOracle Service Registryに公開されます。
|
注意: 次のプロパティは、対応するプロパティがOracle Enterprise Repositoryの「システム設定」で設定されていない場合にのみ使用されます。Oracle Enterprise Repositoryの「システム設定」プロパティが構成されている場合、その設定によってorrxu.propertiesファイルのプロパティがオーバーライドされます。 |
cmee.uddi.business.service.relationship=BusinessService - サービスのアセット・タイプとビジネス・エンティティのアセット・タイプのリレーションシップ。
cmee.import.uddi.service.assettype=Service - サービスのアセット・タイプ。
cmee.uddi.default.business=A UDDI Node - アセットがビジネス・エンティティにリンクされず、Oracle Service Registryにサービスを公開する場合のみ。
Oracle Enterprise Repositoryのその他の「システム設定」の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
デフォルトでは、XUは、ハーベスタ・ソリューション・パックに用意されているアセット・タイプを使用した操作の収集によってOERで生成されたWSDLベースのHTTPサービスをOSRに公開することをサポートしています。これらのサービスはインタフェース、アーティファクト、エンドポイントおよびシステム提供のリレーションシップとともに、OSRに統合されているツール(Oracle Service Busコンソールを含む)で使用できる方法でOSRでレンダリングされます。
|
注意: すべてのサービスは、特に断りのないかぎり、Oracle Service RegistryでOracle Service Busによる使用が可能です。 |
表10-1 収集したWSDLサービスに対するXUのサポート
| サービス・タイプ/元 | OER内のサービス・モデルに含まれる内容 | XUによってOERからOSRに対して公開されるかどうか | 注意 |
|---|---|---|---|
|
WSDLアタッチメントとともに収集されたWSDLベースのHTTPサービス |
インタフェースにアタッチされたArtifact:WSDL |
はい(WSDLにリモートURIが含まれる場合) |
サービスを発行するためにエンドポイントは必要ありませんが、OSBで使用する場合はエンドポイントが必要です。 |
XUは、別の方法で構成すると、異なるモデルを使用して異なるソースから生成された様々な非WSDL HTTPサービス・タイプもOERでサポートできます。
表10-2 手動で作成された*サービスに対するXUのサポート
| サービス・タイプ/元 | OER内のサービス・モデルに含まれる内容 | XUによってOERからOSRに対して公開されるかどうか | 注意 |
|---|---|---|---|
|
アタッチメントとともに手動で作成されたWSDLベースのHTTPサービス(収集なし) |
インタフェースに手動でアタッチされたArtifact:WSDL |
はい(WSDLにリモートURIが含まれる場合) |
サービス、インタフェース、エンドポイント、Artifact:WSDLを持つSOAモデルとこのモデルの間に一貫性がある場合、異なるアセットおよびリレーションシップをXUマッピング・ファイルで使用およびマップできます。 |
|
XSDアタッチメントとともに手動で作成された非WSDLベースのHTTPサービス |
XUでマップされているリレーションシップを介してインタフェースに手動でアタッチされたArtifact:XSDまたは同様のアーティファクト。インタフェース・タイプは定義されていません。 |
はい(XSDにリモートURIがある場合。XSDはtModel: uddi-org:resource:type with value=xsdとして公開されます) |
|
|
アーティファクト(WADLを持つRESTなど)とともに手動で作成された非WSDL HTTPサービス |
XUでマップされているリレーションシップを介してインタフェースにアタッチされた様々なタイプのアーティファクト(非XSD、WADLなど) |
はい(アーティファクトにリモートURIがあるかぎり。アーティファクトはtModel: uddi-org:resource:type with value=xmlとして公開されます) |
|
|
アーティファクト(RESTなど)なしで手動で作成された非WSDL HTTPサービス |
アタッチされたXSDまたは同様のアーティファクトなし |
はい |
入力XML/出力XMLとともにメッセージング・サービス・タイプとして公開されます。 |
|
注意: OERで(収集なしで)手動で作成されたサービスを、Oracle Service Busで使用可能な形式でOSRに公開できるようにするには、少なくとも1つのエンドポイントおよび1つのインタフェースが必要です。 *REX APIを使用して作成されたサービスにも適用されます。 |
XUは、別の方法で構成すると、異なるモデルを使用して異なるソースから生成された様々な非WSDL HTTPサービス・タイプもOERでサポートできます。
表10-3 Oracle Service Busから収集された非WSDLサービスに対するXUのサポート
| サービス・タイプ/元 | OER内のサービス・モデルに含まれる内容 | XUによってOERからOSRに対して公開されるかどうか | 注意 |
|---|---|---|---|
|
WSDLアタッチメントとともにOSBで収集されたWSDLベースのHTTPサービス |
インタフェースにアタッチされたArtifact:WSDL |
はい(WSDLにリモートURIが含まれる場合) |
OERハーベスタによって収集されたWSDLサービスと同じです。 |
|
OSBで収集された非WSDLベースのHTTPサービス |
任意のXML (REST以外) |
はい |
|
|
OSBで収集された非WSDLベースのHTTPサービス |
任意のSOAP (REST以外) |
はい |
|
|
OSBで収集された非WSDLベースのHTTPサービス |
MFLを使用したメッセージングのみ(Artifact:MFLアタッチ済) |
いいえ |
|
|
OSBで収集された非WSDLベースのHTTPサービス(RESTプロキシ・サービスを含む) |
MFLを除くすべてのメッセージング(Artifact:XSDを持つ場合と持たない場合あり) |
はい。ただし、XSDアーティファクトはリモートURIなしでは公開されません。 |
|
|
OSBで収集されたREST HTTPビジネス・サービス |
インタフェースにアタッチされたArtifact:XSDまたは同様のアーティファクトなし |
OSRでOSBによる使用は不可能です。 |
|
注意: サービスをOracle Service Busで使用可能な形式でOSRに公開できるようにするには、少なくとも1つのエンドポイントおよび1つのインタフェースが必要です。 |
XUでマップされたリレーションシップ(たとえば、インタフェースとアーティファクト間)のうち、特定のXUセッションで非WSDLサービスまたは手動で作成されたサービスの公開時に使用できるのは1つのタイプのみです。これは同時に、収集されたWSDLベースのサービスでもサポートされます。XUでは、単一指定されたシステムで提供(システム提供または手動提供)されるリレーションシップを持つ非WSDLサービスを公開できますが、一度に複数のタイプを公開することはできません。
XUでは、サービスおよびそのエンドポイントを構成するアセット・タイプおよびリレーションシップを定義します。たとえば、OERサービスのアセット・タイプにより、UDDIビジネス・サービスが定義されます。エンドポイント・アセットにより、アクセス・ポイントとリレーションシップDeployed-Toが定義され、2つのアセット・タイプが関連付けられます。これらのデフォルト設定を使用して、ハーベスタによって作成されたサービスがOSRに公開されます。
ただし、ハーベスタなしでサービスを作成するか、デフォルトの構成とは異なる独自のアセット・タイプおよびリレーションシップを使用する場合、OSBから収集した非WSDLベースのHTTPサービスなどのサービスをOSRに公開するには、次の構成手順に従う必要があります。
一度に公開できるサービス・アセット・タイプは1つのみです。デフォルトで定義されているものとは異なる独自のアセット・タイプおよびリレーションシップを使用する場合:
OERでシステム設定のcmee.import.uddi.service.assettypeを変更し、カスタム・アセット・タイプを指すようにします。デフォルトでは、サービスを指していますが、目的のアセット・タイプを指すことができます。
orrxu.propertiesを変更します。
cmee.import.uddi.accesspoint.assettype=<custom endpoint asset type>
WSDLサービスの場合
cmee.import.uddi.artifactwsdl.assettype=<custom artifact WSDL asset type>
|
注意: このカスタム・アーティファクトWSDLタイプのNAMEは、先頭がArtifactである必要があります。 |
非WSDLサービスの場合
cmee.import.uddi.definingartifact.relationship=<custom artifact asset type>
cmee.import.uddi.artifactwsdl.relationship=<custom relationship between endpoint/interface and artifact asset>
cmee.import.uddi.interface.service.relationship=<custom relationship between service and interface assets>
cmee.uddi.service.endpoint.relationship=<custom relationship between service and endpoint>
収集されていないサービス
タイプ・マネージャで、アクセス・ポイントを定義するために使用されているアセット・タイプ(即時利用可能なエンドポイント)を選択し、カスタム・データURL要素endpoint-uriを追加します。
このendpoint-uriフィールドには、UDDIレジストリに公開するサービスのアクセス・ポイントを手動で移入する必要があります。
この項では、Oracle Registry Repository Exchange Utilityを使用してメタデータを同期し、Oracle Enterprise Repository内で交換されるメタデータを検索する方法について説明します。
この項には次のトピックが含まれます:
10.3.3項「Oracle Enterprise Repository内のOracle Service Registryの交換されるメタデータの検索」
10.3.4項「Oracle Registry Repository Exchange Utilityのログ・ファイルの確認」
Oracle Registry Repository Exchange Utilityは、次の構文を使用してコマンド・プロンプトから実行されます。
> orrxu.bat <options>
表10-4では、Oracle Registry Repository Exchange Utilityの実行時に使用できる構成オプションを定義しています。
表10-4 Oracle Registry Repository Exchange Utilityのコマンド行オプション
| オプション | 必須 | 動作 |
|---|---|---|
|
|
はい |
publishまたはreceiveモードで実行するようにユーティリティを構成します。
|
|
|
オプション |
使用例:
このパラメータを省略すると、orrxu.batファイルが保存されている現在のディレクトリから、システムのクラスパスを使用して構成XMLファイルがロードされます。 |
|
|
オプション |
使用例:
|
|
|
オプション |
使用例:
|
ワークフローを使用してOracle Registry Repository Exchange Utilityを起動すると、Oracle Enterprise RepositoryとOracle Service Registryの同期を自動化できます。
この項には次のトピックが含まれます:
workflow.xmlファイルおよびワークフローの構成の詳細は、第A章「Oracle Enterprise Repositoryワークフローの構成」を参照してください。
この項では、Oracle Registry Repository Exchange Utilityワークフローを実行する前に必要な前提条件の構成手順について説明します。
Oracle Registry Repository Exchange Utilityのソリューション・パック11.1.1.x.x-RR-ExchangeUtility.zipを<Oracle_HOME>\repository111\core\tools\solutionsからダウンロードします。
zipファイルを抽出し、ここから次のファイルを<Oracle_Home>\obpm\enterprise\server\aler_engineディレクトリにコピーします。
plugins
orrxu.properties
orrxu.xml
log4fl.properties
types.properties
UDDIMappings.xml
これらのファイルは、Oracle Registry Repository Exchange UtilityワークフローをOracle BPMから実行する際に必要です。
Oracle Service Registryインスタンスからイベントを生成したりOracle Service Registryインスタンス用のイベントを生成するOracle Enterprise Repositoryインスタンスの接続情報について、およびアセットの公開または受取りのためにorrxu.xmlを構成します。
ファイル内のパスワードが暗号化ツールを使用して暗号化されていることを確認します。
タイマー・ベースのワークフローを使用すると、Oracle Service RegistryからOracle Enterprise Repositoryへの同期、またはOracle Enterprise RepositoryからOracle Service Registryへの同期が可能になります。
表10-5は、タイマー・ベースのワークフローの名前と説明を示しています。
表10-5 タイマー・ベースのワークフロー
| ワークフロー名 | 説明 |
|---|---|
|
|
サービスをOracle Enterprise RepositoryからOracle Service Registryに移動します。 |
|
|
サービスをOracle Service RegistryからOracle Enterprise Repositoryに移動します。 |
タイマーは、workflow.xmlファイルのtimerIntervalの設定に基づいて起動するように構成できます。次の例は、workflow.xmlファイルで構成されているautoSyncAlerToUddiおよびautoSyncUddiToAlerワークフローを示しています。
<automation>
<autoSyncAlerToUddi configFilename="AlerToUddiSyncOrrxuConfig.xml"
mappingFileName="AlerToUddiSyncOrrxuMapping.xml" timerInterval="2d"/>
<autoSyncUddiToAler configFileName="UddiToAlerSyncOrrxuConfig.xml"
mappingFileName="UddiToAlerSyncOrrxuMapping.xml" timerInterval="3d"/>
</automation>
個々のサービスとそのメタデータは、これらのサービスが登録された場合やサービスのライフサイクルが変更された場合にトリガーされるイベントをワイヤリングすることにより、Oracle Service Registryに移動できます。
サービスの移動には、PublishAssetToUDDIワークフローを使用できます。PublishAssetToUDDIワークフローは、要件に応じて任意のイベント・トリガーにワイヤリングできます。
たとえば、次の構成では、アセット・ライフサイクル・ステージがQAである場合にサービスを移動します。
<state name="urn:com:bea:aler:events:type:CategorizationChanged:AssetLifecycleStage" value ="QA"> <action>PublishAssetToUddi</action> <alrrxConfigFileName>my_orrxu.xml</alrrxConfigFileName> <alrrxMappingFileName>my_uddiMappings.xml</alrrxMappingFileName> </state>
また、レジストリの実行場所に関連する構成はalrrxConfigFileNameの設定を使用して構成され、カテゴリ分けに関連するマッピング・ファイルはalrrxMappingFileNameの設定を使用して構成されます。
|
注意:
|
異なるレジストリを指すように構成された複数の構成ファイルを使用できます。ライフサイクルによっては、アセット・ライフサイクルのトリガーに基づいて別のレジストリにサービスを移動できます。
Oracle Enterprise Repositoryでは、自動ワークフローに対して次のユースケースをサポートします。
自動ワークフローでは、構成されているタイマー間隔に基づいてOracle Enterprise RepositoryとOracle Service Registryの同期を自動化できます。
ライフサイクルに基づいてサービスを分類するために異なるレジストリが実行される場合は、公開するアセット・ライフサイクル・イベン・トリガーを適切なレジストリにワイヤリングすることで、これらのレジストリにサービスを自動的に公開できます。
サービスがOracle Enterprise Repositoryに発行される場合は、サービスをOracle Service Registryに自動的に公開できます。サービスがOracle Enterprise Repositoryに発行されると、ワークフローによって処理されるイベントがトリガーされます。ワークフローでは、このサービスをOracle Service Registryに自動的に移動します(そのように構成されている場合)。
この項では、Oracle Enterprise RepositoryとOracle Service Registryの間でアセットが交換される場合のメタデータの同期方法について説明します。この項には次のトピックが含まれます:
10.3.2.1項「Oracle Enterprise RepositoryからOracle Service Registryに公開されるメタデータの同期」
10.3.2.2項「Oracle Service RegistryからOracle Enterprise Repositoryに移動するメタデータの同期」
この項では、Oracle Enterprise RepositoryからOracle Service Registryにアセットを公開する場合のメタデータの同期方法について説明します。内容は次のとおりです。
|
注意: 以前に同期されたサービスをOracle Service Registryと同期するときに、Oracle Service Registryブラウザ・インスタンスがすでに開いている場合、Oracle Service Registryでは更新された値が表示されません。そのため、更新された値を参照するには、すべてのOracle Service Registryブラウザ・インスタンスを再起動する必要があります。 詳細は、10.3.5項「既知の問題」を参照してください。 |
公開されるサービス・アセットに、関連する(構成されたリレーションで指定されている)ビジネス・エンティティ・アセットがあるかどうかを確認します。
該当する場合は、構成されているリレーションを使用して、既存のビジネス・エンティティ・アセットを使用して、新しく作成されるサービス・アセットに関連付けます。
該当しない場合は、次に示すように、デフォルトのビジネス・エンティティ名を構成から取得します。
デフォルトのビジネス・エンティティ・アセットがOracle Enterprise Repositoryの「システム設定」で構成されているかどうかを確認します。
該当する場合は、それをデフォルトのビジネス・エンティティとして使用します。
該当しない場合は、orrxu.propertiesファイルのデフォルトのビジネス・エンティティ名を使用します。
Oracle Service Registryにサービスを公開すると、新しいサービス・キーが自動的に生成され、Oracle Enterprise RepositoryおよびOracle Service Registry内のサービスに割り当てられます。また、アセット・エディタを介してサービスに独自のサービス・キーを指定することもできます。
|
注意: 独自のサービス・キーを指定する場合、英数字および':'、'.'、'%'、'_'および'-'のみを含める必要があります。サービスがUDDIレジストリに公開されると、サービス・キーが |
UDDIプラグインが適用されているタイプの場合、UDDIサービス・セクションの下の「技術的」タブにある「サービス・キー」フィールドを使用できます。このフィールドに移入されている場合、サービス・キーはOracle Service Registryに同期されます。ただし、このサービスが公開された場合、このフィールドは編集できなくなります。
Oracle Enterprise Repositoryでは、サービスの公開先であるUDDIレジストリの存在により、公開済ステータスを確認します。
|
注意: UDDIレジストリ表が削除機能を使用してすべてのエンドポイントまたはサービスから除去されると、サービス・キーは書込み可能になります。ただし、サービス・キーを変更し、UDDIレジストリに再公開すると、サービス・キーが同期しなくなります。これはサポートされていません。サービス・キーを変更する場合は、UDDIレジストリ内の対応するサービスを削除して再公開する必要があります。 |
これを確認するために、サービスに属するエンドポイント用として、UDDIレジストリが表示される表が用意されています。この表は、「技術的」タブにあります。ただし、Oracle Enterprise Repository内にローカルに格納されているWSDLによってサービスが定義される場合、エンドポイントはUDDIレジストリに公開されません。このため、この表は、「技術的」タブ内のサービス・アセットにあります。
Exchange Utility構成でエンドポイント・アセット・タイプが使用されていない場合は、UDDIレジストリ・プラグインを手動で追加する必要があります。これを行うには、タイプ・マネージャに移動し、使用されているアセット・タイプを選択します。目的のタブを選択し、「要素」の下の「追加」を選択します。リストから、「UDDIレジストリ」を選択します。また、このプラグインは必ず「ビューア」タブに追加してください。
アセット・タイプの変更の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
次に示すように、公開されるサービス・アセットに、1つ以上の関連するエンドポイント・アセットがあるかどうかを確認します。
該当する場合は、UDDIバインディング・テンプレートを作成します(初回のみ)。以前に同期されている場合は、既存のバインディング・テンプレートを更新します。UDDIアクセス・ポイントに到達するには、エンドポイント・アセットでエンドポイントURIを使用します。エンドポイント・アセットのファイル情報にアタッチされるWSDLからポートを導出します。WSDLがOracle Enterprise Repositoryにローカルで格納されている場合、Oracle Service Registry内の既存のバインディング・テンプレートは更新されません。
該当しない場合は、サービス・アセットのファイル情報にアタッチされるWSDLに基づいてバインディング・テンプレートを作成します(WSDLにポート情報が含まれる場合)。バインディング・テンプレートは、リモート(http://)に位置するWSDLに対してのみ作成されます。Oracle Enterprise Repositoryにローカルで格納されるWSDLは含まれません。
アセット・ライフサイクルがエンドポイントにアタッチされる場合や、エンドポイント・アセット・ライフサイクル問合せが使用される場合は、アセット・ライフサイクルに基づいてエンドポイントをフィルタ処理します。たとえば、ステージング・エンドポイントをステージング・レジストリに公開し、本番エンドポイントを本番レジストリに公開できます。
次に示すように、カテゴリ分けがサービス・アセットとエンドポイント・アセットに適用されるかどうかを確認します。
該当する場合は、適用される各カテゴリ分け用のカテゴリ分けマッピングをUDDIMappings.xmlファイルからロードします。
マッピングが見つかった場合は、カテゴリ・バッグへのエントリをビジネス・サービスまたはバインディング・テンプレートに追加します。
t-modelがOracle Service Registryに見つからない場合は、t-modelを自動的に作成します。
該当しない場合、カテゴリ分けはOracle Service Registryのサービスに適用されません。
登録およびアクティブ・ステータスは、カテゴリ・バッグに追加されます。図10-8は、Oracle Service Registryで参照がどのように表示されるかを示しています。
図10-8 Oracle Service RegistryのWSDLサービスのt-modelカテゴリ
図10-9は、Oracle Enterprise Repositoryのサービスにリンクされる2つのエンドポイントがOracle Service Registryでどのように表示されるかを示しています。
図10-10および図10-11は、異なるエンティティとそれらのリレーションシップがOracle Enterprise Repository Navigatorでどのように表示されるかを示しています。
図10-10 Oracle Enterprise Repository Navigatorでのエンティティのリレーションシップ
図10-11 Oracle Enterprise Repository Navigatorでの別のエンティティのリレーションシップ
図10-12は、この項で説明した、Oracle Enterprise RepositoryからOracle Service Registryへのメタデータの同期を示しています。
図10-12 Oracle Enterprise RepositoryからOracle Service Registryに公開されるメタデータのフロー
この項では、Oracle Service Registryからアセットを受け取ってリポジトリに格納する場合のメタデータの同期方法について説明します。内容は次のとおりです。
次に示すように、受け取るサービス・アセットが存在し、そのアセットがビジネス・エンティティ・アセットに関連付けられているかどうかを確認します。
該当する場合は、同じビジネス・エンティティのリレーションシップが使用されます。
該当しない場合は、Oracle Service Registry側のビジネス・エンティティが使用されます。Oracle Enterprise Repositoryにビジネス・エンティティが存在しない場合は、作成されます。
サービス・アセットが新しく作成される場合は、UDDIビジネス用のデフォルトのビジネス・エンティティのアセット・タイプをOracle Enterprise Repositoryの構成から取得します。
見つかる場合は、システム設定から
見つからない場合は、orrxu.propertiesファイルから
次に示すように、その名前とタイプのアセットが存在するかどうかを確認します。
該当する場合は、構成済のリレーションシップを使用して、その既存のアセットを新しく作成されるサービス・アセットに関連付けます。
該当しない場合は、新しいアセットを作成し、構成済のリレーションシップを使用して、そのアセットを新しく作成されるサービス・アセットに関連付けます。
次に示すように、受け取るサービス・アセットに、1つ以上の関連するエンドポイント・アセットがあるかどうかを確認します。
該当する場合は、UUIDを使用して、エンドポイント・アセットが既存のバインディング・テンプレートと同じであるかどうかを確認します。同じ場合は、エンドポイントを更新します。
該当しない場合は、各バインディング・テンプレート用のエンドポイントを作成し、それらをサービス・アセットに関連付けます。
次に示すように、カテゴリ分けがカテゴリ・バッグに存在するかどうかを確認します。
該当する場合は、適用される各カテゴリ分け用のカテゴリ分けマッピングをUDDIMappings.xmlファイルからロードします。
マッピングが見つかった場合は、サービス・アセットのカテゴリ分けを設定します。
図10-13は、この項で説明した、Oracle Service RegistryからOracle Enterprise Repositoryへのメタデータの同期を示しています。
Oracle Registry Repository Exchange Utilityでは、公開されたサービスおよび受け取ったサービスごとに、問合せに使用できる次のような情報がタグ付けされます。
公開または受取りの日時
ソースと宛先のレジストリ
公開されたサービスまたは受け取ったサービスの情報に対する問合せを実行するには、次の手順に従って、Oracle Enterprise Repositoryの「詳細な検索オプション」機能を使用します。
Oracle Enterprise Repository Webコンソールで、「アセット」ページを開きます。
サイドバーにある「検索」ボックスで、「詳細な検索オプション」リンクをクリックします。「詳細な検索オプション」ダイアログが表示されます。
追加基準によるフィルタ・オプションを選択して、フィルタ処理基準の追加のオプションを表示します。
「フィールドの選択」リストで、「internal.alrr.exchange.store」オプションを選択します。
図10-14に示すように、「追加」ボタンの横にあるフィールドに、メタデータが交換された日付を入力します。
ダイアログの一番下にある「検索」ボタンをクリックします。
Oracle Enterprise Repositoryの検索オプションの使用の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
Oracle Registry Repository Exchange Utilityでは、実行される詳細なタスクのロギングにlog4jを使用します。ログ・ファイルは、<ExhangeUtility Tool Home>ディレクトリに格納されます。ロギング・オプションの変更は、<ExhangeUtility Tool Home>ディレクトリにあるlog4fl.propertiesファイルを更新して行うことができます。
この項では、Oracle Registry Repository Exchange Utilityの使用時の既知の問題について説明します。内容は次のとおりです。
以前に同期されたサービスをOracle Service Registryと同期するときに、Oracle Service Registryブラウザ・インスタンスがすでに開いている場合、Oracle Service Registryでは更新された値が表示されないという既知の問題があります。そのため、更新された値を参照するには、すべてのOracle Service Registryブラウザ・インスタンスを閉じてから再起動する必要があります。
サービスがOracle Enterprise RepositoryからOracle Service Registryに公開されると、Oracle Service RegistryでサービスのWSDLの場所を示すURLを開こうとするときにエラーが発生する可能性があります。
回避策:
Oracle Enterprise Repositoryコンソールのログイン先の同じブラウザ・インスタンスに、WSDLの場所を示すURLをコピー・アンド・ペーストします。
Oracle Enterprise Repository Registry Exchange Utilityを使用してサービスをOracle Service Registryに公開した場合、サービス・レジストリでこのサービスに対して新しいサービス・キーが生成されます。サービス・キーはすべて、サービス・アセットとすべてのサービス・レジストリ・インスタンス間で一貫性のある状態で保持されています。Oracle Enterprise Repository Exchange Utilityでは複数のレジストリに対するサービス・エンドポイントの同時公開がサポートされるため、このサービス・キーはすべてのレジストリにわたるサービスに対して一貫性のある状態で保持されます。
回避策:
ありません。
サービス・キーが含まれないOracle Enterprise RepositoryサービスがOracle Service Registryに発行されると、サービス・アセットのUUIDからサービス・キーが作成されます。このサービスが複数のレジストリに発行されると、このサービス・キーがすべてのレジストリにわたって保持されます。
回避策:
ありません。
Oracle Enterprise Repository Registry Exchange Utilityを実行するときに、最小限必要なJDK 1.6バージョンを使用していない場合、次のエラー・メッセージが表示されます。
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad
version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
@ at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
@ at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
@ at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
