[ 
https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063268#comment-13063268
 ] 

Simon Laws commented on TUSCANY-3894:
-------------------------------------

Object identity
===========

So, IIUC, you're saying the the following is true for the SCA binding 
delegations

    local               p1==p2
    remote(ws)    p1!=p2
    remote(rmi)   p1==p2

Is that correct? If so I think what you say is correct in that there is a 
binding/technology specific aspect to be taken into account. I.e. we're not in 
the business of making web services behave like RMI. We take them as they come. 

Databinding
=========

Still not sure I get this. In the local case I think there will only be on 
databinding transformation, if any is required, as the local wire optimizes the 
service side databinding interceptor away. I might just try a test where the 
reference has a Java interface and the service implementation has a WSDL 
interface., e.g. BPEL. Thinking about this we need to test that there isn't a 
hole if you specify a service interface, as opposed to a component type service 
interface, with the intention of restricting the number of operations exposed.  

> Binding.sca local behavior:  copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
>                 Key: TUSCANY-3894
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3894
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: SCA Java Runtime
>    Affects Versions: Java-SCA-2.x
>            Reporter: Scott Kurz
>            Assignee: Scott Kurz
>            Priority: Minor
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides 
> share a common databinding, which might not be a desirable limitation.  
> Also the object reference graph of copy vs. mediate seems to be different, 
> which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to 
> open this up to move the discussion out of the 3884 JIRA, to avoid confusion 
> as this is a separate issue from simply adding the ability to delegate.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to