Configuring UDDI Services

The Universal Description, Discovery, and Integration (UDDI) protocol provides a broad, standardized infrastructure that lets you describe and discover Web services. The UDDI registry is a Simple Object Access Protocol (SOAP)–based Web service that locates Web services and programmable resources on a network. UDDI provides a foundation for developers and administrators to readily share information about Web services.

One problem with UDDI is that people think of it as a big, unsecured, centralized repository on the Internet that they would never use for their own businesses for fear of compromising their data. Most organizations simply wouldn't trust an untested third-party Web service to carry out important business logic for them. This fear is justified. After all, no one wants to let someone else implement important business logic in a Web service that's publicly exposed.

Microsoft realized that enterprises would adopt UDDI much more rapidly than business-to-business (B2B) users would. As a result, Windows Server 2003 includes UDDI Services, which lets companies run private UDDI services for intranet or extranet use and take advantage of the flexibility that UDDI offers without worrying about data privacy.

Implementing UDDI Services in Windows 2003
UDDI Services is a database-driven ASP.NET application that has both a UI and a Web services interface. Microsoft designed the UI to search for Web services, find providers of Web services, or manually enter Web services metadata. The Web services interface, which fully implements the UDDI 2.0 and UDDI 1.0 APIs, is used at runtime to perform tasks such as running queries against the registry and programmatically registering Web services. The database is implemented either as a Microsoft SQL Server 2000 database or as a Microsoft SQL Server 2000 Desktop Engine (MSDE) database. (To determine which database you should use, see the sidebar "SQL Server or MSDE?") UDDI Services also comes with an administrative console—the UDDI Services Console, which consists of a Microsoft Management Console (MMC) snap-in and a set of command-line tools that let you administer local or remote UDDI Services sites and perform database backups.

Before You Install UDDI Services
In a standalone UDDI Services installation, both the Web application and database reside on one computer running a member of the Windows 2003 family. The database resides on a SQL Server 2000 or a local MSDE database instance, and the Web application then connects to that instance. Most developers will want to install a standalone installation on their development workstations or servers. This solution is perfect for a limited number of users. For enterprisewide implementations, however, Microsoft recommends a distributed installation, which provides the most fault-tolerant and responsive configuration available because it places each of the UDDI Services components on separate servers, a server cluster, or a Web farm. How you decide to distribute the UDDI Services components depends on how you choose to load-balance your installation. MSDE doesn't include administrative tools and can't communicate across a network. For this reason, you can use MSDE only in standalone UDDI Services installations. To perform a distributed installation, you must be running Windows 2003, Enterprise Edition or Windows 2003, Datacenter Edition (these editions also support standalone installations). Windows 2003, Standard Edition supports only a standalone UDDI Services installation.

Installing UDDI Services
To install UDDI Services, open the Control Panel Add/Remove Programs applet. Clicking the Add/Remove Windows Components icon in the navigation menu starts the Windows Components Wizard; scroll down the list of check boxes and select UDDI Services. Click Next. If you don't already have Microsoft IIS installed, the wizard installs IIS and configures ASP.NET for you. Next, perform the following steps:

Installation Notes
In a default IIS installation, all the Web extensions (e.g., Active Server Pages—ASP, ASP.NET) are prohibited. After you run the UDDI Services installation, the wizard permits the ASP.NET v1.1.4322 Web extension, as Figure 4 shows. If you prohibit this Web extension, you won't be able to use UDDI Services.

If you want to use SQL Server 2000 to host the UDDI Services database components, you must either install the application on your machine or point to an already existing instance on another machine before you can install the UDDI Services database components. As Figure 1 shows, the UDDI Services installation wizard UI doesn't let you choose whether you want to point to a SQL Server database; it detects only that either SQL Server or MSDE is installed on the machine, then offers the option of installing an instance of MSDE. To change this default, open the UDDI Services MMC snap-in, find the site that you created, expand the list of servers, right-click your server to access its Properties dialog box, select the Database Connection tab, then click Change to change which database UDDI Services will use.

Registering XML Web Services
You've now installed UDDI Services. But before you can use it, you need to publish an XML Web service into your UDDI registry. To do so, you must know a few things about how UDDI classifies its organizations and services.

UDDI Services has six primary entities, with their associated UDDI specification names in parentheses:

The Provider entity is the highest level in the UDDI Services data entity hierarchy. Immediately below it are the Contact (optional) and Service entities. Each Service entity has a Binding entity, and each Binding entity has an optional Instance Info entity, which is really a pointer to a tModel entity, as Figure 5 shows.

For demonstration purposes, I've provided a sample Web service application that you can use to register your UDDI Services instance (see Web Listing 1, http://www.winnetmag.com, InstantDoc ID 42004). The Web service is a basic "Hello World" Web service that, when invoked, returns the string "Hello World." Simply create a virtual directory on your machine and point it at the location of the "Hello World" Web service files.

Publishing an XML Web Service
To publish an XML Web service to UDDI Services, follow these steps:

You can perform all the above steps by using the UDDI Services Web application (http://servername/uddi) or by programmatically making Web Service calls to the UDDI Services server. Web Listing 2 shows a sample C# Console application that registers a Web service to a UDDI Services instance using the Microsoft UDDI .NET software development kit (SDK) version 1.76 (http://download.microsoft.com/download/visualstudionet/patch/v.1.76/w98xp/enus/uddisdksetup.msi), which you must first install for the code to compile and run. The code includes the batch file UddiDemoPublisherBuild.bat that compiles the code into an executable program called UddiDemoPublisher.exe. The console application prompts you for the UDDI machine name, username, and password to authenticate against UDDI Services. The application then asks for your service provider name (organization), the name you want to give to the Web service, and the Web service URL. After the application has all this information, it creates an entry in the UDDI Services database for your Web service. This code demonstrates how easily you can use the UDDI .NET SDK to automatically register Web services.

Integration with Visual Studio .NET
Now that your Web service is published to UDDI Services, you can take advantage of its integration with Visual Studio .NET. As long as you've entered the WSDL file with your Web service, you can reference your Web service from Visual Studio .NET. This process is the same as the process for referencing all other Web services in Visual Studio .NET—you use the Add Web Reference Wizard. This time, enter http://your UDDI server name/uddi/addwebreference, which will bring up the UDDI Services search tool in the Visual Studio .NET Wizard, as Figure 6 shows. After you find your Web service in the search results, click the service you want, then click the service's corresponding interface definition. The WSDL file appears in the left pane, and you can click Add Reference below the right pane.

Publish WSDL Files for Your Web Services
Even though Microsoft doesn't require it, I highly recommend that you publish all WSDL files for Web services as tModels. If you have multiple Web services that implement the same interface (e.g., WSDL), they can all reuse the same Instance Info tModel. Here's where the real power of UDDI lies. Registering one WSDL file that one or more Web services can implement lets you perform some interesting functions at runtime, such as Web service failover, Web service aggregation, and polymorphism.

Next Steps
After you get the hang of how UDDI Services works, you'll be hooked. Application developers can use the centralized information in UDDI to make intelligent decisions at runtime about which Web services need to be invoked according to certain business rules. UDDI Services lets you quickly and easily implement these possibilities.