Title: Message
Hello
Mike,
nothing stops you from doing it async, and in fact for reliability
reasons it is a good idea to use async methods, possibly with reliable
messaging. But if you have to implement a sync. web service with Best-Efford
Quality of Service, you should be able to do this.
Our
engine allows the QOS to be configured. Currently in both cases the problem is
detected on the reply activity (not before), and then is decided if the
(unhandled) error should be preserved or forgotten, because there is nothing
which can be done about it.
Mit freundlichen Grüßen
Bernd
Eckenfels
Chief Architect
--
SEEBURGER
AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone:
+49 (0)7252 96-1256
mailto: - http://www.seeburger.de
-----Original Message-----
From: Marin, Mike
[mailto:]
Sent: Wednesday, October 15, 2003 6:30
PM
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.
AUTOTEXTLIST
\s "E-mail Signature" --
Regards,
Mike
Marin
-----Original
Message-----
From: Ron
Ten-Hove [mailto:]
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:
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
