| | h1. Service Contract |
| | |
| | Here's a definition I tend to use: |
| | |
| | bq. A *service contract* represents what the _requestors_ and _providers_ of a [service] must agree on. It embodies a service's [interface|service interface] and [behavior|service behavior] (as measured by [service test]s), 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|http://soabooks.com/]_ 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|REST vs. 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. |
| | |
| | h2. 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 test]s can be used to validate a provider's behavior, and to validate adherence to policy and SLA as well. |
| | |
| | | h2. Design by Contract |
| | |
| | Service contract is an extension of an older, more established concept, [Design by Contract|http://en.wikipedia.org/wiki/Design_by_contract], made famous by [Bertrand Meyer|http://en.wikipedia.org/wiki/Bertrand_Meyer] and [Rebecca Wirfs-Brock|http://en.wikipedia.org/wiki/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. |
| | |
| | h2. 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 |
| | |
| | h2. Blog Posting |
| | |
| | From my blog posting [service contract|http://www.ibm.com/developerworks/blogs/page/woolf?entry=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|http://www.ibm.com/developerworks/blogs/page/woolf?entry=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|http://www.ibm.com/developerworks/blogs/page/woolf?entry=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|Service-Oriented Architecture]. |
