Private UDDI Registries
| In this section, we talk about implementations of the UDDI specification outside the context of the UDDI Business Registry. We use the term private UDDI This section is based on a series of articles published on the IBM developerWorks Web site (http://www.ibm.com/developerWorks) titled "Role of Private UDDI." Why Would a Company Host a Private UDDI Registry?There are several reasons a company would want to host a private UDDI registry. To address this question, we need to look at why a company would use a UDDI registry at all, and then examine the circumstances that would encourage them to choose private UDDI registries. In the beginning of this chapter, we discussed the role of a service discovery in a service-oriented architecture (see "The Role of Service Discovery"). The central idea was to provide a mechanism by which a service provider can communicate the Web service description to service requestors. A service registry, based on UDDI, is one important mechanism to publish and search for service descriptions. 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 will choose to advertise all of their Web services descriptions in the UDDI Business Registry. These companies will also use the UDDI Business 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. Being advertised in the UDDI Business Registry maximizes the visibility of the business and the services it makes available to potential business partners . The UDDI Business Registry is not 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, and reliability of the content of the registry. As we discuss later, choosing to host a private UDDI registry does not preclude also using the UDDI Business Registry. Far from it, many organizations coordinate the 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. Some organizations want to restrict who is allowed to view sensitive service description information and the network address at which their Web services are accessible. For this reason, many organizations choose to 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 it controls its 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 will use a private UDDI registry to control the visibility of service description information. Some organizations are simply not comfortable with having this information managed by some other organization, including an open consortium such as UDDI.org. For Web services with network location that changes with some frequency, direct control over changes to the service description entries in UDDI is necessary. Many organizations will choose to 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 is the partner) and how the service is described (use of service interface definition standards). We illustrate an example of how private UDDI registries support dynamic find in the "Putting It All Together: WSDL-based UDDI and Dynamic Find section of this chapter. The UDDI Business Registry contains business and service information about companies from a broad range of industries. Very 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 NAICS taxonomy, for example), not all of these businesses are desired partners. Worse, there is no guarantee that a company classified in a particular way does, in fact, do business in that industry. Some organizations will 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 UDDI entries for those partners are removed. The flexibility provided by UDDI to register services regardless of how they are described is both a benefit and drawback for users. Many organizations, such as SkatesTown, have standardized on WSDL as the mechanism for IDL-level service description. These companies have adopted tooling to enable their applications to bind to Web services described using WSDL. Web services registered in UDDI that use some other service description technique, such as an ASCII text document, are not useful to these applications. Organizations that have standardized on a common service description mechanism, such as WSDL, will use a private UDDI to make sure that the entries in their service registry also use WSDL as the mechanism of service description. We discuss the convention for using UDDI to register Web services using WSDL in a later section, "Using WSDL with UDDI." Further, most organizations have enabled their applications to consume Web services of a given type. If a Web service is not based on one of a pre-selected set of Web service types, then it is not useful to the business's applications and, therefore, should not be registered in their private UDDI registry. A private UDDI registry, therefore, 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 search pattern describes desired Web service type and other characteristics, such as non-functional requirements such specific to the business policy. The Web services discovered by this search criteria will fit the business need of the application, be in a format that is directly consumable by the application, and 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 to the characteristic of loosely coupled application integration, either within an organization or between business partners. Let's take a look at five types of private UDDI node and examine how SkatesTown, WeMakeIt Inc., and e-Torus use them. Five Types of Private UDDIThe 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 might 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. There are five broad categories of private UDDI use, summarized here and described in more detail in the following sections:
E-Marketplace UDDIThis 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-Torus 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 narrow range of related industries. Further, the membership process allows the entries in this UDDI 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. The e-Torus organization provides a mechanism for registration at its Web site. Each user from each participating member organization must register with the e-Torus Web site to receive an authentication token. This registration and the corresponding authentication token is associated with the e-Torus business registry example of identifierBag s discussed in "More on Classification and Categorization." This authentication token can be stored as a cookie on a Web browser. The authentication 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-Torus's private e-marketplace UDDI. This authentication token allows e-Torus to track which members are doing publish and find operations, and support a small subscription fee for 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 target-rich environment for finding Web services metadata for doing business within a particular e-marketplace or industry. The e-marketplace hosted by e-Torus is clearly the place to be seen in the small wheel and bearing world. The e-marketplace UDDI is also the logical place to find industry-specific custom taxonomies (standard product coding hierarchies, specializations of NAICS categories, etc.) as well as standard Web service interface definition tModel s for common business processes in the industry. As detailed in the section "Using WSDL With UDDI," e-Torus hosts a set of standard tModel s for Web services used in this e-marketplace. This set of tModel s includes standards for synchronous priceCheck (based on work donated to e-Torus by SkatesTown), formal asynchronous RFQ, and purchase order placement. These standard Web service types are all based on a common orders suite WSDL document managed by e-Torus. This type of private UDDI allows an e-marketplace organization to provide value-add to Web services advertisement and searching, such as: providing Quality of Service (QoS) monitoring on the partner's Web services response times, doing better business bureaustyle industry self monitoring of business practices of its member's Web services, and so on. An e-marketplace type of private UDDI registry is where finds in serious machine-to-machine B2B can happen. Because e-Torus monitors the participants in the e-marketplace, SkatesTown can trust that the entries in the e-Torus UDDI registry are all legitimate suppliers. As we detail in the section "Using WSDL with UDDI," SkatesTown can do a find against the e-Torus e-marketplace UDDI node to discover all the suppliers of nylon wheels for skateboards as part of the dynamic bind implementation of the priceCheck feature of its reorder application. The e-Torus organization is considering a value-add feature that sorts the result set of a particular kind of find operation for RFQ service, by price value returned by invoking the business's priceCheck Web service. Portal UDDIWeb services technology is defining the standard way to use the Internet for machine-to-machine B2B. This use of the Internet can be contrasted with the current browser-based or HTML-based World Wide Web by calling it the semantic Web or the transactional Web. (See Chapter 9, "Future Concepts.") Just as a company has a Web presence on the browser-based World Wide Web (http://www.WeMakeIt.com), so too might it have presence on the semantic web (such as http://www.WeMakeIt.com/services/uddi/servlet/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 (DMZ), part of WeMakeIt Inc.'s edge of the network architecture. 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 interests to keep the find APIs available from the Internet; however, WeMakeIt Inc. does not 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 its private Portal UDDI 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 to 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 here: <businessEntity authorizedName="..." businessKey="DCD2B450-A4C0-11D5-AF98-BD95162D3AC9" ...> <discoveryURLs> <discoveryURL useType="businessEntity"> http://www.someoperator.com/uddiget?businessKey=EF433600... </discoveryURL> <discoveryURL useType="urn:uddi-inquiry-api"> http://www.WeMakeIt.com/services/uddi/servlet/uddi </discoveryURL> </discoveryURLs> <name>WeMakeIt Inc.</name> ... </businessEntity> 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 free to tailor the response to find and get operations based on some property associated with the requestor (such as gold member status). 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 UDDIThis type of private UDDI node sits behind the firewall. It provides a very 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 with which it has formal business relationships. In most cases, neither the publish nor 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. The use of this mechanism 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. This style of programming is described in a later section, "Putting It All Together: WSDL-Based UDDI and Dynamic Find." Because the partner catalog UDDI registry contains only approved business partners, this style of dynamic binding does not imply the risk of dealing with an unknown service provider. No matter which Web service is returned by the find operation, we know it is 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 does not lock them into any particular supplier. The management at WeMakeIt Inc. agrees to do business with some supplier. Joanna Pravard examines the UDDI entries for that partner (either from the UDDI Business Registry, an e-marketplace UDDI like e-Torus, 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 are negotiated. The set of suppliers change 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. Proxies are generated from WSDL service interface definitions by WeMakeIt Inc.'s developers. WeMakeIt Inc.'s applications are coded to use these proxies and to do finds against its partner catalog private UDDI registry. 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 set of available Web services and chooses one or more of the best Web services from this set to invoke. This choice is based upon WeMakeIt Inc.'s business policies, such as choosing the best price, best delivery terms, and so on. The Web service of the supplier is then invoked by the application and business is done. To make this dynamic binding application support complete, Joanna Pravard places restrictions on 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. Joanna makes sure that each businessService follows the standard convention for publishing WSDL using UDDI (see "Using WSDL with UDDI"). And further, Joanna makes sure that each tModel referenced by these businessServices is from a set of approved, standard tModel s 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 UDDIThe Internal Enterprise Application Integration (EAI) type of UDDI registry is similar to the partner catalog type, except 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 that separates the Internal EAI type of private UDDI from the partner catalog type is the potential for common administrative domain that can dictate standards (which tModel s are used, common use of WSDL portTypes , and so on). This allows the Internal EAI type of UDDI registry to operate with different publish restrictions than those suggested for the partner catalog type. For example, the Internal EAI UDDI registry could restrict the publication of new tModel s and thereby restrict publishing of businessService entries and bindingTemplate entries to accept only entries associated with a fixed set of tModel s. The fixed set of tModel s corresponds 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 UDDIProgrammers 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 test that the UDDI entries describing its purchase order placement Web service were 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 test its applications' ability to cope with external services. For example, Joanna Pravard uses a test UDDI to make sure that different variants 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 from the UDDI Business Registry, any e-marketplace such as e-Torus' e-marketplace private UDDI, or a supplier's private portal UDDI. Joanna copies a UDDI entry from the source UDDI registry to the test UDDI first, then runs a battery of tests to make sure WeMakeIt Inc.'s applications can use the information found in the entry and then, only after testing, she promotes the entry to the WeMakeIt Inc.'s partner catalog UDDI. The notion of promote is used here to describe copying a UDDI entry from one UDDI registry to another. A UDDI entry can be promoted from one registry to another using a variety of techniques including: manual re-publication of the UDDI entry (destroying the correspondence between the UUID keys of each entry), or using a modified API that allows a record to be created in a UDDI repository with UUID keys already assigned. Techniques to facilitate promotion are being considered as part of the UDDI Version 3.0 specification.  |
to refer to these UDDI registries that are not operator nodes within the UDDI Business Registry. Many organizations host their own, private implementations of UDDI for various reasons. We will examine several categories of private UDDI and discuss how SkatesTown, WeMakeIt Inc., and e-Torus use private UDDI registries. 
EAN: N/A
Pages: 130