Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

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.

 

RELATED ARTICLES IBM Offers Free Public Cloud Beta For Software Development Zend, Oracle Hook Up for Enterprise-Class Linux and PHP Database Migration Tool Updated Google Maps Navigation Released Amazon Web Services Announces Relational DB Service		TOP 5 ARTICLES No Top Articles.