The SCA binding provides the default binding and appears when the user doesn't explicitly provide a binding against a reference or a service. The Tuscany runtime can use the SCA binding to implement local wires between components running in the same VM or remote wires between components running on different nodes.
There is a simple SCA binding implementation for the distributed runtime ( binding.sca) which uses JMS for remote wires. Initially the intention had been to hide all of the remote wiring parts of binding.sca behind the reference and service providers but there are some issues with the way wires are managed with respect to the SCA binding. Specifically the ones I came across were: - The original SCA binding was implemented as part of the assembly model and there is an amount of code that appears in the process of wiring references to services that specifically checks for the presence of the SCA binding and does special things in that case. I would like to ensure that the special things that are done are a product of the binding itself rather than the builder and activator code. - There are a number of issues about how to identify the target of a reference in various parts of the code. I believe this primarily boils down to the separation of targets and bindings, i.e. a reference has a set of targets and a binding held independently. For example, CompositeActivator.addBindingInterceptor() is creating binding providers but is not aware of which target is being addressed. This makes it tricky from within the binding to assess whether a local or remote wire is required. - If we want to have the SCA binding provide a facade of the remote binding that is actually in use then there is an issue with service invokers. The service side expects to find an invoker based on the binding service provider for the binding type in use. If SCA binding is acting as a facade the real binding type doesn't have a wire registered against it. There may be more issues as I didn't get to the end of trying to make this work before seeking an alternative. The solution in place now for these items has been to provide methods on the SCA Binding model that provide access to the remote binding that the SCA binding is using for remote wires. During the build phase the SCA Binding is replaced with the remote binding (JMS currently) and the wire creation process continues as normal. What I would like to do is look further at how we can move these features inside the SCA binding itself. Does anyone have any background on the issues I mention above? Are there any other features that the SCA binding should be providing? There as been much work in TUSCANY-1341 [1] relating to how wiring is being organized to ensure that callbacks work and I expect that this will have a (positive) impact on the ability to tidy up the SCA binding in this respect. These changes need to be taken into account also. Simon [1] http://issues.apache.org/jira/browse/TUSCANY-1341
