What does "self-describing" in reference to Web Services really mean?

Question

I've heard a lot of buzz through the years about "Self Describing" web services and I'm curious what it means. I've flipped through the W3C standard and it doesn't really help.

I understand you can say "Give me this argument and call this functionality and I'll return something like this", but how is that actually helpful? How can software know what is relevant to a client given some context?

Can anyone give real world examples of this concept, and explain how it's better than some other alternative? Or maybe how useful/useless it is?

Answer 1

Here's explanation from IBM

Web services are self-contained. On the client side, no additional software is required. A programming language with XML and HTTP client support is enough to get you started. On the server side, a Web server and servlet engine are required. The client and server can be implemented in different environments. It is possible to Web service enable an existing application without writing a single line of code.

Web services are self-describing. The client and server need to recognize only the format and content of request and response messages. The definition of the message format travels with the message; no external metadata repositories or code generation tools are required.

Answer 2

It's really designed as a standard for describing in a cross-platform cross-language manner an interface that a developer can use to develop a SOAP based way to exchange information with a web service.

Another alternative would be providing a library that provides a local interface to a blackbox communcation scheme, which is fraught with compatability/security issues.

Or providing documentation, which may be difficult to find, have compatibility issues, be out of date, or incomplete.

In short, it's very useful.