Contracts define agreement

After reading various comments to my somewhat inflammatory post, I feel like we're really getting to the heart of this discussion - and don't consider it a waste of time at all - unfortunately it seems I'm not getting my point across well. If there were only a better language to express myself in... ;-)

 

First take a look at Don's comments:

 

 

Don also encouraged everyone to read Steve Maine's post on isomorphism, which should be prerequisite reading for anyone interested in this topic. Kudos Steve. Excellent job summarizing the issues and terminology surrounding the different perspectives in this thread.

 

I agree that isomorphism is everywhere at the conceptual level in this discussion, however, I disagree that we've come close to achieving isomorphism across different contract authoring languages in practical terms. In other words, Don's #4 above is a bigger issue than we think.

 

The problem is more than just determinism, it's about whether the developer understands the consequences that local type selection can have on #2. That is precisely the gist of Steve Vinoski's recent post.

 

I agree with Maine that if there is a single source of truth, the "true" contract is the XML message on the wire. However, the pragmatist in all of us (especially in Clemens) wants tools that make it easy to produce such messages. Our tools require a description of the messages to figure out how to hide the XML details from us in our code. The description is what both sides of an interaction use today via their toolset. The description of the messages negotiates an agreement between parties interacting via Web services.

 

Contracts define agreement. Period.

 

I don't care what language you use to author a service, but the contract is the artifact that you exchange with other tools wanting to use it.

 

The language contracts are written in is going to differ depending on the parties involved. A contract used between two Indigo-hosted parties will look much different than a contract exchanged heterogeneous parties. Not only will they be expressed differently, they must also be designed differently.

 

For me this is a reality.

 

Another reality: contracts authored in the language used to share them usually turn out better. Avoiding translation prevents domain-specific things from slipping into the contract.

 

I come at this discussion from a perspective where widespread interop/reach is an assumption and one of the primary goals during design. I know this isn't always the case, but this is how I typically look at the situation. Perhaps this is where my perspective differs the most.

 

Seeking reach greatly impacts your contract design.

 

You could author contracts with #1 above, but it's useless to our tools. And we all want the tools' help...no one's arguing against that (except maybe the POX folks). You could also author contracts with other schema languages like RNG or some other obscure schema language, but then your interactions will be constrained to those parties that understand that particular language, and can accept the contract. That's cool but across the industry XSD/WSDL/Policy are the most widely understood and increase your reach via tools.

 

You can also author contracts using powerful tools and visual designers (a la Whitehorse and beyond), which shield you from the complexities of the languages while still allowing you to author in it. This is ideal imo. I've been ranting about this for some time now and believe the reason more developers don't buy into the contract-first approach is because the vendors don't provide such tools. This is where I'd personally like to see things go in the Orcas timeframe. I don't expect or believe that developers should have to author service contracts using angle brackets (is that clear everyone?) but I do think they should understand concepts like simple and complex types, interfaces, bindings and the likes.

 

I think the biggest risk affecting reach is in authoring with code-centric DSL's (domain specific languages) and then using a not-well-understood translation layer. The fact that these languages are 'domain specific' is problematic in and of itself when it comes to establishing agreement. Automatic translations have proven difficult in the past when it comes to interoperability and reach. This is not opinion, but rather a hard fact proven in recent years. In practical terms, you'll do better with reach by avoiding translations when authoring contracts you plan to share with variant frameworks.

 

Could Indigo change all of this? Perhaps. It depends how tight it is wrt #5. Only time will tell.

 

Another clarification: none of these comments are meant to be negative towards Indigo. In fact, they're completely orthogonal. I've been working with Indigo for quite some time and I love the programming model - it has really grown on me even though they keep changing it. ;-) As Don has clearly outlined, Indigo supports authoring contracts using a variety of different models, including contract-first. Like ASMX, Indigo allows you to choose the development approach that best fits your needs (reach vs. productivity).

 

What would really make me happy are better tools and designers that facilitate designing Web service contracts, without having to look at angle brackets, or even code for that matter.

 

Whitehorse is a nice teaser but we definitely need more.