[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R13 - BPEL partner link assignments
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]