Having covered the product architecture for OSR, let us now turn our attention to the functionality provided by the tool in support of SOA Governance.
OSR fully implements the UDDI specification providing an open standards framework for exposing services and their associated metadata. OSR is used to provide an interface by which selected OER content may be accessed or published and serves as an integration point for runtime tooling such as Oracle Service Bus, Oracle SOA Suite 11g, and JDeveloper. Oracle Service Bus can automatically publish and subscribe to new or modified assets.
OER and OSR are synchronized using the Oracle Registry Repository Exchange Utility.
While OSR fully implements the core UDDI V3 standard, Oracle has additionally provided key extensions to the base standard to provide support for enterprise deployments. These include:
- Advanced security that provides a mechanism for defining granular access control for registered components. Component publishers can specify find, get, modify, and delete access permissions for every published object.
- Data accuracy and quality enforcement mechanisms to ensure that component registrations are accurate and up-to-date. OSR clearly defines responsibility for every registered component. It offers component promotion and approval mechanisms for promoting components between development, QA, and production environments.
- Subscription and notification mechanisms for automatically notifying registry users about changes to components to which they subscribe.
- Selective replication among multiple registries allowing for automated propagation between different registries. For example, between internal and external registries.
- Advanced Taxonomy management for enforcement of well-defined taxonomies.
- Powerful management for granular control, logging, and auditing of the publishing and discovery processes.
- OSR provides maximum performance and scalability for a UDDI Registry by efficient implementation of the web services stack and database algorithms, and by supporting load balancing and clustering mechanisms.
Users interact with OSR using two-key functional components and their associated user interfaces. These are the Registry Control and the Business Service Control. These consoles provide a user interface that wraps UDDI web service implementations, allowing the user to search, maintain, and publish components to the registry.
Registry Control is aimed at developers familiar with Business Entities and tModels. It allows users to create tModels, define taxonomies, browse and publish registry content, create subscriptions, and manage security. Registry Control is also the primary console for administrators to perform registry management.
Business Service Control provides a much simpler user interface for less-technical users who are unfamiliar with tModels and other complex attributes. UDDI functionality is exposed through easy-to-use and customizable publication wizards. Developers, architects, and business users can browse the registry from different perspectives to locate services and artifacts using business-relevant abstractions of SOA information such as schemas, interface local names, or namespaces.
Services can be published and discovered using both configurations.
The registry console is the primary user interface for advanced users and for administrators to perform registry management. The console provides users with more fine-grained access to the UDDI Registry information model, allowing them to add and amend tmodels and other UDDI artifacts including taxonomies.
Registry Control can be found at http://<hostname>:<port>/<context>/uddi/web. The host name and port are defined by the administrator when OSR is installed. The default port is 7101 or 8888, depending on application server settings. Accessing this URL provides access to a home page from which the user can log into the registry (or create a log in account) and search and amend the registry. The home page is shown as follows:
Registry Control supports the following functionalities:
|
Function |
Description |
|---|---|
|
Browse |
This link allows users to browse UDDI entities. |
|
Search |
This tab allows users to search the registry. Users can perform queries on UDDI entities, search for services, Binding Templates, tModels, and related Business Entities. The Menu option also allows users to browse taxonomies. Entities are queried directly using their entity key if it is known in advance (business, service, Binding Template, and tModel). |
|
Publish |
This tab allows users to publish UDDI structures ( |
|
Profile |
Users can use this link to maintain user account properties, account groups, and favorite taxonomies. |
|
Manage |
This tab is used by the Oracle Service Registry administrator to perform management tasks. Refer to the Administrators Guide for more information. |
Before any artifacts or services can be published to the registry, we have to publish a Business Entity for the Service Provider. In this section we will provide an example of using ORC by creating a new Business Entity.
- The user should first log into the ORC and then click on the Publish link. The following screenshot illustrates that, by right-clicking on the Businesses node in the tree navigator, we can add a new Business Entity. In this case, we are going to add
Weir & Bell Telecomas a Business Entity:
- The user then enters the Publish wizard. The following screen is used to specify the Name and Description value of the new Business Entity. We can also add a custom Business Key value for search purposes:
- Once the details have been entered, click on the Add Business button to create the new Business Entity. A screen similar to the one shown as follows will appear showing the newly created entity:
This section provides a high level overview of the functions that can be performed under Business Control Service.
Business Service Control can be found at the following URL: http://<hostname>:<port>/<context>/uddi/bsc/web. The host name and port are defined when OSR is installed. The default port is 7101 or 8888, depending on the application server setting. The context is specified during the installation and defaults to registry.
A user must have an OSR account before they can publish data to the registry. The following section details the account setup process.
A user must create an account before publishing data to the Registry. An account can be created from the Business Service Control console (or the Registry Control console) as follows:
- Click on the Create New Account link illustrated as follows:
- Then the user enters their details illustrated as follows:
- The user should select their role from the My Profile tab. OSR contains a list of predefined user profiles that differ in respect of which main menu tabs will be available to them. Each user profile also contains a definition of default formats for result views. The registry administrator can adjust these as required:
- And finally, once the user has entered their details they should click on Create Account.
OSR Administrators can maintain accounts from the ORC including group membership and permissions.
Tip
Please refer to section Registry Configurations and Permissions of the OSR OFM Service Registry Guide 11 g (11.1.1.6.0). URL: http://www.oracle.com/technetwork/middleware/registry/osr111productdocumentation-159992.pdf.
Business Service Control allows users to search OSR for services and related metadata. Searching functions are located under the Search menu tab and allow consumers to search for Providers, Services, Endpoints, and other artifacts that have been published to OSR.
The following screenshot shows the Search tab as selected by a user:
Properties for search criteria are used in conjunction with one another. The search function returns all records that satisfy any of the search criteria property values.
The following screenshot shows the options available for searching that include Keywords, Local Name, and Namespace, among others:
Under the Catalog main-menu tab, users can use publishing wizards to publish entities to OSR:
The following entities can be published from this tab:
|
Entity |
Description |
|---|---|
|
Providers |
A two-step publishing wizard allows users to enter a provider's name and description, taxonomy classification, and contacts. |
|
Services |
A four-step publishing wizard guides the user through publishing a service, its interfaces, and its endpoints. |
|
Interfaces |
A wizard for publishing and republishing service interfaces. |
|
Resources |
This node allows users to publish WSDL files, XML files, XML schemas, and XSL transformations. |
Any UDDI Registry user can subscribe to a set of UDDI entities and monitor their creation, modification, and deletion. The UDDI Registry notifies the user whenever any entity that matches the subscription query changes even if the change itself causes the entity to not match the query any more. The following entities can be monitored: providers, services, interfaces, and endpoints, as well as resources (WSDL, XML, XSD, and XSLT).
The notification can be synchronous or asynchronous. Synchronous notifications occur when the interested party explicitly asks for all changes that have happened since the last notification. Asynchronous notifications are periodically run at a configurable interval and notify interested parties whenever the matched entity is created, modified, or deleted.
The following screenshot shows a user adding a subscription to Holiday request service:
Users can establish a subscription based on a set of entities in which they are interested or on a specific search query. Users can receive notifications about modified structures via e-mail or they may view the modified entities under the Tools main-menu tab in the My Subscription Results section.
The approval process governs the consistency and quality of data stored in OSR. It involves the creation of two registries. One registry is used to publish entities for verification by a supervising party and the other is a Discovery Registry, which is open to consumers and only contains data that has been approved and promoted from the Publication Registry.
The approval process includes two types of users. A requester seeks approval for data to be promoted to the Discovery Register. An approver is a user or a group given the ability to review published information in the Publication Registry. The approver can grant or deny approval in order to promote that data to the Discovery Registry. Every user can ask for approval; however, to have data considered for promotion, a user must have the administrator-assigned approver privilege. An approver group can be created with multiple users assigned.
The Business Service Control console contains a set of predefined reports under the Reports main-menu tab. A registry user can browse and execute these reports:
The Business Service Control console includes the following predefined reports:
|
Report Functionality |
Description |
|---|---|
|
Usage |
This report shows services, resources, endpoints, and interfaces categorized by the |
|
Endpoint status |
This report shows endpoints categorized by the |
|
Interface status |
This report shows interfaces categorized by the |
|
Namespace |
This report shows services, endpoints, interfaces, and resources categorized by the |
|
Local Name |
This report shows services and endpoints categorized by the |
|
Certification |
This report shows services categorized by the |
|
Availability |
This report shows endpoints categorized by the |
|
WS-I Compliance |
This report shows endpoints and interfaces categorized by the |
|
Milestone |
This report shows services categorized by the |
|
Release date |
This report shows services categorized by the |
|
Version |
This report shows services categorized by the |
In OSR, roles are tied to permissions. Permissions, used by administrators, define the right to perform an action on a part of the interface. They represent the ability to process a particular method on a particular UDDI interface.
Permissions are very different from Access Control Lists, which is the other mechanism for enforcing rights in OSR. Access Control enables the administrator to control access to the basic UDDI data structures such as businessEntity, businessService, bindingTemplate, and tModel. Access Control on OSR is provided by the Access Control List (ACL). An ACL is based on permissions given to a user or group. An ACL ensures that a given user can access only the information that has been made available to the user by the Registry administrator or other users.
Thus, Access Control Lists limit the visibility of entities and so restrict access to the underlying UDDI data structures stored in OSR. Permissions, on the other hand, limit users through the visibility of interfaces.
Tip
For more details on permissions and ACLs, please refer to chapter 6 Permissions of the OFM Service Registry Guide 11 g (11.1.1.6.0). URL: http://www.oracle.com/technetwork/middleware/registry/osr111productdocumentation-159992.pdf.