Table of contents:

What is an XML web service?
The history of 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 callter of  a web service is called a 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 does not have a 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 platform-independent library or API (application programming interface) available over a 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).

 From a software architecture point of view, XML web services can be extremely useful.  For example, a web service can handle all write accesses to a database.  End-user clients then need not know the powerful "write" login for a database, and the web service can make sure that all appropriate error checking occurs and can control how writing of the database takes place.

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, sent using the HTTP protocol, as XML files 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), businesses have sunk a lot of money 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 made such software distribution difficult.  The long and tattered list of attempts includes RPC, EDI, CORBA, and COM/COM+/DCOM from Microsoft.   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.  XML standards and tools and the HTTP protocol 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 on the server side.  Web clients are also being written using other languages such as Python or Ruby.

The standards being used for web services

The Internet (or an intranet) has become the ubiquitous means of shipping a file from a server to a client, using the HTTP protocol over TCP/IP.   Typically, corporate firewalls leave TCP port 80 open for outbound requests, which means that HTTP clients inside a 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 need break; parsers on the receiving end can 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 independently of each other without breaking the service.  "Cutover" problems for new versions can be reduced.

The third major standard enabling web services is Simple Object Access Protocol (SOAP), a  W3C Recommendation which is based on an open source recommendation, 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 (sometimes).  Microsoft Developer's Network offers a decent SOAP tutorial.  Microsoft preferred SOAP-encoded XML over standard XML because SOAP uses less space than standard XML; the downside of that is that SOAP-encoded XML is not quite as easy for humans to read.

Note that when a C# web service is called from a Java client, it is sometimes necessary still to do the explicit XML handling because Java-based web servers and Microsoft web servers do not package their responses completly alike.  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 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 simple XML-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 is transmitted as 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 call a service developed using .NET, and vice versa.

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 (Web Services Description Language) specification file, and a more human-readable HTML file, 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 Quote web service used in our lab) 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.  They are, however, quite complex to learn and use.

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.