OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-implement message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel-implement] Fault tolerance considerations

Title: Message


I’m only asserting two things:


1- The nature of BPEL makes it almost impossible to guarantee that the path between a receive and a reply will happen in an amount of time that make it usable as a synchronous operation. The time between the receive and the reply may be very long, and a lot of stuff may happen during that time in both ends of the connection.


2- It is a mistake for the BPEL specification to assume that a WSDL request-response operation means synchronous operation, because a WSDL 1.1 request-response operations can be implemented as synchronous or asynchronous, depending on the binding. The end result is that when you do an invoke, you may be waiting for a long time (maybe weeks), because you may invoke a non-BPEL web service that was implemented asynchronously.


Using the example given by Ron in the original message:


  <receive name="rcv" ... />
  <assign  name="as1" ... />
  <invoke  name="inv" ... />
  <assign  name="as2" ... />
  <reply   name="rep" ... />


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?




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?



-----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


Edwin’s 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.




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



Fletcher, Tony wrote:

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]