明示的なパーミッションにより、指定のエンティティでアクションを処理するパーティにアクセス権を付与（許可のパーミッション）または取り消し（禁止のパーミッション）ます。

明示的なパーミッションは、特殊なkeyedReferenceとしてエンティティとともにcategoryBagに保存されます。詳細は、後述する「UDDI v3構造でのACLの設定」および「UDDI v1およびv2構造でのACLの設定」を参照してください。

エンティティの検索/取得アクションに明示的パーミッションが設定されていない場合は、誰でもそのエンティティを検索/取得できます。エンティティの保存/削除アクションに明示的パーミッションが設定されていない場合は、そのエンティティの所有者のみが保存/削除できます。これは、標準UDDIアクセス制御です。アクションに明示的パーミッションが設定されている場合は、次のルールに示す、別のアクセス制御が使用されます。

例:

ユーザーU1は、businessEntity BEを所有しています。ユーザーU1は、ユーザー・グループG1に対して明示的な取得許可パーミッションを定義します。BEに対する検索は、誰でも実行できます。検索に対する明示的パーミッションがなく、標準UDDIアクセス制御が使用されるためです。ただし、BEを取得できるのは、ユーザーU1（所有者）およびグループG1のユーザーのみです。

businessService BSは、businessEntity BE1からbusinessEntity BE2に移動できます。BS上でsave_service操作を実行すると、BSのbusinessKeyはBE2を指すように更新されます。このアクションを実行するには、パーティがBE1、BE2およびBSを保存するパーミッションを持っている必要があります。このいずれのエンティティも変更されるためです。

bindingTemplate BTも同じく、businessService BS1からbusinessService BS2に移動できます。この移動を行うパーティは、BS1、BS2およびBTに対する保存パーミッションを持っている必要があります。

businessEntity BE1に保存されているbusinessService BSを、businessEntity BE2に移動することができます。BSを移動するパーティは、BE2に対する保存パーミッションを持っている必要があります。

ACLのロジックでは、パーミッションの評価時に、あらかじめ作成されている特殊な抽象グループが考慮されます。 これらの抽象グループを使用すると、パブリッシャは特定のOracle Service Registryユーザー群にパーミッションを付与できます。

ACLパーミッションは、tModelに指定します。詳細は次のとおりです。

UDDI v3では、明示的なACLパーミッションは、専用のkeyedReferenceGroupに、tModelKey uddi:systinet.com:aclとともに指定します。このkeyedReferenceGroupには、ACL tModelへのkeyedReferenceのみを含めることができます。これに含まれるkeyNameにのみ「user」および「group」を指定でき、keyValueには（keyName値に従って）ユーザーまたはグループの名前を含める必要があります。

たとえば、ユーザーdemo_johnは、次のbusinessEntityをその所有者でなくても保存（更新）できます。

<businessEntity xmlns="urn:uddi-org:api_v3">
  ...
  <categoryBag>
    ...
    <keyedReferenceGroup tModelKey="uddi:systinet.com:acl">
      <keyedReference tModelKey="uddi:systinet.com:acl:save-allowed"
      keyName="user" keyValue="demo_john"/>
      ...
    </keyedReferenceGroup>
  </categoryBag>
</businessEntity>
  

UDDIのバージョン1および2では、明示的なACLパーミッションをcategoryBagの専用のkeyedReferenceに指定します。このkeyedReferenceは、ACLパーミッションを表しているtModelの1つを参照します。これに含まれるkeyNameには、「user」および「group」のみを指定でき、keyValueには（keyName値に従って）ユーザーまたはグループの名前を含める必要があります。

たとえば、ユーザーdemo_johnは、次のbusinessEntityをその所有者でなくても保存（更新）できます。

<businessEntity ...>
  ...
  <categoryBag>
    <keyedReference tModelKey="uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4"
                                         keyName="user" keyValue="demo_john"/>
    ...
  </categoryBag>
</businessEntity>
        

	注意
	bindingTemplate構造には、UDDI v1/v2のcategoryBagがないため、ACLパーミッションを設定できません。

キー・ジェネレータtModelは、domain:keygenerator形式のキーがあるtModelです。このtModelを使用すると、その所有者はdomain:string形式のキーで、構造を保存できます。たとえば、tModel uddi:systinet.com:uddiRegistry:demo:keygeneratorにより、キーを使用して次のように構造を公開できます。

いずれも、uddi:systinet.com:uddiRegistry:demoドメインの派生キーです。

例外として、キー・ジェネレータtModelではuddi:systinet.com:uddiRegistry:demo:businessService:exchangeRateなどサブドメインに基づくキー（つまり、uddi:systinet.com:uddiRegistry:demo:businessServiceの派生キー）を保存できません。

ただし、キー・ジェネレータtModelでは、直接のサブドメインごとにキー・ジェネレータを保存できます。たとえば、ユーザーはuddi:systinet.com:uddiRegistry:demo:businessService:keygeneratorを保存できます。この2つ目のキー・ジェネレータを作成した後に、ユーザーはuddi:systinet.com:uddiRegistry:demo:businessService:exchangeRateなどのuddi:systinet.com:uddiRegistry:demo:businessServiceドメインのキーで構造を保存できます。

	重要
	ドメインのキーを生成するには、ユーザーはそのドメインのキー・ジェネレータtModelを所有している必要があります。キー・ジェネレータtModelがなくても、割り当てたキーを使用して構造を保存できるのは、管理者のみです。管理者以外のユーザーにもこの処理を実行できるようにするには、管理者がドメインのtModelを保存し、管理転送によってその所有権を目的のユーザーに変更する必要があります。詳細は、「管理転送の公開」を参照してください。

前述のルールにより、同じキーを持つ構造を2人のユーザーが作成することはできません。1人のユーザーがキーを保持したままUDDI構造をレジストリ間でコピーしようとすると、複雑な状況が発生します。次の2つの問題があります。

アフィリエート・レジストリのメカニズムによって、両方の問題が解決されます。アフィリエーションとは、2つのレジストリ間の関係です。コピー元のレジストリはあるドメインのキーの生成を断念し、この権限をコピー先のレジストリに移管します。これで、両レジストリのキーが一意になります。

	注意
	この後の例では、2つのレジストリをマスター（master）とスレーブ（slave）とします。また、3人のユーザーがいます。 ユーザー1はマスター・レジストリの管理者で、このアカウントはmaster-adminです。 ユーザー2は、スレーブ・レジストリの管理者（アカウントslave-admin）であり、マスター・レジストリの共通ユーザー（アカウントmaster-user2）です。 ユーザー3は、スレーブ・レジストリの共通ユーザー（アカウントslave-user3）であり、マスター・レジストリの共通ユーザー（アカウントmaster-user3）です。

次の例では、範囲問合せの使用法を示します。find_businessリクエストのcategoryBagに記述するkeyedReferenceについて考えてみます。

greaterThan  categoryBagでtModelKeyがtmKeyと等しく、かつkeyValueがkvよりも大きいkeyedReferenceを持つビジネス・エンティティのみが返されます。

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>greaterThan</findQualifier>
   </findQualifiers>
</keyedReference>
        

greaterThanおよびlesserThan  categoryBagで、tModelKeyがtmKeyと等しく、かつkeyValueがkvと等しくないkeyedReferenceを持つビジネス・エンティティのみが返されます。

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>greaterThan</findQualifier>
      <findQualifier>lesserThan</findQualifier>
   </findQualifiers>
</keyedReference>
        

notExists categoryBagでtModelKeyがtmKeyと等しくなく、かつkeyValueがkvと等しくないkeyedReferenceを持つビジネス・エンティティのみが返されます。

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
   </findQualifiers>
</keyedReference>

notExistsおよびgreaterThan categoryBagでtModelKeyがtmKeyと等しくなく、かつkeyValueがkv以下であるkeyedReferenceを持つビジネス・エンティティのみが返されます。

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
      <findQualifier>greaterThan</findQualifier>
   </findQualifiers>
</keyedReference>

notExists、greaterThan、およびequal categoryBagでtModelKeyがtmKeyと等しくなく、かつkeyValueがkv未満であるkeyedReferenceを持つビジネス・エンティティのみが返されます。

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
      <findQualifier>greaterThan</findQualifier>
      <findQualifier>equal</findQualifier>
   </findQualifiers>
</keyedReference>

デモ、「高度な照会 - 範囲問合せ」を参照してください。

分類（値セット。UDDI仕様の用語）とは、categoryBag、identifierbagsまたはpublisherAssertionsで使用できるtModelのことです。 このtModelは、特定の形式に従っている必要があります。これによってOracle Service Registryが分類として認識することができます。tModelは、分類のタイプでカテゴリ化する必要があります。また、必要に応じてkeyedReferenceの値を検証するかどうか、検証する場合は検証方法についての情報で分類することもできます。

UDDIの仕様では、分類のタイプがカテゴリ化、categorizationGroup、識別子およびリレーションシップの4つに分けられています。

分類のパブリッシャは、分類内でkeyedReferenceの値をチェックするかどうかを設定できます。

分類の作成者は、UDDIエンティティのカテゴリ化に使用するカテゴリ化分類にsystinet-com:isOrderedBy分類の適切なコンパレータ参照（コンパレータtModel）を割り当てることによって、keyValueの型を指定する必要があります。次のkeyValue型がサポートされています。

たとえば、数値型のkeyValueを設定したカテゴリ化分類のtModelでは、そのcategoryBagに次のkeyedReferenceを指定する必要があります。

<keyedReference tModelKey="uddi:systinet.com:isOrderedBy"
   keyValue="uddi:systinet.com:comparator:numeric"/>
        

図42 数値カテゴリ化の例

図42に、デモ・データのdemo:location:floor分類に数値型のkeyValueを割り当てる方法を示します。

	重要
	ユーザーが分類のkeyValue型を変更した際、Oracle Service Registryにその分類ですでにカテゴリ化されたエンティティがある場合には、Oracle Service Registry管理者はTransform keyed references（キー参照の変換）作業を行う必要があります。この作業を行うボタンは、「Registry management」リンクの「Manage」タブの下のレジストリ・コントロールにあります。「管理者ガイド」の「レジストリ管理へのアクセス」を参照してください。

カスタム序数タイプ  ^目次

カスタム序数タイプを定義できます。 使用可能な拡張を示すため、Oracle Service Registryには次の2つのデモ・コンパレータが含まれています。

• systinet-com:comparator:date

• systinet-com:comparator:stringToLowerCase

keyValueに日付値を指定して分類を作成する場合を考えてみます。分類のtModelに、<keyedReference tModelKey="uddi:systinet.com:isOrderedBy" keyValue="uddi:systinet.com:comparator:date"/>を指定する必要があります（つまり、このkeyedReferenceをcategoryBagに追加します）。この処理は、レジストリに日付のデモ・コンパレータがあるため非常に簡単です。この日付コンパレータがない場合を考えてみます。日付コンパレータをレジストリに作成するには、次の手順を実行します。

1. 日付値を文字列値または数値に変換する変換サービスを作成します。 変換サービスには、TransformerKeyedReferenceApiを実装し、このクラスをOracle Service Registryクラス・パスに追加します。

2. 日付のコンパレータtModelを新規に作成します。このtModelは、systinet-com:comparator分類を使用してコンパレータとしてカテゴリ化します。そのコンパレータで、変換サービスを参照します。この参照は、分類IsTransformedByで指定します（ここでは、"uddi:cba104c0-fb5c-11d8-8761-eb2505508761"が、変換サービスが指定されているbindingTemplateのキーです）。

	重要
	分類の変換サービスの実装を変更したときに、Oracle Service Registryにその分類ですでにカテゴリ化されたエンティティがある場合、Oracle Service Registry管理者はTransform keyed references（キー参照の変換）作業を行う必要があります。この作業を行うボタンは、「Registry management」リンクの「Manage」タブの下のレジストリ・コントロールにあります。「管理者ガイド」の「レジストリ管理へのアクセス」を参照してください。

図43に、日付のカテゴリ化を順序付けするtModel参照を示します。 この図では、XML-to-UDDI機能によってOracle Service Registryにマップされ、その後acceptancedate分類でカテゴリ化された注文伝票を示しています。そのカテゴリ化分類は、日付変換サービスの場所が指定されたbindingTemplateを参照するコンパレータtModel uddi:systinet.com:comparator:dateを参照する必要があります。

図43  カテゴリ化（日付）のカスタマイズ例

該当するkeyedReferenceが処理されるときに、変換サービスが呼び出されます。カスタム・タイプの分類tModelを使用したkeyedReferenceがエンティティに含まれている場合は、そのkeyedReferenceの正しい（変換後の）keyValueを検出するために、変換サービスが呼び出されます。このような変換後の値がデータベースに保存されます。このkeyedReference（同じ分類tModelのkeyedReference）でエンティティを検索すると、再度サービスが呼び出されて変換後の値が取得されます。変換後の値は、keyedReferenceの保存および検索に使用されます。

分類タイプを編集する方法については、「管理者ガイド」の「分類の編集」を参照してください。

この項では、分類APIおよび分類の永続形式に関する基本事項を示します。分類APIの包括的な説明は、「開発者ガイド」の「分類」を参照してください。

	注意
	わかりやすくするため、ここではXML表現を使用しますが、Javaオブジェクトでも同じ結果が得られます。

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0"
        xmlns:uddi="urn:uddi-org:api_v3"
         check="false">
    <tModel tModelKey="uddi:systinet.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
</taxonomy>
  

各分類を保存できるようにするには、有効なtModelが必要です。tModelには、tModelKeyと名前を含める必要がありますが、categoryBagの内容を設定する必要はありません。

前述の例を使用して、unchecked分類をchecked分類に変換してみます。checked分類には、検証を含める必要があります。この例では、http://www.foo.com/MyValidationService.wsdlにあるカスタム検証Webサービスで分類をチェックしています。

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0"
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <bindingTemplate bindingKey="" serviceKey="" xmlns="urn:uddi-org:api_v3">
            <accessPoint useType="endPoint">
               http://www.foo.com/MyValidationService.wsdl
            </accessPoint>
            <tModelInstanceDetails>
                <tModelInstanceInfo
                        tModelKey="uddi:uddi.org:v3_valueSetValidation"/>
                <tModelInstanceInfo
                        tModelKey="uddi:systinet.com:demo:myTaxonomy"/>
            </tModelInstanceDetails>
        </bindingTemplate>
    </validation>
</taxonomy>
  

validation要素には、検証Webサービスまたはカテゴリの構造を指定したbindingTemplateを含める必要があります。この例では、すでにbindingTemplateが選択されています。そのbindingTemplateには完全なaccessPointを含める必要があり、tModelInstanceDetailでは保存済分類のValueset_validation APIおよびtModelKeyを保持する必要があります。serviceKeyを指定し、かつbusinessServiceがすでに存在する場合、そのbusinessServiceは操作可能なビジネス・エンティティの一部である必要があります。

	重要
	このサービスは、save_taxonomyの実行時に置き換えられます。

許可された値を指定できる場合は、独自の検証Webサービスを実装する必要はありません。次のように、categories構造に許可された値を指定するだけです。後は内部検証サービスがkeyedReferenceの検証を実施します。

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0"
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <categories>
            <category keyName="Value A" keyValue="A"/>
            <category keyName="Value B" keyValue="B">
                <category keyName="Value B1" keyValue="B1"/>
                <category keyName="Value B3" keyValue="B3" disabled="true" />
            </category>
            <category keyName="Value C" keyValue="C"/>
        </categories>
    </validation>
</taxonomy>
  

ここに示すとおり、階層的に値を配置できます。これは、ドリルダウン・パターンを実装するレジストリ・コントロールで有効です。必要な場合は、bindingTemplateにcategories構造を指定することもできますが、accessPointに内部検証サービスを指定する必要があります。

Oracle Service Registryには、次の分類があらかじめ用意されています。

レジストリ・コントロールは、次のオブジェクトで構成されています。

A: メイン・メニュー・タブ 

B: メニュー・バー ここにはサブメニュー・オプションがあります。

図47 レジストリ・コントロール概要

C: 履歴パス（ブレッドクラム） この領域には、最近実行したアクションのログが表示されます。ハイパーリンクをクリックすると、この以前のアクションのいずれにも戻ることができます。

D: ユーザー・アクション この領域にはコントロール要素がいくつか含まれており、ユーザーは次の操作を実行できます。

E: ツリー表示領域 利用可能なオブジェクトのツリーが適宜表示されます。このツリーは、ビジネス・エンティティおよびその子オブジェクトを表示する場合、およびユーザーがUDDIワークスペースの階層概要を必要とする場合（公開する場合など）に表示されます。

F: メイン表示領域  タブおよびツリー表示から選択した情報が使用可能になります。

G: 表示タブ  これらのタブでは、ユーザーが情報タイプに基づいてメイン領域の表示を制御できます。プレーンなリストにビジネス・プロパティをすべて掲載しようとすると、長すぎて読みづらくなります。ビジネス・プロパティをいくつかのタブに分けると、情報量が減り、読みやすくなります。表示される情報はコンテキストによって変化します。

H: アクション・ボタン メイン表示の内容に対して操作を実行できます。

I: 「Show/Hide」ボタン ツリー表示領域の非表示と表示を切り替えることができます。

J: アクション・アイコン この領域にはアイコンが2つあります。1つ目のアイコンはページ内容をリフレッシュし、もう1つのアイコンは製品ドキュメント・ページを開くことができます。

K: アクション・アイコン この領域のアイコンでは、表示タブのオン/オフを切り替えたり、現在のページをプリンタ優先モードで開くことができます。

L: コンテキスト・メニュー 図48に示すコンテキスト・メニューは、ツリー表示領域でノードのアイコンを右クリックすると表示されます。

図48 コンテキスト・メニュー

詳細は、図47を参照してください。

「Profile」メニュー・タブでは、ユーザー・アカウント、ユーザー・グループおよびお気に入りの分類を管理できます。

図49 「Profile」メニュー・タブ

アカウント・プロパティを更新するには、「My account」を選択し、「Edit account」ボタンをクリックします。

図50 アカウントの表示

フィールドの説明（説明がなくてもわかるようなフィールドは省略）

ユーザー・グループをメンテナンスするには、「Groups」リンクをクリックします。「Groups」画面から、次の処理を実行できます。

図51 ユーザー・グループの表示

お気に入りの分類  ^目次

「Profile」タブでは、お気に入りの分類を管理できます。お気に入りの分類のリストに含める分類を定義できます。お気に入りの分類を使用すると、UDDIエンティティを検索およびカテゴリ化するのが容易になります。

お気に入りの分類のリストを管理するには、次の手順を実行します。

1. 「Profile」メニュー・タブをクリックします。「favorite taxonomies」リンクをクリックします。図53に示すように、お気に入りの分類のリストが表示されます。

2. 分類を名前で検索するには、「Filter」をクリックします。

3. リストに含めるすべての分類のボックスを選択し、右向きの矢印をクリックしてこれらの分類をお気に入りの分類の表にコピーします。

4. 分類を追加した後、「Save」ボタンをクリックしてレジストリを更新します。

図53 お気に入りの分類の管理

この項では、分類構造をブラウズして、分類でカテゴリ化または識別されるUDDIエンティティを検出する方法について説明します。また、分類フィルタを定義し、問合せに検索基準を設定できます。 Oracle Service Registryには、あらかじめデモ・データ・セットがインストールされています。このデモ・セットは、レジストリの理解に役立つように作られています。

分類およびUDDIエンティティをブラウズするには、次の手順を実行します。

	注意
	「favorite taxonomies」オプションは、お気に入りの分類のリストが空でない場合にかぎり、ドロップダウン・リストに表示されます。お気に入りに分類を追加するには、お気に入りの分類の指示に従ってください。エンタープライズ分類のリストは管理者が定義します。詳細は、「管理者ガイド」の「分類管理」を参照してください。

最初「filter」には、システム分類以外の分類がすべて含まれています。ドロップダウン・リストの横のアイコンは、カテゴリ化されたエンティティの表示/非表示および空のカテゴリのすべて表示/非表示に使用します。

分類カテゴリをすべて表示するには、分類ツリーをドリルダウンします。サブカテゴリがある分類カテゴリは展開および縮小できます。

内部checked分類をブラウズすると、その値セットを表示して、それぞれのキー値でカテゴリ化されたUDDIエンティティを参照できます。unchecked分類または外部checked分類については、キー値でUDDIエンティティを検索できます。デモ・データからunchecked分類をブラウズする方法を次に示します。

demo:location:floor分類を使用してデモ・データをブラウズするには、次の手順を実行します。

また、問合せにこの検索基準を追加することもできます。

フィルタの定義  ^目次

分類フィルタを定義すると、分類リストの分類の数を削減できます。分類ブラウズからフィルタ定義に切り替えるには、左下隅の「filter」リンクをクリックします。図56に示すページが表示されます。

図56 分類フィルタ

ワイルド・カード文字%および_を使用して、名前で分類をフィルタ処理できます。分類タイプ、互換性および検証タイプを指定できます。フィルタ基準を定義した後、「Apply filter」をクリックします。「browse taxonomy」ページに戻ります。

問合せの定義  ^目次

検索基準を問合せに結合することもできます。検索基準を問合せに追加するには、図55に示すように「Add to query」ボタンを使用します。続いて、別の分類を展開し、新しい基準を指定できます。図57に示すページには、本部を上層部門として持ち（demo:hierarchy taxonomy）、5階にある（demo:location:floor taxonomy）ビジネス・エンティティを戻す問合せが表示されています。

図57 問合せ

問合せからカテゴリを削除するには、問合せを右クリックし、コンテキスト・メニューから「remove from query」を選択します。

	注意
	問合せ定義は永続的ではありません。「Browse」メニュー・タブを終了するとただちに、問合せは表示されなくなります。

Oracle Service Registryの検索機能では、次の検索を実行できます。

「検索」の項では、あらかじめOracle Service Registryにインストールされているデモ・データ・セットを使用します。このデモ・セットは、レジストリの理解に役立つように作られています。

	注意
	Oracle Service Registryでは、ワイルド・カード文字がサポートされています。%と_の両方を使用できます。 %は、任意の数の文字および空白のかわりに使用します。たとえば、Aで始まるビジネスをすべて検索する場合は、A%と入力します。アンダースコア・ワイルド・カード（_）は、任意の1文字のかわりに使用します。たとえば、DanまたはDaneを検索するには、Dan_と入力します。

範囲問合せ機能の使用方法については、カテゴリによるビジネスの検索を参照してください。

ビジネスの検索  ^目次

この項では、様々な方法を使用してビジネス・エンティティを検索する方法を説明します。ビジネス・エンティティは、次の項目で検索できます。

• 名前

• カテゴリ

• 識別子

• 検出URL

• tModel

どの検索方法でも、「Search」パネルの「Find Qualifiers」タブにある修飾子を指定できます。

図58 検索修飾子

名前によるビジネスの検索  ^目次

ビジネスを名前で検索するには、次の手順を実行します。

1. メインの「Search」タブで、「Businesses」リンクをクリックします。

2. 「Search」パネルの「Add Name」ボタンをクリックします。

3. ビジネス名を入力します。インストールされているデモ・データではITとなっています。次に、右下隅の「Find」タブをクリックします。

   ビジネスをすべて表示するには、ワイルド・カード%を入力し、「Find」をクリックします。

4. 検索結果が、「Results」パネルに表示されます。ビジネス名のリンクをクリックすると、図59に示すページが開きます。

   図59 ビジネス詳細の表示

   

カテゴリによるビジネスの検索  ^目次

この項では、カテゴリでビジネス・エンティティを検索する方法について説明します。デモ・データを使用して、特定の階にある部門をすべて検索する方法について説明します。また、範囲問合せの使用例も示します。

カテゴリでビジネスを検索するには、次の手順を実行します。

1. メインの「Search」タブで、「Businesses」リンクをクリックします。

2. 「Categories」タブをクリックし、「Add category」ボタンをクリックします。利用可能な分類のリストが表示されます。

   「all taxonomies」を表示するには、「Show」ドロップダウン・リストで「favorite taxonomies」から切り替えます。「favorite taxonomies」を管理するには、ユーザー・プロファイルを参照してください。

3. 目的の分類をクリックします。

   分類はツリーとして表示され、そのサブブランチにはカテゴリが含まれています。

   デモ・データからdemo:location:floorを選択します。

4. 「Key name」および「Key value」を入力できるようになりました。

   「Key value」ボックスに1と入力し、「Add category」アイコンをクリックします。

   図60 カテゴリによるビジネスの検索

   

5. カテゴリを検索基準として追加した後、「Find」をクリックします。

1階にある部門が表示されます。2階以上の部門をすべて検索する場合は、範囲問合せ機能を使用する必要があります。前の検索を続行します。

1. 「Search」タブをクリックして、「Find business by categories」ページに戻ります。

2. 「Edit category」アイコンをクリックします。図61に示すページが表示されます。

   図61 範囲カテゴリによるビジネスの検索

   

3. 「Operator」ドロップダウン・リストから、>演算子を選択し、「Update」アイコンをクリックします。

4. 「Find」をクリックします。2階以上の部門がすべて表示されます。

識別子によるビジネスの検索  ^目次

この項では、識別子でビジネス・エンティティを検索する方法について説明します。デモ・データを使用して、部門番号識別子で部門を検索する方法について説明します。

識別子でビジネスを検索するには、次の手順を実行します。

1. メインの「Search」タブで、「Businesses」リンクをクリックします。

2. 「Identifiers」タブをクリックします。次に、「Add identifier」ボタンをクリックします。利用可能な分類のリストが表示されます。

3. 目的の分類をクリックします。

   分類はツリーとして表示され、そのサブブランチにはカテゴリが含まれています。

   デモ・データからdemo:departmentIDを選択します。

4. 「Key name」および「Key value」を入力できるようになりました。

   「Key value」ボックスに002と入力し、「Add identifier」をクリックします。

   図62 識別子によるビジネスの検索

   

5. 識別子を検索基準として追加した後、「Find」をクリックします。

検出URLによるビジネスの検索  ^目次

検出URLでビジネス・エンティティを検索するには、次の手順を実行します。

1. メインの「Search」タブで、「Businesses」リンクをクリックします。

2. 「Discovery URLs」タブを選択します。

3. 検出URLに値を入力し、「Find」をクリックします。

直接取得  ^目次

検索するUDDI構造のキーがわかっている場合には、「Search」メニュー・タブの「Direct get」を使用して、Oracle Service Registryからデータを取得することもできます。 Oracle Service Registryでは、UDDI Version 2とUDDI Version 3のいずれのキーも指定できます。UDDI v2キーを使用して検索する場合は、「Find by v2」タブをクリックします。

図63 直接取得

XML構造の直接取得  ^目次

URIに構造のキーを入力することで、自動処理に使用されるXML形式のビジネス、サービス、バインディングおよびtModelを取得することもできます。

URIの形式は、次のとおりです。

http://<hostname>:<port>/<context>/uddi/web/directGetXml?<structureKey>=<key>

URIの例 デフォルトではUDDI v3とみなされます。

• http://localhost:8888/registry/uddi/web/directGetXml?businessKey=uddi:systinet.com:uddinodebusinessKey

• http://localhost:8888/registry/uddi/web/directGetXml?serviceKey=...

• http://localhost:8888/registry/uddi/web/directGetXml?bindingKey=...

• http://localhost:8888/registry/uddi/web/directGetXml?tModelKey=...

ログインの例 このURIには、ユーザー名およびパスワードが含まれています。

• https://localhost:8888/registry/uddi/web/directGetXml?businessKey=uddi:systinet.com:uddinodebusinessKey&userName=admin&password=changeit

UDDI Version仕様を使用した例 この形式は、v1およびv2の構造に関する情報を取得する場合に使用します。

• http://localhost:8888/registry/uddi/web/directGetXml?businessKey=8f3033d0-c22f-11d5-b84b-cc663ab09294&version=2

WSDLの検索  ^目次

Oracle Service Registryに公開されたWSDLドキュメントをすべて検索できます。 WSDLの場所へのURIを指定すると、WSDLドキュメントのアーティファクトがOracle Service Registryにどのように公開されているかを確認できます。WSDLドキュメントの場所、tModelキー、ビジネス・サービス・キーおよびバインディング・テンプレート・キーを、基準として使用できます。 Oracle Service RegistryのWSDLドキュメントを検索するには、次の手順を実行します。

1. 「Search」メニュー・タブを選択し、「WSDL」リンクをクリックします。図64に示すページが表示されます。

2. 「Find all published WSDLs」をクリックします。あるいは、

   「WSDL location URI」に値を入力し、「Examine this WSDL」ボタンをクリックします。

図64 WSDL検索

XMLの検索  ^目次

XML文書の場所へのURIによって、Oracle Service RegistryでXML文書を検索できます。

XML文書を検索するには、次の手順を実行します。

1. 「Search」メニュー・タブを選択し、「XML」リンクをクリックします。図65に示すページが表示されます。

2. 場所を入力し、「Find」をクリックします。

図65 XML文書の検索

XSDの検索  ^目次

XML文書の場所へのURIによって、Oracle Service RegistryでXMLスキーマを検索できます。

XML文書を検索するには、次の手順を実行します。

1. 「Search」メニュー・タブを選択し、「XSD」リンクをクリックします。図66に示すページが表示されます。

2. XMLスキーマ文書の場所、名前空間、XMLスキーマ文書に定義されているxsd:elementsおよびxsd:typesで検索できます。検索基準を指定した後、「Find」をクリックします。

図66 XSD検索

XSLTの検索  ^目次

XSLTを検索するには、次の手順を実行します。

1. 「Publish」メニュー・タブを選択し、「XML」リンクをクリックします。図67に示すページが表示されます。

2. XSLTの場所を入力できます。また、入力および出力XMLスキーマに従って検索することもできます。XMLスキーマの検索基準は、tModelキーまたは名前空間で指定できます。「Select XML Schema」をクリックすると、XMLスキーマに対してさらに基準を指定して、XMLスキーマ・リストからXMLスキーマを選択できます。

3. XMLスキーマに従って検索するように指定した場合には、「Find」をクリックする前に、「Update」アイコンをクリックします。

図67 XSLT検索

Oracle Service Registryへの公開は、いくつかの構成要素からなります。

	注意
	公開するには、Oracle Service Registryにログインする必要があります。ユーザーが保存できるUDDI構造の数には制限があります。「管理者ガイド」の「アカウント制限」を参照してください。

メイン公開ページは、2つのパネルに分かれています。左側のパネルには、ログインしたユーザーに所属するUDDIデータ構造か、またはそのユーザーがアクセス権限を持つUDDIデータ構造が表示されます。右側のパネルには、左側のパネルで選択したデータ構造の詳細が表示されます。構造を選択しない場合は、図に示すように、ビジネスおよびtModelを追加するためのボタンが表示されます。

図68 公開ページ

ビジネスの公開  ^目次

この項では、businessEntityを公開し、businessEntity関連の構造を編集する方法について説明します。

• ビジネス名および説明の追加

• 連絡先の追加

• 検出URLの追加

• カテゴリの追加

• 識別子の追加

• ビジネス・サービスの追加

• 計画されたサービスの追加

• ビジネス・リレーションシップのアサート

ビジネスを公開するには、次の手順を実行します。

1. 公開ページの右側のパネルで「Add Business」ボタンをクリックするか、または「Business Entities」ノードを右クリックすると表示されるコンテキスト・メニューから「Add Business」を選択します。

   図69 ビジネスの追加

   

2. ビジネス名および説明を入力し、「Add Business」をクリックします。

3. ビジネスが、左側のツリー・パネルの「Business entities」ノードの下に表示されます。

ビジネス・エンティティを編集するには、次の手順を実行します。

1. 「Publish」メニュー・タブを選択します。

2. 「Publish」リンクをクリックします。

3. 左側のツリー・パネルで、編集するビジネス・エンティティ・ノードをクリックします。

   図70 ビジネスの編集

   

4. ビジネス・エンティティを変更した後、「Save changes」ボタンをクリックします。

連絡先の追加  ^目次

連絡先構造には、ビジネス・エンティティに関連する人物を一覧表示できる領域があります。この領域には、名前、電話、電子メール、住所、説明および使用タイプの6つのプロパティがあります。

説明フィールドには、連絡先の使用方法に関する簡単な説明を記載しておくことをお薦めします。

使用タイプには、その連絡先をどのような目的で使用するかを示すことができます。たとえば、新規フランチャイズ、営業先、技術的な質問などです。

連絡先を追加するには、次の手順を実行します。

1. 「Edit business」ページまたは「View business」ページの「Contacts」タブで、「Add contact」ボタンをクリックします。図71に示すように、連絡先の名前および使用タイプを指定できる「Add contact」ページが表示されます。

   図71 連絡先の追加

   

2. 「Add contact」をクリックします。

3. 説明、電話番号および住所の情報リストを作成します。住所収集以外の各収集ページは、いずれも同じように機能します。追加する要素の「Add」ボタンをクリックします。2つ以上の編集フィールドが作成されます。

   	重要
   	フィールドを編集した後、右側の「Update」アイコンをクリックする必要があります。

   住所の場合は、「Addresses」タブをクリックします。このタブでは、該当するボタンをクリックすることによって、既存の住所構造を追加、編集または削除します。

   住所を追加または編集するときは、目的のフィールドにデータを入力し、リストにデータを追加します。終了するときは、「Update」をクリックします。

4. 連絡先の情報をすべて更新した後、「Edit contact」ページの最下部の「Save changes」をクリックします。新しい連絡先エントリの名前および使用タイプが連絡先リストに表示されます。

検出URLの追加  ^目次

検出URLを追加するには、次の手順を実行します。

1. 「Edit business」ページで、「Discovery URLs」タブの最下部の「Add discovery URL」ボタンをクリックします。

2. 「Discovery URL」および「Use Type」編集フィールドに適切なデータを入力します。

3. フィールドへの入力が完了した後、右側の「Update」をクリックしてこの情報をリストに追加します。

4. 「Save changes」をクリックします

カテゴリの追加  ^目次

広く使用されている多くの分類とビジネスを、カテゴリで関連付けすることにより、ビジネスの検索結果がより見やすくなります。このような分類カテゴリでは、ビジネスおよびそのサービスを、場所、製品、サービス・ラインおよび業種によって特定します。

Oracle Service Registryには、デフォルトで3つの基本的なchecked分類のキーが用意されています。ISO3166の地理的分類システム、NAICSおよびSICの業種製品分類です。

また、Microsoft GeoWeb2000にもキーが用意されていますが、unchecked分類であるため、キー名およびキー値を手入力する必要があります。

リストにカテゴリを追加するには、次の手順を実行します。

1. 「Edit business」ページの「Categories」タブで、「Edit」ボタンをクリックします。すでにこのビジネス・エンティティに関連付けられたカテゴリがある場合は、そのリストと「Add category」ボタンが表示されます。それ以外の場合は、このボタンのみが表示されます。

2. 「Categories」タブの下の「Add category」ボタンをクリックします。利用可能な分類のリストが表示され、その中からリストに追加するカテゴリを選択できます。

3. 使用可能な分類をクリックします。checked分類が、そのモデルに有効なカテゴリのツリーに展開されます。検索ボックスに既知のキー名を入力すると、データをより高速に取得できます。ブランチが大きい場合には、項目の数が1ページ当たり10個に制限されます。

4. また、分類フォームの最上部にある検索ボックスで分類の名前を検索することもできます。必要に応じて、「starts with」、「contains」および「exact match」の各ラジオ・ボタンを使用してください。いずれのボタンでも、標準のワイルド・カードと同様に、指定したとおりに入力文字列が検索されます。たとえば、パターンCanaを「starts with」ボタンおよび地理的分類と併用した場合、セット{"Canada" "Canarias"}が返されます。結果セットは、最大250項目に制限されます。

   	注意
   	検索パターンを広くしすぎると、結果リストが100項目で切り捨てられます。

   unchecked分類（たとえば、MicrosoftのGeoWeb分類）では、編集フィールドを使用してキー名およびキー値を指定できます。

5. uddi-org:iso-ch:3166:1999分類から複数のカテゴリ（たとえば、AlbaniaおよびArmenia）を追加するには、それぞれのキー名の右側のボックスを選択し、「Add category」をクリックします。別のページのカテゴリを追加する場合は、最初のページで「Add category」をクリックしてから、次の選択項目が含まれているページに進む必要があります。たとえば、AlbaniaおよびKazakhstanを選択するには、次の手順を実行します。

   1. Albaniaを選択し、「Add category」をクリックします。

   2. 「Find service」ページで「Add category」をクリックします。

   3. 展開された「Find service」ページで、8ページへのリンクをクリックします。

   4. Kazakhstanの横のボックスを選択し、「Add category」をクリックします。

   図72 カテゴリの追加

   

6. 目的の分類種別が見つかったら、checked分類の場合は「Add category」ボタンをクリックします。unchecked分類の場合は、編集フィールドに値を入力してから「Add category」をクリックします。

識別子の追加  ^目次

パブリックまたはプライベートの識別子（D-U-N-S、タックスナンバー、または地理ロケータ番号など）をレジストリに指定して、自分の組織を参照しやすくすることもできます。UDDI識別子構造は、次の要素で構成されています。

tModelキー

名前空間またはサービスを指定します。キー名およびキー値が重要です。

keyName

使用されるキーの名前または説明。

keyValue

キーの値。

リストに識別子を追加するには、次の手順を実行します。

1. 「Edit business」ページで、「Identifiers」タブに切り替えます。

2. 識別子リストの最下部にある「Add identifier」ボタンをクリックします。

3. 表示された分類tModelのリストから識別子タイプを選択します。キー名およびキー値を入力するフィールドが表示されます。

4. そのフィールドにデータを入力した後、右側の「Add identifier」ボタンをクリックして、この新しい識別子をリストに追加します。

	重要
	checked識別子のtModelを使用する場合は、キー値が識別可能な形式および値である必要があります。たとえば、uddi-org:isReplacedByキーを使用する場合は、keyValueフィールドに有効なビジネス・エンティティUUIDキーを指定する必要があります。指定しないと、データベースにビジネス・データを送信しようとしたときにエラーが発生します。

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

ビジネス・サービスを宣言および定義したら、今後のビジネス・パートナが、そのサービスにアクセス方法、検索できる場所を含めた、そのサービスの技術的な説明を用意する必要があります。これには、bindingTemplateを使用します。

bindingTemplateはWebサービス・インスタンスであり、ここから主に親ビジネス・サービスのインスタンスのアクセス・ポイントを取得することになります。どのbindingTemplateにも、識別に使用される一意のbindingKeyがあります。（アクセス・ポイントには、URL、電子メール・アドレス、電話番号など、サービスの場所を特定するために使用する連絡先情報が含まれています）。

bindingTemplate構造のaccessPointには、WebサービスのエンドポイントのURLを含めます。同じビジネス・サービスを提供するbusinessEntityが複数ある場合は、bindingTemplateのこの情報を再利用することをお薦めします。businessServiceにbindingTemplateを作成し、技術情報を保存します。それ以外のbusinessServiceには、技術情報を保存した1つ目のbindingTemplateのキーをaccessPointに含めたbindingTemplateを作成します。それぞれのaccessPointには、値hostingRedirectorを設定したuseTypesも含めてください。

	注意
	また、別のbindingTemplateへの参照をaccessPointではなくhostingRedirector構造に保存することもできます。ただし、hostingRedirector構造（useTypeのhostingRedirector値ではない）は、UDDI v2での構造であり、UDDI v3では非推奨になっています。

bindingTemplateを追加するには、次の手順を実行します。

1. 「Publish」メニュー・タブを選択し、「Publish」リンクをクリックします。

2. 左側のパネルで、bindingTemplateを追加するサービスをクリックします。右側の表示領域にサービス詳細が表示されます。「Bindings」タブをクリックし、「Add Binding」ボタンをクリックします。

   また、bindingTemplateを追加するサービス・ノードを右クリックし、コンテキスト・メニューから「Add Binding」を選択することもできます。

   図74  bindingTemplateの追加

   

tModelの公開  ^目次

tModelは、メタデータ（データに関するデータ）にキーを指定する形式の構造です。 一般的な意味では、Oracle Service Registry内でのtModelの目的は、抽象に基づく参照システムを提供することです。UDDIでtModelが果たす役割には、仕様または概念に準拠できるようにし、これを分類に記述することなどがあります。

tModelを公開するには、次の手順を実行します。

1. 「Publish」タブを選択し、「Publish」リンクをクリックします。

2. 右側の「Publish」パネルで、「Add tModel」ボタンをクリックします。

   また、左側のパネルのtModelノードを右クリックし、コンテキスト・メニューから「Add tModel」を選択することもできます。

   図75 tModelの追加

   

3. tModel名および説明を入力し、「Add tModel」ボタンをクリックします。

	注意
	使用されていないtModelを削除すると、そのtModelはデータベースから削除されます。 この動作を、tModelに削除済とマーク付けするだけの動作に変更することもできます。 「管理者ガイド」の「Node」を参照してください。

カテゴリの追加  ^目次

この項では、図42のように、demo:location:floor分類に数値の順序を指定する方法について説明します。

1. demo_johnユーザーとしてログオンします。（パスワードはユーザー名と同じです）。

2. メイン・メニューの「Publish」タブをクリックします。ページ左側のツリーで、tModel demo:location:floor項目をクリックします。「Edit tModel 'demo:location:floor'」ページが表示されます。

3. 「Add category」ボタンをクリックします。分類リストが表示されます。

4. 分類systinet-com:isOrderedByを選択し、「Key value」にuddi:systinet.com:comparator:numericと入力します。

5. 「Add category」ボタンをクリックし、「Save changes」ボタンをクリックします。

サブスクリプションの公開  ^目次

サブスクリプションを設定すると、Oracle Service Registryの変更に関する情報を通知するサービスに登録できます。サブスクリプションによって、UDDI構造の新規作成、変更および削除を監視できます。各サブスクリプションには、サブスクリプション有効範囲をレジストリ・エンティティのサブセットに制限するフィルタがあります。

特定の問合せまたは関係するエンティティのセットに基づいて、サブスクリプションを設定できます。問合せベースのサブスクリプションは、所定の期間内に結果セットが変更された場合にユーザーに通知します。エンティティ・ベースのサブスクリプションは、指定したエンティティの内容が変更された場合にユーザーに通知します。

サブスクリプションを設定すると、次の操作が可能になります。

• 新しいビジネスまたはサービスの登録の通知

• 既存のビジネスまたはサービスの監視

• プライベート・レジストリで使用するためのレジストリ情報の取得

• マーケットプレイスまたはポータル・レジストリで使用するためのデータの取得

このフィルタは、次の標準UDDI照会のいずれかを実行します。

• find_business

• find_relatedBusinesses

• find_service

• find_binding

• find_tModel

• get_businessDetail

• get_serviceDetail

• get_bindingDetail

• get_tModelDetail

図77 サブスクリプションの追加

サブスクリプションの追加  ^目次

新しいサブスクリプションを追加するには、次の手順を実行します。

1. 「Publish」メニュー・タブの下の「Subscriptions」リンクをクリックして、「Subscriptions」ページを表示します。

2. 「Add subscription」ボタンをクリックして、図77に示す「Add subscription」ページを表示します。

3. 「Change filter」をクリックして、サブスクリプションのフィルタを指定します。「Subscription filter type」ページが表示されます。

4. 「Subscription filter type」ドロップダウン・リストからフィルタ・タイプを選択します。

5. 「Select filter」をクリックします。

6. 通常の検索実行と同様に、フィルタ・プロパティを設定します。

7. 「Preview results」ボタンをクリックして、フィルタ結果を確認します。

8. 「Save filter」をクリックして、図77に示すフィルタ設定のページに戻ります。

9. 必要に応じて他のサブスクリプション・フィールドに値を入力します。次に、各フィールドについて説明します。

通知リスナー・タイプ  ^目次

図78 サブスクリプションの追加 - 電子メール通知リスナー・タイプ

• Subscription filter - どのUDDI構造の変更について通知するかを指定します。

• Notification listener type - 通知のリスナー・タイプを選択します。

  • 電子メール・アドレス

  • サービス・エンドポイント

  • バインディング・テンプレート

• Email address - 通知を送信する電子メール・アドレス。

• XSLT transformer tModel - XSLTを参照するtModel。

• Business serviceおよびBusiness entity - 通知リスナー・サービスを表すbindingTemplateが保存されるビジネス・サービスおよびビジネス・エンティティ。これらのドロップダウン・リストには、バインディング・テンプレートを作成するパーミッションをユーザーが持っているビジネス・エンティティおよびビジネス・サービスのみが一覧表示されます。

• Notification interval - サブスクライバに変更を通知する頻度を指定します。非同期通知にのみ必要です。

• Expires after - 管理者がサブスクリプションを存続させる期間を指定します。

• Max entities - サブスクリプション・リスナー宛の通知に含めるエンティティの最大数です。

• Brief - サブスクリプション・リスナーに返される詳細レベルを制御します。

図79 サブスクリプションの追加 - サービス・エンドポイント・リスナー・タイプ

• Subscription filter - どのUDDI構造の変更について通知するかを指定します。

• Notification listener type - 通知のリスナー・タイプを選択します。

  • 電子メール・アドレス

  • サービス・エンドポイント

  • バインディング・テンプレート

• Notification listener endpoint - 通知が送信されるURL

• Business serviceおよびBusiness entity - 通知リスナー・サービスを表すbindingTemplateが保存されるビジネス・サービスおよびビジネス・エンティティ。これらのドロップダウン・リストには、バインディング・テンプレートを作成するパーミッションをユーザーが持っているビジネス・エンティティおよびビジネス・サービスのみが一覧表示されます。

• Notification interval - サブスクライバに変更を通知する頻度を指定します。非同期通知にのみ必要です。

• Expires after - 管理者がサブスクリプションを存続させる期間を指定します。

• Max entities - サブスクリプション・リスナー宛の通知に含めるエンティティの最大数です。

• Brief - サブスクリプション・リスナーに返される詳細レベルを制御します。

図80 サブスクリプションの追加 - バインディング・テンプレート・リスナー・タイプ

• Subscription filter - どのUDDI構造の変更について通知するかを指定します。

• Notification listener type - 通知のリスナー・タイプを選択します。

  • 電子メール・アドレス

  • サービス・エンドポイント

  • バインディング・テンプレート

• Binding Template - 通知リスナー・サービスを表すbindingTemplate。

• Notification interval - サブスクライバに変更を通知する頻度を指定します。非同期通知にのみ必要です。

• Expires after - 管理者がサブスクリプションを存続させる期間を指定します。

• Max entities - サブスクリプション・リスナー宛の通知に含めるエンティティの最大数です。

• Brief - サブスクリプション・リスナーに返される詳細レベルを制御します。

サブスクリプションの編集  ^目次

既存のサブスクリプションを編集するには、次の手順を実行します。

1. 「Publish」メニュー・タブの下の「Subscriptions」リンクをクリックして、「Subscriptions」ページを表示します。

2. 編集するサブスクリプションの横の「Edit」ボタンをクリックします。「Edit subscription」ページが表示されます。ここでは、サブスクリプション・フィルタ以外のサブスクリプション引数を編集できます。

サブスクリプションの削除  ^目次

サブスクリプションを削除するには、次の手順を実行します。

1. 「Publish」メニュー・タブの下の「Subscriptions」リンクをクリックして、「Subscriptions」ページを表示します。

2. 削除するサブスクリプションの横のボックスを選択します。

3. 「Delete selected」ボタンをクリックします。確認ページが表示されます。

4. 確認ページには、削除対象としてマークされたサブスクリプションのリストが含まれています。リストが正しい場合は、「Yes」ボタンを押してサブスクリプションを完全に削除します。

管理転送の公開  ^目次

管理転送は、選択した構造（ビジネス・エンティティ、ビジネス・サービス、バインディング・テンプレートまたはtModel）の所有権をユーザー間で転送する場合に使用するサービスです。管理転送には、2つの手順があります。転送する構造の選択と管理転送トークンの生成です。新たな所有者となり得るユーザーが（暗号化電子メールなどセキュアなトランスポートで）管理転送トークンを受信すると、そのユーザーは管理転送を受け入れるか、または拒否します。

	重要
	このトークンは、機密事項です。知られると、その構造の管理を誰でも転送できるためです。

リクエストを取消す場合（たとえば、転送トークンの安全性が損なわれた場合）は、「Discard transfer token」ボタンを使用します。

管理転送のリクエスト  ^目次

管理転送をリクエストするには、次の手順を実行します。

1. 「Publish」メニュー・タブの下の「Custody」リンクをクリックして、「Custody transfer」ページを表示します。

2. 「Request transfer token」リンクをクリックします。所有するUDDIデータ構造のリストが表示されます。

3. 転送するUDDI構造の横のボックスを選択し、「Request transfer token」をクリックします。

4. 次ページで、転送トークンを生成します。転送トークンのテキストをファイルにコピーし、選択した構造の新しい所有者となるユーザーにそのファイルを送信します。トークンは機密事項です。知られると、誰でもそのトークンを使用して構造の管理を転送できるためです。たとえば、暗号化されていない電子メールは、データ転送には適していません。

管理転送の承認  ^目次

管理転送を受け入れるには、次の手順を実行します。

1. 「Publish」メニュー・タブの下の「Custody」リンクをクリックして、「Custody transfer」ページを表示します。

2. 「Transfer custody」リンクをクリックします。

3. 転送トークンが記載されたファイルを開き、その内容をクリップボードにコピーし、「Transfer structures」ページの編集領域に貼り付けます。

4. 「Transfer」ボタンをクリックします。

WSDLドキュメントの公開  ^目次

Oracle Service Registry WSDLからUDDI（WSDL2UDDI）へのマッピングは、OASISのテクニカル・ノート『Using WSDL in a UDDI registry Version 2.0』に準拠しています。これにより、WSDLドキュメントをUDDIに自動的に公開し、特定のWSDLアーティファクトおよびメタデータに基づいて正確かつ柔軟なUDDI問合せを可能にし、UDDI v2の一貫したマッピングを実現できます。

WSDLの公開  ^目次

WSDLドキュメントを公開するには、次の手順を実行します。

1. 「Publish」メイン・メニュー・タブの下の「WSDL」リンクをクリックします。

2. 図81に示すページが表示されます。

   図81 WSDLの公開

   

3. WSDLドキュメントでサービスを公開するビジネスの「Business key」を入力します。「Find business key」ボタンをクリックして、ビジネス・キーを検索できます。

4. 「WSDL location」を入力します。 REGISTRY_HOME/demos/conf/employeeList.wsdlからOracle Service RegistryデモのWSDLドキュメントを使用してみることができます。

5. 「Advanced mode」チェック・ボックスは選択しないで、「Publish」ボタンをクリックします。

WSDLドキュメントが、Oracle Service Registryに公開されます。 図82で、ドキュメントのWSDLアーティファクトがOracle Service Registryにどのようにマップされるかを確認できます。

図82 WSDLの公開の要約

WSDLドキュメントの公開（拡張モード）  ^目次

拡張モードで公開すると、WSDLドキュメントをUDDIレジストリにどのようにマップするかを詳細に指定できます。このモードで公開するには、前項の手順を実行します。ただし、「Advanced mode」チェック・ボックスを選択します。「Publish」ボタンをクリックすると、図83に示す「Advanced Mode Publish」ページが表示されます。

図83 WSDLの公開（拡張モード）

左側のツリー・パネルでは、WSDLドキュメントのアーティファクトがどのように公開されるかを参照できます。 WSDLアーティファクトをOracle Service Registryにマップする方法を編集するには、ツリーのブランチをクリックします。右側のパネルにマッピング・オプションの詳しい説明が表示されます。WSDLドキュメントの各部がレジストリにどのようにマップされるかを参照するには、「Preview」をクリックします。「Preview」ページから、WSDLマッピングの調整に戻ることができます。

図83に示すウィザードのデフォルトの選択内容は、次のルールに基づいています。

• WSDLアーティファクトの有効なマッピングがすでにレジストリに存在し、ユーザーがこのUDDI構造を所有している場合は、レジストリのそのマッピングを再書き込みすることを薦められます。

• WSDLアーティファクトの有効なマッピングがすでにレジストリに存在し、ユーザーがこのUDDI構造を所有していない場合は、そのUDDIエンティティを再利用することを薦められます。

• WSDLアーティファクトのマッピングがレジストリに存在しない場合は、マッピングを表すUDDIエンティティを新規に作成することを薦められます。

Oracle Service Registryでは、「Advanced mode」オプションを選択しないでWSDLドキュメントを公開すると、自動的にこれらのルールが適用されます。

	注意
	WSDLの公開と操作およびWSDLメッセージは、今回のリリースのOracle Service Registryには実装していません。

WSDLの非公開  ^目次

WSDL定義を非公開にするには、次の手順を実行します。

1. レジストリでWSDLドキュメントを検索します。

2. 結果ビューで、ビジネス・サービスをクリックします。

3. ビジネス・サービスの詳細が記載されたページが表示されます。このページの「Unpublish」ボタンをクリックします。

4. 「Unpublish WSDL document」ウィザードが表示されます。

XMLの公開  ^目次

Oracle Service Registry XMLからUDDI（XML2UDDI）へのマッピングを有効にすると、XML文書をUDDIに自動的に公開し、特定のXMLアーティファクトおよびメタデータに基づいて正確かつ柔軟なUDDI問合せを実現できます。

XML文書を非公開にする場合は、「Find XML」ボタンを使用し、検索結果ページの「Unpublish」ボタンをクリックします。

XML文書の公開  ^目次

XML文書を公開するには、次の手順を実行します。

1. 「Publish」メイン・メニュー・タブの下の「XML」リンクをクリックします。

2. 図84に示すページが表示されます。

   図84 XML文書の公開

   

3. 「XML location」を入力します。 デモを実行するには、Oracle Service RegistryデモのREGISTRY_HOME/demos/conf/employees.xmlファイルを選択します。

4. 「Advanced mode」チェック・ボックスを選択しないままにしておき、「Publish」ボタンをクリックします。

XML文書がOracle Service Registryに公開されます。図85で、XML文書がOracle Service Registryにどのようにマップされたかを確認できます。

	注意
	XML文書の内容はレジストリにコピーされません。

図85 XML文書の要約の公開

XML文書の公開 - 拡張モード  ^目次

拡張モードで公開すると、XML文書をUDDIレジストリにどのようにマップするかを詳細に指定できます。このモードで公開するには、前項の手順を実行します。ただし、「Advanced mode」チェック・ボックスを選択し、「Publish」をクリックします。図86に示す「Advanced Mode Publish」ページが表示されます。

図86 XML文書の公開 - 拡張

左側のツリー・パネルでは、XML文書の名前空間がどのように公開されるかを参照できます。 名前空間をOracle Service Registryにマップする方法を編集するには、その名前空間をクリックします。右側のパネルにマッピング・オプションの詳しい説明が表示されます。 XML文書およびその名前空間がOracle Service Registryにどのようにマップされるかを参照するには、「Preview」をクリックします。「Preview」ページから、XMLマッピングの編集に戻ることができます。

図87 XML文書の公開 - プレビュー

XML文書の非公開  ^目次

XMLの非公開により、Oracle Service RegistryからXMLマッピングを削除できます。XML文書を非公開にするには、まずそのXML文書を検索する必要があります。

XSDの公開  ^目次

Oracle Service Registry XSDからUDDI（XSD2UDDI）へのマッピングを有効にすると、XMLスキーマ文書をUDDIに自動的に公開し、特定のXMLスキーマ・アーティファクトおよびメタデータに基づいて正確かつ柔軟なUDDI問合せを実現できます。

XMLスキーマ文書を非公開にするには、「Find XSD」ボタンを使用し、検索結果ページの「Unpublish」ボタンをクリックします。

XMLスキーマの公開  ^目次

XMLスキーマ文書を公開するには、次の手順を実行します。

1. 「Publish」メイン・メニュー・タブの下の「XSD」リンクをクリックします。

2. 図88に示すページが表示されます。

   図88 XSDの公開

   

3. 「XML Schema location」を入力します。 デモを実行するには、Oracle Service RegistryデモのREGISTRY_HOME/demos/conf/employees.xsdファイルを選択します。

4. 「Advanced mode」チェック・ボックスを選択しないままにしておき、「Publish」ボタンをクリックします。

5. XMLスキーマ文書がレジストリに公開されます。図89に、XMLスキーマ文書自体とその要素のマッピングを示します。

図89 XSDの要約の公開

XMLスキーマの公開（拡張モード）  ^目次

拡張モードで公開すると、XMLスキーマ文書をUDDIレジストリにどのようにマップするかを詳細に指定できます。このモードで公開するには、次の手順を実行します。

1. 前項の手順を実行します。ただし、「Advanced mode」チェック・ボックスを選択します。

2. 「Publish」をクリックします。図90に示す「Advanced Mode Publish」ページが表示されます。

   図90 XSDの公開 - 拡張

   

3. 左側のツリー・パネルでは、XMLスキーマおよびその有効なXMLスキーマ・インポートがどのように公開されるかを参照できます。 XMLスキーマの各部をOracle Service Registryにマップする方法を編集するには、そのXMLスキーマ・モデル・ノードをクリックします。右側のパネルにマッピング・オプションの詳しい説明が表示されます。

4. XMLスキーマ文書がOracle Service Registryにどのようにマップされるかを参照するには、「Preview」をクリックします。「Preview」ページから、XMLスキーマ・マッピングの編集に戻ることができます。

XMLスキーマの非公開  ^目次

XMLの非公開を行うと、Oracle Service RegistryからXMLスキーマ・マッピングを削除できます。XMLスキーマ文書を非公開にするには、まずそのXMLスキーマ文書を検索する必要があります。

XSLTの公開  ^目次

Oracle Service Registry XSLTからUDDI（XSLT2UDDI）へのマッピングを有効にすると、XSLTをUDDIに自動的に公開し、特定のXSLTアーティファクトおよびメタデータに基づいて正確かつ柔軟なUDDI問合せを実現できます。

XSLTを非公開にする場合は、「Find XSLT」ボタンをクリックし、検索結果ページの「Unpublish」ボタンをクリックします。

XSLTの公開  ^目次

XSLTを公開するには、次の手順を実行します。

1. 「Publish」メイン・メニュー・タブの下の「XSLT」リンクをクリックします。

2. 図91に示すページが表示されます。

   図91 XSLTの公開

   

3. 「XSLT location」を入力します。 デモを実行するには、Oracle Service RegistryデモのREGISTRY_HOME/demos/conf/employeesToDepartments.xslファイルを選択します。

4. 「Advanced mode」チェック・ボックスを選択しないままにしておき、「Publish」ボタンをクリックします。

XSLTが、Oracle Service Registryに公開されます。 図92で、XSLTアーティファクトがOracle Service Registryにどのようにマップされたかを確認できます。

図92 XSLTの要約の公開

XSLTの公開（拡張モード）  ^目次

拡張モードで公開すると、XSLTをUDDIレジストリにどのようにマップするかを詳細に指定できます。このモードで公開するには、次の手順を実行します。

1. 前項の手順を実行します。ただし、「Advanced mode」チェック・ボックスを選択します。

2. 「Publish」をクリックします。図86に示す「Advanced Mode Publish」ページが表示されます。

   図93 XSLTの公開 - 拡張

   

   左側のツリー・パネルでは、XSLTおよびその入出力スキーマがどのように公開されるかを参照できます。

3. これらのアーティファクトをOracle Service Registryにどのようにマップするかを編集するには、XSLTノード自体、その入力XMLスキーマおよびXSLT出力のタイプをクリックします。右側のパネルにマッピング・オプションの詳しい説明が表示されます。

4. XSLTがOracle Service Registryにどのようにマップされるかを参照するには、「Preview」をクリックします。「Preview」ページから、マッピングの編集に戻ることができます。

Signerツールのインタフェースでは、メイン画面の左側に、businessEntityおよびtModelをすべて含むツリーが表示されます。デジタル署名を追加または削除する場合は、このツリーから、署名の構造を選択します。レジストリからその構造がフェッチされます。構造がフェッチされると、そのXML表現が右側のパネルに表示されます。「Sign」ボタンがブロック解除されます。構造にすでに署名がある場合は、「Remove signatures」ボタンもブロック解除されます。

図96 署名ツール - メイン画面

Signerの最下部にあるステータス・バーには、現在のアクションの進行状況および結果が通知されます。

UDDI構造に署名するには、Javaキーストアを設定する必要があります。キーストアを生成するには、JDKツールkeytoolを使用します。keytoolの使用方法の詳細は、JDKのドキュメントを参照してください。Signerツールは、JKSおよびPKCS12形式のキーストアを使用したテストが完了しています。

注意

証明書を生成するには、次のコマンドを発行します。 keytool -genkey -keyalg RSA -storetype JKS -alias demo_john -keystore test_certificate.jks ダイアログの例を次に示します。 Enter keystore password: changeit What is your first and last name? [Unknown]: John Johnson What is the name of your organizational unit? [Unknown]: UDDI What is the name of your organization? [Unknown]: Myorg What is the name of your City or Locality? [Unknown]: San Diego What is the name of your State or Province? [Unknown]: California What is the two-letter country code for this unit? [Unknown]: CA Is CN=John Johnson, OU=UDDI, O=Myorg, L=San Diego, ST=California, C=CA correct? [no]: yes Enter key password for <demo_john> (RETURN if same as keystore password):

UDDI構造に署名するには、次のように、Javaキーストア・ファイル、エイリアスおよびパスワードを設定する必要があります。

「Validate」ボタンは、XMLデジタル署名が含まれているUDDI構造の妥当性チェックに使用します。この操作の結果は、ステータス・バーに表示されます。

「Remove signatures」ボタンは、選択したUDDI構造からデジタル署名をすべて削除するために使用します。この操作が完了すると、UDDI構造のXML表現が更新されます。「Publish changes」ボタンが無効化されていた場合は、有効になります。

選択したUDDI構造に署名するか、またはそのUDDI構造からデジタル署名を削除した場合は、「Publish changes」ボタンを選択して変更内容をレジストリに公開できます。そのボタンを選択すると、標準のUDDI公開メソッド（save_tModelなど）でレジストリの該当するUDDI構造が更新されます。この操作には秘密鍵は使用されません。

Signerツールでは、レジストリ・エンドポイント、キーストアの場所と形式など実際の構成が自動的に記憶されます。構成ファイルは、signer.confという名前でユーザーのホーム・ディレクトリに保存されています。Signerスクリプトの-cオプションを使用して、場所（およびファイル名）を変更できます。この機能が必要ない場合は、-nを使用します。有効なオプションのリストは、-hオプションで表示できます。

Signerツールでは、XMLデジタル・セキュリティ・プロバイダによって署名および検証が実行されます。Signerツールには、あらかじめデジタル署名プロバイダが2つ用意されています。

デフォルトはssjです。oracleに切り替える場合は、該当するスクリプトで、Signerツールを実行するコマンドを修正します。