On Fri, May 15, 2009 at 11:16 AM, Simon Laws<[email protected]> wrote: > 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 >
I was having thinking about backward compatibility again and wonder if there is another approach we've not mentioned yet which may be easier - translate OSOA contributions to OASIS at runtime. At the simplest level all that needs to be done is change the namespace in XML files (eg in getName in the XMLStreamReader) and change the annotation package name in Java implementation classes (eg using ASM in BaseJavaImplementationImpl.setJavaClass), just those two changes would get a lot of the 1.x samples running in 2.x, and with a bit more work would be to do more complex transformations of composites to map between OSOA and OASIS. There are some things we can't support, such as conversations, but we should be able to get a lot of 1.x contributions running on the 2.x runtime with that approach. WDYT, is this something worth having a go at? ...ant
