Discovering Web Services

The Universal Description, Discovery, and Integration (UDDI) specification outlines the structure (i.e., the syntax and semantics) for the Web Services equivalent of the yellow pages. Businesses can register their Web Services in the UDDI business registry and, in doing so, let partners and anyone else who knows and supports UDDI easily find the Web Services they need. With UDDI, Web Services descriptions exist in one place that provides a standard interface for query and storage. The UDDI software development kit (SDK) supplies API functions that let you interact with the UDDI registry directly from a COM-based program.

Strictly speaking, you don't need UDDI to issue calls to remote or local Web Services. As I demonstrated in my previous two columns, you can call a Web service if you know its URL and use a particular Simple Object Access Protocol (SOAP)-based format to make an HTTP request. UDDI has very little to do with any calling protocol you might use.

Likewise, you don't need the UDDI SDK for many Web Services scenarios. In particular, you don’t need to be acquainted with UDDI to write a Visual Basic.NET (VB.NET) or a C# Web service. Nor do you need it if you want to access a given service as a client. In any circumstance where you know everything you need about a Web service, you simply don’t need UDDI and its SDK.

So when can the UDDI SDK really benefit you? The UDDI SDK is useful when you need to know about the specific services that partners participating in the UDDI program offer and when you're preparing your own information so that others can link to it and work with you. For example, if you want to share a Web service with partners or use it to generate revenue, UDDI can help. You can also use UDDI to write an offline application that manages the UDDI registry, caches data locally, and maintains the settings for your Web Services. Such a management application isn't necessary for developing Web Services, but any successfully developed Web control can take advantage of it.

Before you can publish data to the UDDI registry, you need to register with the UDDI server and obtain valid credentials—typically a username and a password. The UDDI SDK includes objects that can help you manage Web service registrations. You can also register when you set up any application that's UDDI-compliant and that requires you to use and advertise special Web Services.

The UDDI registry uses XML messages with a SOAP layout to communicate with potential client programs. Because the messages use a SOAP-based format, they consist of an envelope portion and a body. The envelope objects in the UDDI SDK take care of the raw SOAP details, including the request/response processing and byte transportation. The message objects provide an object-based programming interface that lets you send and receive the request and response data you want to exchange with the UDDI registry.

When you work with UDDI, a key object is the RequestManager, which, in VB 6.0, you declare using the following syntax:

Dim r As New UDDIEnv.RequestManager

Of course, for this code to work, you must have imported the necessary type libraries for envelopes and messages. By default, the RequestManager connects to the UDDI registry's production instance at the Microsoft Web site [http://uddi.microsoft.com] to obtain these libraries.

When you want to find information about Web Services in the UDDI registry, you first "find" the service, and then you "get" the details. After the Find stage, you typically know whether your search has been successful. Each message (e.g., Find_Business) returns a specific message type. You typically use the Find message if you're looking for someone that offers a certain Web service. You might use the Get message if you're familiar with a company's Web service but want to learn more about its implementation and related features.

   Previous  [1]  2  3  Next