Enterprise Software

Making your Web services available to the world

You've created a Web service and now it's time to let others know where to find it and how to use it. See how to add a namespace to your service and publish it to a public directory using UDDI.


In our previous article, we worked through a basic example that demonstrated how easy it is to build an XML Web service in .NET. We just created a simple text file and placed it on the Web server, and we had a functional Web service. But what about publishing the service so that others can use it? How do you get the word out about a service? How do others locate it? In this article, we'll address these questions. We'll start by looking at namespaces, which are necessary to avoid conflicts with other Web services. Then, we'll discuss how to publish your Web service in a directory so others can use it.

Namespaces
When we created the ConvertMoney Web service in the previous article and accessed it in a browser, a page was generated by the .NET Framework. This page makes the service easy to test. But as you can see in Figure A, the page also contains a large amount of information. Most developers, being developers, don’t take the time to read that information. However, you should understand what it is saying and why it is important.

Figure A
ConvertMoney page generated by .NET Web service


The first two lines below the list of functions are:
  • This Web service is using http://tempuri.org/ as its default namespace.
  • Recommendation: Change the default namespace before the XML Web service is made public.

What does this mean? A Web service needs a namespace. A namespace is an additional way to identify a Web service. If you and someone else both create a ConvertMoney Web service, they can exist in separate namespaces and therefore be treated independently.

The default namespace for a .NET Web service is tempuri.org. While this might sound like a Japanese dish, it stands for “temporary uniform resource identifiers” and is pronounced “temp URI.” Microsoft recommends that you change the namespace before making your Web service public, even if “public” just means within your organization. Typically, it's a good practice to use a namespace that matches your company’s domain name.

To set the namespace, you simply add some code to your Web service. The code is simply an attribute to the WebService keyword that appears before the class. For our ConvertMoney Web service, the first three lines of code look like this:
<%@ WebService Language="VB" Class="ConvertMoney" %>
Imports System.Web.Services
<WebService()>Public Class ConvertMoney

To change the namespace, you just add a Namespace attribute to the WebService tag, as shown here:
<%@ WebService Language="VB" Class="ConvertMoney" %>
Imports System.Web.Services
<WebService(Namespace:="http://volanttraining.com")> _
Public Class ConvertMoney

By adding this Namespace attribute, you have now differentiated your ConvertMoney Web service from anyone else’s ConvertMoney Web service. If you run the Web service again, the warning about tempuri.org no longer appears (Figure B). The service still runs as it did before, but it is no longer using the default namespace of tempuri.org; instead, it is using volanttraining.com.

Figure B
ConvertMoney Web service without warning


UDDI: Yellow Pages for Web services
To publish your Web service so that others can use it, you need to register it in a searchable directory. Fortunately, such a directory already exists: Universal Description, Discovery, and Integration (UDDI). It's an open, vendor-independent initiative designed to act as a Yellow Pages. You can use UDDI to find existing Web services or to publish your own. The services don’t actually get copied to the UDDI servers; instead, UDDI lists services and refers people to the servers on which they exist. In this sense, it is a true directory and not a repository.

You can learn more about UDDI by visiting its Web site. This is the public UDDI, which anyone can search and with which anyone can list Web services. To use the public UDDI directory, you have to sign up for an account. You can also bring UDDI into your organization; by setting up a UDDI server inside your enterprise, your developers can publish, discover, and use Web services.

When you visit the UDDI Web site, you can register your company in the directory. Because UDDI is an open initiative, companies such as Microsoft, HP, and IBM are using it. Each company participating in the initiative is running its own UDDI server, so you’ll have to choose which company you want to visit. Version 1 is the current UDDI version, with version 2 currently in beta. If you choose to visit the Microsoft version 1 UDDI site, you will be able to search for existing Web services.

UDDI offers a great deal of flexibility in searching for a particular service or functionality. You can search for services based on a company name, business location, SIC code, or other criteria. For example, if you choose to search for the term “zip” and set the search to occur in “tModel by name,” you’ll return five instances of Web services that contain “zip.”

In addition to searching for services, you can register your own. Once you've registered your company on the site, you can add a service name and description and the Web address for the service you are registering.

Conclusion
We've seen how easy it is to create an XML Web service in .NET and to add a namespace to differentiate it from other Web services. Now, you can publish your service to a public directory using UDDI so that others can find and consume your Web services. You can also use UDDI to search for other Web services to use in your own applications, and you can even use UDDI inside your organization to register Web services for your enterprise development.

Editor's Picks

Free Newsletters, In your Inbox