HP has released at technology preview of HP Web Services Transactions (HP-WST) the industry's first implementation based on OASIS' Business Transaction Protocol (BTP). HP-WST enables Web services to reliably transact outside the firewall, among many parties, over long durations of time, without blocking underlying resources. HP-WST currently only supports HP AppServer 8.
Check out HP Web Services Transactions
By reading through http://www.hpmiddleware.com/downloads/PDF/business_transactions_on_the_web.pdf,
I understand, that each action requires the implementation of a compensating action, that recovers the changes committed when the action was executed.
However, which mechanism guarantees, that the compensating action _does_ commit, when the original transaction attempts to rollback?
I didn't have time yet to study the whole PDF, but it seems to me that this issue is acknowledged in the PDF (page 5, 1st paragraph) and no solution is provided, just "tell the system administrator and let the humans <Ferengi accent> solve this".
Hi, I'm the architect for HP's Web Services Transactions product.
HP-WST is based on the OASIS BTP (as the publicity blurb mentions). BTP doesn't mandate a particular type of participant implementation, so you can have implementations based on forward (compensating) and backward recovery. The ones you're probably most familiar with would use backward recovery, but in order for them to work they typically require resources to be locked for the duration of the activity (transaction), otherwise you could end up with what's known as a cascade rollback (where someone reads dirty data and does something based on it but you then want to retract that). ACID transactions fall into this category.
Now, this is fine for some kinds of business (e.g., I'd always like my bank to transfer money for me using this type of transaction because if there's a failure I don't want to lose money for even a minute). However, there are other business cases where forward compensation is a better fit, where the transaction is long-lived, for example.
Now, if we stick with backward compensating transactions alone, it's pretty easy to write a single participant (the entity that gets told to commit or roll back the work done within the scope of the transaction) for all time. To all intends and purposes, the participant that works for one XA-aware db will work for all (they typically use a shadow-state approach, where the new state exists alonside the old but in a slightly different format or name; then on commit the new state becomes the "old" and the "old" is removed, or it is deleted if the transaction rolls back.) No semantic information is required to be possessed by this participant - it works only on a blob of data.
With forward compensation things get a little more tricky. You now typically need semantic information (e.g., what does it mean to roll back an operation when the operation was to buy an airline ticket?) This tends to mean that the participants are more closely tied to the services/objects that they work on behalf of.
However, as the original question asks, what if the "undo" operation fails? Well, this isn't actually a question only aimed at forward compensation. What if the "undo" fails for the traditional ACID transaction system, which used backwards compensation? It is possible (e.g., catastrophic disk failure). In both situations we can end up with heuristics (or in BTP-speak, contradictions). Basically, we can never guarantee atomicity, but we'll try to the best of our ability and if things go wrong then we'll report as much information to the admin or user as possible to enable them to try to figure it out. But I can't stress this enough: we won't do this unless it is absolutely necessary! Any failures will be assumed to be transient and we will keep trying as long as it makes sense (or, more accurately, for as long as the sys admin has configured the failure recovery system to retry for.)
Hope this answers the question. If not, just let me know.
Hi Bob. Hopefully if you read the other email I've just sent this will answer your original question. Basically, every service does not need to write a compensating action. If you want to use backward recovery (and, for example, wrap a db via an XADataSource) then you can do that. In fact, the next release of HP-WST will have support for this and close integration with J2EE compliant transaction services so you can flow transactionality across different domains. It's out intention to try to tackle the 80/20 case and make it easy to write fairly complex transactional web services.
All the best,
great article. Especially the first half. If you want to know why web services are way too young to be used, but how architectures are emerging to try and work with them then I'd recommend the read.
I have steared clear of web services because of security, and now I have even better reasons!
I was actually meaning to be more upbeat. What I mean to say is 'Thank-you Mark, very clear, and approachable paper, hardly any jargon.'
Actually the protocol on which WST is based (BTP) isn't that new. The issues involving forward and backward compensation have been known about for well over a decade and used in other, non-WS environments. Forward compensation techniques are much more appropriate to optimistic applications/services, where things tend to go the way you'd think and so why bother with locking resources, for example? Because WS run in a large-scale, loosely-coupled, distributed environment, they just tend to fit forward compensation more than backward. However, that is not to say that you can't use backward compensation techniques: running JTA/JTS in a web-services world is straightforward.
So, it's wrong to think that there is something inherently wrong with Web Services that makes using transactions in them even worse. There isn't.
I just loved the example:
Normal flow -
1: Book taxi
2: Book plane
3: Book taxi
4: Book hotel
5: book restaurant.
What could happen
1: Book taxi = OK
2: Book plane = OK
3: Book taxi = OK
4: Book hotel = FAIL
5: try again = FAIL
6: compensate taxi (3 above) = ok
7: compensate plane (2 above) = fail
8: try to compensate plane again = fail
9: fall in a heap and let a human deal with it.
And good web services will have all sorts of negotiation in them, where the hotel may offer a taxi service, requiring a compensation of prior taxi order, but a valid business transaction all the same...
And I can immediatly think of adding far more complexity to this system to make it actually work usefully. And since real money is being used to buy these services the error handling really has to be good....
This is why I was saying its too early to buy into web services as some kind of infrastructure. Basically you will code it yourself depending on the application - which is what we all do at the moment.
Much like Corba for most projects is used as a point to point protocol, I recon 'web services' will be used on projects as an inefficient point to point protocol and little else. Wow, I can see the comms, look its in ascii, that means it's open, great....(In case you miss the point, NO ITS NOT OPEN, just slow).
I agree nothing is new under the sun - IT was invented by a greek who escaped from atlantis.. or something. BUT, your article was the first I'd read about this stuff, and I thought you explained the issues very well.
Glad you like the article. The follow-up was just to put the picture right: the issues with forward compensation are not web services specific. It's damn difficult to use forward compensation models in complex environments, hence the reason why all of traditional TP uses backward recovery. It may be pessimistic, but it works and you (the application programmer) don't need to worry about what the heck it means to undo.
Luckily, BTP doesn't tie you to forward compensation. You can use the same protocol to do backward (e.g., JTA) recovery.
BTW, where forward compensation does become useable is in conjunction with certain workflow systems. Then you get many layers of abstraction between your services and the way you use them to help you structure your final application into compensatable units.
However, when you look at transactional workflows and BTP you start to see that perhaps the latter is a little over-specified. The idea of cohesions (essentially relaxing atomicity to give your business logic the control over what to do next) looks a bit like a "poor mans" workflow, but without all of the really useful tools like service specification languages, flow languages etc. And in fact there has been this argument within the BTP technical committee that perhaps atoms (essentially traditional 2PC but without a requirement for two-phase locking or isolation) are all you need, since service composition and choreography will happen at the workflow level.