What is a web service? Imagine you're writing a function in some programming language. It might be C or C++, as part of a larger program development, or you may be writing it in VBA so you can refer to it within cells of your latest Excel budget spreadsheet. Whatever the case, the idea is that you're likely to use it a lot and so you've decided to write it once and refer to it from any number of different programs you write.
Now imagine someone in another office of your organisation wants to use the same function. Easy - just email them the text of the procedure, or if it's a C program you could compile it into a library and send them the object code. The trouble with this approach is that if you find a bug, or you decide to change the logic of the function, you now need to send fresh copies to all the people who use it. Wouldn't it be great if you could simply make the function available on a server somewhere to be called from arbitrary locations based on some predefined authentication and/or access control scheme?
This is where web services come in. A web service is a wrapper that you put onto one or more functions in order to make them accessible to remote users via HTTP (web-based) connections. So an interface is constructed whose back end interfaces to the function (to pass in parameters and pull out any returned values) and whose outward-facing interface defines the data items that are passed in and out and handles the mapping between what it receives from the calling system and what the back end function is expecting. The standard used for this external presentation is the web service definition language (WSDL), as defined by the World Wide Web Consortium, and XML structures are used for the actual input and output of program data.
Why the big deal?
Aside from the ability to concentrate functions in one controllable place, there is a second major bonus to adopting web services in client-server applications. Imagine you have a pair of servers, A and B, each of which hosts a particular business application, and you have a home-built program that does some data extraction involving both systems. Normally, you would have to write the client application such that it pulls all the required data from A, pulls all the required data from B, maps the dataset together based on some rules and then works out the answer.
Now imagine you could move the mapping function over to a machine that sits right next to both A and B in the datacentre, instead of doing the mapping on the client machine. The client sends a simple function call as an XML-style query via HTTP, the server performs the lookups and the mapping, and the answer is returned to the caller over the HTTP connection. The network traffic has been minimised by keeping the majority of the data within the server farm, and once the processing has been centralised in this way you could even consider implementing some kind of central cacheing function on the web service server, in order to speed up instances where several client machines are requesting the same lookups. The only real downside is that you're concentrating the processing requirement on a single, central server. So, there may be resilience and/or capacity issues to consider if you're going to make the web service thing a habit.
Although web services are clearly useful tools for reducing network traffic within the corporate network, as the name suggests they're just as useful in the wide area, for exactly the same reason. In this case, by concentrating the processing on the server you're eliminating the bandwidth bottleneck that would have made the direct access technique irritating at best, or unusable at worst.
Web services aren’t the only way to eliminate bandwidth bottlenecks in client-server programs, though. Stored procedures have been used for years to this end by database application writers and they work in exactly the same way. The caller passes in some parameters, the processing is done at the server and only the required data is passed back to the client.
One of the problems with stored procedures, though, is that it relies on all the required data residing within reach of the stored procedure itself. This is fine if, say, you have a personnel database and a payroll database on the same SQL Server cluster, as the stored procedure can talk between database instances. But if you want to aggregate data between, say, your SQL Server personnel database and a proprietary CRM system, this will generally lie beyond the scope of a stored procedure. You'll have to implement it as an external application (access to which, as we've seen, is made easy if you write it as a web service).
Web services increase traffic?
Even where a client-server application can be implemented as a stored procedure, though, web services can help. By implementing the data access part of the client end of the client-server package using web services, you can eliminate proprietary database access from this program altogether. Thus it will be completely oblivious to what kind of database is being used (if you were accessing stored procedures directly, you'd generally have to have the database-specific driver software on each client, as well as writing the code to chant database-specific procedure calls). Want to change the back-end database? Simple, just rewrite the web services at the central server.
With the latter approach, though, it's important to realise that this may in fact cause an increase in network traffic and potentially some application slowdown too. This is because the data will generally be bundled up inside some XML-style structures, which by their nature can be verbose. When the response reaches the client, it'll need to parse the XML data stream in order to extract the data, whereas with a native stored procedure call it would have seen a much more raw stream of data flying in.
Where it's not possible to use stored procedures and other generally available server-side processing tools, web services provide a useful way to move the data processing and integration aspect of an application toward the server and thus reduce network traffic (or make the program more suited to slow VPN or WAN links). Web services also provide a standards-based means of interfacing the client and server components of a client-server system, and allow you to eliminate proprietary database calls from your applications, although this may be at the expense of a noticeable increase in network traffic.