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