OSR has a much simpler architecture than OER. The following diagram shows the conceptual architecture of the product. The sections that follow will elaborate on each of the application layers shown in the following figure:
OSR is essentially a set of web services and applications that implement and conform to the UDDI specifications. The Java-based web applications provide a framework for publishers to register services in a registry and for consumers to locate and consume these services.
The OSR installer supports a standalone-registry or multi-registry configuration. The default installation option provides a standalone registry and enables the creation of a new registry database.
For Discovery, Publication, or Intermediate installation options, multiple registry installations are required to support approval processes. A multi-registry deployment is appropriate for environments where organizations want to impose more control over the exposed registry content. Quality control processes are implemented by separating the registry into Publication and Discovery registries, with an Approval Process to control promotion of services from one to another. This approval process can be configured to use either manual or automated approval of promoted information. An Intermediate registry sits between one or more Publication Registries and a top-level Discovery Registry.
OSR can be clustered to provide increased scalability and resilience, and also configured to use external accounts in an LDAP repository.
Tip
Detailed installation instructions for OSR can be found in Oracle Fusion Middleware Service Registry Guide 11 g (11.1.1.6.0). URL: http://www.oracle.com/technetwork/middleware/registry/osr111productdocumentation-159992.pdf.
A relational database is required to store data and metadata associated with an OSR installation. Although the preceding diagram shows an Oracle relational database, OSR is also certified against MSSQL or DB2. Installation options include the ability to create a new database or to populate a new schema in an existing database.
Currently, OSR 11g is only certified with the Oracle's WebLogic Application Server. The primary recommendation when implementing OSR along with OER is to install a standalone topology of OSR 11g in its own Managed Server within the same WebLogic Domain as the SOA Suite, illustrated as follows:
This setup has the advantage that it does not require a completely separate domain to be created for OSR. Since OSR is contained in a dedicated managed server, this configuration provides the administrator with the flexibility to configure and tune the registry independently in its own JVM. Alternatively, OSR can be installed in its own separate WebLogic Domain. In this architecture, OSR is completely independent of the SOA Suite and can be managed separately, meaning that the environment can be independently patched and backed up. The downside to this configuration is that there is an added overhead for creating and maintaining the extra WebLogic Domain for OSR.
For enterprise deployments, OSR should not be installed in the Admin Server since the Admin Server is meant for administrative applications such as Enterprise Manager and the WebLogic Console. Changing any configurations in this managed server can lead to unpredictable behaviors for the registry server. Smaller departmental or development environments can employ this configuration, but as a general rule OSR should be deployed in a separate managed server. This ensures that OSR does not conflict with existing applications and provides OSR with a dedicated JVM leading to better flexibility, availability, and scalability.
The content of a UDDI Registry can be replicated using a simple parent-child model. The registry replicates data according to multiple replication definitions that are defined using standard UDDI queries. The parent-child relationship is specific to the replication definition, so one registry might be the parent registry for one specific replication definition and a child for another. The security settings (ACL, users, and groups) are not subject to replication, but permissions can be configured on replicated data.
One of the most important advantages of UDDI version 3 is its support for digital signatures. Without signatures a service consumer cannot verify whether the publisher of a Business Entity is really who they claim to be. When a publisher has signed the UDDI structure, however, consumers can verify that the registry information is unmodified and can confirm the publisher's identity.
The OSR Signer tool is provided to simplify signature manipulation. The tool's scripts are located in the bin directory of the OSR installation. The Signer is a graphical application that can be used to add, remove, and verify the signatures of UDDI structures you have published.
Tip
More details of how to utilize this tool can be found in section 2.6.2 Signer of the OFM Service Registry Guide 11 g (11.1.1.6.0). URL:
http://www.oracle.com/technetwork/middleware/registry/osr111productdocumentation-159992.pdf.