Registering Interest

I have been involved in some interesting discussions recently on the use of a service registry.  Oracle SOA Suite ships with a limited use license for a service registry and there is the option to upgrade it to a full use license and so the question comes up, Antony why would we want to use a registry and can we use it for all our service lookups.
Lets start by looking at what a registry is.

Glorified Yellow Pages

Uncharitably a registry may be described as a glorified yellow pages.  It allows artifacts such as XML schema and service WSDLs to be stored in a searchable, categorized archive.  Artifacts are stored under different categories and may have keywords associated with them to assist in searching.  So at the end of the day the registry is just a repository of meta-data about artifacts.  In the same way a car is just a large amount of beaten metal with a power unit that drives wheels.  Calling it a repository of meta-data does not actually explain what it does or how it may be used.

Registry use Cases

Let me suggest a few registry use cases

• Design Time Service Discovery
  A registry can be used to catalogue existing services and associated artifacts.  This encourages re-use by making it easier to discover existing services.  The ability to promote items between registries also makes it possible to put in place a service approval process that vets new services before making them available to developers.  This again promotes re-use and generalisation of existing services.
  
• Run Time Service Discovery
  A registry can also be used at runtime to provide the physical endpoint for a service.  This makes it easy to change the physical provider of a particular service.  This also simplifies migration of services between development test and production environments as outlined in the next use case.
  
• Service Migration Mechanism
  The use of multiple registries provided a managed path for services to be promoted between environments, either from a development perspective or from a runtime perspective.

Design Time Considerations

Use of a registry at design time is generally a good idea but it does a require a certain amount of discipline in its use otherwise it becomes yet another dumping ground for all design decisions, good and bad!  However individual develpoment team can maintain their own local registry that has a well defined promotion process to a central registry, allowing teams to work on their development services which may later be migrated to a corporate registry.  In my experience most customers are not making use of a registry even in their design time environments and this is probably the best place to start using a registry.

Run Time Considerations

Using a registry in a runtime environment promises a greater degree of de-coupling.  However a similar amount of decoupling may be achieved through the use of an ESB alone.  If a registry is used to look up an ESB endpoint then there is a potential cost to be paid in terms of an additional lookup.  If an ESB endpoint is not looked up then there is the risk of coupling the data formats of unrelated services together, losing the use of an ESB to provide message transformation to/from canonical form.  Some informal tests I ran indicated that the additional overhead of a registry lookup does not add much to the service invocation, but in high volume environments it may be the straw that breaks the camels back.
A good policy may be to begin using a service registry in design time, later trying it out in non-high volume environments.  Using an ESB can make this migration to registry use easier, if less pure by having the ESB perform the registry lookup.

Using a Registry with Oracle BPEL PM

The current production release of Oracle BPEL PM has built in support for use of a registry.  Al that is required to make a service lookup occur through a registry is to perform the following.

1. In the BPEL Console, go to the "Manage BPEL Domain" and set the following properties
• uddiLocation - the inquiry address of the registry
• uddiUsername - if it is a secured registry set it to a username for performing lookups, if not set it to urn:unknown
• uddiPassword - if it is a secured registry set it to a password for performing lookups, if not set it to urn:unknown
2. In a BPEL process for each service endpoint (partner link) that you want to go through a UDDI lookup
• Add a property "registryServiceKey" to the partner link with the "Entity Key" value assigned in the UDDI repository

For more on potential performance impacts of registry lookup see Chintan Shahs blog entry. Note that I haven't seen such a bad degradation as he reports, but I could believe it for a complex WSDL and high system load, meaning unresponsive threading, particularly in a Windows environment.

An Example of Dynamic Lookup

To give a feel for dynamic lookup I have uploaded 3 JDeveloper Projects in the this file.

• JavaWS includes a simple Java web service (GreetingWS) that can be registered in a service registry.  When registering it in the registry you will need to note the service key and copy it into the partner link property in Dynamic BPEL.
  
• DynamicBPEL is a BPEL process that looks up the web service (GreetingWS) and invokes it in three different ways
1. Static, it uses the endpoint defined in a WSDL file
2. Dynamic, it sets the endpoint explicitly (passed in as a parameter to the process), showing how you can be very dynamic in the endpoint you invoke.
3. UDDI, it uses the UDDI repository to lookup the endpoint, showing how unintrusive it is on the rest of the process.
• TestDynamic is a BPEL process that you invoke to test the DynamicBPEL process.  It iterates over all three methods and calculates how long each method takes to complete the given number of iterations.  The first invocation is not counted to allow the system to "warm up" for each call.