[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?
Your example has a spoolID, it just happens to be a fixed number with only one legal value and is implicit in the address of the process. When viewed in that way the scenario fits well into BPEL. It's all a matter of perspective. Ugo Corda wrote: > > > I think you are referring to a use case different than the one Maciej > and myself were talking about. Your example has multiple instances of > the process, each associated with a different spool. The use case I was > making is one where there is only a single spool (so there is really no > need of a spoolID, even if implicit) and multiple printing requests > against that single spool. My point was about not having one separate > process instance for each of those printing requests. > > Ugo > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Thursday, April 22, 2004 4:55 PM > > To: Maciej Szefler > > Cc: Ugo Corda; Satish Thatte; wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 118 - When are Correlation Sets > > Mandatory? > > > > > > There is always a spoolID but it might be implicit. For > > example, rather > > than having an explicit spoolID in the message the URI the message is > > sent to may implicit represent that spoolID. > > > > It seems to me that at a minimum we should clarify the language such > > that it is fine to leave a correlation set off a message > > activity if the > > correlation semantics are being handled at the WSDL level or below. > > > > In other words if each printer spool I create has a unique > > address and > > correlation is based on that address then I shouldn't be > > forced to put > > correlation sets on my receives. I should be able to leave > > them off and > > let the engine handle it. > > > > Just a thought, > > > > Yaron > > > > Maciej Szefler wrote: > > > > > > > > > > > The bizarre thing is that in BPEL you can implement a > > singleton print > > > spooler, but only if there exists /the possiblity/ that it is not a > > > singleton. That is, if the print spooler has a spool(spoolId, > > > printjob) method, then you can correlate on spoolId and tell your > > > clients to always place X for spoolId and voila, you have a > > singleton. > > > Of course you need a createSpooler(spoolId) method to start the > > > spooler. Seems to me if you can do this much, you should > > also be to do > > > it in a natural way (i.e. without the useless spoolId). > > > > > > -maciej > > > > > > On Thu, 2004-04-22 at 12:08, Ugo Corda wrote: > > > > Well, the singleton pattern is well know and widely used. It was > > > first > codified in the Gang of Four's patterns book. A printer > > > spooler is a > classic example (from that same book), and > > in high-end > > > printing it is > easy to think of printing processes that > > are complex > > > enough to justify a > BPEL spooling process. I am sure > > people who are > > > more business-minded > than myself can come up with some typical > > > business example. > > Ugo > > > > > > > > > -----Original Message----- > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > Sent: Thursday, April 22, 2004 9:16 AM > > > > > To: Ugo Corda; ygoland@bea.com; Maciej Szefler > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > > > > > Mandatory? > > > > > > > > > > > > > > > Singletons are not a concept supported by the current > > > > > specification. The current assumption is that a process > > > > > always operates through instances and therefore > > > > > message-instance correlation must be specified for all > > > > > inbound messages, (optionally) except for the one that > > > > > instantiates the process. > > > > > > > > > > I have not seen any compelling argument for supporting > > > > > singletons. Can somebody post a potential canonical example? > > > > > > > > > > -----Original Message----- > > > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > > > > Sent: Thursday, April 22, 2004 9:00 AM > > > > > To: Satish Thatte; ygoland@bea.com; Maciej Szefler > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > > > > > Mandatory? > > > > > > > > > > Please see my answers below. > > > > > > > > > > Ugo > > > > > > > > > > > -----Original Message----- > > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > > Sent: Thursday, April 22, 2004 7:33 AM > > > > > > To: Ugo Corda; ygoland@bea.com; Maciej Szefler > > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets > > > > > > Mandatory? > > > > > > > > > > > > > > > > > > OK, by now I am lost so I will respond here, just to clarify > > > > > > what the current spec was meant to say. > > > > > > > > > > > > 1. As Yaron said in the issue def, the current assumption is > > > > > > that all correlation must be explicit. However it is not > > > > > > true that all correlation must be specified by correlation > > > > > > sets. The exception is responses in synchronous operations. > > > > > > The assumption for synchronous ops is that the infrastructure > > > > > > will correlate request and response in both inbound and > > > > > > outbound cases. > > > > > > > > > > I now see where the term "synchronous" came for in the BPEL > > > > > spec. As I already mentioned, the use of the term with that > > > > > meaning is quite unusual, and prone to generate confusion. A > > > > > different term should be adopted (and I think you already > > > > > agree with that modification). > > > > > > > > > > > Thus the response is always properly > > > > > > correlated to the request by definition, but a request to an > > > > > > existing instance must be correlated by a cset. > > > > > > > > > > Not if you are dealing with a singleton. In that case, any > > > > > new request has only one place to go. > > > > > > > > > > > All this > > > > > > regardless of the nature of the transport binding. Of course > > > > > > a response may carry a cset, usually to initiate it (see > > > > > > below for the pizza example). > > > > > > > > > > > > 2. For a start activity, there is no requirement to have an > > > > > > inbound correlation set specified. There are two cases of > > > > > > correlation establishment for start activities. Case 1: The > > > > > > cset is specified by the message that starts a new instance. > > > > > > Case 2: The cset is created by the instance. In Case 2, the > > > > > > typical pattern is that the start activity will be > > > > > > synchronous and the response will initiate the cset -- in > > > > > > Maciej's pizza case, the instance would create the "order > > > > > > number" that is later used to let the customer know that the > > > > > > order is ready. The alternative is Case 1 -- the customer > > > > > > gives his/her (hopefully unique) name in the inbound start > > > > > > message and then that is used to inform the customer about > > > > > > the order completion. In my experience these are exactly the > > > > > > two alternatives used by real Pizza parlors. Note that Case > > > > > > 2 takes advantage of the implicit correlation of responses > > > > > > discussed in Point 1 above. > > > > > > > > > > You seem to imply here that a cset is always there (even > > > > > though it might not be initialized at start). But, according > > > > > to your point 1, I should be able to have cases that are > > > > > neither case 1 nor case 2 (i.e. no cset is even defined > > > > > throughout the process). Could you please clarify? > > > > > > > > > > > > > > > > > Does that sound more consistent? > > > > > > > > > > > > Satish > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > > > > > Sent: Friday, April 16, 2004 6:09 PM > > > > > > 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/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. > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]