BPEL-SE processes 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 may not be desirable or may be 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. Latter 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 are 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 -
   1. When atomic=no & persistence is enabled, BP (Receive) state is persisted to recovery db in transaction associated with ME . BP (activities after Receive) execute when the ME transaction is committed. Each Invoke is associated with new transaction. If persistence is not enabled transaction has no impact.
   2. When atomic=yes, transaction associated with ME is propagated on the invokes BP makes.
4. Security context - BPEL-SE has no mechanism to persist and recover 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. When persistence is enabled Security Subject is not propagated on the invokes BP makes

---

By Example

Receive - Activity-1-Activity-2- - - - Activity-n
Business process has Receive activity  with createInstance=yes followed by Activity-1 to n WS-BPEL activities.
Default behavior - BPEL-SE receives message from partner (BC or SE)executes Receive activity (creates a BP instance) and sends ACK to its partner and continues to execute Activity-1 to n. On receiving ACK message delivery is complete from Partner's perspective.

Let us assume system crashes while executing Activity-1. It will result in message loss. User has two options address this issue

• Enable persistence on BPEL-SE - BPEL-SE persists the BP instance state to database before it sends ACK to partner.
• set BP "atomic" property  to yes. - BPEL-SE does not send ACK till it executes all the activities in BP instance.

We recommend option-1 for long running process. option-2 for short lived (What is "short-lived" business process? there is no easy way to explain or categorize this. Rule of thumb, if Activity-1 to n is Receive, Pick and Event handler activities, it is not short-lived. ) business processes. Why? When BP is marked (atomic-yes) ACK behavior is altered only for first Receive activity and no change for 2nd (other) Receive activity(ies), it is implementation choice to keep complexity under control. So there is potential loss of message associated with 2nd Receive if the system crashes after 2nd Receive activity.

In documentation "2nd Receive Activity" and "Correlating Receive Activity" used interchangeably as it is mandatory to define correlation on it.

High level there are 3 simple rules

1. Message loss is OK - No configuration is required
2. At-least-Once - BP has 2nd Receive activity - configure BPEL-SE persistence. BP has no 2nd Receive activity - set BP atomic - yes. No persistence to database will boost throughput at least 10 times faster.
3. Once-only-once - Use partner BC(s) and SE(s) that support transaction.

This page (revision-29) was last changed on 18-Nov-08 16:16 PM, -0800 by Murali.
This page was created on 12-Sep-07 10:03 AM, -0700 by Murali.

More info...