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
Sent: Wednesday, October 15, 2003 11:25
To: Marin, Mike; 'Ugo
Corda'; 'Ron Ten-Hove'; 'Fletcher, Tony'
Cc: 'bpel implementation'
Subject: RE: [wsbpel-implement] Fault
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
because this is what the developer wants. Otherwise he would have
<receive name="rcv" ... />
<assign name="as1" ... />
<invoke name="inv" ... />
<assign name="as2" ... />
<invoke name="callback" ... />
language is offer the choice to the developer.
From: Ugo Corda
Sent: Wednesday, October 15, 2003 10:02
To: Marin, Mike; Ron
Ten-Hove; Fletcher, Tony
RE: [wsbpel-implement] Fault tolerance
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?
Sent: Wednesday, October 15, 2003 9:30
To: Ron Ten-Hove;
Cc: Ugo Corda;
RE: [wsbpel-implement] Fault tolerance considerations
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)?
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.
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
Sent: Wednesday, October 15, 2003 8:28
Cc: Ugo Corda; Marin,
Mike; bpel implementation
Subject: Re: [wsbpel-implement] Fault
Fletcher, Tony wrote:
Dear Ron, Mike, Ugo,
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 (???)
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.