incubator-agila-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Terminated instance and correlations
Date Sun, 12 Feb 2006 18:20:42 GMT

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



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