When should a web service not be used?

Solution 1:

Web Services are an absolutely horrible choice for data access. It's a ton of overhead and complexity for almost zero benefit.

If your app is going to run on one machine, why deny it the ability to do in-process data access calls? I'm not talking about directly accessing the database from your UI code, I'm talking about abstracting your repositories away but still including their assemblies in your running web site.

There are cases where I'd recommend web services (and I'm assuming you mean SOAP) but that's mostly for interoperability.

The granularity of the services is also in question here. A service in the SOA sense will encapsulate an operation or a business process. Data access methods are only part of that process.

In other words:

  - someService.SaveOrder(order);  // <-- bad
    // some other code for shipping, charging, emailing, etc

  - someService.FulfillOrder(order);  //<-- better
    //the service encapsulates the entire process

Web services for the sake of web services is irresponsible programming.

Solution 2:

Nick Harrison, a brilliant developer in Charlotte, suggested these scenarios where using a web service makes sense:

• On a Web farm, where there are multiple web servers hosting website(s), all pointing to web service(s) running on another web server. This allows for distributing the load over multiple servers.
• Client/server, where Windows forms apps can call a web service.
• Cross platform
• Passing through a firewall

Solution 3:

Just because the tool generates a bunch of stubs doesn't mean it's a good use. WS-* excels in scenarios where you expose services to external parties. This means that each operation should be on the granularity of business process as opposed to data access.

The multitude of standards can be used to describe different facets of your contract in great detail and a (hypothetical) fully compliant WS stack can take away a lot of pain from the third party developers and even allow the fabled point and click integration a'la Yahoo Pipes. With good governance controls you can evolve your public interface and manage the backward compatibility as needed.

All this is next to impossible to be generated automatically. The C# stub generator knows only the physical interface of your class, but doesn't have any idea about the semantics involved. See this paper for more detailed discussion.

If you are building a web site, then build a web site. If you want asynchronous messaging inside your application, use MSMQ. If you want to expose data to internal clients, use POX. If you need efficient binary message format, check Google's Protocol Buffers or if you need RPC check Hessian for C# or DCOM.

Web services are a coarse grained integration solution. They are rigid, they are slower than alternatives, they take too much effort to do well (and when not done well are next to pointless).

To summarize: "When should a web service not be used?" - anytime you can get away without it