[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] RE: Issue - 52 - Should BPEL provide a standard way to specify when flows are sending messages to each other?
Yaron, Could you please clarify what you mean by interflow? - do you mean an instance of a BPEL process calling itself? - do you mean 2 instances of a BPEL process calling each other? - do you mean 2 instances of a flow activity exchanging signals? Thank you, Edwin > -----Original Message----- > From: Yaron Goland [mailto:ygoland@bea.com] > Sent: Wednesday, August 20, 2003 11:38 AM > To: 'Maciej Szefler'; 'Satish Thatte'; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] RE: Issue - 52 - Should BPEL provide a > standard way to specify when flows are sending messages to each other? > > Executive Summary: Add my +1 to Tony Andrews and Danny's comment. > > Long Winded Version: > > There are two problems with specifying that interflow > messaging is occurring at the WSDL Binding Level: > > Clarity - BPEL is intentionally designed to bind to WSDL > portTypes rather than ports in order to allow the BPEL > program to remain independent of any particular binding. This > means that if a program uses interflow messaging and if > interflow messaging can only be described with a WSDL binding > then a BPEL that uses interflow messaging is not portable. > Think of it this way. Imagine you are writing a BPEL > template to express some common design pattern and the > pattern involves interflow messaging. You want to hand that > template out so people can base their code on it. If people > are to understand the template's design they clearly need to > know that interflow messaging is occurring. But currently > there is no way to express that interflow messaging is > happening in BPEL and templates don't have WSDL port bindings > (it rather defeats the point of being a template) so there is > no standard way to express that interflow messaging is > required to occur. > > WSDL Can't Do It - This all presumes that there is some > standard way to bind WSDL to the process. In so far as I am > aware there is no standard way in WSDL 1.1 to do this. The > problem is that each BPEL instance is created dynamically so > there is no way to know ahead of time what address to bind > the WSDL interface to in order to ensure that it will point > at the BPEL process. > > 'partnerIsSelf' solves both problems. It makes it clear, at > the BPEL layer, that interflow messaging is occurring. It > also provides a way for tools, at deploy time, to understand > that they need to bind a particular instance of a WSDL > interface to the process itself. > > Killing two birds with one stone that doesn't require any > changes to BPEL's existing semantics seems like a cheap price > to pay to solve this problem. > > Yaron > > > > -----Original Message----- > > From: Maciej Szefler [mailto:mbs@fivesight.com] > > Sent: Wednesday, August 20, 2003 7:54 AM > > To: ygoland@bea.com; Satish Thatte; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] RE: Issue - 52 - Should BPEL provide > a standard > > way to specify when flows are sending messages to each other? > > > > > > Why not just specify that partnerIsSelf at deploy time (i.e. > > through an IPC protocol binding)? > > > > -maciej > > > > > -----Original Message----- > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > Sent: Tuesday, August 19, 2003 5:21 PM > > > To: 'Satish Thatte'; wsbpel@lists.oasis-open.org > > > Subject: [wsbpel] RE: Issue - 52 - Should BPEL provide a standard > > > way to specify when flows are sending messages to each other? > > > > > > > > > Rather than discussing the scenario maybe we can skip to > the end. Do > > > you have any objections to adding the 'partnerIsSelf' > > > attribute to the partnerLink definition? > > > > > > Thanks, > > > > > > Yaron > > > > > > > -----Original Message----- > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > Sent: Tuesday, August 19, 2003 9:56 AM > > > > To: ygoland@bea.com; wsbpel@lists.oasis-open.org > > > > Subject: RE: Issue - 52 - Should BPEL provide a standard way to > > > > specify when flows are sending messages to each other? > > > > > > > > > > > > Yaron, > > > > > > > > I am left wondering why one would model the power management > > > > service as a set of flows in the same process. Is it about > > > > sharing > > > state? Based > > > > on the available detail I would find it much more > natural to use > > > > autonomous agents for individual facilities and have them > > > communicate > > > > normally using (external) messaging. > > > > > > > > In other words, I don't "get" the scenario. > > > > > > > > Satish > > > > > > > > -----Original Message----- > > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > > Sent: Monday, August 18, 2003 4:17 PM > > > > To: Satish Thatte; wsbpel@lists.oasis-open.org > > > > Subject: Issue - 52 - Should BPEL provide a standard way to > > > > specify when flows are sending messages to each other? > > > > > > > > Executive Summary: > > > > Just as interprocess communication (IPC) is > extremely common in > > > > asynchronous applications so one can reasonably expect it > > > to be common > > > > in BPEL process definitions. In the case of BPEL IPC will be > > > > referred to as interflow communication, that is, sending > > > > information > > > between flows > > > > in the same process. Two solutions are available in BPEL > > > for interflow > > > > communication - shared variables and interflow messaging. > > > > > > > > Shared variables are extremely difficult to get > right and require > > > > a lot of code. Therefore just as most IPC is done using > > > > interprocess messaging it is fair to assume that interflow > > > > communication will also often occur using interflow > messaging. The > > > > challenge in making interflow messaging code portable > and readable > > > > is to make it possible to express the fact that interflow > > > > messaging is happening at > > > the level of > > > > the BPEL process definition. > > > > > > > > Three solutions to this problem are explored > below of which only > > > > one is consistent with the BPEL partnerLink model in which the > > > > 'myRole' > > > > portType is used to receive messages and the 'partnerRole' > > > portType is > > > > used as the destination of messages. This solution is to add a > > > > 'partnerIsSelf' attribute to partnerLink definitions > > which specifies > > > > that both 'myRole' and 'partnerRole' will resolve to > the same BPEL > > > > process. > > > > > > > > Long Winded Version: > > > > > > > > Scenario: A local power company has three power generating > > > plants and > > > > two power transmission facilities. The power company has > > created the > > > > PowerManagement web service who communicates with all five > > > facilities. > > > > In addition the PowerManagement web service routinely sends > > > out status > > > > updates on how the whole system is operating. > > > > PowerManagement is designed as six BPEL flows. > One flow is > > > > dedicated to each of the facilities and is responsible for > > > > managing that facility. The six flow is used exclusively for > > > > creating > > > status update > > > > messages. The other five flows will send the sixth flow > an update > > > > message when something interesting happens. Every hour > or so (or > > > > sooner if something really interesting happens) the six > flow will > > > > paste together the updates it has received from the other five > > > > flows and send out a single update message to > interested parties. > > > > > > > > Technical Issues: The key challenge in this scenario is > deciding > > > > how to communicate information between the first five flows and > > > > the sixth flow. > > > > In BPEL there are two obvious choices, either use shared > > > variables or > > > > interflow communication. > > > > > > > > Using shared variables is a non-trivial challenge for > > > > programmers. There are many subtle cases in which shared > > > variables can > > > > get a programmer into trouble. For example, let us say > that flow 1 > > > > wants to send flow 6 a status update. So flow 1 writes > the status > > > > update into the StateUpdate variable. What happens if > at the same > > > > time flow 2 decides to also send a status update and writes it > > > > into the same variable? In that case flow 1's update > will be lost. > > > > > > > > Our intrepid programmer eventually figures the > problem out and > > > > creates one variable for each flow. So lets say that flow 1 > > > records a > > > > status update in the StateUpdateFlowOne variable. > However, before > > > > flow 6 has a chance to grab the state update from that variable > > > > flow > > > > 1 needs to > > > > send another state update and so overwrites the first > > > status update. > > > > > > > > That can be fixed by having flow 1 append its > state updates and > > > > having flow 6 remove state updates it uses them but > that solution > > > > introduces at least two problems. First, there is no way > > in BPEL to > > > > append and delete part of a variable. Second, there are > > various race > > > > conditions that are possible with XPATH evaluation if > > both flows are > > > > simultaneously accessing the variable. > > > > > > > > Compare shared variables to message passing. In > a message passing > > > > system flow 1 can just 'fire and forget' its > > state update by > > > > using a one-way invoke to flow 6. Flow 6 doesn't have to do any > > > > kind of state management (e.g. deleting data in state > variables) > > > > since the message stack handles that automatically by removing > > > > messages after they have been processed. Also, depending on the > > > > resolution to Issue 49 flow > > > > 6 also won't have to worry about losing messages. > > > > > > > > It shouldn't be surprising that interflow > messaging is the > > > > easiest way to solve interflow communication. All mature > > > asynchronous > > > > platforms inevitably end up providing message based > interprocess > > > > communication (IPC), the equivalent of BPEL interflow > > > > communication, as it is the easiest paradigm with which > to solve > > > > the > > > IPC/interflow data > > > > exchange problem. > > > > > > > > The main challenge in interflow communication > in BPEL is how to > > > > express in a standard way that a process wants to send a > > message to > > > > itself. The key problem in BPEL today is that there is no > > way at the > > > > BPEL layer to tell that a 'partner' in a partnerLink is > > actually the > > > > same process. > > > > > > > > The lack of such a mechanism means that it is > impossible to > > > > specify in a standard, portable way that a process is > > > communicating to > > > > itself. > > > > > > > > There are at least three ways to fix this problem. > > > > > > > > Single Role partnerLinkTypes - One can create a > single role > > > > partnerLinkType and then create a partnerLink that > points at that > > > > partnerLinkType and specifies the role in 'myRole'. One > can then > > > > specify that partnerLink in an Invoke. E.g. (taken from > a modified > > > version of > > > > Satish's example): > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > <role name="Receiver"> > > > > <portType name="foo:BillProcessingPortType"/> > > > > </role> > > > > </partnerLinkType> > > > > > > > > <partnerLinks> > > > > <partnerLink name="MyBillLink" > > > partnerLinkType="foo:BillProcessing" > > > > myRole="Receiver"/> > > > > </partnerLinks> > > > > > > > > <!--- Flow A ---> > > > > > > > > <invoke partnerLink="MyBillLink" operation="billsending" > > > > inputVariable="TheSentBill"/> > > > > > > > > <!--- Flow B ---> > > > > > > > > <receive partnerLink="MyBillLink" operation="billsending" > > > > variable="TheReceivedBill"/> > > > > > > > > The plus side is that one can now explicitly > specify that a > > > > message is intended for interflow messaging. The downside > > > is that this > > > > design is likely to cause confusion. In BPEL 'myRole' > is used for > > > > receives and 'partnerRole' is used for invokes. But in this > > > > example this behavior is reversed in the case of the > invoke. Worse > > > > yet > > > one can only > > > > figure out that the reversal has happened by carefully > > examining the > > > > code. > > > > > > > > Role Attribute on Invokes - One could make the > reversal more > > > > explicit by putting a role attribute on the Invoke which would > > > > explicitly specify which role the message is being sent > to. E.g.: > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > <role name="Receiver"> > > > > <portType name="foo:BillProcessingPortType"/> > > > > </role> > > > > </partnerLinkType> > > > > > > > > <partnerLinks> > > > > <partnerLink name="MyBillLink" > > > partnerLinkType="foo:BillProcessing" > > > > myRole="Receiver"/> > > > > </partnerLinks> > > > > > > > > <!--- Flow A with a new role attribute ---> > > > > > > > > <invoke partnerLink="MyBillLink" role="Receiver" > > > > operation="billsending" > > > > inputVariable="TheSentBill"/> > > > > > > > > <!--- Flow B ---> > > > > > > > > <receive partnerLink="MyBillLink" operation="billsending" > > > > variable="TheReceivedBill"/> > > > > > > > > The upside of this design is that it makes it > explicit when > > > > interflow communication is occurring. The downside is that > > > it is still > > > > likely to cause some confusion as one now has to pay > > > careful attention > > > > to the role attribute to see if the normal scheme of > > things is being > > > > reversed. This just seems to beg for problems. > > > > > > > > Put a 'partnerIsSelf' attribute on partnerLink > definitions - A > > > > third possibility is to explicitly state on the partnerLink > > > definition > > > > that the 'partner' is in fact the same BPEL process. E.g.: > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > <role name="Receiver"> > > > > <portType name="foo:BillProcessingPortType"/> > > > > </role> > > > > <role name="Sender"> > > > > <portType name="foo:BillProcessingPortType"/> > > > > </role> > > > > </partnerLinkType> > > > > > > > > <partnerLinks> > > > > <partnerLink name="BillLink" > > partnerLinkType="foo:BillProcessing" > > > > myRole="Receiver" partnerIsSelf="true"/> > > > > </partnerLinks> > > > > > > > > <invoke partnerLink="BillLink" operation="billsending" > > > > inputVariable="TheSentBill"/> > > > > > > > > .. > > > > > > > > <!-- somewhere else --> > > > > > > > > <receive partnerLink="BillLink" operation="billsending" > > > > variable="TheReceivedBill"/> > > > > > > > > In this case everything works consistently with > the BPEL model. > > > > 'myRole' is used to receive messages and 'partnerRole' is > > > used to send > > > > messages. So the upside is that the fact that interflow > > > > communication is going on is explicitly specified and the BPEL > > > > partnerLink model operates as expected. The downside is > that one > > > > has to create > > partnerLinkTypes > > > > with two roles with the same portType. But that actually seems > > > > appropriate as that is what's going on, the BPEL is talking > > > to itself. > > > > > > > > Therefore I would propose that we adopt the > 'partnerIsSelf' > > > > attribute as a way to explicitly state at the BPEL level that > > > > interflow communication is occurring without causing > any violence > > to the BPEL > > > > processing model. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > Sent: Wednesday, August 13, 2003 10:31 PM > > > > > To: ygoland@bea.com; wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > on Invoke > > > > > activity and partnerLinkType > > > > > > > > > > > > > > > My proposal was the following for all circularity cases > > > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > > <role name="Receiver"> > > > > > <portType name="foo:BillProcessingPortType/> > > > > > </role> > > > > > </partnerLinkType> > > > > > > > > > > <partnerLinks> > > > > > <partnerLink name="MyBillLink" > > > > partnerLinkType="foo:BillProcessing" > > > > > myRole="Receiver"/> > > > > > <partnerLink name="PartnerBillLink" > > > > > partnerLinkType="foo:BillProcessing" > > > > > partnerRole="Receiver"/> </partnerLinks> > > > > > > > > > > <invoke partnerLink="PartnerBillLink" operation="billsending" > > > > > inputVariable="TheSentBill"/> > > > > > > > > > > .. > > > > > > > > > > <!-- somewhere else --> > > > > > > > > > > <receive partnerLink="MyBillLink" operation="billsending" > > > > > variable="TheReceivedBill"/> > > > > > > > > > > IOW role is not an attribute in <invoke>. Sending an > > > > external message > > > > > looks like sending an external message. If it circles > > back to the > > > > > process (instantiation case) or instance (internal signaling > > > > > case) that > > > > > is an artifact of external binding/deployment. > > > > > > > > > > I simply don't see the need to create confusion for a > > corner case. > > > > > > > > > > Satish > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > > > Sent: Tuesday, August 12, 2003 1:08 PM > > > > > To: Satish Thatte; wsbpel@lists.oasis-open.org > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > on Invoke > > > > > activity and partnerLinkType > > > > > > > > > > Satish, > > > > > > > > > > The problem with the second example is that because > BPEL doesn't > > > > > require that every new instance of a process have a > unique URI > > > > > so it may not be possible to express at the BPEL > level the full > > > > > 'name' for > > > a process > > > > > instance. This is why, in those cases, one is forced > to play the > > > > > games I specified. > > > > > > > > > > Is the following an accurate portrayal of your proposed > > > solution for > > > > > case #2? > > > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > > <role name="Receiver"> > > > > > <portType name="foo:BillProcessingPortType/> > > > > > </role> > > > > > </partnerLinkType> > > > > > > > > > > <partnerLinks> > > > > > <partnerLink name="ProcessBill" > > > > > partnerLinkType="foo:BillProcessing" > > > > > myRole="Receiver"/> > > > > > </partnerLinks> > > > > > > > > > > <invoke partnerLink="ProcessBill" role="Receiver" > > > > > operation="billsending" inputVariable="TheBill"/> > > > > > > > > > > Before I discuss this proposal I want to make sure I > > > understand you > > > > > correctly. > > > > > > > > > > BTW, do you actually object to the idea of allowing for the > > > > use of the > > > > > role attribute on invoke? > > > > > > > > > > Yaron > > > > > > > > > > > -----Original Message----- > > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > > Sent: Monday, August 11, 2003 11:09 PM > > > > > > To: ygoland@bea.com; wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > > on Invoke > > > > > > activity and partnerLinkType > > > > > > > > > > > > > > > > > > I don't get the third (invisible intermediary) > scenario. The > > > > > > sample you have below works for the first but not the second > > > > > (createInstance) one > > > > > > unless you interpret the role="Receiver" in an instance > > > > > agnostic way, > > > > > > which I think would be extraordinarily confusing. How do > > > > > you prevent > > > > > > the intra-instance "cross flow" communications from > > > > leaking to other > > > > > > instances? > > > > > > > > > > > > Why not just create two partnerLinks with the same > portType (I > > > > > > don't see the use of the two distinct protTypes in your > > > > > > example) > > > -- one for > > > > > > sending/invoking (with only partnerRole) and the other > > > > for receiving > > > > > > (with only myRole), and let deployment/binding create the > > > > circuit as > > > > > > appropriate? > > > > > > > > > > > > Satish > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > > > > Sent: Monday, August 11, 2003 5:20 PM > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > > on Invoke > > > > > > activity and partnerLinkType > > > > > > > > > > > > There are at least three real world scenarios I can > think of > > > > > > [1] where a process would want to call itself. If I > understand > > the proposal > > > > > > correctly then this is how a process would go about > > > > calling itself: > > > > > > > > > > > > <partnerLinkType name="BillProcessing"> > > > > > > <role name="Receiver"> > > > > > > <portType name="foo:BillProcessingPortType/> > > > > > > </role> > > > > > > <role name="Sender"> > > > > > > <portType name="foo:BillConfirmationPortType/> > > > > > > </role> > > > > > > </partnerLinkType> > > > > > > > > > > > > <partnerLinks> > > > > > > <partnerLink name="ProcessBill" > > > > > > partnerLinkType="foo:BillProcessing" > > > > > > myRole="Receiver"/> > > > > > > </partnerLinks> > > > > > > > > > > > > <invoke partnerLink="ProcessBill" role="Receiver" > > > > > > operation="billsending" inputVariable="TheBill"/> > > > > > > > > > > > > So assuming the partnerLink ProcessBill hasn't been used > > > > > > before so that the partner endpoint reference hasn't been > > > > > > previously instantiated then in the example both > partners in > > > > > > the ProcessBill partnerLink > > > > > would have > > > > > > the same endpoint reference which would be the endpoint > > > reference > > > > > > belonging to the process itself. > > > > > > > > > > > > Is that right? > > > > > > > > > > > > Yaron > > > > > > > > > > > > [1] Here are the three main scenarios I know of for why a > > > > > > process would call itself: > > > > > > > > > > > > Inter-Flow Communication - If two flows in the same > > > > process want to > > > > > > share information they either have to use shared > variables or > > > > > > they have to send messages to each other. Shared > variables are > > > > > > a > > > > > nasty business > > > > > > which give even experienced programmers a headache. > > Just sending > > > > > > yourself messages is usually easier. > > > > > > > > > > > > Kicking off New Process Instances - Depending on the URI > > > > > model a BPEL > > > > > > process is using (something left unspecified by BPEL) the > > > > > only way to > > > > > > create a new process instance of the same type as > > > > yourself may be to > > > > > > call a 'createInstance' enabled receive activity on > yourself. > > > > > > An example > > > > > > of this situation is a system where all instances > of a process > > > > > > have the same URL but different HTTP cookies. > > > > > > > > > > > > Benefiting from Bad Intermediary Design - This is a pet > > > > > peeve of mine > > > > > > but unfortunately people constantly have the brilliant > > > > 'new' idea of > > > > > > providing 'invisible' services via intermediaries. Router > > > > based HTTP > > > > > > proxies, firewalls and nats are all examples. In these > > > > cases network > > > > > > based entities provide services as a consequence of > > > > routing messages > > > > > > rather than being directly addressed. For example, one > > > > > could imagine a > > > > > > logging intermediary that automatically logs, possibly with > > > > > > some sort of cryptographically secure timestamp, when it > > > > > > routed a particular message. > > > > > > If a web service wants some information logged it couldn't > > > > > > just send the logger a message since the logger is > supposed to > > > > > > be 'invisible'. Instead the web service would have > to actually > > > > > > send out a > > > message into the > > > > > > network that it knew would eventually be routed through > > > > the logger. > > > > > > However such a message would need a destination (you > > > can't route a > > > > > > message that isn't going anywhere) which in this case would > > > > > be the Web > > > > > > Service itself. Of course you better pray that your > > > > > application server > > > > > > doesn't do you a 'favor' by short circuiting the web stack > > > > > and sending > > > > > > you your own message locally. > > > > > > > > > > > > (Web Service)---->("Invisible" Logger Intermediary)--| > > > > > > /-\ | > > > > > > | | > > > > > > ------------------------------------------------ > > > > > > > > > > > > -----Original Message----- > > > > > > From: Marin, Mike [mailto:MMarin@filenet.com] > > > > > > Sent: Monday, August 11, 2003 1:23 PM > > > > > > To: Satish Thatte; wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > > on Invoke > > > > > > activity and partnerLinkType > > > > > > > > > > > > > > > > > > Satish, > > > > > > > > > > > > I do agree that it is unlikely that a process will call > > > > > > itself, but the specification do allow it, because you do > > > > > > specify the port > > > > > type in the > > > > > > Invoke. So you could specify the one that refers to the > > > > > > process itself. > > > > > > In order to retain that functionality, I did proposed to > > > > > > optionally use the role instead. But, I will be happy to > > > > > > modify my > > > > proposal to just > > > > > > remove the port type form the Invoke. > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Mike Marin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > > Sent: Monday, August 11, 2003 1:01 PM > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > Subject: RE: [wsbpel] Issue - 44 - portType is duplicated > > > > on Invoke > > > > > > activity and partnerLinkType > > > > > > > > > > > > I agree with the analysis and the proposal except that I > > > > > don't see the > > > > > > need for the optional role specification. When would a > > > > > > process need to invoke itself? And in the rare > cases when it > > > > > > does, the > > > > > binding of the > > > > > > portLinks to create the cycle could be done externally > > > > > relative to the > > > > > > process definition, could it not? > > > > > > > > > > > > Satish > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: ws-bpel issues list editor > > > > > > [mailto:peter.furniss@choreology.com] > > > > > > Sent: Thursday, August 07, 2003 3:41 AM > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > Subject: [wsbpel] Issue - 44 - portType is duplicated on > > > > > > Invoke activity and partnerLinkType > > > > > > > > > > > > This issue has been added to the wsbpel issue list. The > > > > > issues list is > > > > > > posted as a Technical Committee document to the > OASIS WSBPEL > > > > > > TC pages on a regular basis. The current edition, as a TC > > > > > > document, > > > > is the most > > > > > > recent document with the title in the "Issues" folder of > > > > > the WSBPEL TC > > > > > > document list - the next posting will include this > > > issue. The list > > > > > > editor's working copy, which will normally include an issue > > > > > when it is > > > > > > announced, is available at this constant URL. > > > > > > Issue - 44 - portType is duplicated on Invoke activity and > > > > > > partnerLinkType > > > > > > Status: open > > > > > > Date added: 5 Aug 2003 > > > > > > Submitter: Marin, Mike > > > > > > Date submitted: 01 August 2003 > > > > > > Description: The Invoke activity requires a > partnerLink and a > > > > > > portType. > > > > > > However the partnerLink refers to a partnerLinkType, which > > > > > > also includes the portType. Therefore the portType in the > > > > > > Invoke is > > > redundant. > > > > > > A partnerLinkType do refer to a maximum of two portTypes. > > > > > > Assuming that > > > > > > a process does not invokes itself, then the Invoke > > refers to the > > > > > > partnerRole, not myRole, so there is only one possible > > > > portType, for > > > > > > that Invoke. In the other hand, if we assume the process > > > > can invoke > > > > > > itself, then it will be better to specify the role in > > the Invoke > > > > > > activity instead of the portType, because role has > > > > process semantics > > > > > > instead of the portType. > > > > > > Submitter's Proposal: I propose that portType on the Invoke > > > > > > activity be removed and instead an optional role be > included > > > > > > instead. > > > > > > When the role > > > > > > is specified, it must correspond to one of the two roles > > > > > > defined in the partnerLink. If the role is not specified the > > partnerRole in the > > > > > > partnerLink should be assumed. > > > > > > Changes: 5 Aug 2003 - new issue > > > > > > > > > > > > > > > > > > > > > > > > To comment on this issue, please follow-up to this > > > > > announcement on the > > > > > > wsbpel@lists.oasis-open.org list (replying to this > > > message should > > > > > > automatically send your message to that list), or ensure > > > > the subject > > > > > > line as you send it starts "Issue - 44 - [anything]" or is > > > > > a reply to > > > > > > such a message. > > > > > > To add a new issue, see the issues procedures document. > > > > > > > -------------------------------------------------------------- > > > > > > ------- To > > > > > > unsubscribe, e-mail: > > wsbpel-unsubscribe@lists.oasis-open.org For > > > > > > additional commands, e-mail: > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]