Requestor Approval Process Roles

7.1.2. Approver

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 contacts role, see the Users Guide, Section 1.5.2, Approvers Actions .

7.1.3. autoApprover

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.

7.1.4. Administrator

The administrator is responsible for setting up Oracle Service Registry and is therefore also responsible for setting up the approval process. The term administrator refers to the user of Oracle 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 contacts 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.

7.2. Optional Content Checking Setup

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_HOMEappuddiservicesWasp- inflib , or • Implement a Web service that can perform the checkRequest method from CheckerApi interface and deploy t h e s e r v i c e t o t h e S O A P s t a c k o f y o u r c h o i c e . U s e http:host_name:http_portuddidocwsdlapproval_checker.wsdl to generate a web service. 3. Register the implementation of the content checker class in the Oracle Service Registry data: Page 376

7.2. Optional Content Checking Setup

Publish the WSDL of the checker service. Publish the WSDL located at http:host_name:http_portuddidocwsdlapproval_checker.wsdl to a new or already existing business entity. You should reuse the existing WSDL portType tModels name: CheckerApi, tModels key: uddi:systinet.com:uddi:service:porttype:approvalchecker. a. b. 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 SOAP Web service , then the access point is the endpoint URL of the service. For example http:localhost:6060ContentChecker. See Developers Guide, Section 3.6, Writing a Content Checker to see the implementation example.

8. PStore Tool

The PStoreTool provides Oracle Service Registry Protected Store management. It provides functionality to: • Import and export trusted certificates locally to or from a file. • Create new security identities in the Oracle Service Registry configuration file. • Copy identities between protected stores. Note Remote protected store management via SOAP is not supported with Oracle Service Registry. The general usage is: PStoreTool [command [options]] You can perform operations from the command line or start up a GUI interface.

8.1. Commands Description

The PStore tool has the following commands: • new - Creates a new security identity in the local protected store. The configuration file of the protected store can be specified using the -config parameter. • newServer - Creates a new security identity on Oracle Service Registry. The location of the server is specified with the -url parameter. • copy - Copies the existing security identity from one protected source to another or to the Oracle Service Registry protected store. • add - Adds a trusted X.509 certificate to the local protected store. The X.509 certificate can be supplied as a local file. Page 377

8.1. Commands Description