Originally posted by Balachandran Vijayarajan:
This is my requirement,Having lots of webservice.
That is not a requirement. Web services can be part of a solution developed in response to requirements, but they are never a requirement in themselves. Otherwise you simply end up with a whole mess of web services that do not solve any particular problem. And often
lots of web services are only a very small part of a solution to a much "larger scale" set of problems.
So what problem are you trying to solve?
Like more scalable, performance, maintainable ..
Scalabilty - ensure that your web services are stateless. That means that the do not store any client or application state. As they are often used in the processing of "long running business transactions" (we are talking about hours, days, possibly weeks) they usually delegate storage of transaction state to their persistence store rather than keeping it in memory - and compensation is preferred over two-phase commit (Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF)) Performance - only use web services for large-grained interactions. For example: only submit an entire purchase order - don't submit it a line-item at a time. Maintainability - this is where things get complicated. Any web service endpoint exposes an interface - which means that changing the interface will affect both the service and consumer. There is some freedom in XML Schema as you should be able to add new optional elements without problems; however that will only work if your client's SOAP stack will simply ignore elements that it isn't expecting. Often changing the interface requires exposing the new interface on a separate endpoint so that new clients can use it while the old client aren't forced to upgrade; often this make the service more complicated as it has to support multiple web service interfaces.