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

["Satish Thatte" <satisht@microsoft.com>]

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