RE: [sca-assembly] [ISSUE 132] Rebuttal: Against the use of portability andfunctions as reasons for requiring one of the existing 4 languages

Don,

I think that the central question at
issue here is what it means to claim conformance to the SCA Assembly Model
spec.

Currently, the requirement essentially
covers two things:

a) that the SCA runtime concerned passes
the Conformance test suite

b) that an SCA specification exists
for the implementation language that is used in the Conformance test suite

At the moment, because we're doing the
standardization work at OASIS, both of these requirements are tied to OASIS:

- the test suite is required to be the
one that is available from the OASIS website, freely available to all

- the SCA specification for the implementation
type is one that is available from OASIS, again freely available to all

I think that the debate that is going
on is about modifying these requirements.

I believe that these requirements don't
restrict the ability to support any implementation type or implementation
language with SCA.

Clearly, it is possible to extend the
conformance suite to embrace new implementation types and it is also possible
to bring

forward specifications for new implementation
types in SCA to OASIS for standardization.  That, in essence, is the
approach

embodied in the current conformance
statements in the Assembly spec.

I think that the debate is around whether
this approach is too onerous and whether it should be relaxed in some ways
so as to make it

easier and more attractive for anyone
to build an SCA runtime for some new implementation type and then claim
conformance for

that runtime.

So far, I believe that it is agreed
that passing the conformance test suite is required in order to claim conformance.
 The question is

how the test suite can be adapted for
a new language. There is also question of the availability of the adapted
test suite for anyone to 

obtain and run.  If everything
is done at OASIS, this is guaranteed.  If it is done elsewhere, how
can it be guaranteed?

The issue of the need for some form
of SCA specification for a new implementation type has been debated less,
although in my

opinion, it does need debate and a clear
answer.  First: is it still required to have an "SCA specification
document" for some new

implementation type, independent of
the venue for the creation and publication of such a document?  Secondly,
if there is such

a document, is it required that it is
available freely to all? Thirdly, if there is such a document, what requirements
are there on its

contents?  I note that we have
answers for all of these for SCA implementation type specifications developed
at OASIS.  If such

documents are created in some other
way, how do we ensure the right content and availability?

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:
"Ferguson, Donald F" <>

To:
Mike Edwards/UK/IBM@IBMGB, "OASIS
Assembly" <>, <>

Date:
24/06/2009 11:42

Subject:
RE: [sca-assembly] [ISSUE 132] Rebuttal:
Against the use of portability and functions as reasons for requiring one
of the existing 4 languages

I will reexamine the material.
Does your respond mean that you are willing to remove the requirements
on supporting certain languages? I have been having a little trouble with
the mailing lists and may have missed your comments.

 

Thanks.

 

Dr. Donald F. Ferguson

Distinguished Engineer

Corporate Senior Vice President

Chief Architect Products and
Technology





www.donald-ferguson.net/blog

 

From: Mike Edwards [mailto:]

Sent: Wednesday, June 24, 2009 6:27 AM

To: Ferguson, Donald F; OASIS Assembly; 

Subject: RE: [sca-assembly] [ISSUE 132] Rebuttal: Against the use of
portability and functions as reasons for requiring one of the existing
4 languages

 

Don, 

I agree with you that we should define a conformance test for the SCA Assembly
Model spec. 

Have you had a chance to look at the test suite materials for SCA Assembly,
which can be found here: 

http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/download.php/32963/sca-assembly-1.1-test-assertions-cd01.pdf

http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/download.php/32961/sca-assembly-1.1-testcases-cd01.pdf

http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/download.php/32967/sca-assembly-1.1-testcases-cd01.zip

I'm interested in your views as to the suitability of this test suite for
testing conformance to the SCA Assembly spec.  If you can suggest

improvements, extensions or changes to any of the materials, that would
be great. 

As I said in my recent note in reply to Jim, one thing we don't say with
regard to the current test suite materials is what can and what cannot

be changed in adapting the test materials to suite some new implementation
type.  Suggestions for defining this are most welcome.

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:

"Ferguson, Donald F"
<>

To:

"Jim Marino" <>,
"OASIS Assembly" <>, <>

Date:

23/06/2009 18:40

Subject:

RE: [sca-assembly] [ISSUE 132] Rebuttal:
Against the use of portability and functions as reasons for requiring one
of the existing 4 languages

 

I do not see any reason to believe that we cannot define a conformance
test for SCA Assembly. If we are able to do so, we would not need to require
support for the core languages. I assert that 1) We should not assume that
we cannot define a compliance test until we have tried. 2) An assembly
spec that places requirements on internal implementation languages is flawed.

  

Finally, I was present in IBM when we started work on SCA. Language independence
and encapsulation of implementation was an explicit objective.  The
IBM architecture leadership would have vetoed any assembly spec with this
requirement. 

  

Dr. Donald F. Ferguson 

Distinguished Engineer 

Corporate Senior Vice President

Chief Architect Products and Technology





www.donald-ferguson.net/blog

  

From: Jim Marino [mailto:]

Sent: Tuesday, June 23, 2009 1:06 PM

To: OASIS Assembly; 

Subject: Re: [sca-assembly] [ISSUE 132] Rebuttal: Against the use of
portability and functions as reasons for requiring one of the existing
4 languages 

  

Mike, 

  

You did not addressed the points I was hoping you would. In fairness, I
probably did not explain them clearly. Here's another try. 

  

As background, I think we all agree on the value of strong, verifiable
conformance and clear tests that can perform that task. No one is arguing
that point. And no one is claiming vendors should be allowed to "invent"
or otherwise modify portions of the conformance test suite with abandon
:-). I'm sure we can safely assume everyone understands the virtues of
conformance test suites and avoid rehashing them here. 

  

Given that, my point is that a vendor should be able to claim conformance
to the SCA Assembly specification without being required to be conformant
with one of the official languages. One of the reasons given for not accepting
Microsoft's request to change this requirement was, "If
there were no requirement to support one of the implementation types covered
by the Open CSA Member Section, this would mean that end users could have
no assurance that the SCA runtime concerned really provides the functions
laid down by the SCA specifications"[1]. In a nutshell, I don't think
the statement is accurate and I believe conformance tests that do not rely
on a specific implementation type (other than composites) can be developed
for Assembly. The purpose of my email was to outline how that could be
accomplished. 

  

I would not characterize this approach as more "open" since it
still hold vendors (or open source projects) accountable in very defined
and verifiable ways. It is perhaps more "modular" and arguably
will promote portability, which is lacking with SCA.

  

What would I like to see? Basically, I would like a runtime to be able
to claim conformance to the SCA Assembly Specification without having any
requirements by way of a programming language. In other words, it should
be possible for a runtime to pass the Assembly conformance suite without
having to support any of the sanctioned programming language specifications.
One proviso which could be attached to claim conformance is that a vendor
(or open source project) would be required to make any artifacts required
to run the tests (excluding the runtime) available under the same license
terms as the OASIS tests. Given the current test suite requires vendor-specific
code, this probably should be a requirement regardless of the present proposal.

  

I believe this approach would address the concerns raised by a number of
parties during the public review. What issues do you see with this approach
or is it acceptable in your view?

  

Jim 

  

  

[1] http://lists.oasis-open.org/archives/sca-assembly-comment/200905/msg00001.html.
  

  

On Jun 23, 2009, at 4:03 PM, Mike Edwards wrote: 

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 

  

 

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 

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