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

	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

	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"/>

   <partnerLink name="MyBillLink" partnerLinkType="foo:BillProcessing"

<!--- Flow A --->

<invoke partnerLink="MyBillLink" operation="billsending"

<!--- Flow B --->

<receive partnerLink="MyBillLink" operation="billsending"

	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"/>

   <partnerLink name="MyBillLink" partnerLinkType="foo:BillProcessing"

<!--- Flow A with a new role attribute --->

<invoke partnerLink="MyBillLink" role="Receiver" operation="billsending"

<!--- Flow B --->

<receive partnerLink="MyBillLink" operation="billsending"

	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 name="Sender">
      <portType name="foo:BillProcessingPortType"/>

   <partnerLink name="BillLink" partnerLinkType="foo:BillProcessing"
                myRole="Receiver" partnerIsSelf="true"/>   

<invoke partnerLink="BillLink" operation="billsending"


<!-- somewhere else -->

<receive partnerLink="BillLink" operation="billsending"

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

<<attachment: winmail.dat>>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]