The role of private UDDI nodes in Web services, Part 1: Six species of UDDI

Transcription

1 developerworks > SOA and Web services > Technical library The role of private UDDI nodes in Web services, Part 1: Six species of UDDI Steve Graham [ Web Services Architect, IBM Emerging Internet Technologies Date: 01 May 2001 Level: Introductory Activity: 3820 views Summary: Steve Graham introduces the concepts behind Web services discovery and gives a brief overview of UDDI (Universal Description Discovery and Integration). He examines six variants of UDDI registries, highlighting the role each of these plays in a serviceoriented architecture. In service-oriented architectures, service descriptions and metadata play a central role in maintaining a loose coupling between service requestors and service providers. The service description, published by the service provider, allows service requestors to bind to the service provider. The service requestor obtains service descriptions through a variety of techniques, from the simple " me the service description" approach and the ever popular sneaker-net approach, to techniques such as Microsoft's DISCO and sophisticated service registries like the Universal Description, Discovery and Integration (UDDI), which is what I am going to examine here. UDDI UDDI defines four basic data elements within the data model in version 1.0: businessentity (modeling business information), businessservice (high level service description), tmodel (modeling a technology type or service type), and bindingtemplate (mapping between businessservice and tmodels). I won't discuss the intricacies behind these elements, so if you need more basic information on UDDI, please visit the UDDI web site before continuing (see Resources). The set of operator nodes known as the UDDI business registry, or UDDI operator cloud, implies a particular programming model characterized by design-time service discovery. We need design-time discovery since it is often not feasible to implement dynamic discovery at runtime due to overwhelming complexity. However, the just-in-time integration value proposition of the IBM Web Services Initiative allows organizations to provide dynamic discovery and binding of Web services at run time. To do this,

2 API characteristics and other non-functional requirements are specified as business policies at design time. This flexibility has important characteristics for loosely-coupled enterprise application integration, both within and between organizations. The role of the UDDI cloud to support a dynamic style of Web services binding is currently limited. However, the UDDI API and data model standard can still play a role in a serviceoriented architecture. The notion of a private or non-operator UDDI node is critical to the emergence of a dynamic style of a service-oriented architecture. Six species of UDDI UDDI is really two things: 1. the UDDI cloud of operator nodes, an Internet-wide repository (made up of white, yellow, and green pages) for Web services metadata; and 2. an API and data model standard for a Web services metadata repository. The former hosts the data while the latter provides a means to access it. Currently, the most important form of UDDI is the UDDI operator cloud. The UDDI operator cloud is a collection of UDDI nodes coordinated by an operator's agreement to provide uniform access to Web services metadata from any of the operator nodes. If Web services metadata is entered in one operator node, it can, with some reasonable time delay, be retrieved from any of the other operator nodes. The operator nodes share the data using a well defined replication scheme. The structure of the UDDI specification allows the possibility of private UDDI nodes. A private UDDI node can implement all of the UDDI APIs as defined by the UDDI v1.0 specification, but it does not participate in the replication scheme defined by the UDDI operator's agreement. I have identified six variants, or what I call species, of UDDI: 1. UDDI Operator node 2. e-marketplace UDDI 3. Portal UDDI 4. Partner catalog UDDI (also known as Vetted partners or rolodex-like UDDI) 5. Internal Enterprise Application Integration UDDI 6. Test Bed UDDI. All but the first species, UDDI operator node, are considered private or non-operator nodes. Because of the data volumes, the breadth of industry, geography, products covered, and the requirement of adherence to the operator agreement, operator nodes are limited in the degree of additional or variant behavior they can provide. Private nodes are not under the same restrictions. I will now briefly discuss each type of UDDI node. The UDDI operator

3 This is what most folks think of when they consider UDDI. These UDDI nodes form the operator cloud facility that can be accessed from (see Resources). The prime example of this is the UDDI Business registry currently replicated between IBM, Microsoft, and soon HP (see Resources). Ariba, formerly an operator, has just announced that it is shifting to the role of a registrar of Web services. The e-marketplace UDDI This private UDDI node is hosted by an e-marketplace, a standards body, or a consortium of organizations that participate and compete in the industry. In this UDDI node, all the Inquiry APIs (that is, publish and find) are deployed for access over the Internet by any of the member organizations. The entries in this species of UDDI relate to a particular industry or narrow range of related industries. Such a membership process allows the entries to be pre-filtered to include only legitimate businesses participating in the industry. The membership process can also restrict who is allowed to invoke find operations against the UDDI node. For example, the steel manufacturer's association may choose to host a UDDI node, allowing its members to register their business and Web services. An e-marketplace UDDI is a target-rich environment for finding Web services metadata for doing business within a particular e-marketplace or industry. The e-marketplace UDDI would be the logical place to find industry-specific custom taxonomies (standard product coding hierarchies, specializations of North American Industry Classification System [NAICS] categories, and so on) as well as standard Web service interface definitions (tmodels) for common business processes in the industry. For example, vendors would be able to determine which types of purchase order placements are typically made in the steel industry by examining the tmodels that are contained in the e-marketplace's UDDI. As industries agree on standard Web services interface definitions, Web services adoption will accelerate. This style of private UDDI node allows an e-marketplace to provide value-adds like quality of service monitoring on the partner's Web services response times and Better Business Bureau style industry self-monitoring of its members' Web services business practices. Finds in serious machine-to-machine (M2M) B2B will happen in the e-marketplace UDDI node. A buyer may issue a find against an e-marketplace UDDI node in preparation for the issuing of a request for quotes (RFQ) to various suppliers within an industry. A simple find against this UDDI node reveals all the suppliers able to receive a RFQ via a Web service invocation. These e- marketplaces will want to move into the Web services arena to avoid being dis-intermediated by the UDDI operator cloud. The portal UDDI The transactional Web refers to use of the Internet for M2M B2B. Just as a company has a Web presence on the eyeball Web ( so too will it have presence on the

4 transactional Web ( I call this transactional Web presence a portal UDDI. The portal UDDI typically sits on the company's firewall in its demilitarized zone and is a private node that contains only metadata related to that company's Web services. So the entries in reflect the metadata for Web services that acme.com wishes to provide to external partners. Clearly it is in the company's interests to keep the find APIs accessible from the Internet, although the publish APIs will be removed, restricting publish to internal processes only. When acme.com wants to deploy a Web service, it publishes the Web service description to its portal UDDI. Other facilities, described in the next installment of this article, are then automatically invoked to make sure the new Web services metadata is properly reflected in other UDDI nodes, such as the operator cloud, various e-marketplaces, and key partners catalogs. The portal UDDI gives a company ultimate control over how metadata describing its Web services is used. For example, a company can restrict find access. It can also monitor and manage the number of lookups being made against its data and potentially get information about who the interested parties are. With respect to the UDDI operator cloud, the URL for acme.com's transactional Web presence UDDI node can be used as the discoveryurl in the businessentity record for acme.com. The partner catalog UDDI This private UDDI node sits behind the firewall and finds and binds are made against it. It also only contains Web service description metadata published by trusted business partners (that is, those organizations with which acme.com has formal agreements/relationships). The publish and find APIs are not available over the Internet, so only internal applications have access to all APIs. The partner catalog allows an organization to build applications in a service-oriented way, taking advantage of dynamic binding against Web services through a Eeb services interface established at design-time. The API to the Web service, as embodied by the Web services interface definition (for example, a conventional use of WSDL using a tmodel), is fixed at design-time. But other characteristics, such as transport, security stack, and so on can be dynamically accommodated at run-time. Applications are coded to accept any Web service that matches a find executed against this UDDI. Because the UDDI node contains only approved business partners, this dynamic binding does not raise the risk of dealing with an unknown service provider. Consider the following scenario. Buyer.com wants to do M2M e-business using Web services techniques in order to reduce transaction costs for supply-chain tasks, such as supplyreordering, but they don't want to be locked into dealing with a particular vendor. The management at Buyer.com agrees to do business with acme.com. Buyer.com's IT staff can examine the UDDI entries for acme.com (either from the operator cloud, an e-marketplace

5 UDDI, or acme.com's portal UDDI) and copy these entries into its own Web services partner catalog UDDI. Buyer.com repeats this process for all vendors it wishes to contract with. Now as the list of suppliers changes over time as business relationships are formed and dissolved, the changes in the entries within Buyer.com's partner catalog UDDI node will be updated. Proxies can be generated from WSDL standards and applications written to carry out finds against the partner catalog UDDI node. The applications do not need to be recoded to cope with the changing list of approved partners. The application uses the UDDI entries to determine the Web services available, it chooses one or more of the best Web services to invoke, based on a given business policy, and then it invokes the Web service. To make this dynamic binding application support complete, the partner catalog UDDI node can restrict the publish function to allow only entries under a certain criteria (for example, only businessservices associated with a WSDL based tmodel or only businessservices which support a well-known industry standard purchase order tmodel). This allows the administrator to guarantee the shape of entries that are placed within the UDDI node and, therefore, what applications can expect in response to find operations. The partner catalog UDDI node also supports value-added services like find businessservice based on tmodel key, or find businessservice based on WSDL type, regardless of the business that supports it. These additional APIs support the scenarios described above. The internal enterprise application integration UDDI This resembles the partner catalog species, except that the entries are for Web services provided by other departments or groups within an organization. The major distinction of this species is the potential for common administrative domain that can dictate standards (for example, the tmodels used, common use of WSDL porttypes, and so on). This allows the UDDI node to operate with different publish restrictions than those suggested for the partner catalog UDDI. For example, the node could restrict the publication of new tmodels and thereby restrict publishing of businessservices and bindingtemplates to accept only entries associated with a fixed set of tmodels. The fixed set of tmodels corresponds to the technology standards chosen by the common administrative domain. Of course, this species exists completely hidden behind an organization's firewall. Publish and find operations would be restricted to applications within an organization. The test bed UDDI This type of private UDDI node tests applications. The testing can be for both requestor applications and provider Web services. If acme.com provides Web service access to their purchase-order placement-system, acme.com uses this type of UDDI node to make sure of two things: 1. that the UDDI entries for

6 their Web service are accurate and 2. that applications can use the Web service information to generate proxies from the UDDI entry to access the Web service. If acme.com builds applications to consume Web services, it tests the application's ability to cope with different variants of Web service description with entries from the test bed UDDI. Acme.com will clearly want to run some trials against any new UDDI entry discovered in the operator cloud, or an e-marketplace UDDI or partner's transactional Web presence UDDI. Entries will typically be copied here first. A battery of tests are then run to make sure the application can use the information found in the entry. And then, only after testing, the entry will be promoted to the vetted partner's UDDI, or the enterprise application integration UDDI node. Conclusion We have briefly examined the discovery role played by UDDI within a service-oriented architecture and enumerated six species of UDDI, each supporting different uses of a serviceoriented architecture. In the next installment of this article, I will contrast the programming models that use private and operator UDDI nodes, and review requirements for functionality to make private UDDI nodes easier to use. Resources Check out part two of this series [ Check out the official UDDI site [ Check out this UDDI Browser [ An open-source Java-based implementation of UDDI is available for review [ Take a look at the UDDI4j project hosted on developerworks Read the XML cover pages [ Take a look at the Microsoft UDDI pages [ 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

7 MMAth in computer science from The University of Waterloo.You can reach him at

8 The role of private UDDI nodes, Part 2 : Private nodes and operator nodes Steve Graham (sggraham@us.ibm.com) Web Services Architect, IBM Emerging Internet Technologies 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.

9 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 targetrich environment will have significant impact on the programming model for requestorapplications 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 operatoragreement, 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

10 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 The transactional Web presence (that is, 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

11 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 Participate in the discussion forum on this article by clicking Discuss at the top or bottom of the article. Read the first installment of this series. Learn more about RosettaNet's [ b2b specifications. Target-rich environments are described in detail here [

12 Check out the official UDDI site [ Take a look at the collection of UDDI resources [ Go to the IBM UDDI registry [ Check out this UDDI Browser [ An open source Java-based implementation of UDDI is available. Take a look at the uddi4j project hosted on developerworks. Find out about the UDDI day that happened at the XML DevCon. Read the XML cover pages on UDDI. Take a look at the Microsoft UDDI pages. 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.

13