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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-comment message

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


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


[forwarding to wsbpel-comment]


-----Original Message-----
From: Andi Abes 
Sent: Friday, September 22, 2006 4:38 PM
To: 'Dieter Koenig1'
Cc: wsbpel@lists.oasis-open.org; Gregory Lucas
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]