[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 75 - Do we need locally declared partnerLinks?
+1 arkin Yaron Goland wrote: >If I understand the points made on this thread correctly then there are two >questions that have to be answered if we are to support locally scoped >partnerLinks. > #1 - How do you specify myRole for dynamically specified >partnerLinks? > #2 - How do you specify partnerRole for dynamically specified >partnerLinks? > >Dealing with #1 at deployment time is relatively straight forward. The BPEL >has no say as to what EPR is used in myRole. So a BPEL engine can choose >whatever deployment behavior it would like. It can require that one EPR be >used for every myRole in every partnerLink in the process (after all, >portType in an EPR is optional). It can dynamically generate EPRs. It can >statically generate EPRs for the same portType and re-use them for dynamic >myRoles, whatever. The BPEL process doesn't need to know since it has no say >in the choice. > >#2 however brings up an interesting question. Today, how does a BPEL process >know when the EPR for the partnerRole in a partnerLink will be statically >configured at deploy time and when the BPEL process itself is expected to >define the EPR for the partnerRole using <assign>? The answer is - it >doesn't. > >This seems like a bug to me. It seems to me that there should be an >attribute defined on a partnerLink definition whose meaning is 'I, the BPEL >process, expect the BPEL engine to define the EPR for the partnerRole for >this partnerLink for me.' This would make it clear to the BPEL programmer >what partnerRoles they are required to configure using <assign> and which >partnerRoles they can count on the BPEL engine to provide an EPR for. > >E.g. ><partnerLink deployDefined="yes"> > ... ></partnerLink> > >The previous point now leads me to issue #2. I would only allow the >deployDefined attribute on globally defined partnerLinks. The assumption >being that the EPR for a locally scoped partnerLink's partnerRole must be >defined by the BPEL process using an <assign>. > > Make Sense? > > Yaron > > > >>-----Original Message----- >>From: Satish Thatte [mailto:satisht@microsoft.com] >>Sent: Monday, November 17, 2003 8:57 AM >>To: Assaf Arkin >>Cc: Frank Leymann; wsbpel@lists.oasis-open.org >>Subject: RE: [wsbpel] Issue - 75 - Do we need locally declared >>partnerLinks? >> >> >>I would not want to make myRole dynamic - dynamic (visible) listen >>points will take us in the direction of auto generation. This is the >>complication - copies of partnerLinks that need to stay consistent for >>myRole and dynamic for partnerRole. >> >>-----Original Message----- >>From: Assaf Arkin [mailto:arkin@intalio.com] >>Sent: Monday, November 17, 2003 7:37 AM >>To: Satish Thatte >>Cc: Frank Leymann; wsbpel@lists.oasis-open.org >>Subject: Re: [wsbpel] Issue - 75 - Do we need locally declared >>partnerLinks? >> >>Satish Thatte wrote: >> >> >> >>>Assaf, if the issue was partnerLink visibility limited to a >>> >>> >>local scope >> >> >>>it would be trivial. But that is the only situation where >>> >>> >>you can have >> >> >>>'each locally scoped partner link is assigned a unique endpoint >>>reference'. All the examples I have seen justifying this idea also >>>require lifetime semantics, i.e., multiple copies of a locally scoped >>>partnerLink could exist, held, e.g., in corresponding compensation >>>handlers. Now the situation becomes much more complex as >>> >>> >>Frank pointed >> >> >>>out earlier. >>> >>> >>> >>> >>Then let's try and tackle it. >> >>The spec already has to deal with lifetime semantics of >>locally scoped >>variables and correlation sets. Let's assume that partner links are >>another type of scoped variable accessed (read/write) like any other >>locally or globally declared variable. That would cover the >>lifetime and >> >>access semantics. The spec also handles the case where >>multiple partner >>links are based on the same partner link type. We can extend >>that to the >> >>myRole EPR of a locally declared partner link (i.e. unique >>EPR in each >>scope). >> >>What other problems are we going to run into? >> >>arkin >> >> >> >>>Satish >>> >>> >>> >>> >> >> >> >> >>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/le >>ave_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. >> -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]