There is a subtle difference between a service provider and building web services in a SOA context. The difference can be quite evident in the design process. A service provider has to design services that can be potentially leveraged beyond an immediate consumer. It is also important to think about service capabilities not being bound to a specific transport. They have to think through governance concerns such as versioning, metering, service level agreements, and production support. Additionally, they have to consider data contracts, reuse of schema types and definitions, runtime metrics, monitoring, and reporting across consumers that access services. A web service builder doesn't consider these aspects - at least not to the same extent as a service provider. For instance, they might build a service as an extension of an existing procedure, class, or module. That is perfectly okay. However, if you consider the service provider perspective, you will examine a larger set of design issues that can be of relevance to not just the current service but future ones as well.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=536ee35f-ddeb-47c4-94a3-9bd7e30ad0e7)
"For instance, they might build a service as an extension of an existing procedure, class, or module. That is perfectly okay", yes, it is OK except for the fact that the use of Web Service to add a Web access to the “existing procedure, class, or module” has very little in common with building the Service.
It is obvious that the work of the Service provider and the work of the programmer writing Web Service interface are VERY different. It is as different as Service and one of its interfaces.