[2.x] [DISCUSS] Backward compatibility

[Simon Laws <si...@googlemail.com>]

We recently moved over to the OASIS package names [1] and I notice commits
to change the schema yesterday. So I want to discuss the backward
compatibility issue again. If we have aspirations to support any kind of
backward compatibility then we need to think about it now a bit otherwise
we'll make life difficult for ourselves later on

So what does backward compatibility mean? There are a range of answers. For
example,

A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate 1.x
and 2.x Tuscany runtimes. Any interaction is through remote bindings
B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to the
same domain but spec specific node/runtimes are required to actually run
them. Binding. sca is compatible though.
C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to the
same node/untimes

In my opinion we should do at least B and give some though to the
implications of C to either discount it or address it.

I think the implication of B is that the assembly model is shared between
SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still
agree with Ant that we can bring backward compatibility on line a little
later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it
makes this later effort more difficult that it need be.

This probably just comes down to simple things. It's tempting to just
replace all the xsd's and fix up the processors to take account of them. But
unless we change the processor package names and/or class names then it
makes it harder to bring the SCA1.1 processors back in when we want to run
both in the domain.

Thoughts?

Regards

Simon

[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04724.html

Re: [2.x] [DISCUSS] Backward compatibility

[Luciano Resende <lu...@gmail.com>]

On Fri, Feb 27, 2009 at 9:18 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
> From: Simon Laws
> Sent: Friday, February 27, 2009 6:16 AM
> To: tuscany-dev
> Subject: [2.x] [DISCUSS] Backward compatibility
> We recently moved over to the OASIS package names [1] and I notice commits
> to change the schema yesterday. So I want to discuss the backward
> compatibility issue again. If we have aspirations to support any kind of
> backward compatibility then we need to think about it now a bit otherwise
> we'll make life difficult for ourselves later on
>
> So what does backward compatibility mean? There are a range of answers. For
> example,
>
> A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate 1.x
> and 2.x Tuscany runtimes. Any interaction is through remote bindings
> B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to the
> same domain but spec specific node/runtimes are required to actually run
> them. Binding. sca is compatible though.
> C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to the
> same node/untimes
>
> <rfeng>Good list. There are two primary concerns: XML compatibility and Java
> API/Annotation compatibility. XML translation might be much simpler than the
> Java API/Annotation. Maybe we should start with XML compatibility
> first.</rfeng>
>
> In my opinion we should do at least B and give some though to the
> implications of C to either discount it or address it.
>
> I think the implication of B is that the assembly model is shared between
> SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still
> agree with Ant that we can bring backward compatibility on line a little
> later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it
> makes this later effort more difficult that it need be.
>
> <rfeng>We should have one java model which should be based on OASIS specs.
> Then we can see if we can translate the OSOA XML into the OASIS model by the
> legacy processors. I don't think the infosets for the two models are
> completely compatible. We'll probably see cases that we cannot parse the
> OSOA XML into the OASIS model. I more view this as a best-effort.<rfeng>
>
> This probably just comes down to simple things. It's tempting to just
> replace all the xsd's and fix up the processors to take account of them. But
> unless we change the processor package names and/or class names then it
> makes it harder to bring the SCA1.1 processors back in when we want to run
> both in the domain.
>
> <rfeng>I would rather keep both OSOA and OASIS XSDs. One thing we can do is
> to keep a copy of the OSOA-based processors into a different package name
> with osoa. </rfeng>
>
> Thoughts?
>

So, trying to summarize the decisions items here :

- Have one model, and this one is going to be based on OASIS spec.
- Have two processors for each extension, one handling OSOA composites
and the other handling OSOA; but both are going to produce OASIS
modules.

Some more related action items

- Start to have two versions of Tuscany NS, 1.0 and 1.1
- Separate 1.0 and 1.1 schemas into separate folders (sca10 and
sca11). Note that Tuscany extensions will have two versions of XSD,
one using Tuscany 1.0 NS and the other using 1.1 Tuscany NS

Some other questions

How to handle validation ? Are we going to apply only OASIS
assertions, even to OSOA based composite ? Are there any compliance
implications here ?
What do we do with OSOA based composites that cannot be mapped to
OASIS Java Model ? Should we reject it ?

> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04724.html
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.x] [DISCUSS] Backward compatibility

[Raymond Feng <en...@gmail.com>]

Hi, 

Please see my comments inline.

Thanks,
Raymond


From: Simon Laws 
Sent: Friday, February 27, 2009 6:16 AM
To: tuscany-dev 
Subject: [2.x] [DISCUSS] Backward compatibility


We recently moved over to the OASIS package names [1] and I notice commits to change the schema yesterday. So I want to discuss the backward compatibility issue again. If we have aspirations to support any kind of backward compatibility then we need to think about it now a bit otherwise we'll make life difficult for ourselves later on

So what does backward compatibility mean? There are a range of answers. For example,

A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate 1.x and 2.x Tuscany runtimes. Any interaction is through remote bindings
B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to the same domain but spec specific node/runtimes are required to actually run them. Binding. sca is compatible though. 
C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to the same node/untimes

<rfeng>Good list. There are two primary concerns: XML compatibility and Java API/Annotation compatibility. XML translation might be much simpler than the Java API/Annotation. Maybe we should start with XML compatibility first.</rfeng>

In my opinion we should do at least B and give some though to the implications of C to either discount it or address it. 

I think the implication of B is that the assembly model is shared between SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still agree with Ant that we can bring backward compatibility on line a little later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it makes this later effort more difficult that it need be. 

<rfeng>We should have one java model which should be based on OASIS specs. Then we can see if we can translate the OSOA XML into the OASIS model by the legacy processors. I don't think the infosets for the two models are completely compatible. We'll probably see cases that we cannot parse the OSOA XML into the OASIS model. I more view this as a best-effort.<rfeng>

This probably just comes down to simple things. It's tempting to just replace all the xsd's and fix up the processors to take account of them. But unless we change the processor package names and/or class names then it makes it harder to bring the SCA1.1 processors back in when we want to run both in the domain. 

<rfeng>I would rather keep both OSOA and OASIS XSDs. One thing we can do is to keep a copy of the OSOA-based processors into a different package name with osoa. </rfeng>

Thoughts?

Regards

Simon

[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04724.html

Re: [2.x] [DISCUSS] Backward compatibility

[Simon Laws <si...@googlemail.com>]

On Fri, Feb 27, 2009 at 3:53 PM, ant elder <an...@gmail.com> wrote:

>
>
> On Fri, Feb 27, 2009 at 2:16 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> We recently moved over to the OASIS package names [1] and I notice commits
>> to change the schema yesterday. So I want to discuss the backward
>> compatibility issue again. If we have aspirations to support any kind of
>> backward compatibility then we need to think about it now a bit otherwise
>> we'll make life difficult for ourselves later on
>>
>> So what does backward compatibility mean? There are a range of answers.
>> For example,
>>
>> A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate
>> 1.x and 2.x Tuscany runtimes. Any interaction is through remote bindings
>> B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to
>> the same domain but spec specific node/runtimes are required to actually run
>> them. Binding. sca is compatible though.
>> C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to
>> the same node/untimes
>>
>> In my opinion we should do at least B and give some though to the
>> implications of C to either discount it or address it.
>>
>> I think the implication of B is that the assembly model is shared between
>> SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still
>> agree with Ant that we can bring backward compatibility on line a little
>> later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it
>> makes this later effort more difficult that it need be.
>>
>> This probably just comes down to simple things. It's tempting to just
>> replace all the xsd's and fix up the processors to take account of them. But
>> unless we change the processor package names and/or class names then it
>> makes it harder to bring the SCA1.1 processors back in when we want to run
>> both in the domain.
>>
>> Thoughts?
>>
>> Regards
>>
>> Simon
>>
>> [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04724.html
>>
>
>
> That C/ above is the ideal isn't it? So what if we just say we will do that
> until we find some blocking issue? OTTOMH I can't think of a blocking issue,
> can anyone? If not then its just implementation detail - we need scdl
> processors for each version, the SCA API for bother versions, and in the
> Tuscany code things like everywhere it looks for an SCA annotation it needs
> to check in both old and new packages. As we implement it we may come across
> something that impossible to do in the one runtime so if/when that happens
> we'd either need to abandon the backward compatibility effort or else
> document the case and say if thats an issue to an application then it needs
> to stay using the 1.x code.
>
>    ...ant
>
>
Yeah, right. The runtime, certainly the XML processors, have been explicitly
designed to be fired up based on the namespace of the XML they are trying to
process so it seems a real shame to rip and replace.

As for C. I just don't think we know but I agree it's the ideal and, as I
say, I wouldn't want to discount it just because we haven't thought about it
properly.

+1 to doing as much as we can until it gets in the way.

Simon

Re: [2.x] [DISCUSS] Backward compatibility

[ant elder <an...@gmail.com>]

On Fri, Feb 27, 2009 at 2:16 PM, Simon Laws <si...@googlemail.com>wrote:

> We recently moved over to the OASIS package names [1] and I notice commits
> to change the schema yesterday. So I want to discuss the backward
> compatibility issue again. If we have aspirations to support any kind of
> backward compatibility then we need to think about it now a bit otherwise
> we'll make life difficult for ourselves later on
>
> So what does backward compatibility mean? There are a range of answers. For
> example,
>
> A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate
> 1.x and 2.x Tuscany runtimes. Any interaction is through remote bindings
> B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to the
> same domain but spec specific node/runtimes are required to actually run
> them. Binding. sca is compatible though.
> C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to
> the same node/untimes
>
> In my opinion we should do at least B and give some though to the
> implications of C to either discount it or address it.
>
> I think the implication of B is that the assembly model is shared between
> SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still
> agree with Ant that we can bring backward compatibility on line a little
> later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it
> makes this later effort more difficult that it need be.
>
> This probably just comes down to simple things. It's tempting to just
> replace all the xsd's and fix up the processors to take account of them. But
> unless we change the processor package names and/or class names then it
> makes it harder to bring the SCA1.1 processors back in when we want to run
> both in the domain.
>
> Thoughts?
>
> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04724.html
>


That C/ above is the ideal isn't it? So what if we just say we will do that
until we find some blocking issue? OTTOMH I can't think of a blocking issue,
can anyone? If not then its just implementation detail - we need scdl
processors for each version, the SCA API for bother versions, and in the
Tuscany code things like everywhere it looks for an SCA annotation it needs
to check in both old and new packages. As we implement it we may come across
something that impossible to do in the one runtime so if/when that happens
we'd either need to abandon the backward compatibility effort or else
document the case and say if thats an issue to an application then it needs
to stay using the 1.x code.

   ...ant