Mark Little's team has been working on support for transactional Web Services (with accordance to the Business Activity model described in the WS-BusinessActivity specification) for some time. Recently, one of his contributors, Maciej Machulak, wrote an annotation based framework on top of this service. Writing transaction-aware Web Services is relatively problematic and requires a lot of support from business programmers. Developers need to manually wire up original services with their compensation actions and must ensure the correctness of those links (e.g. in terms of data that needs to be shared). The aim of the annotation framework is to facilitate development of transaction-aware Web Services and provide a comprehensive framework which would release programmers from mixing transaction-related code with business logic of their applications. The framework has a very clean API, which can be easily learned and applied.

@Stateless @Remote(HotelBA.class) @WebService(name="HotelBA") @SOAPBinding(style = SOAPBinding.Style.RPC) @HandlerChain(file = "jaxws-ba-handler-server.xml") public class HotelBAImpl implements HotelBA { @WebMethod @BAService(BAServiceType.MODIFY) @BAAgreement(BAAgreementType.PARTICIPANT_COMPLETION) @BACompensatedBy(value="cancel",type = BACompensationType.CUSTOM) @BAResult("resNo") public Integer book(@BAParam("user")String user, @BAParam("pass")String pass, Integer room) { // ... business logic return reservationNumber; } @WebMethod public void cancel(@BAParam("user")String user, @BAParam("pass")String pass, @BAParam("resNo")Integer rNumber) { // ... business logic Integer refund = (Integer) cm.get("refund"); if (refund != null) { // ... business logic } // ... business logic } }

This framework is still under development, but we're looking for early adopters to test drive and new contributors to help out. For more details: Website Forum Article in my blog

BTW, beyond the functionality this framework introduces, I think this is a great general example/usecase for annotations on parameters.

Not knowing the specs at all, I'm a bit amazed. Hasn't history already determined that for distributed transactions (based on the title of the article) two phase commits are the better approach as opposed to manual rollbacks? What if the rollback fails because of a local system crash? Has the initial transaction then been committed or not? But I probably assume wrong.

Here's a blog entry by Mark Little that might give some context to the idea of "Business Transactions" http://www.webservices.org/weblog/mark_little/the_oasis_ws_caf_approach_to_web_services_business_transactions

Not knowing the specs at all, I'm a bit amazed. Hasn't history already determined that for distributed transactions (based on the title of the article) two phase commits are the better approach as opposed to manual rollbacks? What if the rollback fails because of a local system crash? Has the initial transaction then been committed or not?

But I probably assume wrong.

Tranditional 2PC does not scale well in long running activities. Think of a travel agent that is booking a vacation. Air, hotel, and taxi reservations. The agent could take minutes, hours, even days to finish the entire activity. You can't hold up database resources that long. Even a minute is too long in highly concurrent systems. I don't know the Arjuna Business Activity Manager implementation (I hope Mark elaborates), but if you were coordinating this activity manually you could easy guarantee commits and rollbacks/compensations by sending persistent JMS messages for these events. JMS guarantees the delivery. I talked a bit abount this in regards to JBPM in these blogs: Guaranted JBPM transitions Guaranteed jBPM Failure Handling

Exactamundo. It's amazing how often "Transaction" and "Workflow" are conflated. - Don

Exactamundo. It's amazing how often "Transaction" and "Workflow" are conflated.

- Don

Don, this is actually something I'm planning on writing about soon. While BA puts the onus on the server and decouples the "client" from compensation responsibility. Workflow or BPM on the other hand, puts the onus on the "client" and business process to perform compensations. Which is better? You can make a case for both I believe.

You may still coordinate it using the provided XTS (XML Transaction Service). The framework is built on top of it. All messages that are sent from the coordinator to services (and the other way round) have to be acknowledged so delivery is also guaranteed. The problem is with the implementation as business programmers must develop everything from scratch (i.e. the participant that would react on different transaction messages).

As Bill points out that's not always desirable due to resource contention. Besides, lot of times it turns out you can relax the strict ACID requirements and live with it. For example, in a reliable messaging based transaction scenario, your rollbacks/compensation will *eventually* succeed but in between you will not have isolation - question is can your business live with it. I know a very large bank that does not use 2PC at all and distributed transactions cannot get any more critical than this. But they do have extensive compensation schemes and failing all, manual reconciliation.

When dealing with long running business processes that potentially cross not just application but also corporate boundaries, the store and forward pattern seems much more appropriate than any form of transactional pattern. While I admire the efforts to create a distributed transaction model for web services, past experience with Corba has shown that this approach usually just isn't practical. I'd really prefer to see a lot more effort put into creating a standard approach for using store and forward with web services. And in particular, a standard way to have this pattern interact with a workflow engine. Because many times when a long running multi step business process encounters a failure, you don't really want to roll back everything that has happened prior to that.

When dealing with long running business processes that potentially cross not just application but also corporate boundaries, the store and forward pattern seems much more appropriate than any form of transactional pattern.

While I admire the efforts to create a distributed transaction model for web services, past experience with Corba has shown that this approach usually just isn't practical.

I'd really prefer to see a lot more effort put into creating a standard approach for using store and forward with web services. And in particular, a standard way to have this pattern interact with a workflow engine.

Because many times when a long running multi step business process encounters a failure, you don't really want to roll back everything that has happened prior to that.

That's right, but then that's why there are a range of extended transaction models. Full ACID is just one part of the spectrum. They include things like nested transactions (where you don't undo everything that "happened prior" to the rollback) and coloured actions. This spectrum of protocols, relaxing all of the various aspects of A, C, I and D in a controlled manner, was referenced in Jim Gray's original IBM technical report. It's also what lead to the development of the CORBA Activity Service and the Java equivalent, and ultimately the Web Services transactions protocols.