Hello,
what
about the reply activity?
Currently it requires the designer to fill in the right
partner/porttype/operation
Another idea I had (with a somewhat different semantic) is to link the
reply to the associated receive on desing time, by use of elemnt
IDs.
<receive id="1" ... />
....
<reply href="1" />
I am
not sure, if it is intentional to have multiple receives with the same port, and
reply will answer to the one which was used, or is it more intentional, to
specifically reply to a given receive, and make sure the control flow handles
this.
Anyway, if we touch the receive signature, we might want to modify reply
accordingly.
Greetings
Bernd
-----Original Message-----
From: Satish Thatte
[mailto:]
Sent: Tuesday, August 12, 2003 12:44
AM
To: Marin, Mike;
Subject:
RE: [wsbpel] Issue - 44 - portType is duplicated on Invoke activity and
partnerLinkType
Thanks. Unless
someone has a good argument for retaining portType in invoke I would propose
that we just remove it.
From: Marin,
Mike [mailto:]
Sent: Monday, August 11, 2003 1:23 PM
To: Satish Thatte;
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:]
Sent: Monday, August 11, 2003 1:01 PM
To:
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:]
Sent: Thursday, August 07, 2003 3:41 AM
To:
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 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: For additional
commands, e-mail:
