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

["Ugo Corda" <UCorda@SeeBeyond.com>]

Danny,
Please see my responses below.

Ugo

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com] 
> Sent: Friday, April 16, 2004 3:41 PM
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets 
> Mandatory?
> 
> 
> i'm concerned that such a difference of opinion exists on 
> such a basic part of the spec.  i think that that largely 
> derives from the fact that the spec says little or nothing 
> about how different process instance relate to each other.
> 

I agree.

> my understanding is that in the case Ugo describes, a 
> different instance is created for each incoming message to 
> the initial instance-starter that has no correlations.
> 

I cannot think of a useful use case that would justify the creation of
all these undistinguishable instances. It also would imply that each
individual subsequent message (not directed to the start activity) would
have to be broadcast to all instances (since there is no way to
distinguish them) and, again, I have trouble thinking of a use case
where that would make sense.

> > When there are no existing instances, the first message directed to 
> > that activity would instruct the BPEL processor to instantiate one. 
> > Once that happens, the flow of execution would go past that start 
> > activity, and any additional incoming message directed to that same 
> > activity would just get dropped to the floor because the targeted 
> > activity is not active and ready to get it
> 
> it wasn't "active and ready" before that message was recieved 
> (if i understand your interpretation correctly).
> 

In a way it was. Think about the correlation case. The start activities
for all the existing instances are not active any more (the flow of
execution has gone past them), but we should think of those same start
activities in the process "template" as being active and ready in case
messages are directed to them with new correlation values that do not
belong to any existing instances.

> > (and the BPEL engine would have no reason to
> > create a new instance, since there is no correlation set that would 
> > distinguish it from the already existing instance).
> 
> you're saying that every <process> that has a starter with no 
> correlations MUST be a singleton.  that certainly isn't my 
> interpretation.  however, my interpretation doesn't allow for 
> a process to say that it's a singleton.
> 
> it seems to me that in the current spec, whether a process is 
> a singleton or not is completely implementation defined.  so 
> we either need to pin it down in the spec on way or another, 
> or point out that it's implementation-specific.
> 
> danny
> 
> ----- Original Message ----- 
> From: "Ugo Corda" <UCorda@SeeBeyond.com>
> To: <ygoland@bea.com>
> Cc: <wsbpel@lists.oasis-open.org>
> Sent: Friday, April 16, 2004 2:36 PM
> Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets 
> Mandatory?
> 
> 
> I can also think of how the single start activity would work 
> even in cases where it does not have restricted access.
> 
> When there are no existing instances, the first message 
> directed to that activity would instruct the BPEL processor 
> to instantiate one. Once that happens, the flow of execution 
> would go past that start activity, and any additional 
> incoming message directed to that same activity would just 
> get dropped to the floor because the targeted activity is not 
> active and ready to get it (and the BPEL engine would have no 
> reason to create a new instance, since there is no 
> correlation set that would distinguish it from the already 
> existing instance).
> 
> Ugo
> 
> > -----Original Message-----
> > From: Yaron Y. Goland [mailto:ygoland@bea.com]
> > Sent: Friday, April 16, 2004 2:21 PM
> > To: Ugo Corda
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets 
> > Mandatory?
> >
> >
> > Far from there being anything wrong with the case you 
> describe, it is,
> > in fact, quite common and even has a name - a singleton service.
> >
> > But couldn't one trivially implement a singleton service by 
> creating a
> > BPEL with a single start activity which is access restricted so that
> > only the admin can call it? The admin would then call the
> > start activity
> > exactly one time. That would guarantee that there was only
> > one instance of the service.
> >
> > I admit that it would be nice to have a way to mark a service as a 
> > 'singleton' but given that there is a work around I'm not sure it's 
> > worth providing a dedicated short cut.
> >
> > Yaron
> >
> > Ugo Corda wrote:
> >
> > >
> > > 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 <#Issue96>?
> > >
> > >     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_work
> > > group.php.
> > >
> > >
> >
> 
> 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/le
ave_workgroup.php.


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.