RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke activity and partnerLinkType

["Yaron Goland" <ygoland@bea.com>]

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