TheArchitect.co.uk - Jorgen Thelin's weblog

The Need for Interface Definitions

I completely agree with Don here - I think what Dave means by "standards" are always "his" protocols. As an example, is there a WSDL definition of any XML-RPC API anywhere? The industry (as a whole) has moved on since the days when all we had to work with was SOAP encoding.

For me, everything that is wrong with Dave's viewpoint is summarised in this one statement Dave made way back in 2001, and which I don't think Dave has moved off since:

SOAP 1.1 is the contract

The challenge is no longer _SOAP_ interop anymore, but _Web Services_ interop. To achieve that requires an unambiguous definition of the service interface or contract. That's exactly the reason why WS-I had to deal with the WSDL and SOAP specifications side by side rather than separately (not least because there are several inconsistencies between the two specs!)

The lack of interface definitons always seems to me to be one of the biggest problems with XML-RPC APIs - there is no machine readable definiton of the API or message formats, just narrative descriptions.
Incidently, the same is true in general of REST too, which I have mentioned previously - "Does REST need WSDL?".

Without an interface definition, there is no real contact for the service.
Without a contract definiton, then application interoperability has to be achieved (and tested) on a point-to-point basis, which does not scale beyond a small community.

All of the above are part of the reason I think why there has been a lot of attention recently on "Evolution of the Weblog APIs" and a "SOAP Blog API".

Put simply, an application protocol without an interface definition is unusable to my mind.