Simeon Simeonov

Subscribe to Simeon Simeonov: eMailAlertsEmail Alerts
Get Simeon Simeonov via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Private UDDI Registries

Private UDDI Registries

This article is based on the UDDI chapter in Building Web Services, to be released this month. It appears here in slightly different form by permission of the publisher, Sams. Contributors to the book are Doug Davis, Steve Graham, Yuichi Nakamura, and Ryo Neyama from IBM; Toufic Boubez from Saffron Technology; and Glen Daniels from Macromedia.

The last issue of XML in Transit focused on the categorization and classification capabilities of UDDI. This month we look at the means for customizing the power and flexibility of UDDI for your business through the use of private UDDI registries. Why would a company host a private UDDI registry?

UDDI provides a standard message API to publish and find service descriptions from a repository. This standard is supported and used by many organizations; there are multiple UDDI registry implementations to choose from. Some organizations advertise all of their Web services descriptions in the UDDI Business Registry. These companies also use the registry to search for any business partner's Web service descriptions.

The UDDI Business Registry is in a well-known location (www.uddi.org) and therefore highly visible on the Web. Everyone in the Web services community knows about UDDI, and knows how to use the UDDI Business Registry for find and publish. Advertising in the registry maximizes the visibility of a business and the services it makes available to potential business partners.

The UDDI Business Registry isn't the only place to register business and service descriptions in a UDDI format. Many organizations are choosing to host their own private UDDI registries. These companies make this choice for several reasons:

  • Control of access to the information
  • Control over updating the information
  • Reliability of the content of the registry

    Hosting a private UDDI registry doesn't preclude using the UDDI Business Registry. Far from it. Many organizations coordinate use of their private UDDI registries with occasional access to the UDDI Business Registry.

    The broad visibility of the UDDI Business Registry has a downside for some organizations that want to restrict who is allowed to view sensitive service description information and the network address that accesses their Web services. For this reason many organizations advertise just their company in the UDDI Business Registry; the only Web service they advertise is the UDDI Inquiry API Web service to one of their private UDDI registries. In this way potential partners who are interested in learning more about a business's Web services capabilities are encouraged to contact the business's private UDDI registry. The business hosting the private UDDI gains control over access to Web services information through a registration and authentication scheme. Because they control their private UDDI registry, access can be tracked and monitored, and, if necessary, follow-up can be initiated with a potential partner showing interest in the business by executing a find operation.

    Some organizations use a private UDDI registry to control the visibility of service description information. Some organizations simply aren't comfortable with having this information managed by another organization, including an open consortium such as UDDI.org.

    For Web services with a network location that changes with some frequency, direct control over changes to the service description entries in UDDI is necessary.

    Many organizations host a private UDDI to ensure consistency of service description information to support runtime discovery of Web services. This consistency is at the business level (who the partner is) and determines how the service is described (use of service interface definition standards).

    The UDDI Business Registry contains business and service information about companies from a broad range of industries. Few of these entries are of interest to any given businessperson searching for a particular partner or Web service implementation. For those businesses categorized within a particular industry (using the North American Industry Classification System taxonomy, for example), not all of these businesses are desired partners. Worse, there's no guarantee that a company categorized in a particular way does in fact do business in that industry. Some organizations use a private UDDI to ensure that only services from approved business partners appear in the services registry. As new partners are approved, their UDDI entries are added to the private UDDI registry. As business relationships dissolve, the entries for those partners are removed.

    The flexibility provided by UDDI to register services regardless of how they're described is both a benefit and drawback for users. For example, most organizations have enabled their applications to consume Web services of a given type. If a Web service isn't based on one of a preselected set of Web service types, then it isn't useful to the business's applications and therefore shouldn't be registered in their private UDDI registry.

    A private UDDI registry thus offers a target-rich environment so that an application, at runtime, can do a find against the registry. A business policy, defined by human developers at design time, is used as the search pattern in the find operation. The pattern describes the desired Web service type and other characteristics, such as nonfunctional requirements specific to the business policy. The Web services discovered by these search criteria will fit the business need of the application, be in a format that is directly consumable by the application, and will be hosted by a known and approved business partner.

    Supporting dynamic runtime discovery and binding to Web services at runtime is one of the key points of flexibility in a service-oriented architecture. This flexibility is important for loosely coupled application integration, either within an organization or between business partners.

    Let's examine five types of private UDDI nodes and how businesses might use them. For example purposes I'll use three fictitious companies: SkatesTown (a skateboard manufacturer), e-Taurus (a small wheels and bearings e-marketplace), and WeMakeIt Inc. (a participating company in the e-Taurus marketplace).

    Five Types of Private UDDI
    The UDDI specification was defined to allow the possibility of private UDDI registries. A private UDDI registry can implement some or all of the UDDI APIs. A private UDDI is certainly not bound to any restrictions articulated by the UDDI operator's agreement, and in particular does not participate in the replication mechanism within the UDDI Business Registry. A private UDDI registry may alter the behavior of the common UDDI operations, for example, requiring an authentication SOAP:header on the find operations. A private UDDI registry can offer additional APIs over and above those defined by the UDDI specification.

    The five broad categories of private UDDI use summarized here are described in detail below:

    1. E-marketplace UDDI
    2. Portal UDDI
    3. Partner catalog UDDI (also known as
      Vetted partners or Rolodex-like UDDI)
    4. Internal Enterprise Application Integration UDDI
    5. Test Bed UDDI
    E-Marketplace UDDI
    This type of private UDDI node would be hosted by an e-marketplace, an industry standards organization, or some other consortium of organizations that compete/participate in an industry. All publish and find (inquiry) APIs are typically deployed for Internet access.

    The e-Taurus organization hosts an e-marketplace private UDDI on its Web site. All buyers and sellers of small wheels, nylon, steel and aluminum, and related components, such as wheel bearings, come to this site and use this private UDDI registry.

    The entries in the e-marketplace type of private UDDI are all related to businesses within a particular industry or a narrow range of related industries. Further, the membership process allows entries in this UDDI to be prefiltered 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. Private e-marketplace UDDIs can implement custom taxonomies and the associated validation processes as discussed in the previous XML in Transit (XML-J, Vol. 2, issue 11).

    The e-Taurus organization provides a mechanism for registration at its Web site. Each user from each participating member organization must register to receive an authentication token. The token must be included as a SOAP:header on any find operation and is required by the UDDI API specification to be part of any publish operation issued against e-Taurus's private e-marketplace UDDI. The token allows e-Taurus to track which members are doing publish and find operations and support a small subscription fee based on the size and number of publish operations done by each company as well as the number of find operations and the size of the result sets.

    An e-marketplace UDDI is a rich environment for finding Web services metadata for doing business within a particular e-marketplace or industry. The e-marketplace hosted by e-Taurus is clearly the place to be seen in the small wheel and bearing world. And the e-marketplace UDDI is the logical place to find industry-specific custom taxonomies (standard product coding hierarchies, NAICS categories, etc.) as well as standard Web service interface definition tModels for common business processes in the industry.

    This type of private UDDI allows an e-marketplace organization to provide value-add to Web services advertisement and searching; for example, Quality of Service monitoring on a partner's Web services response times and Better Business Bureau-style industry self-monitoring of business practices of its members' Web services.

    An e-marketplace type of private UDDI registry is where finds in serious B2B applications happen. Because e-Taurus monitors the participants in the e-marketplace, SkatesTown can trust that the entries in the e-Taurus UDDI registry are all legitimate suppliers. Further, e-Taurus can provide value-add features to a UDDI search at the business level. For example, its private UDDI registry can sort the result set of a particular kind of find operation for a Request for Quotes (RFQ) service by price value by automatically checking the RFQ against suppliers' catalogs.

    Portal UDDI
    Web services technology is defining the standard way to use the Internet for B2B applications. This use of the Internet can be contrasted with the current eyeball or HTML-based World Wide Web by calling it the semantic Web or the transactional Web. Just as a company has a Web presence on the eyeball Web (www.WeMakeIt.com), so too might it have a presence on the semantic Web (e.g., www.WeMakeIt.com/services/uddi/). The private UDDI representing the organization's semantic Web presence is called a portal UDDI.

    The portal UDDI hosted by WeMakeIt Inc. resides within the company's demilitarized zone. The entries in WeMakeIt Inc.'s private portal UDDI registry contain descriptions for those Web services that WeMakeIt Inc. wishes to provide to external partners. Clearly it is in the company's interest to keep the find APIs available on the Internet; however, WeMakeIt Inc. doesn't allow access to the publish APIs from the Internet, restricting publish to internal processes only. WeMakeIt Inc. also hosts its product code taxonomy in its private portal UDDI registry. Partners that wish to do business with WeMakeIt Inc. examine that registry to determine what formats the company accepts for purchase orders and the WSDL description of the purchase order placement service, including its network address.

    When WeMakeIt Inc. wants to deploy a new Web service, it publishes the Web service's description in its portal UDDI.

    As part of WeMakeIt Inc.'s businessEntity registration in the UDDI Business Registry, the URL for its private portal UDDI registry is used as a discoveryURL element, with the useType attribute set to urn:uddi-inquiry-api. A segment of WeMakeIt Inc.'s businessEntity entry is shown in Listing 1.

    The portal type of private UDDI registry gives a company ultimate control over how metadata describing its Web services is used. For example, companies are free to restrict find access to the registry. Companies are able to monitor and manage the number of find operations being made against their data and potentially derive information about the interested parties.

    Partner Catalog UDDI
    This type of private UDDI node sits behind the firewall. It too provides a target-rich environment against which Web services finds and binds can be made. A partner catalog UDDI registry contains only Web service description metadata published by trusted business partners. WeMakeIt Inc. has a partner catalog UDDI registry containing entries for those organizations it has formal business relationships with. In most cases neither the publish nor the find APIs to the partner catalog UDDI registry are available over the Internet, restricting access to all APIs to internal applications only.

    Businesses today do business with organizations they know. Use of a partner catalog UDDI registry allows an organization to build applications in a service-oriented way, taking advantage of dynamic binding against Web services at runtime based on a Web service interface built into the application at design time. Because this kind of registry contains only approved business partners, this style of dynamic binding doesn't imply the risk of dealing with an unknown service provider. No matter which Web service is returned by the find operation, we know it's provided by a validated business partner.

    WeMakeIt Inc. uses its partner catalog private UDDI to help in its own supply chain automation systems. Web services technology allows WeMakeIt Inc. to do process integration with their suppliers. Using Web services, WeMakeIt Inc. can reduce transaction costs for supply chain tasks, such as supply reordering, in a way that doesn't lock them into any particular supplier.

    The management at WeMakeIt Inc. agrees to do business with some supplier. Someone on the business development automation team at WeMakeIt - let's call her Joanna Pravard - examines the UDDI entries for that partner (either from the UDDI Business Registry, an e-marketplace UDDI like e-Taurus,or the supplier's portal UDDI. Joanna copies these entries into WeMakeIt Inc.'s partner catalog UDDI.

    This process is repeated for each supplier as new suppliers are found and business terms negotiated. The set of suppliers changes over time as business relationships are formed and dissolved. Changes to this set are reflected by changes in the entries within WeMakeIt Inc.'s partner catalog UDDI registry.

    To make this dynamic binding application support complete, Joanna restricts the kinds of entries that can be published into the partner catalog UDDI registry. Joanna works with each supplier to make sure the supplier's businessServices are properly categorized according to WeMakeIt Inc.'s product code taxonomy. She also makes sure that each tModel referenced by these businessServices is from a set of approved, standard tModels supported by WeMakeIt Inc.'s applications. This allows Joanna to guarantee the shape of entries that are placed within the UDDI node and therefore what applications can expect in response to find operations.

    Internal Enterprise Application Integration UDDI
    The Internal Enterprise Application Integration type of UDDI registry is similar to the partner catalog type except that it contains entries for Web services provided by other departments or groups within an organization. Many organizations treat their partner catalog UDDI and Internal Enterprise Application Integration UDDI as logical views on the same physical registry.

    The major difference between the Internal Enterprise Application Integration type of private UDDI and the partner catalog type is the potential for a common administrative domain that can dictate standards (which tModels are used, common use of WSDL portTypes, etc.). This allows the Internal Enterprise Application Integration type of UDDI registry to operate with different publish restrictions than those suggested for the partner catalog type. For example, it could restrict the publication of new tModels and thereby restrict publishing of businessService entries and bindingTemplate entries to accept only entries associated with a fixed set of tModels. These tModels correspond to the technology standards chosen by the decision makers controlling the common administrative domain.

    Of course, this kind of UDDI registry exists completely hidden behind the organization's firewall. Publish and find operations are restricted to applications within the organization.

    Test UDDI
    Programmers use this type of private UDDI registry to test applications. The testing can be for both requestor applications and provider Web services.

    SkatesTown uses this type of private UDDI registry to ascertain that the UDDI entries describing its purchase order placement Web service are accurate and that UDDI-aware tools can generate proxies from the UDDI entries to access its purchase order placement Web service.

    WeMakeIt Inc. also uses a test UDDI to determine its application's ability to cope with external services. For example, Joanna Pravard uses a test UDDI to make sure that different permutations of the RFQ Web service provided by various suppliers all run correctly with WeMakeIt Inc.'s reorder application. Joanna runs trials against any new UDDI entry discovered in the UDDI Business Registry, or an e-marketplace's private UDDI, or a supplier's private portal UDDI. First she copies a UDDI entry from the source UDDI registry to the test UDDI, then she runs a battery of tests to make sure WeMakeIt Inc.'s applications can use the information found in the entry. Then, only after testing, she promotes the entry to the WeMakeIt Inc.'s partner catalog UDDI.

  • More Stories By Simeon Simeonov

    Simeon Simeonov is CEO of FastIgnite, where he invests in and advises startups. He was chief architect or CTO at companies such as Allaire, Macromedia, Better Advertising and Thing Labs. He blogs at blog.simeonov.com, tweets as @simeons and lives in the Greater Boston area with his wife, son and an adopted dog named Tye.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.