OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue - R13 - BPEL partner link assignments


I realise that the use of WS-Addressing is outside the scope of the
specification. However, both your last mail and the specification seem to
hint that the reply-to EPR is the appropriate value to assign silently to
the partnerRole. This seems incorrect to me.

In WS-Addressing, the reply-to header specifies the endpoint to which the
reply message goes. Naturally, this would be used by the reply activity in

In BPEL the partnerRole is used where two portTypes are associated with a
single partnerLinkType to describe peer-to-peer messaging. Having received a
message, a BPEL script would use the invoke activity to send messages to the
partnerRole. I think it would be a misinterpretation of the WS-Addressing
specification to use the reply-to EPR for this invocation. 

For example, consider the situation where two partners communicate using a
request/reply HTTP transport. The message sender will be obliged to set the
reply-to EPR to be "anonymous". This indicates that replies will be sent
back using the existing HTTP connection. This EPR could not be used for the
invoke on a partnerRole.

It seems more correct to me to use the "from" EPR to silently assign to the


-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] 
Sent: 25 September 2006 09:24
To: Andi Abes
Cc: Gregory Lucas; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - R13 - BPEL partner link assignments

Hi Andi, two general remarks.

The scenarios requiring WS-Addressing support are valid and permitted by
BPEL, but the presence of WS-Addressing support is not mandated by BPEL.
The infrastructure may take the WS-A replyTo EPR and assign it "silently"
to the partnerRole of the partner link used when receiving the request fro
REQ. This behavior is possible, but as BPEL is not dependent on
WS-Addressing, the specification is silent about it. It would only work
when the WS-Addressing infrastructure is also in place. OTOH, your original
scenario b) always works in a portable way.

The messageExchange attribute is only used to disambiguate the
process-internal relationship between receive (or onMessage or onEvent) and
reply activities. This also helps avoiding bpel:conflictingRequest
/bpel:conflictingReceive faults. This concept is completely independent
from instance correlation, i.e. correlation set property values,
WS-Addressing EPR Reference Parameters, etc.

Kind Regards

 Dieter König                                Mail: dieterkoenig@de.ibm.com
IBM Deutschland Entwicklung GmbH      

 Senior Technical Staff Member               Tel (office): (+49)
7031-16-3426      Schönaicher Strasse 220               

 Architect, Business Process Choreographer   Fax (office): (+49)
7031-16-4890      71032 Böblingen                       

 Member, Technical Expert Council            Tel (home office): (+49)
7032-201464  Germany                               

             "Andi Abes"                                                   
             are.com>                                                   To 
                                       Dieter Koenig1/Germany/IBM@IBMDE    
             22.09.2006 22:38                                           cc 
                                       "Gregory Lucas"                     
                                       RE: [wsbpel] Issue - R13 - BPEL     
                                       partner link assignments            

  You got the scenario I was describing just right, but I'm not sure I
completely understood some of your answers.

> > There are 2 possible implementations:
> > a)
> >   The router process assigns from the receiving partner link to a
> > variable (or message part) which is then relayed to process B.
Process B
> > then performs its activities and assigns this value to the a partner
> > link which it uses to invoke an operation on REQ.
> >
> The receiving partner link in R has no knowledge about the callback
> address provided by REQ. This approach a) may work in conjunction with
> e.g. WS-Addressing replyTo EPRs, however, this is not mandated by

Do you mean that it is not a valid approach, which is not supported by
As you pointed out, it is dependent on the assumption that the
underlying transport supports the notion of a reply address, and hence
ties the BPEL process to such transports (e.g. WSA enabled), however, my
understanding of assign from partner link seems to explicitly support
this use case.

To try another point of view, consider the following scenario.
A process performs the following activities:

1. Receive PT1, Operation1, messageExchange=First
2. Receive PT1, Operation1, messageExchange=Second
... some work...
3. Reply PT1, Operation1, messageExchange=First
4. Reply PT1, Operation1, messageExchange=Second

Now let's complicate things a bit.

Case 1.
Assume that there's a requirement to audit all request information, and
rely that to a 3'rd service.
The business logic in the requesting service should not have to change
(i.e. add information into the payload of the request) to accommodate
this new requirement.

Case 2.
 Assume that in between steps 2 & 3, there's a requirement to invoke an
operation on the originating partner - i.e introduce the following:

 2a. invoke PT1, Operation2.

Also assume that EPR encodes instance specific information (e.g
relatesTo in WSA).

Clearly these use cases relay on underlying engine capabilities (WSA or
equivalent support), and might not be completely portable.

My understanding (and please correct me if I'm wrong), is that the
messageExchange attribute is meant to be used by an engine to correlate
the reply activity to the appropriate request when multiple requests are
pending. Further, this correlation should work when the transport is
In the case that an EPR contains instance specific information, this to
me implies that the engine must maintain all separate instances of
incoming requests' EPRs.

The leap of faith I'm making is that the scenarios described above are
permissible - i.e.

1) Assignment from a dynamically initialized partner link, which was
initialized by a receive is allowed, and

2) The assignment result can be used for both data manipulation (case 1)
and for invocation of unrelated operations on the initiating partner
link (case 2).

3) if either the engine does not support the behavior described, or the
service was described using synchronous semantics (i.e. WSA anonymous)
then bpel:uninitializedPartnerRole fault is thrown when the assignment
activity is attempted.

Are these assumptions valid?  Are the use cases described above allowed?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]