Update on the SCAClientFactoryImpl

[Raymond Feng <en...@gmail.com>]

Hi,

I made some changes under [1] to improve how SCA client works in Tuscany. 
Here is the basic idea:

1) The SCAClientFactoryImpl connects to an SCA domain. It looks up an 
EndpointRegistry for the domain and receives Endpoints published to the 
domain by nodes.
2) The getService() call will find a matching Endpoint by the serviceName 
(componentName/serviceName/bindingName)
3) An endpoint reference is created from the Endpoint (which has the binding 
and URI). It's similar as we have a component reference with @target.
4) A service proxy is created from the endpoint reference

[1] http://svn.apache.org/viewvc?rev=908285&view=rev

Thanks,
Raymond

---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action (A book on Tuscany SCA): 
http://tuscanyinaction.com/
www.enjoyjava.com
http://twitter.com/raymondfeng
 

Re: Update on the SCAClientFactoryImpl

[Raymond Feng <en...@gmail.com>]

Hi,

A few comments:

1) It's probably not only for <binding.sca>. I think it also applies to 
other bindings that use SCA addressing, such as:

<reference name="ref1" target="C1/S1">
    <binding.xyz/>
</reference>

<service name="svc1">
    <binding.xyz/>
</service>

2) Ideally, we should be able to map the <binding.sca> to any concrete 
bindings. If a binding can handle case 1) where only a structural URI is 
available, it should be a candidate for <binding.sca>.

3) I'm not sure if the mapping of binding.sca to binding.xyz should go to 
the SCDL. Maybe the Domain/Node configuration is a better place to be.

Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, February 12, 2010 12:03 PM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: Update on the SCAClientFactoryImpl

> On Fri, Feb 12, 2010 at 6:45 PM, ant elder <an...@gmail.com> wrote:
>> On Wed, Feb 10, 2010 at 10:48 PM, Simon Laws <si...@googlemail.com> 
>> wrote:
>>
>>> More generally we need to look at the default binding. At the moment
>>> it's restricted to one and only one remote transport. I think we need
>>> to relax this and allow the binding to decide what transport to use
>>> based on the environment it finds itself in and the configuration of
>>> the endpoint.
>>
>> Yes that would be good. The way I've been thinking this could work is
>> any binding should be able to be used for an SCA binding and the
>> sca-binding remote code could just decide on the name of the binding
>> provider and delegate to that, and we'd not need a separate
>> binding-sca-runtime-xxx module for each. We might need a new interface
>> which binding providers can implement (eg something like
>> sca-binding-cabable) to indicate that the binding is able to be used
>> as an SCA binding. We've also a couple of cases now where multiple sca
>> binding impls being used concurrenlty would be useful.
>
> I'm all for getting rid of code if we can so this sounds like a useful
> line of thought. We need to think about where the rubber hits the road
> and where the decision is actually made. For example,
>
> <binding.sca/>
>
> Must assume some default case where no more information is provided
>
> <binding.sca remote="binding.ws"/>
>
> or
>
> <binding.sca>
>   <remote>
>       <binding.ws/>
>   </remote>
> <binding.sca>
>
> Or similar (probably need ability to actually configure the remote
> version of the default binding). So that the reference can pick up
> configuration from the service as required.
>
> We also need to work out how the wire format story plays out here. Do
> we configure the default binding and expect it to propagate down to
> remote bindings or do we configure the remote bindings explicitly. The
> former sounds attractive and would need to be the case if we assume a
> default remote binding is in place. However this means that we need
> common wire formats across the bindings. Maybe we should allow this
> configuration to be binding specific with a sensible default which is
> in place 90% of the time.
>
>>
>>> In particular we have this situation where, in the remote endpoint case, 
>>> we have to decide whether it's really remote
>>> (different JVM) or just in a different classloader, in which case an
>>> optimization is possible. I guess this is a different thread.
>>>
>>
>> I've already implemented that now in r908835 so now the local sca
>> binding invoker does any cross classloader copies if necessary.
>
> Saw the change. Haven't absorbed it yet.
>
>>
>>   ...ant
>> 

Re: Update on the SCAClientFactoryImpl

[Simon Laws <si...@googlemail.com>]

On Fri, Feb 12, 2010 at 6:45 PM, ant elder <an...@gmail.com> wrote:
> On Wed, Feb 10, 2010 at 10:48 PM, Simon Laws <si...@googlemail.com> wrote:
>
>> More generally we need to look at the default binding. At the moment
>> it's restricted to one and only one remote transport. I think we need
>> to relax this and allow the binding to decide what transport to use
>> based on the environment it finds itself in and the configuration of
>> the endpoint.
>
> Yes that would be good. The way I've been thinking this could work is
> any binding should be able to be used for an SCA binding and the
> sca-binding remote code could just decide on the name of the binding
> provider and delegate to that, and we'd not need a separate
> binding-sca-runtime-xxx module for each. We might need a new interface
> which binding providers can implement (eg something like
> sca-binding-cabable) to indicate that the binding is able to be used
> as an SCA binding. We've also a couple of cases now where multiple sca
> binding impls being used concurrenlty would be useful.

I'm all for getting rid of code if we can so this sounds like a useful
line of thought. We need to think about where the rubber hits the road
and where the decision is actually made. For example,

<binding.sca/>

Must assume some default case where no more information is provided

<binding.sca remote="binding.ws"/>

or

<binding.sca>
   <remote>
       <binding.ws/>
   </remote>
<binding.sca>

Or similar (probably need ability to actually configure the remote
version of the default binding). So that the reference can pick up
configuration from the service as required.

We also need to work out how the wire format story plays out here. Do
we configure the default binding and expect it to propagate down to
remote bindings or do we configure the remote bindings explicitly. The
former sounds attractive and would need to be the case if we assume a
default remote binding is in place. However this means that we need
common wire formats across the bindings. Maybe we should allow this
configuration to be binding specific with a sensible default which is
in place 90% of the time.

>
>> In particular we have this situation where, in the remote endpoint case, we have to decide whether it's really remote
>> (different JVM) or just in a different classloader, in which case an
>> optimization is possible. I guess this is a different thread.
>>
>
> I've already implemented that now in r908835 so now the local sca
> binding invoker does any cross classloader copies if necessary.

Saw the change. Haven't absorbed it yet.

>
>   ...ant
>

Re: Update on the SCAClientFactoryImpl

[ant elder <an...@gmail.com>]

On Wed, Feb 10, 2010 at 10:48 PM, Simon Laws <si...@googlemail.com> wrote:

> More generally we need to look at the default binding. At the moment
> it's restricted to one and only one remote transport. I think we need
> to relax this and allow the binding to decide what transport to use
> based on the environment it finds itself in and the configuration of
> the endpoint.

Yes that would be good. The way I've been thinking this could work is
any binding should be able to be used for an SCA binding and the
sca-binding remote code could just decide on the name of the binding
provider and delegate to that, and we'd not need a separate
binding-sca-runtime-xxx module for each. We might need a new interface
which binding providers can implement (eg something like
sca-binding-cabable) to indicate that the binding is able to be used
as an SCA binding. We've also a couple of cases now where multiple sca
binding impls being used concurrenlty would be useful.

> In particular we have this situation where, in the remote endpoint case, we have to decide whether it's really remote
> (different JVM) or just in a different classloader, in which case an
> optimization is possible. I guess this is a different thread.
>

I've already implemented that now in r908835 so now the local sca
binding invoker does any cross classloader copies if necessary.

   ...ant

Re: Update on the SCAClientFactoryImpl

[Simon Laws <si...@googlemail.com>]

Looks like a good change to me Raymond. It means that the client is
using the same default binding stack that normal references are. I'm
adding tests and using just the SCA client in isolation does highlight
that we need to init() the node to get the registry up an running.

More generally we need to look at the default binding. At the moment
it's restricted to one and only one remote transport. I think we need
to relax this and allow the binding to decide what transport to use
based on the environment it finds itself in and the configuration of
the endpoint. In particular we have this situation where, in the
remote endpoint case, we have to decide whether it's really remote
(different JVM) or just in a different classloader, in which case an
optimization is possible. I guess this is a different thread.

Simon