|
Working with Web Services in .NET
A web service is a platform–independent software component that contains a group of functions that are packaged together for use in a common framework throughout a
network. Web services are based on the Simple Object Access Protocol or SOAP. This article discusses Web Services and their implementation in .NET.
Note: This article was originally published on AspAlliance.
By: Joydip Kanjilal
Date: November 5, 2007
<%--
--%><%--
Printer Friendly Version--%>
What Are Web Services?
According to MSDN, "Web Services are based on a core set of standards that describe the syntax and semantics of software communication: XML provides the common
syntax for representing data; the Simple Object Access Protocol (SOAP) provides the semantics for data exchange; and the Web Services Description Language
(WSDL) provides a mechanism to describe the capabilities of a Web service." Web services are based on the SOAP protocol for exchange of data in heterogeneous
environments.
What is SOAP?
It should be noted that as SOAP is a XML-based protocol; and as it is a text based, XML based protocol, it allows data exchange even through the firewalls. As Web
Services rely on SOAP to provide its services to its consumers via HTTP protocol, a XML Web Service can be consumed by any application irrespective of its
architecture. SOAP has been officially defined by the W3C group (http://www.w3.org/TR/SOAP) as a protocol that
"provides a simple and lightweight mechanism for exchanging structured and strongly-typed data between peers in a decentralized, distributed environment using
XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism
for expressing application semantics by providing a modular packaging model and mechanisms for encoding application defined data. This allows SOAP to be used for a
large variety of purposes ranging from messaging systems to Remote Procedure Call (RPC) invocations."
A SOAP message is composed of:
- An envelope that defines a framework for describing what is in a message and how to process it
- A set of rules for how to handle different data types
- A convention for representing remote procedure calls
The following is an empty SOAP message that has a root envelope element and its two child elements, header and body:
Listing 1
<Envelope>
<Header>
This is the optional part of a SOAP message that
contains the information on what the message contains and how it can be
processed
</Header>
<Body>
This is a mandatory part of the SOAP message
and contains data in XML format that is needed to access the interfaces of a
specific object
</Body>
</Envelope>
Please refer to my article An Introduction to Simple Object Access Protocol for more information on the SOAP protocol.
Web Service Description Language (WSDL)
Web Service Description Language, an XML based standard for describing Web services, is used for locating a Web service regardless of the underlying protocol that
is being used. WSDL has been defined by W3C as "an XML format for describing network services as a set of endpoints operating on messages containing either
document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and
message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of
endpoints and their messages regardless of what message formats or network protocols are used to communicate." Learn more on WSDL at
Using WSDL in SOAP applications.
A typical WSDL document describes the type description, message description, port type, service description and the binding specification details. The following
sample shows the structure of an empty WSDL document.
Listing 2
<definitions>
<types>
definition of types
</types>
<message>
definition of messages
</message>
<portType>
definition of ports
</portType>
<binding>
definition of bindings
</binding>
</definitions> Universal Description, Discovery and Integration (UDDI)
The Universal Description, Discovery and Integration (UDDI) protocol is a platform-independent,
open framework that enables companies and applications to dynamically discover and use Web services over the Internet. It is a "Web-based distributed directory
that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book's yellow and white pages." You will
find more information about UDDI at http://www.uddi.org/.
Implementing a Web Service in .NET
The three major components that make up a Web Service are as follows.
- A Web Service that runs on the Web Server
- A Client application that invokes the Web Service
- A WSDL document that describes the Web Service and specifies how to discover the Web Service
Web Services can be implemented in .NET in a couple of ways. We can have self contained services that use a single .ASMX page containing both the Web Service header
and the source code for the Web Service. The second way is to have a Web Service header separately and reference a Web Service class externally. The following code
sample shows how the former can be implemented.
Listing 3
<%@ WebService Language="C#" Class="TestWebService" %>
using System;
using System.Web;
using System.Web.Services;
public class TestWebService
{
[WebMethod]
public string Display()
{
return "This is a Web Method";
}
}
Note the header at the top of the code in the listing above; it specifies the name of the class and the language to be used. The following code snippet shows how we
can implement the later approach, i.e., the Web Service class is referenced externally here.
Listing 4
<%@ WebService Language="c#"
Codebehind="TestWebService.asmx.cs" Class="AspAlliance.TestWebService" %>
To test the Web Service, navigate to http://localhost/TestWebService/Service.asmx.
To access this Web Service from a Client application, add the Web Service as a web reference to the Client Application and call its methods as shown below.
Listing 5
Service s = new Service();
MessageBox.Show(s.Display()); Web Services and .NET Remoting
This section highlights some of the major differences between Web Services and .NET's Remoting technology. Web Services are interoperable, i.e., they enable cross
platform integration. This means they can run in heterogeneous environments. They can be used for exchange of data independent of platform or language. In contrast,
.NET Remoting can only run in homogenous environments. It requires that both the Server and the Client should be .NET and, hence, have the .NET Framework installed
in them. However, Web Services can be invoked only over HTTP while Remoting can be used across any protocol. Web Services are stateless while we can have support for
state management using Remoting.
References
Web Services and the Microsoft Platform (MSDN)
Web Services Description Language (WSDL) 1.1
A Web Services Primer
A Busy Developers Guide to WSDL 1.1
Conclusion
Web Services are Open Standard Enterprise Web Applications that are based on the SOAP protocol and are used for exchange of data efficiently on the same or disparate
systems irrespective of the architecture. This article has discussed Web Services, their benefits, the differences between Web Services and .NET Remoting and
illustrated how we can implement a simple Web Service in .NET. I hope that the readers who are new to this technology will find this article useful.
|