RE: [wsbpel] Issue 218 - informal recap of discussion (fowarding an email conv with Alexandre to the TC list)

Hi all,

 

Here is a part of the email that I sent to Alexandre previously on the isolation topic on MessageExchange 

**last week**:

 

===================================
I tend to think messageExchange is a token to retrieve/access a state 
facet of a partnerLink. messageExchange does NOT contain a state. The 
open/close state of IMA is NOT stored in messageExchange. It is still 
stored within a partnerLink ... I think. The messageExchange is merely 
an id to retrieve that open/close state of IMA, as we may have multiple 
conversation going on a particular parnterLink.

Therefore, I think isolation would not block concurrency based 
messageExchange alone. But, it will block concurrency based on access 
partnerLink state. 

[AYIU's additional note as of Jan 11, 2006: 

if we decide to apply isolation to message 

exchange state in partnerLink; as of discussion on Jan 10, 2006, 

we tend to not to use isolation ]

I would try to discuss the following questions with this train of 
thought ...

(BTW, I still have not made up my mind regarding all the details how 
isolation is applied to messageExchange.)
(Also note: isolation would be super vendor-implementation dependent area.)

See more inline ...

[AYIU's additional note as of Jan 11, 2006: 

the following email is based on the assumption, 

if we decide to apply isolation to message exchange state ]

 wrote:

>Hi Chris,  
>
>I have a few comments: 
>- how does the concept of IMA play along isolated scopes? If a IMA is closed within a isolated scope, when does the process sees this status change, immediately or when the isolated scope finishes? 
>

No. The status change is a part of partnerLink state change. If other 
concurrent parts of process tries to access the partnerLink state, it 
would get block. It would see just "before" and "after" picture in terms 
of isolated scope completion. Not the "immediate" version. Similar to 
control status status, I guess (?)

>While an isolated scope is being executed that started with a open IMA, could a concurrent flow in the process close the IMA 
>

No. Similar reasoning to the above. A concurrent  flow  can close the 
IMA only  after the isolated scope which opens the IMA is done. (I hope 
I understand your question correctly)

>and cause a  missingRequest fault to be raised within the isolated scope? 
>  
>

If the isolated scope which opens the IMA got executed finished first, 
the missingRequest fault would not happen, because the isolated scope 
would block the closing action until the isolated scope finishes.

If the isolated scope which opens the IMA got executed after the other 
concurrent part of the process which tries to close the IMA, then 
missingRequest would happen.

>- onEvent and parallel for-each can only have default message exchanges, whereas scopes can also have custom message exchanges, right?
>  
>

I am not sure I follow your questions here ... All scopes can have 
custom message exchange, regardless whether they are vanilla scope or 
scope for onEvent or parallel for-each.
===================================

 

 

Regards,

Alex Yiu

 

 

From Alex Yiu <>

Sent Tue 1/10/2006 7:50 PM

To wsbpeltc <>

Cc Chris Keller <>; Alexandre Alves <>; Alex Yiu <>

Subject [wsbpel] Issue 218 - informal recap of discussion

Hi all,

Informal recap of discussion today:

Properties are merely projections of variables and so any use of properties are always coupled with a variable. Hence, the isolation semantics is applied to the variable. [as mentioned in the issue description] 

messageExchange handles declared in a scope are just an identifier-like handle. The handler by itself does not have any mutatable state. Any use of messageExchange handles are always coupled with a partnerLink and the actual message exchange states (i.e. open or close state of a request-response operation) are parts of the state of a partnerLink and accessed with a messageExchange identifier. Hence, messageExchange handles are under the isolation realm.

partnerLinks declared in a scope are under isolation realm. To be more specific, the isolation is applicable only to the end point reference part of the partnerLink state, not the message exchange parts of the partnerLink state. 

correlationSets can be mutated only once by initialization. Isolation on correlationSet does not produce any valuable usage pattern in WS-BPEL. Hence, correlationSets are not under the isolation realm. 

I hope these wording reflects the intended semantics that we discussed today.
Thanks!

Regards,
Alex Yiu