Hi,
There is a second approach to backwards compatibility that has not yet been mentioned. I will raise it here and present some of its benefits so it can at least be discussed. Instead of making the Tuscany Runtime support both OSOA and OASIS, we could make Tuscany support OASIS only and provide tools that will help existing OSOA Developers convert their legacy OSOA applications to OASIS. The advantage of this approach is that the Tuscany Runtime is kept clean and simple - Tuscany is responsible for doing one thing - running OASIS SCA applications. We do not need to compromise its design to support both OSOA and OASIS. Supporting both OSOA and OASIS on the same runtime will be complex and in places likely to be messy. In this approach, the complexity of backwards compatibility with OSOA applications is contained within the conversion tools. These could do as much of the conversion as possible automatically. Where there are issues, the conversion tools can present the developer with options of how to resolve the problems manually. I my humble opinion, supporting both OSOA and OASIS is just a short to medium term thing. Eventually, all applications will be converted from OSOA to OASIS and there will be no need to support OSOA. When the day comes when OSOA is no longer required, it will be much easier to remove some OSOA to OASIS conversion tools rather than ripping OSOA out of the Tuscany runtime. Thanks, Mark _____ From: ant elder [mailto:[email protected]] Sent: 01 March 2009 10:40 To: [email protected] Subject: Re: [2.x] [DISCUSS] Backward compatibility On Fri, Feb 27, 2009 at 6:12 PM, Raymond Feng <[email protected]> wrote: Hi, I quickly realized that it's much more complicated than I had thought for the back compatibility by maintaining two versions of the processors. There are a few factors involved here: 1) We need to copy the OSOA processors into a new package and adjust its logic to load/save XML to/from the OASIS-based assembly model. It involves some conversions. 2) We need to maintain the test cases for the OSOA based processors too. 3) We will register the two set of processors in the META-INF/services files 4) For some of the artifacts such as Intents and PolicySets, do we treat the OSOA version the same as the OASIS version as now they have different QNames? I'm now starting to think if we should finish the OASIS round first and then merge the 1.x processors back as a separate effort. The problem with just focusing on OASIS for now and ignoring backward compatibility is that it might make more work and be harder to do in the long run, or we may end up just never getting around to it later. I think thats what the mail initiating this thread was saying. Backward compatibility is important. Being incompatibile makes unnecessary work for our users, they'll find applications breaking frustrating, and it may end up loosing us users when they decide instead of spending the time to upgrade to Tuscany 2.x they might as well change to use new framework xxx instead. I don't think 2.x backward compatibility needs to be perfect, as was said earlier a best-effort approach will do. So things like saving XML, or supporting policy variations seem less important as they're not used that much in 1.x. All we really need is for common 1.x applications to continue to run unchanged in 2.x. Take some of our basic samples from 1.x like the calculator and helloworld samples and ideally they'd run unchanged in 2.x. I don't think achieving that will not be so hard, I've done some SVN diffs of 1.x and 2.x and th changes aren't that big. Searching all the modules for "import org.oasisopen.sca" shows there are not that many hits, most are just for things like ServiceRuntimeException, and lots of others would be easy to fix with trivial changes to check for either annotation. Most of the extension schemas are very similar, the JMS binding has some attributes changed like "name" to "jndiName" which would be easy to code compatibility for. A diff of the calculator sample from 1.x to 2.x shows trivial changes to the Tuscany APIs that it would be easy for us to provide deprecated methods for so the samples continue to run unchanged. So unless someone can give a concrete example of something that would be really hard to make work then i think we should try do this for now. ...ant
