C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

Visual Studio automatically creates a DISCO file when you create a Web service project. This file has an extension of .vsdisco and is stored in the main application virtual directory (along with the ASMX file). This file contains links to the resources that describe the Web service.

Note

If you are not using Visual Studio to create your Web service (or find them), you need to manually create the DISCO document. In this case, you must create an XML file containing DISCO elements that can be used to find your Web service description documents. The following is a sample DISCO document for our CTemp Web service:

<?xml version="1.0" ?>

<disco:discovery xmlns:disco="http://schemas.xmlsoap.

org/disco/">

xmlns:scl="http://schemas.xmlsoap.

org/disco/scl">

<scl:contractRef ref="http://jdc7200cte/Services/

CTemp/CTemp.asmx?WSDL"/>

<disco:discoveryRef ref="SomeFolder/default.disco" />

</disco:discovery>

The DISCO document consists of a discovery element that serves as a container for contractRef and discoveryRef elements. You can specify as many contractRef and discoveryRef elements as you desire. This makes it possible to provide information for more than one Web service from within a single DISCO document.

The contractRef element is used to provide a pointer to the WSDL document that describes the message formats and exchanges supported by the Web service. In the preceding example, you can see that a single contractRef element has been included that provides a pointer to the WSDL document for the CTemp Web service. The contractRef element is optional.

References specified by the ref attribute can be absolute or relative. If you specify a relative reference, the reference is relative to the folder in which the DISCO document resides.

The discoveryRef element is used to provide a pointer to other DISCO documents. This allows you to logically link the discovery process to several Web services, which may have independent DISCO documents. In the preceding example, a single discoveryRef element has been included that provides a pointer to another DISCO document. The discoveryRef element is optional.

Because a DISCO document simply contains pointers to the resources that describe a Web service, you can physically deploy your DISCO documents anywhere you want (in other words, they don't have to be physically deployed with the Web services that they describe). This provides you with the capability to enable discovery of any set of Web services that may be physically distributed on your network, but allow users to browse to a single point at which to begin the discovery process to find them.

To make it easier for consumers to find your Web service, you can create a DISCO file in the root directory of your Web server named Default.disco, which then links to the various Web service DISCO files that you have implemented. That way, a consumer can simply browse to the root directory of the server to begin the discovery process using tools such as disco.exe.

the Already Registered tab at the top of the home page. Alternatively, you can go directly to the page by typing http://www.uddi.org/alreadyregistered.html in the Address bar of your browser.

In either case, you will next be asked to choose which registry you wish to use to add or update your information. As of the writing of this book, IBM and Microsoft were both maintaining UDDI business registry sites. The examples presented here will use the Microsoft site, but you could just as easily use the IBM site with the exact same results.

Note Although there are multiple distributed registries (and more expected to come online), the UDDI architecture uses replication techniques to keep all the registries synchronized. Therefore, you don't have to worry about which online registry you use to search or maintain your business information.

If you have not yet registered your business, you will be required to obtain a username/password before adding any information to the UDDI business registry. This is necessary so that your particular business information can be protected from any unauthorized changes. Although the specific methods for obtaining a username and password differ between the IBM and Microsoft sites, the end result is the same. In the case of Microsoft, you will be asked to create a Passport account. If you already have a Passport account, you can choose to use that account instead of creating another one.

Go ahead and choose Microsoft from the list and submit the form. You will then be requested to log in to the site using your username and password. If you don't have a username and password yet, create one and then log in.

After you have successfully logged in to the site, you will see the personal registration page, similar to Figure 26-2.

Figure 26-2: UDDI Web site personal registration page

Fill in your personal contact information here. This information is used for private registration purposes so that you can add and update entries in the business registry database, and it is not published within the public business registry database.

After you have filled in your personal information and submitted the form, you are now ready to review and accept the terms and conditions of use for the site. Confirm your acceptance of the terms and conditions. After you have done so, a confirmation page is displayed. Everything up to now has been part of a one-time process that you should not

1. Scroll the browser window to the Services section within the business details page. This is where all of your published Web services reside in the business registry.

2. Click the Add A Service link. Specify the name of your Web service and provide a brief description, as shown in Figure 26-4.

Figure 26-4: UDDI Service Registration page

3. After you have entered this information and clicked the Continue button, you are ready to add the appropriate classification categories for your service as well as the bindings that your service supports (see Figure 26-5).

Figure 26-5: UDDI service classification and bindings page

Although not visible in this figure, the classifications are similar to those that you specified when you registered your company information. This helps potential consumers more easily locate Web services based on these classifications. We won't go through the classification process here, but you should consider using classifications so that it is easier for consumers to find your Web services.

Defining a new binding

Let's define a new binding for our Web service publication. To do this, complete the following steps:

1. Click the Define New Binding link in the Bindings section of the page. This displays the Binding Detail page, shown in Figure 26-6.

Figure 26-6: UDDI Binding Detail page

2.In the Access Point text box, enter the URL to your Web service entry point (ASMX) file. In this example, you can see the pseudo-URL for the CTemp Web service.

3.Select HTTP as the URL type from the drop-down list. In the

Description text box, enter a description for the binding. Typically, you will want to mention the protocol details for the entry point you specified. For ASP.NET Web Services (which is what you build using Visual Studio or the .NET Framework), you should specify HTTP and SOAP. Note the description that was specified for the CTemp Web service.

4. After you have finished entering this information, click the Continue button. This will return you to the Service Detail page. Click the Continue button on this page and you will be returned to the Business Detail page, where you can further administer your business information.

Note You may find it easier to supply the appropriate information for your business and Web services by first examining business registry information from other companies such as Microsoft and IBM.

That, in a nutshell, is the basic process for getting your Web services published via UDDI. You can learn a lot more about UDDI by visiting the UDDI Web site and browsing the existing registry as well as the available help information. The information you can glean from the examples will be quite useful to you in creating the necessary information that will make it easier for consumers to find your Web services.

Internal publication tools

Before we wrap up our discussion of Web service deployment and publication (which has focused on making your Web services visible to the outside world), let's spend a few moments to discuss using these tools for internal (intranet) publication.

If you are a developer in a small to medium-sized business that has a relatively small network with few developers and Web servers, you may find that discovery through DISCO is a sufficient mechanism for publishing your Web services on an intranet. Larger companies that are physically distributed and have large, possibly diverse developer groups may consider implementing their own internal UDDI registry just for companyspecific Web services. At any rate, a great deal of flexibility is offered by these tools to structure the discovery process in a manner that is the most efficient for your specific needs.

Summary

In this chapter, you learned how to deploy a Web service using simple file-copying techniques (such as XCOPY) and received a short introduction to the built-in support provided by Visual Studio. In addition, this chapter covered how to publish a Web service so that potential consumers can locate the service via DISCO and/or UDDI.

You will learn more about the discovery process from a Web service consumer's perspective when we discuss this topic in Chapter 28, "Consuming Web Services."

Chapter 27: Finding Web Services

Overview

Previous chapters discussed the tools used to publish Web services from the perspective of a Web service author. This chapter examines the tools used to find Web services from the perspective of a Web service consumer. This process includes locating where a Web service resides, as well as interrogating the WSDL document to determine how to interact with the Web service. This chapter examines the tools in the Microsoft

.NET Framework that can be used to locate Web services.

Web Service Discovery

In previous chapters, we have discussed the tools used to publish Web services from the perspective of a Web service author. In this chapter, we will examine the tools used to find Web services from the perspective of a Web service consumer.

As you have learned in the chapter on Web service deployment and publishing, several methods are available for a consumer to locate a Web service. Visual Studio combines these methods into a single tool via the Add Web Reference feature. When using the

.NET tools for locating Web services, the tool you use depends on how much you know about the location of the Web service before you start. We will examine how to use each of these tools in this chapter.

If you have been provided with (or already know) the URL of a Web server where one or more Web services are deployed, you can locate these Web services using a discovery tool (if Web service discovery has been enabled by placing one or more discovery documents on the Web server). The .NET Framework provides a command-line tool named Disco.exe that can be used to locate discovery documents against a specified URL.

In cases where you do not know anything about where a Web service is located (or even if it exists), you will need the services of Universal Description, Discovery, and Integration (UDDI). This technology is essentially a universal search engine for Web services that is available via the Internet as both an interactive Web site and a set of programmable Web services.

UDDI consists of two parts:

§An XML-based schema that describes attributes of businesses, including basic demographic information, as well as specialized information related to industry affiliations, types of goods or services provided, and other taxonomies.

§A Web-based distributed database consisting of multiple, synchronized nodes that can be accessed via a Web browser, as well as programmable Web services.