[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?
>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. > > Some client libraries allow you to send a request and receive the response asynchronously even when using a synchronous protocol like HTTP. So to assume something is synchronous because some library handles HTTP that way is not something I will use in a specification. However, what if we define a synchronous channel as one that is blocked after receiving a request and cannot receive until after it emitted a response? If such a channel was defined by a combination of partner link/operation/correlation set, then a receive/reply pair would in fact be synchronous, with respect to both client and server, and independent of protocol or implementation details. Now, it's fair to say that a receive/reply pair implements a request/response pattern. But there's some added semantic when we say it's synchronous. A request/response operation is not necessarily blocked in such a manner. Assaf >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. > > > -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]