1. XML Web Services

2. 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.

3. 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.

4. 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

5. The .NET Framework Infrastructure for
Web Services
Although 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.

6. 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

7. 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.

8. 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.

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

11. 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.

12. 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:

13. 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.

14. 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.

15. 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:

16. Processing a Web service call

17. 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.

18. A Windows Forms Web service client in
action.

19. 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.

20. 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: