As the WS-* specs, tool support, and SOA in general evolve there are numerous design discussions and tradeoffs to navaigate that come back to a central theme: how much should be built into the framework versus how much should be left up to programmers? Kim Cameron blogged a richly illustrative example in WS-MEX v. HTTP-GET. Among other points, Kim posed an interesting design goal to strive for:
"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?"
Adam Bosworth and Tim Bray both come down squarely on the side of simplicity. I am usually in this camp as well. One of the keys to longevity, IMO, is simplicity, and I think the example of J2EE superseding CORBA is one example of this. But in this specific case I am not sure that we are comparing apples to apples (or even apples to oranges (which are both round, edible, and grow on trees)). For one thing the WS-* is working to deliver interoperable security standards, which we have not previously had in the industry. While it is certainly true that developers can build secure code with HTTP-GET/REST - style services, in general I would rather take my chances at having this built into the framework where it can be tested and analyzed by the industry as a whole. The same approach as with other security mechanisms such as declarative security in J2EE and cryptographic functions which are developed as reusable modules externalized from the end developer's code.
But having said all of that, the trap WS-* must avoid is to make the specs useable by a wide range of developers and implementations.
Comments