The Universal Description, Discovery and Integration (UDDI) specification has received much attention as one of the enabling technologies required for Web services. However, few people understand its capabilities beyond the fact that it's used to store and retrieve Web service definitions. A UML model of the UDDI content and message structures provides a quick introduction to their scope of use, without requiring any understanding of other specifications such as XML Schema or SOAP.
The UML model described in this article was produced with an automated reverse-engineering procedure based on the same principles described in the first three articles in this series. In particular, I'll focus on creating a platform-independent model that hides the XML Schema syntax and terminology used in the UDDI specification. These details are retained, however, within the UML profile meta-data contained in the model.
Initial UDDI Schema Model [click for larger image] This UML diagram depicts the initial top-level data structure reverse-engineered from the XML Schema for UDDI 2.0 (www.uddi.org). UML stereotypes on several attributes indicate which are mapped to XML attributes in the schema; the others are mapped to XML child elements. The classes for contacts and businessServices
represent simple XML element containers. |
UDDI Data Structure Model
UDDI provides us with a way to publish and discover information about Web services,
but its content goes beyond the narrow definition of Web services interfaces
to include contextual information about the business entities that offer those
services. One business may offer many services, and a similar or identical service
may be offered by many businesses. Each business entity and service is also
described by industrial classification codes and taxonomies that facilitate
the search through a large repository—the so-called "yellow pages"
in UDDI.
It's also likely that these same capabilities of UDDI will be used to describe Web services deployed within the private boundary of a single business. A lone firm like General Motors or IBM is larger than many extended business collaborations and faces a similar challenge of heterogeneous system integration using Web services.
The UDDI specification documents (see www.uddi.org) describe the data structures of UDDI content and the SOAP messages used to interact with a repository. However, I'll concentrate on the XML Schema document that defines all content and messages for UDDI 2.0.
The "Initial UDDI Schema Model" (at right) graphic depicts a small
subset of the UML class diagram reverse-engineered from the UDDI 2.0 schema.
Each complexType definition from the schema is represented as a
UML class, and the XML attributes and child elements are represented either
as UML attributes (for primitive datatypes) or associations to other classes
(references to other complex types).
The reverse-engineering algorithm can map schema structures into conceptual
modeling structures in UML that would be recognized as good object-oriented
design. Also, many modelers strive for concise, uncluttered diagrams. The UDDI
schema contains several element type definitions like this one for businessServices:
<xsd:element name =
"businessServices">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref =
"businessService"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
This defines an XML element that serves as a container for businessService
elements. The initial class diagram represents this structure directly. However,
it's better represented as an association end-role in UML. The reverse-engineering
algorithm will be enhanced to recognize this pattern, but at this point, I manually
modified the diagram after importing this model into Rational Rose.
UDDI Core Data Structure  [click for larger image] This UML diagram depicts the core data structures that define the content of XML messages sent to and received from a UDDI repository. UML stereotypes for XSD are suppressed to focus attention on the conceptual information model. The container element classes from the initial model were refined into association end-role names in this model, but an equivalent schema is generated from this model. The businessEntity
is the most aggregated structure, but some messages refer directly to substructures
such as businessService or tModel. |
The "UDDI Core Data Structure" diagram depicts the complete model for UDDI content, with the exception of request and response message wrappers used to find, save and delete UDDI content. The simple element containers have been replaced by role names in this diagram.
The definitions of several attribute types are not shown (discoveryURL,
phone, email and so on), but they represent simple
data structures with one or two primitive attributes, and each type extends
the XML Schema built-in datatype for string content. For a more concise view
in the diagram, these types are represented as UML attributes, but could also
be shown as associations (for example, from contact to email).
Even if you don't know the XML Schema language, this diagram can serve as a
map to encourage understanding of the range of possible structures contained
in UDDI. A businessService describes a service that's offered by
one businessEntity and is classified using a categoryBag
containing one or more taxonomy keys. Standard categories include industry type,
product or service type, and geography.
A set of bindingTemplates describes how and where to access this
Web service. The access method is a choice of either an accessPoint
(for example, a URL) or a hostingRedirector (an indirect reference
to another bindingTemplate).
Next, you must define how to use this Web service. A set of tModelInstanceInfo
objects contains reference to specifications that provide technical details
about the service. The tModelKey attribute points to a tModel
object instance, which in turn references an overviewDoc object
that contains a specification URL.
A tModel service type definition is used to describe compliance
with a specification, a concept or a shared design. Web Services Definition
Language (WSDL) is the dominant approach used to describe current Web services.
The overviewDoc URL points to a document containing a WSDL service
interface definition—a separate XML document defined by its own schema. A complex
business-service definition in UDDI refers to several tModels.
One of these might be a process flow definition that describes the orchestration
of several Web service calls required to fulfill the overall service goal.
UDDI Message Model
These UDDI data structures are only half the story. The UDDI interface is itself
described as a set of Web services used to publish and discover services contained
in the repository. The single UDDI schema contains a long list of service messages
that use the core data structures as their content. And, because these messages
are each defined in an XML Schema document, we can apply the same reverse-engineering
approach to create a UML model of the message structures.
UDDI Messages  [click for larger image] The UDDI specification includes many messages for finding or publishing content in a repository. This UML diagram shows the model of two messages used to find and save businessEntity
definitions. A find_business message
instance includes one or more of its associated objects that specify the
search parameters. The message response (not shown here) contains a set
of zero or more references to businessEntity
objects that satisfy those criteria. A save_business
message includes the complete definition of a businessEntity
and all of its child elements. |
The "UDDI Messages" diagram depicts the model produced from two of
these messages: find_business and save_business. The former message is used
to search for a business by various criteria. The latter message is used when
creating a new business entry or updating an existing entry. When saving a business
description, the message content is contained in a businessEntity object as
defined in the core data structures model. As appropriate, businessServices
and bindingTemplates may be included in this entity. A corresponding XML message
instance appears as follows:
<save_business generic="2.0" xmlns="urn:uddi-org:api_v2"> <authInfo><!- token -></authInfo> <businessEntity>...</businessEntity> </save_business>
As part of registering a business, a set of identifiers, categories or discovery
URLs is included. As seen in the "UDDI Messages" diagram, those same
identification objects form the basis for finding a specific business or a set
of businesses in a particular category. If the tModelBag object
is included in a query, the returned business list is restricted to entities
that implement services fulfilling the specified tModels.
Although the UDDI messages are intended to be carried via the SOAP protocol, one of the benefits of abstracting these message definitions in a platform-independent UML model is the ability to discuss and debate the information content separate from its transport. These same messages and data structures could be carried via other, non-SOAP message middleware or even via distributed object facilities such as CORBA—alternative platform-specific deployment architectures for service description and discovery.
XML Vocabularies and Web Services
Platform-independent UML models highlight information content while suppressing
premature attention to implementation considerations. Or, as in the case of
the UDDI schema, a platform-independent model is abstracted from an implementation
specification as a means to explain its purpose and use.
The UDDI model describes a vocabulary for the Web services infrastructure, but the same reverse-engineering techniques may also be applied to application domains such as finance, order management and health care. Indeed, I have reverse-engineered UML models from schemas for the XML Common Business Library (xCBL), the Financial Products Markup Language (FpML) and many other specialized and company-specific schemas.
An interesting tension exists between object-oriented design practices and the service-oriented designs that are the foundation of Web services integration. Many of the first-generation Web services simply create request-response messages based on the operations of existing Java or C++ objects—the operation's parameters become the request message content and the operation's result value is wrapped in an XML response message. However, this often yields a large number of fine-grained messages that may not perform well in distributed systems.
A scalable service interface is similar to the EJB session bean
concept, in which the session interface has a more coarsely grained structure
and the details of low-level operations are hidden within its implementation.
One operation for getProduct() would return an XML document containing
the entire product definition, instead of using separate methods to retrieve
and update the product's name, description and so on. This is analogous to UDDI
messages for querying and saving business entities and service definitions.
The design challenge is also reversed when many Web services interfaces are defined as a long list of independent messages. This is the case with UDDI: The supplementary documentation classifies and explains the message types, but only in human-readable format.
The next steps of my journey into model-based Web services will focus on using session-oriented interfaces to define related service messages; for example, by creating a BusinessEntityManager interface that collects operations for finding, saving and deleting business entities in UDDI.
In spite of the rush to implement them, Web services specifications are still in their formative stages—and best practices for their design are difficult to find. However, I hope that I've convinced you of modeling's value as one of the techniques that will help guide this exciting evolution.
