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
