 | Level: Introductory Steve Graham (sggraham@us.ibm.com), Web Services Architect, IBM Emerging Internet Technologies
01 May 2001
Part one of this series introduced the topic of Web service discovery and examined six basic UDDI species. In this installment, Steve Graham contrasts the programming models associated with using a UDDI operator node and those models associated with using a private, non-operator node. He also discusses two kinds of additional API and related facilities: those that support interactions between different private UDDI nodes, and those that allow interoperability between private UDDI nodes and the UDDI operator cloud.
Private UDDI nodes and the UDDI operator
cloud make up two distinct usage categories, each of which implies a very
different programming model. Although they both implement the 20 APIs represented
in the UDDI API specification, the implementations for the operator cloud
and for the private nodes optimize different areas of the design, corresponding
to their different uses. A set of additional functions discussed in this article specifies
collaboration among private nodes and between the operator nodes and operator
cloud. Let's take a look at each of these nodes and the ways in which they
can be made to communicate effectively.
Operator cloud use: design-time discovery
The operator cloud contains Web services data for different kinds of
businesses in various geographies and industries. Some of this data represents
legitimate business and information about the business processes exposed
as Web services. Some of this data represents organizations posing on the
transactional Web, but do not provide Web services. Finally, some of this
data can represent fraudulent or misleading information on business intent.
So, we must be able to distinguish between meaningful entries and entries
that are a waste of time.
The operator cloud also contains a wide range of mechanisms to describe
services. Although the IBM Web Services Architecture recommends the use
of WSDL to describe Web services, the tModel facility in UDDI actually
allows any mechanism to describe Web services. The tModel could, among
other things, be something computable, like a WSDL service-interface definition,
or a reference to a text document describing the service in prose, or a
description using RosettaNet' PIP format. Its flexibility allows for these
different options.
But the universality of the UDDI Business Registry limits its usefulness
for dynamic binding. It is not a target-rich environment for doing
dynamic service find and bind operations since
the ratio of potential targets to actual matches for the operation are
very low. Businesses generate a lot of false hits that are not interesting
or legitimate business partners. Service descriptions allow too varied
a set of find operation results to be immediately translated into code
for service invocation. Future versions of the UDDI API may improve the
find
APIs to address some of these concerns.
If Web services discovery relies only on the operator cloud, all discovery
operations must be performed at design-time. So you can not rely on supporting
tools to build the application's use of the UDDI entries returned from
the find operations. This means that the tModel must be examined
in detail, and the Web service must be invoked by handcrafted code based
on the text-prose description of the tModel.
Private node use: design-time or run-time discovery
The contents of the UDDI entries within
a private node can be constrained to follow certain patterns. These patterns
include only approved partners (for example, partner-catalog UDDI species)
or only allowed WSDL-based tModels. Efforts taken at publish-time
to ensure a target-rich environment will have significant impact on the
programming model for requestor-applications doing find calls
against the private UDDI and using the resulting entries to bind to Web
services.
For example, a requestor-application suite executes find calls
against a partner-catalog UDDI node. Because of publish-restrictions on
this private node, both the legitimacy of the service provider and the
computability of the service description found in associated tModels (for example,
entries reflecting Web services described using WSDL), guarantee the application.
These guarantees mean the programming model may use dynamic find
and
bind
operations at run-time. These dynamic find
and
bind
operations are the foundation of the loosely-coupled nature of Web services.
The requestor-application specifies the find call parameters
(for example, find all services that implement the tModel corresponding to some RFQ web
service interface standard). The find operation executes at run-time
against the partner-catalog UDDI node; the resulting set is all of the
approved business partners that support the RFQ Web service interface definition.
The application is then free to invoke any or all of the Web services found.
Because they all implement the same tModel, and the tModel refers to a
WSDL service interface definition, the application can use a single service
proxy as a front-end to the RFQ Web service
of any business partner selected by the find operation.
Implementing private nodes vs. operator nodes
Due to the possible volume of data and the replication semantics imposed
by the operator-agreement, operator cloud nodes must be designed to optimize
data throughput. Private nodes are free from this restriction, but the
intended use of private nodes encourages other design tradeoffs.
Private nodes have several distinguishing characteristics. They can
be lighter weight, they do not have to implement the replication API, and
their transaction volumes are significantly less than operator nodes. Some
large organizations may choose to implement private nodes as a federation
of nodes, in which case a replication model may be required. A private
UDDI implementation should emphasize design characteristics such as ease
of configuration or reconfiguration (this is, pluggability of supporting components,
including the XML Parser, SOAP message processor, database, Web application
server, etc.) and deployment flexibility to decide which UDDI APIs to deploy
(that is, standard UDDI APIs as well as value-added APIs).
Managing the relationships between UDDI nodes
The world is somewhat simpler when there is only one species of UDDI.
The UDDI spec was written to support use-cases related to the single UDDI
operator cloud. The replication semantics and the conventions surrounding
the use of Universally Unique Identifiers (UUIDs) for entity keys specify the relationship between the nodes
(all operator nodes in the cloud).
When we introduce additional species of UDDI, all which are private
nodes that do not collaborate using the replication agreement, we must
clarify how information can be shared between private nodes.
Additional UDDI functionality
This article proposes an additional set of functions based on the standard
UDDI APIs that address the management of collaborations among private UDDI
nodes, and between private UDDI nodes and the UDDI Business Registry.
Consider the following scenario involving private UDDI nodes, and the
issue of publishing and subscribing service data between them. The URL
for acme.com's html Web presence is www.acme.com. The transactional
Web presence (that is, www.acme.com/uddi) is a URL to a UDDI API-compliant
private node (that is, a portal UDDI). This portal UDDI contains the Web services
metadata from acme.com.
The collection of remotely hosted UDDI entries should be easy to accumulate
and manage via a nice interface. Also, the target UDDI node should be kept
in sync with the original source of the data (for example, an e-marketplace UDDI,
the UDDI cloud or the partners' transactional Web presence UDDI node).
It should be possible to move entries back and forth from private nodes
to the operator cloud, making it easy for the developer to verify that
the entry is accurate before it is published to the cloud or other UDDI
nodes.
Here is a set of functions that help to solve these problems. Some of
these functions will make excellent candidates for version 3.0 of the UDDI
API specification:
Management of UUID assignment
- UDDI is very particular about how entity keys (UUIDs) are assigned.
Operator nodes assign keys, not the business that makes the registration.
This affects how the
save_XXXX APIs work. A save_businessEntity
operation, for example, uses the value in the businessKey as a switch
to decide whether the save is a new entry (when businessKey is empty)
or an update to an existing entity (when businessKey has a UUID).
So entries from private UDDI nodes new to the operator cloud must be presented
to the operator node with an empty key. The UDDI operator node itself must
assign the value of the key.
In order to encourage the use of private nodes, we must provide a facility
for users to create UDDI entries in private nodes (for example, portal nodes, e-marketplace
nodes, etc.). Subsequently, we must publish these entries to the UDDI operator
cloud. Support, in this case, involves negotiating the assignment of UUID
keys. If the private node originally creates the entry, the private node
will assign the key. If the entry is subsequently published to an operator
node, either the key must be removed from the entry before publishing to
allow the operator to assign UUID values to these keys, or the operator
node must approve the UUID assignment algorithm used by the private UDDI
node.
Facilitate copy-and-paste between nodes
- It must be easy to select an entry from a private or operator UDDI
node and copy the entry into a target UDDI node. For example, partner.com
has an entry for an important Web service in its portal UDDI node. Acme.com
can use this copy-and-paste facility to select this entry (perhaps through
a simple browse facility built on top of UDDI4J). By the click of a button,
acme.com can copy that entry into a target UDDI node (for example, acme.com's partner-catalog
UDDI node).
Subscribe-for changes to existing entries
- This function is related to the copy-and-paste operations described
above. For any change to the copied entry results, a notification is sent
to the target specified in the subscription. The target is a Web service
invoked when the notification is generated. The user specifies the implementation
of the notification-handler Web service that may ignore all notifications,
delete or update the entry in a target private UDDI node, or even post
the change to a separate node for examination.
Subscribe-to pattern
- The requestor doing a
find operation against a UDDI node asks
to be notified of any new entry matching a specified pattern. This function
can, for example, set up a subscription service within an e-marketplace
UDDI node. FlowerWholesalers.com sets up a wholesale e-marketplace
catering to flower retailers. Participants in this e-marketplace place
subscriptions against the UDDI node. The combination of property values
(that is, taxonomy) and service tModel use forms a pattern against which each
publish
operation is compared. When the pattern matches, the notification-handler
Web service is sent a notification specified by the subscription.
Caching and delegation
- A caching and delegation model provides an alternative to the copy-paste-subscribe
mechanism to populate a private UDDI node and keep it in sync with collaborating
UDDI nodes. The user still selects a UDDI entry (or pattern). But instead
of duplicating the entry from the original UDDI node to the target UDDI
node, an indirection is set up. This indirection acts like a real UDDI
entry. However, when found, it goes back to the original source UDDI node
to retrieve details. For example, acme.com might not keep the complete
businessEntity entries for its partners. Rather, it uses the indirection
mechanism to satisfy the
find_business, and redirects follow-up
get_business
requests through to the UDDI instance that is the original location of
the businessEntity entry.
In this way, the administrator of the UDDI node can choose which entries
should be cached (for example, copy/paste and subscribe) and which entries should
be redirected.
Conclusion
The deployment of private UDDI registries presents
additional opportunities for Web services discovery and integration beyond
the those provided by the UDDI Business Registry. In order to encourage
the adoption of private UDDI registries, the UDDI API needs to be
extended to support federating multiple UDDI registries.
Resources
About the author | 
| |
Steve Graham is an architect in the Emerging Technologies division of IBM Software Group. He has spent the last several years working on service-oriented architectures, most recently as part of the IBM Web Services Initiative. Prior to this, Steve worked as a technologist and consultant working with various emerging technologies such as Java and XML, and before that he was an architect and consultant with the IBM Smalltalk consulting organization. Before joining IBM, Steve was a developer with Sybase, a consultant, and a faculty member in the Department of Computer Science at the University of Waterloo. Steve holds a BMath and MMAth in computer science from The University of Waterloo.You can reach him at sggraham@us.ibm.com. |
Rate this page
| |
