I've begun to think that Web services really needs the concept of "registry of contracts," otherwise a large number of anonymous users of a WSDL interface is eventually going to make change management difficult.
WSDL & WS-Policy describe what the provider offers, but nothing in the WS-* architecture describes what the consumer accepts. A Web Service Contract Language (WSCL) would enable the description of what functionality, data, and SLs the consumer actually wants vs. what was offered. In many cases, the consumer will accept less than what is offered.
For example, a Credit-Check service may offer many elements in the XML document it returns, besides the basic yes/no element authorizing the amount. Yet many WS consumers only refer to and depend on the basic authorization element. Also, the WS may offer a response time of 3 seconds, but the consumer needs only 7 second response time. It would be nice to know which consumers would be affected by dropping or redefining an element; or which consumers could tolerate slower service.
These contracts would also form the basis for intermediary processing: since the contract describes what the consumer wants and what the provider offers, the difference between the two would be the requirements spec for the intermediary.
One vendor who's at least grappling with the issue is Infravio. Its WS Broker establishes a functional and SLA "contract" for every consumer/provider pair. This way, one can keep track of every consumer of a Web Service so that if one changes the WSDL interface, the impact on consumers can be managed.
6:34:38 AM 
