Continuing with the theme of "What is a service?", I'm thinking it's best to think of it in terms of a "service contract."
The notion of a service is kind of squishy. It's a repeatable business task, hopefully well encapsulated so that it can be requested in a simple interaction and performed in a unit of work. That makes sense to business people and can be gathered as requirements, but is rather vague for us technical people (especially when trying to achieve business/it alignment). So we tend to fall back on a service interface as being the technical definition of a service. But as I discussed in service behavior, a service is a lot more than just its interface.
So how can we describe a service with some rigor? I'm coming to think of that as a service contract (which I discuss more on my wiki). In short, a service contract captures a service's behavior, interface, policies, and service level agreement (SLA). It's everything that a requestor and provider of a service must agree on so that the requestor knows what it can depend on and a provider knows what it must do.
For us technical people, I think that thinking of a service (a task) as a contract (an agreement that describes the task) will help us be a lot more specific and make good use of the ideals of SOA.
New and updated wiki pages: