Approval Process in BEA AquaLogic Service Registry Locate
The approval process provides functionality to ensure consistency and quality of data stored in BEA AquaLogic Service Registry. There are two registries in the approval process:
a publication registry is used for testing and verification of data;
a discovery registry only contains data that has been approved and promoted from the publication registry.
See the Installation Guide for details of how to install and configure these registries.
The approval process includes two types of users:
A requestor is a user of the publication registry who can request approval of data for promotion to the discovery registry;
An approver is a user who can approve or reject requests for promotion of data.
Adminstrators can specify:
the users or groups of users who are approvers;
the users or groups of users whose requests they can approve;
Every user can ask for approval, but to have data considered for promotion, a user must have an administrator-assigned approver.
For more information see Approval Process Management in the Administrator's Guide.
Approval requests have a lifecycle shown in Figure 1. A requestor can create a request. Once the request is created, the requestor can add UDDI data structures (described in UDDI Data Model) or resources (WSDL, XML, XSD and XSLT) to the request. Note that the requestor does not need to know how resources are mapped to UDDI data structures. When the requestor adds a resource to the request, all underlying UDDI structures (bindings, tModels) the resource represents are automatically added to the request. Once the requestor specifies all entities to promote, the request may be submitted for approval.
The approver will review incoming requests, and then can approve or reject the request. If the approver approves the request, the requested data is immediately promoted to the discovery registry. If the requestor is not satisfied with the approver's response time, this user can remind the approver to review the requests. The requestor can also cancel submitted requests.
In the following section, we will look at requestor's and approver's actions in detail.
Requestor's Actions Locate
A requestor may perform the following actions:
Submit a request for approval of data promotion
After submitting the request, all data referenced in the request is blocked (locked for writing) until the request is either canceled by the requestor, approved for promotion, or rejected by the approver.
![[Note]](../images/note.gif)
Note A requestor may request approval for the promotion of the same set of data several times, and may have several unprocessed requests at one time.
Find request.
This action provides the requestor with the ability to list information about all requests. If the requestor has privileged access on the Requestor API, then it is possible to get brief information on the requests of other users. Otherwise only the requestor's own requests may be viewed.
Get request
This action returns full information about the given request. If the requestor has privileged access on the Requestor API then they can obtain full details of other user's requests. Otherwise only the requestor's own requests may be accessed.
Cancel request
Provides requestor with the ability to cancel the given request. Only requestors with privileged access can cancel the requests of other requestors.
Synchronize data
This action enables the requestor to synchronize data on the publication registry with data on the discovery registry. There are three types of synchronization - publication priority, partial discovery priority, and full discovery priority. For detailed information about synchronization, please see Synchronization of Data.
To publish data to the discovery registry, the data must first be published to the publication registry and then approved by an appropriate approver. Once the requestor is satisfied with the quality of data, it is possible to ask for data promotion.
Requestors can publish data on the publication registry for testing. Once this data is ready for approval, the requestor asks for approval. An approval request contains two different sets of keys - keys for saving and keys for deletion. The keys select the data. Keys for saving are used for entities to be published (saved or updated) to the discovery registry. Keys for deletion can be used for deletion of any entity from the discovery registry. Approval requests can contain data (keys of entities) either for saving or for deletion.
Both types of keys can contain keys for businessEntities, businessServices, bindingTemplates, tModels or publisherAssertions. For example, if a requestor wants to promote a businessEntity to the discovery registry and remove a bindingTemplate from a service on the discovery registry then the request for approval must contain the key of the businessEntity in the keys for saving and the key of the bindingTemplate in the keys for deletion. After successful approval the business entity is saved (created or updated) to the discovery registry and the binding template is deleted from the discovery registry.
Context Checking Locate
During a request for approval, and when approval is granted, automatic context checking is processed to ensure the integrity of data from a request. The context checker has the following rules:
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 a businessService, the parent is a businessEntity; for a bindingTemplate, the parent is a businessService.
An entity whose key is included in those for deletion may not be referenced by an entity whose key is included in those being saved.
An entity whose key is included in those for deletion must exist on the discovery registry.
Deleting a tModel that is referenced by entities on the discovery registry is not allowed.
If a publisher assertion is included in keys for saving, then its business entities (specified in fromKey, toKey) and tModel must already exist on the discovery registry or be contained in keys for saving.
If the data is valid, according to these rules, the request for approval is made.
If data is invalid (for example, an entity is included in keys for deletion that does not exist on the discovery registry), an exception is thrown and the request for approval is not made.
If context checking fails, the requestor is informed that the data must somehow be changed before requesting approval again.
A Special Approval Case Locate
If the registry administrator trusts a requestor, that requestor may be assigned the approval contact AutoApprover. Under this approval contact, there is no human review of the data. The data is automatically promoted to the discovery registry as long as automatic context checking is successful.
Approver's Actions Locate
Approval contacts are assigned by users who have permission to set up the approval process via the ApprovalConfiguration API (such as registry administrator). The approval contact reviews requests to promote data to the discovery registry and approves or rejects these requests.
If enabled, content checking (additional rules applied to approved data) is performed at this time as well.
If context checking and content checking are successful, an email is sent to the requestor indicating the successful promotion of data, and including any message entered in the Message for requestor box.
Optional Content Checking Locate
Optional content checking provides an approver with 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 specified categories
To enforce such a policy, a developer can write an implementation of the Checker API to enforce these checks. The implementation is called automatically during the approval process when an approver presses the Approve request button. So the approver does not have to check it manually. For more information on setting up optional content checking, see Optional Content Checking Setup in the Administrator's Guide.
Synchronization of Data Locate
Requestor's synchronization is used to synchronize the information on the publication and discovery registries. There are three different kinds of synchronization described below - publication priority, partial discovery priority and full discovery priority. Each is performed on all data structures associated with the synchronizing user's account. Synchronization is performed only upon request.
| Note |
|---|---|
These tools do not change information on the discovery registry. The only way to change data on discovery registry is via the publication registry and the approval process. Only administrator can publish to discovery registry. | |
Publication priority Locate
Publication priority has the following rules:
If an entity exists only on the discovery registry then it is copied to the publication registry.
If an entity exists only on the publication registry then it is preserved.
If an entity exists on both registries, then the publication registry takes priority over the discovery registry.
Publication Priority Example Locate
Before synchronization, structures A and X exist on the publication registry and structures X and B exist on the discovery registry.
The Publication Priority synchronization copies structure B to the publication registry. Structure X on publication registry remains the same because when the same entity exists on both servers, Publication Priority synchronization favors the publication registry.
Partial Discovery Priority Locate
Partial discovery priority has the following rules:
If an entity exists only on the discovery registry, then it is copied from the discovery registry to the publication registry.
If an entity exists only on the publication registry then it is preserved.
If an entity exists on both registries, then data on the publication registry is overwritten by data from the discovery registry.
Partial Discovery Example Locate
Before this synchronization, structures A and X exist on the publication registry and structures X and B exist on the discovery registry.
Partial discovery synchronization copies structure B to the publication registry and overwrites the version of structure X on the publication registry with that from the discovery registry.
Full Discovery Priority Locate
Under this synchronization scenario, all the user's data on the publication registry is deleted, and all the user's data from discovery registry is copied to the publication registry. After full discovery priority synchronization, data on the discovery and publication registries is identical.
![[Important]](../images/important.gif) | Important |
|---|---|
The BEA AquaLogic Service Registry administrator cannot execute full discovery priority synchronization. | |
Full Discovery Example Locate
Before synchronizing, structures A, X, Y and B exist on the publication registry and structures A, X and B exist on the discovery registry.
Full discovery synchronization deletes structures A, X, Y and B from the publication registry, and replaces them with A, X, and B from the discovery registry.
Related Links Locate
Installation of publication and discovery registries - Installation Guide.
Approval process via Business Service Console - User's Guide, Approval Process
Configure requestors and approvers - Administrator's Guide, Approval Process Management