On Fri, Feb 12, 2010 at 6:45 PM, ant elder <[email protected]> wrote:
> On Wed, Feb 10, 2010 at 10:48 PM, Simon Laws <[email protected]>
> 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
>
