[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue 169: Sample wsdl in conflict w WS-I BP in WS-Trust1.3, 1.4
Hi Tony, Thanks for the input. - I am rewording the issue below to refer to BP 1.1. - Also, the issue title inadvertently ref'd "BSP", it should be "BP" (also changed in subject of email which will shift thread refs) The action from the committee did not appear to me to necessarily cover the issue, which is why I decided to raise it. In particular, the TC action appears simply to be to say that the text in the appendices is non-normative: http://lists.oasis-open.org/archives/ws-sx/200805/msg00029.html Also in 2nd action, it was not clear to me that the "errors" Marc will write up are these particular concerns, since I do not believe these are explicitly "errors" in the wsdl, but simply at variance w WS-I BP. While it may be claimed that the WSDL in appendices is non-normative, this particular WSDL in this particular Appendix is referenced quite prominently in section 1.4 of WS-Trust 1.3 (and 1.4) lines 57-62, which implies to me at least, that it is being regarded by the spec as more than "just a sample". This issue came up as a result of organized activity (wstf) attempting to build interoperability scenarios as mentioned in the original issue. While engaging in this process there were reports that this WSDL caused code generation to fail. Considering the fact that the STS is emerging as such a highly visible web service it seems to me that if the WSDL describing that service is non-conformant to WS-I BP, that the document should at least address this issue in a manner that implementors can feel free to proceed without concern about this apparent conflict. Thanks, Rich Revised issue wording: PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred. Protocol: ws-trust ws-trust-1.4-spec-ed-03: p 79, Appendix B, lines 3177,3184,3188; 3204,3208 http://www.oasis-open.org/committees/download.php/28255/ws-trust-1.4-spec-ed-03.doc the problem described here also relates to these ws-trust 1.3 documents ws-trust-1.3-os: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf wsdl: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.wsdl Artifact: wsdl Type: editorial Title: Sample wsdl in conflict w WS-I BP Description: ws-trust-1.4-spec-ed-03: p 79, Appendix B, lines 3177,3184,3188; 3204,3208 It was found during preparation of use cases for the web services test forum (wstf) committee: http://www.wstf.org/ (need to join to read archives, but if so, then issue was discussed here: http://www.wstf.org/mail/sc006/200805/msg1) that the sample wsdl in Appendix B appears to possibly have inadvertently included wsdl that is in conflict with WS/I BP 1.1: http://www.ws-i.org/Profiles/BasicProfile-1.1.html WS-I BP text: 4.7.6 Operation Signatures Definition: operation signature The profile defines the "operation signature" to be the fully qualified name of the child element of SOAP body of the SOAP input message described by an operation in a WSDL binding. In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement. An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique operation signature. R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another. Here is the wsdl for ref w problem lines marked by "<---***" on RHS: <!-- This portType models the full request/response the Security Token Service: --> <wsdl:portType name="WSSecurityRequestor"> <wsdl:operation name="SecurityTokenResponse"> <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/> <---*** </wsdl:operation> <wsdl:operation name="SecurityTokenResponse2"> <wsdl:input message="tns:RequestSecurityTokenResponseCollectionMsg"/> </wsdl:operation> <wsdl:operation name="Challenge"> <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/> <---*** <wsdl:output message="tns:RequestSecurityTokenResponseMsg"/> </wsdl:operation> <wsdl:operation name="Challenge2"> <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/> <---*** <wsdl:output message="tns:RequestSecurityTokenResponseCollectionMsg"/> </wsdl:operation> </wsdl:portType> <!-- These portTypes model the individual message exchanges --> <wsdl:portType name="SecurityTokenRequestService"> <wsdl:operation name="RequestSecurityToken"> <wsdl:input message="tns:RequestSecurityTokenMsg"/> </wsdl:operation> </wsdl:portType> <wsdl:portType name="SecurityTokenService"> <wsdl:operation name="RequestSecurityToken"> <wsdl:input message="tns:RequestSecurityTokenMsg"/> <---*** <wsdl:output message="tns:RequestSecurityTokenResponseMsg"/> </wsdl:operation> <wsdl:operation name="RequestSecurityToken2"> <wsdl:input message="tns:RequestSecurityTokenMsg"/> <---*** <wsdl:output message="tns:RequestSecurityTokenResponseCollectionMsg"/> </wsdl:operation> </wsdl:portType> </wsdl:definitions> The problem with violating this convention is that if you try to do automatic code generation, in at least one popular implementation language you cannot have 2 methods in the same class with the same signature, which is what happens with these identical input messages. Related issues: N/A Proposed Resolution: None: Not sure what would be intended here, because the example is showing messages to an STS, which can reply with different responses for output w same input. However, as shown the methods violate the WS-I guidelines. (appears that concept of in/out "signature" may be overloaded here as there is both input/output at the message-in/message-out level as well as creation of input message level) Anthony Nadalin wrote: OF79390EDE.D9822ED4-ON8625745C.004BF006-8625745D.00457659@us.ibm.com" type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]