XA transaction, guarantee of delivery, consistency and Glassfish ESB BPEL

[Paul Perez]

Today pymma issued a document that details Glassfish ESB BPEL engine support of XA transactions and introduces BPEL features that can be used in order to increase reliability, consistency and guarantee of delivery in an application of integration. XA technology is the best way to achieve perfect delivery and consistency; however, it works only in environments (world) that do not match the environment of integration.  For that reason, Pymma advices against XA usage in the integration process. This paper explains our position. The link to access to this long document (>3Mo) is :
http://www.pymma.com/eng/IT-Tech-Papers/Pdf-folder/XA-transaction,-guarantee-of-delivery,-consistency-and-Glassfish-ESB-BPEL 
Thanks for your feedback at [e-mail]
Paul Perez

[Murali Pottlapelli]

Some javascript/style in this post has been disabled (why?)

Hi Paul,
This document does the  good job  in discussing hard to understand concepts and educating them. But it falls short in application and guiding the right solution.

1. Categorization of Integration and Business process does not seem to be right, according to this document Integration processes are short lived. And limits the scope of the document to these processes, but discussion in this document equally applicable to long running processes.
   
2. Page 14 & 15, document presents business process "atomic" property as the only solution for message loss, and warns the user on applying it for long running processes. Later part is true, but not the former. GlassFish ESB provides options, user needs to determine the right solution based on the requirements.
   
3. "atomic" property is the right option if the requirement dictates rolling back message to original partner in the event of error.
   
• To handle the malformed messages (discussed on page 26), configure Redelivery on original partner, and choose "Redirect" option to route the message to "error processor" end point, this could be another business process, POJO, EJB or JMS Queue. It also address "infinite loop" issue raised in page 28.
  
• If requirement is at-least-once message is delivery, and not concerned on potential duplicate messages, all the partners involved in the process do not need to support XA.
• If the requirement is once-only-once message delivery, all the partners need to support XA.
4. When BPEL-SE to configured to run in persistence mode,
   
• it guarantees at-least-once message delivery by persisting state of business process instance on message exchange.
  
• In the event of system crash/failures there is potential for duplicate message.
  
• If the requirement is once-only-once message delivery, partner needs to support XA.
  
• Errors in the process needs to be handled by defining fault handlers. Malformed messages (discussed on page 26) is handled by defining a fault handler with Invoke activity that routes message to "error processor".
• Compensation handlers used to undo the partial work completed (SIDE EFFECT).
  

In summary GlassFish ESB uses XA to improve message delivery guarantee from at-least-once to once-only-once for both short running process (one transaction) and long running process (multiple transactions, a transaction for each partner interaction from/to long running business process).

Please let me know if something is not clear.

Regards
Murali

Paul Perez wrote:

Today pymma issued a document that details Glassfish ESB BPEL engine support
of XA transactions and introduces BPEL features that can be used in order to
increase reliability, consistency and guarantee of delivery in an
application of integration. XA technology is the best way to achieve perfect
delivery and consistency; however, it works only in environments (world)
that do not match the environment of integration.  For that reason, Pymma
advices against XA usage in the integration process. This paper explains our
position. The link to access to this long document (>3Mo) is : 
http://www.pymma.com/eng/IT-Tech-Papers/Pdf-folder/XA-transaction,-guarantee-of-delivery,-consistency-and-Glassfish-ESB-BPEL  
Thanks for your feedback at [hidden email] 
Paul Perez

  

[Paul Perez]

Hi Murali,
Thanks for reading our document and us your feedback. It is interesting to note when you write A long document, how each reader is sensitive to a part of your document and how it is difficult to express exactly what is your ideas especially in a foreign language (I’m a French speaker).  
The main idea of this document is to list the BPEL features that can be used to increase reliability and consistency in a process and warn people against the XA transaction in an integration process. You may be right when you write “we fail in application and guiding the right solution”. In my defence, I did not finish the second part of the document that gives a guide to choose which BPEL feature. At present, I’m completely stacked with reusing and reference in Open-ESB (Let me know if you have some tricks).
In this reply, I’ll try to answer to your comments point by point. I will be happy to get your feedback again.
 
1-Categorisation of Integration
In our document we distinguish the integration process from the business process. The later is defined by long running process but by manual task as well. I don’t think that the discussion about “XA or not XA” can be applied on business process (Long Running Process) since we cannot apply XA on manual by example. But above all that, there is no system in production that can afford itself the luxury of blocking resources (Thread, Memory...) more than few minutes without problem. From our part, at Pymma we never saw any company that plan to manage LRP with XA. (May be at Sun you met one ???).
We maintain that Business Process (Long Running Process) cannot be use with XA transaction and it is the reason why we don’t take into account this case in our document.

2-Atomic property in BPEL
In fact at the page 15, I talk about the Atomic property, but I never presented it as the “only solution for lost message...”. Let’s read again what is written in page 15:
“Whether used or not, atomic properties of the BPEL engine are dependent on the functional requirements. Using atomic, provides a better level of reliability during the exchange between partners and BPEL engine. However, this configuration consumes resources; especially when the Business Process is long (> few seconds). In that case, BPEL performances collapse quickly. The rule of thumb to remember is: using atomic increases the level of reliability but it is resource consumer and can stack the integration system if the BPEL processes are too long”.
I just said that atomic property provides a better level of reliability.  

3- Atomic property (next)
May be I did not understand well this third point, but it seems I failed in getting my message across.
Of course, Atomic property is needed if you want to use XA, of course if you need once and only once delivery you need XA, of course you can find technical solution for the infinite loop create by the malformed message in the process (page 26).
In the paper, I wanted to explain that:
• First XA is tricky and vicious. The simple example detail in the document is simple enough to be understood by anyone and however can stack a development team for many days. What about the more complex process.
• Second that we cannot use XA in all the situations. Sometime in a transactional context, for technical reasons, XA implementation are incompatible (I can give you many examples) and global transaction cannot be guaranteed. But the main reason for not using XA is the evolution of your application. May be when starting your application you work with XA partners only. Very quickly you will have to integrate non XA partner. Then you will have to use the other feature described in the document.

4- BPEL persistence
You said:
• it guarantees at-least-once message delivery by persisting state of business process instance on message exchange. I agree with you.
• In the event of system crash/failures there is potential for duplicate message.  I agree with you but using persistence decrease dramatically the possibility to hade duplicated message.
• If the requirement is once-only-once message delivery, partner needs to support XA. Again, there are so many cases where XA cannot be implemented that we had to detail the substitute features in the BPEL .
• Errors in the process needs to be handled by defining fault handlers. Malformed messages (discussed on page 26) is handled by defining a fault handler with Invoke activity that routes message to "error processor". Obvious there is no difference between us
• Compensation handlers used to undo the partial work completed (SIDE EFFECT).  I agree with you but compensation is completely inefficient when a crash/failure occurs.
As summary, I agree that XA increases the delivery guarantee, but we went a step further by saying that XA MUST not be used in the Business Process (Long Running Process or BP with Manual Task). Moreover, we advice against Xa for the integration process since it is a strong limitation to the integration.
I hope this reply may clarify our document? Again thanks for your interest and you feedback

PPe

[guillaume]

Hello Paul,

first of all, congratulation for this document. The pictures are great and all the cases are well introduced. I'm interesting in JBI technology and I'm facing the issue of "global transaction", and of course I'm investigating on XA. I'm curious to know which incompatible XA implementations you met?

thanks

Paul Perez wrote:

Hi Murali,
Thanks for reading our document and us your feedback. It is interesting to note when you write A long document, how each reader is sensitive to a part of your document and how it is difficult to express exactly what is your ideas especially in a foreign language (I’m a French speaker).  
The main idea of this document is to list the BPEL features that can be used to increase reliability and consistency in a process and warn people against the XA transaction in an integration process. You may be right when you write “we fail in application and guiding the right solution”. In my defence, I did not finish the second part of the document that gives a guide to choose which BPEL feature. At present, I’m completely stacked with reusing and reference in Open-ESB (Let me know if you have some tricks).
In this reply, I’ll try to answer to your comments point by point. I will be happy to get your feedback again.
 
1-Categorisation of Integration
In our document we distinguish the integration process from the business process. The later is defined by long running process but by manual task as well. I don’t think that the discussion about “XA or not XA” can be applied on business process (Long Running Process) since we cannot apply XA on manual by example. But above all that, there is no system in production that can afford itself the luxury of blocking resources (Thread, Memory...) more than few minutes without problem. From our part, at Pymma we never saw any company that plan to manage LRP with XA. (May be at Sun you met one ???).
We maintain that Business Process (Long Running Process) cannot be use with XA transaction and it is the reason why we don’t take into account this case in our document.

2-Atomic property in BPEL
In fact at the page 15, I talk about the Atomic property, but I never presented it as the “only solution for lost message...”. Let’s read again what is written in page 15:
“Whether used or not, atomic properties of the BPEL engine are dependent on the functional requirements. Using atomic, provides a better level of reliability during the exchange between partners and BPEL engine. However, this configuration consumes resources; especially when the Business Process is long (> few seconds). In that case, BPEL performances collapse quickly. The rule of thumb to remember is: using atomic increases the level of reliability but it is resource consumer and can stack the integration system if the BPEL processes are too long”.
I just said that atomic property provides a better level of reliability.  

3- Atomic property (next)
May be I did not understand well this third point, but it seems I failed in getting my message across.
Of course, Atomic property is needed if you want to use XA, of course if you need once and only once delivery you need XA, of course you can find technical solution for the infinite loop create by the malformed message in the process (page 26).
In the paper, I wanted to explain that:
• First XA is tricky and vicious. The simple example detail in the document is simple enough to be understood by anyone and however can stack a development team for many days. What about the more complex process.
• Second that we cannot use XA in all the situations. Sometime in a transactional context, for technical reasons, XA implementation are incompatible (I can give you many examples) and global transaction cannot be guaranteed. But the main reason for not using XA is the evolution of your application. May be when starting your application you work with XA partners only. Very quickly you will have to integrate non XA partner. Then you will have to use the other feature described in the document.

4- BPEL persistence
You said:
• it guarantees at-least-once message delivery by persisting state of business process instance on message exchange. I agree with you.
• In the event of system crash/failures there is potential for duplicate message.  I agree with you but using persistence decrease dramatically the possibility to hade duplicated message.
• If the requirement is once-only-once message delivery, partner needs to support XA. Again, there are so many cases where XA cannot be implemented that we had to detail the substitute features in the BPEL .
• Errors in the process needs to be handled by defining fault handlers. Malformed messages (discussed on page 26) is handled by defining a fault handler with Invoke activity that routes message to "error processor". Obvious there is no difference between us
• Compensation handlers used to undo the partial work completed (SIDE EFFECT).  I agree with you but compensation is completely inefficient when a crash/failure occurs.
As summary, I agree that XA increases the delivery guarantee, but we went a step further by saying that XA MUST not be used in the Business Process (Long Running Process or BP with Manual Task). Moreover, we advice against Xa for the integration process since it is a strong limitation to the integration.
I hope this reply may clarify our document? Again thanks for your interest and you feedback

PPe

[Paul Perez]

Hi guillaume and thanks for the congatulation

I’ll try to give you a concise answer to your question.  As said in the paper, you can set a global, reliable, safe and secure transaction only in a heterogeneous environment localized in a small place. Heterogeneity and localization are the keys to set a global transaction, if one is missing you will not able to get 100% consistent and available system. (See Theorem CAP).  This is for the theory.
Because of the ‘I’, JBI has been design for Integration. So we met many systems where parts were not issued by the same editor: Ex: IBM, Oracle, SAP… So we met very vicious problems linked to the transaction. Each case is different and need a long background explanation.  But the rule of thumb is : “XA Transactions run where only with simple cases”.  
In our document, we showed that Glassfish BPEL cannot be used with an external transaction manager. You create a process with 2 orchestrators, one for the process (BPEL) the other for the transaction (transaction manager).
Just an advice to finish, if you have a no standard integration system to develop with Open-ESB, use the features described in the our document. In Fact it can be more complex at the development level but you will avoid some nightmarish bug in production that will convince you to give up with transaction

Best regards

paul : www.pymma.com

guillaume wrote:

Hello Paul,

first of all, congratulation for this document. The pictures are great and all the cases are well introduced. I'm interesting in JBI technology and I'm facing the issue of "global transaction", and of course I'm investigating on XA. I'm curious to know which incompatible XA implementations you met?

thanks

Paul Perez wrote:

Hi Murali,
Thanks for reading our document and us your feedback. It is interesting to note when you write A long document, how each reader is sensitive to a part of your document and how it is difficult to express exactly what is your ideas especially in a foreign language (I’m a French speaker).  
The main idea of this document is to list the BPEL features that can be used to increase reliability and consistency in a process and warn people against the XA transaction in an integration process. You may be right when you write “we fail in application and guiding the right solution”. In my defence, I did not finish the second part of the document that gives a guide to choose which BPEL feature. At present, I’m completely stacked with reusing and reference in Open-ESB (Let me know if you have some tricks).
In this reply, I’ll try to answer to your comments point by point. I will be happy to get your feedback again.
 
1-Categorisation of Integration
In our document we distinguish the integration process from the business process. The later is defined by long running process but by manual task as well. I don’t think that the discussion about “XA or not XA” can be applied on business process (Long Running Process) since we cannot apply XA on manual by example. But above all that, there is no system in production that can afford itself the luxury of blocking resources (Thread, Memory...) more than few minutes without problem. From our part, at Pymma we never saw any company that plan to manage LRP with XA. (May be at Sun you met one ???).
We maintain that Business Process (Long Running Process) cannot be use with XA transaction and it is the reason why we don’t take into account this case in our document.

2-Atomic property in BPEL
In fact at the page 15, I talk about the Atomic property, but I never presented it as the “only solution for lost message...”. Let’s read again what is written in page 15:
“Whether used or not, atomic properties of the BPEL engine are dependent on the functional requirements. Using atomic, provides a better level of reliability during the exchange between partners and BPEL engine. However, this configuration consumes resources; especially when the Business Process is long (> few seconds). In that case, BPEL performances collapse quickly. The rule of thumb to remember is: using atomic increases the level of reliability but it is resource consumer and can stack the integration system if the BPEL processes are too long”.
I just said that atomic property provides a better level of reliability.  

3- Atomic property (next)
May be I did not understand well this third point, but it seems I failed in getting my message across.
Of course, Atomic property is needed if you want to use XA, of course if you need once and only once delivery you need XA, of course you can find technical solution for the infinite loop create by the malformed message in the process (page 26).
In the paper, I wanted to explain that:
• First XA is tricky and vicious. The simple example detail in the document is simple enough to be understood by anyone and however can stack a development team for many days. What about the more complex process.
• Second that we cannot use XA in all the situations. Sometime in a transactional context, for technical reasons, XA implementation are incompatible (I can give you many examples) and global transaction cannot be guaranteed. But the main reason for not using XA is the evolution of your application. May be when starting your application you work with XA partners only. Very quickly you will have to integrate non XA partner. Then you will have to use the other feature described in the document.

4- BPEL persistence
You said:
• it guarantees at-least-once message delivery by persisting state of business process instance on message exchange. I agree with you.
• In the event of system crash/failures there is potential for duplicate message.  I agree with you but using persistence decrease dramatically the possibility to hade duplicated message.
• If the requirement is once-only-once message delivery, partner needs to support XA. Again, there are so many cases where XA cannot be implemented that we had to detail the substitute features in the BPEL .
• Errors in the process needs to be handled by defining fault handlers. Malformed messages (discussed on page 26) is handled by defining a fault handler with Invoke activity that routes message to "error processor". Obvious there is no difference between us
• Compensation handlers used to undo the partial work completed (SIDE EFFECT).  I agree with you but compensation is completely inefficient when a crash/failure occurs.
As summary, I agree that XA increases the delivery guarantee, but we went a step further by saying that XA MUST not be used in the Business Process (Long Running Process or BP with Manual Task). Moreover, we advice against Xa for the integration process since it is a strong limitation to the integration.
I hope this reply may clarify our document? Again thanks for your interest and you feedback

PPe