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?


Fine with me -- there are only two connotations we need to preserve -- the right WSDL operation type and the implicit correlation of response to request.

Satish

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Monday, April 19, 2004 10:33 AM
To: Eckenfels. Bernd
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?

An excellent idea.
-maciej

On Fri, 2004-04-16 at 22:53, 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.
> 


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]