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:]
> Sent: Tuesday, August 19, 2003 9:56 AM
> To: ;
> 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:]
> Sent: Monday, August 18, 2003 4:17 PM
> To: Satish Thatte;
> 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:]
> > Sent: Wednesday, August 13, 2003 10:31 PM
> > To: ;
> > 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:]
> > Sent: Tuesday, August 12, 2003 1:08 PM
> > To: Satish Thatte;
> > 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:]
> > > Sent: Monday, August 11, 2003 11:09 PM
> > > To: ;
> > > 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:]
> > > Sent: Monday, August 11, 2003 5:20 PM
> > > To:
> > > 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:]
> > > Sent: Monday, August 11, 2003 1:23 PM
> > > To: Satish Thatte;
> > > 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:]
> > > Sent: Monday, August 11, 2003 1:01 PM
> > > To:
> > > 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:]
> > > Sent: Thursday, August 07, 2003 3:41 AM
> > > To:
> > > 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
> > > 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: For
> > > additional commands, e-mail:
> > >
> > >
> >
> >
>
>
