"Philosophically contract-first is a good idea because it elevates the exchange of business documents to be the primary artefact around which systems are built. Modelling such exchanges leads to integration at a high level and should in turn lead to solutions which are suitably loosely coupled.
However, pragmatically contract-first is hamstrung by the contract languages which Web Services practitioners have at their disposal. WSDL is cumbersome and provides the wrong set of abstractions, while WS-BPEL is heavyweight and relies on WSDL. Given the prevailing conditions, contract first is fraught with difficulty when contract languages are brittle and unwieldy.
Using WSDL as the contract language for contract-first development may require some creativity at best. At worst the contract language will constrain the underlying service implementation resulting not so much with a robust Service-Oriented Architecture but a rather limp RPC-ish one. If that is the case, then it makes sense to drop WSDL in favour of some other contract language whether that is SSDL, BPEL, or simply schemas and natural language descriptions of message exchanges. Ultimately it boils down to the fact that the services are there to support the business and the contract language must be able to capture business interactions. A contract language should enable rather than constrain business protocols: the tail, after all, does not wag the dog."
Having said this I must look into SSDL, when I first started down the path of integrating hotel systems for chains I was doing it using XML over HTTP using MSMQ as asyn layer. Things were simple before we had SOAP, WSDL and WS-I, does anyone remember ebXML looks like it may have died a natural death.
Going by SSDL we should just have schemas and use SOAP to transport it without the constraints of WSDL....hmm not a bad idea eh..........