More from Bill

Bill responded to my response around his original posting. I'm not going to cut-and-paste everything here, but will concentrate on the main points again. I'll have to delete some of the text from Bill's blog, but hopefully I don't lose the context as a result:

"... I think the layers you have to have in sync are very different in size and complexity. While a REST over HTTP web service only really requires an HTTP client, HTTP web service, and maybe an XML parser, WS-* requires those plus all the WS-* libraries, plus any generated stubs. What I like about REST over HTTP you can actually tell the server what data format you’re sending (content-type) and what format you want back (accept)."

I think Bill's confusing implementations with what's defined by the standards. All WS-* does is state what flows on the wire, e.g., the format of a prepare call. It doesn't define interfaces per se (let's not get into the WSDL versus IDL debate) and really only defines the legal and standard ways in which endpoints can interact. How implementations choose to support this is outside the scope of all of the standards/specifications. Some do it well, some don't. In terms of REST, you still need some kind of programmer support when you think about it (what do you think is going on in the browser?)

Bill then looks at my point around defining the message formats so endpoints can communicate.

"Don’t you have to do the same thing with WS? You still have to agree on the message you are sending. What is the name of the remote method call you are invoking. What are its parameters. What is the data format of its parameters, and so on."

Yes, but that's precisely my point (remember, I said that there's no technical impediment to doing this - it's entirely political and monetary). The companies behind Web Services include IBM, BEA, Red Hat/JBoss, Oracle, IONA, TIBCO, webMethods/Software AG, HP etc. etc. etc. and they've spent the last 7 years defining these payloads and message exchange patterns. Sure it's complex, but when you have to do complex things the infrastructure becomes complex too, either explicitly or implicitly (hidden behind service endpoints). But my point is that it's done in Web Services and we have a set of agreed standards that allow us to do business over the intranet or internet with arbitrary vendors and an arbitrary number of those vendors. We don't need to sit down and argue what it means to associate a transaction policy with a service endpoint, or what it means to have a service fail in the middle of a business transaction. Those things are hard to agree on. Yes, we could do it all again around REST, but I don't think that's going to happen any time soon.

"I am officially in my late 30s. I did work through both the short-lived DCE and long-lived CORBA eras that touted the same story of interoperability. Sorry if I am skeptical and worried that the industry will yet again re-invent itself in another 5-10 years."

Same here, but add a few more years and distributed systems (yes, I feel old at times!) These things do go in cycles. I also have no doubt that Web Services are not the end result and we'll see more evolution and revolution to come. But at the moment Web Services have it. Plus, as I've said before, this is the only time since the start of the WWW that all of the major players have agreed on something like this. It never happened with CORBA. It isn't happening with REST.

"The idioms I described with jBPM use all three of these subsystems, but they do not require a remote protocol definition. As responsible engineers, we should be questioning the need for WS-*. The amount of investment is just too huge for any organization. There’s too much money and time to be lost."

I don't see it as black and white: this is precisely why I don't believe there is one good way of tackling everything. WS-* has its place. So has REST. But then again, a good ESB can help tie all of this together as well. As for the investment reference, I've done some of this in REST before and it was just as time consuming as WS-*. More so now when you have to fight against the WS-* wave of supporters (of which I am one, sitting on my fence).

"Why the need for BA if it is not going to do things automatically for you? If the line between your business process and your compensation engine is starting to blur, why not have your bpm and compensation engine be the same thing?"

BA can do things for you automatically. It just doesn't have to. Plus, don't think of a BA coordinator as being a separate (centralized?) service: all WS-BA defines is a protocol engine; where it sits is entirely up to the developer. So it could well be at the heart of a workflow system. One of the things I've been trying to show is that you still need a coordinator somewhere: something that remembers who and what needs to be done in a reliable manner. It doesn't have to have a narrow interface (commit or rollback), but can have complex ways in which its internal protocol is driven. That was one of the reasons behind the CORBA (J2EE) Activity Service. Hey, we have coordinator technology that'd let us do that!

"Not so sure this is true. If your content type is text/xml, you’ll probably have an XSD associated with it. If you use the design by contract to implement your web services that people like the Spring guys are pushing, you really have the same thing."

OK, so go and persuade Oracle, Amazon, Google, Adobe, Microsoft, TIBCO, company ABC, company XYZ etc. to agree to this and maybe we can start talking about a new global standard for information interchange.

"What I really want here is to have the client drive the application and simplify the complexity of the distributed protocol."

You should take a look at WS-CAF too BTW.

"This is why I said I really liked the idea of using BA with a web application. It would all be local and controllable. After reading up on BPEL compensation handlers, I also like the idea of using them with RESTful web services. Again, put all the responsibility on the client for managing the coordination. Then we don’t have a dual dependency on an in-sync client and server."

Well I still think you'll find that there's a coordinator hidden in there somewhere.