[ISSUE 132] Rebuttal: Against the use of portability and functions asreasons for requiring one of the existing 4 languages

Jim,

Thanks for your comments.

First, I would like to point out that
we have built the Assembly testcase suite along the lines that you

want to see.  It is built in a
way that is language independent with all top level materials being

wholly composite based, and then with
replaceable language-specific implementations at the

bottom.

Availability of the testcase suite in
each of the OASIS supported language types is not a "convenience"

- it is a requirement.  We already
have Java, and C, C++ and BPEL are well advanced.  Others will be

added as their specifications come forward
to public review.

The second point about the testcase
suite is that it is not just a matter for the SCA runtime implementers.

The idea is that the conformance testcase
suite is available to all - anyone can take it and use it to 

verify that some SCA runtime conforms
to the specifications.  It is the open nature of the test suite that

is the biggest guarantee that SCA runtime
vendors will take it seriously - no one can bend their way

around it without facing the possibility
that users will catch them out.

The second question to address is what
you really think it means to "conform" to the SCA specifications.

One important thing is that SCA is extensible
and can accommodate the use of pretty well any implementation

technology and implementation language.
 Any vendor can do this at any time.  So SCA is very much open,

as you desire.

However, claiming conformance is something
else.  What does "claiming conformance" really mean?

To me, it means that the SCA runtime
meets the requirements of the relevant SCA specifications.  

I am sure there is real value to end
users in a claim of conformance - the end users can have  expectations

of a conforming system that it will
work in a certain way - and that the end users knowledge of SCA will apply

to the conforming system.  It is
clear that vendors also attach importance to claiming conformance too.

If conformance is to have any real meaning,
I believe that this must mean adhering to the letter of the spec.

Our current approach to this is to require
the passing of the test suite - as a minimum check.  There will always

be things that the test suite does not
check - and for those, the wording of the conformance points in the spec

is the tool that people can use.

So, let us say that we want a more "open"
approach to claiming conformance for a runtime that supports 

one or more implementation languages
not specified by any of the OASIS TCs.  How might we do this while

still retaining some meaning to the
term "conformance"?  Some thoughts:

- Might we allow a claim of conformance
for language "X" as long as there is a Test Suite for Assembly
that

uses implementation language "X"?

- Might we allow a claim for conformance
for language "X" as long as there is a specification for SCA
component

implementations written in lnaguage
"X"?  Without such a specification and in particular without
a definition of

how the componentType is calculated
for an implementation artifact written in language "X", how would
it be

possible to know that the test suite
was a valid test suite?

- Should it be required that the test
suite and the specification for language "X" is available publicly
with some

form of open terms?  I note that
the current OASIS TC specs and test suite are available to anyone on open

terms - so that anyone can take them
and run them.

What are your thoughts on this?

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  

From:
Jim Marino <>

To:


Cc:
OASIS Assembly <>

Date:
10/06/2009 02:07

Subject:
[sca-assembly] Rebuttal: Against the
use of portability and functions as reasonsfor requiring one of the existing
4 languages

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

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU