| Oracle® Fusion Middleware Oracle Enterprise Repository管理者ガイド 12c リリース 1 (12.1.3) E59479-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Enterprise Repository管理者ガイド 12c リリース 1 (12.1.3) E59479-02 |
|
前 |
次 |
この章では、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がビジネス・エンティティに到達する仕組みの詳細は、21.3.2.1項および21.3.2.2項を参照してください。
サービスへのアクセス・ポイントとなる「サービス」にリンクされているエンドポイント・アセット。たとえば、ステージングまたは本番としてタグ付けし、UDDIバインディング・テンプレートに適切にマップされる複数のエンドポイントがある場合があります。
Oracle Enterprise Repositoryのカテゴリ分けはUDDI t-modelにマップされます。カテゴリ分けをサービス・アセットに適用すると、対応するエントリがUDDIカテゴリ・バッグに追加され、適切な分類t-modelにリンクされます。これらのt-modelは、初回検出時にOracle Service Registryに自動的にロードされるか、またはOracle Enterprise Repository Exchange Utilityを使用して手動でロードできます。
詳細は、表21-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 Registry Repository Exchange Utilityを使用してOracle Enterprise RepositoryのメタデータとOracle Service Registryを同期する場合、エンドポイントの変更が保持されるようにすべての変更がマージされます。
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の同期が開始されるようにすることができます。 |
この項では、Oracle Registry Repository Exchange Utilityをインストールして構成する方法について説明します。
この項には次のトピックが含まれます:
21.2.1項「Oracle Registry Repository Exchange Utilityのインストールおよび構成」
21.2.3項「Oracle Registry Repository Exchange Utilityの構成ファイルの構成」
21.2.4項「UDDIマッピング・ファイルでのOracle Enterprise Repositoryのカテゴリ分けの構成」
21.2.6項「Oracle Registry Repository Exchange Utilityのプロパティ・ファイルについて」
Oracle Registry Repository Exchange Utilityを使用してOracle Enterprise RepositoryのメタデータをOracle Service Registryに公開したり、Oracle Service Registryから受け取るには、事前に次の構成手順を完了しておく必要があります。
デフォルトでは、Oracle Enterprise Repositoryをインストールすると、Oracle Registry Repository Exchange Utilityファイルが次の場所に配置されます。
<Oracle_HOME>\oer\modules\tools\solutions
Oracle Enterprise Repository用のOracle Registry Repository Exchange Utilityファイルは次のとおりです。
12.1.3.0.0-RR-ExchangeUtility.zip: Exchange Utilityのパッケージが格納されています。
12.1.3.0.0-RR-ExchangeUtility.zipファイルは、Oracle Enterprise Repositoryをインストールしたファイル・システム上のディレクトリ(通常はOracle_HOME\oer)に解凍できます。Oracle Registry Repository Exchange Utilityが格納されたzipファイルをファイル・システムに解凍すると、次の構造が作成されます。
orrxu <ExchangeUtility Tool Home>
| lib
<ExchangeUtility Tool Home>ディレクトリ内には、orrxu.xml、UDDIMappings.xml、orrxu.properties、orrxu.bat、encrypt.batファイルなどのOracle Registry Repository Exchange Utilityファイルが含まれています。
システムにソリューション・パックをインポートするときに、パックとは異なるUUIDを持つ既存のアセット・タイプがある場合、アセット・タイプはバージョン付きで作成されます。orrxu.propertiesファイルではアセット・タイプを名前で指定しているため、結果は不正確になります。これは、新しいソリューション・パックに含まれていたアセット・タイプではなく、すでに存在するアセット・タイプの使用が試行されるためです。
以前のバージョンのOracle Enterprise Repositoryでは、一部のアセット・タイプはソリューション・パックでは作成されず、手動で作成していましたが、このため、生成されるUUIDがランダムでした。
データパックと同名のアセットがすでに存在する場合は、回避策として、システム内のアセットの名前を変更してから新しいデータパックをインポートします。
Oracle Service Registryをインストールし、http://host:port/registry/uddi/inquiryなどのUDDI照会URLを取得できます。
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>/oer/modules/tools/solutions/12.1.3.0.0-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を実行することをお薦めします。 |
パスワードの暗号化の詳細は、第12章「パスワードの暗号化」を参照してください。
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>/oer/modules/tools/solutions/12.1.3.0.0-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>/oer/modules/tools/solutions/12.1.3.0.0-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"/>
|
注意: serviceCategorizationsのtypeでは、サービス・アセットの分類にあるすべてのカテゴリ分けがサポートされています。次に例を示します。<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に基づいてフィルタ処理できます。
サービス・タイプを例として考えます。このメタデータは、ハーベスタによって作成されたすべてのサービスに適用されます。メタデータ・タイプは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の値: remoteまたはlocalです。リモートWSDLを使用するサービスを公開する場合、次のようにします。
<filter type="wsdllocation" value="remote" />
exclude (オプション・フィールド): excludeフラグの値をtrueに設定した場合、フィルタ基準を満たすサービスを除き、すべてのサービスが公開されます。ローカル・ファイル情報として格納されているWSDLを使用するサービスを除き、すべてのサービスを公開するには、次のようにします。
<filter exclude="true" type="wsdllocation" value="local" />
excludeフラグを設定した場合は、同じタイプのフィルタを複数使用できます。この場合、タイプがビジネス・サービスまたは分割-結合サービスのサービスを検索できます。ただし、excludeフラグを設定しなかった場合は、同じタイプのフィルタを複数指定しても機能しません。この場合、タイプがビジネス・サービスと分割-結合サービスのサービスを検索できません。
検索結果からその基準を除外する場合にのみ、複数のフィルタ基準を組み合せることができます。ビジネス・サービスの除外とプロキシ・サービスの除外は機能します。しかし、ビジネス・サービスの包含とプロキシ・サービスの包含は機能しません。
次に例を示します。
<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のデフォルト構成です。Oracle Service Busからのサービスで、サービス・タイプがプロキシ・サービスではなく、かつ、リモートWSDLを使用するもののみを公開します。
<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とローカルに格納されたWSDLのどちらを使用するかを問わず、タイプがプロキシ・サービスのサービスのみを公開するには、次のようにします。
<filters> <filter type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" /> </filters>
例3
Webサービスのみを公開し、ビジネス・サービス、プロキシ・サービスおよび分割-結合サービスを除外するには、次のようにします。
<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を使用すると、Oracle Service Registryのカスタム・カテゴリ分けをOracle Enterprise Repositoryのカスタム・カテゴリ分けにバインドできます。そのためには、図21-1に示すように、Oracle Enterprise Repositoryでカテゴリ分けタイプを作成するときに、tModelキーv3オプションを使用します。このフィールドには、Oracle Service Registryの関連するカテゴリ分けのtModelキーを入力する必要があります。
tModelKey UDDI設定を構成する手順は次のとおりです。
アセット・エディタ・ウィンドウで、「アクション」、カテゴリ分けの構成の順に選択します。カテゴリ分けの構成ダイアログが表示されます。この際、Oracle Service Registryのカテゴリ分けを反映したカスタム・カテゴリ分けタイプが作成されます。
|
注意: tModelキーv3フィールドは、Oracle Service Registryのサービス・カテゴリのtModelキーであるuddi:oracle.com:aia:service:lifecyclestatusに設定されています。 |
「追加」をクリックしてカテゴリ分けを追加します。カテゴリ分けの追加ダイアログが表示されます。たとえば、AIA-LifeCylceStatusカテゴリ分けを追加します。
図21-2に示すように、カテゴリ分けの追加ダイアログに値を入力します。
tModelキーv3フィールドの下にあるペインで「AIA-LifeCycleStatus」を選択し、「追加」をクリックします。カテゴリ分けの追加ダイアログが表示されます。
図21-3に示すように、「名前」フィールドに「Active」と入力します。
「OK」をクリックします。
同様に、図21-4に示すように、カテゴリ分けに「Deprecated」、「Obsolete」および「Planned」という値を追加します。
「OK」をクリックします。
アセット・エディタ・ウィンドウで、「アクション」、タイプの管理の順にクリックします。タイプ・マネージャ・ウィンドウが表示されます。
「サービス」アセット・タイプを選択します。「サービス」アセット・タイプの詳細が右側のペインに表示されます。
タブ・ペインで、分類を選択します。分類に対応する要素が「要素」ペインに表示されます。
「要素」ペインの隣にある「追加」ボタンをクリックします。追加する要素タイプの選択ダイアログが表示されます。
図21-5に示すように、「要素タイプ」リストからカテゴリ分け: AIA-LifeCycleStatusを選択します。
「OK」をクリックします。カテゴリ分けの編集: AIA-LifeCycleStatusダイアログが表示されます。
「OK」をクリックします。
「ビューア」タブをクリックします。
非表示要素ペインで、「AIA-LifeCycleStatus」を選択し、「グループでの表示」をクリックします。要素の移動ダイアログが表示されます。
図21-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つ以上のエンドポイントがない場合、または既存のエンドポイントに無効なアクセス・ポイントがある場合、Exchange Utilityにより公開対象から除外されます。この設定を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のその他のシステム設定の詳細は、第2章「システム設定の概要」を参照してください。
XUをデフォルトのまま使用した場合、Harvester Solution Packに用意されているアセット・タイプを使用してOERからWSDLベースのHTTPサービスを収集し、それをOSRに公開できます。これらのサービスは、そのインタフェース、アーティファクト、エンドポイントおよびシステム供給リレーションシップとともにOSRにレンダリングされ、Oracle Service Busコンソールを含め、OSRに統合されているツールから利用できるようになります。
|
注意: 特に指定のないかぎり、Oracle Service RegistryではOracle Service Busによってすべてのサービスを利用できます。 |
表21-1 収集されたWSDLサービスに対するXUサポート
| サービス・タイプ/起点 | OERのサービス・モデルの内容 | XUによりOERからOSRに公開されるか | 備考 |
|---|---|---|---|
|
収集されたWSDLベースのHTTPサービス、WSDLアタッチメント付き |
WSDLアーティファクトがインタフェースにアタッチされています。 |
はい(WSDLがリモートURIを持つ場合)。 |
サービスを公開するためにエンドポイントは不要ですが、サービスをOSBで利用するためにはエンドポイントが必要です。 |
XUの構成を変更すると、異なるソースを起点とし、異なるモデルを使用するOER内の多様な非WSDL HTTPサービス・タイプも扱えるようになります。
表21-2 手動で作成*されたサービスに対するXUサポート
| サービス・タイプ/起点 | OERのサービス・モデルの内容 | XUによりOERからOSRに公開されるか | 備考 |
|---|---|---|---|
|
収集ではなく、手動で作成されたWSDLベースのHTTPサービス、アタッチメント付き |
WSDLアーティファクトがインタフェースに手動でアタッチされています。 |
はい(WSDLがリモートURIを持つ場合)。 |
サービス、インタフェース、エンドポイント、WSDLアーティファクトを扱うSOAモデルと整合したモデルであれば、異なるアセットやリレーションシップを使用してXUマッピング・ファイルでマップできます。 |
|
手動で作成された非WSDLベースのHTTPサービス、XSDアタッチメント付き |
XUでマップされたリレーションシップに基づいて、XSDアーティファクトまたは類似のアーティファクトがインタフェースに手動でアタッチされています。インタフェース・タイプは定義されていません。 |
はい(XSDがリモートURIを持つ場合)。XSDは、tModel: uddi-org:resource:typeに値xsdを設定することで公開されます。 |
|
|
手動で作成された非WSDL HTTPサービス、アーティファクト付き(WADLを使用したRESTなど) |
XUでマップされたリレーションシップに基づいて、様々なタイプのアーティファクト(WADLなどの非XSD)がインタフェースにアタッチされています。 |
はい(アーティファクトがリモートURIを持つ場合)。アーティファクトは、tModel: uddi-org:resource:typeに値xmlを設定することで公開されます。 |
|
|
手動で作成された非WSDL HTTPサービス、アーティファクトなし(RESTなど) |
XSDまたは類似のアーティファクトはアタッチされていません。 |
はい |
入力XML/出力XMLを使用するメッセージング・サービス・タイプとして公開されます。 |
|
注意: OERに手動で作成されたサービス(収集されたもの以外)をOracle Service Busで利用可能な形式でOSRに公開するには、少なくともエンドポイントとインタフェースが必要です。*REX APIを使用して作成されたサービスにも当てはまります。 |
XUの構成を変更すると、異なるソースを起点とし、異なるモデルを使用するOER内の多様な非WSDL HTTPサービス・タイプも扱えるようになります。
表21-3 Oracle Service Busから収集された非WSDLサービスに対するXUサポート
| サービス・タイプ/起点 | OERのサービス・モデルの内容 | XUによりOERからOSRに公開されるか | 備考 |
|---|---|---|---|
|
OSBから収集されたWSDLベースのHTTPサービス、WSDLアタッチメント付き |
WSDLアーティファクトがインタフェースにアタッチされています。 |
はい(WSDLがリモートURIを持つ場合)。 |
OERハーベスタによって収集されたWSDLサービスと似ています。 |
|
OSBから収集された非WSDLベースのHTTPサービス |
あらゆるXMLが扱われます(RESTは扱われません)。 |
はい |
|
|
OSBから収集された非WSDLベースのHTTPサービス |
あらゆるSOAPが扱われます(RESTは扱われません)。 |
はい |
|
|
OSBから収集された非WSDLベースのHTTPサービス |
MFLを使用したメッセージングのみが扱われます。MFLアーティファクトがアタッチされています。 |
いいえ |
|
|
OSBから収集された非WSDLベースのHTTPサービス(RESTプロキシ・サービスを含む) |
MFLを除くすべてのメッセージングが扱われます。XSDアーティファクトは状況に応じて扱われます。 |
はい。ただし、リモートURIを持たないXSDアーティファクトは公開されません。 |
|
|
OSBから収集されたREST HTTPビジネス・サービス |
XSDアーティファクトまたは類似のアーティファクトはアタッチされていません。 |
OSRでOSBにより利用することはできません。 |
|
注意: サービスをOracle Service Busで利用可能な形式でOSRに公開するには、少なくともエンドポイントとインタフェースが必要です。 |
非WSDLサービスまたは手動で作成されたサービスをXUセッションで公開する際には、XUでマップされたリレーションシップ(インタフェースとアーティファクトのリレーションシップなど)を1つのタイプにかぎり使用できます。これは、収集されたWSDLベースのサービスに対しても同時にサポートされます。XUでは、指定されたシステム供給リレーションシップ(システム供給または手動指定のいずれか)に基づいて非WSDLサービスを公開できますが、同時に扱えるタイプは1つのみです。
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タイプの名前は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で検索する方法について説明します。
この項には次のトピックが含まれます:
21.3.3項「Oracle Service Registryとの間で交換されたメタデータのOracle Enterprise Repositoryでの検索」
21.3.4項「Oracle Registry Repository Exchange Utilityのログ・ファイルの確認」
Oracle Registry Repository Exchange Utilityは、次の構文を使用してコマンド・プロンプトから実行します。
> orrxu.bat <options>
表21-4に、Oracle Registry Repository Exchange Utilityの実行時に使用できる構成オプションの定義を示します。
表21-4 Oracle Registry Repository Exchange Utilityのコマンド行オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
|
はい |
publishモードまたはreceiveモードで実行するようにユーティリティを構成します。
|
|
|
オプション |
使用例:
このパラメータを省略した場合は、システムのクラスパスを使用して、orrxu.batファイルが現在格納されているディレクトリから構成XMLファイルがロードされます。 |
|
|
オプション |
Oracle Enterprise Repositoryに接続し、構成済のカテゴリ分けに基づいてt-modelを移入することによって、 使用例:
|
|
|
オプション |
使用例:
|
ワークフローを使用してOracle Registry Repository Exchange Utilityを起動すると、Oracle Enterprise RepositoryとOracle Service Registryの同期を自動化できます。
この項には次のトピックが含まれます:
workflow.xmlファイルおよびワークフローの構成の詳細は、第13章「Oracle Enterprise Repositoryエクスプレス・ワークフローの構成」を参照してください。
この項では、Oracle Registry Repository Exchange Utilityワークフローを実行するための前提条件となる構成手順について説明します。
<Oracle_HOME>\oer\modules\tools\solutionsからOracle Registry Repository Exchange Utilityソリューション・パック12.1.3.0.0-RR-ExchangeUtility.zipをダウンロードします。
zipファイルを解凍し、その中に含まれている次のファイルを<Oracle_Home>\obpm\enterprise\server\aler_engineディレクトリにコピーします。
plugins
orrxu.properties
orrxu.xml
log4fl.properties
types.properties
UDDIMappings.xml
これらのファイルは、Oracle BPMからOracle Registry Repository Exchange Utilityワークフローを実行するために必要です。
orrxu.xmlの構成として、イベントの生成元となるOracle Enterprise RepositoryインスタンスとOracle Service Registryインスタンスの接続情報、さらにアセットの公開/受取りに関する情報を指定します。
ファイル内のパスワードが暗号化ツールにより暗号化されるようにします。
タイマー・ベースのワークフローを使用すると、Oracle Service RegistryからOracle Enterprise Repositoryへの同期、またOracle Enterprise RepositoryからOracle Service Registryへの同期が可能になります。
表21-5に、タイマー・ベースのワークフローの名前と説明を示します。
表21-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設定を使用して構成することに留意してください。
|
注意: <alrrxConfigFileName>および<alrrxMappingFileName>で指定したファイルは、obpmのaler_engineフォルダに保存されます。 |
異なるレジストリを参照するように構成された複数の構成ファイルを使用することもできます。ライフサイクルによっては、アセット・ライフサイクル・トリガーに基づいて別のレジストリにサービスを移動できます。
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との間でアセットが交換されるときのメタデータの同期方法について説明します。この項には次のトピックが含まれます:
21.3.2.1項「Oracle Enterprise RepositoryからOracle Service Registryに公開されるメタデータの同期」
21.3.2.2項「Oracle Service RegistryからOracle Enterprise Repositoryへのメタデータの同期」
この項では、Oracle Enterprise RepositoryからOracle Service Registryにアセットを公開するときのメタデータの同期方法について説明します。内容は次のとおりです。
|
注意: 以前に同期されたサービスをOracle Service Registryと同期するときに、Oracle Service Registryブラウザ・インスタンスがすでに開いている場合、更新された値は表示されません。そのため、更新された値を参照するには、すべてのOracle Service Registryブラウザ・インスタンスを再起動する必要があります。詳細は、21.3.5項「既知の問題」を参照してください。 |
公開対象のサービス・アセットに関連する(構成済のリレーションで指定されている)ビジネス・エンティティ・アセットが存在するかどうかを確認します。
存在する場合は、構成済のリレーションを使用して、既存のビジネス・エンティティ・アセットを新規に作成されるサービス・アセットに関連付けます。
存在しない場合は、次に示すように、デフォルトのビジネス・エンティティ名を構成から取得します。
デフォルトのビジネス・エンティティ・アセットがOracle Enterprise Repositoryのシステム設定で構成されているかどうかを確認します。
構成されている場合は、それをデフォルトのビジネス・エンティティとして使用します。
構成されていない場合は、orrxu.propertiesファイル内のデフォルトのビジネス・エンティティ名を使用します。
サービスをOracle Service Registryに公開すると、Exchange Utilityにより新しいサービス・キーが自動的に生成され、Oracle Enterprise Repository内およびOracle Service Registry内のサービスに割り当てられます。アセット・エディタを使用してサービスに対して独自にサービス・キーを指定することもできます。
|
注意: 独自にサービス・キーを指定する場合は、英数字と:、.、%、_、-のみで指定する必要があります。サービスがUDDIレジストリに公開されると、サービス・キーがorg.apache.axis.types.URIオブジェクトに変換されます。したがって、URI構文に準拠している必要があります。 |
UDDIプラグインが適用されているタイプの場合は、UDDIサービス・セクションの「技術的」タブにある「サービス・キー」フィールドを使用できます。このフィールドにサービス・キーを移入すると、そのキーがOracle Service Registryと同期されます。ただし、該当するサービスが公開された時点でこのフィールドは編集不可になります。
Oracle Enterprise Repositoryでは、サービスの公開先のUDDIレジストリが存在していれば公開済ステータスとみなされます。
|
注意: 削除機能を使用してすべてのエンドポイントまたはサービスからUDDIレジストリ表をクリアすると、「サービス・キー」が書込み可能になります。ただし、サービス・キーを変更してUDDIレジストリに再公開すると、サービス・キーの同期がずれる可能性があります。これはサポートされていません。サービス・キーを変更した場合は、UDDIレジストリ内の対応するサービスを削除してから再公開する必要があります。 |
これを確認するには、サービスに属するエンドポイントからUDDIレジストリを示す表にアクセスします。この表は「技術的」タブにあります。ただし、Oracle Enterprise Repositoryにローカルに格納されているWSDLによってサービスが定義されている場合、エンドポイントはUDDIレジストリに公開されません。そのため、表は「技術的」タブ内のサービス・アセットに表示されます。
Exchange Utilityの構成でエンドポイント・アセット・タイプを使用していない場合は、UDDIレジストリ・プラグインを手動で追加する必要があります。その場合、タイプ・マネージャに移動し、使用するアセット・タイプを選択します。目的のタブを選択し、「要素」で「追加」を選択します。リストからUDDIレジストリを選択します。また、このプラグインを「ビューア」タブに追加してください。
次に示すように、公開対象のサービス・アセットに関連するエンドポイント・アセットが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内のサービスにカテゴリ分けは適用されません。
登録ステータスおよびアクティブ・ステータスはカテゴリ・バッグに追加されます。図21-8に、参照がOracle Service Registryでどのように表示されるかを示します。
図21-8 Oracle Service RegistryにおけるWSDLサービスのt-modelカテゴリ
図21-9に、Oracle Enterprise Repository内のサービスにリンクされている2つのエンドポイントがOracle Service Registryでどのように表示されるかを示します。
図21-10および図21-11に、異なるエンティティとそれらのリレーションシップがOracle Enterprise Repository Navigatorでどのように表示されるかを示します。
図21-10 Oracle Enterprise Repository Navigatorにおけるエンティティのリレーションシップ
図21-11 Oracle Enterprise Repository Navigatorにおける別のエンティティのリレーションシップ
図21-12に、この項で説明したOracle Enterprise RepositoryからOracle Service Registryへのメタデータ同期を示します。
図21-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ファイルからロードします。
マッピングが見つかった場合は、サービス・アセットのカテゴリ分けを設定します。
図21-13に、この項で説明したOracle Service RegistryからOracle Enterprise Repositoryへのメタデータ同期を示します。
Oracle Registry Repository Exchange Utilityでは、公開されたサービスまたは受け取られたサービスに対して、問合せに使用できる次のような情報がタグ付けされます。
公開または受取りの日時
ソース・レジストリと宛先レジストリ
公開されたサービスまたは受け取られたサービスに関する情報を問い合せるには、次の手順に従って、Oracle Enterprise Repositoryの詳細な検索オプション機能を使用します。
Oracle Enterprise Repository Webコンソールで、「アセット」ページを開きます。
サイドバーにある「検索」ボックスで、詳細な検索オプション・リンクをクリックします。詳細な検索オプション・ダイアログが表示されます。
追加基準によるフィルタ・オプションを選択して、フィルタ処理の追加基準オプションを表示します。
フィールドの選択リストで、「internal.alrr.exchange.store」オプションを選択します。
図21-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 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)
