[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] usage of <partner> in BPEL?
Hi, all, +1 to Yaron and Eckenfels viewpoints in general ... More clarification questions to those who prefer keeping <partner>: (1)
Is <partner> just a logical grouping of <partnerLink> ?
If <partner> is just a pure logical grouping of <partnerLink>, then what entity in the computing world exactly can a partner be mapped to? A single EPR value? A single authenticated identity? It is just merely an intention documentation? Open to people's interpretation? (2)
"However, I think that it is a legitimate question whether partner adds sufficient value to BPEL, particularly since there is no single way we can point at for using that information. My own opinion would be to keep it because it allows embedding relevant business constraints into the process definition."Paco, could you elaborate a bit more about "embedding relevant business constraints"? These unanswered questions make me tend to prefer removing
<partner> from the spec. Thanks!
Alex Yiu Eckenfels. Bernd wrote: I agree, the value for partners is only within a collaborative design scenario, and that is not what BPEL is made for. Especially since I think Partner is the wrong name anyway, it would be better to name this "Role". If a tool wants to annotate stuff like relationships and roles, it can so do with extensions. In fact making BPEL a planning and degning and tool-exchange language could be good, but it is clearly out of scope for this TC. Mit freundlichen Grüßen Bernd Eckenfels Chief Architect -- SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 mailto:b.eckenfels@seeburger.de - http://www.seeburger.de -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Friday, July 02, 2004 7:53 PM To: Francisco Curbera Cc: Alex Yiu; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] usage of <partner> in BPEL? If a feature has at best speculative value then we should err on the side of cutting it. Therefore I think we should cut partners. Yaron Francisco Curbera wrote:Hi Alex, I don't see partners as a deployment detail, even though they (like everything else in a BPEL process) would need to be resolved at deployment time. If anything, partner belongs to a higher level of abstraction than partner links, since the intent was to capture business relationships between partner links which are not reflected on how port types (nor bindings) are factored. It certainly doesn't belong at the lower layer of WSDL bindings. However, I think that it is a legitimate question whether partner adds sufficient value to BPEL, particularly since there is no single way we can point at for using that information. My own opinion would be to keep it because it allows embedding relevant business constraints into the process definition. Paco Alex Yiu <alex.yiu@oracle. To: wsbpel@lists.oasis-open.org com> cc: Alex Yiu <alex.yiu@oracle.com> Subject: [wsbpel] usage of <partner> in BPEL? 06/28/2004 08:19 PM Hi all, We define <partnerLink> and <partner> in BPEL. The usage of <partnerLink> is very clear in BPEL. (e.g. invoke relies on partnerLink). However, the usage of <partner> is not clear. Is it more like a deployment related information? Should it be a part of WSDL binding? There are not other BPEL construct make uses of <partner> declaration. I have done a very informal poll to a number of vendors last week at BPEL F2F in SF. It seems to me that no particular vendor is actively making use of <partner> Any further thoughts? Thanks! Regards, Alex Yiu To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]