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