[an error occurred while processing this directive]
Issue dated - 18th August 2003


Previous Issues



Symantec Report
Security Headquarters

 Network Sites
  IT People
  Network Magazine
  Business Traveller
  Exp. Hotelier & Caterer
  Exp. Travel & Tourism
  Exp. Pharma Pulse
  Exp. Healthcare Mgmt.
  Express Textile
 Group Sites
  Indian Express
  Financial Express

Front Page > TechSpace > Story Print this Page|  Email this page

ASP.NET Web Services - II

The C# Column - Yashawant Kanetkar

In the last article we explored the distributed computing architecture, the different solutions for it, along with their pros and cons, and the reasons why Web services came into existence. In this article we will explore more issues regarding Web services.


The only requirement of Web services is that both the communicating parties should have SOAP (Simple Object Access Protocol) servers. SOAP is built upon HTTP and uses XML. It describes function calls and their parameters using XML. The .NET Web services use this protocol for transfer of data. A Web service is a piece of code that resides on the Internet server. This code can accept requests from clients using HTTP and XML. Once a Web service is put on the Internet it can be consumed or used by any client across the Internet that uses HTTP and XML.

We can use a Web service already available on the Net. For example, a bookstore can have a Web service that takes an ISBN number of a book and returns all the details of the book to the user. This Web service can be used by many sites, which provide information related to books. Apart from being generalised, the main advantage of using the SOAP protocol is that SOAP can support a rich set of data types including the primitive data types, enums, classes, structs, ADO.NET data sets and arrays of these types.

I must note here that the Web services can be built in any .NET compliant language like VB.NET, C# or Managed C++.

XML Web services are based on open Web standards that are broadly supported and are used for communication and data formats. XML Web services provide the ability to expose application logic as URI-addressable resources, available to any client in a platform-independent way. Web services are self-describing. Any clients incorporating open Web standards for communication and data formatting (HTTP and XML) can query dynamically for Web service information and retrieve an XML document describing the location and interfaces supported by a particular XML Web service. These open standards make Web services indifferent to the operating system, object model, and programming language used. Web services are accessible to disparate systems, supporting application interoperability to an unprecedented level thanks to the ubiquity of HTTP and XML.

Because XML-based messaging is used for the data interchange, a high level of abstraction exists between a Web service implementation and the client. This frees the client from needing to know anything about a Web service except for its location, method signatures, and return values. Additionally, most Web services are exposed and accessed via HTTP, virtually eliminating firewall issues.


Web services are discovered using UDDI (Universal Description Discovery and Integration). We will look at UDDI in more detail later in the article. Any client can use a Web service. Hence, when we create Web services we must provide the information that programmers need to know. For example, we must provide information about the methods available, types of parameters and return values of methods, ways of calling these methods, how the Web service should be used, etc. This information is available through a WSDL file standing for Web service Definition Language. This file contains XML schema that describes the Web service.

Benefits of Web services

One of the benefits of using Web services is that we have a broader reach. No matter what the infrastructure is, if the object is exposed as a Web service communication becomes easier.

Another benefit is that even within enterprises the objects can be exposed as Web services. Web services hence facilitate Business to Business (B2B) communication and Enterprise Application Integration.

How to use Web services

Web services are deployed on Web servers. Once a Web service is put on the Web any client that understands HTTP and XML can use it. Here we have used an example of the IIS Web Server. The IIS has a built-in SOAP server. IIS listens for client requests on port 80. The WSDL file can also be kept on the same Web server.

The client that wants to use the Web service adds the link to the WSDL file in VS.NET IDE. VS.NET then creates a proxy, which contains the methods with same name as those that were exposed by the Web service. These methods contain logic to convert the data passed by the client to a SOAP request. The client calls methods in the proxy class. The proxy creates a SOAP envelope and sends it to IIS. When IIS detects that it is a SOAP message, IIS passes the message to the SOAP server, which in turn invokes methods in the Web service. The return values trace the path back from the server, get converted into SOAP and are sent to the proxy and finally to the client.

Like any other resources on the Internet, it would be virtually impossible to find a particular Web service without some means to search for it. Web service directories provide central locations where Web service providers can publish information about their Web services. Such directories can be accessed directly or programmatically, which provide search results in response to queries from potential Web service clients. The UDDI is such a location that defines a standard way to publish and discover information about Web services. Using the browser we make a request to search for the Web service. The UDDI responds with listing of the services. The list of services contains URIs of either discovery documents or WSDL documents.

If we get this we can get the WSDL file and then the client creates a proxy object based on the details provided by the WSDL. Once we have the proxy object we can call the methods of the Web service.

Creating a Web service

After understanding the need of Web services, how they evolved and how they make communication possible between heterogeneous systems, let us now see how to build and consume a Web service. We will build a simple Web service that exposes two methods. One method would convert temperature in Celsius to Fahrenheit. Another method would convert temperature in Fahrenheit to Celsius. The steps to create the Web service are given below:

(a) Open Visual Studio.NET IDE. Select ‘File | New | Project | Visual C# Projects’. Select ‘ASP.NET Web Service’ as the project template. Provide the project name as ‘webservice’ and click OK. The location of this project would be the ‘C:\ Inetpub\ wwwroot’ folder. The ‘Inetpub’ folder is present on the local drive if IIS is installed.

(b) A form gets displayed. Right-click on it and select ‘View Code’. You will see a commented HelloWorld( ) method as shown below:

//public string HelloWorld( )
// return "Hello World" ;

Uncomment the code and execute the program by pressing Ctrl + F5. You will see the output in IE, as shown in the following screen shot.

Here, HelloWorld is a Web service. The attribute [WebMethod] enables the method for being called by clients through the network.

We will add our Web methods and create a Winform client next time.

Yashavant Kanetkar, one of the first Express Computer columnists, is an established software expert, speaker and author with several best-sellers to his credit, including titles like “Let Us C” and the “Fundas” series. Contact him at kanet@nagpur.dot.net.in
<Back to top>

© Copyright 2003: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in
Mumbai by The Business Publications Division of the Indian Express Group of Newspapers.
Please contact our Webmaster for any queries on this site.