Oracle Service Registry

Oracle Service Registry provides a ‘DNS’-like reference for SOA. A fully compliant UDDI v3 registry, Oracle Service Registry provides a standards-based interface for SOA runtime infrastructure to dynamically discover and bind to deployed service end points. As part of the Oracle SOA Governance solution, Oracle Service Registry bridges the gap between the design time and runtime environments through automated synchronization with Oracle Enterprise Repository and Oracle SOA Suite
Comprehensive UDDI v3 compliance—Provides a standards-based mechanism for dynamic discovery of services and their associated policies during runtime
SOA agility—Keeps SOA infrastructure up-to-date with changes to service end points, ensuring your SOA doesn’t break
End-to-end SOA Lifecycle Management—Serves as the UDDI interface to Oracle Enterprise Repository for support of end-to-end management of the SOA lifecycle
Hot-pluggable—Supports heterogeneous services from any vendor

You can use Oracle SOA Suite with the following versions of OSR:

  • OSR 10.3 (with Oracle WebLogic Server 10.3)
  • OSR 11g

This section describes how to integrate Oracle Service Registry with Oracle SOA Suite 11g. It contains the following topics:
1. Integrating with Oracle JDeveloper
To create a connection between the Oracle Service Registry and JDeveloper:

  • Go to Oracle JDeveloper.
  • Select File > New > Connections > UDDI Registry Connection to create a UDDI connection.
  • Enter a connection name.
  • Enter an inquiry endpoint URL. For example:
  • Ensure that the Business View option is selected.
  • Click Next.
  • Click Test Connection.
  • If successful, click Finish. Otherwise, click the Back button and correct your errors.

2. Configuring Oracle Service Registry at Runtime
Oracle SOA Suite uses the SCA standard as a way to assemble service components into a SOA composite application. SCA provides a programming model for the following:

  • Creating service components written with a wide range of technologies, including programming languages such as Java, BPEL, C++, and declarative languages such as XSLT. The use of specific programming languages and technologies (including web services) is not required with SCA.
  • Assembling the service components into a SOA composite application. In the SCA environment, service components are the building blocks of applications.
  • SCA provides a model for assembling distributed groups of service components into an application, enabling you to describe the details of a service and how services and service components interact. Composites are used to group service components and wires are used to connect service components. SCA helps to remove middleware concerns from the programming code by applying infrastructure declaratively to composites, including security and transactions.
  • The key benefits of SCA include the following:
  • Loose coupling: Service components integrate with other service components without needing to know how other service components are implemented.
  • Flexibility
  • Service components can easily be replaced by other service components.
  • Services Invocation
  • Services can be invoked either synchronously or asynchronously.
  • Productivity: Service components are easily integrated to form a SOA composite application.
  • Easy Maintenance and Debugging: Service components can be easily maintained and debugged when an issue is encountered.

The Oracle Service Registry (OSR) provides a common standard for publishing and discovering information about web services. This section describes how to configure OSR against a separately installed Oracle SOA Suite environment:
3. Publishing and Browsing the Oracle Service Registry 
This section provides an overview of how to publish a business service. For specific instructions, see the documentation at the following URL:
To Manually Publish a Business Service

  • Go to the Registry Control: http://hostname:port/registry/uddi/web
  • Click Publish > WSDL.
  • Log in when prompted.
  • Complete the fields on this page to specify the access point URL and publish the WSDL for the business service. The following screen provides details.
If you later change your endpoint location, you must also update the WSDL location in the Registry Control. Otherwise, UDDI invocation fails during runtime. To change the WSDL location:
·         Log in to the Registry Control.
·         Navigate to the service.
·         Change both URLs within the port type and binding information using the model key
4. Configure a SOA project to Invoke a Service from the Registry  
To configure a SOA project to invoke a service from the registry:
·         Open the SOA project in which to create a reference to the business service.
·         Drag a Web Service icon into the External Services swimlane. The Create Web Service dialog appears.
·         To the right of the WSDL URL field, click the icon to select a WSDL.
·         From the list at the top, select Resource Palette.
·         Expand the navigational tree.
·         Expand UDDI Registry > Business Services.
·         Select the published business service, and click OK. The following screen provides details.
5. UDDI Deployment Options dialog.
  •  Select one of the following deployment options:
    •  Dynamically resolve the SOAP endpoint location at runtime.
    •  Dynamically resolve the concrete WSDL location at runtime.
  • The following screen provides details.

  •  Click OK. You are returned to the Create Web Service dialog.
  •  See the following section based on your selection in the UDDI Deployment Options dialog.

6.      Dynamically Resolving the SOAP Endpoint Location
  • Complete the remaining fields in the Create Web Service dialog, and click OK. The Create Web Service dialog looks as shown in the following screen.

  • Verify the wiring of the reference with the appropriate service component.

7.      Dynamically Resolving the WSDL Endpoint Location  
  •  Complete the remaining fields in the Create Web Service dialog, and click OK. The Create Web Service dialog looks as shown in the following screen.

  • Verify the wiring of the reference with the appropriate service component.

8.      Configure the Inquiry URL, UDDI Service Key, and Endpoint Address for Runtime 
You can set the inquiry URL, UDDI service key, and endpoint address during runtime in Oracle Enterprise Manager Fusion Middleware Control Console.
To configure the inquiry URL, service key, and endpoint reference for runtime:
  • Log in to Oracle Enterprise Manager Fusion Middleware Control Console and navigate to Common Properties, as shown in the following screen.

  • Specify values for the following properties:
    • In the SOA Infrastructure Common Properties page, specify the same UDDI inquiry URL in the Inquiry URL text box, as shown in the following screen, that you specified in the Create UDDI Registry Connection wizard. For example,

o   In the Properties page of the reference binding component, you can change the endpoint reference and service key values created during design time. For information, see section “Configuring Service and Reference Binding Component Properties” of Oracle Fusion Middleware Administrator’s Guide for Oracle SOA Suite.
  • Restart the SOA Infrastructure.
  • Exit Oracle Enterprise Manager Fusion Middleware Control Console.
  • To see endpoint statistics, return to the Registry Control.
  • Go to the Manage page and check statistics to see the increase in the number of invocations when not cached (the first time).



Best Practices – SOA Service Registry


Use the Right Type of Module:

  • Think about mediation logic vs. process logic.
  • Use Mediation Modules (Oracle ESB) for integration / mediation logic:
    • Short-running, minimal choreography.
    • Supports header manipulation.
  • Use (Integration) Modules (Oracle 11g Suite) for business / process logic:
    • Can be long-running, powerful choreography and business logic

Design your System Topology

  • Check if need more than one server.
  • Use clustering for scalability, For failover etc
  • Database selection.
  • Need to use a load balancer / HTTP server for failover and scalability.

Spend Time on Interfaces and Business Objects

  • Refactoring support is limited inside mediation flows, so good to get this right first time round.
  • Adopt a naming convention.
  • Add constraints?
    • Add modelled faults?
  • Think about namespaces.
  • Configure default namespace policy before you start.

Consider How you Split up Mediation Modules

  • How many mediation flows inside each mediation flow component?
    • Large number of modules impacts performance / deployment.
    • Small number impacts ease of development.
  • Remove unused library content.

Select your Binding Types Carefully

  • Often binding type dictated by circumstance.
  • But if you have the scope to decide:
    • Prefer SCA default/native for inter communications
    • Prefer Web Services for synchronous service exposure
    • Prefer JMS for asynchronous service exposure
  • Sometimes you have alternatives. For example:
    • Web Services binding : allows easy access to SOAP headers
    • Or
    • HTTP with SOAP data binding : allows access to HTTP headers but not SOAP headers

Consider your Custom Coding Strategy

  • Custom mediation:
    • Most useful for one-off coding.
    • Cannot be re-used between modules.
    • ‘Visual’ mode available which may be useful to those less comfortable with Java/SDO API.
    • Custom primitive (also called roll-your-own primitive):
    • A first-class new primitive: same abilities as any other primitive type (XSLT, Endpoint Lookup…).
    • Can have customisable properties.
    • Appears in palette in WID.
    • More re-usable, but more work to create.

Consider your Logging Strategy

  • You will want one; consider it before you start developing.
  • Options include:
    • Message Logger – limited functionality – logs only to a fixed schema database table.
    • JDBC or Flat File Adapter (in separate mediation module?)
    • Custom mediations logging.
    • Custom primitives.

Use Source Control & Do Automated Builds

  • Use source control and integrate with IDs
  • Only one developer per mediation module at once.
  • Automated build direct from source control.

Do Unit Testing
Do the unit testing before check –in