Wednesday, February 23, 2005
« List of ORM tools, code generators and r... | Main | The Intersection of Objects and Services... »
Just a super-quick entry that I'll hopefully follow up on later. Ted wrote a bunch of stuff on contracts related to Indigo, etc.
 
I think this is all wrong-headed. The idea of being loosely coupled and the idea of being bound by a contract are in direct conflict with each other. If your service only accepts messages conforming to a strict contract (XSD, C#, VB or whatever) then it is impossible to be loosely coupled. Clients that can't conform to the contract can't play, and the service can never ever change the contract so it becomes locked in time.
 
Contract-based thinking was all the rage with COM, and look where it got us. Cool things like DoWork(), DoWork2(), DoWorkEx(), DoWorkEx2() and more.
 
Is this really the future of services? You gotta be kidding!

Wednesday, February 23, 2005 3:57:02 PM (Central Standard Time, UTC-06:00)
I can't wait to read your follow up on this.

If not Contracts - then what?

(I think I know your thoughts, but I'll wait)
Wednesday, February 23, 2005 4:39:27 PM (Central Standard Time, UTC-06:00)
I believe the answer is Contracts with the proper use of xml. (xsd:any and the Open content model) This is a hard sell however as the tools are not up to the task yet.
Jim Kieley
Wednesday, February 23, 2005 10:55:38 PM (Central Standard Time, UTC-06:00)
Why is it so hard to come up with a new XML that is stored and serialized binary, and you can put minor script based validation right into it?

Not to mention, everytime you double click on it, the operating system natively shows it as text - so the end user never knows the difference?

I Call it "BML".
Monday, February 28, 2005 9:16:32 PM (Central Standard Time, UTC-06:00)
How about all services use the same contract?
anonymous
Comments are closed.