[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Untested conformance items in WS binding spec
I took and AI to send out an analysis of untested conformance items in WS binding spec. Below is that analysis. Note that I did not find any conformance items that needed a change in the main spec (eg, changing a SHOULD to MUST, removing a MAY etc). All that is needed is either explicitly marking an item as untestable or writing new tests. I'll file two new issues for that. 1) [BWS20022] The SCA runtime SHOULD support the element <wsa:EndpointReference> and [BWS20023] If an SCA runtime does not support the element <wsa:EndpointReference>, then it MUST reject an SCA WS Binding XML document (as defined in Section 5.1) that contains the element. Add a single new test that uses an EPR. This test will test both 20022 and 20023. This would require adding instructions on how select the expected output from the TC for runtimes that support EPRs and runtimes that don't. 2) [BWS20027] When binding.ws is used on a service or reference with an interface that is not defined by interface.wsdl, the SCA runtime MUST derive a WSDL portType for the service or reference from the interface using the WSDL-mapping rules defined for that SCA interface type. This is not tested in the WS binding testcases as it requires a non WSDL interface. But it is tested in the POJO testcases (and I assume C/C++). The POJO testcases do use binding.ws as well as interface.java together. We should just note that in the TC doc. 3) [BWS20028] An SCA runtime MUST raise an error if the interface on a service or reference element with a binding.ws element does not map to a WSDL portType. This is hard to test as all the interfaces that are used are mappable to WSDL portType. Testing this would require an instance of a new interface type that does not map to WSDL portType. I think it is OK to not test this. And it is important to have this in the spec. Mark this as untestable in the TC doc. 4) [BWS20029] Any service hosted by an SCA runtime with one or more web service bindings with HTTP endpoints SHOULD return a WSDL description of the service in response to an HTTP GET request with the “?wsdl” suffix added to that HTTP endpoint URL. This is not tested as it is an optional feature. This is a good practice and we should have a test for it with instructions for how to adapt it to runtimes that don't support it. For example, the test could do a HTTP get on "?wsdl" and see if it returns a 2xx with a wsdl doc 5) [BWS20030] If none of the web service bindings for an SCA service have HTTP endpoints, then the SCA runtime SHOULD provide some other means of obtaining the WSDL description of the service. This is not tested as it is an optional feature. I don't see a harm in keeping this in the spec and not testing it. Mark this as untestable. 6) [BWS20034] The SCA runtime SHOULD support the WSDL 1.1 binding extension for SOAP 1.2 over HTTP [W11-SOAP12], as identified by the WSDL element wsoap12:binding that has the @transport attribute with a value of "http://schemas.xmlsoap.org/soap/http". This is not tested as it is an optional feature. A new test that uses WSDL 1.1 with SOAP 1.2 binding constructs should be added for this; include instructions for adapting the test suite for runtimes that don't support it. 7) [BWS20036] The <bindingType> element associated with this binding SHOULD include the SOAP.v1_2 intent in its @mayProvides attribute. This is not tested as it is an optional feature. A new test in conjunction with the test for BWS20034 should be added. A common test could be written for both 20036 & 20034. 8) [BWS20037] The SCA runtime MUST raise an error if a web service binding is configured with a policy intent(s) that conflicts with the binding instance's configuration. This is marked as untestable as it is claimed that there is no standard way of producing a conflict between attached intent(s) and the configuration of a <binding.ws/> element. I think this should be tested and it is testable. A simple way to do this would be to attach a SOAP.v1_2 intent to an element that has a SOAP 1.1 binding (or vice versa) 9) [BWS40007] When using the default transport binding rules with the rpc-literal pattern, the SCA runtime SHOULD use the structural URI associated with the binding as the namespace of the child elements of the SOAP body element. This is not tested as it is an optional feature. A test should be added for this. For example, the new test could requires the default transport binding rules and uses the rpc-lit pattern. The associated soap message should contain the appropriate namespace. 10) [BWS50010] The WSCallback policy assertion indicates that the WSCB Client and the WSCB Service MUST use SCA Web Services Callback Protocol to implement callbacks. Since SCA runtimes aren't required to support/understand WS-Policy this is not tested. An optional test should be added to test this. For exapl the new test could contains a WSDL that has the WSCB policy assertion with wsdl:required='true' 11) [BWS50013] The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for a WSCallback policy assertion but which MUST NOT have WSCallback policy assertions attached: wsdl:portType This is not tested. A new optional test should be added. For example, a negative test that contains a WSDL that has the WSCB policy assertion with wsdl:required='true' attached to the wsdl:portType 12) [BWS50014] Policies and assertions SHOULD be signed to prevent tampering. Not tested as it is optional. I don't think it is important to test this. It still makes sense to leave this in the spec. 13) [BWS50015] Policies SHOULD NOT be accepted unless they are signed and have an associated security token to specify the signer has proper claims for the given policy. Not tested as it is optional. I don't think it is important to test this. It still makes sense to leave this in the spec. -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]