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
<simonsl...@googl
email.com> To
[email protected],
03/05/2009 09:30 [email protected]
AM cc
Subject
Please respond to Re: [2.x] [DISCUSS] Backward
[email protected] 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
<<inline: graycol.gif>>
<<inline: pic27258.gif>>
<<inline: ecblank.gif>>
