|
I think you've done quite a nice job of balancing a frank assessment of a preliminary draft with "serious engagement" with the still-fuzzy concepts. The fundamental challenge here is that "web services" is a marketing term not a technical one, and making sense of it all is really like nailing jelly to a tree. I certainly invite a wider group engage in the effort on the WSA public list and appreciate any serious discussion this article helps begin. I do (surprise!) think there are some powerful ideas at the core of WSA, although a) we don't fully understand them yet; and b) they bear only superficial resemblence to the utterances of certain big company executives; and c) the "web services" that you generate by pressing a button in your favorite IDE bear almost no relationship to the real value that, for example, SOAP brings to the table. (See http://weblogs.java.net/pub/wlg/118 for an elaboration on the real value of SOAP)
A couple quick points:
I *personally* completely agree that YAML would be a fine serialization format for Web services messages and RELAX NG a wonderful way to define the structure of the messages. The WSDL WG had a bit of a thread on making sure that RELAX NG was a "legal" message definition language, but I don't know where that ended up. Whether language along these lines gets into a W3C Recommendation is, of course, subject to forces far beyond my control; suffice it to say that there are no YAML or RELAX NG stakeholders raising their voices in favor, so there's relatively little incentive for a consensus-driven group to go looking for trouble. The agnosticism with respect to transport -- oops sorry Mark :-) "underlying communication" -- protocols, conversely, is because there are LOTS of stakeholders who want to send web services messages around with email, JMS APIs, BEEP, MQ or other proprietary message queueing protocols, etc. and they make their use cases known. Hint, hint :-)
The diagram displayed above is known not-so-affectionately in the working group as the "spaghetti diagram" so the critique is well-taken. The last couple of weeks of discussion on www-ws-arch@w3.org have featured an effort to model SOAP and WSDL in UML; now we need to re-visit the "spaghetti diagram" as an abstracted view of that model, and welcome any thoughts on which concepts are key at the architectural level and which are merely details of SOAP or WSDL.
I think I have a better understanding of the "REST vs WS" issue after yet another round with Mark Baker. I think we agreed that the essence of the REST approach is to expose fundamental resources to direct manipulation by the REST primitive operations; the essence of the SOA/Web services approach (which subsumes REST as a special case) is to hide the "real" resources and expose them via message-based, WSDL-defined interfaces.
A couple
|
Previous Message
