[Design of JBoss ESB] - Re: Embedded FTP Server and FTP Clients
by mark.little@jboss.com
You misunderstand. You need a reliable coordinator to record the compensations and trigger them when necessary. A rollback is a compensation that is triggered, either by the application or by the recovery subsystem. A forward compensation is just the same: the information about which compensation to trigger and when, needs to be durably recorded and replayed when/if necessary. Believe it or not, but failures during compensation do occur.
As far as compensations are concerned, if you're doing forward compensation then they are often tied to the application or business logic and not generally applicable. Take a look at the OMG Additional Structuring Mechanisms for the OTS, or the Java Activity Service specifications for some examples of what I mean (although I'm fairly sure you understand). Some BPEL engines are implemented on these frameworks. What those frameworks do is generalise a coordinator (what you've called a transactionmanager) so that it can do forward or backward recovery.
Although we have an implementation of these frameworks, ArjunaCore isn't it, but is similar. It allows for the structured relaxation of the ACID properties in "transaction" coordination as defined by Jim Gray in his original IBM technical report. (It was actually the basis of some of the work I mentioned above.)
BTW, compensation transactions (including WS-BA) are being used today in some pretty important and mission critical environments. Compensations aren't new and many vertical sectors have been using them ad hoc for nearly 20 years. What they've been doing over the past 5 years is moving to the standards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029148#4029148
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029148
19 years
[Design of JBoss ESB] - Re: Embedded FTP Server and FTP Clients
by bill.burke@jboss.com
"mark.little(a)jboss.com" wrote : "bill.burke(a)jboss.com" wrote : Mark, this is what we've been arguing about privately over email. JBPM provides support for long-term flows, and because the flow definition/metadata can either be persisted or travel with the message, federation would be supported.
| |
|
| I'm pretty sure we've established that this is a good thing for us to support on the ESB.
|
| anonymous wrote :
| | In my mind, even compensating transactions could be covered in the process flow definition. You either rollback in a local transaction to your original save point in the message flow and start over, or you catch the problem and transition to the compensating part of the defined message flow.
| |
|
| Until I see an implementation of a process engine that uses a transaction engine as its core for compensations, I'm not convinced that compensations are truly supported. Something like WS-BA (or one of the other dozen or so compensation transaction models) require durability, coordination and reliability characteristics that are often just ignored by process engines (both commercial and open source), leaving a lot up to the user.
Wasn't thinking about crash and recovery. Still, don't compensations have to be more business process oriented usually anyways?
Bill
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029142#4029142
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029142
19 years