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?


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.

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.

> 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).

> (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/leave_workgroup.php.



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