[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?
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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]