Comments on: Must I compensate for everything?

By: Distributed Compensation with REST and jBPM « Angry Bill

Distributed Compensation with REST and jBPM « Angry Bill — Tue, 18 Sep 2007 12:18:27 +0000

[...] Must I compensate for everything? [...]

By: Mark Little

Mark Little — Thu, 02 Aug 2007 09:19:59 +0000

I think the difference is that in the BA case the client doesn’t need to worry about how to invoke a compensator on a service (or a number of services that must be compensated together or not at all). The information about how to compensate is down to the service developer and this is wrapped within a participant that then gets enrolled with the BA coordinator. In the case where you’ve only got a single service to compensate then something like BA is overkill (though an equivalent of onePhaseCommit would help there). But as soon as you enlist more than one service, it becomes too much overhead on the client developer IMO. BTW, BA also supports a “mixed” outcome. By default, the termination of a BA scope is atomic, so either all of the participants compensate for their services or none of them do. But you can change that so a subset are compensated and the remaining aren’t. The coordinator does this reliably too, so we fail safe.

By: billburke

billburke — Wed, 01 Aug 2007 22:04:01 +0000

I’m talking about business logic. In the BPM case, which is business logic driven, the business logic invokes all the compensation actions. In the BA case, doesn’t the framework coordinator handle all this? Meaning, all this compensation logic is hidden from the application developer?

By: Mark Little

Mark Little — Wed, 01 Aug 2007 22:00:35 +0000

You know, I wish we had a whiteboard again or I lived in Boston ’cause I’m always sure we’d have good conversations Anyway … in BA the client doesn’t know how a service compensates for the work that it did for the client, but the client definitely knows whether the business transaction (for which the BA provides the scope) needs to undo or not. So I don’t quite get the “the client is decoupled from whether the resource must be compensated”. BTW, I’m assuming resource is service/component/object/whatever and not the participant registered with the coordinator? Maybe there’s some disconnect there too: as with traditional tx, there’s a service/participant split in BA too. Clients talk to services/objects/whatevers that encompass the business logic, whereas the BA coordinator talks to participants (registered by the service or on behalf of the service somehow).

By: billburke

billburke — Wed, 01 Aug 2007 21:45:50 +0000

Mark, seems BA is about further decoupling. With BPM, the process drives and must know about whether to compensate or not. With BA driven services, the client is decoupled from whether the resource must be compensated or not and how it is compensated.

By: Mark Little

Mark Little — Wed, 01 Aug 2007 21:17:39 +0000

First off, all transactions are “compensation transactions” The ones we know and long just do backward compensation. What you’re describing is forward compensation (at least that’s was WS-BA/Sagas is all about). Second, I don’t see this as a jBPM versus BA approach. Ultimately you need something that can reliably record who was involved in the “transaction” and hence who needs to be told to undo, even in the presence of arbitrary failures. That’s a coordinator. Plus, some of the participants in the “transaction” may not need to be compensated (c.f., returning VoteReadonly during prepare of 2PC). That’s all WS-BA does: it provides a standard (for Web Services) for the protocol between coordinator and participants. It doesn’t define when or if a “transaction” should be terminated in a successful or failure state. That’s definitely the domain of the business logic. Plus, it doesn’t define how any compensations should be done. Again, that’s an implementation decision. Participants in a forward compensation based transaction are more often than not tied to the business logic/object/service that they’re compensating: they’re rarely re-usable (e.g., forward compensating a flight reservation is different to compensating buying a book). WS-BPEL defines compensation handlers in the same way that jBPM would for the business process. Some implementations use WS-BA, others don’t. But those that don’t have a coordinator somewhere to do the same thing; they just don’t bother with the interoperability. One of the earlier Web Services TX specifications (BTP) tried to mix business logic with the coordinator, but that wasn’t the right approach. The business logic should always be in charge, driving the coordinator appropriately. You might find this useful.

By: Andy

Andy — Wed, 01 Aug 2007 03:49:29 +0000

I guess my big whine is your use of “compensating transactions” which I regard as something different. Write this in JBossese: http://blogs.msdn.com/rogerwolterblog/archive/2006/05/24/606184.aspx He more or less explains what I was trying to say and what you were trying to say and hocks BizTalk to boot

By: billburke

billburke — Thu, 26 Jul 2007 13:49:13 +0000

Andy, you’re stealing my thunder My next blog was going to be about how compensation is better to be handled as a business process through jbpm than handled by a business activity service or compensating transaction coordinator.

By: Andy

Andy — Thu, 26 Jul 2007 06:49:27 +0000

In some cases. Compensating transactions wouldn’t ever be my first choice for most stuff, but there are plenty of edge cases. It is a tool, however, dang how many people even use EJB transactions correctly? Crap how many people use basic database transactions correctly? I also don’t know that canceling an order is a great case for compensating transactions as I know them. In a good system these follow accounting rules and there is more of a workflow. The data is maintained but put in a new state rather than undone. I don’t know that this falls into what I call “compensating transactions”…certainly compensation is involved ;-). I kinda like Gavin’s new terminology of “conversation” for this. Certainly JBPM would be a way to map the workflow and states. I just don’t know that I’d call your specific example quintessential compensation per se — but what do I know… I just crashed gnome for the 5th time today.

By: billburke

billburke — Wed, 25 Jul 2007 20:37:53 +0000

So what you’ve basically done is further justify the need for compensation. Thanks