OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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 tospecify when flows are sending messages to each other?


seems to be less clear to me than to have actual language support.

----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Maciej Szefler" <mbs@fivesight.com>; <ygoland@bea.com>;
<wsbpel@lists.oasis-open.org>
Sent: Wednesday, August 20, 2003 8:32 AM
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
> > > >
> > > >
> > >
> > >
> >
> >
>


---------------------------------------------------------------------
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]