Defining Service Contracts with Angle Brackets... Yes/No?
Below is a copy of an email I sent to a buddy in Redmond (feel free to take a guess as to who it is). He's *very* against using XSD to define a service contract. I, on the other hand, am for it (though I have to say that he and others are beginning to sway me).
Anyone out there have any opinions? I'll post his response later because I want some honest feedback on this one. I'm about to define the architecture for a pretty large app, and the decision I make now I will have to live with for a l o n g t i m e...
<emailSnip>
So let me run this by you. I'm always open to opinions/critique...
-- If there's one thing I learned from doing VB.COM back in the day it's that using a programming language to define a interoperable, *language agnostic* interface can get you in trouble. The tendency to define concepts that are not understood by all consumers of the interface is to great. I understand that I am (very) loosely comparing Indigo to VB.COM, but theoretically the same issue exists. I understand there is a perfectly valid counter argument saying that you can define concepts in XSD that are not supported by all languages, but these are edge cases that are rarely an issue (substitution groups come to mind).
-- I don't have to see pointy brackets anymore. Tools like XMLSpy are getting better and better at abstracting away the pointy brackets. In fact, XMLSpy is getting close to being a DSL for defining the aforementioned interoperable interface. :)
-- The idea behind this whole contract-first hoo ha is that we define contracts, that represent documents that are passed from consumer --> service --> and (maybe) back. IMHO, there is no better (or more natural) method for creating a document definition than XSD.
-- I also love the fact that I can expose a XSD on a server-side endpoint and a consumer is free to use it in order to gain access to cursory business logic that would otherwise cost them a round-trip to the server.
Example:
int withdrawalAmount; // This could be 450,000
Vs.
<element name="withdrawalAmount">
<simpleType>
<restriction base="positiveInteger">
<maxExclusive value="400"/>
</restriction>
</simpleType>
</element>
My ATM limit per transaction is 400 bucks. In the XSD world, I can push that constraint down to the client for validation prior to sending me the entire document. Additionally, to validate it on the server, I don't have to write trivial code such as:
If(withdrawalAmount > 400) return false;
That stuff is handled for me by the schema validator.
</emailSnip>
Thoughts?
[Listening to: The Bravery - Unconditional]