Re: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?

[Danny van der Rijn <dannyv@tibco.com>]

i would have thought that whether there were more than one instance would be
implementation defined.  however, all messages ot the port type would go to
all of the instances in cases where that makes sense.  in cases where it
doesn't, that, too, would be implementation defined.

danny

----- Original Message ----- 
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Thursday, April 15, 2004 7:37 PM
Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?


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 <http://www.oasis-open.org/apps/org/workgroup/wsbpel>  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 <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php>
- 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
<http://www.choreology.com/external/WS_BPEL_issues_list.html> .

Issue - 118 - When are Correlation Sets Mandatory?

Status: open
Categories: Correlation
Date added: 15 Apr 2004
Submitter: Yaron Y. Goland <mailto:ygoland@bea.com>
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_workgr
oup.php.