Response to a Question on the Openness and Structure of the SCA Assemblytest suite

Folks,

This email is a response to some questions
that I received regarding the SCA Assembly test suite, as described in
the

SCA Assembly TestCases document and
as embodied in the TestCase artifacts currently present in the OASIS SVN

repository, which can be found here:

http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/download.php/32455/SCA_Assembly_TestCases_21.pdf

http://tools.oasis-open.org/version-control/browse/wsvn/sca-assembly/TestCases/#_TestCases_

The first thing to be clear about is
that the test suite is not fully baked yet.  The version that is described
in the TestCases

document is currently under review by
both the Assembly Test Subcommittee and by the main SCA Assembly technical

committee, with the aim of getting this
to a formal Public Review starting some time in June.  It is pretty
well certain that there

will be changes before the TestCases
are formally adopted.  Comments and suggestions for improvements are
welcome.

The next question concerns the apparent
Java-ness of the current Test Suite.  This is something that we debated
early on.

A test suite that cannot be exercised
is not likely to be a good test suite.  As a result, the SCA portions
of the TestCases

(composites, WSDLs, etc) do have an
underpinning of concrete implementation classes.  However, the testcases
are being

designed with the intention that the
implementation language dependent parts are replaceable and that the test
suite can

be "rendered" in any of the
SCA implementation languages.  At present, there is an appearance
of bias towards Java

simply because we have only completed
versions of the testcases in Java.

You will note in the current SVN repository
that most of the "higher level" materials, principally composites,
are built to be 

language neutral.  They only use
<interface.wsdl/> and <implementation.composite/> and they
mostly use <binding.sca/>,

other than a single <binding.ws/>
which is used to communicate with the Client test runner application.  The
language

specific parts of the test suite are
being placed into directories (aka "contributions") which are
tagged with the language

concerned, such as "General_Java"
for the Java-specific artifacts.  So, when we get around to creating
BPEL, C++ (etc)

versions of the testcases, these will
have separate language specific directories with names like "General_BPEL"
and

"General_CPP".  Of course,
we are later in creating such test artifacts as it is necessary to first
get the basic structure of

the test suite completed - and it has
been simpler to do this using Java implementation artifacts.  We can
add new 

implementation languages to the test
suite at any time.

The Client test runner application has
been configured to accept an parameter which specifies which implementation

language to use for running the tests,
i.e. "Java" or "BPEL" or "CPP" (etc).  This
causes the appropriate language versions

of the language dependent contributions
to be used to run the test.

One other concern that has been expressed
to me is the fact that the current Client test runner application, with
its test

configuration metadata, is entirely
in Java.  The first point to make in response to this is that the
Client application is in

"pure" Java - ie based on
the use of the capabilities of Java Standard Edition 6 and with no assumption
of any SCA

capabilities.  The Client application
communicates primarily with the applications under test through the means
of Web

services invocations, done using standard
JAX-WS capabilities built into the JSE 6 runtime.  

The only "non standard" part
of the Client application is the Bridge code which is specific to the particular
SCA runtime that 

is under test.  This code is used
to start the SCA runtime under test and to configure it with the contribution(s)
that make up the

testcase. This code is replaceable and
I anticipate that every SCA runtime vendor will build their own version
of this code.

The code is selectable by means of a
configuration parameter of the Client.

If there is a desire to build a version
of the test Client in some other language other than Java, I am sure that
we can

accommodate that.  All that is
required is that the client is able to start up and configure the SCA runtime
and then invoke

services using standard Web services.
 The metadata for each test has a simple form that is basically a
set of strings,

containing composite configuration,
input data and output data.

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:  

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