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 - 118 - When are Correlation Sets Mandatory?


Title: Message
Hmm, this requirement for correlation sets sounds surprising to me too. I would have thought that, when a process is instantiated that does not have a correlation set defined, a single instance of that process would exist. All messages would be sent to that single instance. No new instances would be created until that existing instance terminates. I don't fully understand what would be wrong with the scenario I just described.
 
Ugo
-----Original Message-----
From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]
Sent: Thursday, April 15, 2004 10:58 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 118 - When are Correlation Sets Mandatory?

Status: open
Categories: Correlation
Date added: 15 Apr 2004
Submitter: Yaron Y. Goland
Date submitted: 15 April 2004
Document: BPEL Specification
Description: It wasn't until Satish explicitly pointed it out to me that I finally understood that all Picks and Receives MUST have at least one correlation set defined on them with "initiate = 'no'" unless the pick/receive is a start activity. I had always assumed that the system was allowed to implicitly route messages based on URL but that is in fact wrong. All routing criteria MUST be explicit and MUST be specified by a correlation set. This also means that it is always illegal to have a pick or receive which does not have at least one correlation set on it.

Normative Change - The schemas for pick and receive make correlation sets optional. That would appear to be wrong.

Also, I'm unclear about what assumptions we make regarding invoke, specifically, is there a requirement to have a correlation set defined on pattern="in" on an invoke? This is kind of a tricky issue. If a synchronous transport is being used then there may not be any explicit information available to mark the response for correlation purposes. In that case do we allow the correlation set for the response to be left off or do we require programmers to use issue 96 : Engine-managed correlation sets ?

Also note, that the WSDL 1.1 spec quite clearly states that request/responses do not have to be sent over synchronous transports so there may be values we could use for correlation sets. In other words, the situation is inconsistent. In some cases a request/response uses a synchronous transport and in other cases it could be using an asynchronous transport with some message based correlation. Do we want to distinguish these cases or do we want to just say that we presume that any time a request/response pattern is used there is some correlation mechanism implicitly known to the engine and therefore correlation sets are always optional on the incoming message? Reply has the same issue as responses on invokes.
Changes: 15 Apr 2004 - new issue


To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 118 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.



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