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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


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

> 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:

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