Regarding the continuing argument about the complexity of the WS-* specifications, Steve Maine repeats a couple of common arguments in favor of the specifications. Let me paraphrase:
- The individual specifications are not as complex as people make them out to be.
- The key to WS-* is composition -- use only what you need and ignore the rest.
Let me say up front that I don't mean to pick specifically on Steve about this, since others have said basically the same things.
First, I disagree about the complexity of the specifications. Anytime you're dealing with hundreds of pages worth of specifications, you're dealing with complexity. Some individual specs might not be complex, but when you put them all together, the result is complex, no two ways about it. Moreover, since most of these specs have never been vetted by an actual standards body or standards process, they surely contain numerous holes and ambiguities (compare SOAP before standardization to standard SOAP, for example). Private review workshops are no substitute for a robust standardization process.
The second argument about composition and ignoring what you don't need is also problematic. Given that there's no overall architecture spec that tells you how all these specs fit together, it's not always easy to know which ones you need and which ones you don't. (The lack of an architecture spec also means that new additions to WS-* just seem to appear whenever someone at one of the big vendors feels like it.) Second, how do you know you don't need something unless you understand what it is to begin with?
Before they collapse under their own weight and complexity, let's stop adding new WS-* specs, or at least considerably reduce the rate at which they're published, until we can get a WS-Architecture spec in place. I'm not advocating a waterfall process here, and the bottom-up approach that's provided the WS-* collection to date has its merits, but given how much progress has been made lately on resolving the great REST vs. SOAP debate, there's no time like the present to try (again) to reach industry consensus on the big WS picture. We all win if we can get there.
Comments (2)
Isn't the existence of a WS-Architecture spec only possible once the other specifications have run their course? Experimentation and implementation are the only two oracles, and if the early growth of WS-* has taught us anything, it is that the thought leaders can be wrong at first.
But that said, I like something along the lines of what you're suggesting: We need a notion of packaging and coupling for specifications along the lines of dependency analysis performed for package in a Java application. The wildcarded import statement is just as evil in WS-* as it is in Java...
Posted by Paul Brown | October 14, 2004 8:13 PM
Posted on October 14, 2004 20:13
Steve, I agree that something like a WS-Arch would be good. But removing my technical hat and sticking on my pragmatic hat for a moment, I don't see it happening for a long time. The reality is that there isn't the political will in the *entire* industry to do this, and there was (almost) in the early days of the OMG.
It's possible that is the usual split of vendors that occurred then (MSFT in one camp and pretty much everyone else in the other) occurred in WS that there might be a chance for a good WS-Arch, but that isn't the case and I don't see it happening on something as wide sweeping as this. That's not to say that it won't happen on individual specifications, but that's not sufficient.
Ignorning the attitude of specific vendors, one of the contributors to this problem is the plethora of standards bodies trying to get into the act. W3C, OASIS, WSI, OMG. What we need is One Body to Rule Them All (TM Tolkien ;-)
Posted by Mark Little | October 16, 2004 5:03 AM
Posted on October 16, 2004 05:03