Table of contents:

What is an XML web service?
The history of web services
The tools being used for web services
The standards being used for web services
Example of a non-SOAP web service today (RSS)
Example of a SOAP-based web service
Finding out about existing web services
Advantages of SOAP-based web services
Limitations of SOAP-based web services

What is an XML web service?

An XML web service is a way of having a function on one computer which you can call from another computer.  A web service resides on a web server that passes the client request to the service.   The consumer of  a web service is called a web service client.  The client can be an application running on any operating system, or it can be a web page on any web server.

A web service itself does not have a direct user interface; it only provides callable methods, and it provides a "discovery page" with instructions on how to call its methods.  You can think of it as a sharable DLL somewhere out on the network.  To develop a simple web service in C#, see this tutorial.

An XML web service is especially useful in a heterogeneous computing environment, where the client may be implemented on a different operating system or with different programming tools than the server (i.e., the web server on which the XML web service).

An XML web service may also be useful, as in the case of the Blinky web service in Project 5, to handle all the write access to a publicly readable database.  The web service can use a more powerful password than read-only clients have; it can also guarantee that the database is only modified in limited fashion.

Strictly speaking, "web services" does not really mean any one set of standards. But in practice, the majority of web services being developed today are implemented as XML files sent over HTTP using SOAP encodings. This combination of standards has broken open a long-standing bottleneck in cross-network communications. 

The history of web services

Since networks became ubiquitous (at least 20 years ago), business has sunk billions of dollars into the search for ways to write programs that reside on multiple machines. But by and large, machine architectural differences such as how an integer is stored have made such software distribution difficult.  The long and tattered list of attempts includes RPC, EDI, CORBA, and COM/COM+.   These strategies were the ones that did at least work, but they each required a lot of time and money to purchase special tools, and deep programming expertise (an expensive item) was needed on both the server and client sides. Thus it was only feasible to develop the most lucrative, large-scale services across a network; lesser services were simply unaffordable.

Today, this has all changed.  Standards and tools have emerged so programmers can distribute software across networks easily (at least, relative to the previous strategies).  In a nutshell, the standards are HTTP, XML and SOAP, and the two competing tool platforms are Java and Microsoft .NET. 

The tools being used for web services

There are at least two major tool platforms for developing XML/HTTP/SOAP web services and clients: Java-based tools, and Microsoft .NET. It's essentially an arms race between the two platforms to see who can provide the most cost-effective and maintainable way of developing XML web services.

The standards being used for web services

The foundational standard is HTTP, as well as its related user-session strategies including cookies.  The Internet (or an intranet) has become the ubiquitous means of shipping a file from a server to a client.  Typically, corporate firewalls leave TCP port 80 open, which means that HTTP clients inside the firewall can access web servers outside the firewall.  HTTP has solved the long-standing need for a relatively trivial transport method for calling remote methods.

Another foundational standard for web services is XML, a form of self-describing data. When two applications communicate by exchanging XML files, there are some very big benefits. First, all data is text, which makes the old problem of how integers are stored on a specific machine type irrelevant. Second, if the sender adds a new field which the receiver doesn't handle yet, nothing breaks; parsers on the receiving end simply ignore the unrecognized fields and continue to work just fine. This means that developers of services and consumers of services can grow their XML data asyncronously.

The third major standard enabling web services is Simple Object Access Protocol (SOAP), a  W3C Recommendation which is based on XML_RPC.  SOAP specifies how to format many common data types as XML when calling a remote method, and how to ship the XML request file and response file using HTTP.   SOAP-encoded XML sent over HTTP makes it feasible to develop remote functions across a network without the aggravation of programming with RPC, CORBA or COM, or the awkwardness of explicit XML file handling.  Microsoft Developer's Network offers a decent SOAP tutorial.  Microsoft preferred SOAP-encoded XML over standard XML because SOAP uses less space that standard XML; the downside of that is that SOAP-encoded XML is not quite as easy for humans to read.

Note that when calling a C# web service is called from a Java client, it is sometimes necessary still to do the explicit XML handling, although several recent Java toolkits offer support for SOAP-encoded XML and make the process of calling cross-platform web services easier.

Example of a non-SOAP web service - RSS

XML is now the de facto format for data exchange between services and clients.  As soon as the XML standard was first published, companies began using XML files to communicate purchasing requests, class registrations and the like.  Despite a scarcity of tools supporting it, XML was immediately better than previous EDI-defined data formats.  The XML files were emailed, FTP'd, placed passively somewhere on a web server and then retrieved by a web client, and even generated actively on web servers.   Today, there are many XML support tools for programmers.  Java and .NET programming languages can serialize objects (store them to disk, and then reopen them with all state retained) as XML files.

Really Simple Syndication (RSS) standard is perhaps the simplest form of XML-based web service; it is implemented asyncronously without SOAP.  It is a way to use the web to pick up a list of HTTP links to the latest information about something (in XML form).  The publisher makes an XML file available on the web and updates it at will.  "Subscribers" periodically fetch the RSS file from the publishing website or FTP server.  This is likely the means by which, for example, portal websites such as Yahoo! obtain Associated Press and other headline news links. 

Examples of C#web services

The advent of good tools supporting Simple Object Access Protocol (SOAP) means you no longer need to be a rocket scientist in network programming to create a set of remote methods (a "web service") on a web server.  A call to a SOAP-based web service consists of one request and one answer.  The client sends an XML file that contains the parameters needed by a method in the web service.  The web service method consumes the XML file and sends back an XML file containing the results of its execution.  All information transmitted is text and passes freely through corporate firewalls.

The client program which calls the web service might be embedded in a scripted web page on a different web server; it might also be a stand-alone Windows, Linux or Mac application.  The client and server may reside on different operating systems and may have been developed using completely different development tools.  A client developed using Java should be able to consume a service developed using .NET, and vice versa.  Using Microsoft Visual Studio, developing a web service is almost identical to developing an application program--you just have to add a few metadata directives to the code, which resides on a web server.  Microsoft has done all the plumbing and infrastructure for you.

Here are some sample web services (source code is available) developed as learning projects by Penn students.

Finding out about existing web services

On IIS6, a web service compiles to a DLL (.NET assembly) which is invoked by the web server when the URL of the web service is provided.  Visual Studio .NET makes it quite easy to write a web service; it is generally no more complicated than writing methods in VB.NET or C#.NET.  Using the IIS6 web server on Windows Server 2003, Visual Studio .NET generates all the plumbing to encapsulate the client interaction via XML and HTTP; it also generates the WSDL and HTML file needed to document the web service's methods to potential clients.

Web Services Description Language is an XML schema for describing a particular web service. Here is a sample XML WSDL file (from the Blinky web service used in Project 5) that fully specifies the signature of all methods available in the web service.  Also, Visual Studio .NET automatically generates an HTML description of each web service method; the description is obtained by reflection on the "WebMethod" attributes embedded in the web service code.

To locate available C# web services on the internet, you can use this cheap trick for googling web services.

Advantages of SOAP-based web services

Some major advantages of SOAP-based web services include:

1. All SOAP information is text strings; there are no format concerns for integers or for complex data types.  Even binary objects such as graphics can be transmitted as text using base64 encodings similar to those used in email attachments.
2. Since SOAP messages are carried over HTTP, they pass through existing company firewalls as is.
3. The server can be developed using different programming and operating system technologies than the client/consumer.
4. The client or consumer can either be another web page or a local application program.
5. Off-the-shelf tools for Java and .NET make programming these services much easier than any of the "old" approaches did.
6. The approach is fully standards-based; providers need not lock into any one expensive, proprietary piece of software such as CORBA or COM.
7. Web services allow the situation where only one company can provide answers to certain questions, and any consumer can reach this information; this results in actual software reuse, a concept long touted but very seldom realized.

Weaknesses of SOAP-based web services

The major missing areas that I know of include:

1. The SOAP-based services standard currently lacks transactions.  What if multiple back-and-forths between client and server are needed to get something done? SOAP currently just specifies one request and one answer, and each method call instantiates a new instance of the web server object (which becomes garbage-collectible immediately after that method call ends).
2. There is currently a lack of standard security models in SOAP-based services.

The missing areas are being actively worked as standards proposals. No one knows yet which of several current approaches will win out.  Microsoft has a set of SOAP extensions and is encouraging developers to try them out with an eye towards finding out whether they are standards-worthy.  Many of these extensions are implemented in ASP.NET 2.0.

The efficiency police still complain about the extra overhead of processing XML messages to and from other forms at either end of the client-server chain.  Nonetheless, the advantages of SOAP-based web services often outweigh even that concern.
 

Here's the .NET Framework 2.0 documentation on XML Web Services.
 

HTTP GET and HTTP POST are disabled in the .NET Framework 2.0 XML web services.  To enable them, add a web.config file to your web service and fill it with exactly this text.