[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]