RE: [wsbpel] Issue - 52 - Proposal For Vote

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

Yaron, 

The self-binding doesn't have to be done in code.  If it is part of the
model that can be reflected in a static deployment plan.  Then you can
avoid Kerberos et al with an optimized binding in your platform
implementation.  No need to burden the language with something that can
be easily done outside it.

Satish 


 

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Friday, September 17, 2004 3:01 PM
To: Dieter Koenig1
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 52 - Proposal For Vote

The problem with this approach is that the copied EPR contains very
specific information about how communication is supposed to occur. For
example it could say things like "Send the message via SOAP over UDP
using WS-Security with a Kerberos Key and make sure to route it through
our high security firewall."

If a process was interested in testing its communication path then
copying the EPR and having the message be transmitted following the
EPR's instructions makes sense. But if a process really just wanted to
deliver a message to itself requiring that message to go through all the
hoops outlined in the EPR isn't appropriate.

This kind of misunderstanding is typical when one tries to implement a
feature as a side effect rather than declaratively. That is, the goal of
the code you give below is to allow a process to talk to itself but
rather than just stating that outright (which is what partnerIsSelf
does) the effect is achieved through a side effect of copying the EPR. 
But that then introduces the complexities I describe above.

I also don't believe that IPC is anymore deadlock prone than business
process web services are. If we don't like IPC maybe we should also get
rid of Web Services? :)

		Yaron

Dieter Koenig1 wrote:
> 
> 
> 
> 
> If one *really* chooses to model a process like this, it can be done
> already:
>    assign-copy from partnerLink "myself-inbound" (myRole) to 
> "myself-outbound" (partnerRole)
>    invoke (use partnerLink "myself-outbound" and a correlation set to 
> get the same instance)
>    receive (use partnerLink "myself-inbound" and a correlation set to 
> get the same instance)
> 
> In addition, imo, we should not introduce a dedicated construct which 
> encourages intra-process-instance communication patterns that are 
> asking for deadlocks.
> 
> Kind Regards
> DK
> 
> 
> 
>

>              "Yaron Y. Goland"

>              <ygoland@bea.com>

>
To
>              16.09.2004 03:05          wsbpeltc

>                                        <wsbpel@lists.oasis-open.org>

>
cc
>              Please respond to

>                   ygoland
Subject
>                                        [wsbpel] Issue - 52 - Proposal
For 
>                                        Vote

>

>

>

>

>

>

> 
> 
> 
> 
> In section 6.2, 7.2
> Change the partnerLink schema to:
> 
> <partnerLinks>
>        <partnerLink name="ncname" partnerLinkType="qname"
>             myRole="ncname"? partnerRole="ncname"?
>             partnerIsSelf="Boolean"?>+
>        </partnerLink>
> </partnerLinks>
> 
> Add the following text to the end of section 7.2:
> 
> If the partnerIsSelf attribute is set to true then it indicates that 
> the partnerRole points to the BPEL process instance in which the 
> partnerLink is being used. The default value of the partnerIsSelf 
> attribute is false. partnerIsSelf is used to support internal 
> communication so that a BPEL process instance can send messages to 
> itself. By specifying partnerIsSelf="true" the BPEL engine knows that 
> it is to provide a binding for the partnerRole that points at the BPEL
process instance.
> 
> Add the following to the schema definition of tPartnerLink:
> <attribute name="partnerIsSelf" type="bpws:tBoolean" use="optional"
> default="no"/>
> 
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_work
> group.php
> 
> .
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
> 
> 

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.