Service Registry へのオブジェクトの発行が完了すると、それらのオブジェクトに対して操作を実行できます。この章では、それらの操作について説明します。
Association オブジェクトを作成し、それを使って任意の 2 つのオブジェクト間の関係を指定することができます。ebXML 仕様で規定されている AssociationType 分類スキーマには、Association 作成時に使用可能な標準的な概念が、数多く含まれています。AssociationType 分類スキーマ内に独自の概念を作成することもできます。
AccessControlPolicyFor
AffiliatedWith (サブ概念 EmployeeOf と MemberOf を持つ)
Contains
ContentManagementServiceFor
EquivalentTo
Extends
ExternallyLinks
HasFederationMember
HasMember
Implements
InstanceOf
InvocationControlFileFor (サブ概念 CatalogingControlFileFor と ValidationControlFileFor を持つ)
OffersService
OwnerOf
RelatedTo
Replaces
ResponsibleFor
SubmitterOf
Supersedes
Uses
レジストリは、これらの関連付けタイプの一部を自動的に使用します。たとえば、Service を Organization に追加する場合、レジストリは、その Organization をソースに、Service をターゲットに持つ OffersService 関連付けを作成します。
関連付けには方向があります。各 Association オブジェクトは 1 つのソースと 1 つのターゲットを持ちます。2 つのオブジェクト間の関連付けを確立する操作は、次の 3 つの手順から成ります。
使用する AssociationType 概念を検索するか、作成します。
LifeCycleManager.createAssociation メソッドを使って関連付けを作成します。このメソッドは 2 つの引数を取ります。ターゲットオブジェクトと関係を識別する概念の 2 つです。
たとえば、2 つのオブジェクト obj1 と obj2 があり、それらの間に RelatedTo の関係を確立するとします。この関係の場合、どちらのオブジェクトをソースにし、どちらのオブジェクトをターゲットにするかは、自由に決めてかまいません。まず、RelatedTo 概念を検索します。
// Find RelatedTo concept for Association String concString = CanonicalConstants.CANONICAL_ASSOCIATION_TYPE_ID_RelatedTo; Concept relConcept = (Concept) bqm.getRegistryObject(concString); |
obj2 をターゲットとして指定して関連付けを作成します。
Association relAssoc = blcm.createAssociation(obj2, relConcept); |
その関連付けをソースオブジェクト obj1 に追加します。
obj1.addAssociation(relAssoc); |
最後に、その関連付けを保存します。
Collection associations = new ArrayList(); associations.add(relAssoc1); BulkResponse response = blcm.saveObjects(associations); |
関連付けには区域内と区域外の 2 種類があります。ユーザーがソースオブジェクトとターゲットオブジェクトの両方を所有している場合、「区域内関連付け」が作成されます。これらのオブジェクトの少なくとも一方を所有していない場合は、「区域外関連付け」を作成します。オブジェクトの所有者は、アクセス制御ポリシーを使用して、そのオブジェクトをソースまたはターゲットに持つ区域外関連付けを作成する権限を制限できます。
関連付けの作成の例については、<INSTALL/registry-samples/publish-association/src/ ディレクトリにある JAXRPublishAssociation.java を参照してください。このサンプルは、指定した一意の識別子を持つ任意の 2 つのオブジェクト間の RelatedTo 関連付けを作成します。たとえば、「組織階層の作成と取得: 例」で作成された 2 つの子組織を指定することができます。
INSTALL/registry-samples/organizations ディレクトリに移動します。
次のコマンドを実行して組織階層を取得します。
Ant-base/ant search-fam |
2 つの子組織のキーとなる ID 文字列に注意してください。
INSTALL/registry-samples/publish-association ディレクトリに移動します。
次のコマンドを入力します。
Ant-base/ant run -Did1=string1 -Did2=string2 |
string1 と string2 を 2 つの子組織の ID 文字列に置き換えてください。
関連付けが区域内、区域外のいずれになるかは、2 つのオブジェクトの所有者によって決まります。この場合の関連付けは、区域内になります。
レジストリパッケージを使えば、論理的に関連付けられている多数のレジストリオブジェクトをグループ化できます。その際、個々のメンバーオブジェクトが異なる所有者に属していてもかまいません。RegistryPackage はファイルシステムのディレクトリまたはフォルダに相当し、その中のレジストリオブジェクトはディレクトリまたはフォルダ内のファイルに相当します。
RegistryPackage オブジェクトを作成するには、LifeCycleManager.createRegistryPackage メソッドを呼び出します。このメソッドは String 引数または InternationalString 引数を取ります。それから、RegistryPackage.addRegistryObject、RegistryPackage.addRegistryObjects のいずれかのメソッドを呼び出してオブジェクトをパッケージに追加します。
たとえば、“SunPackage” という名前の RegistryPackage オブジェクトを作成できます。
RegistryPackage pkg = blcm.createRegistryPackage("SunPackage");
それから、文字列 "Sun" を名前に含むすべてのオブジェクトを検索したあと、その結果に対して繰り返し処理を行い、各オブジェクトをパッケージに追加することができます。
pkg.addRegistryObject(object);
パッケージの一般的な用途は、一連の付帯オブジェクトをグループ化することです。レジストリ管理者は、Admin Tool の cp コマンドを使用して Service Registry にファイルシステムをロードし、ディレクトリをレジストリパッケージとして、またファイルをパッケージの内容として、それぞれ格納できます。詳細については、『Service Registry 3.1 管理ガイド』の「cp」を参照してください。
レジストリパッケージの使用例については、 INSTALL/registry-samples/packages/src ディレクトリにある JAXRPublishPackage.java および JAXRSearchPackage.java を参照してください。最初のサンプルは、文字列 "free" を名前に含むレジストリ内のすべてのオブジェクトが格納された RegistryPackage オブジェクトを発行します。2 つ目のサンプルは、このパッケージを検索し、その内容を表示します。
INSTALL/registry-samples/packages ディレクトリに移動します。
次のコマンドを入力します。
Ant-base/ant pub-pkg |
次のコマンドを入力します。
Ant-base/ant search-pkg |
オブジェクトを Service Registry に発行したり、オブジェクトを何らかの形で変更したりするときは、オブジェクトの監査証跡に AuditableEvent オブジェクトを追加します。これらのイベントやこれらに関する情報の取得方法の詳細については、「オブジェクトの監査証跡の取得」を参照してください。
ほかのアクションの結果として多くのイベントが作成されます。
オブジェクトをレジストリに保存すると、EVENT_TYPE_CREATED イベントが作成されます。
変更するオブジェクトのオブジェクト型に対してバージョン管理を有効にした場合、次のアクションを行うと、EVENT_TYPE_VERSIONED イベントが作成されます。
オブジェクトの名前または説明の変更
Classification、ExternalIdentifier、または Slot の追加、変更、または削除
Organization または User に対する、PostalAddress または TelephoneNumber の追加、変更、または削除
オブジェクトのバージョン情報を取得できます。詳細については、「オブジェクトのバージョンの取得」を参照してください。
このリリースでは、オブジェクトのバージョン管理はデフォルトで無効になっています。オブジェクトのバージョン管理を有効にするには、管理者は、『Service Registry 3.1 管理ガイド』の「レジストリオブジェクトのバージョン管理の有効化」で説明したタスクを実行する必要があります。通常、管理者は一部のオブジェクト型のバージョン管理を有効にできますが、すべてはできません。
オブジェクトの状態を明示的に変更することもできます。さまざまなバージョンのオブジェクトが混在しており、何らかのバージョン管理を行う必要がある本稼働環境においては、この機能が役立つ場合があります。たとえば、あるオブジェクトのバージョンを一般的に使用するものとして承認し、古いバージョンを非推奨にしてから削除する、といったことが可能です。オブジェクトを非推奨にしたあとで変更したくなったら、その非推奨を解除できます。登録ユーザーは、自分が所有するオブジェクトに対してのみ、このようなアクションを実行できます。
LifeCycleManagerImpl.approveObjects メソッドを使ってオブジェクトを承認できます。この機能は実装に固有です。
LifeCycleManager.unDeprecateObjects メソッドを使ってオブジェクトの非推奨を解除できます。
LifeCycleManagerImpl.approveObjects メソッドのシグニチャーは次のとおりです。
public BulkResponse approveObjects(java.util.Collection keys) throws JAXRException
オブジェクトを非推奨にするコードは通常、次のようになります。
String id = id-string; Key key = blcm.createKey(id); Collection keys = new ArrayList(); keys.add(key); // deprecate the object blcm.deprecateObjects(keys);
これらのアクションへのアクセスを、レジストリ管理者などの特定のユーザー、ユーザーロール、およびユーザーグループに制限することが可能です。「オブジェクトへのアクセスの制御」を参照してください。
RegistryObject の状態を変えないアクションに対しては、AuditableEvent は作成されません。たとえば、クエリーを実行しても AuditableEvent は生成されません。また、ある RegistryObject を RegistryPackage に追加したり、そのオブジェクトをソースまたはターゲットに持つ Association を作成したりしても、そのオブジェクトに対して AuditableEvent が生成されることはありません。
オブジェクトの承認、非推奨、非推奨解除の例については、INSTALL/registry-samples/auditable-events/src にあるサンプル、JAXRApproveObject.java、JAXRDeprecateObject.java、および JAXRUndeprecateObject.java を参照してください。各サンプルは、指定された一意の識別子を持つオブジェクトに対してアクションを実行したあと、そのオブジェクトの監査証跡を表示します。このため、ユーザーはサンプルの実行結果を確認できます。
すべてのサンプルについて、ユーザーが指定するオブジェクトはそのユーザーが作成したものである必要があります。
INSTALL/registry-samples/auditable-events ディレクトリに移動します。
次のコマンドを入力します。
Ant-base/ant approve-obj -Did=id-string |
次のコマンドを入力します。
Ant-base/ant deprecate-obj -Did=id-string |
次のコマンドを入力します。
Ant-base/ant undeprecate-obj -Did=id-string |
レジストリ内のオブジェクトへのアクセスは、アクセス制御ポリシー (ACP) によって設定されます。デフォルトのアクセス制御ポリシーの指定内容は、次のとおりです。
定義済みユーザー Registry Guest は、任意のオブジェクトを読み取ることができます。Service Registry にログインしていないユーザーはすべて、このアイデンティティーを持ちます。
すべての登録済みユーザーは、オブジェクトを作成できるほか、自分が所有するオブジェクトに対してアクションを実行できます。
RegistryAdministrator として分類されるすべてのユーザーは、Service Registry 内のすべてのオブジェクトに対してアクションを実行できます。デフォルトでは、定義済みユーザー Registry Operator のみが、管理者として分類されています。管理者になる方法については、『Service Registry 3.1 管理ガイド』の「管理者の作成」を参照してください。
カスタム ACP を使えば、個々のオブジェクトに対して細粒度のアクセス制御を設定できます。ただし、ACP の記述は現時点では手動による処理であり、OASIS の XACML (eXtensible Access Control Markup Language) の知識が必要になります。詳細については、『ebXML RIM 3.0』の第 9 章「Access Control Information Model」、特に 9.7.6 節から 9.7.8 節にかけてのサンプルを参照してください。
レジストリに送信したオブジェクトはどれでも、そのレジストリから削除することができます。対象オブジェクトの ID を、LifeCycleManager.deleteObjects メソッドの引数として使用します。
次のコードでは、指定されたキー文字列に対応するオブジェクトを削除したあと、正しいオブジェクトが削除されたことをユーザーが確認できるよう、そのキーを再度表示しています。
String id = key.getId(); Collection keys = new ArrayList(); keys.add(key); BulkResponse response = blcm.deleteObjects(keys); Collection exceptions = response.getException(); if (exceptions == null) { System.out.println("Objects deleted"); Collection retKeys = response.getCollection(); Iterator keyIter = retKeys.iterator(); javax.xml.registry.infomodel.Key orgKey = null; if (keyIter.hasNext()) { orgKey = (javax.xml.registry.infomodel.Key) keyIter.next(); id = orgKey.getId(); System.out.println("Object key was " + id); } }
Organization オブジェクトを削除しても、その Organization に属する Service オブジェクトと User オブジェクトは削除されません。これらのオブジェクトを削除する場合は、個別に削除する必要があります。
Service オブジェクトを削除すると、それに属する ServiceBinding オブジェクトも削除されます。ただし、Service オブジェクトと ServiceBinding オブジェクトを削除しても、それに関連付けられた ExtrinsicObject インスタンスとその関連リポジトリ項目は削除されません。付帯オブジェクトは個別に削除する必要があります。
Classification や ExternalIdentifier を持つオブジェクト、または Slot オブジェクトを削除すると、付帯オブジェクトも削除されます。ただし、ExternalLink オブジェクトの場合は、付帯オブジェクトは削除されません。
AuditableEvent オブジェクトは、関連付けられたオブジェクトが削除されても削除されません。レジストリの使用を続けると、これらのオブジェクトが多数蓄積されていくのがわかります。
Service Registry からオブジェクトを削除する例については、INSTALL/registry-samples/delete-object/src ディレクトリにある JAXRDelete.java を参照してください。このサンプルは、指定された一意の識別子を持つオブジェクトを削除します。