Interview: Mark Little on Transactions, Web Services, and REST

It clearly shows that the BIG Companies were driving the specifications, as usual these will end up in complex stuff, which only help them selling products which are extremely complex ;)

I think they (BIG Companies) probably wanted to make WS-* some kind of Rocket Science, especially looking at the number of specifications and two different major standardizing agencies (W3C & OASIS in WS-* Space) causes further more problems for standardization itself.



Best part of presentation was Mark mentioning a hand in hand approach of REST and Web Services in general, it really make sense to say that. Enough of REST vs (ALL of the rest), we all know neither REST solves all the problems nor WS-*. Mark was very clear about the fact that both have their goods and bads.

BTW I will be more interested in an interview explaining best things of REST, particularly implementing a real life application using RESTful principles and situations under which RESTful approach is appropriate.

A good interview by Stefan, but an entirely useless set of responses from Mark. I don't normally find interviews as irritating as this, but it was pretty typical from a standards body member. Lots of talk, and little action. Where is all of the WS-TX support? Spring WS, CXF, even JBoss WS -- nope. Axis2 + Kandula2 say they have it, yet according to the site, Kandula2 has not been active at all (still in 0.1-SNAPSHOT, site last published 14-May-2006). The current state of WS-TX is perhaps that those that have created the standard (Microsoft, IBM, etc.) are the only ones that end up implementing it, simply because they have the standard, not because it's needed or even valid.



On REST: stop calling it "REST over HTTP". REST without HTTP is just RPC with POX, no? The whole point of REST is to use the "fabric" of the internet -- HTTP (yes and the underlying protocols). Content negotiation, HTTP verbs, response codes, URIs, etc. You can't take the HTTP out of REST.

You should do your background homework before posting. Take a look at JBossTS (XTS) for WS-TX support for instance. Plus, JBossTS has been at the forefront of practical engineering efforts in long running transactions for nearly 20 years; and from a practical perspective not an "ivory tower". WS-TX support in CXF was discussed a while back but there hasn't been the resources: we (JBoss) suggested adding JBossTS bindings to it and would still do that when there's time. Metro supports the WS-AT component of WS-TX despite the fact that Sun didn't participate in the WS-TX technical committee. webMethods has WS-TX support in Fabric back in 2004/2005. Oh and it's pretty common for "those that have created the standard" to implement it: otherwise it's a pretty pointless exercise!

And REST is an architectural approach, with the Web as the best example of what's possible. But REST does not mandate HTTP. Have you not heard of REST-over-JMS, for instance? Or didn't you catch our WOA article the other week?

To quote from Roy's dissertation:

"REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components [...]"

And if something has to be supported by Spring and CXF to be meaningful then I think I'll hang up my hat and retire. No disrespect to either of those communities, but for good reasons they can't always be at the forefront of everything.

Yes, I have done some homework. I was hoping that I could in fact use WS-TX for my own purposes, but was woefully dissapointed to not find as much practical, implementation information as I had hoped or expected. I didn't expect it to be difficult for a simple, "busy developer" to find this stuff. However I will gladly look at JBossTS to solve my problem, thank you for that. I certainly did expect more implementations to be out there though, wouldn't you?



I did not mean to imply that simply because Spring WS or CXF don't have it, then it's not good enough. But if this has been in development for some years now and major open source projects aren't supporting it, it certainly makes you wonder, doesn't it? You probably feel differently since you have been intimiately involved with it, but for an outsider, it's a bit different.



Re WOA article, you mean the one that quotes, "Resources are manipulated by HTTP verbs (GET, PUT, POST, DELETE)"? Hopefully I'm not taking that out of context. I would love to see what REST-over-JMS looks like too, since I have in fact not heard of it (SOAP-over-JMS I have).



I'm not at all interested in starting a "flame war", I do appreciate your point of view.

I wouldn't get too bogged down on the WS-* complexity. The need for extended transactions (weakening of ACID semantics) goes beyond Web Services or REST. As a developer, you should be able to have long running "transactions" (maybe Sagas based, but doesn't have to be the case) in whatever environment you are using. That's where true extreme transaction processing comes in: it's not just the rate at which you can process transactions, but also the scale of the problem (both number of participants and physical locality), which require these models and implementations. And we can definitely make them easier to use.

Hi Josh. No flame war intended :-) I think the implication I was a "standards person" stung ;-) Although I've been involved with standards for more years than I care to remember, it's always been from the practical perspective: pushing user-driven implementations into standards.

I'd love to see more implementations of WS-TX out there, just as I'd love to see more use of transactions across the board. But transactions are a very hard sell; take it from someone who has been trying to do it for 20+ years: persuading someone that they need something that only shows its benefits when there are failures that don't happen often, is really difficult to do. I think that has affected the take-up of transactions in lots of sections of middleware, not just Web Services. As a die-hard transaction guy, it scares me that there are systems running that really should have transactions (even "just" normal ACID transactions) and don't.

There's also an aspect of complexity here that doesn't help matters: transactions are hard to do right and this often puts people off. This isn't an open-source vs closed-source issue either: there are (were) closed source transaction managers that didn't really cut it because the developers didn't bother working on the "edge cases" (e.g., recovery). But it's the "edge cases" where transactions really give benefit.

As for REST support for something other than HTTP, I know a couple of groups have been talking about JMS (JBoss definitely, I think Jersey). I believe Roy is also still working on waka (en.wikipedia.org/wiki/Waka_(protocol)).

Yay, we're all still friends! I certainly have nothing against standards or standards bodies, and this is one place where it seems necessary particularly when involving disparate systems from multiple vendors (MS, IBM, etc.). I wonder what your thoughts are on architectures and approaches that advocate not using spanning transactions such as those of eBay and Amazon.



I would agree that the "REST style" can be acheived without HTTP. However again, in practical terms, I don't see it (for now at least) living without HTTP. Waka looks fun though!



Thanks for the replies...

I think Mark's intent was to distinguish between REST as an architectural style and a REST-compliant (or "RESTful") usage of HTTP and other Web protocols. (Correct me if I'm wrong, Mark.) "REST over HTTP" wouldn't be my first choice, but it's as valid as any of the other complicated expressions one can come up with to minimize flames from what Paul Downey called "Roy's posse" :-)

You're right with my intent for the term "REST over HTTP" Stefan. I didn't want to use WOA ;-)

The ebay/Amazon approach is interesting and would fall within the general concept of extended transactions. It has some similarities to the WS-BP model in OASIS WS-CAF, which was based on real world experiences some of us had (specifically HP) around REST transactions in 2000: funny how things go around.

Looks like there was intent to Chroma-key some tropical background (or perhaps leaping over tall buildings) but the opportunity was lost.

Shame.

What is the future for standards like BTP also is there an equivalent for WS-Context in WS-TX ?

BTP and WS-Context are both OASIS standards so they'll continue to exist, but the reality is that none of the major vendors support BTP (some of the more important concepts are available in WS-BA anyway) and only Oracle, IONA and JBoss have implementations of WS-Context. I don't know what's happened to the Oracle and IONA ones since we finalised WS-Context, but I suspect they aren't in product. But many of us still think that WS-Context is important.

Is there an alternative or something similar to open-top control exist in WS-TX ?

I was actively involved in the creation of Web Services. A goal of that technology was to enable interoperability among platforms, so that you can have code written in Java invoke code written in C++ and later on - .NET when that came along.

REST does not support a contract based approach, so it does not support this kind of interoperability. All I hear is that its lightweight. Well, it lacks a lot of functionality, which is why its lightweight.

I don't mind using REST where it can be beneficial as a lightweight framework.

A friend of mine is architect in a big IT shop and was doing a huge project at a local telco. They needed to automate the process of reserving a phone number for a customer, and tried to do this with BPEL/SOAP.

It more or less went like this:

-reserve the number for the customer (in one backend service)
-do workflow stuff
-bill the customer
-...

One of the particularities that I remember: they needed to be able to reverse a composite process when it failed at the end, i.e. when billing the customer failed. The number from step 1 had to be freed up again. And: they needed to be able to change the process (business agility) within every x weeks.

Now, I remember my friend complaining that this was nearly impossible, especially the reverse logic. Had they used transactions, they would have been focusing on the happy path instead.

My point: IMHO we are still at the dawn of a new age where service composition will happen (some day). When that day comes, I bet a lot of us will looking for some transactional guarantees.

However, today, for your facebook page all this won't matter I guess; not yet at least...


Best
Guy
www.atomikos.com
Transactions for SOA and XTP