Analysis of WS Test suite as potential conformant implementation

Folks, here's an analysis of the WSCB callback
client and service conformance from the point of view of considering the
WS testcases as a conforming implementation.  There are 8 statements
which apply, two to WSCB clients, and 7 to WSCB services (one applies to
both).

My initial concern is that the test
suite includes negative tests - i.e. it is deliberately non-conformant
in order to check that a conformant implementation handles error cases
correctly.  So taken as a whole the test suite is not a conformant
implementation.  That means we must take only the positive tests if
we are to have a conformant implementation.  

Another point is that as far as the
WSCB service is concerned, the implementation is in one very simple class,
Service5Impl.java, which then relies on the JAX-WS runtime to host it,
to pass callback EPRs to it, and to handle the details of the WS-A conformance.
 So Service5Impl.java PLUS the JAX-WS runtime provide the functionality
required to conform to the WSCB Service statements.  The test suite
currently does not provide a means to validate this directly - we would
have to duplicate all the WSCB service tests, replacing the SCA runtime
with Service5Impl.java and the JAX-WS runtime in order to check it conforms.

BWS50002 - Every request message from
the WSCB Client that invokes the forward interface MUST contain a Callback
EPR.

BWS_5002_TestCase is a positive test,
it sends a request with a valid callback URL in the WS-A From header.

BWS_5003_TestCase is a negative test,
it deliberately sends a request with a WS-A "anonymous" callback
EPR.

BWS50004 - If the Callback EPR's [address]
value is "http://www.w3.org/2005/08/addressing/anonymous"
or "http://www.w3.org/2005/08/addressing/none"
then the WSCB Service MUST generate the Invalid Addressing Header fault
as specified in Section 6.4.1 of [WS-Addr-SOAP]. 

Service5Impl.java acts as a WSCB Service
to check that BWS50002 is observed (at least checks that the callback is
non-null through a Java annotation).

If the callback is null however, it
does not return a fault; instead it returns an error string via a normal
response message, so from that point of view it is not conformant.

BWS50005 - When the WSCB Service invokes
the callback interface, it MUST use the Callback EPR from a request message
that invoked the forward interface. 

Service5Impl.java acts as a WSCB Service
and does indeed use a callback EPR to make the callback (assuming the annotation
is resolved appropriately).

BWS50006 - Once the Callback EPR is
selected, the WSCB Service MUST follow the rules defined in Section 3.3
of [WS-Addr] to invoke operations on the callback interface.

Not evident to me from the test case
implementations themselves (Service5Impl.java in particular) if this is
the case.

BWS_5006_TestCase is the test that if
a client sends reference parameters, they are returned in the callback
via SOAP headers;  I don't see any corresponding test case which is
acting as the WSCB service for this statement.

BWS50007 - When the WSCB Service invokes
the callback interface, if the request message from which the Callback
EPR was obtained contained the wsa:MessageID SOAP header block, the WSCB
Service MUST include a wsa:RelatesTo SOAP header block in the callback
message.

BWS_5005_TestCase is the test that the
SCA runtime acts as a WSCB service.  I don't see any test case acting
as a WSCB service sending back the relatesTo SOAP header to the SCA runtime
- I can't envisage a test which can influence whether or not the SCA runtime
includes a wsa:messageID SOAP header block in the messages it sends from
a reference with a callback.

BWS50008 - The wsa:RelatesTo SOAP header
block MUST have the relationship type value of "http://docs.oasis-open.org/opencsa/sca-bindings/ws/callback"
and the related message id MUST be the wsa:MessageID of the message from
which the Callback EPR was obtained.

Only explicitly tested from the client
point of view.

BWS50009 - If the request message from
which the Callback EPR was obtained did not contain the wsa:MessageID SOAP
header block, the WSCB Service MUST NOT include a wsa:RelatesTo SOAP header
block with a relationship type value of "http://docs.oasis-open.org/opencsa/sca-bindings/ws/callback"
in the callback message.

Only explicitly tested from the client
point of view.

BWS50010 - The WSCallback policy assertion
indicates that the WSCB Client and the WSCB Service MUST use SCA Web Services
Callback Protocol to implement callbacks.

Not tested

Extraneous comment:  I noticed
that the TA to normative statement table in Appendix B includes:

BWS50013
BWS-TA-50009

BWS50014
BWS-TA-50010

BWS50015
BWS-TA-50011

And TA to TestCase mapping in Appendix
C includes:

BWS-TA-50009
SCA runtimes are not required to support
or understand WS Policy - untestable

BWS-TA-50010
Untested

BWS-TA-50011
Untested

However these statements and TAs do
not exist.

I believe we should handle this via
errata, there's no normative change and no effect on any testcase behaviour.

Regards, Simon

Simon Holdsworth

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