In http://www.infoq.com/articles/poulin-governance, I have posted a diagram that defines Service Description. Service Contracts are derived from the Service Description and represent potential sub-descriptions that agreed between service provider and service consumer(s).
As of the message schema control versus a control at an intermediary, I think that 1) an intermediary may represent a bottleneck and a point of conflicting controls (different version would require different formats, etc.) 2) you can effectively control changing elements by manipulating message namespaces. This allows to deliver what was requested instead of what was available and save your consumers a lot of data related troubles that are, actually, the provider's problems. Example of manipulating message namespaces is in here: http://soa.sys-con.com/node/523434 - Michael ________________________________ From: Colin Jack <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, October 29, 2008 12:59:05 PM Subject: [service-orientated-architecture] Contract Design - Constraint Granularity Wanted to canvass some opinion on how you guys go about designing the contracts of your services and in particular how you tradeoff the advantages of very specific constraints in your contract against the problems this could cause in the future if/when things change. The topic interests me becaus we're doing an integration thats going to use a standard schema to communicate with a 3rd party, however most of the integration is going to be done using our own custom schema which has a lot of our own domain terminology/ structure build into it. So I'm wondering whether you would build constraints regarding things like country/address/ telephone codes into the schema itself or would you just allow anything that passes a simple regular expression through and just le the client or a run-time check in the integration platform catch any violations (e.g. passing in "GPB" instead of "GBP")? In some cases the decision is easy, if the data is very dynamic then you would definitely avoid putting it into the contract. However I'm interested in how you handle things that *might* change, even if changes will happen very seldom if at all.
