Creating and Consuming an XML Web Service

The following code is a Web service object.  It doesn’t do much, but it does show much of the
idea behind Web services.  This object simply returns a string describing the current date and
time.
<%@ WebService Language="C#" Class="DateService" %>
using System;
using System.Web.Services;

public class DateService:WebService{
     [WebMethod]
     public String GetDateString() {
          return DateTime.Now.ToString("D");
     }
}
Figure 2-1  DateService.asmx
The code in Figure 2-1 describes a server side object that provides data for a client.  However,
unlike web applications, a Web service does not serve its data to a browser.  Instead, a Web
service serves its data to other software.
In the case of the DateService.asmx its not what the service does that is interesting, but rather
what the service doesn’t do.  (After all, what is does is return the current date in the form of a string).  But what it doesn’t do is implement any network communication code, nor does it deal
with any protocol code.  That’s the infrastructure to which I am referring.  The .NET Framework
handles network communication and protocol parsing through ASP.Net and the class library,
so that the DateService.asmx can focus on its business logic.
Note:  The two lines of code in Figure 2-1 shown in green represent markup parsed by
ASP.Net and a managed attribute.  I will explain the significance of both later in this tutorial.
Deploying this Web service is as simple as copying the .ASMX file into a directory in your file
system that is configured as an IIS virtual root.  This is because IIS (Internet Information
Service) is the host for your service object (and a listening/communication agent).
Now imagine that the DateService.asmx Web service has been published to a URL on the
internet; for this example let’s assume http://www.wintellect.com/Services/DateService.asmx,
and you want to consume this object with client code running on your machine.  Here is what
the client code looks like.
using System;

class App{
   public static void Main(){
      DateService webObj = new DateService();
      webObj.Url =
         "http://www.wintellect.com/Services/DateService.asmx";
     
      String dateString = webObj.GetDateString();
      Console.WriteLine(dateString);
   }
}
Figure 2-2  DateClient.cs
If you are finding it hard to believe that this is all the code that is required to consume a
distributed object exposed on the Internet, then you would be correct.  But this is all of the
code that you have to write.  The DateService type is actually derived from a class library
type called SoapHttpClientProtocol.  The SoapHttpClientProtocol type actually
does most of the work of communicating with the Web service, and the DateService type is
just a specific derivation of the base class designed for communicating with the
DateService.asmx.
So, if you don’t have to write the DateService class that is derived from
SoapHttpClientProtocol, then who does?  There are actually two answers to this
question.  Visual Studio .NET will create a proxy derivation class for you, or you call the
WSDL.exe tool that ships for free with the .NET Framework, and it will do the same.
Note:  If you are wondering how a tool is able to find sufficient information to create code for
a specific service, the answer is in the WSDL service contract.  WSDL stands for Web
Service Description Language, and all Web services can be described by a WSDL document
(that is part of being a Web service).  I will talk more about WSDL shortly, but for now, just be
aware that Web services that you create using the .NET Framework can automatically
describe themselves using WSDL, simply by adding ?WSDL to their URL. So that’s it!  It takes less than 25 lines of C# code to write both a Web service and a client to
consume the service.  I will admit that a lot of work is happening automatically.  But don’t
worry, I will explain the magic parts such as client proxies, WSDL, etc. shortly.