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 244 - Proposal for Vote


Title: Message
Thank you, Alex, now it makes more sense to me.
 
> However, if operation1 is a request-response MEP operation, then conflictingRequest fault will be thrown.
 
That depends, of course, on the time the reply occurs with respect to the various receive's. (If the reply occurs before the second receive, there would be no exception immediately after the second receive, etc.)
 
Ugo

-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, February 28, 2006 10:40 AM
To: Ugo Corda
Cc: Dieter Koenig1; wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 244 - Proposal for Vote


Hi Ugo,

Those text has been a part of BPEL spec (since BPEL 1.1?) ...
(used to be in "Execution Extension" section)

Anyhow ... here is an example: (psuedo syntax for lazy typing)
---------------------------------
  <sequence>
         <receive partnerLink1 operation1 CS1 />
          ...
          <receive partnerLink1 operation1 CS1 />
          ...
          <receive partnerLink1 operation1 CS1 />
          ...
  </sequence>
---------------------------------

With this sequence of <receive>, conflictingReceive will not get triggered at all.
Because, there is no more than one receive operation on same PL, operation and CS active at the same time.

However, if operation1 is a request-response MEP operation, then conflictingRequest fault will be thrown.
On the other hand, if operation1 is an one-way MEP operation, then fault may not be thrown at all.

This example illustrate my interpretation on that sentence.

Given Ugo's question, I think it is worthwhile to keep that sentence and highlight the differences of these two faults.

Thanks!


Regards,
Alex Yiu



Ugo Corda wrote:
Alex,
 
I personally find the text you underlined rather confusing. Do you have a simple example to visualize what that sentence says?
 
Thank you,
Ugo
 
 -----Original Message-----
From: wsbpel-return-6242-ugo.corda=sun.com@lists.oasis-open.org [mailto:wsbpel-return-6242-ugo.corda=sun.com@lists.oasis-open.org] On Behalf Of Alex Yiu
Sent: Monday, February 27, 2006 10:52 PM
To: Dieter Koenig1
Cc: wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 244 - Proposal for Vote


Hi Dieter,

+1 in general.

With a minor amendment on item (1):

There are text to compare conflictingRequest and conflictingReceive in paragraph 10 in Section 10.4, which still help users to understand the nature of conflictingRequest fault. How about merging that useful and correct part to paragraph 15, which explains bpws:conflictingRequest:

If there should ever be multiple simultaneous incomplete inbound message activities which have the same partnerLink, operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown within the BPEL process on the conflicting inbound message activities subsequent to the execution of the successful incomplete receive.  Note that bpws:conflictingRequest is semantically different from the bpws:conflictingReceive, because it is possible to create the conflictingRequest by consecutively receiving the same request on a specific partner link for a particular portType, operation and correlation set(s), while conflictingReceive fault is not triggered. 



Thanks!


Regards,
Alex Yiu



Dieter Koenig1 wrote:
In order to fix the definition of bpws:conflictingRequest, and remove
bpws:invalidReply in favor of bpws:missingRequest, I propose the following
changes to the spec.

Note that all remaing references to the tuple (partner link, port type,
operation, correlation set) - dealing with bpws:conflictingReceive - are
correct.

----------------
(1) Section 10.4 - paragraph 10 - wrong text:
The correlation between a request and the corresponding reply is based on
the constraint that more than one outstanding synchronous request from a
specific partner link for a particular portType, operation and correlation
set(s) MUST NOT be outstanding simultaneously. If this constraint is
violated during execution, then the standard fault bpws:conflictingRequest
MUST be thrown by a conforming implementation. Note that this is
semantically different from the bpws:conflictingReceive, because it is
possible to create the conflictingRequest by consecutively receiving the
same request on a specific partner link for a particular portType,
operation and correlation set(s). For the purposes of this constraint, an
onMessage clause in a pick is equivalent to a receive (see Pick).

Action - drop this text from paragraph (paragraph 15 already explains
bpws:conflictingRequest correctly). The text starting with "Moreover, ..."
remains.

----------------
(2) Section 10.4 - paragraph 12 - wrong text:
If a reply activity is being carried out during the execution of a business
process instance and no synchronous request is outstanding for the
specified partnerLink, portType, operation and correlation set(s), then the
standard fault bpws:invalidReply MUST be thrown by a conforming
implementation.

Action - drop this paragraph completely (paragraph 16 already explains it
correctly using bpws:missingRequest).

----------------
(3) Appendix A. - wrong text (table row explaining conflictingRequest):
Thrown when more than one synchronous inbound request on the same partner
link for a particular port type, operation and correlation set(s) are
active.

Action - replace with new text (table row explaining conflictingRequest):
Thrown when more than one synchronous inbound request on the same partner
link, operation and message exchange are active.

----------------
(4) Appendix A. - wrong text (table row explaining invalidReply):
Thrown when a reply is sent on a partner link, portType and operation for
which the corresponding receive with the same correlation has not been
carried out.

Action - drop this row completely (bpws:missingRequest is sufficient).


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

  




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