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?


ugo -

i don't see these as necessarily correlated at all.  unless you're talking
about the response being correlated with the request, which i'm hoping that
we are not requiring ourselves to depend on correlation to do?

danny

----- Original Message ----- 
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org>
Sent: Monday, April 19, 2004 11:51 AM
Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?


Danny,
I think you are really arguing in favor of multiple parallel instances
with some form of engine-managed correlation, as you describe in your
cases 1,2,3 below (this would correspond to issue 96). I have no problem
with that.

My singleton discussion was rather about cases where any correlation
mechanism is completely absent.

Ugo

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Monday, April 19, 2004 10:20 AM
> To: Ugo Corda; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets
> Mandatory?
>
>
> marked with DV2
>
> ----- Original Message ----- 
> From: "Ugo Corda" <UCorda@SeeBeyond.com>
> To: "Danny van der Rijn" <dannyv@tibco.com>;
> <wsbpel@lists.oasis-open.org>
> Sent: Friday, April 16, 2004 4:44 PM
> Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets
> Mandatory?
>
>
> Responses below again.
>
> > -----Original Message-----
> > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > Sent: Friday, April 16, 2004 4:09 PM
> > To: wsbpel@lists.oasis-open.org
> > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets
> > Mandatory?
> >
> >
> > responses inline, marked with <DV>
> >
> > ----- Original Message -----
> > From: "Ugo Corda" <UCorda@SeeBeyond.com>
> > To: "Danny van der Rijn" <dannyv@tibco.com>;
> > <wsbpel@lists.oasis-open.org>
> > Sent: Friday, April 16, 2004 3:56 PM
> > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets
> > Mandatory?
> >
> >
> > 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.
> >
> > <DV> i can think of many such cases.  maciej already
> pointed one out -
> > make me a pizza.  another one might be "fire off the build
> process for
> > my product."  in either case, *if* there are subsequent messages,
> > which isn't always the case, then the process will come up with a
> > correlation ID to send back to the initiator.  the case of
> "subsequent
> > message (not directed to the start activity) would have to be
> > broadcast to all instances" is what i think this issue was about in
> > the first place.  non-initial receives are
> > *required* to have correlations, precluding any routing being
> > done by address, say.  which i also think is wrong. </DV>
> >
>
> <UC> The concept of having separate instances makes sense if
> I want to address them individually after they are initiated
> (and in order to do that I need some correlation ID). If I
> don't need to do that, why would I need to care about
> instances? If I say "make me a pizza", I then want to know
> which one is my pizza among the many coming out, so I need a
> correlation ID. So, again, in my mind it only makes sense to
> have multiple instances with correlation sets or singletons
> with no correlation sets</UC>
>
> <DV2> So you want to address them individually.  Why does
> that addressing
> *have* to come from the initial request?  It could come in a
> response (1), it could just be a request/response (2) .  Or
> it might not need to be addressable at all (3, possibly a
> special case of (2)).  an example of each of these:
>
> 1) addressable element comes in the response:  i'd like to
> start a long-running conversation.  please assign me an ID so
> we can continue to have the conversation.
>
> 2) please return the current inventory of the part number
> referenced in the request
>
> 3) please return the value of your system clock
>
> 2) and 3) look a lot like event handlers, but i don't see a
> requirement that they be written in the context of a
> different process.
>
>
> > > > 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.
> >
> > <DV> exactly my point.  so why wouldn't the active and ready start
> > activity in the non-correlation case start another
> activity?  it seems
> > to me that in your argument, one case has the "active and ready"
> > activity being in the "template" (correlation sets), while
> the other
> > has it in the instantiated process (non-correlation) and therefore
> > another instance isn't started. </DV>
>
> <UC> The argument I was making is that, in the case a
> correlation set exists, I have to distinguish between start
> activities in existing instances and start activities in
> future instances (with correlation values different than
> existing instances). Only the latter are active and ready. In
> the case of a singleton, there is either one existing
> instance or no instance at all. So, adapting the previous
> rule to this special case, if there is an existing instance
> the start activity is inactive (and there will be no new
> instances until that existing instance terminates - a message
> sent to that start activity would behave like a message
> having a correlation value identical to an existing instance:
> it would be dropped). If there are no existing instances, the
> start activity is active. </UC>
>
> <DV2> this argument sounds a bit circular to me.  but in any
> case, i think we've proved that either interpretation is
> defensible.  now we have to figure out which one is desired,
> and make the spec reflect that.
>
> my preference is to allow the parallel instances, since yaron
> and others have shown how singletons can be implemented using
> parallel instances, but i don't think it's possible to allow
> parallel instances if the singleton interpretation is used.
> i'll open an issue.  <DV2>
>
> >
> > > > (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/le
> ave_workgr
> oup.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_workgr
oup.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.


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.


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]