Savas goes beyond the call of duty, and responds to two of my posts simultaneously. I’m glad he did, because the “uniform” question I asked came about as a result of my initial response to him. He writes;
However, doesn’t the consumer now need to understand the specification of the type that governs the returned document’s structure? Isn’t this similar? In fact, I think it’s worst because the service may return information to a consumer that the consumer did not understand. Hence, we allowed an interaction to take place for nothing.
I’d say that the capacity to receive data you don’t understand is highly underrated. 8-) What you might not understand now, you might understand later.
So, my view on this is pretty simple; stuff that changes shouldn’t be fixed in a design-time element like a service description. IMO, that includes the schema(s) that a service inputs and/or outputs. Which brings us to …
One of SOA’s principles, as described by Don Box, suggests that services will only interact with one another only when they have determined, based on policy assertions and metadata about the document structure of the information, that they can meaningfully exchange information.
Ok. But as I see it, until some advanced form of AI comes along, a service will only ever interact with other services that conform to the preconceptions hardcoded into it. A constrained interface (the uniform interface, in particular) shines when you keep this in mind, because it suggests that any service can exchange information with any other service. If Web services don’t do similarly, then they have necessarily forged islands of interoperability (where each island is comprised of all services that share the same preconceptions).