OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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:


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:  mike_edwards@uk.ibm.com

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]