Oracle Service Registryの概要

Oracle Service Registryの概要 ^目次

Oracle Service Registryは、UDDI（Universal Description, Discovery and Integration）V3の仕様に完全に準拠した実装で、SOA（Service Oriented Architecture）の主要コンポーネントです。UDDIレジストリは、サービスの検索、サービスの起動およびサービスに関するメタデータ（サービスのセキュリティ、転送および品質）の管理のための標準ベースの基盤となります。UDDIレジストリでは、任意のカテゴリ化を使用してこれらのメタデータを保存し、利用できます。このようなカテゴリ化は、分類と呼ばれます。

この概要の内容は、次のとおりです。

Webサービスの世界におけるUDDIの役割 - UDDIの利点 ^目次

アプリケーションにWebサービス・インタフェースを作成する際、開発チームが直面する問題には、コードの再利用、継続的なメンテナンス、ドキュメント化などがあります。これらのサービスを管理する必要性は急速に高まっています。

UDDIレジストリは、このような問題の対処に有効であり、次の利点があります。

ビジネス要件を満たすために再利用できる組織内のサービスがどれかを特定しやすくする可視性があります。
再利用を促進し、再開発を回避します。開発時間が短縮され、生産性が向上します。UDDIの機能によって、増加し続けるサービスのポートフォリオをカテゴリ分けすることができ、サービスをより簡単に管理できます。コンポーネント間の関係の理解、バージョン管理および依存性の管理にも役立ちます。
位置と転送の独立性というサービス志向アーキテクチャの構築原則により、サービスを構成し適合しやすくします。ユーザーは、UDDIレジストリに保存されたサービスを動的に検出できます。
サービス間の関係の理解、コンポーネントのバージョンと依存性の管理に役立ちます。
ビジネス・サービスのライフサイクルを管理できます。たとえば、コーディングから公開まで、開発の各フェーズを通して移動するサービスの経過を管理できます。詳細は、「承認プロセス」を参照してください。

UDDIレジストリの使用例 ^目次

UDDIレジストリには、ビジネス・サービスに関するデータおよびメタデータが保存されます。UDDIレジストリには、Webサービスを分類、カタログ化および管理する標準ベースのメカニズムがあります。これにより、他のアプリケーションからWebサービスを検出し、使用できます。UDDIでは、サービス・ベースのアプリケーションの間の間接化という一般的なストラテジとして、コードの再利用を高め、（次の点における）インフラストラクチャ管理の改善など、設計時と実行時の両方でITマネージャに様々な利点をもたらします。

Webサービスに関する情報および組織に固有のカテゴリ化ルール（分類）の公開
特定の条件を満たしたWebサービスの検索
特定のWebサービスによってサポートされるセキュリティおよび転送プロトコル、およびそのサービスの起動に必要なパラメータの指定
起動したサービスで発生したエラーや変更からアプリケーションを切り離す手段（およびフェイルオーバーとインテリジェント・ルーティング）の提供

UDDI仕様の基本概念 ^目次

UDDIは、HTTP、XML、XMLスキーマ（XSD）、SOAP、WSDLなどの確立された複数の業界標準に基づいています。最新版のUDDI仕様は、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3で参照できます。

UDDIの仕様には、Webサービスのレジストリおよびそのプログラム・インタフェースについて記述されています。UDDI自体が、Webサービスのセットです。UDDIの仕様には、次の項目の説明および検出をサポートするサービスが定義されています。

Webサービスのビジネス、組織およびその他のプロバイダ
使用可能なWebサービス
Webサービスへのアクセスおよび管理に使用できる技術的なインタフェース

UDDIデータ・モデル ^目次

UDDIレジストリの基本情報のモデルおよび相互作用のフレームワークは、次のデータ構造で構成されます。

businessService: サービスのビジネス機能を記述します。
businessEntity: サービスを公開するプロバイダに関する情報を記述します。
bindingTemplate:プログラム・インタフェースやAPIへの参照など、サービスの技術的な詳細が保存されています。
tModel: その他の様々な属性やメタデータ（分類、転送、ポリシーなど）が保存されています。

これらのUDDIデータ構造はXMLで表現され、UDDIレジストリに永続的に保存されます。UDDIレジストリ内では、各コア・データ構造に、標準スキームに従った一意の識別子が割り当てられます。この識別子は、UDDIキーといいます。

ビジネス・エンティティ ^目次

ビジネス・エンティティは、サービスを担当するユーザーの組織またはグループ（サービス・プロバイダ）を表します。また、ビジネス・エンティティは、サービスの範囲を超えたもの（開発プロジェクト、部門、組織など）を表す場合もあります。ビジネス・エンティティ構造には、次の要素が含まれます。

名前および説明: ビジネス・エンティティには、必要に応じて様々な言語での名前および説明を含めることができます。
連絡先: ビジネス・エンティティに関連するユーザーのリスト。連絡先には、連絡先名、アドレス、電話番号、ユーザーのタイプなどを含めることができます。
カテゴリ: ビジネス・エンティティの特徴や特性を表す複数のカテゴリ。たとえば、ビジネス・エンティティを「カリフォルニア」というカテゴリに入れると、そのビジネス・エンティティがその地理的領域にあると表すことができます。
識別子: ビジネス・エンティティに任意の数の識別子を付け、一意に識別できます。たとえば、ビジネス・エンティティを部門番号やD-U-N-S番号で識別できます。
検出URL: ビジネス・エンティティを説明するドキュメントへの追加リンクです。

アサーションと呼ばれる、ビジネス・エンティティ間のモデルを使用すると、ビジネス・エンティティを相互にリンクできます。

ビジネス・サービス ^目次

ビジネス・サービスは、ビジネス・エンティティが提供する機能やリソースを表します。ビジネス・エンティティは、複数のビジネス・サービスを参照できます。ビジネス・サービスは、次の要素で記述されます。

名前および説明: ビジネス・サービスには、必要に応じて様々な言語での名前および説明を含めることができます。
カテゴリ: ビジネス・サービスの特徴や特性を表す複数のカテゴリ。たとえば、ビジネス・サービスをサービスの可用性やバージョンなどを表すカテゴリに入れることができます。

UDDIレジストリのビジネス・サービスは、必ずしもWebサービスを表すわけではありません。UDDIレジストリには、EJBやCORBAなどの任意のサービスを登録できます。

バインディング・テンプレート ^目次

ビジネス・サービスには、1つまたは複数のバインディング・テンプレートを含みます。バインディング・テンプレートは、サービスの起動方法に関する技術的な詳細を表します。バインディング・テンプレートは、次の要素で記述されます。

アクセス・ポイント: サービス・エンドポイントを表します。これには、エンドポイントのURIおよびプロトコルの仕様が含まれます。
tModelインスタンス情報: バインディング・テンプレートに関するその他の情報を表します。
カテゴリ: バインディング・テンプレートは、認証ステータス（テスト、本番）やバージョンなど、そのバインディング・テンプレートの具体的な特徴を示すカテゴリに入れることができます。

tModel ^目次

tModelは、仕様および概念の準拠性を抽出した記述への参照を指定します。TModelは、次の要素によって記述されます。

名前および説明: tModelには、必要に応じて様々な言語での名前および説明のセットを含めることができます。
概要ドキュメント: tModelの目的を指定するドキュメントへの参照です。
カテゴリ: 他のすべてのUDDIエンティティと同様に、tModelはカテゴリ化できます。
識別子: tModelに任意の数の識別子を付け、一意に識別することができます。

UDDIエンティティは、分類を介したtModelを使用してカテゴリ化されます。ビジネス・エンティティ、ビジネス・サービスおよびバインディング・テンプレートでは、categoryBag内に特定のtModelが存在することによって、特定のカテゴリとの関連を宣言します。

分類種別 ^目次

UDDIは、レジストリに含まれるWebサービスの情報に対して意味構造を持たせるために役立つ基盤であり、ベスト・プラクティスです。ユーザーはUDDIを使用して複数の分類を定義し、レジストリで使用できます。ユーザーは任意の数（無制限）の適切な分類システムを同時に使用できます。またUDDIでは、パブリッシャが新規の分類スキームをレジストリに追加する際の共通の方針を定義することもできます。

分類は、様々なUDDIエンティティの特徴や特性（製品タイプ、地理的領域、会社の部門など）を表現するために使用されます。

UDDIの仕様には、各UDDIレジストリ製品に添付する必要がある、様々な標準の分類が規定されています。いくつかは、UDDIタイプの分類や地理的な分類のような内部的なUDDI分類です。ある分類を、ビジネス、サービス、バインディング・テンプレートまたはtModelに固有とすることも、任意のUDDIエンティティ・タイプで使用することもできます。

エンタープライズ分類 ^目次

エンタープライズ分類は、特定の企業またはアプリケーションに特化した分類です。このような分類には、会社の部門、アプリケーションのタイプ、アクセス・プロトコルなどの固有の分類が反映されます。

Oracle Service Registryでは、エンタープライズ分類を定義できます。ユーザーは、すべての分類をXMLファイルとしてダウンロードおよびアップロードすることもできます。 Oracle Service Registryには、Webユーザー・インタフェースとSOAP APIの両方のレベルにおいて分類を作成、変更および参照するためのツールがあります。

checked分類およびunchecked分類 ^目次

分類には、checkedとuncheckedの2つのタイプがあります。checked分類は厳格であり、分類に事前定義されていないカテゴリをUDDIレジストリで使用することはできません。通常、checked分類は、分類の作成者が分類内の個々の値をすべて把握できる場合に使用されます。 checked分類は、Oracle Service Registryで使用可能な内部の検証サービスまたは外部の検証サービスを使用して検証できます。

unchecked分類には固定の値セットは規定されず、UDDIエンティティのカテゴリ化には任意の名前と値のペアを使用できます。unchecked分類は、容量、重量、価格などの項目に使用されます。特殊なケースのunchecked分類として、general_keywords分類があり、任意のキーワードを使用してカテゴリ化できます。

セキュリティの考慮事項 ^目次

UDDIの仕様には、アクセス制御メカニズムは定義されていません。UDDIの仕様では、特定のエンティティの変更を、そのエンティティの所有者（作成者）のみに許可します。このことは、エンタープライズ環境での基準ではありません。このような環境では、特定のUDDIエンティティを変更または削除する権限を、より多くのIDまたは複数のロールに対しても与える必要があるためです。

Oracle Service Registryでは、この問題に対処するため、ACL（アクセス制御リスト）をUDDIセキュリティ・モデルに拡張します。すべてのUDDIエンティティは、検索（UDDI問合せ結果に一覧表示）、取得（UDDIオブジェクトの詳細をすべて取得）、変更または削除できるユーザーを定義するACLと関連付けることができます。ACLは、特定のユーザー・アカウントまたはユーザー・グループのいずれかを参照できます。

UDDI v3の仕様では、デジタル署名がサポートされています。 Oracle Service Registryでは、UDDI構造のパブリッシャによってその構造にデジタル署名できます。デジタル署名を検証すると、なんらかの方法で情報が変更されていないかどうかを確認したり、パブリッシャの識別情報を確認することができます。

通知およびサブスクリプション ^目次

UDDI v3の仕様には、通知およびサブスクリプションの機能が導入されています。すべてのUDDIレジストリ・ユーザーは、UDDIエンティティのセットにサブスクライブし、作成、変更および削除を監視できます。サブスクリプションは、標準UDDIのAPIコールgetまたはfindを使用して定義されます。UDDIレジストリでは、サブスクリプション問合せに一致するエンティティが変化すると、ユーザーに通知されます。変化した結果、エンティティが問合せに一致しなくなる場合も通知されます。また、変更されたエンティティについて、変更後にサブスクリプション問合せに一致するような場合も通知されます。

通知には、同期と非同期があります。同期の場合は、最後の通知以降に発生したすべての変更を関係者が明示的に要求するときに、通知されます。非同期通知は、構成可能な間隔で定期的に実行され、一致したエンティティが作成、変更または削除されるたびに、関係者に通知されます。

レプリケーション ^目次

UDDIレジストリの内容は、単純なマスタースレーブ・モデルを使用してレプリケートできます。UDDIレジストリでは、UDDI標準問合せを使用して定義される複数のレプリケーション定義に従って、データをレプリケートできます。マスターとスレーブの関係は、レプリケーション定義に固有です。したがって、あるレプリケーション定義ではマスターであるレジストリが、別の定義ではスレーブである場合もあります。セキュリティ設定（ACL、ユーザーおよびグループ）はレプリケーションの対象ではありませんが、レプリケートされたデータに権限を設定することはできます。

UDDI API ^目次

UDDIレジストリのデータ管理ツールにおけるコア機能は、次のとおりです。

サービスに関する情報のレジストリへの公開
サービスに関する情報のUDDIレジストリでの検索

UDDIの仕様には、次の概念も含まれます。

サービスに関するデータのレプリケーションおよび管理転送
登録キーの生成および管理
登録サブスクリプションAPIセット
セキュリティおよび認可

UDDIの仕様では、前述の機能を、UDDIでサポートされるノードAPIセットとUDDIクライアントでサポートされるクライアントAPIセットに分かれています。

テクニカル・ノート ^目次

テクニカル・ノート（TN）は、UDDIの仕様に付属する標準以外のドキュメントで、UDDIレジストリの使用方法についてのガイドラインを示します。テクニカル・ノートは、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmで参照できます。最も重要なテクニカル・ノートに、『Using WSDL in a UDDI Registry』があります。

UDDI Version 3の利点 ^目次

最も重要な機能は、次のとおりです。

わかりやすい識別子: レジストリ間のサービスの記述を再利用しやすくなりました。
デジタル署名のサポート: UDDIで、より高い水準のデータ整合性および認証性を確保できます。
拡張された検出機能: 以前の複数ステップの問合せを単一ステップの複雑な問合せに結合できます。また、単一の問合せ内にサブ問合せをネストさせる機能により、クライアントはさらに効率的に検索を絞ることができるようになりました。

Oracle Service Registryのサブスクリプション ^目次

サブスクリプションは、Oracle Service Registryで構造が変更されたときに、関係するユーザーへのアラートに使用されます。 Oracle Service RegistryのサブスクリプションAPIを使用すると、ユーザーはサブスクリプションを管理（保存と削除）し、通知の重要性を判断できます。通知は、指定された時間間隔内で行われた変更項目です。サブスクリプションのメカニズムを使用すると、ユーザーはbusinessEntity、businessService、bindingTemplate、tModelまたはpublisherAssertionに対する新規、変更済、削除済のエントリを監視できます。ユーザーがどのエンティティ・セットに関与しているかは、SubscriptionFilter（次のUDDI v3 API問合せのいずれか）で表現されます。

find_business、find_relatedBusinesses、find_services、find_bindings、find_tmodel
get_businessDetail、get_serviceDetail、get_bindingDetail、get_tModelDetail、get_assertionStatusReport

	注意
	ビジネス・サービス・コントロールでは、ユーザーはリソースをUDDIデータ構造にマッピングする方法についての詳細な知識がなくても、サブスクリプションやリソース（WSDL、XML、XSDおよびXSLT）を作成することができます。

サブスクリプションの引数 ^目次

サブスクリプションは、次の引数で定義します。エンティティが変更された場合、サブスクライバにどのような通知が行われるかが、サブスクリプションによって示されます。

SubscriptionKey - サブスクリプションの登録時にサーバーによって生成されるサブスクリプションの識別子。
Subscription Filter - ユーザーが関与するエンティティのセットを指定します。このフィールドは必須です。サブスクリプション・フィルタを設定すると、後で変更できないことに注意してください。
Expires After - サブスクリプションが無効になるまでの時間（オプション）。
Notification Interval - クライアントに通知する頻度（オプション）。サーバーでサポートされている最小の通知間隔（管理者が構成）まで増やすことができます。

詳細は、「管理者ガイド」の「レジストリ構成」を参照してください。
Max Entities - 通知に一覧表示できるエンティティの数（オプション）。通知のエンティティ数が最大エンティティ数を超えても、通知に含められるエンティティ数は、この引数またはレジストリ構成に指定されたエンティティ数までです。通知には、「0」以外のchunkTokenが指定されます。このchunkTokenを使用すると、後続のエンティティを検索できます。
BindingKey - bindingTemplateを指します。通知を処理するサービスのエンドポイントを含みます（オプション）。現在は、HTTPおよびメール転送のみがサポートされています。このbindingKeyを指定しないと、通知は検索同期コールのみで検索できます。
Brief - デフォルトでは、サブスクリプション・フィルタのタイプに対応した結果が通知に含まれます。たとえば、サブスクリプション・フィルタがfind_businessの場合、通知にはbusinessInfosの形式でビジネス・エンティティが含まれます。「Brief」が選択されていると、通知にはエンティティのキーのみが含まれます。（オプション）

サブスクリプション通知 ^目次

通知は、サブスクライバが変更を認識するためのメカニズムです。エンティティに関する次のような情報がサブスクライバに通知されます。

サブスクリプション・フィルタの条件を満たし、指定した期間内に最終変更または作成されたエンティティ。このエンティティは、該当するデータ型のリストにデフォルトで含まれます。たとえば、サブスクリプション・フィルタがfind_businessの場合、通知にはbusinessList/businessInfoの形式でビジネス・エンティティが含まれます。（「Brief」スイッチが選択されている場合は、keyBag内のエンティティ・キーのみが含まれます。）
指定した期間内に変更または削除され、サブスクリプション・フィルタの条件を満たしていないエンティティ。適切なエンティティのキーのみがkeyBag構造に含まれ、「deleted」フラグが選択されます。

通知には、次の2つのタイプがあります。

非同期通知 - 非同期通知を使用すると、サーバーは定期的に変更をチェックし、HTTPまたはSMTPを介してクライアントに提示します。HTTPは、UDDIの変更をリスニングするサーバーに適しています。SMTP（つまり、メール通知）は、サービスとユーザーの両方に適しています。この転送では、ユーザーは通知間隔ごとに電子メールで通知されます。非同期通知を実行するには、通知間隔およびbindingKeyを使用してサブスクリプションを生成する必要があります。詳細は、「開発者ガイド」の「サブスクリプション通知サービスの作成」を参照してください。
同期通知 - 同期通知を使用すると、サーバーは変更をチェックし、定期的な非同期通知以外にクライアントが明示的に要求したときに、クライアントに変更情報を通知します。これは、クライアント・アプリケーションで通知をリスニングできない場合、およびサービス自身で通知時間を管理する場合に役立ちます。詳細は、デモの「Subscription（サブスクリプション）」を参照してください。

XSLT処理通知 ^目次

電子メールでユーザーに送信される通知を読みやすくするために、Oracle Service Registryには、通知が送信される前にXSLTを処理する機能があります。この機能を有効にするには、次の手順を実行します。

tModelの最初のoverviewDocに、XSLTを参照するtModelとして、UDDIにXSLTを登録します。
tModelInstanceInfoによるXSLT tModelを参照するように、（サブスクリプションに指定されたbindingKeyを使用して）bindingTemplateを変更します。
XSLT tModelに、keyValue="xslt"と指定したuddi:uddi.org:resource:typeを参照するkeyedReferenceによってタグ付けします。

空の通知の除去 ^目次

仕様に対するもう1つの追加機能として、Oracle Service Registryでは空の通知を抑制する機能があります。これを行うには、サブスクリプションから参照されるbindingTemplateに、keyValue="suppressEmptyNotification"およびkeyName="suppressEmptyNotification"と指定したtModel uddi:uddi.org:categorization:general_keywordsを参照するkeyedReferenceによってタグ付けします。

Oracle Service Registryの承認プロセス ^目次

承認プロセスには、Oracle Service Registryに保存されるデータの整合性と品質を保証する機能があります。承認プロセスには、次の2つのレジストリがあります。

公開レジストリ: データのテストおよび検証に使用されます。
検出レジストリ: 公開レジストリから承認および昇格されたデータのみが含まれます。

これらのレジストリをインストールおよび構成する方法の詳細は、「インストレーション・ガイド」の「承認プロセス・レジストリのインストール」を参照してください。

承認プロセスには、2種類のユーザーが関与します。

リクエスタ: 公開レジストリのユーザー。データを検出レジストリに昇格させる承認を要求できます。
承認者: データの昇格を求めるリクエストを承認または否認できるユーザーです。

管理者は、次の項目を指定できます。

承認者であるユーザーまたはユーザーのグループ
リクエストを承認できるユーザーまたはユーザーのグループ

いずれのユーザーも承認を要求できますが、データの昇格を考慮に入れるには、ユーザーには管理者が割り当てた承認者が必要です。

詳細は、「管理者ガイド」の「承認プロセスの管理」を参照してください。

図1 承認リクエストのライフサイクル

承認リクエストには、図1に示すライフサイクルがあります。リクエスタはリクエストを作成できます。リクエストを作成すると、リクエスタはUDDIデータ構造（「UDDIデータ・モデル」を参照）またはリソース（WSDL、XML、XSDおよびXSLT）をリクエストに追加できます。リクエスタは、リソースがどのようにUDDIデータ構造にマッピングされるかを知っている必要はありません。リクエスタがリソースをリクエストに追加すると、そのリソースが示すすべての基本UDDI構造（バインディング、tModel）が自動的にリクエストに追加されます。リクエスタが昇格するエンティティをすべて指定した後は、リクエストの承認を送信できます。

承認者は受信リクエストを確認してから、リクエストを承認または否認できます。承認者がリクエストを承認した場合は、リクエストされたデータは即座に検出レジストリに昇格します。承認者の応答に時間がかかる場合、リクエスタは承認者にリクエストの確認をリマインドできます。また、リクエスタは送信したリクエストを取り消すこともできます。

次の項では、リクエスタおよび承認者のアクションについて詳細に説明します。

リクエスタのアクション ^目次

リクエスタは、次のアクションを実行できます。

データ昇格の承認を求めるリクエストの送信

リクエストを送信すると、そのリクエストがリクエスタによって取り消されるか、昇格が承認されるか、または承認者によって否認されるまで、そのリクエストで参照されるすべてのデータがブロック（書込みロック）されます。

	注意
	リクエスタは同じデータ・セットについて昇格の承認を複数回要求することができます。また、未処理のリクエストは同時に存在してもかまいません。

リクエストの検索

このアクションでは、リクエスタはすべてのリクエストに関する情報を一覧表示できます。リクエスタがリクエスタAPIへのアクセス権を持っている場合は、他のユーザーのリクエストに関する簡潔な情報を取得できます。このアクセス権を持っていない場合は、リクエスタ自身のリクエストのみを参照できます。
リクエストの取得

このアクションでは、特定のリクエストに関するすべての情報が返されます。リクエスタがリクエスタAPIへのアクセス権を持っている場合は、他のユーザーのリクエストに関する詳細を取得できます。このアクセス権を持っていない場合は、リクエスタ自身のリクエストにのみアクセスできます。
リクエストの取消

リクエスタは特定のリクエストを取り消すことができます。アクセス権を持っているリクエスタのみが、他のリクエスタのリクエストを取り消すことができます。
データの同期化

このアクションでは、リクエスタは公開レジストリにあるデータを検出レジストリにあるデータと同期化できます。同期には、公開優先、部分検出優先および完全検出優先の3つのタイプがあります。同期化の詳細は、「データの同期化」を参照してください。

検出レジストリにデータを公開するには、最初に公開レジストリにデータを公開した後、適切な承認者から承認を受ける必要があります。リクエスタは、データの品質を満たした後に、データの昇格を要求できます。

リクエスタは、テストのために公開レジストリにデータを公開できます。このデータを承認する準備ができると、リクエスタは承認を要求します。承認リクエストには、保存用のキーと削除用のキーの2種類のキーのセットがあります。キーでデータを選択します。保存用のキーは、エンティティを検出レジストリに公開（保存または更新）するために使用されます。削除用のキーを使用すると、検出レジストリからエンティティを削除できます。承認リクエストには、保存用と削除用のいずれかのデータ（エンティティのキー）を含めます。

いずれのキーのタイプにも、businessEntitiy、businessService、bindingTemplate、tModelまたはpublisherAssertion用のキーを含めることができます。たとえば、リクエスタがbusinessEntityを検出レジストリに昇格させ、検出レジストリのサービスからbindingTemplateを削除する場合、その承認リクエストには、保存用のキーにbusinessEntityのキー、および削除用のキーにbindingTemplateのキーを含める必要があります。正常に承認されると、ビジネス・エンティティは検出レジストリに保存（作成または更新）され、バインディング・テンプレートは検出レジストリから削除されます。

コンテキストのチェック ^目次

承認のリクエスト中に承認が付与されると、リクエストのデータの整合性を保証するために自動コンテキスト・チェックが実行されます。コンテキスト・チェッカには、次のルールがあります。

エンティティが保存用のキーに含まれている場合は、親エンティティがすでに検出レジストリに存在するか、または検出レジストリへの保存用のキーに含まれている必要があります。businessServiceの場合、親はbusinessEntity、bindingTemplateの場合、親はbusinessServiceです。
削除用のキーに含まれるキーを持つエンティティは、保存用のキーに含まれるキーを持つエンティティによって参照することはできません。
削除用のキーに含まれるキーを持つエンティティは、検出レジストリに存在する必要があります。
検出レジストリにあるエンティティによって参照されるtModelは、削除できません。
パブリッシャのアサーションが保存用のキーに含まれている場合は、そのビジネス・エンティティ（fromKey、toKeyに指定）がすでに検出レジストリに存在するか、または保存用のキーに含まれている必要があります。

データが有効な場合は、これらのルールに従って承認のリクエストが実行されます。

データが無効な場合（たとえば、検出レジストリに存在しないエンティティが削除用のキーに含まれる場合）には例外が発生し、承認のリクエストは実行されません。

コンテキスト・チェックに失敗した場合は、再度承認を要求する前に、なんらかの方法でデータを変更する必要があることがリクエスタに通知されます。

特別な承認のケース ^目次

レジストリの管理者がリクエスタを信頼している場合は、そのリクエスタにAutoApproverという承認コンタクトを割り当てることができます。この承認コンタクトでは、人間によるデータの確認はありません。自動コンテキスト・チェックに成功すると、データは自動的に検出レジストリに昇格されます。

承認者のアクション ^目次

承認コンタクトは、承認プロセスを設定するパーミッションを持つユーザー（レジストリ管理者など）により、ApprovalConfiguration APIを介して割り当てられます。承認コンタクトは、検出レジストリにデータを昇格させるためのリクエストを確認し、これらのリクエストを承認または否認します。

コンテンツ・チェック（承認済データに適用される追加ルール）を有効にした場合は、同時に実行されます。

コンテキストのチェックおよびコンテンツ・チェックに成功した場合は、データの昇格に成功したことを示す電子メールがリクエスタに送信されます。この電子メールには、「Message for requestor」ボックスに入力されたメッセージが含まれます。

オプションのコンテンツ・チェック ^目次

オプションのコンテンツ・チェックによって、承認者はプログラムで承認用データをチェックできます。たとえば、承認者は次のポリシーを設定できます。

各ビジネス・サービスにバインディング・テンプレートを含める必要があるというポリシー
各ビジネス・サービスは、指定されたカテゴリでカテゴリ化する必要があるというポリシー

このようなポリシーを施行するには、これらのチェックを施行するようなチェッカAPIの実装を開発者が作成します。承認者が「Approve request」ボタンを押すと、承認プロセス中に自動的にこの実装が呼び出されます。したがって、承認者は手動でチェックする必要がありません。オプションのコンテンツ・チェックの設定の詳細は、「管理者ガイド」の「オプションのコンテンツ・チェックの設定」を参照してください。

データの同期化 ^目次

リクエスタの同期は、公開レジストリおよび検出レジストリにある情報の同期化に使用されます。同期には、公開優先、部分検出優先および完全検出優先の3種類があります。それぞれの同期は、同期化するユーザー・アカウントに関連付けられたすべてのデータ構造で実行されます。同期は、リクエスト上でのみ実行されます。

	注意
	これらのツールでは、検出レジストリの情報を変更できません。検出レジストリのデータは、公開レジストリおよび承認プロセスを経由することによってのみ変更できます。管理者のみが検出レジストリに公開できます。

公開優先 ^目次

公開優先には、次のルールがあります。

エンティティが検出レジストリにのみ存在する場合は、公開レジストリにコピーされます。
エンティティが公開レジストリにのみ存在する場合は、そのまま保持されます。
エンティティが両方のレジストリに存在する場合は、公開レジストリが検出レジストリよりも優先されます。

公開優先の例 ^目次

同期の前に、AとXという構造が公開レジストリに存在し、XとBという構造が検出レジストリに存在すると想定します。

公開優先の同期では、構造Bが公開レジストリにコピーされます。同じエンティティが両方のサーバーに存在する場合、公開優先の同期では公開レジストリが優先されるため、公開レジストリにある構造Xはそのまま保持されます。

部分検出優先 ^目次

部分検出優先には、次のルールがあります。

エンティティが検出レジストリにのみ存在する場合は、検出レジストリから公開レジストリにコピーされます。
エンティティが公開レジストリにのみ存在する場合は、そのまま保持されます。
エンティティが両方のレジストリに存在する場合は、公開レジストリのデータは検出レジストリのデータで上書きされます。

部分検出優先の例 ^目次

この同期の前に、AとXという構造が公開レジストリに存在し、XとBという構造が検出レジストリに存在すると想定します。

部分検出の同期では、構造Bが公開レジストリにコピーされ、公開レジストリにある構造Xのバージョンは検出レジストリのバージョンで上書きされます。

完全検出優先 ^目次

この同期のシナリオでは、公開レジストリにあるすべてのユーザー・データは削除され、検出レジストリにあるすべてのユーザー・データは公開レジストリにコピーされます。完全検出優先の同期後は、検出レジストリと公開レジストリにあるデータは同一になります。

	重要
	Oracle Service Registryの管理者は、完全検出優先の同期を実行できません。

完全検出優先の例 ^目次

同期の前に、A、X、Y、Bという構造が公開レジストリに存在し、A、X、Bという構造が検出レジストリに存在すると想定します。

完全検出の同期では、公開レジストリからA、X、Y、Bの構造が削除され、検出レジストリにあるA、X、Bの構造で置換されます。

承認プロセスのメール通知 ^目次

承認プロセスでは、関係者に通知するためにメールが送信されます。承認者には、リクエスタが承認を要求したり、承認リクエストを取り消すことなどがメールで通知されます。リクエスタには、承認者がリクエストを承認することや、リクエストを否認することなどがメールで通知されます。メールの書式はXSLTによって決まり、変更可能です。

デフォルトでは、次のXSLTが使用されます。XSLTは、該当するtModelのキーで指定します。uddi:systinet.com:approval:defaultRequestEmailXSLTは、リクエスタが承認リクエストを送信することについて承認者に通知する場合に使用されます。uddi:systinet.com:approval:defaultMessageEmailXSLTは、承認リクエストを取消し、承認または否認することについて承認者およびリクエスタに通知する場合に使用されます。

ユーザーが自身でXSLTを定義すると、メールの書式を変更できます。この場合、デフォルトのXSLTではなく、定義したXSLTがアカウントに指定されます。ユーザーは、そのアカウントに専用のプロパティを設定できます。approval.email.approver.request.tranformationという名前のプロパティには、新規に作成された承認リクエストについてのメール通知に対してカスタムのXSLTを指定します。承認者がこのプロパティ値にこのXSLTのキーを設定すると、受信するメール通知にはこのXSLTが使用されます。同様に、approval.email.approver.message.tranformationという名前のプロパティには、リクエストの取消、承認または否認についてのメール通知に対するカスタムのXSLTを指定します。ユーザーがデフォルト以外のメールを受信するには、このプロパティに新しいXSLTのキーを設定します。

	注意
	レジストリ・コントロールから承認プロセスを使用する場合は、メール通知の書式は、`approval.email.approval.message.tranformation.60`プロパティで指定されます。デフォルトでは、`uddi:systinet.com:approval:defaultMessageEmailXSLT_60` tModelで定義されたXSLTが使用されます。