BPEL-SE process Message Exchanges in two modes. Processing mode is determined by associated Business Process attribute {http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/Transaction}atomic. This attribute is set on the "process" element of Business Process, default value is "no".

Business Process execution behavior is enumerated by Message Exchange type.

---

InOnly Message Exchange

When InOnly (one way request ) message creates an instance
atomic=no - acknowledges Message(MEx) to its partner immediately after executing Receive activity.
atomic=yes - acknowledges Message(MEx) to its partner when the instance completes.

atomic=no

• When a business process execution takes few hours/days to complete it is not possible/inefficient to block the partner with no acknowledgment for the duration of instance execution time. For these scenarios this is preferred option.
• In this mode there is potential for message loss when the machine crashes. To address the message loss scenario BPEL-SE can be configured with persistence enabled. In persistence enabled mode there is potential for duplicate message based on crash point. It is equivalent of "At-least-once" semantics.
• By associating Message with unique-id or transaction we could achieve "once-only-once" semantics. Later case partner needs to support XA.
• Correlating Messages (In or InOut), no behavior change.

atomic=yes

• When business process execution time is predictable and short interval acknowledgment can be delayed for the duration of instance execution. For these scenarios this is preferred option.
• No message loss would be experienced. No need to persist the state of the business process. "Persistence Enabled" attribute has no influence. Potential duplicates are possible in the event of crash or failure in the execution. In the event of crash partner would redeliver the message and all the activities in the business process would be re executed.
• By associating Message with transaction we could achieve "once-only-once" semantics. Partner needs to support XA. Please note that "unique-id" does not help to achieve "once-only-once" as BP state is not persisted.
• Correlating Messages (In or InOut). There is potential of message loss as well as duplicates based on timing of execution.

---

InOut Message Exchange

When InOut (two way request ) message creates an instance.

"Reply" activity in Business Process definition determines when the response/fault is set on Message Exchange. This attribute has no influence determine timing of it, but influences behavior as enumerated below.

atomic=no

• It is preferred option when the time interval between the execution of Receive and Reply is unpredictable and could take long.
• There is potential for duplicate message if system crashes and consumer/partner redelivers the message.
• Duplicate messages can be addressed by enabling BPEL-SE persistence and tagging the Message with unique id. It is semantically "once-only-once".
• Correlating Messages (In or InOut), no behavior change.

atomic=yes

• It is preferred option when the time interval between the execution of Receive and Reply is predictable and short.
• There is potential for duplicate message if system crashes and consumer/partner redelivers the message.
• Duplicate messages can be addressed by associating transaction with the Message. No need to persist the state of the business process until execution of Reply activity. State of BP at Reply activity is persisted in the message's transaction.
• Correlating Messages (In or InOut). There is potential of message loss as well as duplicates based on timing of execution.

---

Notes:

1. When there are Invoke activities in FLOW they would be serialized for the duration of the execution of Invoke activity.
2. Correlating Receive activity ME is associated with no Invoke activity ME. Alternatively stated as "Correlating Receive activity ME is not parent ME for any other ME".
3. Transaction context - BP (Receive) state is persisted to recovery db in transaction associated with ME when atomic=no. BP (activities after Receive) execute when the ME transaction is committed. So it is invalid to associate committed transaction with Invoke activities.
4. Security context - BPEL-SE has no mechanism to persist and recovery security context and other ME properties. In case of crash when BP recovers from crash it does not have access to security context and other ME properties associated with its receive activity.

This page (revision-26) was last changed on 05-Feb-08 10:18 AM, -0800 by Murali.
This page was created on 12-Sep-07 10:03 AM, -0700 by Murali.

More info...