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