Yep. For this use-case though, I think a single process would work just fine.
@Samuel, have a look at the <forEach> with parallel="yes"
Cheers,
Bob
_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat
----- Original Message -----
> I'd like to second that. This is also a nice example for using two
> partnerlinks. One for the bi-lateral connection between party host and
> process, and another one for the connection between process and
> potential guests.
>
> Anyhow, you also might think of splitting the process into a
> party-host-process and a invitation-process. The latter is exactly
> like
> the process you have described, the first is in charge to spawn an
> instance of the first process for each guest and then collect the
> results. This is a "request-with-referral" SIP
> (http://math.ut.ee/~dumas/ServiceInteractionPatterns/Animation-Request-with-Referral.html)
>
> I think the important thing is to overcome the procedural thinking.
> Instead of having a single process instance that takes care of
> everything, it is better to have a process instance for each guest so
> that a process instance is directly connected to the state of an
> invitation of a guest.
>
> Tammo
>
> On 10.05.2011 16:27, Bob Brodt wrote:
> > Hmm, here's how I would approach this: A BPEL process, being a
> > *service*, needs to receive some kind of request message to initiate
> > a new process instance. This could be something like you, as the
> > "party host", sending details of your party (guest list, date/time,
> > place, etc.) to the process. The process would then send an
> > invitation to each person on the guest list with an <invoke> on an
> > email service. The <invoke> would have to define a correlation on
> > the party invitation message (like the person's first & last name.)
> > Then use a <pick> with createInstace="yes" to wait for replies. The
> > <onMessage> in the <pick> would use the same correlation data as the
> > <invoke> on the guest's reply email. Presumably you would also set a
> > timeout (probably the R.S.V.P. date for the party) and have an
> > <onAlarm> to handle the "no response" cases. Each email sent to your
> > guests becomes a separate process instance, with the correlation as
> > a "handle", so your would have N+1 instances (N=number
> of guests + 1=the original invitation request) running concurrently.
> BPEL is designed for long running processes, and the runtime (ODE in
> this case) will persist state information, so even if the server
> crashes, your process instances are persisted and will resume when the
> server is restarted.
> >
> > _______________________________________
> > Robert ("Bob") Brodt
> > Senior Software Engineer, JBoss Riftsaw
> > JBoss by Red Hat
> >
> > ----- Original Message -----
> >> coincidently, I've got one problem similar to this. look, i have
> >> this
> >> case:
> >> I want to make a more complex test of BPEL, so, I'll make a
> >> business
> >> process that send invitations to my party via email. that's the
> >> business process:
> >> 1- send an email with an invitation and ask for answers about who
> >> will
> >> go to the party.2- wait for the answers3- if the answer is 'yes',
> >> send
> >> another email with the party details, else, send an email thanking
> >> the
> >> person for answering.
> >> the problem for me is that how can i wait for some people answer
> >> while
> >> i have to send the feedback emails... the step 3 depends on the
> >> step
> >> 2, but at the same time one person answer my email and i have to
> >> give
> >> the person a feedback, I have to wait other people answer.
> >> I don't know if BPEL can do this. for example, if the server shut
> >> down, would I have to restart all the process(send the invitations
> >> and
> >> wait for all answers again)?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> From: [email protected]
> >>> To: [email protected]
> >>> Subject: RE: Question about using BPEL
> >>> Date: Mon, 9 May 2011 15:15:32 +0000
> >>>
> >>> As you suggest, parallelism should help. I'm not sure about the
> >>> dependencies that you're talking about, but correlations could
> >>> help
> >>> maybe ?
> >>>
> >>> -----Original Message-----
> >>> From: Samuel Tamassia Martinez
> >>> [mailto:[email protected]]
> >>> Sent: lundi 9 mai 2011 17:10
> >>> To: User ODE
> >>> Subject: RE: Question about using BPEL
> >>>
> >>>
> >>> this question looks interesting, I haven't thougt of it, does
> >>> anybody knows about?
> >>>
> >>>> From: [email protected]
> >>>> To: [email protected]
> >>>> Subject: Question about using BPEL
> >>>> Date: Fri, 6 May 2011 14:39:32 -0300
> >>>>
> >>>>
> >>>> Hi,
> >>>> I am creating a process that should be covered by different
> >>>> clients of mine. Each customer will be in a different step in
> >>>> this
> >>>> process. I am in doubt about using BPEL to address this question,
> >>>> since this process would need to perform several steps at the
> >>>> same
> >>>> time, which to my mind runs away from his purpose.
> >>>> I'm thinking of using parallelism, but there are dependencies
> >>>> between the steps that must be performed several times for
> >>>> different customers.
> >>>>
> >>>> Thx a lot!
> >>>> Bruno Fiusa
> >>>>
> >>>> "Just do IT."
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> -
> >>> -----------------------------------------------------------------------------
> >>>
> >>> E-MAIL DISCLAIMER
> >>>
> >>> The present message may contain confidential and/or legally
> >>> privileged information. If you are not the intended addressee and
> >>> in
> >>> case of a transmission error, please notify the sender immediately
> >>> and destroy this E-mail. Disclosure, reproduction or distribution
> >>> of
> >>> this document and its possible attachments is strictly forbidden.
> >>>
> >>> SPACEBEL denies all liability for incomplete, improper,
> >>> inaccurate,
> >>> intercepted, (partly) destroyed, lost and/or belated transmission
> >>> of
> >>> the current information given that unencrypted electronic
> >>> transmission cannot currently be guaranteed to be secure or error
> >>> free.
> >>> Upon request or in conformity with formal, contractual agreements,
> >>> an originally signed hard copy will be sent to you to confirm the
> >>> information contained in this E-mail.
> >>>
> >>> SPACEBEL denies all liability where E-mail is used for private
> >>> use.
> >>>
> >>> SPACEBEL cannot be held responsible for possible viruses that
> >>> might
> >>> corrupt this message and/or your computer system.
> >>> e
> >>> ------------------------------------------------------------------------------
>
> --
> Tammo van Lessen - http://www.taval.de
