Index Changes
Page Difference

Difference between version and version     

Back to M Eprocessing And Property Propagation, or M Eprocessing And Property Propagation Info


At line 1 changed 1 line.
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".
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".
At line 17 changed 1 line.
* 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.
* 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.
At line 19 changed 1 line.
*By associating Message with unique-id or transaction we could achieve "once-only-once" semantics. Later case partner needs to support XA.
*By associating Message with unique-id or transaction we could achieve "once-only-once" semantics. Latter case partner needs to support XA.
At line 43 added 1 line.
*Correlating Messages (In or InOut), no behavior change.
At line 49 added 1 line.
*Correlating Messages (In or InOut). There is potential of message loss as well as duplicates based on timing of execution.
At line 49 changed 1 line.
----------------------------------
------
At line 51 changed 1 line.
!!Correlating Message Exchange
__Notes__:
# When there are Invoke activities in FLOW they are serialized for the duration of the execution of Invoke activity.
# 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".
# Transaction context -
##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.
##When atomic=yes, transaction associated with ME is propagated on the invokes BP makes.
# 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
At line 53 changed 2 lines.
!atomic=no
Both InOnly and InOut message loss & duplicate message issue can be addressed by associating transaction or tagging with unique id. It is semantically "once-only-once".
------------------------------------
!By Example
At line 56 changed 1 line.
!atomic=yes
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.
At line 58 changed 1 line.
For correlating message "Model-B" is not preferred as there is potential of message loss as well as duplicates.
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.
At line 60 changed 3 lines.
----
__Notes__:
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.
At line 64 changed 5 lines.
# When there are Invoke activities in FLOW they would be serialized for the duration of the execution of Invoke activity.
# Correlating Receive activity ME is associated with no Invoke activity ME.
# Transaction context - BP (Receive) state is persisted to recovery db in transaction associated with ME. BP (activities after Receive) execute when the ME transaction is committed. So it is invalid to associate committed transaction with Invoke activities.
# 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.
# Where there is no persistence enabled nor is the bpel process marked as atomic(transactions), there exits a possibility of message loss.
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
# Message loss is OK - No configuration is required
# 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.
# Once-only-once - Use partner BC(s) and SE(s) that support transaction.
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-29) was last changed on 18-Nov-08 16:16 PM, -0800 by Murali