If you've ever gotten a package delivered to you via the United Parcel Service, you almost invariably need to scrawl your name on the big, brown, bulky tablet handed to you by the guy in the brown shirt. When you sign the tablet, UPS knows that you received the package and they can record that information. Tracking packages in real time is really useful for UPS's business. Recipients always want to know where their packages are at any time, and using this technology helps UPS provide this information to end customers.
UPS undoubtedly spent a great deal of money on their package tracking system. They developed the technology in the early 1990s-long before even Al Gore knew what the Internet was. With the advent of a worldwide connected network (the Internet), small and manageable wireless devices to connect to the Internet, and a commonly understood wire format (SOAP), enterprises can develop functionality similar to that used by UPS for a fraction of the cost.
A second way in which Web services will prove useful is in supply chain management. Back in the 1980s, Electronic Data Interchange (EDI for short) promised to allow companies to order supplies and services automatically with little or no human intervention. The idea was that different companies would subscribe to a data format and would be able to order supplies and services from other enterprises in a much more streamlined way.
Unfortunately, EDI turned out to be mostly a glorified e-mail system. The formats for data interchange were brittle and easily broken. Furthermore, when the format broke, it took a long time for the companies involved to reach another agreement on a new format.
Web services promise to help solve the problem of a brittle data interchange mechanism. Through more elaborate orchestration frameworks (like BizTalk from Microsoft), Web services promise to make automatic data interchange between enterprises much more doable and affordable than ever before.
ASP.NET also implements a number of other features for enhancing Web services. For example, sometimes you want to include some metadata as part of a method call. For example, if you want to ensure only paying clients call your Web methods, you might issue them a token to prove they bought the service. The SOAP specification defines SOAP headers as a way to include such metadata in the method call.
In addition, it's sometimes useful to install pre- and post processing for Web methods. ASP.NET supports various SOAP extensions. For example, if you wanted to write your own encryption mechanism, you might write a client-side and a service-side extension that encrypts and unencrypts messages interacting with your server.