前へ
次へ


承認プロセスの原則  目次

この項では、承認プロセスについて、管理者の立場から説明します。 ここでは、読者が「ユーザーズ・ガイド」の「Oracle Service Registryの承認プロセス」に記載されている承認プロセスの基本的な原則を理解していることを想定しています。

承認プロセスには、公開レジストリおよび検出レジストリという2タイプのレジストリがあります。公開レジストリは、データ精度のテストおよび検証に使用されます。ユーザーは、データを公開レジストリに公開します。検出レジストリには、承認されたデータが格納されます。 このレジストリにはPublishing APIはありませんが、問合せ、サブスクリプション、アカウントなどの他のOracle Service Registry APIはサポートされています。（実際には管理者はデータを検出レジストリに公開できますが、これは例外です）。

注意注意

ユーザー・アカウントを同期化できるように、公開レジストリと検出レジストリの両方を稼動させておく必要があります。検出レジストリが停止しているとき、公開レジストリに新しいユーザー・アカウントを登録することはできません。

公開レジストリと検出レジストリのアカウントはほとんど同じです。公開レジストリで作成されたアカウントおよびそのすべての変更は、検出レジストリにレプリケートされます。ただし、公開レジストリには存在しない、アカウントを検出レジストリに置くことができます。検出レジストリには読取り専用データが含まれているため、より多くのユーザーがアクセスできます。検出レジストリには、公開レジストリに存在しない、問合せ権限とサブスクリプション権限を持つアカウントを作成できます。この場合も、検出レジストリには公開APIは存在しません。（管理者を除き）データを検出レジストリに公開する唯一の方法は、承認プロセスを経由することです。

言い換えると、公開レジストリのすべてのアカウントは検出レジストリに存在しますが、検出レジストリのすべてのアカウントが公開レジストリに存在するとはかぎりません。

昇格が要求されると、自動コンテキスト・チェックによってデータの一貫性が確認されます。たとえば、あるビジネス・サービスが、承認リクエストに保存するためのキーに含まれていても、そのビジネス・エンティティが検出レジストリとリクエストの両方に存在しないと、承認のリクエストは受け入れられません。データの整合性が、自動コンテキスト・チェッカによって確認されます。エンティティが保存用のキーに含まれている場合は、親エンティティが検出レジストリにすでに存在するか、検出レジストリに保存するためのキーに含まれている必要があります。詳細は、「ユーザーズ・ガイド」の「コンテキストのチェック」を参照してください。

承認プロセスのロール  目次

前述のとおり、承認プロセス・レジストリには複数のロールが関係しています。

リクエスタ  目次

リクエスタとは、昇格するデータの承認を求めることができる、公開レジストリ上のユーザーを指します。ユーザーは誰でも承認を求めることができますが、リクエスタになるには、管理者によって割り当てられた承認コンタクトが必要です。

ユーザーに割り当てられている承認コンタクトが1つもないと、このユーザーが承認を求めたときに例外がスローされます。このようなユーザーがデータを検出レジストリに昇格させることはできません。管理者は、承認コンタクトを割り当てることによって、ユーザーがデータを検出レジストリに公開できるかどうかを指定します。

Oracle Service RegistryコンソールまたはAPIを経由してユーザーを作成するときに、公開レジストリに新たに作成されたユーザー全員に、デフォルトの承認者であるadministratorが割り当てられます。すべてのユーザーのデフォルトの承認コンタクトはadministratorですが、これは外部リポジトリ（LDAP）に定義されているユーザーには適用されません。デモ・データには、承認コンタクトは割り当てられていません。たとえば、ユーザーdemo_johnには承認者が割り当てられていないため、管理者はこのユーザーがリクエストを行うことができるように、承認コンタクトをこのユーザーに割り当てる必要があります。

リクエスタ・ロールの詳細は、「リクエスタのアクション」を参照してください。

承認者  目次

承認者とは、検出レジストリへの変更を承認する人またはグループのことです。承認コンタクトがグループの場合は、そのメンバー全員がデータの昇格を承認できます。

承認コンタクト・ロールの詳細は、「ユーザーズ・ガイド」の「承認者のアクション」を参照してください。

自動承認者  目次

承認プロセスには、自動承認者という特殊な承認コンタクトが存在します。このロールは、インストール時にレジストリに定義されます。管理者は、信頼されているユーザーの承認コンタクトとして自動承認者を設定できます。

これにより人による承認が不要となり、このようなユーザーのデータは、コンテキストのチェックに合格していれば、承認をリクエストしたときに、検出レジストリにコピーされます。

管理者  目次

管理者には、Oracle Service Registryを設定する役割があるため、承認プロセスを設定する役割も果たします。 管理者という用語は、レジストリを管理できるOracle Service Registryのユーザーを指します。承認プロセスを構成するパーミッションを持つすべてのユーザーは、リクエスタと承認コンタクト間の関係を設定できます。

リクエスタの承認コンタクトは、承認構成のマネージャが割り当てます。

承認者とリクエスタ間の関係を簡単に管理するために、既存のユーザーまたはグループから承認者またはリクエスタを作成できます。承認者がグループの場合は、このグループ内の各ユーザーがデータの昇格を承認できます。複数のユーザー（リクエスタ）が同じグループに属している場合は、承認コンタクトをグループ全体に割り当てることができます。

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

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

  • 各ビジネス・サービスにバインディング・テンプレートを含める必要がある。または

  • 各ビジネス・サービスを特定のカテゴリ別に分類する必要がある。

このようなポリシーを適用するために、開発者はこれらのチェックを実行するCheckerApiの実装を作成できます。承認者が「Approve request」ボタンを押すと、承認プロセス中に自動的にこの実装が呼び出されます。これにより、承認者は手動でデータを確認する必要がなくなります。

オプションのコンテンツ・チェックを設定するには、次の手順を実行します。

  1. org.systinet.uddi.approval.checker.v3.CheckerApiを実装するクラスを作成します。

  2. この実装クラスを使用可能にするには、次の2つの方法があります。

    • 実装クラスを含む.jarファイルをREGISTRY_HOME/app/uddi/services/Wasp-inf/libにコピーします。

    • CheckerApiインタフェースからcheckRequest()メソッドを実行し、選択したSOAPスタックにサービスをデプロイできるWebサービスを実装します。http://<host_name>:<http_port>/uddi/doc/wsdl/approval_checker.wsdlを使用して、Webサービスを生成します。

  3. Oracle Service Registryデータにコンテンツ・チェッカ・クラスの実装を登録します。

    1. チェッカ・サービスのWSDLを公開します。

      http://<host_name>:<http_port>/uddi/doc/wsdl/approval_checker.wsdlにあるWSDLを新しいビジネス・エンティティまたは既存のビジネス・エンティティに公開します。既存のWSDL portType（tModelの名前: CheckerApi、tModelのキー: uddi:systinet.com:uddi:service:porttype:approvalchecker）を再利用する必要があります。

    2. 新しいバインディング・テンプレートのアクセス・ポイントにチェッカを指定します。

      • レジストリのクラスパスにCheckerApiの実装を記述するには、アクセス・ポイントの値はclass:接頭辞で始め、その後に完全修飾されたクラス名を指定する必要があります。たとえば、class:com.systinet.uddi.approval.v3.approver.CheckerApiImplのように指定します。

      • チェッカをSOAP Webサービスとしてデプロイすると、アクセス・ポイントはこのサービスのエンド・ポイントURLになります。たとえば、http://localhost:6060/ContentCheckerのように指定します。

「開発者ガイド」の「コンテンツ・チェッカの書込み」に含まれている 実装例を参照してください。



前へ
次へ