incubator-agila-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Riou <>
Subject Re: Terminated instance and correlations
Date Sun, 12 Feb 2006 19:20:06 GMT
Hi Alek,

You're right, there's nothing in the BPEL specs stating that the
correlation can't be reused after termination. This is implementation

Ultimately the best mode would be to let the user decide and allow
per-process configuration to say whether the creation of a new
instance having the same correlation as a terminated one is allowed.
However as a first implementation, I decided to be restrictive to
start with. I basically made this choice to make reporting based on
terminated instances easier by users wanting to do so. But in the
future both modes should be supported.



On 2/12/06, Aleksander Slominski <> wrote:
> hi,
> AFAIK there is no requirement in the BPEL spec that engine must forever
> prevent the same correlation to be reused?
> i think it is a good implementation option for a BPEL engine to prevent
> reuse for some processes but there are good cases when correlation is
> used again and again to start new processes that after starting create
> new correlations that then are sent to and used by clients to talk to a
> particular workflow instance.
> this is a common case for a "factory" webservice: first message asks
> factory to create something (this is a correlation) - there can be
> multiple requests for the same thing to be created - and after creation
> the factory returns message with more data inside that is a new
> correlation that identifies a process instance that was created by the
> engine implicitly.
> anyway i would like to find a definitive answer to that ...
> thanks,
> alek
> here is from BPEL 1.1 (6.4. The Lifecycle of a Business Process) - i
> think initial order has no need to have a unique order id in it but
> acknowledgment has unique id (correlation) to use by the buyer : "For
> example, in a supply chain, a seller's business process might offer a
> service that begins an interaction by accepting a purchase order through
> an input message, and then returns an acknowledgement to the buyer if
> the order can be fulfilled. It might later send further messages to the
> buyer, such as shipping notices and invoices. The seller's business
> process remembers the state of each such purchase order interaction
> separately from other similar interactions. This is necessary because a
> buyer might be carrying on many simultaneous purchase processes with the
> same seller. In short, a BPEL4WS business process definition can be
> thought of as a template for creating business process instances."
> Matthieu Riou wrote:
> >That's right. However I would recommend using an correlation that is
> >meaningful for the parties (the other web services) you are
> >communicating with. When communicating with a shippment web service,
> >use the shipping id. When communicating with a payment web service,
> >use the financial transaction id.
> >
> >On 2/11/06, Davide Ling <> wrote:
> >
> >
> >>On Saturday 11 February 2006 18:42, Matthieu Riou wrote:
> >>
> >>
> >>>Yep, that's right. However the correlation is built using several
> >>>properties so you could include this userID or taxNumber as a property
> >>>in a correlation, provided that the correlation also has
> >>>transactionUUID type properties.
> >>>
> >>>
> >>So if I want to create a good correlation set I have to put together
> >>xml elements to form an univoque information like a
> >>database complex primary key.
> >>
> >>Example (userID, transactionTimestamp)... if I suppose one user can do
> >>a transaction at time.
> >>--
> >>Davide Ling
> >>Sito Personale -
> >>Key fingerprint = 284A 0FB9 F9F6 763C D429  E02B AA5D 483A 7E45 D2A6
> >>
> >>
> >>
> >
> >
> >
> --
> The best way to predict the future is to invent it - Alan Kay

View raw message