subbu.org

Here is a realistic application of UDDI registries. This one is not
imaginary, and is not driven by a need to somehow use a registry to get
SOA qualified. Moreover, you may not find this use case prominently
anymore in white papers and brochures on UDDI registries.

In the past, I have blogged about the

hype around registries, repositories and SOA, and I have been

quoted for that. But now, I am about to describe a use case for which
using UDDI registry makes sense. This is one of the few use cases where
finding, and consuming business services at runtime (and not design time)
is possible. In this case, users search for services, select services, and
start using them almost immediately. Please be warned that this use case
does not involve any of the following use cases that registries have been
touted for:

• Dynamic routing of service requests
• Enforcement of policies
• Controlling the integrity of services published
• Governance

My use case is more basic than all of the above. Here it is.

• A developer writes a an app with a web-based UI, and deploys it.
• A user wants to find and it and use it.

In this use case, the app is a portlet, and the user is interested in
finding portlets based on some metadata, and using them. The user is not
interested in understanding the interfaces for services, or their
semantics, or designing software to use services. The user may be a
typical web surfer, or an administrator creating portals. Here is how UDDI
helps solve this use case:

• The runtime hosting the app publishes the app as business service in a
  UDDI registry. Note that the app is not a web service.
• User searches against the registry using some high-level UI. The UI
  presents portlets.
• When the user finds a portlet that he/she is looking for, the user
  will aggregate it into a portal page, and start using it right away.

As I have argued

previously on this blog, most typical service clients can not take
advantage of dynamic discovery of web services through a UDDI registry.
The reason is that most web services are tailored to to specific business
use cases, and a developer needs to know about the service at design time.
The developer will have to look up the WSDL, the schema for messages, and
some other documentation to understand the semantic meaning of each and
every detail of the service.

However, in my use case, the services and the clients are generic, and in
most cases, users can use a service as soon as finding one. Here is how:

• The business service in my use case is a portlet. A portlet is usually
  an app encapsulating some UI, business logic and data.
• The runtime for portlets (a.k.a portlet producer) supports
  
  WSRP, and can offer portlets over web services to any client
  supporting WSRP.
• The producer publishes each portlet as a business service in a UDDI
  registry. The producer can do this behind the scenes without requiring the
  portlet developer/deployer understand UDDI.
• The client is a portal or an application (a.k.a. consumer) that can
  aggregate portlets into web pages. The client implements WSRP.
• When a user searches for portlets, the consumer searches the registry
  for matching business services, and presents the results as portlets.
• The user aggregates portlets found into web pages.

In this use case, both the service and client are generic, and that is the
key to publishing, finding, and using services dynamically at runtime.

I must say that I’m quite excited about supporting this use for the next
release of

WebLogic Portal due to be released in a couple of months. Prior to
supporting this use case, finding portlets was not very easy. Let’s say,
portlets are hosted in a number of producers. Each producer offers a
WSRP-compliant WSDL, and one of the operations in the WSDL can be used to
fetch a list of portlets available on a producer. To search for portlets,
the user will have to go through this list from each producer. This can be
tedious if the number of portlets is large. UDDI helps simplify this use
case. By mapping portlets into business services, and publishing them into
a registry, the problem is much simplified. Instead of browsing lists of
portlets, users can type in keywords or other criteria to search for
portlets. To help this use case, the WSRP TC released a

technical note that describes a mapping portlets and portlet producers
into services that can be published into

UDDI or

ebXML registries. 

There are few issues that may stand in the way of using portlets found in
a registry immediately. In some cases, the user may not have enough
privileges to use a portlet. In other cases, the user may require the
assistance of administrators to help meet the security policy requirements
of portlet producers. But once these infrastructure issues have been
related, finding and using portlets is as easy is getting some plumbing
help via yellow pages.

Despite this simplicity, I don’t imagine emergence of global portlet
registries. The main reason is that a portlet registry makes sense when
there are a large number of remote portlets deployed, and typically such
deployments may be limited to large enterprises. Secondly, there are still
issues around security and other quality of service, and these require
out-of-band negotiation in most cases.