Service Contract
Here's a definition I tend to use:
A service contract represents what the requestors and providers of a service must agree on. It embodies a service's interface and behavior (as measured by service tests), as well as descriptions of the expected quality of service (QoS) like policy and service level agreement (SLA). A requestor and provider of the same service must be built around the same service contract; otherwise their invocations will require mediation.
I'm deciding that the concept of "service" is too vague and that "service interface" only captures part of the technical detail about a service. We need a concept that's in between, which I'm coming to think of as a "service contract."
I first saw the term "service contract" more-or-less formally defined in SOA Principles of Service Design
by Thomas Erl. He defines a service contract as having three parts:
- interface – such as a WSDL definition and XML Schema definitions
- policy – such as WS-Policy description
- service level agreement (SLA) – requirements for availability, response time, etc.
It seems to me that this definition can apply to any approach for implementing a service, not just a SOAP/WSDL Web service. It can also apply to a REST Web service (where the interface is more implied but there's probably still XSDs for the data), to a service implemented as a stateless-session bean or POJO, and so on.
I'd also say that it'd be nice to be able to capture SLA (as well as policy) in WS-Policy. I don't know if that's possible/practical with the current standard; if not, maybe it will be in the future.
A service contract is the part of the service that the service requestor and service provider must agree upon. A requestor delegates to the service contract and a provider implements the service contract. As long as both of their code are designed for the same contract, they'll be able to work together.
What about behavior?
In addition to that definition, I'd say there's also one more aspect to a service contract:
- behavior – what functionality the service is supposed to provide
Service behavior is actually the most fundemental aspect of a service. It's the part you describe first, before trying to nail down the other aspects. Service tests can be used to validate a provider's behavior, and to validate adherence to policy and SLA as well.
Design by Contract
Service contract is an extension of an older, more established concept, Design by Contract, made famous by Bertrand Meyer and Rebecca Wirfs-Brock. The implications are summed up nicely by Alan Knight in "Everything I Know About Programming, I Learned From Dilbert." The contract for an OO class describes what the class must do and what the client can depend on. Now we're applying that concept to services.
Conclusion
A service is more than just a repeatable business task, at least to us technical people. The easiest part to understand technically is the service interface, but that doesn't fully describe a service. A full (technical) description is a service contract, which defines these aspects of a service:
- behavior – expressed as requirements and captured as service tests
- interface – often captured with WSDL and XSDs
- policy – often captured with WS-Policy
- SLAs – expressed as requirements, but perhaps can be captured WS-Policy-style
Blog Posting
From my blog posting service contract:
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.
