Developing XML Web Services

Developing XML Web Services

Xml web services are of the most talked feature of the .NET platform. Many business expose applications to customer as webservices using pay-per-use model where different compnies interect with one anoter across the web. The UDDI(Universal Description, Discovery and Integration) project initiated by IBM, Microsoft and others supports these goals by allowing companies to publish information about the webservices they produce in universal registry the will be accissable by all.

ASP.NET provides these default pages to allow you to browse Web service descriptions.
The page in figure 6.1 is generated by the DefaultWsdlHelpGenerator.aspx
page, which is shipped with .NET. You can change this default by editing the section of the machine-wide configuration file, machine.config, typically
installed at C:\WINNT\Microsoft.NET\Framework\\CONFIG. See

Unlike DCOM, CORBA, web services are founded on universal, non-propritery standards including XML and HTTP. Web services are not exclusively for .NET. One of straingts that they offer a model that is platform independent.

Introduction to XML Web Services

Web services is an application that exposes a programming interface to remote caller over the web unlike CORBA and DCOM web services offer a simple scllable model based on Industery standard such as XML/SOAP. SOAP in turns use HTTP as the transport layer to move stractured type information across the Internet.

SOAP messages are one way transmission but can be combine to create request/Response conversation model suited to Remote Method Invocation(RMI). Developing XML web services and client doesn’t require understaning of SOAP. Using ASP.NET developing the web services and deploying it on IIS. Microsoft IIS and ASP.NET infstracture llok after the compiling the source, bulding a WSDL contract which describes the service forwarding client call to service and return result.

.NET SDK provide tools to query the WSDL contract, and create a proxy class to use to compling a client application.

CREATING A FIRST WEB SERVICE
Without further delay, let’s create our first Web service. We’ll develop a simple service
that accepts the caller’s name and returns a greeting. We’ll be installing our Web services
on IIS, so we’ll need a virtual directory on the Web server. Call this new virtual
directory ws (for Web services) and remember to assign it permission to execute scripts.
Creating the service
Web services are stored on the server in files with a .asmx extension. These files are a
bit like .asp files and can contain server directives and C# code. You can also use the
CodeBehind directive to place the C# code in a separate file, as Visual Studio .NET
does when you create a new Web service project. We don’t bother to do this for the
simple examples shown here.

Once again, we’ll use our old friend HelloService. While not very exciting, its
simplicity will allow us to cover more ground within the confines of a single chapter.
We’ll be creating several versions of HelloService, so we’ll call the first version
HelloService1 and store it as helloservice1.asmx. Listing 6.1 contains the code for
this first version.

The first line in the file identifies the application as a Web service coded in C# and
contained in the class HelloService1. The WebService attribute assigns a
description for the Web service and a default XML namespace for schemas generated
for the service. This attribute is not strictly necessary and your service will work without
it. However, it allows you to specify a name for the service which is not constrained
by the naming rules of the CLR. In this example, we just accept the default
class name, HelloService1. You should assign a unique namespace when you are
publicly exposing your Web service to callers. This will disambiguate your service
from other services on the Web which have the same name. You can use your company’s
Internet domain name as part of the XML namespace, as I have done in this
example. Note that, although this may look like a URL, it does not point to an actual
resource on the Web.
The HelloService1 class is derived from System.Web.Services.Web-
Service. Doing so provides access to the ASP.NET Context property and makes
available the familiar ASP.NET objects including Request, Response, and Session.
We’ll use some of these objects later when we consider how to maintain state
between service invocations.

Public methods which clients can call must be annotated with the WebMethod
attribute. This attribute has several optional properties including the Description
property which we set in this case.
Testing the service
Save this file to the server, launch Internet Explorer and go to the URL. By default,
you should see a page similar to that shown in figure 6.1.

Returning to the page in figure 6.1, click the Greet link and you should be presented
with a page containing a textbox where you can enter your name, and a button to
invoke the Greet method. See figure 6.3.