OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 ]


aalves@bea.com 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 <alex.yiu@oracle.com>
Sent Tue 1/10/2006 7:50 PM
To wsbpeltc <wsbpel@lists.oasis-open.org>
Cc Chris Keller <chris.keller@active-endpoints.com>; Alexandre Alves <aalves@bea.com>; Alex Yiu <alex.yiu@oracle.com>
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]