Binding MEP behaviour leaking up to process? (was RE: Fault toleranceconsiderations)

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Edwin Khodabakchian wrote:

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.

I was referring to the <receive>/<invoke>, and <receive>/<reply> pairs of activities, for services offered. Each pairing reflects a different MEP. You are correct about <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.

This sounds like a good practice, given how BPEL and WSDL work. Isn't this alignment an illustration of the need for either the BPEL author or the WSDL portType writer to be aware of the MEPs supported by the underlying bindings?

Suppose I have two bindings that I want to create for the same portType: one for JMS, the other for BP 1.0. Following the best practice, two different portTypes will actually be needed [1], and we will need two different process definitions, one for each portType. One (bound to BP 1.0) can use <invoke> for request/reply, the other (bound to JMS), <invoke>/<receive>, as you pointed out [2]. Doesn't this need for two processes, with different patterns based on MEPs, illustrate binding information (indirectly) leaking up to the process level?

Cheers,
-Ron

[1] Easier to do in WSDL 1.2!
[2] For the offered service, the activities turn into <receive>/<send> or <receive>/<reply>, but the logic is much the same.