Registry Management  Locate

Accessing Registry Management   Locate

Registry Management is a set of tasks that the administrator can address through the Registry Control. These tasks are listed in Figure 1

To access the Registry Management console:

  1. Log on as administrator or as a user with privilege to display Manage tab as described in Rules to Display the Manage Tab.

  2. Click the Manage main menu tab.

  3. Select the Registry management link under Manage tab. This returns the screen shown in Figure 1.

[Note]Rules to Display the Manage Tab

The Manage tab is available if at least one of the following conditions is satisfied:

  • You have ApiManagerPermission to all methods (*) of one or more APIs (Account,Group,Permission,Taxonomy,ApprovalManagement,Statistics,Administration Utils).

  • You have ConfiguratorManagerPermission to all operations (*) and all configurations (*).

  • You have ApiManagerPermission to all methods (*) of ReplicationApi and ConfiguratorManagerPermission to all operations (*) for replication configuration.

  • You have ConfiguratorManagerPermission to all operations (*) for web configuration.

Figure 1. Registry Management

Registry Management

  • Account Management - Create, edit, and delete user accounts.

  • Group Management - Create, edit, and delete accounts groups.

  • Permissions - Set up permissions using the Registry Control

  • Taxonomy Management - Build and maintain taxonomies via the Registry Control.

  • Replication Management - Set up a subscription-based replication mechanism under which a slave registry receives notification from a master registry regarding updates and changes. (For more information on replication, please see Replication Management.)

  • Approval Management - set up requestors and approvers. This button is available only if the approval process is installed. See Installation Guide, Approval Process Registry Installation

  • Replace UDDI keys - Replace the UDDI keys of businessEntities, businessServices, tModels, and bindingTemplates.

  • Replace URLs - Replace URL prefixes of accessPoint URL, OverviewDoc URL

  • Delete deprecated tModels - This option lets the administrator permanently delete deprecated tModels. A tModel is considered deprecated when it is marked as deleted by its owner. By default, tModels are deleted permanently by users. See Node how to change this behavior.

  • Transform keyed references - This operation is necessary when the type of taxonomy keyValues or the implementation of the taxonomy transformation service have been changed. For more information see, User's Guide, Taxonomy: Principles, Creation and Validation.

  • Statistics - This option displays two statistics tabs:

    • The first tab displays information about the number of accesses made to the various UDDI interface methods. One column displays the total request counts and a count of calls that fail and therefore return exceptions.

    • The second one contains counts of the main data structures (businessEntities, businessServices, tModels, bindingTemplates) in the database.

Account Management  Locate

The Oracle Service Registry administrator manages user accounts using the Registry Control. Use this console whenever you want to disable an account, change limits for a particular account, or take care of general housekeeping.

To access the Account management console:

  1. Log on as administrator.

  2. Click the Registry management link under the Manage tab.

  3. Click the Account management button.

    This displays a list of all accounts, as shown in Figure 2.You can search accounts using the Find users button.

Figure 2. Find Account

Find Account

Create Account  Locate

To create an account:

  1. On the Find Account page, click Create Account button. This returns the Create account page shown in Figure 3.

    Figure 3. Create Account

    Create Account
  2. Provide the information shown in . Fields marked with a red asterisk (*) are required.

    Figure 4. New Account - All Fields

    New Account - All Fields

    Field descriptions (self-explanatory fields are omitted):

    Default Language Code

    Set the default language to be used during publishing when the language code associated with a particular field is not specified.

    Use the following profile

    Profile preference - Select your preferred predefined user profile from this drop down list

    Blocked

    Here you can enable/disable a user account. This is the account flag which prevents/permits a user from successfully logging onto the server.

    Limits

    These fields (Assertions limit, Bindings limit, Businesses limit, Services limit, Subscriptions limit, andTModels limit) indicate the number of these items allowed by the user. Changing default user limits is discussed in the Accounts section of Registry Configuration.

    [Note]Note

    If you are using approval process (you create account in publication or intermediate registry), you can set fields for Approver request transformation and Approver message transformation. Both fields determines XSL transformation for approval process mail notifications. XSL transformation is specified by the key of appropriate tModel. Approver request transformation determines transformation for mail notification about newly created approval request. Approver message transformation is used for mail notification about request's cancellation, approval or rejection. Both transformations are taken into account only for approval process called from the Registry Control

  3. When finished, click Create account. This returns the Find account page. Note that the list of accounts now includes the account you have just created.

Account Limits  Locate

Each user account has the following limits for data saved under the account:

  • Businesses limit - maximum number of businessEntities the account can hold. (1 by default).

  • Services limit - maximum number of businessServices in the same businessEntity (4 by default).

  • bindings limit - maximum number of bindingTemplates in the same businessService (2 by default).

  • tModels limit - maximum number of tModels the account can hold. (100 by default).

  • Assertions limit - maximum number of publisherAssertions the account can hold (10 by default).

  • Subscriptions limit - maximum number of subscriptions an account can hold. (5 by default)

Common users can not change these limits. Only the administrator can change limits for a user or change default limits for newly created users.

The number of businessServices/bindingTemplates are checked against the limit on the user account owning the parent structure, not against the limit of the user processing the save_XXX call. For example, a user U1 owns a businessEntity BE_U1 and provides create ACL right to the user U2. The user U2 saves a new businessService under the BE_U1, total count of businessServices under the BE_U1 (no matter who is the owner) is checked against the service limit of the BE account.

Limit checking is skipped if a user who performs the operation has an ApiManagerPermission with the appropriate permission name and action:

  • API (permission name)

    • org.systinet.uddi.client.v3.UDDI_Publication_PortType for skipping limit tests on Publishing V3 API.

    • org.systinet.uddi.client.v2.Publish for skipping limit tests on Publishing V2 API.

    • org.systinet.uddi.client.v1.PublishSoap for skipping limit tests on Publishing V1 API.

    • org.systinet.uddi.client.subscription.v3.UDDI_Subscription_PortType for skipping limit tests on Subscription API.

  • operation (action)

    • save_business for skipping businesses limit test on Publishing V1/V2/V3 API

    • save_service for skipping services limit test on Publishing V1/V2/V3 API

    • save_binding for skipping bindings limit test on Publishing V1/V2/V3 API

    • save_tModel for skipping tModels limit test on Publishing V1/V2/V3 API

    • add_publisherAssertions for skipping assertions limit test on Publishing V2/V3 API

    • set_publisherAssertions for skipping assertions limit test on Publishing V2/V3 API

    • save_subscription for skipping subscriptions limit test on Subscription API

For more information see Permissions: Principles. By default, only the administrator has these permissions, and therefore the administrator has an unlimited account.

Edit Account  Locate

To edit an account:

  1. On the Find account page shown in Figure 2, click the Edit Account icon ( ) associated with the account you want to edit.

    This returns the Edit account page.

  2. On the Edit account page, provide or change the information in the various fields. These are the same as the fields shown in Figure 4.

    Field descriptions (self-explanatory fields are omitted):

    Default Language Code

    Set the default language to be used during publishing when the language code associated with a particular field is not specified.

    Blocked

    Here you can enable/disable a user account. This is the account flag which prevents/permits a user from successfully logging onto the server.

    Limits

    These fields (Assertions limit, Bindings limit, Businesses limit, Services limit, Subscriptions limit, andTModels limit) indicate the number of these items allowed by the user. These are described in detail in the Accounts section of Registry Configuration.

  3. When finished, click the button labeled Save Changes. This returns the Find account page.

Delete Account  Locate

To delete an account:

  1. On the Find account page, check the box next to the Login name of the account you want to delete.

  2. Click the Delete Selected button.

  3. If you are certain you want to delete the account, click Yes when prompted. Note that on publication registries and standard installations of Oracle Service Registry, all published information associated with the user will be lost.

[Note]Note

If you are using LDAP for storing users, the user account will not be deleted from the LDAP store, because LDAP stores are treated as read-only. The delete account operation will delete an account only from the registry database.

Group Management  Locate

User groups simplify management of access rights to each UDDI data structure. You can use groups to group users with similar rights.

The administrator can:

  • Create and manage user groups

  • Manage group membership

Figure 5. View User Groups

View User Groups

Create and Manage Groups  Locate

To create a new group:

  1. Click on the Manage menu tab. On the Manage tab, select the Registry management link, and then click the Group management button. This returns the Group Management page.

  2. To display all groups on the registry, click Filter. This returns a Group list like the one shown in Figure 5.

  3. Click the Add Group button. This returns a blank Add group page much like the one shown in Figure 6.

    Figure 6. Add Group Page

    Add Group Page

  4. In the edit box labeled Group name, type the name of your group. In the edit box labeled Group owner, type the owner of the group. The default owner is Admin. These two fields are required.

  5. Use the radio buttons labeled public and private to set group visibility.

    Both public and private groups are visible to all users in the registry, meaning that all users are able to see which groups exist. Public and private groups differ in that members of public groups are visible to all users of the registry whereas members of private groups are visible only to the owner of the group.

  6. Optionally, Enter a description of the group in the box labeled Description.

  7. Click the Save group properties button. This returns the Users list and Group members sections shown in Figure 5.

    Figure 7. Edit Group Membership

    Edit Group Membership

  8. In the Users list section, click Filter to display a list of all of the registry's users.

    Use the drop down list in this section to sort users by Login name or Full name.

    Use the text box to further filter users. You can use % as wildcard in this field.

  9. Check the boxes next to all members you wish to include, and click the right-pointing arrow ( ) to move them to the Group members table.

    Group members are updated in the database once you click the arrow buttons.

Manage Group Membership  Locate

To add or remove members from a group:

  1. Click on the Manage main menu tab.

  2. Click on the Registry management link. This returns the main Registry Management page.

    Click the Group management button. This returns the Group list shown in Figure 5.

  3. Enter your search criteria, then click the Filter button. Click Filter without search criteria to return a list of all groups.

  4. Click the Edit button ( ) in the row with the group you want to manage. This returns the Edit Group page. Specify search criterion for user accounts, then click the Filter button.

  5. Use the arrow buttons ( and ) to add and remove users as shown in Figure 7

Permissions  Locate

This chapter describes how you can set permissions using the Registry Control. Before you start to work with permissions, we recommend reading Permissions: Principles to become familiar with permissions principles.

Oracle Service Registry uses the same interface for managing both user permissions and group permissions. In this section we discuss user permissions, but group permissions are handled the same way.

Accessing Permission Management  Locate

To access permission management:

  1. Log on as Administrator or as a user who has permission to set permissions, as described in Permissions Definitions.

  2. Click the Manage main menu tab. On the Manage tab, select the Registry management link, and then click the Permissions button.

  3. On the initial Select Principal screen, click Filter, without changing the default settings, to view a list of all users (principals).

    [Tip]Tip

    Use the drop down list in this section, labeled Filter: to sort users by Login name or Full name.

    Use the text box to further filter users by name. You can use % as wildcard in this field.

    Select the radio button labeled User to manage permissions for individual users. Select the button labeled Group to manage group permissions.

    Check the box labeled Show only users/groups with some permission to filter out principals who have not already been granted permissions.

    This returns the list of users shown in Figure 8.

    Figure 8. Select Principal

    Select Principal

  4. Click the Edit icon ( ) associated with the user or group whose permissions you wish to set.

Add Permission  Locate

To add permissions:

  1. Access permission management as described above in Accessing Permission Management.

  2. On the principal list page shown in Figure 8, click the Edit icon ( ) associated with the group or user to whom you wish to add permissions. On the returned Permissions page, click Add permission.

  3. An Add permissions page much like the one shown in Figure 9 will appear.

    Figure 9. Add Permission

    Add Permission
    • Select the type of permission from the drop down list labeled Permission type.

    • From the drop down list labeled Permission name, select the name of the permission to add.

    • Check the box(es) next to the actions associated with the permission name in order to grant permission to perform those actions. Check the box next to the asterisk (*) to permit all the actions on the list.

  4. Click Save Changes to save the permission.

Editing and Deleting Permissions  Locate

To edit a permission:

  1. On the principal list page shown in Figure 8, click the Edit icon ( ) associated with the user whose permissions you want to edit or delete.

  2. If the principal has permissions defined, a permission list like the one shown in Figure 10 will appear.

    Figure 10. Permissions List

    Permissions List
  3. Click the Edit or Delete icon ( ) associated with the permission you want to address.

Assigning Administrator's Permission  Locate

If you want to give administrator's permissions to an existing user, you must assign the following permissions types to the user:

  • org.systinet.uddi.security.permission.ApiManagerPermission

  • org.systinet.uddi.security.permission.ApiUserPermission

  • org.systinet.uddi.security.permission.ConfigurationManagerPermission

For each Permission type set all Permission names and all actions using the asterisk (*)

Taxonomy Management  Locate

This chapter describes how administrators can build and maintain taxonomies using the Registry Control. Before you start to manage taxonomies, we recommend reading User's Guide, Taxonomy: Principles, Creation and Validation to become familiar with taxonomy principles.

The following tasks are described in this chapter:

To view the Taxonomy management page:

  1. Log on as administrator.

  2. Click the Manage tab under the Main menu, and then click on the Registry management link under the Manage menu tab.

  3. Click Taxonomy management. This returns a blank Taxonomy management page. To view a selection of taxonomies, select a filter from the drop down list labeled Show. Possible filters are:

    • Favorite taxonomies

    • Enterprise taxonomies

    • All taxonomies hide system

    • All taxonomies including system

    This returns a list of taxonomies similar to that shown in Figure 11.

Figure 11. Find Taxonomy (Enterprise Taxonomies)

Find Taxonomy (Enterprise Taxonomies)

Use the page shown in Figure 11 to search enterprise taxonomies. You can classify taxonomies according to the following overlapping groups:

  • Enterprise taxonomies - The Oracle Service Registry administrator can define which taxonomies will be present in the enterprise taxonomies list. The Enterprise taxonomies button located in the bottom part of Figure 11 allows you to manage a list of enterprise taxonomies for all registry user accounts.

  • Favorite taxonomies - All registry users can define their list of favorite taxonomies. See User's Guide, favorite Taxonomies for more information on how to manage your list of favorite taxonomies.

  • System taxonomies - When you edit a taxonomy you can assign whether the taxonomy is a system taxonomy using the check box System taxonomy.

The reason for this taxonomy classification is to make taxonomy management and UDDI entity categorization easier.

If you want to manage taxonomies which are not in the enterprise taxonomy list, select see all taxonomies including system taxonomies from the drop down list labeled Show. The page shown in Figure 12 will appear. You can search taxonomies using the following criteria: taxonomy name, type, compatibility, and validation.

Figure 12. Find Taxonomy

Find Taxonomy

Adding Taxonomies  Locate

You can also add a root for a taxonomy by hand and build it through the Registry Control.

To add a taxonomy:

  1. Click the Add taxonomy button shown in Figure 12.

  2. Fill in as many of the fields on the Add taxonomy page, shown in Figure 13, as you require. Only two fields are required to create a taxonomy: Name and Categorization, however the more information you provide, the more useful your taxonomy will be.

    Figure 13. Add Taxonomy

    Add Taxonomy
  3. In the field labeled Name, name your taxonomy.

  4. Skip the field labeled tModel key. This key is generated when you save the taxonomy.

  5. In the field labeled Description, briefly describe the use of the taxonomy.

  6. Check one or more of the boxes in the section labeled Categorization. Categorizations are discussed in Taxonomy Types.

  7. You may enforce that your taxonomy can be used only within the UDDI structures of your choice. Select one or more of the main UDDI structure types in the section labeled Compatibility.

  8. Validation In this section, specify whether the values in keyedReferences within the taxonomy will be checked or not.

    • Select checked internal if you want Oracle Service Registry to check keyedReferences in which the taxonomy is used against a validation service deployed within Oracle Service Registry.

    • Select checked external if you want Oracle Service Registry to check keyedReferences in which the taxonomy is used against a validation service deployed on a remote SOAP stack.

      If you are using an external validation service, provide at least one Validation service endpoint.

    • Select unchecked if you do not want Oracle Service Registry to perform any checks on values used in keyedReferences in which the taxonomy is used.

  9. Use the box labeled Unvalidatable to mark taxonomies as temporarily unavailable.

  10. Check the box labeled System taxonomy if you want to mark the taxonomy for internal use. Users and administrators can filter System taxomies easily when searching in the Business Service Control.

  11. Select a Value type for keyValues. You can choose from three existing comparators or create a custom comparator. Existing comparators are:

    • string - keyValues are treated as string values. If keyValues type is unknown then keyValues are treated as strings. The maximum length is 255 characters.

    • numeric - keyValues are treated as decimal numbers. The value can have maximum 19 digits before the decimal point and maximum 6 digits after the decimal point.

    • date - keyValues are treated as dates.

    If you want to categorize using a custom comparison, you must create a new comparator tModel and implement a transformation service. The Transformation service endpoint must start with the class: prefix. Please see the Types of keyValues and Custom Ordinal Types for more information.

  12. Use the box labeled Add to favorites to mark the taxonomy as either a personal favorite. This is an option available to all users.

    Check the box labeled Add to enterprise to mark the taxonomy specific to the particular enterprise or application. For more information, see Enterprise Taxonomies

  13. Click Save taxonomy.

[Note]Note

Later, you will be able to modify all taxonomy attributes except the validation type. See Editing Taxonomies for attribute descriptions.

Finding Taxonomies  Locate

To locate a taxonomy in Oracle Service Registry:

  1. Log on as administrator.

  2. Click the Manage tab under the Main menu, and then click on the Registry management link under the Manage menu tab.

  3. Click Taxonomy management. This returns a blank Taxonomy management page. Select a filter from the drop down list labeled Show. Possible filters are:

    • Favorite taxonomies

    • Enterprise taxonomies

    • All taxonomies hide system

    • All taxonomies including system

    This returns a list of taxonomies similar to that shown in Figure 11.

  4. On the returned Find taxonomy page, you can further filter the results by

    1. name

    2. type - Types are discussed in Taxonomy Types

    3. compatibility

    4. validation

  5. From the list of taxonomies the fit the filter criteria, select the taxonomy you wish to view by clicking on its name.

Editing Taxonomies  Locate

The Registry Control makes it possible to change any taxonomy attribute except the validation type attribute. To edit a taxonomy:

  1. Identify the taxonomy you want to edit as described in Finding Taxonomies.

  2. Click on the Edit Taxonomy icon in the Find Taxonomy page shown in Figure 12. This loads the Edit taxonomy page shown in Figure 14.

    Figure 14. Edit Taxonomy

    Edit Taxonomy

  3. In the field labeled Name, edit the taxonomy's name.

  4. In the field labeled Description, briefly describe the use of the taxonomy.

  5. Check one or more of the boxes in the section labeled Categorization. Categorizations are discussed in Taxonomy Types.

  6. You may enforce that your taxonomy can be used only within the UDDI structures of your choice. Select one or more of the main UDDI structure types in the section labeled Compatibility.

  7. Validation In this section, specify whether the values in keyedReferences within the taxonomy will be checked or not.

    • Select checked internal if you want Oracle Service Registry to check keyedReferences in which the taxonomy is used against a validation service deployed within Oracle Service Registry.

    • Select checked external if you want Oracle Service Registry to check keyedReferences in which the taxonomy is used against a validation service deployed on a remote SOAP stack.

      If you are using an external validation service, provide at least one Validation service endpoint.

    • Select unchecked if you do not want Oracle Service Registry to perform any checks on values used in keyedReferences in which the taxonomy is used.

  8. Check the box labeled Unvalidatable to mark the taxonomy as temporarily unavailable. When you save a checked taxonomy without a validation service, the taxonomy will be saved with Unvalidatable toggled on.

  9. Select a Value type for keyValues. You can choose from three existing comparators or create a custom comparator. Existing comparators are:

    • string - keyValues are treated as string values. If keyValues type is unknown then keyValues are treated as strings. The maximum length is 255 characters.

    • numeric - keyValues are treated as decimal numbers. The value can have maximum 19 digits before the decimal point and maximum 6 digits after the decimal point.

    • date - keyValues are treated as dates.

    If you want to categorize using a custom comparison, you must create a new comparator tModel and implement a transformation service. The Transformation service endpoint must start with the class: prefix. Please see the Types of keyValues and Custom Ordinal Types for more information.

Editing a Taxonomy Structure  Locate

While the fields in the Edit Taxonomy page are used for controlling global attributes, the management of nodes within the taxonomy itself is handled by categories. Here you can add nodes, edit node values, and enable or disable them.

[Note]Note

Changing taxonomy structure is allowed only for checked taxonomies which are validated by the internal validation service.

Adding Categories to a Taxonomy  Locate
[Note]Note

Before we begin assigning names to a taxonomy it is important to consider how the naming system will function.

Taxonomy values in UDDI consist of name and value pairs, like entries in a hash table. As with hash table values, the trade-off between economy of space and extensibility must be taken into consideration. Too long a Value string will be wasteful; too small and it will not be extendable.

To add a node to a branch or root:

  1. Identify the taxonomy you want to edit as described in Finding Taxonomies.

  2. Click the Edit taxonomy structure icon () in the Find taxonomy page as shown in Figure 12.

    [Important]Important

    This icon is only available for checked taxonomies that are validated by the internal validation service. You cannot edit the structure of unchecked taxonomies and checked taxonimies that are validated by other services.

  3. The Edit taxonomy structure page will appear.

  4. On this page, right-click on the taxonomy's folder icon to display its context menu, and select the Add category action or click the Add child category to ... icon next to the item.

  5. This displays the Add category page. Provide the required Key name and Key value, and click Save category.

    In the shipping taxonomy example shown in Figure 15, we use a value algorithm that employs an array of six alphanumeric characters:

    • The first element in the array signifies the first geographic division.

    • The second and third elements signify further geographic subdivisions where necessary.

    • The fourth character indicates transport mode.

    • The fifth character is reserved for an extension to the system allowing a coded category containing a maximum of thirty-six divisions.

    • The sixth can be used for a weight coding system.

    Figure 15. Add Category

    Add Category

  6. Check the box labeled Disabled to mark the category as either helper or deprecated. Note that disabled categories cannot be used as valid options in keyedReferences.

  7. Click the Save category button. This builds the taxonomy as shown in Figure 16.

    Figure 16. Edit Shippers Taxonomy 1

    Edit Shippers Taxonomy 1

Moving categories  Locate

To demonstrate category moving, we will extend the Shippers taxonomy from previous section.

Add four non-disabled categories with the following attributes:

  1. Key name: national; Key value: N00000.

  2. Key name: regional; Key value: R00000

  3. Key name: american; Key value: A00000.

  4. Key name: european; Key value: E00000.

The result is shown in Figure 17.

Figure 17. Edit Shippers Taxonomy 2

Edit Shippers Taxonomy 2

Add a new category {world-wide,W00000} to the same level as all previous taxonomies.

We want to put both the european and american categories under the world-wide category as shown in Figure 18.

Figure 18. Edit Shippers Taxonomy 3

Edit Shippers Taxonomy 3

To do so, select both the european and american categories and click Reparent selected. A dialog for the target category should appear. Choose the world-wide category node. The structures will be displayed as shown in Figure 18.

[Note]Note

Child nodes are moved along with the parent.

The Edit taxonomy structure also allows you to see UDDI entities categorized with a category from the taxonomy tree. An example of displayed business entities categorized with the Shippers taxonomy is shown in Figure 19. To switch to the view of categorized UDDI entities, click the house icon ().

Figure 19. Edit Shippers Taxonomy 3

Edit Shippers Taxonomy 3

Deleting and Disabling Nodes  Locate

There are two policy choices for dealing with categories of entities that cease to be active. Either:

  • They can be marked as disabled.

  • They can be deleted entirely from the taxonomy.

To delete a taxonomy node,

  1. Navigate through the taxonomy tree via the Edit taxonomy page.

  2. Right-click on the category node's icon and select the Delete option from its context menu.

    [Important]Important

    Because this process is irreversible you will be asked to confirm.

To disable a taxonomy node:

  1. Navigate through the taxonomy tree via the Edit taxonomy page.

  2. Right-click on the category node icon to display its context menu.

  3. Select the Edit category option from the context menu. This returns the Edit category page.

  4. On the Edit category page, check the option labeled Disable.

  5. Click the Save category button.

Uploading Taxonomies  Locate

To upload a taxonomy:

  1. Log on as administrator.

  2. Click Manage main menu tab, then click on the link Registry management under the Manage menu tab.

  3. Click the Registry management button. A list of taxonomies like the one shown in Figure 12 will appear.

  4. Click the Upload taxonomy button.

[Note]Note

The format of data on this page is described in the Persistence Format of the Developer's Guide.

Downloading Taxonomies  Locate

There are two obvious cases in which you will want to download a taxonomy from the database:

  1. If you are planning to edit the taxonomy, it is good to keep a safe copy for version control. You can either edit the downloaded copy directly, and even manage it through a versioning system, or keep the downloaded copy as the safety copy and edit the taxonomy directly through the Registry Control and save changes directly to the database.

  2. You may wish to replicate the taxonomy for other systems in other departments of your organization. These departments or branches may even tailor the taxonomy for their own purposes.

To download the taxonomy, click the Download () icon. This returns the system Save file dialog. The default name for the destination file is the taxonomy name with a .xml extension appended. Rename the file if you choose, then save the taxonomy file as you would any other.

Deleting Taxonomies  Locate

If at any point you decide that a taxonomy is no longer necessary, you can delete it by clicking the Delete taxonomy icon () in the Find Taxonomy page.

[Important]Important

Because this procedure is irreversible you will be asked to confirm your deletion.

Replication Management  Locate

Selective One-way Replication is a subscription-based replication mechanism under which a slave registry retrieves update and change notifications from a master registry. The slave registry then applies these to its own data.

Replication is set up by a set of subscriptions, each defining the set of businessEntities, businessServices or tModels being replicated. The subscription filter is a find_business, find_service or find_tModel query with no special requirements.

Each time replication is invoked, the slave registry retrieves a set of changed entities from all subscriptions. The changes are then filtered and saved to the slave registry. The filtering part does not allow changes to the operator business entity, system tModels, checked taxonomies or structures that were originally created at the slave registry; that is, it disallows replication cycling when there is also a replication from the slave to the master registry. Finally, the filtering part also changes the ACLs of published data according to the configuration of the replication. These ACLs are configurable and should be designed in a way that disallows changes to replicated data.

[Important]Important

Replicated data should not be changed because such changes in the slave registry will be lost when someone changes these entities in the master registry and the replication is automatically processed.

Replication may fail or produce warning messages. The failure may occur for one of the following reasons:

  • The master registry is not accessible or the connection is broken during data replication;

  • Saving/Deleting of a subscribed businessEntity on the slave registry fails.

  • A replicated structure (businessEntity, businessService or tModel) references another structure that is not known at the slave registry and is not in the list of changes for the executed replication. (Unlike in version 10.3 of registry the referenced tModels need an extra subscription to retrieve them.)

A warning is produced when:

  • The subscribed businessEntity is not accessible on the master registry. For example because of ACL GET denied permission;

  • Referenced tModels are not accessible on the master registry;

  • Referenced tModels are saved/deleted.

Replication tries to obtain all changes to subscribed data since the last successful replication.

Replication process logs can be found in the REGISTRY_HOME/log/replicationEvents.log file. You can edit the REGISTRY_HOME/conf/log4j.config and make replication logging more detailed by uncommenting the following statement:

log4j.category.replication_v3.com.systinet.uddi.replication.v3.ReplicatorTask=DEBUG,replicationLog
[Important]Important

Each registry must have a unique Operator Name. This value is set in the SMTP Configuration step during Registry installation. The Operator Names for the master registry and for any slave registry must not be the same.

Understanding Replication  Locate

Selective One-way Replication is a subscription-based replication mechanism under which a slave registry retrieves update and change notifications from a master registry. The slave registry then applies these to its own data.

Replications are simply a set of subscriptions created on the Master Registry that are then invoked from the Slave Registry. Registry replication is designed to propagate a set of information from one or more Master Registry instances to a Slave Registry instance, as depicted in the figure below.

The registry administrator creates a Subscription on the Master Registry, which determines the set of information that is propagated from the Master into the Slave. The Replication is then in the Slave Registry, and determines how frequently the replication is performed.

By default, all new or updated businessEntities are copied to the Slave Registry. However it is possible to limit the data that is replicated using subscription filters configured on the Slave Registry. Note in the image above that not all entities that exist on the Master have been replicated to the Slave. In addition, the Slave can have its own data which does not exist in the Master.

At the time of execution, the Slave Registry performs a get_subscriptionResults call on the Master Registry based on the subscription key and time range (interval) specified in the replication. For the purposes of this introductory section, keep in mind that the subscription on the Master must be a find_business subscription. When the Slave runs the subscription, it gets back a set of keys corresponding to new or changed businessEntities. A businessEntity is considered to be changed if:

  • Any of its businessServices or bindingTemplates have been modified.

  • A new businessService or bindingTemplate was created within it.

The Slave registry will then retrieve the complete businessEntity, and store it in the Slave Registry. If an instance of the businessEntity already exists on the Slave, it will be overwritten with the replicated data. As such, the Master is the “source of truth”.

Replication is set up by a subscription defining the set of businessEntities or tModels being replicated. The subscription filter is a find_business or find_tModel query with no special requirements.

Each time replication is invoked, the slave registry retrieves a set of changed businessEntities and referenced tModels. The tModels are referenced in tModelKeys of either tModelInstanceInfos or keyedReferences. These changes are then saved.

New features of replication  Locate

This release adds the following replication features:

  • A Replcation Definition can hold several subscriptions. tModel dependencies are resolved automatically.

  • Programatic filtering of transferred entities can be configured (not documented, but available, we use it to filter some undesirable entities from replications).

  • Replication time specifications are more flexible (like unix cron scheduler).

  • Reports have also been improved.

Table 1. Replication feature issues

Replication feature issueDescriptions
Number of subscriptions in replication item.Multiple subscriptions are possible. Typical use is one for business entities, other tModels.
Failure modes.Transactional – either fully replicated or nothing.
Some tModels are not a part of a subscription yet referenced from other replicated entities.The tModel of the same key is missing in target registry.The tModel will not be replicated. This will cause failure when the referencee entity is replicated. Causing a rollback of the replication.
The tModel of the same key is present in target registry.The tModel will not be replicated. It may contain different data.
What happens when the tModel was originally missing and replication is run for second time. (Combination of two rows above).The tModel will not be replicated. This will cause failure when the referencer entity is replicated. Causing a rollback of the replication. Second replication will start in same state and for same reason it will also roll back.
Some tModels are referenced from other replicated entities. But another subscription which is part of replication covers them.The tModel of the same key is missing in the target registry. The other subscription which covers the tModel must be part of same replication item (other wise transactional processing will end with roll back). The tModel will be replicated correctly.
The tModel of the same key is present in target registry. The tModel is covered by a subscription that is part of the replication. It will be replicated correctly even when it changes on source registry.
Specification of time when the replication is run.Time is specified in format similar to the UNIX cron scheduler. This allows definition patterns like: every day at 2:00am, every hour at :15, every Saturday 1:00am.
Correctness when used in a cluster of RegistriesYes.
SSL certificate fetch in a replication item edit page.Yes.
ReportsA colored HTML report is written to the log directory and the report is presented when replication is run directly from Web UI.
Replicate on behalf of original user (instead of fixed user) of entity.Yes - in Tibco 2.1, Oracle 11g. No - in HP SOA Registry Foundation (probably until next version is released).
Replicated entities carry identification of source Registry.Yes. Also the mark called Node or Operational Id has the effect that non-admin users cannot edit the entities on the target Registry that come from another Registry. This assures that no ordinary user can change entities so that they are out of synchronization yet not tracked by subscription (which is on the source Registry).
Configuration in database feature interaction.Yes. No known issues.
Limitations  Locate
[Important]Important

Selective One-way Replication is not an implementation of the UDDI v3 Inter-Node Replication APIs as defined in the UDDI specification, which is not supported by Oracle Service Registry. The Inter-Node replication is intended to solve a different problem. Instead, the replication mechanism in Oracle Service Registry is based on a UDDI subscription-based "pull" model.

Selective One-way Replication does not provide Federation capabilities, such as for a federated search where one registry propagates queries to other registries and consolidates the results.

[Important]Important

Replicated data should not be changed because such changes in the slave registry will be lost when someone changes these entities in the master registry and then replication is automatically processed. Note also that replicated data should be stored under an account having administrator privileges (admin).

Master Registry Setup  Locate

To set up the master registry:

  1. If you do not have an account on the master registry, you must create one. It can be a standard account.

    [Note]Note

    The default subscription limit for a new user is five. The Oracle Service Registry Administrator may increase the subscriptions limit for the user.

  2. Log into the master registry account.

  3. Create a subscription for the replication with the following details:

    • The subscription filter must be a find_business or find_tModel query.

    • Set the Notification listener type drop down list to None

    • The brief option is recommended to reduce the amount of transferred data.

    For more information, please see Publishing Subscriptions.

Slave Registry Setup  Locate

[Note]Note

Only the administrator of the slave registry should do this.

There are two parts to the slave registry configuration:

  • Master registry information including the location of master registry endpoints for inquiry, subscription and security APIs, and the username/password pair on the master registry are needed to obtain notifications;

  • Slave registry information including the username/password pair on the slave registry for the user who will own the replicated data, and the notification interval.

To set up replication:

  1. Log on as Administrator to the slave registry.

  2. Click the Manage main menu tab, then click on the link Registry management under the Manage menu tab.

  3. Click Replication management. This returns a list of replications.

  4. Click Add replication.

  5. Fill in the form under the Master tab as described in Figure 20.

  6. Fill in the form under the Slave tab as described in Figure 21.

  7. Specify permissions for replicated data under the Permissions tab as shown in Figure 22.

  8. Click Save replication.

Figure 20. Add Replication Master

Add Replication Master
  • User name - Name of the user who created the replication subscription on the master registry

  • Password - Password of the user who created this subscription. This password is encrypted in the configuration file.

  • URL of Master registry The URL must contain the full Master registry URL including protocol, hostname, and application server context (if deployed). It must not contain "uddi/web" which is the address of the Console. For example, for a registry deployed to context "my_context": https://registry.example.com:8443/my_context/ Moreover the URLs must not refer to the slave registry itself, otherwise you may lose some data.

  • Replication subscription key - key of the find_business or find_tModel subscription from the master registry. You can input both tModel and business entity subscriptions.

Figure 21. Add Replication Slave

Add Replication Slave
  • Replication name - Name the replication for better orientation within the list of replications.

  • Disabled - Check this box to disable replication.

  • The user name of replicated entities can be selected one of the following:

    • Fixed user name

      Uncheck Replicate entities on behalf of original user in Master Registry. The following field appears: User name - User account name under which replicated data is stored.

      [Important]Important

      Unlike in previous versions, the permission for generating any keys is granted during replication. Previous versions required: ApiManagerPermission on org.systinet.uddi.client.v3.UDDI_Publication_PortType API for all * actions to be able to generate keys without having the appropriate keyGenerator. For more information, see User's Guide, Generating Keys. By default, the only user who can do this is the admin.

    • Same user name as in the master Registry

      Keep Replicate entities on behalf of original user in Master Registry checked.

      The replication process assigns the same user name for replicated entities as is present in the Master Registry from which the entity is gathered. This only works when a user of the same name exists in the Slave Registry. Note that the user is not able to change or delete the entity unless he owns the ApiManagerPermision for the given operation as this is disallowed for entities that have a foreign Operator Name.

  • Execution time - Specify the period between replications by selecting an option from the drop-down box or select "Other" and input a period pattern. The pattern follows the UNIX Crontab format. It consists of five fields that describe the time period in the following order:

    • Minute of the hour (0-59)

    • Hour of the day (0-24)

    • Day of the month (1-31)

    • Month of the year (Jan-Dec or 1-12)

    • Day of the week (Sun-Sat or 0-6, 7 is same as 0)

    Instead of a number, the patterns can contain a star character which means any value. They can also contain a star, a slash, and a number N which means that only N-th occurrence of such a time would be active. A list of comma separated numbers, months or days (without spaces) is also allowed. Examples:

    • 15 * * * *

      every hour on 15th minute

    • */10 * * * *

      every 10 minutes

    • 0 0 * * Sat-Sun

      every weekend at midnight

    • 0 18 1 *

      6:00 PM on the 1st day of any month

    • 0 */6 * * Fri

      every sixth hour on Friday

  • Last replication time - The date and time when the last replication occurred.

Figure 22. Add Replication Permissions

Add Replication Permissions

In the page shown in Figure 22, the administrator can set up permissions for replicated data. If you do not enter any data on this page, all users from the slave registry have find and get permissions on replicated data.

To specify permissions on replicated data:

  1. Enter a filter criteria for users or groups, and click Filter.

  2. Check the box in front of users or groups. Then, click the Add selected users button. Selected users or groups will be added to the permissions list.

  3. Click the Edit icon to change permissions for Find, Get, Save and Delete operations

  4. Click the Save replication button.

[Tip]Tip

Use the button Replicate now on the replication page to test the replication settings.

Approval Process Management  Locate

This chapter describes how administrators can manage the approval publishing process. We will show you how to set up requestors and approvers using the Registry Control. Before you start, we recommend that you read Approval Process Principles.

Loading the Approval Management Page  Locate

The tasks described in this section are performed from the Approval management page. To load this page:

  1. Log on as administrator.

  2. Click the Manage main menu tab, then select the Registry management link under the Manage menu tab.

  3. Click Approval management. This returns a list of approvers similar to that shown in Figure 23.

    Figure 23. Approval Management

    Approval Management

Create Approver  Locate

To create an approval contact:

  1. Click the Modify approvers button on the Approval management page shown in Figure 23

  2. This returns the Modify approvers page as shown in Figure 24

    The left side of this page, labeled Principal list is a list of all users and groups on the registry. The administrator may make any name on this list into an approval contact.

    The right side, labeled Approvers is a list of all approvers on the registry.

  3. Check the box next to the login name of a user you would like to turn into an approver and click the right-facing arrow ( ). If you would like to create an approver from a group, check the group box and use the right-facing arrow.

  4. Click the Save approvers button.

[Tip]Tip

Using the left-facing arrow buttons, you can deselect approvers in the same way.

Figure 24. Modify Approvers

Modify Approvers

Create Requestor   Locate

To create a requestor from a user:

  1. On the Approval management page shown in Figure 23 click the link labeled Requestors next to an Approver type.

  2. This returns the Modify requestors page shown in Figure 25

    The Requestors page consists of two lists:

    • A list of all users and groups on the registry labeled principals

    • A list of users and groups, labeled Requestors assigned to the selected approver

  3. Select a user or group from the Principals column (or click Select all if you choose), and click the right-pointing arrow ( ) to turn the user(s) into requestors.

  4. Click the Save requestors button.

[Tip]Tip

Using the left-pointing arrow button, you can deselect requestors in the same way.

Figure 25. Modify Requestors

Modify Requestors

Replacing UDDI Keys  Locate

Replacing keys of businessEntities, businessServices, tModels, and bindingTemplates is intended to correct errors in keys before entities are commonly used by users.

To access the key replacement page:

  1. Log on as administrator.

  2. Click the Registry management link under the Manage tab.

  3. In the row labeled Replace UDDI keys, click the appropriate button tModel, business, service, or binding.

[Important]Important

The replace key operation can break digital signatures on changing entity as well as on other entities which reference to the changing entity.

Replacing tModel keys  Locate

When you replace a tModel key, the key will be updated in the following data structures:

  • tModel

  • keyedReferenceGroups

  • keyedReferences

  • tModelInstanceInfos

  • publisherAssertions

  • addresses

  • taxonomies

Replacing businessEntity keys  Locate

When you replace a businessEntity key, the key will be updated in the following data structures:

  • businessEntity

  • services

  • keyedReferences

Replacing businessService keys  Locate

When you replace a businessService key, the key will be updated in the following data structures:

  • businessService

  • bindingTemplates

  • keyedReferences

Replacing bindingTemplate keys  Locate

When you replace a bindingTemplate key, the key will be updated in the following data structures:

  • bindingTemplate

  • keyedReferences

  • subscriptions

  • hostingRedirector

  • accessPoint with bindingTemplate useType

Replace URLs  Locate

Replace URL prefixes of accessPoint URL in binding template, OverviewDoc URL in tModelInstanceInfo and tModel to correct wrong or obsolete accessPoint URLs, OverviewDoc URLs. Of course, you can edit these values by editing those entities. However, in case many URLs have the same obsolete prefix, this feature will replace all URLs matched with the prefix entered by user.

To access the URLs replacement page:

  1. Log on as administrator.

  2. Click the Registry management link under the Manage tab.

  3. Click the button Replace URLs.

Figure 26. Replace URLs

Replace URLs

  • Old URL prefix: URL prefix of the following entities

    • tModel - OverviewDoc URL

    • tModelInstanceInfo - overviewDoc URL and DiscoveryURL

    • binding template - accessPoint URL

  • New URL prefix: the URL prefix will be used to replace URLs matching the Old URL prefix

Registry Statistics  Locate

Registry statistics include statistics on:

  • invocations of registry APIs;

  • UDDI structure counts generally;

To access the registry statistics page:

  1. Log on as administrator.

  2. Click the Registry management link under the Manage tab.

  3. Click the Statistics button.

  4. Click the API Usage tab and you will see a page as in Figure 27 showing the number of requests for each API, number of unsuccessful requests and datetime of last API call. You can reset count separately for each API by clicking the Reset button or reset counts for all API by clicking on the Reset all statistics.

    Figure 27. Statistics - API usage

    Statistics - API usage

  5. You can click on the Structure tab. The page similar as shown in Figure 28 appears. On that page you can see number of UDDI entities stored in Oracle Service Registry.

    Figure 28. Statistics - Structure

    Statistics - Structure

Management of configuration - User Interface  Locate

Configuration Management User Interface is available on the Registry Console, "Manage" tab, "Registry management" sub-tab (default), Configuration management button.

This management tool has two main parts designed for the following tasks:

  1. Inspection of current configurations and their history.

  2. Saving configuration states into collections to compare or restore them later.

Current configurations and their history  Locate

View configuration  Locate

Figure 29. View of current configurations

View of current configurations

This view shows current configurations. You can either sort it alphabetically or by time by clicking on the relevant column heading. Configurations that are local to a cluster node are displayed for all nodes. You can switch to the named collections view with the left tab.

Two actions are available:

  1. View the current configuration by clicking on the configuration name or in the case of cluster-local configurations on its Node ID.

  2. View all versions of some configuration by clicking on the icon in the last column.

When the list is sorted by time the configurations with the same name but different Node IDs are not grouped together.

All versions  Locate

Figure 30. View of all versions

View of all versions

This view shows all versions of a specified configuration. If such a configuration is local, multiple entries may be marked as latest, one for each node. Latest nodes are also highlighted. The Length of this list is limited by rules for retaining older configurations (see Configuration in database section).

Clicking on a configuration name will show the configuration which is described in the row.

Configuration view  Locate

Figure 31. Configuration view

Configuration view

This view shows specified configuration information including the content. There are also links to related versions of the configurations (such as latest, later, older, or oldest). You can see these related configurations by clicking on the view icon or compare differences between the displayed version and a selected version by clicking the differences icon in the selected row.

If the displayed configuration is not the latest, a Reactivate button appears in the window. Its function is to make the displayed configuration active (after confirmation). It does so by adding it as a new configuration entry with the latest time stamp.

Differences  Locate

Figure 32. Differences

Differences

This view can be invoked from the configuration view. It shows a comparison between two versions of the configuration. You can alter the options for differences comparison: whether it is case sensitive and whether the full text is shown or omitted.

Named collections of configuration  Locate

List of named collections  Locate

Figure 33. List of named collections

List of named collections

This view shows named collections of configurations which are stored in the database. It also allows you to capture the current state of configurations into such a collection so that you can later compare or restore them.

Creating new collections is easy. Just fill in the name and optionally the description of the collection and press the Make a snapshot button.

Once some collections are created, you can view their contents (by clicking the name) and compare them to the current set of configurations (by clicking the differences icon).

Activation of a collection means that all configurations that the collection holds will be added as new current configurations. Activation can be done on the collection as a whole (by clicking the icon in this view) or selectively on specified configurations (by button in the collection configuration view). Before activation proceeds a confirmation is required.

All Differences  Locate

Figure 34. All Differences

All Differences

This is what a comparison between a collection and the current set of configurations looks like. It shows the differences of matching pairs of all configurations. Matching configurations where no differences appear are listed below. Non-matching configurations (when the configuration appears in the collection only or in the current set only) are also listed below.

You can alter the options for differences comparison: whether it is case sensitive and whether the full text is shown or omitted. It is not recommended to show full text in all differences because the resulting page might get very long.

View collection  Locate

Figure 35. View collection

View collection

Collection content usually looks like this. When you click on the configuration name its view with actions is displayed.

View configuration  Locate

Figure 36. View configuration

View configuration

This view shows a configuration stored inside a collection. You can see the comparison between this configuration and the current configuration by clicking on button Differences. You can also make this configuration the current with the Activate button (after confirmation).