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


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.

HTH
Kind Regards
DK
                                                                       
 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"                                               
             <aabes@sonicsoftw                                         
             are.com>                                                   To
                                       Dieter Koenig1/Germany/IBM@IBMDE
             22.09.2006 22:38                                           cc
                                       <wsbpel@lists.oasis-open.org>,  
                                       "Gregory Lucas"                 
                                       <glucas@sonicsoftware.com>      
                                                                   Subject
                                       RE: [wsbpel] Issue - R13 - BPEL 
                                       partner link assignments        
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       






Dieter,
  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
BPEL.



Do you mean that it is not a valid approach, which is not supported by
BPEL?
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
asynchronous.
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?


TIA,
Andi.






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