Are self-described / auto-descriptive services loosely or tightly coupled in a SOA architecture?

I consider a self-described / auto-descriptive service as a good thing in a SOA architecture, since (almost) everything you know to call the service is present in the service contract (such a WSDL).

Sample of a non self-described service for me is Facebook Query Language (FQL http://wiki.developers.facebook.com/index.php/FQL), or any web service exchanging XML flow in a one String parameter for then parsing XML and performing treatments.

Last ones seem further more technically decoupled, since technically you can switch implementations without technical impact on the caller, handling compatibility between implementations/versions at a business level. On the other side, having no strong interface (diluted into the service and its v开发者_运维百科ersion), make the service tightly coupled to the existing implementation (more difficulty to interchange the service and to ensure perfect compatibility).

This question is related to How to Implement Loose Coupling with a SOA Architecture

So, are self-described / auto-descriptive services loosely or tightly coupled in a SOA architecture ? What are the impacts regarding ESBs ?

Any pointer will be appreciated.

The thing is that loosely coupled SOA services will tend to interact with each other using publish/subscribe semantics not supported by WSDL (which only supports request/response).

When you introduce an ESB like NServiceBus, it focuses on messages and ownership rather than the method invocations that tools generate from WSDL. Those messages can then be represented either as classes in code or in an XSD for interoperability.

The transportation of XML messages from one endpoint to another when done with standard web services does look quite silly as the contract doesn't appear in the WSDL, and that's one of the places where ESBs come in.

Hope that helps.