Todd Biske: Outside the Box

Phil Windley recently asked in his blog, “Is WS-MetadataExchange really necessary?” I would argue that it is, and is actually one of the cornerstones of really making system integration easier. Why? Well, someone else posted in the comments that we should focus on other standards, like WS-Security. WS-Security is exactly the reason why we need WS-MetadataExchange. Suppose I put up a web service and lock it down. I’ve chosen to support SAML assertions embedded within WS-Security headers. I advertise this service out, but only provide a reference to the WSDL. How will any client application know that WS-Security headers are required, and that only SAML assertions should be sent? Wouldn’t it be great if a client system only needed to get the WSDL file, and then through metadata exchanges at the time the service is invoked, the client endpoint would first ask for WS-Policy information, and find out that the service is secured and requires SAML? While that may not guarantee access if the right assertions don’t exist, the systems would have at least included the proper SOAP headers rather than rejecting the request for not having enough information. This is even more important as the policies around the service change. Suppose I now need to require that some data in the message be encrypted. While the functional interface doesn’t change, the policies associated with the message interchange have. With WS-Mex, the runtime engines would pick up the new policy and make the appropriate changes without having to rebuild the Web Services client.

If we want to move toward policy-driven computing, and enable policies to be quickly enacted without requiring a code/build/deploy cycle, WS-Mex and WS-Policy are necessary.