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. > 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
