[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]