[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-implement] Fault tolerance considerations
I meant, of course, "a protocol whose timeout interval is shorter ...".
> -----Original Message-----
> From: Ugo Corda
> Sent: Tuesday, October 28, 2003 10:49 AM
> To: rkhalaf
> Cc: Ron Ten-Hove; edwink@collaxa.com; bpel implementation
> Subject: RE: [wsbpel-implement] Fault tolerance considerations
>
>
> Rania, you say:
>
> > BPEL itself stays explictly away from binding/deployment
> information.
> > They should have no bearing at all on the process model. If
> > they do you, you're mixing up your WS layers.
>
> I think that BPEL designers will choose between synchronous
> or asynchronous interaction modes based on the expected
> bindings used. It's unlikely, for instance, that designers
> will choose a synchronous mode when the expected binding is
> to a protocol whose timeout interval is longer than the time
> required by the interaction. So, like it or not, the bindings
> do have bearing on the chosen process model.
>
> Ugo
>
> > -----Original Message-----
> > From: rkhalaf [mailto:rkhalaf@watson.ibm.com]
> > Sent: Tuesday, October 28, 2003 7:25 AM
> > To: Ugo Corda
> > Cc: Ron Ten-Hove; edwink@collaxa.com; bpel implementation
> > Subject: Re: [wsbpel-implement] Fault tolerance considerations
> >
> >
> > BPEL itself stays explictly away from binding/deployment
> information.
> > They should have no bearing at all on the process model. If
> > they do you,
> > you're mixing up your WS layers.
> >
> > If the process is to send back a message that is equivalent to the
> > output of a WSDL operation, it needs to use a "reply". If the
> > process is
> > calling another Web Service (possibly as a call-back - but must be
> > provided by that service), then you use an "invoke". It is
> > also possible
> > here that the caller had sent you his addressing info in a previous
> > message ("receive") so you can do the call-back dynamically.
> >
> > Beyond that, you are at a different level of the middleware and it
> > should be handled the same way as from any other long-running Web
> > service. The interesting thing for inter-op is that the
> > client may be a
> > BPEL itself, and we may want to see what happens there
> > although again I
> > think we should support the same behavior if we were asking
> the same
> > question for a non-bpel WS setup. It is interesting to note
> here that
> > the connection may have been dropped by the client because
> the client
> > timed-out and aborted/rolled itself back. In this case,
> what does it
> > mean if you send it the reply later asynchronously? perhaps
> > through some
> > WS-RM it can know that that's a reply to something it had
> > aborted. Many
> > of these issues are addressed or still under research in existing
> > distributed systems and are showing up again here.
> >
> > aside: if you're taking down the engine for maintenance and
> you have
> > critical long-running processes running, there are a number of
> > well-known schemes one could use such as replication.
> >
> >
> >
> >
> >
> >
> >
> > Ugo Corda wrote:
> >
> > > Ron, Edwin,
> > > It's also interesting to see that in the cases a SOAP gateway is
> > > present (if I understand correctly what Edwin mean by SOAP
> > gateway),
> > > the only link (and associated binding) that BPEL can see
> is the one
> > > between the SOAP gateway and BPEL, not the one between the
> > browser and
> > > the SOAP gateway (gateways are not supposed to be SOAP
> > > intermediaries). So the process designer has to consider
> > bindings (the
> > > protocol between the browser and the SOAP gateway) that are
> > not even
> > > properly underlying the BPEL links.
> > > Ugo
> > >
> > > -----Original Message-----
> > > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> > > Sent: Friday, October 17, 2003 1:45 PM
> > > To: edwink@collaxa.com
> > > Cc: 'bpel implementation'
> > > Subject: Re: [wsbpel-implement] Fault tolerance considerations
> > >
> > > Edwin,
> > >
> > > I think we are in agreement about the options. It is
> interesting
> > > to note that the process designer must have some level of
> > > awareness of the MEP support of the underlying binding(s).
> > >
> > > -Ron
> > >
> > > Edwin Khodabakchian wrote:
> > >
> > >> Ron,
> > >> Well, if the client is a browser or a service that
> is behind a
> > >> firewall then there are 2 acceptables exchange patterns:
> > >> synchronous request/reply...which can be modeled in
> BPEL using
> > >> <receive></reply> in BPEL. and in this case the HTTP
> > client has to keep a
> > >> connection to the server SOAP gateway (the
> interaction between
> > >> the SOAP gateway and the BPEL engine that be
> > synchronous or async).
> > >> request and then polling...which can be modeled in BPEL using
> > >> <receive> and event handlers. In this case the
> > connection between the HTTP
> > >> client and the SOAP gateway is shortlived.
> > >> If the client is behind the firewall and there is an SMTP
> > >> transport available, then the developer will most
> > likely define 2
> > >> port types and leverage a
> > <receive>...<invoke>(callback) pattern.
> > >> Did I understand your question correctly?
> > >> Edwin
> > >>
> > >>
> > --------------------------------------------------------------
> > ----------
> > >> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> > >> Sent: Friday, October 17, 2003 1:16 PM
> > >> To: edwink@collaxa.com
> > >> Cc: 'bpel implementation'
> > >> Subject: Re: [wsbpel-implement] Fault tolerance
> > considerations
> > >>
> > >> Edwin,
> > >>
> > >> I'll guess that Mike means a client that is
> > browser-based, or
> > >> otherwise running in a constrained environment
> > where creating
> > >> a local web service port for call-backs is not allowed.
> > >>
> > >> I'll add the case that I always run into -- the client is
> > >> running behind a firewall of some sort, and
> cannot create a
> > >> listener that can be called back to. The only way to get
> > >> responses is through synchronous HTTP messaging, or more
> > >> unusually, through something like SMTP.
> > >>
> > >> -Ron
> > >>
> > >> Edwin Khodabakchian wrote:
> > >>
> > >>> Mike,
> > >>> I am not sure I understand your point. Could you
> > please give
> > >>> me an example of a "casual" client and the alternative
> > >>> callback approach you are proposing?
> > >>> Edwin
> > >>>
> > >>>
> > --------------------------------------------------------------
> > ----------
> > >>> From: Marin, Mike [mailto:MMarin@filenet.com]
> > >>> Sent: Wednesday, October 15, 2003 11:50 AM
> > >>> To: edwink@collaxa.com; Ugo Corda; Ron Ten-Hove;
> > >>> Fletcher, Tony
> > >>> Cc: bpel implementation
> > >>> Subject: RE: [wsbpel-implement] Fault tolerance
> > >>> considerations
> > >>>
> > >>> <!--[if !supportEmptyParas]--><!--[endif]-->
> > >>>
> > >>> The main difference is that as soon as you
> do the call
> > >>> back, you need a WSDL file from the client,
> > and so, any
> > >>> client that wants to call your service has
> to provide
> > >>> the call back operation. Not a nice interface
> > for casual
> > >>> clients&
> > >>>
> > >>> <!--[if !supportEmptyParas]--><!--[endif]-->
> > >>>
> > >>> --
> > >>>
> > >>> Regards,
> > >>>
> > >>> Mike Marin
> > >>>
> > >>> <!--[if !supportEmptyParas]--><!--[endif]-->
> > >>>
> > >>> -----Original Message-----
> > >>> From: Edwin Khodabakchian
> [mailto:edwink@collaxa.com]
> > >>> Sent: Wednesday, October 15, 2003 11:25 AM
> > >>> To: Marin, Mike; 'Ugo Corda'; 'Ron Ten-Hove';
> > 'Fletcher,
> > >>> Tony'
> > >>> Cc: 'bpel implementation'
> > >>> Subject: RE: [wsbpel-implement] Fault tolerance
> > >>> considerations
> > >>>
> > >>> <!--[if !supportEmptyParas]--><!--[endif]-->
> > >>>
> > >>> Let assume the invoke is calling a non-BPEL
> > web service
> > >>> that uses a WSDL request-response operation that was
> > >>> implemented asynchronous and takes 10 days
> to respond.
> > >>> That means the time between receive and
> reply may take
> > >>> 10 days in the best case scenario. Will you maintain
> > >>> that session open that time?
> > >>>
> > >>> Yes because this is what the developer wants.
> > Otherwise
> > >>> he would have written:
> > >>>
> > >>><sequence>
> > >>>
> > >>> <receive name="rcv" ... />
> > >>>
> > >>> <assign name="as1" ... />
> > >>>
> > >>> <invoke name="inv" ... />
> > >>>
> > >>> <assign name="as2" ... />
> > >>>
> > >>> <invoke name="callback" ... />
> > >>>
> > >>></sequence>
> > >>>
> > >>> The language is offer the choice to the developer.
> > >>>
> > >>> Edwin
> > >>>
> > >>> --
> > >>>
> > >>> Regards,
> > >>>
> > >>> Mike Marin
> > >>>
> > >>> -----Original Message-----
> > >>> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > >>> Sent: Wednesday, October 15, 2003 10:02 AM
> > >>> To: Marin, Mike; Ron Ten-Hove; Fletcher, Tony
> > >>> Cc: bpel implementation
> > >>> Subject: RE: [wsbpel-implement] Fault tolerance
> > >>> considerations
> > >>>
> > >>> I don't fully understand your proposal.
> Right now BPEL
> > >>> supports two modes of operation: synchronous
> > >>> (receive/reply, in connection with a WSDL
> > >>> request/response operation) and asynchronous
> > >>> (receive/invoke, in connection with two WSDL one-way
> > >>> operations). So the choice is there. Why force
> > >>> everything to be asynchronous?
> > >>>
> > >>> Ugo
> > >>>
> > >>> -----Original Message-----
> > >>> From: Marin, Mike [mailto:MMarin@filenet.com]
> > >>> Sent: Wednesday, October 15, 2003 9:30 AM
> > >>> To: Ron Ten-Hove; Fletcher, Tony
> > >>> Cc: Ugo Corda; bpel implementation
> > >>> Subject: RE: [wsbpel-implement] Fault tolerance
> > >>> considerations
> > >>>
> > >>> Edwins suggestion does make sense; but
> note that this
> > >>> is not only an error recovery issue. This arises
> > >>> during normal operation. Let assume that your engine
> > >>> handle thousands of processes per hour, and
> so at any
> > >>> given moment, some of those processes will be
> > in between
> > >>> the receive/reply pair. How do you bring the
> > engine down
> > >>> for maintenance (let say hardware upgrade
> or database
> > >>> backup)?
> > >>>
> > >>> The act of bringing the engine down will
> > certainly stop
> > >>> some of the processes in the middle of the
> > receive/reply
> > >>> pair. Most engines will consider shutting down the
> > >>> engine as a normal operation, and they will keep the
> > >>> state of all the running processes, but in
> > this case you
> > >>> are forced into considering it as an abnormal
> > operation
> > >>> for those processes that are in the
> > receive/reply pair.
> > >>>
> > >>> Again, IMHO receive/reply should be
> asynchronous. They
> > >>> can be seen as synchronous from a invoke
> perspective,
> > >>> but unless is implemented as asynchronous it creates
> > >>> unnecessary issues for the implementer.
> > >>>
> > >>> --
> > >>>
> > >>> Regards,
> > >>>
> > >>> Mike Marin
> > >>>
> > >>> -----Original Message-----
> > >>> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> > >>> Sent: Wednesday, October 15, 2003 8:28 AM
> > >>> To: Fletcher, Tony
> > >>> Cc: Ugo Corda; Marin, Mike; bpel implementation
> > >>> Subject: Re: [wsbpel-implement] Fault tolerance
> > >>> considerations
> > >>>
> > >>> Tony,
> > >>>
> > >>> Fletcher, Tony wrote:
> > >>> <!--[if !supportLineBreakNewLine]-->
> > >>> <!--[endif]-->
> > >>>
> > >>> Dear Ron, Mike, Ugo, and others,
> > >>>
> > >>> Is this problem not occurring because of layer
> > >>> violation. Surely BPEL - and BPEL implementations -
> > >>> should not need to worry beyond setting a
> > timeout at the
> > >>> sending side on an invoke to which a reply is
> > expected.
> > >>> At the BPEL should just a hand a message over to the
> > >>> SOAP HTTP implementation, and receive
> > messages back from
> > >>> it. Exactly how the message is sent (and in
> particular
> > >>> whether the response rides on an HTTP response or
> > >>> request is surely not a BPEL concern (???)
> > >>>
> > >>> I think the issue arises only in error cases, where
> > >>> error recovery/handling may need some extra
> > insight into
> > >>> the lower-level binding characteristics. As
> Edwin has
> > >>> suggested, this can be determined at
> deployment time,
> > >>> along with suitable recovery policies.
> Obviously this
> > >>> sort of thing is implementation-specific,
> but Edwin's
> > >>> approach makes a lot of sense.
> > >>>
> > >>> -Ron
> > >>> <!--[if !supportLineBreakNewLine]-->
> > >>> <!--[endif]-->
> > >>>
> >
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]