I've been doing more investigation around backward compatibility this week. I have the "Running and interacting in the same domain" scenario in mind [1]. I haven't made all these changes but to make this work using a shared model needs...
1/ Copy in all the 1.x processors. - Copying processors from 1.x to 2.x does require changes as the infrastructure in 2.x is slightly different from 1.x - We need to change the processor package name to avoid conflicts - So not a clean diff between 1.x processor and 2.x version of 1.x processor. - Problematic to skimp where we think the processors haven't changed and just map some 2.x processors to 1.x namspaces because we have changed the way we have done end tag processing so it messes up. If we wanted to allow this then we could review the XML processing but requires work 2/ As discussed previously store QName of elements for each Model element so we know what the namspace is - fix up resolve processing to use this - fix up write processing to use this - I cheated for my experiment and assumed resolve was spec agnostic 3/ Find out which extension runtimes are spec dependent - implementation-java has introspectors that look for model specific annotations. - I cheated here for my experiment and added the OSOA @Reference introspector into the OASIS implementation-java so it looks for both 4/ Allow a different set of builders to run depending on the composite being built. - This is tricky as if we choose to build the domain composite, as the scenario suggests, then we would have to identify particular OSOA/OASIS specific parts of the builder as the domain composite just includes all components from deployed composites. We therefore can't build OSOA and OASIS composites separately in the Domain given the way it works at present. - Could change the way it works and look to build deployable composites separately somehow - Alternatively we need to revisit the builder approach as it is currently too complicated IMO. That gives an opportunity to make the OASIS/OSOA separation easier 5/ We need to instigate some 1.x tests - It's difficult to know what set of tests to pull. The ones we do use would need to be presented as a contribution rather than a Java SE runtime as we are only testing up to the build phase - Need 2.x/1.x interop tests As I'm not considering anything after the build phase these are the five main things. In this scenario an OASIS or OSOA node would be used to run OASIS or OSOA composites. Having been through this experiment it feels more complicated than I'd hoped and I'm wondering if there is an easier way to make this scenario work. The first thought that comes to mind is treating OASIS and OSOA composites completely separately in the domain from a processing point of view but get them to interact by instigating a service registry mechanism. We need a registry of some sort to make SCAClient and late binding work. I don't think it is so such a leap then to exploit this in the 1.x/2.x scenario for cross domain endpoint resolution. We would have to have the domain access 1.x and 2.x code bases independently (OSGI?) based on what type of composite is found. We would also need to fix the SCA binding to allow it to look up service in a registry again. I think that's on the cards for 2.x anyhow but it would be a change in 1.x There are problems inherent in this approach though,for example, how to deal with policy which are supposed to be domain wide. Thoughts? Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Backward+Compatibility
