BPEL itself stays explictly away from binding/deployment information.
They should have no bearing at all on the process model. If they do you,
you're mixing up your WS layers.
If the process is to send back a message that is equivalent to the
output of a WSDL operation, it needs to use a "reply". If the process is
calling another Web Service (possibly as a call-back - but must be
provided by that service), then you use an "invoke". It is also possible
here that the caller had sent you his addressing info in a previous
message ("receive") so you can do the call-back dynamically.
Beyond that, you are at a different level of the middleware and it
should be handled the same way as from any other long-running Web
service. The interesting thing for inter-op is that the client may be a
BPEL itself, and we may want to see what happens there although again I
think we should support the same behavior if we were asking the same
question for a non-bpel WS setup. It is interesting to note here that
the connection may have been dropped by the client because the client
timed-out and aborted/rolled itself back. In this case, what does it
mean if you send it the reply later asynchronously? perhaps through some
WS-RM it can know that that's a reply to something it had aborted. Many
of these issues are addressed or still under research in existing
distributed systems and are showing up again here.
aside: if you're taking down the engine for maintenance and you have
critical long-running processes running, there are a number of
well-known schemes one could use such as replication.
Ugo Corda wrote:
> Ron, Edwin,
> It's also interesting to see that in the cases a SOAP gateway is
> present (if I understand correctly what Edwin mean by SOAP gateway),
> the only link (and associated binding) that BPEL can see is the one
> between the SOAP gateway and BPEL, not the one between the browser and
> the SOAP gateway (gateways are not supposed to be SOAP
> intermediaries). So the process designer has to consider bindings (the
> protocol between the browser and the SOAP gateway) that are not even
> properly underlying the BPEL links.
> Ugo
>
> -----Original Message-----
> From: Ron Ten-Hove [mailto:]
> Sent: Friday, October 17, 2003 1:45 PM
> To:
> Cc: 'bpel implementation'
> Subject: Re: [wsbpel-implement] Fault tolerance considerations
>
> Edwin,
>
> I think we are in agreement about the options. It is interesting
> to note that the process designer must have some level of
> awareness of the MEP support of the underlying binding(s).
>
> -Ron
>
> Edwin Khodabakchian wrote:
>
>> Ron,
>> Well, if the client is a browser or a service that is behind a
>> firewall then there are 2 acceptables exchange patterns:
>> synchronous request/reply...which can be modeled in BPEL using
>> <receive></reply> in BPEL. and in this case the HTTP client has to keep a
>> connection to the server SOAP gateway (the interaction between
>> the SOAP gateway and the BPEL engine that be synchronous or async).
>> request and then polling...which can be modeled in BPEL using
>> <receive> and event handlers. In this case the connection between the HTTP
>> client and the SOAP gateway is shortlived.
>> If the client is behind the firewall and there is an SMTP
>> transport available, then the developer will most likely define 2
>> port types and leverage a <receive>...<invoke>(callback) pattern.
>> Did I understand your question correctly?
>> Edwin
>>
>> ------------------------------------------------------------------------
>> From: Ron Ten-Hove [mailto:]
>> Sent: Friday, October 17, 2003 1:16 PM
>> To:
>> Cc: 'bpel implementation'
>> Subject: Re: [wsbpel-implement] Fault tolerance considerations
>>
>> Edwin,
>>
>> I'll guess that Mike means a client that is browser-based, or
>> otherwise running in a constrained environment where creating
>> a local web service port for call-backs is not allowed.
>>
>> I'll add the case that I always run into -- the client is
>> running behind a firewall of some sort, and cannot create a
>> listener that can be called back to. The only way to get
>> responses is through synchronous HTTP messaging, or more
>> unusually, through something like SMTP.
>>
>> -Ron
>>
>> Edwin Khodabakchian wrote:
>>
>>> Mike,
>>> I am not sure I understand your point. Could you please give
>>> me an example of a "casual" client and the alternative
>>> callback approach you are proposing?
>>> Edwin
>>>
>>> ------------------------------------------------------------------------
>>> From: Marin, Mike [mailto:]
>>> Sent: Wednesday, October 15, 2003 11:50 AM
>>> To: ; Ugo Corda; Ron Ten-Hove;
>>> Fletcher, Tony
>>> Cc: bpel implementation
>>> Subject: RE: [wsbpel-implement] Fault tolerance
>>> considerations
>>>
>>> <!--[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:]
>>> 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
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Mike Marin
>>>
>>> -----Original Message-----
>>> From: Ugo Corda [mailto:]
>>> 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:]
>>> 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
>>>
>>> Edwins 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:]
>>> 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]-->
>>>
