You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/03/01 11:39:49 UTC
Re: [2.x] [DISCUSS] Backward compatibility
On Fri, Feb 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> 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
Re: [2.x] [DISCUSS] Backward compatibility
Posted by ant elder <an...@gmail.com>.
On Fri, May 15, 2009 at 11:16 AM, Simon Laws <si...@googlemail.com> wrote:
> 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
>
+1 for looking at a service registry approach as it seems to have many
benefits including helping with more dynamic domain operation.
> There are problems inherent in this approach though,for example, how
> to deal with policy which are supposed to be domain wide.
>
Policy may not be such a problem if we accept a restriction that
domain wide policy would only apply to nodes at the same sca version
as the policy?
...ant
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Simon Laws <si...@googlemail.com>.
Sounds good, and we could awk (or similar) java files to replace OSOA
package names with OASIS package names.
Simon
Re: [2.x] [DISCUSS] Backward compatibility
Posted by ant elder <an...@apache.org>.
On Thu, Sep 3, 2009 at 11:27 AM, Ramkumar R<ra...@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 1:24 PM, ant elder <an...@apache.org> wrote:
>>
>> On Wed, Sep 2, 2009 at 1:02 PM, Simon Laws<si...@googlemail.com>
>> wrote:
>> >> 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
>> >>
>> >
>> > I think Mark discussed this approach originally under the title of a
>> > migration tool. Given that we currently support OSOA and OASIS
>> > composites using separate runtimes then a migration tool would be
>> > useful. However I don't agree with the "at runtime" part. If we build
>> > a migration tool I think it should be under the control of the user as
>> > to when it runs. If they have a 1.0 composite then they can convert it
>> > to a 1.1 composite, take notice of any errors that are reported during
>> > the conversion and, once happy, run it on the 1.1 runtime. No magic
>> > required.
>> >
>> > Simon
>> >
>>
>> Ok if we have a tool approach then it will be easy enough to have it
>> work ine either batch or runtime and share the code.
>>
>> I guess an obvious way to start would be trying to use XSLT to
>> transform OSOA composites and contribution xml into OASIS ones and
>> seeing what things that comes across which can't be migrated with a
>> simple transform.
>>
>> ...ant
>
> Using an XSLT transformation looks like good migration tool
> for me. But that's only good enough for the composite file transformation,
> we need a method to handle the annotations used in the code?
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Yep, so along with the XSLT transormation the application code needs
to get updated to use the OASIS APIs and annotations. As Simon
suggested an offline tool could use awk on the Java files, or a
runtime tool could use Asm on the class files, to fix the annotaions
as its mostly just a package rename. There are also the varrious SCA
and Tuscany APIs though which are a little more complicated, for them
it might be easiest to include some backward compatible facade classes
that transform the OSOA/1.x clalls to use the OSOA/2.x API. Wont be
able to get everything to work but those will be less common edge
cases and it looks like we should be able to get quite a high
percentage of old contributions working.
...ant
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Ramkumar R <ra...@gmail.com>.
On Thu, Sep 3, 2009 at 1:24 PM, ant elder <an...@apache.org> wrote:
> On Wed, Sep 2, 2009 at 1:02 PM, Simon Laws<si...@googlemail.com>
> wrote:
> >> 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
> >>
> >
> > I think Mark discussed this approach originally under the title of a
> > migration tool. Given that we currently support OSOA and OASIS
> > composites using separate runtimes then a migration tool would be
> > useful. However I don't agree with the "at runtime" part. If we build
> > a migration tool I think it should be under the control of the user as
> > to when it runs. If they have a 1.0 composite then they can convert it
> > to a 1.1 composite, take notice of any errors that are reported during
> > the conversion and, once happy, run it on the 1.1 runtime. No magic
> > required.
> >
> > Simon
> >
>
> Ok if we have a tool approach then it will be easy enough to have it
> work ine either batch or runtime and share the code.
>
> I guess an obvious way to start would be trying to use XSLT to
> transform OSOA composites and contribution xml into OASIS ones and
> seeing what things that comes across which can't be migrated with a
> simple transform.
>
> ...ant
>
Using an XSLT transformation looks like good migration tool
for me. But that's only good enough for the composite file transformation,
we need a method to handle the annotations used in the code?
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] [DISCUSS] Backward compatibility
Posted by ant elder <an...@apache.org>.
On Wed, Sep 2, 2009 at 1:02 PM, Simon Laws<si...@googlemail.com> wrote:
>> 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
>>
>
> I think Mark discussed this approach originally under the title of a
> migration tool. Given that we currently support OSOA and OASIS
> composites using separate runtimes then a migration tool would be
> useful. However I don't agree with the "at runtime" part. If we build
> a migration tool I think it should be under the control of the user as
> to when it runs. If they have a 1.0 composite then they can convert it
> to a 1.1 composite, take notice of any errors that are reported during
> the conversion and, once happy, run it on the 1.1 runtime. No magic
> required.
>
> Simon
>
Ok if we have a tool approach then it will be easy enough to have it
work ine either batch or runtime and share the code.
I guess an obvious way to start would be trying to use XSLT to
transform OSOA composites and contribution xml into OASIS ones and
seeing what things that comes across which can't be migrated with a
simple transform.
...ant
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Simon Laws <si...@googlemail.com>.
> 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
>
I think Mark discussed this approach originally under the title of a
migration tool. Given that we currently support OSOA and OASIS
composites using separate runtimes then a migration tool would be
useful. However I don't agree with the "at runtime" part. If we build
a migration tool I think it should be under the control of the user as
to when it runs. If they have a 1.0 composite then they can convert it
to a 1.1 composite, take notice of any errors that are reported during
the conversion and, once happy, run it on the 1.1 runtime. No magic
required.
Simon
Re: [2.x] [DISCUSS] Backward compatibility
Posted by ant elder <an...@gmail.com>.
On Fri, May 15, 2009 at 11:16 AM, Simon Laws<si...@googlemail.com> 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
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Simon Laws <si...@googlemail.com>.
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
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Simon Laws <si...@googlemail.com>.
Hi Yang
I guess we are incrementally assessing how possible it is to allow our
model processing support both levels of spec. In my mind the jury's
still out but we have potential solutions to the problems we've found
so far. Nothing we have done to date prevents the model processing
from being limited to one level of the spec if we do get stuck.
More comments in-line
snip..
>
> However, I do understand the potential difficulty to enable both OSOA and
> OASIS. .
>
> One solution comes to my mind is if our virtual "SCA Domain" can have two
> domain instances one supporting OSOA , the other supporting OASIS, then
> potentially the "domain" instance can use different set of libraries(of
> course they can also share the same if the shared code can take care of both
> spec level).
>
I think we have to decide whether we consider composites, written to
different spec levels, will be in the same domain or not. I think our
default solution is to follow what you say here IIUC. I.e. what was
SCADomain is now called a Node and I see that it would be practical to
have individual nodes support a single version of the SCA
specification. In this scenario the virtual domain, what we now call
the domain manager, would still have to deal with composites of all
types. In particular when calculating the wiring across the domain we
need a consistent model of references, services, policies etc.
It may be possible that we can do this through an API that provides
service lookup and policy matching features rather than assuming a
completely merged model. Having such an API may also help with
supporting endpoint resolution from Nodes. The implication of this API
based train of thought is that we would, IMHO, be on the "Running and
interacting in the same domain" track from
(http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Backward+Compatibility)
rather than the "Full integration V1.1 reusing V1.0 composite" track.
I.e. we could have multiple types of composite in the domain, we would
like them to interact with one another over binding.sca but a V1.1
composite couldn't reuse a V1.0 composite. Horizontal but not vertical
compatibility if you like.
> One other scenario comes to my mind is if we can make OSOA applications as
> one implementation type , so we use the SCA way to reuse an OSOA
> applications. This way if customer does not want to do a migration, they can
> just define OASIS composite definitions to reuse their OSOA application
> logics... similar as JEE integration to reuse JEE applications...
>
Do you mean implementation.osoa here? Certainly a possibility and adds
an element of the vertical compatibility missing from above. Would
this be the only point of integration? We would have to decide what to
do about policy processing if nothing else.
Simon
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Yang Lei <ya...@us.ibm.com>.
I agree with Simon, I do not think it is a good story to enforce customer
to migrate their application onto the new spec . The whole point of SCA is
to enable assembly of application writing in different technology to
expose/consume services . If ourselves can not offer the solution on the
coexistence and interoperability of the two sets of application on
different level of specifications under the same logical "SCA Domain" , how
we can persuade customer to adapt this technology...
However, I do understand the potential difficulty to enable both OSOA and
OASIS. .
One solution comes to my mind is if our virtual "SCA Domain" can have two
domain instances one supporting OSOA , the other supporting OASIS, then
potentially the "domain" instance can use different set of libraries(of
course they can also share the same if the shared code can take care of
both spec level).
One other scenario comes to my mind is if we can make OSOA applications as
one implementation type , so we use the SCA way to reuse an OSOA
applications. This way if customer does not want to do a migration, they
can just define OASIS composite definitions to reuse their OSOA application
logics... similar as JEE integration to reuse JEE applications...
Thank you.
Yang Lei
Simon Laws
<simonslaws@googl
email.com> To
dev@tuscany.apache.org,
03/05/2009 09:30 mcombellack@apache.org
AM cc
Subject
Please respond to Re: [2.x] [DISCUSS] Backward
dev@tuscany.apach compatibility
e.org
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
... snip
Hi Mark
I certainly think a migration tool would be a useful thing but I think
mandating migration doesn't present a good story for an infrastructure that
is intended to bring together lots of different technologies at potentially
lots of different versions.
But you are right that achieving full backward compatibility at the expense
of completing OASIS compliance would miss the point. I'm trying to get us
to think about it now and at least make provision for it even if we don't
test with it in the first instance. I started some pictures of different
scenarios [1]. Luciano has made a start at making sure that both versions
of the processors can be present. Even with this approach we can still
build an OASIS only runtime if we need to and I don't see it holding us
back particularly. So I think we should push it further and see how it
goes.
Regards
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Backward
+Compatibility
Re: [2.x] [DISCUSS] Backward compatibility
Posted by Simon Laws <si...@googlemail.com>.
>
>
>
> 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
>
... snip
Hi Mark
I certainly think a migration tool would be a useful thing but I think
mandating migration doesn't present a good story for an infrastructure that
is intended to bring together lots of different technologies at potentially
lots of different versions.
But you are right that achieving full backward compatibility at the expense
of completing OASIS compliance would miss the point. I'm trying to get us to
think about it now and at least make provision for it even if we don't test
with it in the first instance. I started some pictures of different
scenarios [1]. Luciano has made a start at making sure that both versions of
the processors can be present. Even with this approach we can still build an
OASIS only runtime if we need to and I don't see it holding us back
particularly. So I think we should push it further and see how it goes.
Regards
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Backward+Compatibility
RE: [2.x] [DISCUSS] Backward compatibility
Posted by Mark Combellack <mc...@apache.org>.
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:ant.elder@gmail.com]
Sent: 01 March 2009 10:40
To: dev@tuscany.apache.org
Subject: Re: [2.x] [DISCUSS] Backward compatibility
On Fri, Feb 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> 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