As you said, teh specification has a speak really comples, I've tried to learn 
somethings from there but learned just a few things...
anyway, thank you so much, i'll begin learning about BPEL and WSDL/SOA 
too(never used a web service before) =]

> Date: Tue, 10 May 2011 22:31:37 +0200
> From: [email protected]
> To: [email protected]
> Subject: Re: Question about using BPEL
> 
> Hi Samuel,
> 
> complex things are described pretty good in the spec [1], however, since
> it's a spec, the speak is quite, well, complex ;)
> 
> A good entry point is also the BPEL primer [2].
> 
> A good introduction can also be found in Sanjiva et al's book [3].
> 
> If you were German, I could recommend our book about BPEL ;)
> 
> HTH,
>   Tammo
> 
> [1] http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
> [2] http://docs.oasis-open.org/wsbpel/2.0/Primer/wsbpel-v2.0-Primer.pdf
> [3] http://www.amazon.com/dp/0131488740
> 
> On 10.05.2011 18:41, Samuel Tamassia Martinez wrote:
> > 
> > Thank you very much for these hints, do you have any site or hint about how 
> > you've learned BPEL? I'm newbie and don't know how to make more complex 
> > things =/ 
> > sorry for the spam and thanks once more...
> > 
> >> Date: Tue, 10 May 2011 11:37:40 -0400
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: Re: Question about using BPEL
> >>
> >> 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
> >                                       
> 
> -- 
> Tammo van Lessen - http://www.taval.de
                                          

Reply via email to