[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]