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?


if i may, replacing "interflow" with "intraprocess" might help clear things
up.

----- Original Message ----- 
From: "Yaron Goland" <ygoland@bea.com>
To: <edwink@collaxa.com>; "'Maciej Szefler'" <mbs@fivesight.com>; "'Satish
Thatte'" <satisht@microsoft.com>; <wsbpel@lists.oasis-open.org>
Sent: Wednesday, August 20, 2003 1:48 PM
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.html, 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
>
>




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