Web Service description and Discovery using UDDI (Part I) [from Microsoft]

web| Microsoft uses UDDI Web Services Description and Discovery (Part I)
Karsten Januszewski
Microsoft Corporation
October 3, 2001

View and download the source code (in English) for this article. Brief Introduction
So far, At Your ServiceThe column has covered the actual case of how to build a Web service: from the original design document to the business association, until the final deployment. The next step is to consider how to publish a Web service so that interested customers can easily discover the service and apply it to their applications. There is now a discovery mechanism for implementing this requirement: Common description, Discovery, and Integration (UDDI), which is the industry's first step in supporting the discovery of WEB services across technology and across platforms.
At Your ServiceAuthor cordially invited me to write a column about UDDI and its registration steps, and I am very happy to accept this work. First I will introduce the implications of UDDI from both technical and business aspects. I will then discuss the relationship between UDDI and the Web Service Description Language (WSDL). Finally, I'll take you through the registration process for UDDI and introduce some of the issues that need to be considered to give full play to the UDDI potential. In the next installment, the second part of this article, I'll introduce At Your ServiceHow the group is making the best use of UDDI. Global Registry of Uddi-web services
UDDI is a public registry that is designed to hold information about companies and their services in a structured way. With UDDI, people can publish and discover information about a company and its WEB services. The data is categorized using a standard taxonomy, so that information can be queried by category. Most importantly, UDDI contains information about the technical interface of the company's services. Through a set of SOAP-based XML API calls, users can invoke and use these services by interacting with UDDI at design time and at run time to discover technical data. In this way, UDDI can be used as the infrastructure of a WEB-services based software system.
Why use UDDI? Why do I need this registry? When we face software systems with thousands of or even millions of Web services, we face the following daunting challenges:

• How do I discover WEB services?
• How do you classify information in a reasonable way?
• What is the impact on localization?
• What is the impact on proprietary technology? How to protect the interoperability of discovery mechanism?
• How do you interact with the discovery mechanism at run time when the application relies on a WEB service?

The advent of UDDI is precisely the answer to these challenges. To address these issues, many companies, including Microsoft, IBM, Sun, Oracle, Compaq, HP, Intel, SAP, and more than 300 other companies (see uddi:community for a complete list of these companies), Together, a specification based on open standards and non proprietary technologies is developed. The beta version of the specification was released in December 2000 and the official product was launched in May 2001. It is a global business registry, built on multiple carrier nodes where users can search and publish information free of charge.
With this infrastructure of Web services, you can now find data about Web services in a generic, vendor-independent way, and the data is consistent and reliable. Using scalable classification systems and identities, users can conduct accurate classification queries. Runtime UDDI integration can be incorporated into the application. Thus greatly prospering the WEB services software environment. Working principle
UDDI data resides on the operator (that is, the company that is committed to running a common node). This public node follows the Uddi.org organization Management specification. Two common nodes that follow the UDDI specification version 1 have been established: one belongs to Microsoft and the other is IBM. HP is also committed to establishing a node that follows Spec version 2. Data storage operators must be able to replicate data across secure channels to provide data redundancy for the entire UDDI cloud. Once the data has been published to a node, it can be found on another node by copying. Currently, replication takes place every 24 hours, and in the future, as more applications rely on UDDI data, the time interval for replication is shortened.
It is worth mentioning that for data hosting operators to implement their nodes, there is no specific requirements, as long as the node follows the UDDI specification. For example, the Microsoft node http://uddi.microsoft.com/default.aspx (English) is written entirely in C # and runs in the. NET Beta 2 Common language runtime environment. Its code base leverages the local SOAP support and serialization provided by the. NET system classes. At the back end, the Microsoft operator node uses Microsoft®sql Server 2000 as its data warehouse. IBM uses other technologies to run its nodes! However, the behavior of these two nodes is the same, since they all follow the same set of SOAP-based XML API calls. The client tools can interoperate seamlessly with these nodes. Thus, a UDDI public cloud is the best solution to show how the XML Web service model works across heterogeneous environments.
To understand UDDI, next we look at the data stored in UDDI and its storage structure. UDDI is relatively lightweight and is designed as a "registry" instead of a "repository." The difference between the two is subtle, but it is important. The registry redirects the user to a resource, and the repository is completely a repository. We take the microsoft®windows® registry as an example: it contains basic settings and parameters, but ultimately directs the application to a resource or binary code. When a COM component is searched based on the Prog ID, it is booted to a class ID and then through the class ID to the location of the binary code itself.
UDDI behaves like this: it relies on a globally unique identifier (GUID) to search for and locate resources, just as the Windows registry does. The UDDI query ultimately points to an interface (. Wsdl. XSD and. DTD files, and so on), or point to implementations on other servers, such as. ASMX or. ASP file). UDDI can therefore answer the following questions:

• "What Web Service Interfaces have been published that are based on WSDL and are built for the specified industry?" ”
• "Which companies have written the implementation for one of these interfaces?" ”
• "What are the Web services currently provided (sorted in some way)?" ”
• "What Web Services does a company provide?" ”
• "If you want to use a company's Web service, who do you need to contact?" ”
• "What are the implementation details for a WEB service?" ”

WSDL and UDDI
WSDL has become an important part of the WEB Service protocol stack. Therefore, it is necessary to understand how UDDI and WSDL work together, and how each protocol resolves interfaces and implements these two relative concepts. Both WSDL and UDDI are designed to clearly illustrate the relationship between abstract metadata and concrete implementations, and understanding why such partitioning is the basis for understanding WSDL and UDDI.
For example, WSDL explicitly distinguishes between messages and ports: messages (the syntax and semantics required for a Web service) are always abstract, and the port (the network address of the calling Web service) is always specific. You do not need to provide port information in the WSDL file. WSDL can contain only abstract interface information, without providing any specific implementation data. Such a WSDL file is considered to be valid. In this way, the WSDL file is detached from the implementation.
One of the important implications is that a WSDL interface can have multiple implementations. This design allows different systems to write their own implementations for the same interface, thus ensuring a dialogue between the systems. If three different companies implement the same WSDL file, and a client software creates proxy/stub code based on this WSDL interface, the client software can communicate with all three implementations using the same code base, as long as the access point is changed.
UDDI describes this distinction between abstraction and implementation through the concept of TModel. The TModel structure (the abbreviation for "technical Model") represents an abstract type of technical fingerprint, interface, and metadata. The inevitable result of using TModel is the binding template, which is a concrete implementation of one or more tModel. Within the binding template, the access point is registered for a specific implementation of the TModel. As the WSDL schema allows for the separation of interfaces and implementations, UDDI also provides a similar mechanism, since TModel can be published independently of the binding template that references it. For example, a standardization organization or industry organization may publish a specification interface for a specific industry, and then multiple companies can write implementations for that interface. Therefore, each company's implementation needs to refer to the same tModel. The WSDL file is the perfect example of a UDDI TModel. registering with a UDDI
Publishing to UDDI is a relatively straightforward process. The first step is to identify the basic information needed to establish a model for the company and its services on UDDI. The actual registration can then be made. This can be done either through a web-based user interface or through programming. Finally, test your registration entries to make sure that the registration is correct, and that you can display them as required in different types of searches and tools.

Step 1: Establish a model for UDDI entries

Considering the above data model, several key data should be prepared before building a UDDI entry.

2. Determine the TModel (WSDL file) that the Web service implementation needs to use.
   Like developing COM components, you can use an existing interface to develop a WEB service, or you can use an interface of your own design. If the Web service is based on an existing WSDL, you need to determine if the WSDL file is already registered on UDDI. If it is, you need to record its name and tModelKey, which is the GUID generated by UDDI when you register the WSDL file.
   On the other hand, if the WSDL file on which the Web service is based is not yet registered on UDDI, you need to prepare to create a new TModel to represent the interface. This tModel should have the name of the Uniform Resource Identifier (URI) format (MYCOMPANY-COM:SAMPLEWEBSERVICE-INTERFACE:V1) and point to the location where the WSDL file resides.
   If the Web service is a microsoft®visual studio®.net service, you can use the. A query string in the ASMX file (that is,:
4. If you want, you can use multiple languages to determine your company's name and profile, as well as the main contact methods for your company's WEB services.
   UDDI supports the Xml:lang namespace, which allows companies to provide company profiles in multiple languages. In addition, UDDI allows you to list contacts, including e-mail, phone, and address information. The contact list is used to list the resources within your company that are related to WEB services. For example, if someone wants to use your WEB service and need to contact the appropriate business relation manager, who should I contact? Who should I contact for technical issues when using the company's WEB services? The contact should also be listed.
6. Identify the appropriate classification and identification for the company.
   Browse the currently supported UDDI taxonomy through Microsoft UDDI node http://uddi.microsoft.com/default.aspx (English). Currently supported Taxonomies are the North American Industry Classification System (NAICS), common standard product and service codes (UNSPSC), ISO 3166, standard Industry Classification (SIC), and GeoWeb geographic classification. Please select a category that best suits your company.
8. Identify the WEB services that the company provides through UDDI.
   Next, determine which WEB services the company will register on the public UDDI node. Does this service have multiple access points? Do you want to provide other required parameters and information to customers who use this WEB service?
   Note that registering a Web service on a UDDI does not mean that everyone has access. You can set security, authorization, and authentication for your UDDI registry entries in turn. knowing the existence of a WEB service alone does not mean that the service can actually be invoked. before authorizing access to WEB services, there is usually a need for some additional communication between companies.
10. Determine the appropriate classification for the service.
    WEB services can also be categorized as if they can be categorized as a company. As a result, the company may be classified as Naics:software Publisher (51121)at a commercial level, while the service level of its hotel reservation Web service may be classified as naics:hotels and Motels (72111) .

Step 2: Register a UDDI entry

After modeling is complete, the next step is to register your company. You need to obtain an account that has access to the UDDI registry, which cannot be done programmatically, because you must agree to the "Use rules" declaration. The Microsoft node uses Passport for authentication and you need to obtain a passport (http://www.passport.com/Consumer/default.asp) to complete the registration.
There are two options: Use the Web user interface provided by the Microsoft node, or programmatically register by using the SOAP API call node itself. If you do not want to change the registry entries, or if the entries are relatively simple, using the Web user interface is sufficient. However, if you want to update frequently, or if your entry is complex, use the Microsoft UDDI SDK to make a script for the registration process. In addition, because the Microsoft user interface is not localized for other languages, you need to programmatically register if you want to take advantage of the multilingual capabilities of the UDDI API.

Note: You can practice the registration process in a simulated environment with the address http://test.uddi.microsoft.com/default.aspx (English), which is a copy of the actual node being put into use. This is useful for familiarity with the registration process before it is formally used.

Using the Microsoft Web user interface

Registering with the Microsoft Web user interface is a relatively straightforward process. First navigate to the admin page http://uddi.microsoft.com/administer.aspx (English). After you sign in, the options for registering TModel and company are displayed. Here are a few things you need to know to continue your operation:

1. Before registering the service, be sure to register the WSDL file as a TModel, as you will need tModel in the future process.
2. When you register a WSDL document as a tModel, you should classify the TModel by using the UDDI type taxonomy. At a minimum, the WSDL should be categorized as "specification for a Web Service" (Wsdlspec).
   Using this classification method, you can ensure that the TModel classification conforms to the principles of the "Using WSDL in a UDDI Registry" best Practice Document (English). Because TModel can contain references to documents other than the WSDL file, it is important to provide some classification for TModel. Many tools, such as Visual Studio. NET) to narrow the result set of a query by these categories.
3. After registering the WSDL interface as TModel, you need to add the corresponding contact information and the classification information to the company business. You can add as many categories as you think fit.
4. Continue to add WEB services that you want to expose through UDDI. Because a service can have a variety of implementations, you need to add a binding to each added service. For each binding, you need to provide the access point for the Web service, that is,
5. Each binding needs to create a reference for the supported interfaces. The Microsoft UI invokes these as "canonical signatures." A canonical signature is a TModel that contains a WSDL interface. The Microsoft UI provides a screen that allows you to search for TModel based on its URN. This tModel can be registered in step 1, or it can be the tModel of someone else's registered WSDL file.
6. Finally, the system displays an option that requires an HTTP address for an overview document for a particular Web service, and any related instance parameters.

Registering with Microsoft UDDI. NET SDK Programming

Another option for the registration process is to register programmatically. This process can be easily accomplished using the Microsoft UDDI SDK. You must use the Web UI to obtain a UDDI account. When the task is complete, the rest of the process is handed to the script. First, download and install the UDDI SDK, the address is http://www.microsoft.com/downloads/release.asp?ReleaseID=30880 (English). Then, use Visual Studio. NET to create a new C # console application. Add a reference to the Microsoft UDDI SDK DLL whose default installation location is C:\Program Files\Microsoft UDDI Sdk\vs7\microsoft.uddi.sdk.dll. Then, add some namespace references at the top of the code:

Using microsoft.uddi;using microsoft.uddi.binding;using microsoft.uddi.business;using Microsoft.Uddi.Service;using Microsoft.Uddi.ServiceType;

Add the following code in the static void Main (string[] args) function:

You'd better run this program first, register on the https://test.uddi.microsoft.com/publish//publish.url = "Https://uddi.microsoft.com/publish" ; Publish.user = "Your account"; Publish.password = "************";

This will establish authentication for your account. Next, add the following code to publish the WSDL file as TModel:

Create Tmodelsavetmodel stm = new Savetmodel (); STM. Tmodels.add (), STM. Tmodels[0]. Name = "Insert URN here"; STM. Tmodels[0]. Descriptions.add ("en", "Insert description here"); Tmodels[0]. Overviewdoc.overviewurl = "Insert WSDL URL here";/the next line is the STM necessary to tModel the correct classification. Tmodels[0]. Categorybag.add ("Uddi-org:types", "Wsdlspec", "Uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"); string sTModelKey = ""; /Send to udditry{tmodeldetail TMD = stm.   Send (); Stmodelkey = TMD. Tmodels[0].         tModelKey; }catch (uddiexception UE) {Console.WriteLine (UE).   message); return;}   catch (Exception e) {Console.WriteLine (e.message); return;}

After a successful save, UDDI generates a new unique tmodelkey that will be used later in the binding of the Web service. Next, create the company entry:

Create company Savebusiness SB = new savebusiness () sb. Businessentities.add () sb. Businessentities[0]. Name = "Insert company name here"; sb. Businessentities[0]. Descriptions.add ("en", "Insert description here")//Create company service SB. Businessentities[0]. Businessservices.add () sb. Businessentities[0]. Businessservices[0]. Name = "Insert service name here"; sb. Businessentities[0]. Businessservices[0]. Descriptions.add ("en", "Insert service description here");//Create binding template sb. Businessentities[0]. Businessservices[0]. Bindingtemplates.add () sb. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. Description.add ("en", "insert binding note here"); sb. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. Accesspoint.text = "Insert access point here"; sb. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. Accesspoint.urltype = microsoft.uddi.api.urltypeenum.http;//Create TModel instance information sb. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. TMODELINSTANCEDETAIL.TMODELINSTANCEINFOS.ADD () sb. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. Tmodelinstancedetail.tmodelinstanceinfos[0]. Descriptions.add ("en", "Insert description here ")//Use the tModelKey string above to SB. Businessentities[0]. Businessservices[0]. Bindingtemplates[0]. Tmodelinstancedetail.tmodelinstanceinfos[0]. tModelKey = stmodelkey;//sent to udditry{   businessdetail BD = sb. Send ();    //display Xml   console.writeline (BD); catch (uddiexception UE) {   console.writeline (UE). message);    return;} catch (Exception e) {   console.writeline (e.message);    return;}

At this point, both the WSDL definition and the company information have been saved to UDDI. You can edit these entries at any time by passing the appropriate keys.

Step 3: Search for entries in UDDI

After registering entries in UDDI, it makes sense to perform the following three kinds of checks. First, use the Microsoft Web user interface to search your company by name and category, confirming that it exists in the result set that is returned. Second, open Visual Studio. NET and make sure it is displayed through the ADD Web Reference dialog box. If not, you may not be able to categorize your tModel correctly using the Uddi-org:types taxonomy described above. You should be able to add WEB services to your project and generate agent code based on a WSDL file. Third, wait 24 hours, your entry will be copied to the IBM node, which can be queried through its UI, address is https://www-3.ibm.com/services/uddi/protect/find (English). Summary
UDDI and WSDL, as a free specification, can help build a web-based software system. WSDL provides a formal vendor-independent approach to defining WEB services so that the next generation of remote procedure calls can be implemented. UDDI provides a broad, standardized infrastructure that allows people to describe and discover Web services. The combination of these two standards will bring a thriving Web services ecosystem.
Next week's column will show you At Your ServiceHow the team models and registers in UDDI for the collection Service (English).