|
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.
SOAP
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.
UDDI & WSDL
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:
//[WebMethod]
//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 |
|