XML Web Services

The term Web service is relatively new, but the idea behind Web services has been

around for a while. A Web service is an interface-less Web site designed for

programmatic access. This means that instead of invoking URLs representing Web

pages, you invoke URLs that represent methods on remote objects. Similarly, instead

of getting back colorful and animated HTML code, you get back XML Schema Definition

(XSD) data types packed in XML messages. Aside from these higher-level differences,

the underlying models for a Web site and a Web service are the same. In addition, any

security measure you can implement on a Web site can be duplicated in a Web service.

To summarize, the Web service model is just another programming model running on

top of HTTP.

A Web service is a software application that can be accessed over the Web by other

software. Web services are applicable in any type of Web environment, be it Internet,

intranet, or extranet. All you need to locate and access a Web service is a URL. In

theory, a number of Internet-friendly protocols might be working through that URL. In

practice, the protocol for everyday use of Web services is always HTTP.

How is a Web service different from a remote procedure call (RPC) implementation of

distributed interfaces? For the most part, a Web service is an RPC mechanism that

uses the Simple Object Access Protocol (SOAP) to support data interchange. This

general definition represents the gist of a Web service, but it focuses only on the core

behavior. A Web service is more than just a business object available over an HTTPaccessible

network. A number of evolving industry standards are supported today,

including the Universal Description, Discovery, and Integration (UDDI) standard and the

Web Services Description Language (WSDL); others, such as the Web Services

Security (WS-Security) and the Global XML Web Services Architecture (GXA), will be

supported soon. These industry standards contribute to setting up a full and powerful

environment for remote object-oriented access and programming

The .NET Framework Infrastructure for Web ServicesAlthough Web services and the .NET Framework were introduced at roughly the same

time, there is no strict dependency between the two, and the presence of one does not

necessarily imply the presence of the other. The .NET Framework is simply one of the

platforms that support Web services and that provide effective tools and system classes

to create and consume Web services. No one person invented Web services, but all the

big players in the IT arena are rapidly adopting and transforming the raw idea of

"software callable by other software" into something that fits their respective

development platforms.

The Simple Object Access Protocol (SOAP)SOAP is a simple, lightweight XML-based protocol for exchanging information on the

Web. SOAP defines a messaging framework that is independent from any application

or transportation protocol. Although, as mentioned, SOAP packets travel mostly as

HTTP-POST commands, SOAP neither mandates nor excludes any network and

transportation protocol

The most important part of the SOAP specification consists of an envelope for

encapsulating data. The SOAP envelope defines a one-way message and is the atomic

unit of exchange between SOAP senders and receivers. The SOAP specification also

needs a request/response message exchange pattern, although it does not mandate a

specific message pattern. The remaining, optional parts of the SOAP specification are

data encoding rules for representing application-defined data types and a binding

between SOAP and HTTP.

IIS Support

A .NET Framework Web service is a Microsoft ASP.NET application with an.asmx

extension that is accessed over HTTP. ASP.NET, as a whole, is part of the .NET

Framework that works on top of IIS, taking care of files with special extensions such as

.aspx and .asmx. One of the key components of the ASP.NET infrastructure is the

Internet Server Application Programming Interface (ISAPI) filter that IIS involves when it

gets a call for files with a certain extension.

The IIS mapping between .asmx files and the appropriate ASP.NET ISAPI

filter.

The connection between the IIS process (the executable named inetinfo.exe) and the

HTTP pipeline (the worker executable named aspnet_wp.exe) is established through a

named pipe—that is, a Win32 mechanism for transferring data over a network. As you'd

expect, a named pipe works just like a pipe: you enter data in one end, and the same

data comes out at the other end. Pipes can be established both locally to connect

processes and between remote machines.

After the ASP.NET worker process receives a request, it routes that request through

the .NET Framework HTTP pipeline. The entry point of the pipeline is the HttpRuntime

class. This class is responsible for packaging the HTTP context for the request, which

is nothing more than familiar Active Server Pages (ASP) objects such as Request,

Response, Server, and the like. These objects are packed into an instance of the

HttpContext class, and then a .NET Framework application is started.

The WebService Class

In the .NET Framework, a Web service is an ordinary class with public and protected

methods. The Web service class is normally placed in a source file that is saved with an

.asmx extension. Web service files must contain the @ WebService directive that

informs the ASP.NET run time about the nature of the file, the language in use

throughout, and the main class that implements the service, as shown here:

<%@ WebService Language="C#" Class="MyWebServiceClass" %>

The Language attribute can be set to C#, VB, or JS. The main class must match the

name declared in the Class attribute and must be public, as shown here:

The WebService Attribute

The WebService attribute is optional and does not affect the activity of the Web service

class in terms of what is published and executed. The WebService attribute is

represented by an instance of the WebServiceAttribute class and enables you to

change three default settings for the Web service: the namespace, the name, and the

description.

Building a .NET Web Service

As mentioned, a Web service is a class that optionally inherits from WebService. As

such, the class can implement any number of interfaces and, as long as you don't need

to directly access common ASP.NET objects, can also inherit from any other .NET

Framework or user-defined class. The definition of the class must necessarily be coded

in an .asmx file. The file is made available to potential clients through a Web server

virtual directory and is accessed through a URL. Any client that can issue HTTP

commands can connect to the Web service unless security settings restrict the client's

access to the service.

What happens after a client points to the URL is the focus of the rest of this chapter.

Let's start by analyzing the internal structure of the Web service class.

Format of SOAP Messages for a Web Method

Although SOAP dictates that the messages being exchanged between the Web service

and its clients must be in XML, it says nothing about the actual schema of the XML. The

.NET Framework provides an attribute-based mechanism to let you control the format

of the XML packed in the SOAP message. To customize the structure of a SOAP

message, you can intervene in two places: you can modify the layout of the information

being packed beneath the <soap:

Processing a Web service call

Building a .NET Framework Web Service Client

Whether you use Microsoft Visual Studio .NET or a simple text editor to code the .asmx

file, writing Web services using the .NET Framework is definitely an easy task. And as

you'll see, writing client applications to use those services is even easier.

You can call a Web service through a URL using either the HTTP-GET or the HTTPPOST

command. You can do that also from within an ASP.NET page using the

WebRequest .NET Framework class. From within Visual Studio .NET, referencing a

Web service is nearly identical to adding a reference to another assembly. What you

get is a proxy class through which your Windows Forms or Web Forms application can

reach its URL across port 80, just like a user's browser. In doing so, firewall problems

disappear and HTTP on top of Secure Sockets Layer (SSL) or any other form of

encryption can be used to transfer data.

A Windows Forms Web service client in action.

Invoking a Web Service Through Script

A Web service is always invoked by using an ordinary HTTP packet that contains

information about the method to call and the arguments to use. This HTTP packet

reaches the Web server by traveling as a GET or POST command. You can invoke a

Web service method using one of these commands:

.. A POST command that embeds a SOAP request

.. A POST command that specifies the method name and parameters

.. A GET command whose URL contains the method name and parameters

To invoke a method in a Web service, SOAP is not strictly necessary. You can use

GET or POST commands, which results in a more compact body. However, the

benefits of using SOAP become clearer as the complexity of data increases. GET and

POST commands support primitive types, including arrays and enumerations. SOAP,

on the other hand, relies on a portable and more complex type system based on XML

schemas. In addition, in the .NET Framework, Web services also support classes that

the XML serializer can handle.

A Windows Script Host Example

To give you a practical demonstration of how Web services are really just HTTPaccessible

software agents, let's write a Windows Script Host (WSH) script that allows

plain Microsoft Visual Basic, Scripting Edition (VBScript) code to download information

from a remote server. To send HTTP commands from VBScript code, we'll use the

Microsoft.XmlHttp object—a native component of Microsoft Internet Explorer 5.0 and

MSXML 3.0 and later versions. The following script calls the method GetSalesReport by

using a GET command: