[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. -- Regards, Mike Marin -----Original
Message----- Tony, 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]