I got what I hoped for. Mark Little responded to my previous blog. Cool, now I’ll really start to learn something…. Let me respond to some of his comments:
Bill: “One of my concerns is the complexity of the WS-* layer and how it affects maintainability and evolvability of a distributed system. WS-* requires both the client and server to have the necessary middleware components and libraries installed to work.”
Mark: Yes, but that’s the case for any distributed system: the endpoints have got to be able to understand each other or go through some intermediary that can do the protocol/data translation. The same is true for HTTP though.
Mark’s right, I said something obvious, but 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). Maybe there is something equivalent in the WS soup of specifications, but it doesn’t seem like that is what the industry is pushing as its default framework.
Bill: “What I continually like about REST over HTTP is that there is little to no requirement on either the client or server side for additional libraries or generated stubs other than a http client library and a http server.
Mark: So let’s assume we can get everyone to agree to use HTTP (not a big assumption, so I’m happy with this). Then we have to get them to agree to the protocol data, the format, representation, etc. that actually flows between the endpoints. It’s no good someone saying “because we agree on PUT or GET that’s the end of the story.” That’s a bit like saying that because we agree on using letters and envelopes to send mail around the world the recipients will be able to understand what’s being sent!
Its eerie. I gave the same argument to Vinoski over private email months ago, but then I thought about it a bit more. 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. What allowed me to break the internal conflict I had was when I came to this realization: What if you think of PUT, GET, POST, DELETE, and OPTIONS as a set of metadata?
@Put void createOrder(Document theOrder); @Delete void deleteOrder(int orderNum); @Get Document getOrder();
Maybe I’m crazy, but these HTTP operations are really nothing more than annotations on a method. In using REST over HTTP, yes, you still have to agree on the data format exchange, but you are providing clearly defined, distinct, exact, metadata on the behavior of your endpoint. Behavior that can be generically communicated to mature tools and services that have been around forever that your operations department knows how to operate and fine tune your application with.
Mark: The Web works because the standards/specifications on which it is based were laid down back in the early 1990’s and haven’t really changed. The W3C manages them and everyone agreed to abide by them very early on; there’s strong commercial incentive not to change things. That has nothing to do with REST and everything to do with protocol agreement: same thing has happened with WS-*.
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.
Mark: Yes, we have interoperability on the WWW (ignoring the differences in HTML syntax and browsers). But we do not have interoperabilty for transactions, reliable messaging, workflow etc.
A wise man once told me if you run into a wall, redefine the problem. To me, that’s what the whole REST exercise is, redefining the problem in distributed computing. The whole underlying point of my previous blog was that maybe you don’t need interoperability for transactions, reliable messaging, and workflow in a distributed environment, if you let the client drive the application. Yes, you need transactions, reliable messaging and workflow at the client. 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.
Bill’s next point was around flexibility. He mentions the ordering of compensations can sometimes (often?) be important and that you can’t rely on ordering within WS-BA. Unfortunately that’s not correct, as was pointed out several years ago.
Apologies. I didn’t make this mistake intentionally. The article Mark points out was one of the things I read before writing my previous blog. The talk of scopes was a little confusing there. Seemed more of talk of nested transactions than the control of ordering. But, even so, I still don’t get the need for it. 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? Cuts out one less piece of infrastructure you have to install and manage.
So just because I decide to use REST and HTTP doesn’t mean I get instant portability and interoperability. Yes, I get interoperability at the low level, but it says nothing about interoperability at the payload. That’s damn hard to achieve, as we’ve seen over the past 7+ years.
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.
Bill: You still have strong decoupling in a bpm driven activity. The difference is that instead of compensation being hidden by the server, it is visible, and in your face, embedded directly in the business process. With jBPM, you can look at the process diagram and know exactly the flow of success and failure conditions of your distributed application. With BA, you would have to dive into the documentation and code to determine how your application functions.”
See? I knew I’d learn something. But when I said “a bpm engine like jBPM might be a better solution to manage compensations.” I meant any bpm engine. What I really want here is to have the client drive the application and simplify the complexity of the distributed protocol. 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.