RE: [wsbpel-implement] Fault tolerance considerations

["Edwin Khodabakchian" <edwink@collaxa.com>]

Ron,

    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). 

 

I am not sure I understand this point. The process designer has only visibility into the port type definition, not the binding. I think that part of the confusion here is that a synchronous portType operation can be implemented through an asynchronous binding. But in that case, from the perspective of the BPEL engine, there is only one activity: an invoke.

 

The best practice though is to align the portType operation with the binding: if you are using a JMS binding, then create 2 port types and a partner link and use invoke/receive.

 

Edwin 

-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:Ronald.Ten-Hove@Sun.COM]
Sent: Friday, October 17, 2003 1:16 PM
To: edwink@collaxa.com
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:MMarin@filenet.com]
Sent: Wednesday, October 15, 2003 11:50 AM
To: edwink@collaxa.com; 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: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  

--

Regards,

Mike Marin

-----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]-->