Connecting Trading Partners and Marketplaces with UDDI

1. The challenges for global trade

In the current environment for (electronic) global trade, businesses are faced with tough challenges:

• Increased competition by existing and new market players cannot be tackled by merely reducing prices. It rather calls for a total cost of ownership reduction and a better partner relationship management.

  As a consequence, you have to integrate your different software applications.

• The need for increased collaboration with business partners necessitates the implementation of mechanisms for collaborative commerce, such as The Efficient Consumer Response movement effectively began in the mid-nineties and was characterized by the emergence of new principles of collaborative management along the supply chain. It was understood that companies could serve consumers better, faster and at less cost by working together with trading partners. (ECR) and The Collaborative Planning, Forecasting and Replenishment Committee is a VICS committee, made up of retailers, manufacturers, and solution providers. This group has developed a set of business processes that entities in a supply chain can use for collaboration on a number of buyer/seller functions, towards overall efficiency in the supply chain. (CPFR).

  As a consequence, you have to integrate your applications with those of your partners.

• The desirable increase in the customer base and the penetration of new markets require good marketing and fewer barriers of international trade.

  As a consequence, you have to make your services available to potential customers and markets. You also have to integrate your applications with the applications your new customers run.

For all these requirements, the extensive use of the Internet seems to be a reasonable approach. The Internet has a global reach. A business without an Internet connection within the next few years seems unimaginable. The Internet has no downtimes. E-commerce 24 hours a day, 7 days a week, is conceivable. The Internet relies on standardized technology. XML, SOAP and HTTP nicely fit together for the exchange of electronic business documents.

However, new partners and customers speak different languages, conduct business differently and offer or request different technical interfaces.

And, firstly,

• How do I find them?

• And how do I find out more about their e-capabilities?

In this paper, we will focus on ways to publish and discover businesses and their Web services in a standardized manner and explain how this enhances inter-enterprise and marketplace integration.

2. A Web Service Architecture

The facilitation of Business to Consumer (B2C) Commerce is a domain for the Yellow Pages. Businesses that provide products or services publish this information publicly (the Yellow Pages) so that consumers can find them based on a given description and/or a specific industry.

This is not sufficient for Business to Business (B2B) Commerce. Since consumers usually search in their geographic region, businesses are also interested in international trade to extend their market reach or use business opportunities from abroad. Therefore, the Yellow Pages from different sources and many countries have to be merged. Assuming that someone is willing to do this tedious work and keeping it up-to-date, there is a further problem. Different Yellow Pages use different languages and different categorization systems. For example, one can imagine that the German "GelbeSeiten"http://www.businessdeutschland.com use different industry categories than the US "YellowPages.com"http://www.yellowpages.com. But with the sheer amount of globally active businesses, we urgently need standardized, or at least comparable, descriptive information and categorization systems.

When two businesses have found one another they have only made the first step. In order to conduct business electronically (B2B E-Commerce) they also need to know about their technical capabilities. This means that information about the business document types, their expected orchestration and the access points to the application systems (that is, where the actual business documents are to be sent to) are required. When applying this idea to the Internet and describing the business documents in XML, we come to a Web Service Architecture (see Figure 1).

Figure 1: Web Service Architecture

A seller (service provider) publishes information about the Web services they offer in a service directory. A buyer (service requester) discovers suitable Web services in the service directory within the seller's published information. Depending on the description of the seller's Web services, the buyer may invoke the Web services by sending a valid XML document to the sellers' access point.

We have now identified the main requirements for a service directory playing a key role in a Web Service Architecture:

• Provide a single point of access to business information that is globally available

• Use of detailed descriptive information and well recognized categorization systems,

• Provision of information about Web services

• Electronic availability based on standardized Internet technology.

3. Universal Description, Discovery and Integration

In this section, we will focus on UDDI and how it tackles the requirements described in the Web Service Architecture above.

3.1. The project

UDDI is an industry initiative http://www.uddi.org to define a foundation component of Web services. The initiative has broad industry support and is a focused effort to ensure rapid development of the UDDI specification. UDDI specifies a mechanism to describe, discover and integrate businesses and Web services.

The UDDI Application Programming Interface (API) specification defines how a business interacts with a UDDI registry for

• Publishing information about the company and its Web services and

• Searching for other businesses and their Web services.

Three public UDDI registries ¹ that fully comply with the specifications are already in use. They serve as service directories where service providers can publish services and service requestors can discover them. Since newly published or updated information is replicated between all public UDDI registries, service requestors can access an arbitrary registry for discovery. Service providers choose a custody registry where they publish and update information. In this way, UDDI serves as a globally-available and virtually-central service directory. The amount of information that is to be replicated is minimized and inconsistencies are prohibited.

3.2. Description

Service providers publish information about their business and services so that service requestors can discover them easily. The published information comprises structures for the service provider's

• Business entity (business name, descriptions, contacts and addresses)

• Business services (service name and descriptions)

• Service bindings (descriptions and access points)

Although this amount of information provides a good description of the service provider and his services, it is not enough for discovery and integration.

Why?

To enable discovery, well-recognized categorization systems that enable service providers to be discovered and compared are required. These categorization systems may include, but are not limited to, classification codes for the industries the publisher represents, the product and service categories that the publisher offers and the region in which the publisher offers their business services.

To enable integration, in addition to the knowledge about the business service's meaning and its access point we also have to know about the service type which is necessary to invoke services at runtime. As we have already seen in section , Web services are invoked by sending an XML document to the service provider's access point, so an XML schema often describes the corresponding service types.

Both the categorization systems and the service types often are defined by organizations specialized in this area, for example, standard bodies or software developers. To enable organizations like these to manage these technical specifications separately, UDDI specifications introduce a structure separate from the business entity, called "tModel" ², to represent all kinds of technical specifications. As a result, service publishers can easily reuse these tModels just by referencing them in the respective structure to describe their services as precisely as necessary.

An overview about the main UDDI data structures and their relationships is given in the UML class diagram Figure 2.

Figure 2: UDDI Data Structure

3.3. Discovery

Service requestors that want to discover information are dependent on the information service providers publish. There are three typical questions:

1. Are there businesses within the category (for example, industry, product category or region) that I am interested in?

   To answer this question, several prerequisites have to be met. Naturally, enough service providers have to publish their information. Also, they have to use well-recognized ID systems and category systems to describe their business. Obviously, it will be hard to discover service providers if they use different category systems, but have a logically similar business. Logically, the ID systems and category systems have to already be published by the managing organizations.

2. Do these businesses offer the services I need?

   Since the description of business services is comprised of text and categories, service requestors will have valuable answers to this question if service providers use meaningful descriptions. As a result, the discovery of services that match the requestor's need cannot usually be carried out automatically.

3. Do these business services have bindings to service types that my system understands so that I can invoke the services technically?

   Assuming that business services are found that correspond to the requirements, there is one more aspect to cover. Service requestors would also like to know if the service provider offers these services in a way that they can directly interact with. Services that are offered by phone, fax or email can be used easily, but Web services that can be invoked by sending an XML document to one of the service providers' Web servers are another level of automation. It is easy to create an XML document but the real challenge is to comply with the XML schema that the service provider expects. As for category systems, service providers would be well advised if they publish service bindings to service types that are well-recognized, that is, represent a widely adopted XML vocabulary.

3.4. Integration

Once a service requestor has discovered useful and usable services, the next logical step is to integrate these services with the requestor's application systems. Coming back to our Web Service Architecture (see the section ), the service requestor now wants to invoke the service the service provider offers. In technical terms, this means that

1. The requestor's application system has to render an XML document from application data

2. The XML document has to be sent over the Internet to the service providers Web server

3. The XML document can be processed successfully by the service provider's application system.

In order to describe the technical requirements for the last point, the service provider has to have published a service binding to a tModel that itself references an XML schema (see the section ). Consequently, the service requestor is responsible for sending valid XML documents (that is, complying with the XML schema). The more XML schemas to which the service provider publishes bindings, the more likely the service requestor's system is able to comply with at least one of them. The cost of ownership for integration depends on the degree to which XML vocabularies gain acceptance. Note that this type of standardization is not the scope of UDDI. UDDI is focused on providing a standard for describing and discovering businesses and services. The definition of XML vocabularies for particular integration scenarios is a task that has already been taken on by many standard bodies and industry consortia. UDDI is more likely to serve as a marketplace of category systems and XML vocabularies as the lack of integration that often exists becomes more visible and the urge for convergence or mappings between XML vocabularies increases even more.

However, there is no guarantee that service invocation can always be performed ad hoc without any prior development of mapping or transformation. Particularly in collaborative e-business, the technical specifications obtained from UDDI, usually have to be extended with service level agreements and other business-related terms and conditions prior to the first invocation of a service. This service negotiation between service requestor and service provider is also not within the scope of UDDI.

Today, service publication and service discovery can already be carried out using a GUI offered by the UDDI registry operators. To streamline the overall integration process from service publication and service discovery to service invocation and to avoid manual disruption, users will also benefit significantly if their systems can directly interact with UDDI registries. Therefore, the UDDI specifications also define APIs for publication and discovery that every UDDI registry operator must offer. Detailed information about the UDDI APIs can be obtained from the Programmers' API Specification [UDDI_API]. In a way, the UDDI APIs represent the essential part of the UDDI standard since they define the contract between UDDI users and operators.

The publishers' API consists of several calls for the publication and management of service providers' information (see table Table 1). Initially, service providers select one UDDI registry operator to host their information. Once chosen, information can only be updated at the registry originally selected. This convention is technically motivated, since it simplifies replication matters between UDDI registries. For security reasons, UDDI registry operators have to support HTTPS and a means of authentication for the publishers' API calls so that service providers' information can be transmitted securely and be authenticated.

Publishers' API

Table 1: Publishers' API

API Message	Description
save_business	Used to register new businessEntity information or update existing businessEntity information. Use this to control the overall information about the entire business.
save_service	Used to register or update complete information about a businessService exposed by a specified businessEntity.
save_binding	Used to register new bindingTemplate information or update existing bindingTemplate information. Use this to control information about technical capabilities exposed by a registered business.
save_tModel	Used to register or update complete information about a tModel.
delete_business	Used to delete registered businessEntity information from the registry.
delete_service	Used to delete an existing businessService from the businessServices collection that is part of a specified businessEntity.
delete_binding	Used to remove an existing bindingTemplate from the bindingTemplates collection that is part of a specified businessService structure.
delete_tModel	Used to delete registered information about a tModel. If there are any references to a tModel when this call is made, the tModel will be marked deleted instead of being physically removed.
get_authToken	Used to request an authentication token from an Operator Site. Authentication tokens are required to use all other API's defined in the publishers API. This function serves as the programs equivalent of a login request.
discard_authToken	Used to inform an Operator Site that a previously provided authentication token is no longer valid.

The inquiry API consists of several calls for the discovery of service providers and their services (see Table 2). Every service requestor, regardless of their industry, size or location can use this API at any of the UDDI registry operators' sites.

Inquiry API

Table 2: Inquiry API

API Message	Description
find_business	Used to discover information about one or more businesses.
find_service	Used to discover specific services within a registered businessEntity.
find_binding	Used to discover specific bindings within a registered businessService.
find_tModel	Used to discover one or more tModel information structures.
get_businessDetail	Used to get the full businessEntity information for one ore more businesses.
get_businessDetailExt	Used to get extended businessEntity information.
get_serviceDetail	Used to get full details for a given set of registered businessService data.
get_bindingDetail	Used to get full bindingTemplate information suitable for making one or more service requests.
get_tModelDetail	Used to get full details for a given set of registered tModel data.

To facilitate the adoption and integration of UDDI APIs in existing and upcoming business applications and marketplace solutions, they fully rely on existing Internet standards. The data structures used in the UDDI APIs are defined in XML. Detailed information about the UDDI data structures can be obtained from the Data Structures Specification [UDDI_DataStructure]. The actual communication with UDDI registries takes place using SOAP (the Simple Object Access Protocol) is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. (SOAP). SOAP, which is built on XML, defines a simple way to package information for exchange across system boundaries. SOAP bindings for HTTP are built on this packaging protocol and define a way to make remote procedure calls between systems in a manner that is independent of the programming language or operating system choices made by individual companies. The SOAP 1.1 specification is available as a The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential as a forum for information, commerce, communication, and collective understanding. (W3C) note [SOAP].

4. Use Cases

We have examined the aspects of publishing and discovering Web services in general and how UDDI tackles it in particular. We will now examine a few use cases that show UDDI's usefulness when conducting collaborative e-business.

4.1. The buyer/seller scenario

The most obvious use case is the buyer/seller scenario. For sellers, UDDI serves as a platform to extend their market reach. By publishing their business and product or service offerings publicly in a standardized format, they can be found globally in a reliable manner, independent of their size. This can efficiently reduce the entry barriers for international trade, particularly for small and medium-sized enterprises.

Buyers can use UDDI for a global, cross-industry search of products and services. Assuming that sellers describe their offerings using well-recognized category systems, this will lead to a very competitive market.

4.2. The marketplace scenario

Buyers and sellers may also participate in an electronic marketplace. Marketplaces are often industry-specific (for example, supply of chemicals and pharmaceuticals or offering travel services) and were often focused on specific aspects of the overall supply-chain (for example, buying/selling or transportation).

Several use cases for using UDDI in a marketplace environment are conceivable:

• Marketplaces represent a community of buyers and sellers. To attract further participants, a marketplace can be published in a UDDI business registry so that it can be discovered and classified more easily.

• Marketplaces make use of UDDI to enrich their business with value-added services. For example, a marketplace for buying and selling of indirect goods in the automotive industry may also want to extend its business to direct goods. Therefore, additional services in the area of logistics, financing or insurance can be discovered in a UDDI business registry.

  These value-added services can be integrated either statically or dynamically. Static integration is intended for services with a higher quality demand, for example, payment services. The service provider will be added to the marketplace's business directory and the service may be further adapted to the marketplace technology needs so that UDDI does not have to be called before the service is invoked. Dynamic integration is more suitable for loosely coupled services, such as catalog services or notification services. Here, the reason for integration is to make the selection of service providers more complete and to be able to choose the fastest or cheapest one. Hence, a steadily growing selection of service providers is likely to be discovered for every new service request, requiring simple ways of integrating services into the overall supply chain.

4.3. Private registries

The UDDI specifications can also be used to implement privately-used registries for single companies or larger communities represented by industry consortia or marketplaces. On the one hand, the advantages for easier and standardized service description and discovery still apply. On the other hand, specific data structures for the needs of the company or community certainly have to be added. For example, a marketplace likely wants to keep information about delivery reliability, payment terms and other key figures for its participants so that a long list of suppliers for a specific type of product can be classified accordingly.

As a consequence, data exchange between existing public and new private registries is the next required step. However, data sent to a public UDDI registry definitely needs to be filtered to some extent. Also, double publication has to be avoided and stable references between public and private entries have to be established.

4.4. Aggregators

The current UDDI Inquiry API only covers discrete retrieval of data, does not support rich queries and covers data authentication and validity to a small amount. The reason for this is that the public UDDI registries can be accessed publicly but should also show high performance.

However, users would definitely like to know more about the quality of the data and also ask for more detailed search functions. As a result, there seems to be a business model for aggregators who merge data obtained from UDDI registries with third-party data providers. For example, enriching the business data from a UDDI registry by financial key figures from other business directories could be used to determine the credit-worthiness of the companies whose collaborative Web services are to be invoked. Also, detailed search functions such as "give me all the businesses that are located in the US, offer EAI consulting and have a zip code beginning with 94" could be offered but have to be provided in addition to public UDDI registries. ³

5. Conclusion

5.1. Use UDDI now

On the one hand, UDDI is a set of specifications that certainly has to be evaluated in practice. On the other hand, UDDI is actually a group of public registries that can be used free of charge for publication and discovery. The easiest way to prove UDDI's usefulness is to publish your business using one of the GUIs that are currently available or the Publishers' API directly. Make sure that you use standardized identifier and category systems and service types which should already be published.

5.2. Participate in UDDI's development and standardization

If you discover any serious problems or shortcomings, bear in mind that UDDI is still in development. Also, there are already some enhancements in UDDI Version 2 that might meet your outstanding requirements:

• Validation of category systems and identifier systems

• Capturing of business relationships

• Reuse of business services

• Further internationalization

• Structuring of address information

Further enhancements will be delivered with UDDI Version 3 in the second half of 2001. There is still the opportunity to participate in UDDI's development by becoming an UDDI Advisor. The advisor's role is to collect requirements and to give early feedback on new specifications, which will help UDDI to meet the needs of a broader set of companies, industries, and countries.

After the development of the first versions, the overall goal is to submit all UDDI specifications to an open standards body in early 2002.

5.3. Look for UDDI-enabled products

Enabling systems, applications and products to interactively collaborate with UDDI registries is the key to really benefiting from UDDI. Products that seamlessly integrate their functions with the UDDI publication and discovery mechanisms will definitely lower the total cost of ownership.

SAP's strategy with regard to UDDI comprises three topics:

• mySAP.com offers Web services

  The mySAP.com™ e-business platform is built on e-business standards and technologies such as XML, HTML, HTTP, and SOAP to ensure openness and interoperability. All SAP Business Application Programming Interfaces (BAPIs) can be accessed using XML over the Internet and represent SAP's Web service infrastructure for collaborative e-business.

• mySAP.com uses UDDI

  The mySAP.com collaborative e-business solutions will use and conform to the UDDI APIs where appropriate. For example, whereas mySAP CRM Internet Selling and Service is the canonical candidate for the publication of Web services, mySAP E-Procurement is the right solution for the discovery of new business partners and their services. All in all, SAP customers will benefit from UDDI-enabled SAP solutions due to seamless and standardized publication and discovery of Web services.

• mySAP Services augmented by UDDI services

  SAP is soon to become a public UDDI registry operator and publicly offer publication and discovery services. Also, value-added services in addition to UDDI are likely to be offered through the SAP Service Marketplace, a portal for SAP customers to access mySAP Services online.

Design and Development by deepX Ltd.