[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
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; [email protected]
> 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>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]