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