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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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


Subject: NEW ISSUE: Need to align language specific testcase artifacts with SCA-Assembly



TARGET: SCA Policy FW Testcase suite

DESCRIPTION:

The initial concern is that the Policy Test Suite has language specific
artifacts in it but there is no document that describes how a vendor should
modify the test suite to suit their own implementation technology.  Mike
and I did an analysis and comparison of the use of Java within the Policy
test suite versus similar Java files in the Assembly test suite.  Here's
what we found:

1) There are some Java files in common (ASM_0002_Client.java, Service
1.java, service1impl.java, service1Impl2.java, TestException.java,
TestInvocation.java).

2) There are some Java files that aren't common but should be common
(service1CallbackImpl.java, Service3Callback.java, service3Impl1.java,
Service3WithCallback.java).

3) There are some Java files that wouldn't be appropriate (nor necessary)
to have in the Assembly test suite (Service1ImplOneWay.java,
ServiceOneWay.java, ServiceOneWayImpl.java).

4) There is also a c/c++ variant of the Policy test suite that has the same
issues.

PROPOSAL:
Sticking with the numbering in the problem description:
1) For the common files, we propose removing them from the policy test
suite and change the test clients to depend on the Java contribution from
the Assembly test suite.

2) For the files that should be common, we propose removing them and
altering the Policy Test suite to accommodate the changes, and then change
the test clients to depend on the Java contribution from the Assembly test
suite.  There is no modification of the Assembly test suite to accomplish
this.

3) This one is tricky.  After having removed as many Java artifacts as
possible, we're left with a small number of Java files (3).  For these we
propose to keep them in the Policy_General_Java contribution.  This takes
us back to the initial problem in this issue; how to address test suite
adaptation needs.  Given that Assembly compliance requires Policy
compliance, it is safe to assume that a vendor that needs to adapt the
Policy suite will (for the same reasons) need to adapt the Assembly test
suite.  Therefore, we propose that the Assembly test suite adaptation
document be updated to cover adaptation of the Policy test suite as well.

4) Make similar change for the c/c++ implementations as in #1-#3 above.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com



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