From agila-user-return-170-apmail-incubator-agila-user-archive=www.apache.org@incubator.apache.org Sun Feb 12 19:20:29 2006 Return-Path: Delivered-To: apmail-incubator-agila-user-archive@www.apache.org Received: (qmail 73158 invoked from network); 12 Feb 2006 19:20:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Feb 2006 19:20:29 -0000 Received: (qmail 58494 invoked by uid 500); 12 Feb 2006 19:20:28 -0000 Mailing-List: contact agila-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: agila-user@incubator.apache.org Delivered-To: mailing list agila-user@incubator.apache.org Received: (qmail 58483 invoked by uid 99); 12 Feb 2006 19:20:27 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Feb 2006 11:20:27 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of matthieu.riou@gmail.com designates 66.249.82.196 as permitted sender) Received: from [66.249.82.196] (HELO xproxy.gmail.com) (66.249.82.196) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Feb 2006 11:20:27 -0800 Received: by xproxy.gmail.com with SMTP id i28so560993wxd for ; Sun, 12 Feb 2006 11:20:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LMOM3IwMTQ3qLfVkbsEBKv22wlkOoGSiMHIQWOYns53d/oB/+Td02xD+bcM6WczF217Xi+7T1573Bv8De0ww3+imyA9/aGTjT9QNzIz7eSbKwofST1ArUyc1gbydwDWD6gmXqN9WBbWL0l+oDi0C+LAemy0LKxYQvoaSxC+zl7U= Received: by 10.11.98.17 with SMTP id v17mr15858cwb; Sun, 12 Feb 2006 11:20:06 -0800 (PST) Received: by 10.11.120.24 with HTTP; Sun, 12 Feb 2006 11:20:06 -0800 (PST) Message-ID: Date: Sun, 12 Feb 2006 20:20:06 +0100 From: Matthieu Riou Reply-To: matthieu.riou@gmail.com To: agila-user@incubator.apache.org Subject: Re: Terminated instance and correlations In-Reply-To: <43EF7C7A.5070900@cs.indiana.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200602110007.54018.lingda@libero.it> <200602111829.03250.lingda@libero.it> <200602111903.47817.lingda@libero.it> <43EF7C7A.5070900@cs.indiana.edu> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 dependent. 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. Regards, Matthieu. 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 - http://davideling.altervista.org > >>Key fingerprint =3D 284A 0FB9 F9F6 763C D429 E02B AA5D 483A 7E45 D2A6 > >> > >> > >> > > > > > > > > > -- > The best way to predict the future is to invent it - Alan Kay > >