I want to get the distributed version of the SCA Binding up and running again now the new wiring code is done and the SCA Binding is only created when required. We need to create a mechanism to switch off/override the local SCA binding when it's not appropriate and then choose the appropriate distributed binding in place of the local binding.
Currently the default SCA Binding model is defined and implemented in o.a.t.s.assembly.The runtime artifacts (providers etc.) for the local SCA Binding are in o.a.t.s.core.runtime. We need to extend the SCA Binding model to take account of domain topology information. In the current distributed runtime this information is available from the domain but is only dealt with by the CompositeActivator when replacing the SCA Binding with remote bindings when required. I think we can make the SCA Binding a bit smarter and record its local/remote status more directly. The topology information should still be maintained by the domain but it should be accessible by the SCA Binding in a form that, given two components, the SCA Binding can tell whether a local or remote binding is required. A remote service SCA Binding needs to advertise the endpoint at which its service is available. Again this is a domain issue and the process for doing this should be managed by the domain through an interface that allows the service name and protocol specific URL to be registered. A remote reference SCA Binding need to determine the endpoint at which the remote service is available, by asking the domain for the protocol specific URL given a service name, and configure the physical binding appropriately. In both cases a matching distributed binding needs to be chosen at both ends. Previously we created a binding-sca module to contain the extra code required for handling the distributed aspects of the SCA Binding. I think it would be useful to maintain this separation in the event that we want to provide alternative protocols for the distribute SCA binding. I'm wondering if we should go with something more specific such as binding-sca-ws, binding-sca-jms. The protocol a domain uses could then be controlled using the usual extension mechanism. Doing this does imply that the correct, i.e. local or distributed, binding provider factory can be located. This is done currently based on the binding type in the model so this will have an impact on how we factor the SCA Binding model. Am hoping to get a bit of discussion going here to help me understand the changes that have recently been made to the wiring code and the SCA binding so that the distributed version provides a neat extension to the new features. Simon
