[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?
Previously we all agreed [1] that intraprocess messaging was already
possible in BPEL through a deployment time binding. Since intraprocess
messaging is already possible doesn't this mean that if there are deadlock
issues they already exist in BPEL independent of this proposal?
Yaron
[1] http://lists.oasis-open.org/archives/wsbpel/200308/msg00178.html
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Friday, August 22, 2003 5:22 PM
> To: Eckenfels. Bernd; 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?
>
>
> One of the concerns I have relative to intra-instance messaging as a
> BPEL process design feature is the potential for internal
> deadlock that
> is (for the first time) introduced. There may be more
> constrained ways
> to address the "data flow without data sharing" requirement
> that do not
> create this possibility.
>
> Satish
>
> -----Original Message-----
> From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
> Sent: Thursday, August 21, 2003 6:44 AM
> To: 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?
>
> this also might be confusing if you think of event handlers, where the
> same flow can have multiple instances :)
>
> But otherwise I also understand: invoking a receive in the
> same process
> instance.
>
> Greetings
> Bernd
>
>
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, August 20, 2003 10:53 PM
> To: ygoland@bea.com; edwink@collaxa.com; Maciej Szefler;
> 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?
>
>
> When I read your first message I had the same need of clarification as
> Edwin did. If what you meant is "2 instances of a flow activity within
> the same bpel process instance", I would spell it out exactly
> that way.
>
> Ugo
>
> > -----Original Message-----
> > From: Yaron Goland [mailto:ygoland@bea.com]
> > Sent: Wednesday, August 20, 2003 1:48 PM
> > To: edwink@collaxa.com; 'Maciej Szefler'; '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?
> >
> >
> > I think that when you say "2 instances of a flow activity
> > within the same
> > bpel process instance" you mean the same thing as I mean when I say
> > interflow messaging but I have to admit that I'm not sure where your
> > confusion is coming from so I can't be sure that we are
> > actually saying the
> > same thing. Please read
> > http://lists.oasis-open.org/archives/wsbpel/200308/msg00158.ht
> > ml, it has the
> > details.
> >
> > Yaron
> >
> >
> >
> > > -----Original Message-----
> > > From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> > > Sent: Wednesday, August 20, 2003 1:32 PM
> > > To: ygoland@bea.com; 'Maciej Szefler'; '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?
> > >
> > >
> > > Excuse me for being slow but I am not sure what you mean by
> > > the term flow in
> > > 'sending information between flows in the same process'. Is
> > > flows referring
> > > to 2 instances of a flow activity within the same bpel
> > > process instance or 2
> > > instances of a flow activity within 2 different business
> > > processes or are
> > > you using flows as a shortcut for process instances?
> > > Thank you.
> > > Edwin
> > >
> > > > -----Original Message-----
> > > > From: Yaron Goland [mailto:ygoland@bea.com]
> > > > Sent: Wednesday, August 20, 2003 1:12 PM
> > > > To: edwink@collaxa.com; 'Maciej Szefler'; '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?
> > > >
> > > > I think my executive summary from my Monday, August 18, 2003
> > > > 4:17 PM (just scroll down far enough =) explains it best:
> > > > 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.
> > > >
> > > > Does that answer the question?
> > > >
> > > > Thanks,
> > > > Yaron
> > > >
> > > > > -----Original Message-----
> > > > > From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> > > > > Sent: Wednesday, August 20, 2003 1:03 PM
> > > > > To: ygoland@bea.com; 'Maciej Szefler'; '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?
> > > > >
> > > > >
> > > > > Yaron,
> > > > >
> > > > > Could you please clarify what you mean by interflow?
> > > > > - do you mean an instance of a BPEL process calling itself?
> > > > > - do you mean 2 instances of a BPEL process calling
> each other?
> > > > > - do you mean 2 instances of a flow activity
> exchanging signals?
> > > > >
> > > > > Thank you,
> > > > >
> > > > > Edwin
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Yaron Goland [mailto:ygoland@bea.com]
> > > > > > Sent: Wednesday, August 20, 2003 11:38 AM
> > > > > > To: 'Maciej Szefler'; '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?
> > > > > >
> > > > > > Executive Summary: Add my +1 to Tony Andrews and
> > > Danny's comment.
> > > > > >
> > > > > > Long Winded Version:
> > > > > >
> > > > > > There are two problems with specifying that interflow
> > > > messaging is
> > > > > > occurring at the WSDL Binding Level:
> > > > > >
> > > > > > Clarity - BPEL is intentionally designed to bind to WSDL
> > > > portTypes
> > > > > > rather than ports in order to allow the BPEL
> program to remain
> > > > > > independent of any particular binding. This means that if
> > > > a program
> > > > > > uses interflow messaging and if interflow messaging
> > can only be
> > > > > > described with a WSDL binding then a BPEL that uses
> interflow
> > > > > > messaging is not portable.
> > > > > > Think of it this way. Imagine you are writing a BPEL
> > > > template to
> > > > > > express some common design pattern and the pattern involves
> > > > > > interflow messaging. You want to hand that template out
> > > so people
> > > > > > can base their code on it. If people are to understand the
> > > > > > template's design they clearly need to know that
> > > > interflow messaging
> > > > > > is occurring. But currently there is no way to express that
> > > > > > interflow messaging is happening in BPEL and templates
> > > don't have
> > > > > > WSDL port bindings (it rather defeats the point of being
> > > > a template)
> > > > > > so there is no standard way to express that interflow
> > > > messaging is
> > > > > > required to occur.
> > > > > >
> > > > > > WSDL Can't Do It - This all presumes that there is some
> > > > standard way
> > > > > > to bind WSDL to the process. In so far as I am aware
> > > there is no
> > > > > > standard way in WSDL 1.1 to do this. The problem is that
> > > > each BPEL
> > > > > > instance is created dynamically so there is no way to
> > > > know ahead of
> > > > > > time what address to bind the WSDL interface to in order
> > > > to ensure
> > > > > > that it will point at the BPEL process.
> > > > > >
> > > > > > 'partnerIsSelf' solves both problems. It makes it clear,
> > > > at the BPEL
> > > > > > layer, that interflow messaging is occurring. It also
> > > > provides a way
> > > > > > for tools, at deploy time, to understand that they need
> > > to bind a
> > > > > > particular instance of a WSDL interface to the
> process itself.
> > > > > >
> > > > > > Killing two birds with one stone that doesn't require any
> > > > changes to
> > > > > > BPEL's existing semantics seems like a cheap price to pay
> > > > to solve
> > > > > > this problem.
> > > > > >
> > > > > > Yaron
> > > > > >
> > > > > >
> > > > > > > -----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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
>
> ---------------------------------------------------------------------
> 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]