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