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

["Yaron Y. Goland" <ygoland@bea.com>]

You should open up an issue on that one. I think it's worth exploring 
further and I suspect the discussion around it would lead to clearer 
language.

Eckenfels. Bernd wrote:

> 
> 
> I propose to remove the term synchronous in al places where it is 
> talking about a two way request-respone operation, and use 
> request-response for it. We did that inhouse, too since it is just too 
> confusing to explain the actual meaning every time the term is used.
> 
> Mit freundlichen Grüßen
> Bernd Eckenfels
> Chief Architect
> -- 
> SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
> Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
> mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
> 
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Saturday, April 17, 2004 3:09 AM
> To: ygoland@bea.com; Maciej Szefler
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?
> 
> 
>  > this is not clearly spelled out one way or another in the spec.
> 
> I agree. I think the problem with synchronous vs. asynchronous in the
> BPEL spec is that the terms are used somewhat differently than their
> usual meaning in the context of request-response MEPs.
> 
> Usually people think of a synchronous request-response as one where the
> client has to wait for the response, and an asynchronous
> request-response as one where the client can do other things between the
> request and the response. (I am aware that some people have other
> understanding of the terms, as I learned after countless discussions on
> this subject in the W3C Web Services Architecture WG, but I think this
> is the most common understanding).
> 
> In the case of BPEL, the term synchronous makes sense in the case of a
> request-response <invoke>. The BPEL process instance (the client)
> actually waits until the response comes back. That is true regardless of
> whether the transport binding is synchronous or not.
> 
> But in the case of a BPEL <receive>/<reply> the term synchronous seems
> to make much less sense. It is true that, given a synchronous transport
> binding, the client (i.e. the Web service interacting with the process)
> would have to wait until it gets the response from the process. But as
> soon as the transport binding is asynchronous, this assumption is not
> valid any more. For instance, a JAX-RPC 2.0 client can issue a request
> against a BPEL/WSDL request-response port, then happily start some other
> activities, and finally receive the BPEL response on a different thread.
> 
> So my understanding of the use of the terms synchronous and asynchronous
> in the BPEL spec is that it made sense at the time a WSDL
> request-response port implied a synchronous transport. (Even though WSDL
> does not require that, it is what implementations have been supporting
> so far). As implementations evolve to support asynchronous transport
> bindings, I think the current BPEL terminology makes much less sense.
> 
> Ugo
> 
>  > -----Original Message-----
>  > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>  > Sent: Friday, April 16, 2004 2:27 PM
>  > To: Maciej Szefler
>  > Cc: wsbpel@lists.oasis-open.org
>  > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets
>  > Mandatory?
>  >
>  >
>  > See below
>  >
>  > Maciej Szefler wrote:
>  >
>  > >
>  > >
>  > > Yaron,
>  > >
>  > > On Thu, 2004-04-15 at 12:58, ws-bpel issues list editor wrote:
>  > >
>  > >  > Normative Change - The schemas for pick and receive make
>  > > correlation  > sets optional. That would appear to be wrong.  >
>  > > This change would preclude start activities without a
>  > correlation set;
>  > > for example if every time I get a message on some port I
>  > want to start a
>  > > new process but there is nothing unique in the received message (the
>  > > operation may have an input message with no unique parts).
>  > To make this
>  > > more concrete, if I have a process for making pizza's, I
>  > might want the
>  > > makePizza(toppings) operation start the process. In this
>  > case there is
>  > > nothing in the makePizza input message to uniquely identify the new
>  > > pizza process (topping not being unique), so there is nothing to
>  > > initiate a correlation set with.  This is explictly allowed
>  > in the spec
>  > > in sec 6.5:
>  > >
>  > >          "If exactly one start activity is expected to
>  > instantiate the
>  > > process,
>  > > the use of correlation sets is unconstrained. This includes
>  > a pick with
>  > > multiple onMessage branches; each such branch can use different
>  > > correlation sets or no correlation sets."
>  > >
>  > > Are you of the opinion that such usage should not be permitted?
>  > >
>  >
>  > There had to be some sort of correlation or the message would
>  > never have
>  > reached the BPEL instance in the first place. For the scenario you
>  > describe I would recommend Issue 96, engine managed
>  > correlation. In this
>  > case the 'correlation' is just the URI assigned to the
>  > process instance.
>  > This would fully support the scenario you describe but be consistent
>  > with our correlation model.
>  >
>  > Another possibility is to specify the absence of a correlation set as
>  > meaning that correlation is being handled by the engine but
>  > that leads
>  > to ambiguities (which seems to be my theme for this week).
>  > For example,
>  > if I specify a single correlation set then did I meant to do
>  > correlation
>  > exclusively on that correlation set or on a combination of the
>  > correlation set and some unspecified machine specific
>  > correlation mechanism?
>  >
>  > Still, as ambiguities go I think I might be able to live with
>  > this one.
>  > I really need to noodle on our correlation set model some
>  > more. It just
>  > seems a big, clunky. The whole start activities mess is
>  > another symptom
>  > of the clunkiness.
>  >
>  > >
>  > >  > 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  > the same issue as responses on
>  > invokes.  >
>  > > Changes: 15 Apr 2004 - new issue The transport being
>  > asynchronous is
>  > > an irrelevant implementation detail (at least as far as the BPEL
>  > > language is concerned): the fact that the operation is declared
>  > > synchronous means that the transport (not the
>  > > engine) has some (transport-specicific) means of matching up the
>  > > response to the request. For the simple HTTP case this is
>  > simple: the
>  > > response is received on the same socket. For an
>  > asynchronous transport
>  > > like JMS, something like the correlationId property of the
>  > JMS message
>  > > would need to be used match up the response to the request; the
>  > > setting and interperetation of such a property would need to be a
>  > > feature of the JMS protocol binding. This applies to both in the
>  > > invoke case and the receive/reply case.
>  > >
>  > > -Maciej
>  > >
>  >
>  > I happen to agree with you but this is not clearly spelled
>  > out one way
>  > or another in the spec.
>  >
>  > >
>  > >
>  > > 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.
> 
> 
> 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. 
> 
> 
> 
> 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. 
> 
>