[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R13 - BPEL partner link assignments
Hi Danny, I agree with your response - it is of course necessary that B is
able to perform the callback using the EPR received from REQ (via R).
I should have been more specific in my remark about the consumer of the
EPR. If e.g. any EPR refrence parameters are used for instance
identification on REQ's side, then this information is produced and
consumed by REQ's infrastructure, and it is opaque for B.
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
Danny van der
Rijn
<dannyv@tibco.com To
> wsbpel@lists.oasis-open.org
cc
26.09.2006 00:53
Subject
Re: [wsbpel] Issue - R13 - BPEL
partner link assignments
b) is definitely a correct approach:
1. REQ assigns from "callback partner link" (myRole) to a variable
2. REQ passes the EPR to R
3. R forwards the EPR to B
4. B assigns the EPR to "callback partner link" (partnerRole)
5. B invokes callback provided by REQ
6. REQ receives the response
The variables for the partner link assignments are typed with
sref:service-ref. The contents are opaque for R and B, that is,
whatever the EPR looks like, REQ is both producer and consumer
of this EPR.
The 2 portions of your note that I have bolded seem to me to directly
contradict steps 4.and 5. I believe that the steps are correct and that
the service-ref is NOT opaque to B, nor is REQ the consumer of the EPR, B
is.
Dieter Koenig1 wrote:
Andi, thanks for submitting your comment. Please see a couple of
remarks
inline below.
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@sonicsoftware.com> wrote on 20.09.2006 23:36:08:
I'm trying to understand the semantics of assignment to and
from partner
links in BPEL, and the spec left me with a few open questions.
For the purpose of discussion, I'm considering a simple
"router" process
(R).
The one operation exposed by this process includes 2 parts:
1) an amount (xsd:int)
2) the EPR of the requesting process (process REQ)
This operation is one way.
Based on content in the incoming request, the router chooses a
process
(process B) to "forward" the request to. Process B is expected
to invoke
an agreed upon operation on Process REQ, using the EPR
information in
the message.
This is how I read your scenario:
Process REQ Router Process R Process B
---------------- ---------------- ----------------
+------------------>|
| (amount, epr) |
| +------------------>|
| (amount, epr) |
| ...
| do work
| ...
|<--------------------------------------+
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.
b)
REQ is responsible to assign from "myrole" on the partner
link facing
the router into the a message it eventually sends it.
b) is definitely a correct approach:
1. REQ assigns from "callback partner link" (myRole) to a variable
2. REQ passes the EPR to R
3. R forwards the EPR to B
4. B assigns the EPR to "callback partner link" (partnerRole)
5. B invokes callback provided by REQ
6. REQ receives the response
The variables for the partner link assignments are typed with
sref:service-ref. The contents are opaque for R and B, that is,
whatever the EPR looks like, REQ is both producer and consumer
of this EPR.
Based on my reading of the 8/23 draft, both implementations are
supported.
The questions for which I have no clear answer are:
1)
Is implementation option A supported ?
As outlined above, only with additional assumptions.
Assuming it is, the spec in silent on IMA activities affecting
the
partner link for the purpose of assign activities, and the
lifetime of
the partner link value.
The spec is silent because there are no assumptions, e.g. about the
use
of WS-Addressing.
My expectation would be that once an IMA activity has
completed,
assigning from the partner link would yield the reply-to EPR.
See above.
Would this also require the partner link variants of the Assign
activity
to include a messageExchange attribute.
No.
The messageExchange is only used to clarify the relationship between
receive and reply activities within one process. It never appears in
an assign activity.
2)
Assuming the above is valid, what would the schema type of the
variable(
or message part) into which the EPR is assigned be?
serf:service-reference - in the case of message part, this
would cause
BPEL specific types to be "leaked" into the abstract WSDL.
wsa:endpoint-reference - this would bind the BPEL process to a
specific
addressing scheme.
Yes. Again, note that the contents of sref:service-ref are opaque to
processes R and B.
In either case, it would be useful for the spec to be specific
about
this point (and an example would be great).
The TC will consider this suggestion.
3)
Section 6.3 ("Endpoint References")states:
The <sref:service-ref> element is not always exposed to WS-BPEL
process
definitions. For example, it is not exposed in an assignment
from the
endpoint reference of myRole of partnerLink-A to that of
partnerRole of
partnerLink-B. On the contrary, it is exposed in an
wsbpel-specification-assignment from a messageType or element
based
variable through expression or from a literal
<sref:service-ref>.
The explicit declaration of a variable of type sref:service-ref is
only
needed when assignments between partner links and that variable are
done.
Section 8.4.3 states that the following is not a valid
assignment:
the selection result of the from-spec is a variable of a WSDL
message
type and that of the to-spec is not, or vice versa (parts of
variables,
selections of variable parts, or endpoint references cannot be
assigned
to/from variables of WSDL message types directly).
This statement has nothing to do with everything discussed above. It
only
means that assignments between WSDL-message-variables and
XML-schema-type-variables/XML-schema-element-variables are not
permitted (they are not meaningful anyway). The same is true for
assignments between WSDL-message-variables and partner links.
It is not clear if these to sections are contradicting.
If assignments to/from partner links is allowed (which is
explicitly
stated in section 8.4), what are the valid combinations?
They are not contradicting. The important piece is the the element
assigned to/from a partner link is of type sref:service-ref.
Thanks in advance for your considerations and clarifications.
HTH. Again, thanks for your comments.
Kind Regards
DK
This publicly archived list offers a means to provide input to
the
OASIS Web Services Business Process Execution Language (WSBPEL)
TC.
In order to verify user consent to the Feedback License terms
and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: wsbpel-comment-subscribe@lists.oasis-open.org
Unsubscribe: wsbpel-comment-unsubscribe@lists.oasis-open.org
List help: wsbpel-comment-help@lists.oasis-open.org
List archive:
http://lists.oasis-open.org/archives/wsbpel-comment/
Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]