Published:
15 Jan 2007
|
Abstract
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 |
|
by Joydip Kanjilal
Feedback
|
Average Rating:
Views (Total / Last 10 Days):
41477/
48
|
|
|
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 |
|
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.
|
|
|
User Comments
No comments posted yet.
|
Product Spotlight
|
|