Without doubt, OER is Oracle's flagship product for design-time Governance, providing rich management features for controlling SOA Assets and their dependencies as well as support for approval and publishing of Assets.
OSR compliments OER by also providing support for runtime governance, but the observant reader may well have noticed a number of overlaps between the two products in the design-time Governance space. For example, both OER and OSR support Asset approvals, service lifecycle via promotions between environments, and the categorization of Assets using taxonomies.
While this chapter has focused on the rich functionality provided by OSR, the reader may be keen to understand how Oracle envisages the two products working hand-in-hand. The following section sets out to answer some of those questions.
As explained earlier in this chapter, OSR can be installed in standalone or multi-registry mode. In organizations where OSR and OER co-exist, the recommended topology is to install OSR in standalone mode and to use OER to manage Asset approval and Asset promotion to multiple environments.
OSR and OER can co-exist in the same WebLogic Domain and the same managed server. However, at the time of writing, a system bug prevents OSR from functioning properly when OER events are turned on.
Thus, our recommendation is to install OSR in standalone mode within its own dedicated managed server and as part of the SOA domain.
As described previously in the chapter, OSR has inbuilt functionality to support Asset approvals. However, the implementation is quite heavy weight, requiring SSL and the installation of multiple registries: one or more Intermediate Registries and a Discovery Registry. Oracle recommends using OER for approvals instead as these are better supported and more lightweight. The following diagram shows how OER can be used to promote Assets between environments using the approvals process:
As can be seen in the preceding diagram, OER handles approvals and promotions of Assets across all environments.
OSR can be employed to monitor service utilization and to provide runtime metrics for service usage. These metrics can feed back into OER to help make more informed Asset management decisions such as defining SLAs.
OSR can also be used to enforce runtime control on Assets, ensuring adherence to SLAs, policies, and performance requirements. Once again, information can be sent back to OER to assist in design-time decision making.
When used with the SOA management packs, Oracle Enterprise Manager can also provide OER with runtime performance metrics using prebuilt integrations with OER APIs:
As we have seen in previous sections, OSR can be used to define new taxonomies or utilize standard prebuilt UDDI taxonomies. However, categorization is better served earlier on in the Asset lifecycle by employing OER to categorize all SOA Assets. Consequently, it is considered best practice to use OER to master all taxonomies rather than OSR when the two products are co-deployed. These taxonomies should be defined prior to service publication to a registry. Generally speaking:
- OER should be used as the single source of truth for taxonomies. Approved taxonomies can be propagated to OSR using supplied utilities. This eliminates the need to create custom taxonomies in OSR.
- Service classification schemes should be determined before services are published to the registry.
- The service providers should not use the default OSR taxonomy. Furthermore, the administrator should remove all unused taxonomies from OSR.
- Taxonomies should be kept simple and business focused to encourage their use in the registry. This is because a registry is only as good as the ability to search it based on a sensible classification scheme.
The following diagram shows how OER taxonomies are mapped to OSR:
