Choosing to Deploy a Web Service

Before diving in and turning all new products and functionality into web services, you should realize that web services are not the solution to all problems. This section outlines the factors you should consider before choosing to develop a given functionality as a web service.

Type of functionality. Is the function needed for internal use or for external business partners and customers? For internal use and a homogeneous target environment, a web service does not really make sense. Interdepartmental data exchange may warrant the development of web services, but there are other technologies that make more sense, including COM+ or .NET Remoting.

Deployment. Does the deployment of the function require a complex installation procedure or a complicated hardware configuration? If so, you can free business partners and customers from this onerous requirement by deploying as a web service. There would then be no need to deploy the software locally.

Access to proprietary data. Does the function need to access data that is proprietary, not available to the public, or located exclusively within your organization? If so, a web service would be an appropriate way to expose this data to consumers. A web service would also let you keep certain information private and away from the public eye. This is clearly a much better method than sending data files.

Frequency of data change. Does the data on which the function relies change frequently? If so, a web service would be a perfect fit. Using a web service would ensure that consumers had up-to-date data while also supporting data updates behind the scenes. As a result, consumers would not have to be constantly supplied with data files, and consumers would not have to spend time handling these files.

Version release frequency. Do you expect incremental or periodic releases to the function? Using a web service would reduce the amount of maintenance needed for code updates and release of new versions. There would be no need to perform installations on any of the consuming machines because the deployment would be performed on the web server hosting the web service.

You must ensure that the interface to each function remains the same so the consuming code will not need to be changed. A change to a function call can break code that is expecting a different function interface.

Performance. Is performance of the function of utmost importance? Web services consume time in the transport of data. Calling a web service within a loop would result in a significant performance impact. Functions of this type would be better implemented as functionality exposed by local compiled libraries (DLLs).

Availability. Is 24/7 availability required? If so, you should probably not use a web service. Web services are taken offline for maintenance. In other cases web servers go down or network troubles arise. Even well-protected and well- maintained networks need to undergo maintenance and therefore will have some downtime during the year. A web service that runs on someone else's infrastructure will never be as dependable as a service running on your own servers.