When to/not to Use Web Services

It's not a secret Web Services are getting popular as both P2P integration and consolidation technology. There are limits to what can and cannot be achieved with any technology. Web Services are no exception.

When to use Web Services:
-To integrate heterogeneous systems (different platforms, different languages)
-when you don't know about client environment in advance (For example, Web Services API's provided by amazon.com, numerous mash-up servers, etc.)
-When you want to have the same data in different presentation (This is due to the fact that messaging is purely based on XML and XML can easily be converted to different document formats)
- To make web site content available as a services (Think of as a replacement to RSS feeds)
- To provide different entry points to the same data repository. (For example, data services provide an abstraction for database access)
-To interface legacy systems
- To build B2B electronic procurement systems
- To expose a software as a service
- To reuse existing components; Unlike traditional middle-ware technologies which are essentially using a component-based model of application development, Web services allow almost zero-code deployment.


When not to use Web Services :
-It is not the most efficient (in terms of response time) way to transfer data compared to RPC, CORBA, etc which use native binary messages. Until we find efficient ways to handle XML, web services may not be used for systems where there are stringent real-time timing requirements.
-Message size is lager than that of its predecessors (of course it depends on the encoding used and standardize text added to the message also contributes to this). It may not be suitable for high data volume systems.