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

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.