Previous
Next


Approval Process Principles  Locate

In this section, we will focus on approval process from the administrator's point of view. We assume you are familiar with basic principles of approval process described in the User's Guide, Approval Process in BEA AquaLogic Service Registry.

Approval process includes two types of registries: a publication registry and a discovery registry . The publication registry is used for testing and verification of the accuracy of data. Users publish data to the publication registry. The discovery registry houses approved data. It has no publishing API, but supports other BEA AquaLogic Service Registry APIs including inquiry, subscriptions, accounts, and so on. (In actual fact, the administrator can publish data to the discovery registry, but this is an exception.)

[Note]Note

Both publication and discovery registries must be running so that user accounts may be synchronized. When the discovery registry is down, it is not possible to register a new user account on the publication registry.

The accounts on publication and discovery registry are nearly the same. Accounts created on the publication registry and also all their changes are replicated to the discovery registry. But accounts can exist on the discovery registry that do not exist on publishing registry. The discovery registry contains right read-only data and can therefore be accessible for more users. It is possible to create accounts with inquiry and subscription privileges on the discovery registry that do not exist on the publishing registry. Note again that there is no Publish API on the discovery registry (except for administrator); the only way to publish data to the discovery registry is via the approval process.

Put another way: all accounts on the publication registry exist on the discovery registry, but not all accounts on discovery registry exist on publication registry.

When promotion is requested, automatic context checking is performed to ensure the consistency of data. For example, if a business service is contained in the keys for saving in the approval request and its business entity is missing on both the discovery registry and in the request, then the request for approval fails. The automatic context checker checks the integrity of data. If an entity is contained in keys for saving, then the parent entity must already exist on the discovery registry or be contained in keys for saving to the discovery registry. For detailed information, please see User's Guide, Context Checking.

Approval Process Roles  Locate

As noted above, the approval process registry has several roles associated with it:

Requestor  Locate

The requestor is a user on the publication registry who can ask for approval of data for promotion. Every user can ask for approval, but to be a requestor requires an administrator-assigned approval contact.

If a user does not have at least one assigned approval contact, an exception is thrown when this user asks for approval. There is no way for such a user to promote data to the discovery registry. By assigning approval contacts, the administrator determines whether to give users the opportunity to publish data into the discovery registry.

During the creation of users via the BEA AquaLogic Service Registry console or via API, the default approver, administrator, is assigned for all newly created users on the publication registry. The default approval contact for all users is administrator, though this does not apply to users defined in an external repository (LDAP). Note that demo data does not come with assigned approval contact. For example, the user demo_john does not have an assigned approver, thus the administrator must assign this user an approval contact in order for him to make a request.

For more information on the requestor's role, see the section Requestor's Actions.

Approver  Locate

The approver is a person or group who approves changes to the discovery registry. If the approval contact is group, then all its members are may approve data for promotion.

For detailed information on the approval contact's role, see the User's Guide, Approver's Actions .

autoApprover  Locate

A special approval contact exists in the approval process, the autoApprover. This role is defined in the registry at installation. The administrator can set autoApprover as the approval contact for trusted users.

This means that no human approval is required and such users' data is copied to the discovery registry upon request for approval, as long as context checking is successful.

Administrator  Locate

The administrator is responsible for setting up BEA AquaLogic Service Registry and is therefore also responsible for setting up the approval process. The term administrator refers to the user of BEA AquaLogic Service Registry who can manage the registry. Note that all users who have permission to configure the approval process are allowed to set relationships between requestors and approval contacts.

The manager of the approval configuration assigns approval contact(s) for requestors.

For easy management of relationships between approvers and requestors, it is possible to create an approver or requestor either from an existing user or from a group. If an approver is a group then each user in this group can approve the promotion of data. When several users (requestors) are in the same group, then an approval contact can be assigned to the whole group.

Optional Content Checking Setup  Locate

Optional content checking provides an approver the ability to programmatically check data for approval. For example, the approver can set a policy that:

  • Each business service must include a binding template, or

  • Each business service must be categorized by some specific categories

To enforce such a policy, a developer can write an implementation of the CheckerApi to ensure these checks. The implementation is called automatically during the approval process when an approver presses the Approve request button. Therefore, the approver does not have to check it manually.

To set up optional content checking:

  1. Write a class that implements the org.systinet.uddi.approval.checker.v3.CheckerApi

  2. There are two ways to make the implementation class available:

    • Copy the .jar file including the implementation class to the REGISTRY_HOME/app/uddi/services/Wasp-inf/lib, or

    • Implement a Web service that can perform the checkRequest() method from CheckerApi interface and deploy the service to the Systinet Server for Java

  3. Register the implementation of the content checker class in the BEA AquaLogic Service Registry data:

    1. Publish the WSDL of the checker service.

      Publish the WSDL located at http://<host_name>:<http_port>/uddi/doc/wsdl/approval_checker.wsdl to a new or already existing business entity. You should reuse the existing WSDL portType (tModel's name: CheckerApi, tModel's key: uddi:systinet.com:uddi:service:porttype:approvalchecker).

    2. Specify the checker in the access point of a new binding template.

      • If you have put your implementation of the CheckerApi into the registry classpath, then the value of access point must start with the class: prefix and continue with the fully qualified class name. For example class:com.systinet.uddi.approval.v3.approver.CheckerApiImpl.

      • If you have deployed your checker as a Web service to the Systinet Server for Java, then the access point is the endpoint URL of the service. For example http://localhost:6060/ContentChecker.

See Developer's Guide, Writing a Content Checker to see the implementation example.



Previous
Next