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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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


Subject: 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








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