September 19, 2004
@ 10:14 PM

Tim Bray has another rant on the prolifieration of WS-* specs in the XML Web Services world. In his post The Loyal WS Opposition he writes

I Still Dont Buy It No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think its going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.

I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I cant help noticing that they dont seem to need much WS-apparatus.

One way to view the various WS-* specifications is that they are akin to Java Specification Requests (JSRs) in the Java world. A JSR is basically a way for various Java vendors to standardize on a mechanism for solving a particular customer problem. Usually this mechanism takes the form of an Application Programming Interface (API). Some JSRs are widely adopted and have become an integral aspect of programming on the Java platform (e.g. the JAXP JSR). Some JSRs are pushed by certain vendors while being ignored by others leading to overlap (e.g. the JDO JSR which was voted against by BEA, IBM and Oracle but supported by Macromedia and Sun). Then there's Enterprise Java Beans which is generally decried as a bloated and unnecessarily complex solution to business problems. Again that was the product of the JSR process.

The various WS-* specs are following the same pattern as JSRs which isn't much of a surprise since a number of the players are the same (e.g. Sun & IBM). Just like Tim Bray points out that one can be productive without adopting any of the WS-* family of specifications it is similarly true that one can be productive in Java without relying on the products of JSRs but instead  rolling one's own solutions. However this doesn't mean there aren't benefits of standardizing on the high level mechanisms for solving various business problems besides saying "We use XML and HTTP so we should interop".   

Omri Gazitt, the Produce Unit Manager of the Advanced XML Web Services team has a post on WS-Transfer and WS-Enumeration which should hit close to home for Tim Bray since he is the co-chair of the Atom working group

WS-Transfer is a spec that Don has wanted to publish for a year now.  It codifies the simple CRUD pattern for Web services (the operations are named after their HTTP equivalents - GET, PUT, DELETE, and there is also a CREATE pattern.  The pattern of manipulating resources using these simple verbs is quite prevalent (Roy Fielding's REST is the most common moniker for it), and of course it underlies the HTTP protocol.  Of course, you could implement this pattern before WS-Transfer, but it does help to write this down so people can do this over SOAP in a consistent way.  One interesting existing application of this pattern is Atom (a publishing/blogging protocol built on top of SOAP).  Looking at the Atom WSDL, it looks very much like WS-Transfer - a GET, PUT, DELETE, and POST (which is the CREATE verb specific to this application).  So Atom could easily be built on top of WS-Transfer.  What would be the advantage of that?  The same advantage that comes with any kind of consistent application of a technology - the more the consistent pattern is applied, the more value it accrues.  Just the value of baking that pattern into various toolsets (e.g. VS.NET) makes it attractive to use the pattern. 

I personally think WS-Transfer is very interesting because it allows SOAP based applications to model themselves as REST Web Services and get explicit support for this methodolgy from toolkits. I talked about WS-Transfer with Don a few months ago and I've had to bite my tongue for a while whenever I hear people complain that SOAP and SOAP based toolkits don't encourage building RESTful XML Web Services.

I'm not as impressed with WS-Enumeration but I find it interesting that it also covers another use case of the ATOM API which is a mechanism for pulling down the content archive  from a weblog or similar system in a sequential manner. 


 

Monday, September 20, 2004 1:21:46 AM (GMT Daylight Time, UTC+01:00)
I like the JSR analogy. One difference of course is that Microsoft exerts a lot more architectural influence over the WS-* stuff than Sun attempts over JSRs. I think that's generally a positive thing -- the successive versions of the MS document describing how it all fits together get clearer and cleaner, indicating at least some degree of "intelligent design" as opposed to "survival by consensus" if you will.

One thing I'd like to see, as as I tried to say in my java.net weblog, is more proactive attention to the obvious arguments against things like WS-Transfer. The MS architecture paper starts out by saying nice things about the Web, but doesn't say why HTTP+XML doesn't suffice to do what WS-Transfer does. Or to put it another way, the authors KNOW that people like Mark Baker are going to say something like "(ROTFL) ... HTTP over SOAP over HTTP! Who needs this?" Just explaining the use cases and best practices for using these things more clearly would go a long way towards moving these discussions forward rather than around in circles.
Monday, September 20, 2004 2:08:29 AM (GMT Daylight Time, UTC+01:00)
I like the JSR analogy. One difference of course is that Microsoft exerts a lot more architectural influence over the WS-* stuff than Sun attempts over JSRs. I think that's generally a positive thing -- the successive versions of the MS document describing how it all fits together get clearer and cleaner, indicating at least some degree of "intelligent design" as opposed to "survival by consensus" if you will.

One thing I'd like to see, as as I tried to say in my java.net weblog, is more proactive attention to the obvious arguments against things like WS-Transfer. The MS architecture paper starts out by saying nice things about the Web, but doesn't say why HTTP+XML doesn't suffice to do what WS-Transfer does. Or to put it another way, the authors KNOW that people like Mark Baker are going to say something like "(ROTFL) ... HTTP over SOAP over HTTP! Who needs this?" Just explaining the use cases and best practices for using these things more clearly would go a long way towards moving these discussions forward rather than around in circles.
Monday, September 20, 2004 8:39:09 AM (GMT Daylight Time, UTC+01:00)
Mike,
First of all SOAP isn't tied strictly HTTP. At the very least Sun has already announced numerous times that they plan to do SOAP as ASN.1 which they've decided to call Fast Web Services. Secondly, WS-Transfer allows you to build RESTful Web Services on top of the WS-* infrastructure like WSDL, WS-Security, built-in object<->XML bindings in various toolkits and so on.

Having a standard way of doing this instead of every one rolling their own as is the current case seems like a good idea.
Monday, September 20, 2004 2:23:16 PM (GMT Daylight Time, UTC+01:00)
*I* know that, but I'm sick of trying to argue the point with the "the web is all you need, we love it yeah, yeah, yeah" folks. I'd just like to see the use cases made more explicit in the WS-* docs to make clear what they think XML+HTTP is good for and what things like WS-Addresing and WS-Transfer add to the picture in the scenarios they are intended for.

For example, Tim Bray asks what WS-Transfer adds to *his* ability to write code that understands HTTP and angle brackets intimately. Obviously the answer is "not much." The question is what they add for the people who are working a hop or two away from the HTTP bridge or working with objects and APIs rather than XML serializations.
mike champion
Thursday, September 23, 2004 4:45:57 PM (GMT Daylight Time, UTC+01:00)
Actually EJB (for all its faulys) was NOT developed by the JSR process.

The first JSR relating to EJB is for version 2.1:
http://www.jcp.org/en/jsr/detail?id=153

Most people seem to think its gotten more responsive to real needs since it went into JSR.
Andrew Thompson
Thursday, September 23, 2004 4:51:26 PM (GMT Daylight Time, UTC+01:00)
Actually EJB (for all its faulys) was NOT developed by the JSR process.

The first JSR relating to EJB is for version 2.1:
http://www.jcp.org/en/jsr/detail?id=153

Most people seem to think its gotten more responsive to real needs since it went into JSR.
Andrew Thompson
Thursday, September 23, 2004 4:55:21 PM (GMT Daylight Time, UTC+01:00)
Actually EJB (for all its faulys) was NOT developed by the JSR process.

The first JSR relating to EJB is for version 2.1:
http://www.jcp.org/en/jsr/detail?id=153

Most people seem to think its gotten more responsive to real needs since it went into JSR.
Andrew Thompson
Thursday, September 23, 2004 4:59:32 PM (GMT Daylight Time, UTC+01:00)
Actually EJB (for all its faulys) was NOT developed by the JSR process.

The first JSR relating to EJB is for version 2.1:
http://www.jcp.org/en/jsr/detail?id=153

Most people seem to think its gotten more responsive to real needs since it went into JSR.
Andrew Thompson
Thursday, September 23, 2004 5:03:56 PM (GMT Daylight Time, UTC+01:00)
Just out of curiosity... if WS-* are like JSRs, what's the equivalent of the JCP? Where's the process documented, and what's the governance model? The statement "A JSR is basically a way for various Java vendors to standardize on a mechanism for solving a particular customer problem" ignores the fact that it's not just any old "way"; it's a particular "way" that has been publically codified, ratified by the community, and evolved to meet the needs of participants.

And then Mike writes, "One difference of course is that Microsoft exerts a lot more architectural influence over the WS-* stuff than Sun attempts over JSRs. I think that's generally a positive thing". Hmmm: does this mean that he and his employer were actively engaged in JSR-171, JSR-215 and so forth, arguing in favour of stronger architectural influence by Sun?
Thursday, September 23, 2004 6:34:42 PM (GMT Daylight Time, UTC+01:00)
Sun's Fast Web Services project is orthogonal to running SOAP over different protocols. Fast WS defines a new serialization (based on ASN.1) for SOAP and XML that, like XML based SOAP, can be used over multiple underlying protocols.
Marc Hadley
Comments are closed.