Ok, so that's pretty cool. Currently it works with a shared runtime. This is because while the EPR is marked as remote the EP is not and so binding.sca is currently configured in this case to talk directly to the service.
In the non-shared case neither the endpointregistry nor the remote version of binding sca are configured to work in this environment. This brings us back to what we should do here. Under the covers, in the non-shared case, it looks like it's creating a copy of the classloader. So this looks like a remote endpoint as far as the reference is concerned. Short diversion... At the moment the sca can only have one representation of the remote binding at any one time as it uses the DistributedSCABinding model to pull in whatever binding is registered against that type. Would we ever want to choose a type on the fly. I think the answer is no at the moment as it's hard to make a decision dynamically on the service side whether one remote binding is more suitable that another in any particular situation. ...end of diversion So, first thing first. how to get the endpoint registry information shared across classloaders? Can we host in in the "tuscany" web app and talk to it via HTTP or RMI (a precursor to a simple domain manager)? Is tribes configuration working well enough to use that? Is there an in memory approach we can use? Can you say something about how the libs in the Tuscany webapp are provided to each of the sca webapps/applications. This would probably work OK if the endpoint registry were shipped with the tomcat hook as it would be in the common classloader. A very specific Tomcat solution and would still need to distribute the registry to include tomcat in a wider domain. Simon
