Phil Windley just posted a comment on WS-MEX, where he asks why we need it…
I’ll admit it: I don’t really get WS-MetadataExchange (or WS-MEX, as it’s affectionately known). I understand why someone might want to get the Scheme, WSDL, and WS-Policy data for a service. I’m just not clear on why a simple URL isn’t good enough. Why do we need to invent new RPC-style request/response pairs?
I guess I can see that this allows me to have one URL for the service that can be interrogated for all three in a standard way. Otherwise, I have to tell you three URLs to give you the metadata instead of one, but couldn’t we just as easily agree to some kind of convention like this:
http://www.example.com/service_path?meta=wsdlhttp://www.example.com/service_path?meta=schemahttp://www.example.com/service_path?meta=policy
This seems much simpler and easier to implement that a request response pair. Plus, I can still grab each of these important documents in a browser and inspect them when I want without having to have a special tool. Am I missing something?
Before turning to the specific issue of why metadata exchange works the way it does, let's think for a minute about why you need it in the first place. The intent is to allow web service providers and consumers to be loosely coupled and negotiate the interfaces, infrastructural services and functional units they require.
To get more specific, let's take an example clear to those of us who work in the identity space. In previous discussions, we've drilled into the advantages of conceiving of digital identities as sets of claims. How would a relying party specify the specific claims it requires? How would it specify the parties from which it is willing to accept such claims (I'm struck by how easy it was to avoid the use of the word ‘trust’ in this sentence)? How would it indicate the types of underlying technologies and token formats which could be used to convey those claims? Finally, how can we create an infrastructure that subordinates, to the extent possible, these decisions to dynamic operational policies, rather than requiring software designers to hard code them?
Clearly Phil understands these motivations, and his question is about the design choice in using a new (if hyper simple) protocol rather than a basic HTTP GET.
To round up the best possible answer, I pinged Don Box, a person of great depth and wisdom who thinks about these issues as long and hard as people like us think about identity issues. He answered this way:
Since I was one of the offending parties, let me try to make clear why we did it.We wanted a way to retrieve metadata for services using the same protocols we use to talk to those services.
It’s tempting to just use HTTP GET with query string hackery. In fact, this is exactly what we did in V1 (ASMX).
However, here are a few issues with that approach:
- To date, we’ve avoided telling people how to form their URI. We’d like to keep it that way if possible.
- Not all services will support HTTP. In Indigo, it’s common to expose an endpoint that only listens over IPC or SOAP-over-TCP.
- We wanted metadata retrieval to compose with things like WS-Security.
- We wanted to have one discoverable mechanism that would scale to arbitrary forms of metadata. In its simplest form, a MEX reply enumerates all of the supported metadata formats a given endpoint supports. For people building generic inspection/diagnostics/management tools, this is pure goodness.
All of this stated, ASMX still supports ?WSDL as does Indigo (if you enable it).
Using plain-old-HTTP-GET isn’t a bad solution – it just doesn’t always work. When it does, though, it’s a beautiful solution.
You can see why I'm so fond of Don. Someone designing protocols who cares as much about inspection and diagnostic and management tools as he does about the specific value of the protocol. Maybe time really is moving forward.
