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

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 name="Sender">
      <portType name="foo:BillConfirmationPortType/>

   <partnerLink name="ProcessBill" partnerLinkType="foo:BillProcessing"

<invoke partnerLink="ProcessBill" role="Receiver" operation="billsending"

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?


[1] Here are the three main scenarios I know of for why a process would call

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

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

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