[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?
I could easily argue that it is in fact better that each spooled request creates a process instance so that, for instance if there is a failure, it can be diagnosed later by inspecting the history of that specific printing request separate from all others. The patterns book is not focused on process design, so that fact of occurring in that book does not really tell us that this is meaningful for a process modeling notation. Once again, the point is not whether one can do something like this in BPEL today, the question is whether this is a compelling requirement for us to go and support as a natural use case. Satish -----Original Message----- From: Maciej Szefler [mailto:mbs@fivesight.com] Sent: Thursday, April 22, 2004 10:53 AM To: Ugo Corda Cc: Satish Thatte; ygoland@bea.com; wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory? 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]