My own rule is if there's a chance the operation may take more than 60 seconds, then make it an asynchronous.
This implies there's a breaking point where you can't add anymore processing inside a synchronous operation -- for transport reasons but also for other reasons (reliability, scalability, concurrency, transactions, ...). alex On Wed, Oct 1, 2008 at 6:47 AM, Jean-Claude Moissinac <[EMAIL PROTECTED]>wrote: > Hello > > We need some advise about time consuming services > > My simplified scenario is: > a BPEL calls a service which is time consuming > > first case: this call is synchronous and I get a timeout on the > request from the BPEL to the external service > second case: this case is asynchronous, the time consuming service > returns immediately after the begining of the process it is in charge > then if the BPEL is waiting for the end that process, it is the > request to the BPEL itself which fire a timeout, because the BPEL > seems to be nor responding > > So, it is not the BPEL which must wait for the external process called > by the BPEL, but the caller of the BPEL > But, how the caller of the BPEL will know how many external services > are called by the BPEL? > > Are there good practices or support about such scenario? > > -- > -- > Jean-Claude Moissinac > Signal and Image processing - Multimedia Group > TELECOM ParisTech > FRANCE > > E-mail: [EMAIL PROTECTED] > Tel: (+33) 1.45.81.80.88 > Fax: (+33) 1.45.81.71.58 > > http://videotoile.blogspot.com > http://svgmpeg4.blogspot.com/ >
