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