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




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