Industrial IoT Authors: Pat Romanski, William Schmarzo, Elizabeth White, Stackify Blog, Yeshim Deniz

Related Topics: Industrial IoT

Industrial IoT: Article

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.

    IoT & Smart Cities Stories
    The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
    There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
    Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
    BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
    DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...