[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?
This is effectively what I have been suggesting. -----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]