It never ceases to amaze me how ambiguity in the definition of simple terms can lead to design choices that have a huge impact on the success of projects. Recently I had a long discussion with a colleague at a client site, where we are in the process of assessing the artifacts that have been created for a Web services-based service-oriented architecture. While we are talking about terms and definitions, let us be clear about the fact that there is a paradigm called service-oriented architecture, and there is a platform on which it can be realized called Web services. Often the two are confused. They are definitely not the same. One is a concept, the other is a technology platform.
Anyway, back to some basic definitions. As you get into defining Web services for service orientation, there needs to be a clear distinction between the definition of the service and its usage. If we get down to the ground-level basics, one is a noun and the other is a verb. A service offers a certain kind of business functionality - it is the what, and it is a noun. The usage of the service is most commonly expressed through a set of scenarios, each of which is represented in UML as an instance of a use case. The use case is the sequence of activities that constitutes an instance of the usage of the service, and it is defined as a verb. For example, CreditCheck is a service. On the other hand, VerifyCredit would be a use case that leverages the CreditCheck service to provide certain value to the calling application or component.
A service is specified by a contract. For example, a Web service is typically specified by its WSDL definition. The service specification does not include scenarios for its usage. The contract includes an SLA (service level agreement) that ensures that the consumer of the service clearly understands how to call the service, what information to pass to it, what information to expect back, the protocol used to call it (in the case of Web services, this is obviously SOAP), how the service behaves under different constraints, etc.
As I mentioned earlier, sometimes these terms are confused. Recently I came across an instance in which the services were defined as a use case. While this may seem to be a trivial deviation, in the grand scheme of things it can have substantial problems as the design of the system matures. For example, if the designer of the service is defining it as a use case, he or she needs to have a very comprehensive view of all of the moving parts of the system. The person who designs the service usually does not have this view. Typically the service designer has a view of how the service is to be called, not of who uses it, and when and how.
The problem has its roots back in the great business-IT divide. The use case is derived from a business requirement that is specified by business. When the use case is defined, the service it calls it treated as a black box. The person defining the use case should not be concerned about how the service is implemented, and this is possible only if the service has a well-defined contract. Now, if the person defining the use case is also defining the contract of the service that is used in the use case, he or she will have a view of the service within the narrow scope and context of the use case. This means that the service might not be applicable to callers, and therefore, it will not qualify as a reusable service. The result will be an unmanageable volume of granular services with ill-defined contracts. A system built on this base is doomed to malfunction.
So as you venture out into service-oriented projects, make sure that you have clear distinction among what the system is composed of, what is exposed as a service, and the different use cases for the service.