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?


+1 

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com] 
> Sent: Wednesday, August 20, 2003 8:57 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?
> 
> seems to be less clear to me than to have actual language support.
> 
> ----- Original Message -----
> From: "Satish Thatte" <satisht@microsoft.com>
> To: "Maciej Szefler" <mbs@fivesight.com>; <ygoland@bea.com>; 
> <wsbpel@lists.oasis-open.org>
> Sent: Wednesday, August 20, 2003 8:32 AM
> Subject: RE: [wsbpel] RE: Issue - 52 - Should BPEL provide a 
> standard way to specify when flows are sending messages to each other?
> 
> 
> This is effectively what I have been suggesting.
> 
> -----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
> 
> 


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