[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]