RE: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?

[Maciej Szefler <mbs@fivesight.com>]

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_workgroup.php.
>