Tài liệu Module 4: Consuming Web Service pdf

Contents
Overview 1
WSDL Documents 2
Web Service Discovery 9
Web Service Proxies 18
Implementing a Web Service Consumer
Using Visual Studio .NET 26
Lab 4: Implementing a Web Service
Consumer Using Visual Studio .NET 36
Review 45

Module 4: Consuming
Web Services



Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, places or events is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2001 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, Authenticode, Biztalk,
Intellisense, Jscript, MSDN, PowerPoint, Visual Basic, Visual C++, Visual C#, Visual Studio,
Win32, and Windows Media are either registered trademarks or trademarks of Microsoft
Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.


Module 4: Consuming Web Services iii


Instructor Notes
This module teaches students how to implement Web Service consumers using
Microsoft
®
Visual Studio
®
.NET Beta 2.
After completing this module, students will be able to:

!
Explain the structure of a Web Service Description Language (WSDL)
document.
!
Explain the Web Services Discovery process.
!
Locate service contracts by using Disco.exe.
!
Generate Web Service proxies by using Wsdl.exe.
!
Implement a Web Service consumer by using Visual Studio .NET.
!
Invoke a Web Service synchronously and asynchronously by using a Web
Service proxy.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the Microsoft PowerPoint
®
file 2524A_04.ppt.
Preparation Tasks
To prepare for this module:
!
Read all of the materials for this module.
!
Try the walkthroughs and demonstrations in this module.
!
Complete the lab.

Presentation:
120 Minutes

Lab:
75 Minutes
iv Module 4: Consuming Web Services


Module Strategy
Use the following strategy to present this module:
!
WSDL Documents
You should approach the topics in this section as a progressive development
of an example of a WSDL document. Explain the concepts in the first topic
with a simple Web Service that has only one operation that returns a class,
(the code is defined in the student notes). Progressively build upon this
example WSDL document when you explain each of the WSDL topics. The
intent of teaching WSDL syntax is not for students to write a WSDL
document from scratch on their own. The intent is for students to be able to
describe the structure of a WSDL document and explain how the definitions
in a WSDL document correspond to the code they will implement in a Web
Service.
!
Web Service Discovery
Explain that the problem focused on by this section is how to find WSDL
documents and the endpoints for Web Services that implement the
interfaces defined in the WSDL documents. For completeness, it is
important that you briefly describe Universal Description, Discovery, and
Integration (UDDI) as part of the solution, but defer any in-depth discussion

of UDDI until Module 6, “Publishing and Deploying Web Services,” in
Course 2524A, Developing XML Web Services Using Microsoft Visual C#
.NET Beta 2. Explain how Disco.exe can be used to generate local copies of
WSDL documents and other discovery documents.
!
Web Service Proxies
This section is intended to help students understand the benefits of
implementing proxies to Web Services. Remind the students about the lab
exercises in Module 3, “The Underlying Technologies of Web Services,” in
Course 2524A, Developing XML Web Services Using Microsoft Visual C#
.NET Beta 2, to emphasize how manual construction of Hypertext Transfer
Protocol (HTTP) and Simple Object Access Protocol (SOAP) messages is
tedious and error-prone. Point out that module 3 did not cover the steps
involved in decoding response messages. Explain that decoding response
messages is an essential functionality in a Web Service consumer. Explain
that this functionality can be encapsulated in a Web Service proxy. Discuss
the code that is generated for the proxies from a high level. Discuss the
properties of a proxy that can be configured. Do not spend too much time on
this discussion, because students will be learning about how to implement
Web Service consumers in the next section.
Module 4: Consuming Web Services v


!
Implementing a Web Service Consumer Using Visual Studio .NET
This section is intended to familiarize students with the steps required to
allow a managed application to consume a Web Service. Stress that the
steps outlined in this section do not apply to unmanaged applications.
Emphasize the similarity between the steps involved in implementing a Web
Service consumer that is a console application and a Web Service consumer

that is a Web Forms application. Also, discuss the importance of
asynchronous invocation of Web Service methods. Point out the similarity
between invoking Web Service methods asynchronously and issuing
asynchronous HTTP requests using the WebRequest class, which is
demonstrated in Module 3, “The Underlying Technologies of Web
Services,” in Course 2524A, Developing XML Web Services Using
Microsoft Visual C# .NET Beta 2.


Module 4: Consuming Web Services 1


Overview
!
WSDL Documents
!
Web Service Discovery
!
Web Service Proxies
!
Implementing a Web Service Consumer Using Visual
Studio .NET

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
To be able to consume (use) Web Services as well as develop them, you need to
know how to implement the consumer for a Web Service. Web Service

developers must understand how a Web Service will be consumed before
implementing it. Also, Web Service developers need to implement Web Service
consumers for test the Web Services that they implement.
In this module, you will learn how to implement Web Service consumers by
using Microsoft
®
Visual Studio
®
.NET.
After completing this module, you will be able to:
!
Explain the structure of a Web Service Description Language (WSDL)
document.
!
Explain the Web Services Discovery process.
!
Locate service contracts by using Disco.exe.
!
Generate Web Service proxies by using Wsdl.exe.
!
Implement a Web Service consumer by using Visual Studio .NET.
!
Invoke a Web Service synchronously and asynchronously by using a Web
Service proxy.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in

In this module, you will learn
how to implement Web
Service consumers by using
Microsoft Visual Studio
.NET.
2 Module 4: Consuming Web Services


WSDL Documents
!
What Is WSDL?
!
Structure of a WSDL Document
"
The types element
"
The message element
"
The portType element
"
The binding element
"
The service element

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
To be able to use or consume a Web Service, you first need to know how to

interact with it.
What Is WSDL?
Web Services Description Language (WSDL) is an XML grammar used for
describing a Web Service in terms of the messages it accepts and generates. In
other words, a WSDL file acts as a contract between a Web Service consumer
(client) and a Web Service.
In a WSDL document, you define the types used in the operations (methods) of
a Web Service, and the documents that are exchanged for each operation. Then,
you associate these definitions with a network protocol and group them into
messages to define an endpoint (the network location of a Web Service).
WSDL can describe endpoints and their operations without specifying the
message formats or the network protocols to which an endpoint is bound. The
only protocol bindings that are examined in this section are Simple Object
Access Protocol (SOAP) 1.1 and HTTP-GET/POST.
As a Web Service consumer, it is important that you are familiar with WSDL to
understand the contract defined in a WSDL document. Also, when you
implement a Web Service, you might not want to use an automatically
generated WSDL file. Instead, you might choose to generate the default WSDL
file and then modify it. Again, for this purpose you need to know WSDL.
Topic Objective
To explain the structure of
WSDL documents.
Lead-in
To be able to consume a
Web Service, you first need
to know how to interact
with it.
Module 4: Consuming Web Services 3

Structure of a WSDL Document
A WSDL document is just a list of definitions. In a WSDL file, the root element
is named definitions. This element contains five primary child elements used to
define the Web Service. The following five elements appear within the
definitions element in a WSDL file in the order specified:
!
The types element defines the various data types used to exchange
messages.
!
The message element describes the messages to be communicated.
!
The portType element identifies a set of operations and the messages
involved with each of those operations.
!
The binding element specifies the protocol details for various service
operations and describes how to map the abstract content of these messages
into a concrete format.
!
The service element groups a set of related ports together.

Let us examine the preceding elements by looking at how these elements can be
used in a WSDL file that describes the following Web Service:
[XmlRoot("account")]
public class Acct
{
[XmlElement("description")]
public string Description;
[XmlElement("number")]
public string Number;
[XmlElement("type")]

public string Type;
[XmlElement("balance")]
public decimal Balance;
[XmlAttribute("status")]
public string Status;
}


public class TheBank
{
[WebMethod]
public Acct GetAccount(string acctNumber)
{
Acct a = new Acct();
a.Description = "Adam's savings acct";
a.Balance=10000.0M;
a.Number="1234-XX";
a.Status="active";
a.Type="SV";
return a;
}
}

Let us look at how to define a WSDL document that describes the preceding
Web Service.
Delivery Tip
Explain the WSDL elements
to the students by walking
them through the sample
code provided in <install

folder>\Democode\Mod04\
WoodgroveBank.wsdl.
4 Module 4: Consuming Web Services


The types element
First you define the types used in the message exchange. This is mostly just a
matter of defining the types using XML Schema Definition Language (XSD).
The acctNumber parameter is defined as follows:
...
<types>
...
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"!
name="acctNumber" nillable="true"!
type="s:string" />
</s:sequence>
</s:complexType>
...
</types>

The type definition for the Acct class, which is returned by the GetAccount
method, is slightly more complex than the previous definition. The type
definition for this class can be as follows:
<s:complexType name="Acct">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"!
name="description" type="s:string" />
<s:element minOccurs="1" maxOccurs="1"!

name="number" type="s:string" />
<s:element minOccurs="1" maxOccurs="1"!
name="type" type="s:string" />
<s:element minOccurs="1" maxOccurs="1"!
name="balance" type="s:decimal" />
</s:sequence>
<s:attribute name="status" type="s:string" />
</s:complexType>

The preceding type definition describes the structure of the account element in
the following XML document:
<?xml version="1.0" encoding="utf-8"?>
<account status="active">
<description>Adam's savings acct</description>
<number>1234-XX</number>
<type>SV</type>
<balance>10000</balance>
</account>

Next, the structure of the messages that are to be exchanged is defined. In this
example, the method name is GetAccount and we use the following naming
convention:
!
The inbound message has the same name as the method.
!
The outbound message has the name of the method with the word Response
appended.

Module 4: Consuming Web Services 5

A possible way to define the message types is as follows:
<s:element name="GetAccount">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"!
name="acctNumber" nillable="true"!
type="s:string" />
<s:element minOccurs="1" maxOccurs="1"!
name="suffix" nillable="true" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetAccountResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"!
name="account" type="s0:Acct" />
</s:sequence>
</s:complexType>
</s:element>

All of these definitions are nested inside the types element.
The message element
In addition to defining the data types passed back and forth during a Web
Service method invocation, the Web Service request and response messages
must also be defined. Because messages are protocol independent, a message
can be used with HTTP-GET/POST, SOAP, or any other protocol that a Web
Service provider supports. If you use SOAP, the message element corresponds
to the payload of the SOAP request or response. It does not include the SOAP

Envelope or the SOAP Fault elements. You can give messages any convenient
name because WSDL does not define a naming convention for messages.
The message element contains zero or more part child elements. A part
element is similar to a parameter or a return value in a function call.
A request message contains all in and inout parameters; and a response
message contains all inout and out parameters, and the return value. Each part
element must have a name and data type that can be mapped to the data types
used in the underlying service implementation. To continue with the previous
example, the request and response messages can be defined as follows:
<message name="GetAccountIn">
<part name="parameters" element="s0:GetAccount" />
</message>
<message name="GetAccountOut">
<part name="parameters" element="s0:GetAccountResponse" />
</message>

In the preceding code, s0:GetAccount and s0:GetAccountResponse refer to
the top-level types defined in the types element.
6 Module 4: Consuming Web Services


The portType element
A Web Service provider (a network node, which is a Web Server) may expose
multiple Web Services. A single Web Service can support invocation of its
operations using a variety of protocols. The format of the data exchanged
between a Web Service consumer and a Web Service may depend on the
protocol used to invoke an operation or a method. Therefore, there must be a
way to map the operations to the endpoints from which they can be accessed, in
a protocol-independent manner. You can do this kind of mapping using the
portType element.

The following XML code shows the GetAccount operation and a portType
with which it is associated:
<portType name="BankService">
<operation name="GetAccount">
<input message="s0:GetAccountIn" />
<output message="s0:GetAccountOut" />
</operation>
</portType>

In the preceding code, notice that the input and output elements specify the
names of the request and response messages that are to be transmitted.
Module 4: Consuming Web Services 7


The binding element
After defining the logical port, next you define how a Web Service consumer
can bind to the port on which the GetAccount operation is available. This
involves associating a operation with a protocol and providing any protocol-
specific binding information. To do this, you use the binding element. The
following XML code shows the SOAP binding definition for the GetAccount
operation:
<binding name="BankService" type="s0:BankService">
<soap:binding transport =!
"
style="document" />
<operation name="GetAccount">
<soap:operation soapAction = !
"
style="document" />
<input>

<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>

The preceding example allows binding using SOAP. It provides information for
the SOAPAction header. It also specifies that the document-encoding style is
document and not rpc, and that the parameter-encoding style is literal and not
encoded. You can give the binding any convenient name.
To see some examples of bindings that use HTTP-GET and HTTP-POST and
examine the binding elements, see the file at:
http://localhost/Woodgrove/Bank.asmx?wsdl.
8 Module 4: Consuming Web Services


The service element
All that remains in creating a WSDL file is defining the endpoints for each of
the protocols that can be used to access a Web Service. To do this, you use the
service element.
The following XML code defines a bank service and specifies the ports that can
be used to access the operations of the service:
<service name="BankService">
<port name="BankService" binding="s0:BankService">
<soap:address location =!
"
/>
</port>

</service>

In the preceding code, the binding attribute of the port element specifies the
name of the binding element that is to be used, in this example,
s0:BankService. Also, notice that the endpoint location is specified as a child
element of the port element.

The complete code for the preceding WSDL file is available in
<install folder>\Democode\Mod04\WoodgroveBank.wsdl.

If a Web Service can be accessed using multiple protocols, then a WSDL
document for the Web Service will contain multiple port elements, each
referring to a protocol-specific binding element by name. Also, each of the
protocol-specific binding elements will in turn refer to protocol-specific
portType elements. The protocol-specific portType elements will in turn refer
to protocol-specific sets of input and output message elements, which in turn
refer to types defined in the types element.
Note
Module 4: Consuming Web Services 9


#
##
#

Web Service Discovery
!
Introducing Disco
!
Locating Discovery Documents Using Disco.exe

!
Demonstration: Locating Discovery Documents Using
Disco.exe
!
Programmatic Discovery

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
In the previous topic, you saw how to write WSDL documents. Because a
WSDL document specifies the format of the messages that are exchanged by a
Web Service and its consumers, you must implement the consumer according to
the WSDL document of a Web Service that you want to consume. If you do not
already have the WSDL document, you must be able to locate it.
The process by which you locate a Web Service and its descriptions and learn
how to interact with it is known as Web Service discovery.
In this section, you will learn how to locate the WSDL documents at a known
endpoint. For more information about how to locate a Web Service whose
endpoints are unknown, see Module 6, “Publishing and Deploying Web
Services,” in Course 2524A, Developing XML Web Services Using Microsoft
Visual C# .NET Beta 2.
Topic Objective
To introduce the topics in
this section.
Lead-in
You need a WSDL
document for the Web
Service to implement its

consumer. If you do not
have the WSDL document
then you need to be able to
locate it.
10 Module 4: Consuming Web Services


Introducing Disco
!
What Is Disco?
!
Static Discovery
!
Dynamic Discovery

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
It is unlikely that a Web Service provider would publish the service descriptions
of all the Web Services through a Web Service broker. Therefore the service
descriptions must be discoverable by Web Service consumer developers.
What Is Disco?
Disco is a mechanism for enumerating the Web Services available at a
particular endpoint and locating the service contracts for the enumerated Web
Services.
At the time of this writing, Disco has not been submitted to the World Wide
Web Consortium (W3C) and therefore it should be considered only as a
possible solution to the problem of discovering Web Services and Web Service

contracts.

A Web server that provides access to a Web Service is not required to
support discovery. Either another server can be responsible for providing the
service contracts, or a Web Service has been created for only private use with
no public mechanism for discovery.

A Web Service provider can make discovery information available to Web
Service consumer developers. It can do this by either statically or dynamically
generating a document that contains a link to the WSDL document for all the
Web Services hosted by the provider.
Topic Objective
To explain Disco and the
two kinds of discovery
possible in Disco.
Lead-in
It is unlikely that a Web
Service provider would
publish the service
descriptions of all the Web
Services through a Web
Service broker.
Note
Module 4: Consuming Web Services 11


Static Discovery
Static discovery is possible when the location of a discovery document (usually
with the extension .disco) is already known. Static discovery involves retrieving
the discovery document and interpreting its contents. The following code is an

example of a discovery document:
<?xml version="1.0"?>
<discovery xmlns:xsi="
XMLSchema-instance"
xmlns:xsd="
xmlns="
<discoveryRef ref="
AccountMgmt.disco"/>
<contractRef ref="
AcctMgmt.asmx?wsdl"
docRef="
AcctMgmt.asmx"!
xmlns="
</discovery>

The two main elements of a discovery document are:
!
discoveryRef, which specifies the location of additional discovery
documents.
!
contractRef, which specifies the location of Web Service contracts.
The contractRef element can also optionally specify the location of a
document that provides the documentation for a Web Service.

In a discovery document, the URLs that specify the various document locations
can be absolute or relative. If the URLs are relative, then the locations are
assumed to be relative to the location of the discovery document.
The root discovery document along with all the referenced discovery
documents make up the catalog of Web Services available at the endpoint that
is interrogated. This catalog is effectively static.

Dynamic Discovery
Dynamic discovery takes place when all that is known to the consumer is the
endpoint of the Web Service provider. In this situation, there is no static list of
.disco files at the endpoint. Instead the list of available Web Services and the
associated service contracts must be dynamically generated.
Delivery Tip
Explain the code in the
following .disco file:
<install
folder>\Democode\Mod04\
Example.disco.
12 Module 4: Consuming Web Services


For Web Services implemented using the Microsoft .NET Framework and
deployed with Internet Information Server (IIS), enabling dynamic discovery is
a fairly simple task. A file named Default.vsdisco is placed at the root of the
Web site that hosts a Web Service. The following code is an example of a
.vsdisco file:
<?xml version="1.0" ?>
<dynamicDiscovery xmlns="urn:schemas-
dynamicdiscovery:disco.2000-03-17">
<exclude path="_vti_cnf" />
<exclude path="_vti_pvt" />
<exclude path="_vti_log" />
<exclude path="_vti_script" />
<exclude path="_vti_txt" />
</dynamicDiscovery>

The preceding document contains a list of sub folders to be excluded in the

search for discovery documents.
During dynamic discovery, the root of a Web site and all of its virtual
directories and sub folders (except the excluded sub folders) are searched for
discovery documents, .NET assemblies, or both. If an assembly is found,
reflection used to determine if the assembly contains a class with the
WebMethod attribute applied to any of its methods. If such a class is found,
discovery information is generated for this Web Service.

Reflection is a mechanism that allows you to dynamically create an
instance of a type, obtain information about a type, invoke the methods of a
type, and access the fields and properties of an instance of a type.

When a WSDL document is requested, the dynamic discovery infrastructure
reflects on the assemblies that contain the Web Service, to extract a list of
operations (which are the methods with the WebMethod attribute) and generate
messages and ports for each operation. Also, depending on the datatypes used
in a method, the dynamic discovery infrastructure can generate type definitions
and bindings for SOAP, and HTTP for the GET and POST methods.
Therefore, a complete WSDL document can be dynamically generated using
reflection.
Also, you can use static discovery documents in dynamic discovery by
renaming .disco files to have the .vsdisco extension and they will be correctly
processed by the dynamic discovery infrastructure.

A static discovery document usually has the extension .disco and a
dynamic discovery document has the extension .vsdisco.

Delivery Tip
Explain the code in the
following .disco file:

<install
folder>\Democode\Mod04\
Example.vsdisco.
Note
Note
Module 4: Consuming Web Services 13


Locating Discovery Documents Using Disco.exe
!
Syntax
!
Uses
"
Example
disco [options] URL
disco [options] URL
disco /out:d:\disco /u:administrator /p:biffle !
/>disco /out:d:\disco /u:administrator /p:biffle !
/>
*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
Disco.exe, the Microsoft Web Services discovery tool in the .NET Framework,
can be used to discover the endpoints of Web Services and save the documents
related to each of the Web Services on a local disk.
The syntax of the command to search for discovery documents (files with the
following extensions: .wsdl, .xsd, .disco, .vsdisco, .discomap) at a given URL is

as follows:
disco [options] URL

The options for the URL argument supported by the disco command are
described in the following table.
Option Description

/d[omain]:domain Specifies the domain name to use when
connecting to a server that requires a
domain name for authentication.
/out:directoryName Specifies the output directory in which to
save the discovered documents. The
default is the current directory.
/u[sername]:username Specifies the username to use when
connecting to a server that requires
authentication.
/p[assword]:password Specifies the password to use when
connecting to a server that requires
authentication.

Topic Objective
To explain how to locate
discovery documents by
using Disco.exe.
Lead-in
Disco.exe is the Microsoft
Web Services discovery
tool.
Syntax
14 Module 4: Consuming Web Services

Uses
The primary use of Disco.exe is to generate local copies of service contract
documents (.wsdl documents) and static discovery documents (.disco
documents). The tool also produces a file named results.discomap. This file can
be used as the input to the Wsdl.exe, which you will examine later in this
module.
The Disco tool displays an error message if it cannot find discoverable
resources at the preceding URL.
The following example shows how to use Disco.exe to search a URL for
discovery documents and save them to a local folder:
disco /out:d:\disco /u:administrator /p:biffle!


In the preceding example, the username and password are supplied to allow the
tool to connect to a server that requires authentication.
Module 4: Consuming Web Services 15


Demonstration: Locating Discovery Documents Using Disco.exe

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
In this demonstration, you will see how to locate discovery documents for a
Web Service by using Disco.exe.
Topic Objective

To demonstrate how to
locate discovery documents
using Disco.exe.
Lead-in
In this demonstration, you
will see how to locate
discovery documents for a
Web Service by using
Disco.exe.
Delivery Tip
1. To open Visual Studio
.NET command prompt,
click Start, point to
Programs, point to open
Microsoft Visual
Studio.NET 7.0, point to
Visual Studio.NET Tools,
and click Visual
Studio.NET Command
Prompt.
2. From the command
prompt, run the following
command:
disco http://localhost/
woodgrove/bank.asmx
3. In Notepad, open the file
Bank.disco that was created
in the current folder.
4. Explain the contents of
Bank.disco.

16 Module 4: Consuming Web Services


Programmatic Discovery
!
The System.Web.Services.Discovery Namespace
!
An Example

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
All of the discovery functionality of Disco.exe is available programmatically
through the classes in the .NET Framework.
The System.Web.Services.Discovery Namespace
The System.Web.Services.Discovery namespace in the .NET Framework
contains a set of classes that model the elements of a discovery document. This
namespace also contains classes that can be used to manipulate discovery
documents.
An Example
The following example code simulates the behavior of Disco.exe:
using System.Web.Services.Discovery;

class DiscoverDemo
{
static void Main(string[] args)
{
GenerateDiscovery(@"!

/catalog.disco",@"d:\disco",true);
}

public static void GenerateDiscovery(string sourceUri,!
string outputDirectory,!
bool printToConsole)
{
string outputPath;
outputPath = Path.Combine(outputDirectory,!
"results.discomap");

Topic Objective
To explain how the classes
in the System.Web.
Services.Discovery
namespace can be used to
perform discovery.
Lead-in
All of the discovery
functionality of Disco.exe is
available programmatically
through the classes in the
.NET Framework.
Module 4: Consuming Web Services 17


DiscoveryClientProtocol client;
client = new DiscoveryClientProtocol();
FileInfo fi = new FileInfo(outputPath);
if (fi.Exists)

client.ReadAll(outputPath);

DiscoveryDocument doc = client.DiscoverAny(sourceUri);
client.ResolveAll();


foreach (DictionaryEntry entry in client.Documents)
Console.WriteLine((string) entry.Key);

DiscoveryClientResultCollection results;
results = client.WriteAll(outputDirectory,!
"results.discomap");
foreach (DiscoveryClientResult res in results)
{
Console.WriteLine(res.Filename + " <- " + res.Url);
}
}


An in-depth discussion of the System.Web.Services.Discovery
namespace is beyond the scope of this course. For complete information about
using the System.Web.Services.Discovery namespace, refer to the .NET
Framework SDK documentation.

Note
18 Module 4: Consuming Web Services


#
##

#

Web Service Proxies
!
Proxies and WSDL
!
Generating Proxies Using Wsdl.exe
!
Configuring Proxies

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
A Web Service consumer must be able to construct the messages that are to be
sent to a Web Service, and parse the messages that are received from a Web
Service. Manually writing the code to construct and parse the messages is time-
consuming and error-prone. It is better to encapsulate this code in a class that
can be reused. We call such a class a proxy class. In this section, you will see
how to generate proxy classes using Wsdl.exe and WSDL documents.
Topic Objective
To introduce the topics in
this section.
Lead-in
A Web Service consumer
must essentially be able to
construct the messages that
are to be sent to a Web
Service, and parse the

messages that are received
from a Web Service.
Module 4: Consuming Web Services 19


Proxies and WSDL
!
Why Are Proxies Needed?
!
Using WSDL to Generate Proxies

*****************************
ILLEGAL FOR NON
-
TRAINER USE
******************************
Proxies are entities that act as intermediaries for other entities. For the purpose
of our discussion, proxies can be considered as objects that expose the same
logical interface to a Web Service consumer as a Web Service.
Why Are Proxies Needed?
Module 3, “The Underlying Technologies of Web Services,” in Course 2524A,
Developing XML Web Services Using Microsoft Visual C# .NET Beta 2
explains interacting with a Web Service by manually constructing the messages
and sending them to a Web Service. However, manual construction of messages
is not an optimal solution.
Also, developers prefer to work with strongly-typed abstractions that model the
logical interface of an entity with which they are interacting. They do not want
to and should not have to manually process text documents that are exchanged
during the invocation of a Web Service method.
Proxies eliminate the preceding problems by providing a strongly-typed

interface that maps to the operations exposed by a Web Service, and by hiding
the construction and parsing details within its implementation.
Topic Objective
To explain proxies and how
WSDL documents are used
in generating proxies.
Lead-in
Proxies are entities that act
as intermediaries for other
entities.