| The amount of information on the Web is growing tremendously every day. Although a lot of this information might be rubbish, an equally significant chunk consists of beneficial goods and services. Unfortunately, those useful goods and services may be hard to find among the trillions of bytes of data. This is where UDDI enters from stage right. Universal Description, Discovery, and Information (UDDI) is a service spearheaded by Microsoft. In essence, UDDI refers to both a directory and a means of using information in that directory. There is the http://uddi.microsoft.com Web site where businesses are encouraged to register and share Web Services, and there is UDDI in the sense of the tools and capabilities that support finding and using Web Services. (There is even a UDDI SDK. New programmers are going to choke on acronyms.) The idea is that you can go out to uddi.microsoft.com and shop for Web Services by industry or business. What else it might mean, probably even Microsoft doesn't know yet. This is leading-edge stuff, and it is impossible to predict how far this technology will take us. Note I am not picking on Microsoft about UDDI. I think it's too new, and there are just too few Web Services yet for everyone to know what to build, whom to build Web Services for, and how to make money in this arena. Checking the Microsoft UDDI site in October 2001, I found a link to "A Beckmann Inn and Carriage House Bed and Breakfast ." Either the folks at Beckmann Inn are building leading Web Services or they were just happy to find a place to list themselves on a Microsoft site. So far, no actual Web Services appear to be available from the bed and breakfast.
I certainly don't want to suggest that this technology is so new that it is unstable. The opposite is true, in fact. Because the Web Services technology is based on HTTP, SOAP, and XMLbasically hypertextit is nearly perfect in its simplicity. Web Services are ready for prime time already. What is probably true, however, is that everyone will be caught off guard for a short period of time, and it may not settle in that new, powerful possibilities exist. Forget sharing and registering COM objects. Sure, this technology will exist for a while, but Web Services do not have to be downloaded. Web Services do not have to be installed, and there is no "DLL Hell" when it comes to Web Services. Web Services are reference-and-go solutions. uddi.microsoft.com In the previous section I related the story about the bed and breakfast. Ultimately, there will probably be thousands of Web Services at uddi.microsoft.com. Prior to the release of .NET, most of the registered companies seemed to be registry services, and actual Web Services were a little hard to find. The model I envision is that great Web Services will spread by word of mouth and e-mail, and developers will be told to use a specific Web Service or will probably recommend them to their bosses. Those Web Services that solve practical business problems will probably be the second wave of services. The first wave will probably be entertainment, travel, and pornography. (I'm not making this pattern up; it's historically the way the Web has progressed.) Slowly but surely, business will figure out how to use this technology to make money. Early adopters, like Scandinavian Airlines, already have Web Services, but it may be several more months before the average programmer is using Web Services as readily as we now use off-the-shelf components . Keep checking on uddi.microsoft.com for Web Services, and I encourage you to register your company and Web Services on the UDDI site when appropriate. Even if you don't think anyone would be interested, sharing Web Services will be important in the early phases of this new technology. (At least the Beckmann Inn thinks so.) Local Web Services You will have to install the .NET Framework and register your server with a directory service to share Web Services. The installation of the .NET Framework on mission-critical Web servers may be the biggest stumbling block to quick adoption and use of Web Services. However, you do not have to wait for your company to install the .NET Framework to build and test Web Services. Tip If you plan on building and testing Web Services on your PC, install IIS 5.0 before installing the .NET Framework.
All that is required to build and test Web Services is a PC, Windows 2000 or Windows XP, the .NET Framework, Visual Studio .NET, and IIS 5.0 or greater. IIS 5.0 comes with Windows 2000 and Windows XP. If you intend to build and test Web Services on your PC, you will be prompted to install IIS on your PC before the Windows Component Update part of the installation process occurs. (Even if you don't intend to build Web Services initially, you should install IIS. IIS is an excellent way to create team intranets , and you will ultimately want to work with Web Services.) By default, when you build Web Services on your PC, a project will be added to your local IIS directory. By default this directory is c:\inetpub\ wwwroot and the URL is localhost or IP 127.0.0.1. The IP 127.0.0.1 is the loopback IP address that is a computer's TCP/IP reference to itself. The loopback IP is in addition to the IP associated with your network interface card (NIC). Your NIC IP, localhost, 127.0.0.1, and your machine name all refer to the same physical box. If you are running IIS on your PC, any of these values will allow you to browse to the pages served by your PC. (By the way, running IIS and adding content is all you need to do to create an intranet site on your PC.) Four Facets of Web Services There are four facets to Web Services. These are directory, discovery, description, and wire format. The following list briefly describes each of the facets. -
The UDDI directory exists to aid in registering and locating Web Services. -
Discovery is supported by the . vsdisco files that are created as part of an ASP.NET and Web Service application. -
The description of Web Services is supported by the Web Services Description Language (WSDL, pronounced whiz-dul ). -
The wire format can be SOAP and XML, HTTP GET and HTTP POST, or a proprietary format like DCOM. You can specifically request the service description by invoking the Web Service with the ?WSDL query. For example, assuming a Web Service named service1.asmx on the localHost, the following query will return the service description: http://localhost/service1.asmx?WSDL Because Microsoft is using or trying to establish open standards, a lot of information is available regarding these various specifications. You can read more about the WSDL specification at http://www.w3.org/TR/wsdl/ and more about the SOAP specification at http://www.w3.org/TR/soap/. At this point we won't digress any further into these specifications. We will proceed with our discussion of using and implementing Web Services. If you need to know more about SOAP, UDDI, or WSDL (or any other protocols), you will have to do some independent exploration. | 
