About a week or two ago, a blog wave was started regarding the increasing difficulty of keeping up with the web services standards process. Most blogphiles have probably read all this stuff, but since I don't post all that often, I'll make note of the highlights here: The release of WS-Transfer and WS-Enumeration, the initial salvos: Tim Bray #1, Mike Gunderloy, Simon St. Laurent, the rebuttals: Sean McGrath, Phil Wainwright, and Tim Bray #2.
Oh, and if you want to understand how all the WS-* specs fit together, Cabrera, Kurt, and Box have put together a whitepaper on it (very useful).
I'm still letting this digest. I've been pretty happy with the WS-* process -- some of these specs solve real problems, while some of them replicate solutions that already exist but in a transport-independent manner.
I'm struck by three observations, and opinions:
1. The dissenters mainly think that XML+HTTP (aka. REST) is enough. Let's be fair: add SSL to that for encryption / signature. And we don't have really interoperable authorization, just HTTP authentication here. Nor do we have any messaging semantics other than synchronous request/response. Granted, a lot can be done with this, but does this really make for good interop when we get into tougher situations? Let a thousand XSLT pages bloom to translate between different security, message correlation, and other plumbing issues?
2. Related to the above is that these specs haven't been fully baked -- some get deprecated before implemented, and we're not likely to see widespread (aka. Microsoft + 2 other vendors) support for these specs for months. It's dangerous to add complexity en masse, piecemeal is better.
I agree in general with this statement, but I'm not sure we're in a dangerous situation yet. I actually see the WS space undergoing piecemeal growth. We have the SOAP/WSDL/HTTP/SSL/XSD kernel today. Some use Relax-NG instead of XSD. That's pretty doable. Now, we're starting to seriously add WS-Security. Tomorrow, WS-ReliableMessaging will come. And then the others. I'm not sure how this isn't piecemeal. Perhaps because the specs are so widely viewable that it's confusing people. I always thought the specs were for specific audiences: leading-edge implementors and vendors -- not mainstream developers. If you're developing with XML+HTTP or SOAP today, and you're happy, what's the fuss? If you're not happy... well, is it a tool or protocol problem?
3. When I look at the specification page count that Tim and others put together, I'm struck by how FEW pages there are. At first glance 569 pages for XML, XSD, and base security specs seems a lot -- though out of this 409 pages are XSD, so perhaps the problem continues to be XSD vs. RNG & other simpler contract definition languages. Then there's 230 pages for the WS-Security family, which doesn't strike me as overly large considering how wide ranging the specs are.
Now then:
Only 21 pages for Reliable Messaging! 39 pages for transactions! This seems rather consise. For core plumbing, there's 111 pages for SOAP messaging from the W3C (which includes the primer and adjuncts, some of which cover miscellaneous / legacy techniques), and another 100 pages for things like events, REST-like transfer verbs, addressing, binary support, and UDP support. Again, not too bad.
I don't know what the fuss is. How big are these vs. the CORBA specs? How hard was this to understand in DCOM? How about any EAI vendor's reference manuals?
Once again, there are different audiences here. Most dissenters have probably never touched CORBA or EAI (though certainly some have and have lost hair from the experience :) and suggest no one should have to ever do that -- the internet proved everything can be done with HTTP! They may have a point, though I haven't been convinced it's applicable to ALL scenarios. The other audience wants web services as a better (more traceable, debuggable, maintainable) enterprise distributed system standard. To these people, there ARE legitimate reasons for these specifcations: some applications really do need standard eventing, some really do need asynchronous support (and hence addressing), reliablity, and a more sophisticated form of transactions than 1-phase "yay or nay". In my experience, anyway.
Perhaps these specs aren't actually going to solve these problems, and we should implement a widely adopted ad-hoc solution first before we trumpet out the spec. This is a good point and a reason why WS-* should be adopted with caution. But -- what else can one do? Use the older frameworks and have HTTP+XML or SOAP gateways for client-based interop. Server-to-server orchestration needs a one-vendor solution, whether Biztalk, WLI, or MQ Workflow. This seems to be the answer, for now.
Posted by stu at October 4, 2004 06:55 AM