This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

What's a Service Contract?

Stefan Tilkov,

It’s once again time for me to create another SOA glossary — mapping a customer’s existing terminology to the way specific terms are used in the SOA community. Always fun. We (once again) have two competing definitions for “contract”, though:

  1. A contract is service interface + policy (+ address)
  2. A contract is the mutual agreement between two parties (usually a specific consumer and provider)

I lean towards the second definition (it’s the one e.g. used by ZapThink and in the OASIS SOA Reference Model), but I wonder how widespread this understanding is? (The only occurrence of the first one I can find right now is, in fact, in a comment by Anne Thomas Manes here on this very blog; IIRC, it’s also the one used in her book).

What do you think?

On August 21, 2006 9:43 PM, Oliver Wolf said:

The first definition is by far the most widely used one in software engineering, but in my opinion it is based on the ill-chosen usage of the term by Bertrand Meyer when he introduced “Design by Contract”. A contract in that context is formed by obligations and benefits, but since the third important property of a legal contract — the mutual agreement — is missing, I’d consider this a weak analogy that can be pretty misleading. So to answer your question: While the first definition is common, I support your opinion that the second one is more appropriate, especially in a large distributed system like an SOA without fixed associations between specific consumers and providers.

On August 22, 2006 9:43 AM, Hartmut Wilms said:

Although the second definition sounds very appealing, it’s vagueness and vision may be far from reality. There are several kinds of contracts in our real world, which are as strict and don’t offer any room for mutual agreements as specified in the first definition.

If you want to send a parcel via your local postal service office, you are are not able to negatiate the contract. You are only able to accept it or decline the offer. Period.

The only alternative, which I can think of is, that two partners offer several altenative assertions within their policies and may match their policies at runtime. Finally they may come to a mutual agreement, if some or any of their alternatives are compatible.

This is a perfect match of the first definition. The interface is carved in stone, the defined policies give room for variations, which offer some kind of “mutual agreement” at runtime. Thus I cannot see the difference between the definitions within the boundaries I just mentioned. Am I missing something? How can these boundaries be broken?

On August 24, 2006 1:41 PM, Jacek said:

I fully agree with the second definition, but it’s general enough not to be practically useful. As said by Hartmut, often there’s very little flexibility in contracts presented by services, so the client just has the option to accept the contract, and the advertisement by the service means that as soon as the client accepts the contract, the service does as well, and that’s the two parties in mutual agreement, so from this POV, “design by contract” is not lacking anything. Sometimes contracting will need negotiation, and policies are trying to solve part of that.

So, in short, I see definition 1 as currently practiced subset of definition 2.

On August 24, 2006 6:36 PM, Stefan Tilkov said:

Somehow this seems to echo real life: When you’re going to your post office, you’re not in a position to negotiate the contractual terms. When you’re CEO of a Fortune 500 company, you may well be able to get a very special deal.

Maybe the difference is that the first one is really only a special case of the second one? I.e. a contract is between two parties, but there’s also a default contract between the provider and the anonymous default consumer.

On August 25, 2006 8:03 PM, Anne Thomas Manes said:

As I said in my previous comment on this topic:

IMO a contract defines much more than just the service’s interface. A contract comprises all aspects of agreement between a service consumer and a service provider, and it includes, for example, the definition of the interface, the agreed-to intersection of the constraints and capabilities of both the consumer and the provider, any service level agreements in place between the consumer and the provider, etc.

I’ll add to the stuff listed above: - remuneration agreement - support agreement - enhancement agreement

As with policies, I think you can create generic contracts, which you can then customize and attach to a specific consumer/provider combination.

You should manage and maintain contracts as first class artifacts. Folks like Systinet and Infravio provide contract management systems for just this purpose.

In response to Stefan last comment:

When you’re going to your post office, you’re not in a position to negotiate the contractual terms.

That’s not true. You can definitely negotiate terms (at least here in the States, but I imagine most countries have similar options): - class of mail (express, priority, first class, third class, etc) - acknowledgement semantics (certified, registered, return receipt, etc) - insurance

People typically opt for the standard contract most of the time, but you do have the option of selecting special services.

On August 25, 2006 10:01 PM, Stefan Tilkov said:

Thanks for the comment, Anne. Of course you are right that it’s possible to negotiate terms in the sense that you can select from the available options; but that’s different from making up terms on the fly.

It’s also good to see that I misread (or rather, mis-remembered) your original comment, thanks for clearing this up.