Understanding UDDI (unified description, discovery and integration)

This article is from IBM
[Guide] unified Description, Discovery and Integration (Universal Description, Discovery, and Integration, UDDI) the project continues to enrich the tool set used by enterprises to represent Web services and establish their models in the UDDI business registration center. This article will introduce UDDI and its role in promoting the development of Web Services.

What is UDDI?

The UDDI project encourages Web services to operate and adopt each other. It is a partnership between leading enterprises in the business and industry, which was first established by IBM, Arba and Microsoft. More than 300 companies have participated. UDDI provides a set of standards-based specifications for describing and discovering services and a set of Internet-based implementations. UDDI continues to develop rapidly and has won industry support. The reason for the rapid development of this specification is that it provides support behind the rapid implementation, which not only proves the idea, but also provides a rich practical basis for further improving the specification.

UDDI solves a large number of problems encountered by enterprises. First, it can help to expand the scope of business-to-business (B2B) interaction and simplify the interaction process. For manufacturers that need to establish many relationships with different customers, each of them has its own set of standards and protocols. UDDI supports a highly adaptive service description and can use almost any interface. Although a flower shop in Australia is eager to enter all the markets in the world, it is hard to know how to succeed. UDDI provides a way to achieve this goal. The regulations allow an enterprise to publish the services it provides in the registration center, so that enterprises and services become efficient and simple.

For B2B trading place providers, they need to obtain classified data of suppliers in this industry and their relationships with billing services, packers, carriers, insurance companies, etc, UDDI allows you to dynamically discover and integrate relevant Web services into an aggregated business process. UDDI provides an all-in-one search for enterprise and electronic services. Publish enterprise and service information in UDDI so that other enterprises can access this information in a wide range.

UDDI is based on existing standards, such as Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP ). All compatible implementations of UDDI support the UDDI specification. Public regulations are developed by institutional members in an open and inclusive process. The purpose is to generate and implement three consecutive versions of this specification, and then hand over the ownership of future developed results to an independent standard organization.

Figure 1. Hierarchical Web service protocol stack of UDDI

As shown in figure 1, UDDI is included in the complete Web Service protocol stack and is one of the main components of the protocol stack. It supports creating, describing, discovering, and calling Web Services.

UDDI is built on the network transmission layer and the XML message transmission layer based on SOAP. Service Description languages such as Web Services Description Language (WSDL) provide a unified XML Vocabulary (similar to Interactive Data Language (IDL) it is used to describe the Web service and its interfaces. You can build the entire foundation by adding hierarchical functions, such as using Web Service Flow Language (WSFL) Web service Flow Description, security, management, and service quality functions, this solves the problems of system reliability and availability.

Working principle of UDDI

The UDDI registration center contains descriptions of services supported by enterprises and enterprises that can be accessed by means of programs. In addition, it includes industry-specific specifications and classification definitions supported by Web Services (used for categories that are important to enterprises and services) and the reference of the identification system (which is very important to the enterprise. UDDI provides a programming model and model that defines rules for communication with the Registry. All APIs in the UDDI specification are defined in XML, packaged in a SOAP envelope, and transmitted over HTTP.

Figure 2. The flow of UDDI messages between the client and the Registration Center

 

Figure 2 illustrates the transmission of UDDI messages, which are transmitted from the client's SOAP request to the Registration Center node through HTTP and then reverse transmission. The SOAP server of the Registry server receives and processes the uddi soap message, and then returns the SOAP response to the client. As far as the Registry regulations are concerned, requests sent by clients to modify data must be secured and verified.

Figure 3. Working Principle of UDDI

Figure 3 shows how to send data to the UDDI registration center and how customers can discover and use this information. The UDDI registration center is built on the data provided by customers. Several steps are required to make full use of data in UDDI. As shown in step 1, software companies and standard organizations start to publish useful information to the Registration Center when defining specifications for industries or enterprises registered in UDDI. These specifications are called technical models or, more commonly, tModels.

In step 2, the company will also register a description of its business and the services it provides. As shown in step 1, the UDDI registration center assigns each entity a Unique Identifier in the program, called the Unique Universal Identifier (UUID) Key, so that you can understand the situation of all these entities at any time. The UUID key must be unique and never changed during a UDDI registration. These keys look like formatted hexadecimal random strings such as C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 ). These keys can be used to reference objects associated with them. The UUID key created in a registration is valid only in the context of the Registration Center.

In step 2, other types of clients and commercial applications such as e-Marketplace and search engine (for example, Web Services Based on Workflow aggregation) use the UDDI registration center to discover the services they are interested in. Then, other enterprises can call these services to facilitate dynamic integration, as described in step 1.

The data in the process of UDDI registration can be divided into four categories, each of which represents an entity at the top of UDDI. Each such entity has its own UUID. This identifier can always be found in the context of the UDDI registration center:

• Technical model)
• Business)
• Business service)
• Service binding)

 

We can divide the registration information of enterprises and services into three groups: White Pages, yellow pages, and green pages.

Basic information about an enterprise, such as the company name, business scope, and contact information. It also includes any identifier of the enterprise, such as the Dun & Bradstreet D-U-N-S number.

The yellow page information allows you to search for enterprises or services registered in the registration center in a larger scope by using a variety of classification systems. Such classification can be associated with not only the enterprise and its services, but also the tModel. One or both of the white pages and yellow pages are provided, so the value of items in the Registration Center is very limited for service discovery and use through programs. To this end, it is necessary to know how and where the service can be called through a program, and the green page provides such information.

Green pages refer to the binding information associated with services, and provide references to the technical specifications implemented by these services and pointers to different discovery mechanisms based on file URLs.

The UDDI registration center consists of one or more implementations of the UDDI specification, which can interoperate to share the Registration Center data. A special UDDI registration center is composed of a group of UDDI implementations called nodes that are publicly accessible. They interoperate with the data of the shared registration center and form a UDDI business registration center. The Registration Center is free to the public. All entries in the UDDI service registration center are redundant on all Operator sites, but the entries can be changed only when the site is created.

IBM and Microsoft jointly run the 1st edition UDDI business registration center node. These two companies and HP and SAP are currently operating beta testing sites that support most of the 2nd edition UDDI specifications. The four companies plan to support version 2 production registration centers by mid-December 2002. Each company supports SOAP APIs defined by the UDDI specification. Ensure consistency through commercial contracts. Several companies are free to provide additional services beyond the scope of the services required by the specifications, such as browser-based user interfaces (all companies have done this ).

A glimpse of the UDDI Specification

The UDDI specification consists of some documents. API Specification Description specifies the soap api that allows you to perform discovery and release operations. Also describes request/response semantics and error handling. In addition, there is a lot of information about conventions and usage. The accompanying documents include Data Structure specifications and API Schema, which define message and Data semantics.

The uddi api belongs to the Inquiry or Publishing category. Version 1st supports API operations, as shown in Listing 1.

List 1. Summary of UDDI V1 APIs

Inquiry Operations: Publishing Operations: Find Save find_business save_business find_service save_service find_binding save_binding find_tModel save_tModel Get details Delete get_businessDetail delete_business get_serviceDetail delete_service get_bindingDetail delete_binding get_tModelDetail delete_tModel get_registeredInfo get_registeredInfo Security get_authToken discard_authToken

 

Query APIs classify themselves into three query modes:

• In browser mode, you need to use the search operation. The search operation allows you to use different types of standards when Browsing entries, such as classification categories, identifiers, or use the find_xxx API to find incomplete name information.
• The step-by-step mode involves obtaining detailed information about the items you have found. The get_xxx API supports this function.
• The call mode is the last mode. To call a service, you need to bind the template information. Generally, the client places this information in the cache for reuse. You do not need to go back to the Registration Center to obtain the same information every time you need this information. If the binding information changes, the client will return to the Registration Center to update the information once the service cannot be obtained or used. This is called the call mode.

Although each top-level entity can be saved and deleted (using the save_xxx and delete_xxx APIs), it is automatically described. However, it should be noted that the preservation operation in UDDI is destructive. For example, if the same service is retained, but the information is different, the entity that previously represented the service will be completely replaced.

Operations related to authTokens require you to pre-register with a UDDI business registration center node and provide the creden。 necessary to confirm the identity of the publisher. These creden。 are used to obtain the authToken used to perform the publish operation (using the save_xxx API. If we assume that the authToken has not expired, it can be reused for a short period of time during the closely following release operation. The regulations formulated by the carrier determine the content and life of the authToken.

Supports Modeling

Updates on supported modeling mainly aim to help large organizations build their enterprise and service models more efficiently. From large group enterprises that involve different types of risks to companies that focus on a business and want to divide their Web products according to the geographical regions of their services, many want them to be independent but associated enterprises on the Web. In UDDI Version 1, the only choice for these cases is to keep the enterprise independent, but there is no relationship between them. Version 2 allows you to define relationships between enterprises, such as parent-child relationships, partners-partners, and equivalent relationships. In this way, you can create models for companies with subsidiaries, external business partners, or various internal departments. Any two enterprises (defined according to their unique enterprise key) may have a relationship. The standard tModel of the new Business Relationship type supports this capability, and there are some new release APIs that allow you to define, delete, and request Relationship states, as shown in Listing 2.

The new query API named find_relatedBusinesses enables you to search for the relationships related to a given company anonymously. Other new release APIs in Listing 2 are related to the relationships created and owned by specific publishers, and these relationships cannot be accessed through anonymous queries. An enterprise relationship consists of a pair of identical relational assertions. Each relational assertion connects the two enterprises and marks the established relationship. To form an externally visible Enterprise Relationship, each of the two enterprises involved must declare the same relational assertions. Only those matching relational assertions will be returned as the find_relatedBusinesses () query results.

The following example shows how a link is formed and how to discover it in the future. First, you will get a release authorization token:

Listing 2. Get an authToken

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <get_authToken generic="2.0" xmlns="urn:uddi-org:api_v2" userID="businessA_UserId" cred="businessA_Password" /> </Body> </Envelope>

The returned content is as follows:

Listing 3. Get the authToken response

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <authToken generic="2.0" operator="www.ibm.com/services/uddi" xmlns="urn:uddi-org:api_v2" > <authInfo>businessA_AuthToken</authInfo> </authToken> </Body> </Envelope>

Then, you establish an enterprise assertion to associate enterprise A with Enterprise B. Here, we do not use the typical UUID format, but abbreviated their businessKeys as businessKeyA and businessKeyB respectively. For the sake of simplicity, we will not show SOAP envelopes.

<add_publisherAssertions generic="2.0" xmlns="urn:uddi-org:api_v2"> <authInfo>businessA_AuthToken</authInfo> <publisherAssertion> <fromKey>"businessKeyA"</fromKey> <toKey>"businessKeyB"</toKey> <keyedReference keyValue="parent-child" keyName="Subsidiary" tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/> </publisherAssertion> </add_publisherAssertions>

Once the master of Enterprise B has established the same assertion, it will be able to see a publicly visible Enterprise Relationship in the Registration Center. Then, you can use the find_relatedBusinesses () API to execute a simple query:

<find_relatedBusinesses generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessKey>"businessKeyA"</businessKey> </find_relatedBusinesses>

Listing 3 shows the returned XML. A more fine-grained query may include a keyedReference that identifies the specific link being searched.

Another important feature added in version 2 to support modeling needs of large enterprises is Service Projection, which allows an enterprise to create references to services owned by another enterprise. This is useful in some situations. For example, it is useful for companies and general services (such as overnight transportation) that provide the same service in two or more industries, many enterprises want to link a common service to their own services to encourage them to use them.

This is not the case with the projection service reference function. The creator of service projection cannot change the referenced real service, but in all other aspects, this service is actually owned by the enterprise that creates the projection. The service is part of the response returned by the get_businessDetail () or get_serviceDetail () API call. With the enterprise key associated with the service, you can separate the projection service from the real service area. This key always matches the real enterprise that owns the service, rather than the enterprise that creates the service projection.

Internationalization

Efforts have been made to improve the internationalization of UDDI, and some new features have been added. We have added support for multiple names and xml: lang code for businessService and businessService. Although you must provide at least one name, you can also provide multiple names (each name uses a different language code ).