[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-implement] Fault tolerance considerations
The 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 clients… -- Regards, Mike Marin -----Original
Message----- 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? Yes because this is what the developer
wants. Otherwise he would have written: <sequence> <receive name="rcv" ... /> <assign name="as1" ... /> <invoke name="inv" ... /> <assign name="as2" ... /> <invoke name="callback" ... /> </sequence>
The language is
offer the choice to the developer. Edwin -- Regards, Mike Marin -----Original
Message----- 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?
Ugo -----Original
Message----- 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]