Reviewing the Role of XML Web Services
Interfaces in and of themselves simply define a strongly typed contract. They do not provide any details
regarding how to communicate with the implementing type. For example, interfaces do not specify which
protocol (TCP, HTTP, and so forth) should be used to invoke their members.
In a distributed system, the choice of protocol can be a very important design decision. Some protocols will
tie you to a specific programming framework such DCOM, JAVA EE, or .NET. Other protocols are only
appropriate when you can ensure all networked computers use the same operating system. Still other
protocols (such as HTTP) allow diverse operating systems and programming platforms to exchange data at
the expense of performance.
XML web services are an attempt to enable data exchange in a language-, platform-, and OS-neutral manner.
Rather than using a proprietary wire protocol to move across machine boundaries (DCOM, Java RPC, and so
on), communication occurs using standard HTTP. Rather than expressing data using platform-specific data
types (CTS, Java’s type system, COM types, and the like), web services encode all parameters / return
values as streams of loosely typed XML.
Also, SOAP provides a standard XML-based message format to represent a method call and its response.
Most XML web services make use of SOAP to allow callers to invoke remote methods in a neutral manner.
SOAP messages can also provide other details such as security and attachments.
By using industry standards such as HTTP / XML / SOAP, it is much easier to build enterprise-ready
systems. Thus, regardless of which platform you use to build an XML web service (.NET or JAVA EE),
callers can exchange data in a neutral fashion.
XML Web Services under the .NET Platform
The .NET platform makes it very simple to build XML web services. Each method you wish to expose via
HTTP is marked with the [WebMethod] attribute. You may optionally extend the System.Web.Services.
WebService base class to inherit functionality to build a stateful web service. If your web service does not
require state, you can simply derive from System.Object.
The ASP.NET runtime will automatically encode incoming and outbound data as XML. Additional attributes
can be applied on custom data types returned from an XML web service. These attributes are part of the
System.Xml.Serialization namespace and control the format of the generated XML.
.NET web services are little more than classes with ‘web methods’ hosted within an IIS virtual directory.
.NET web services are defined within *.asmx files. Requests for these files are routed to the ASP.NET
worker process. The ASP.NET runtime, which is an ISAPI extension, maps incoming requests for a given
web service via a named pipe.
In its simplest form, web service code resides within an *.asmx file as shown in the following C# example:
The VB code would be similar. *.asmx file are compiled on the fly.
<%@ WebService Language = "C#" Class = "SimpleMath" %>
public class SimpleMath
{
[WebMethod]
public int Add(int n1, int n2)
{
return n1 + n2;
}
}
While an *.asmx file can contain code and the <%@WebService> directive, you typically place web service
code within a related code file. In this case, the *.asmx file only contains a directive pointing to the code file.
<%@ WebService Language = "c#" Codebehind = "SimpleMath.asmx.cs"
Class = "SimpleMath" %>
Once deployed, a .NET client communicates with an XML web service using an intervening proxy. The
proxy is typically generated using Visual Studio or the wsdl.exe command line tool. Other programming
environments such as Java have similar tools to generate a Java proxy based on an external web service. In
order for these tools to generate the proxy code, they must have an accurate description of each exposed web
method at the specified endpoint.
XML web services are able to describe their format using the Web Service Description Language (WSDL).
WSDL describes all custom types exposed from a given web method, as well as incoming parameters and
outbound return values. WSDL also describes information about the service itself (name, location, and more).
The WSDL definition of an XML web service can be found by suffixing ?wsdl to the URL. When you do so,
you are essentially seeing the ‘interface’ to the web service. Although WSDL descriptions look nothing like a .
NET interface type, they serve the same purpose: describing a contract. Note the ‘interface’ to the Add()
method.
Once the proxy is generated, invoking remote web methods is trivial. The proxy encapsulates all the details of
opening an HTTP connection, translating XML data into .NET types, and so forth.
// C# (VB code would be similar).
static void Main(string[] args)
{
// Assume you named the proxy ‘Service’.
Service proxy = new Service();
Console. WriteLine("10 + 10 = {0}", proxy.Add(10, 10));
}
Interfaces in and of themselves simply define a strongly typed contract. They do not provide any details
regarding how to communicate with the implementing type. For example, interfaces do not specify which
protocol (TCP, HTTP, and so forth) should be used to invoke their members.
In a distributed system, the choice of protocol can be a very important design decision. Some protocols will
tie you to a specific programming framework such DCOM, JAVA EE, or .NET. Other protocols are only
appropriate when you can ensure all networked computers use the same operating system. Still other
protocols (such as HTTP) allow diverse operating systems and programming platforms to exchange data at
the expense of performance.
XML web services are an attempt to enable data exchange in a language-, platform-, and OS-neutral manner.
Rather than using a proprietary wire protocol to move across machine boundaries (DCOM, Java RPC, and so
on), communication occurs using standard HTTP. Rather than expressing data using platform-specific data
types (CTS, Java’s type system, COM types, and the like), web services encode all parameters / return
values as streams of loosely typed XML.
Also, SOAP provides a standard XML-based message format to represent a method call and its response.
Most XML web services make use of SOAP to allow callers to invoke remote methods in a neutral manner.
SOAP messages can also provide other details such as security and attachments.
By using industry standards such as HTTP / XML / SOAP, it is much easier to build enterprise-ready
systems. Thus, regardless of which platform you use to build an XML web service (.NET or JAVA EE),
callers can exchange data in a neutral fashion.
XML Web Services under the .NET Platform
The .NET platform makes it very simple to build XML web services. Each method you wish to expose via
HTTP is marked with the [WebMethod] attribute. You may optionally extend the System.Web.Services.
WebService base class to inherit functionality to build a stateful web service. If your web service does not
require state, you can simply derive from System.Object.
The ASP.NET runtime will automatically encode incoming and outbound data as XML. Additional attributes
can be applied on custom data types returned from an XML web service. These attributes are part of the
System.Xml.Serialization namespace and control the format of the generated XML.
.NET web services are little more than classes with ‘web methods’ hosted within an IIS virtual directory.
.NET web services are defined within *.asmx files. Requests for these files are routed to the ASP.NET
worker process. The ASP.NET runtime, which is an ISAPI extension, maps incoming requests for a given
web service via a named pipe.
In its simplest form, web service code resides within an *.asmx file as shown in the following C# example:
The VB code would be similar. *.asmx file are compiled on the fly.
<%@ WebService Language = "C#" Class = "SimpleMath" %>
public class SimpleMath
{
[WebMethod]
public int Add(int n1, int n2)
{
return n1 + n2;
}
}
While an *.asmx file can contain code and the <%@WebService> directive, you typically place web service
code within a related code file. In this case, the *.asmx file only contains a directive pointing to the code file.
<%@ WebService Language = "c#" Codebehind = "SimpleMath.asmx.cs"
Class = "SimpleMath" %>
Once deployed, a .NET client communicates with an XML web service using an intervening proxy. The
proxy is typically generated using Visual Studio or the wsdl.exe command line tool. Other programming
environments such as Java have similar tools to generate a Java proxy based on an external web service. In
order for these tools to generate the proxy code, they must have an accurate description of each exposed web
method at the specified endpoint.
XML web services are able to describe their format using the Web Service Description Language (WSDL).
WSDL describes all custom types exposed from a given web method, as well as incoming parameters and
outbound return values. WSDL also describes information about the service itself (name, location, and more).
The WSDL definition of an XML web service can be found by suffixing ?wsdl to the URL. When you do so,
you are essentially seeing the ‘interface’ to the web service. Although WSDL descriptions look nothing like a .
NET interface type, they serve the same purpose: describing a contract. Note the ‘interface’ to the Add()
method.
Once the proxy is generated, invoking remote web methods is trivial. The proxy encapsulates all the details of
opening an HTTP connection, translating XML data into .NET types, and so forth.
// C# (VB code would be similar).
static void Main(string[] args)
{
// Assume you named the proxy ‘Service’.
Service proxy = new Service();
Console. WriteLine("10 + 10 = {0}", proxy.Add(10, 10));
}
XML Web Services
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services