<!--[if
!supportEmptyParas]--><!--[endif]-->
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…
<!--[if
!supportEmptyParas]--><!--[endif]-->
--
Regards,
Mike
Marin
<!--[if
!supportEmptyParas]--><!--[endif]-->
-----Original
Message-----
From: Edwin
Khodabakchian [mailto:edwink@collaxa.com]
Sent: Wednesday, October 15, 2003
11:25 AM
To: Marin, Mike;
'Ugo Corda'; 'Ron Ten-Hove'; 'Fletcher, Tony'
Cc: 'bpel implementation'
Subject: RE: [wsbpel-implement] Fault
tolerance considerations
<!--[if
!supportEmptyParas]--><!--[endif]-->
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
-----Original
Message-----
From: Ugo
Corda [mailto:UCorda@SeeBeyond.com]
Sent: Wednesday, October 15, 2003
10:02 AM
To: Marin, Mike;
Ron Ten-Hove; Fletcher, Tony
Cc: bpel implementation
Subject: RE: [wsbpel-implement] Fault
tolerance considerations
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-----
From: Marin,
Mike [mailto:MMarin@filenet.com]
Sent: Wednesday, October 15, 2003
9:30 AM
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.
--
Regards,
Mike
Marin
-----Original
Message-----
From: Ron
Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
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:
<!--[if
!supportLineBreakNewLine]-->
<!--[endif]-->
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
<!--[if
!supportLineBreakNewLine]-->
<!--[endif]-->