Anatomy of a Service Contract

As companies actually begin to implement SOAs, they are starting to ask questions about key essentials such as: What goes into a Service Contract?

As Ronald Schmelzer from ZapThink explains, the Service Contract is an agreement between producer and consumer that "loosely couples the relationship" between the two. This is a contract "that stipulates IT 'rules of engagement' in a standardized manner that both the consumer and provider can understand." 

Loose coupling is made possible "by implementing contracted interfaces on systems, and making sure that we enforce those contracted relationships while allowing each party to independently change how they implement the contract," Schmelzer adds. According to ZapThink, here are some of the key aspects of a contract: 

• Contracts should describe functional requirements, that is, what a provider will give to any consumer that chooses to abide by the terms of the contract. The contract should define what functionality the provider provides, what data it will return, or typically some combination of the two.
• Contracts must also specify nonfunctional requirements that detail not what the Service does, but the way in which it goes about its business. This includes information both about the responsibility of the providers for providing their functionality and/or data as well as the expected responsibilities of the consumers of that information and what they will need to provide in return, such as availability, security, and other quality of service considerations.
• Contracts also specify the rules of engagement between consumers and providers, known as policies, that govern who can access a provider, what security procedures the participants must follow, and any other rules that apply to the exchange.

As Schmelzer concludes, "one of the most important activities that a company can do is to define their contracts and policies in a language that humans can understand...If people can focus on developing contracts instead of code, we’ve already made significant progress toward building loosely-coupled systems. The next step is then to encode those contracts and policies to make the Services actually work."