Rebuttal: Against the use of portability and functions as reasonsfor requiring one of the existing 4 languages

[Jim Marino <jim.marino@gmail.com>]

Hi,

I haven't had much time lately to participate in TC discussions on  
language conformance due to other commitments. However, I did have the  
opportunity to discuss the technical merits of this issue at length  
with people from Microsoft. I think I understand where they are coming  
from and believe there may be a way to accommodate Microsoft's  
concerns while also improving the SCA specifications.

Coupling conformance to the Assembly specification with one of the  
"official" TC languages places an unneeded and expensive burden on  
potential implementors that may not support one of those languages.  
This is particularly evident given the OASIS requirement for two  
independent conformant implementations. The original spirit of  
assembly was language independence and that can be maintained. It  
seems the main sticking point is with conformance testing: namely, how  
can language independent tests be created that verify assembly  
assertions?

As a proposal, I believe it is feasible to use composite  
implementations to create language independent verification tests. The  
tests would make extensive use of the implementation.composite type as  
well as service and reference promotions. The actual implementations  
would be contained in a separate contribution (or contributions) and  
made available to the using composite via the contribution import/ 
export mechanism. The verification tests would be run against the  
components using the composites and their promoted services, which  
would result in language independent conformance checks.

As a convenience, composites which used "official" language types such  
as implementation.java or implementation.bpel could be made available.  
However, it would also be possible for a vendor to supply their own  
composites that used a proprietary language.

Making assembly truly language independent would have two significant  
benefits, specifically portability and expanding SCA's relevance.  
Realistically, the best chance of achieving portability for SCA is at  
the assembly level. The further one goes "down" - e.g. into policy,  
component implementations, and actual application code - portability  
becomes problematic. For example, policy is not likely to be portable  
given the ability to use different policy languages. The Java  
specification also does not address many of the areas required to  
write portable applications such as database access and using managed  
threads. If Java EE is any indicator, achieving portability of  
application code is likely to require years of effort, and even then  
the results are likely to be incomplete. However, in my opinion,  
portability at the assembly level is a realistic goal and should be  
pursued by making it as language independent as possible.

Language independence would also expand the relevance of assembly to  
areas Java EE could never touch. Assembly can be used across a host of  
proprietary programming languages, essentially providing a portable  
blueprint of systems, regardless of the technologies they run on. In  
my opinion, this may prove to be the most important contribution SCA  
has to make.

Jim