I think I heard general agreement on removing the WSDL from the
doc. I’ll get a draft together that shows that before the next call.
After thinking about the points made on the call for this issue I
have some thoughts on what’s confusing here. I’l collect those
thoughts up and get something back to the list by early next week.
From: Greg Carpenter
Sent: Friday, June 06, 2008 11:57 AM
To: Anthony Nadalin; Rich.Levinson
Cc: Geoff Bullen; Marc Goodner; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue 169: Sample wsdl in conflict w WS-I BP in
WS-Trust 1.3, 1.4
+1
The WSDL is just a sample. As it seems to be a
source of confusion, I propose to remove the references to sample
WSDL from the spec as follows.
(1) Section
1.4 Schema and WSDL – drop WSDL from section name and remove the
reference to the WSDL appendix and the reference to the WSDL description
in the namespace
(2) Section
1.8 Conformance – remove any mention of WSDL from the third
paragraph
(3) Section
3 – remove the sentence “These elements are passed as
the payload of specific WSDL ports …” from the
second paragraph
(4) Remove
Appendix B
Thanks,
-greg
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Tuesday, June 03, 2008 10:28 PM
To: Rich.Levinson
Cc: Geoff Bullen; Marc Goodner; ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue 169: Sample wsdl in conflict w WS-I BP in
WS-Trust 1.3, 1.4
In the appendix B it states:
"The WSDL below does not
fully capture all the possible message exchange patterns, but captures the
typical message exchange pattern as described in this document." So this
seems to indicate a sample.
I think that it should refer
to BP 1.2
I think that folks will
create WSDL in a BP 1.x compliant way if that is what they want, but some folks
won't care and other folks won't use WSDL.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Rich.Levinson" ---06/03/2008 08:39:39 PM---Hi
Tony,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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:
It
seems that we already discussed this issue on the call last week relative to
the WSDL with the problems found when getting ready to publish latest drafts.
The WSDL is (1) non-normative and is (2) ONLY a sample and (3) not all the
services described in the specification are in the WSDL and (4) nothing says
WSDL MUST be BP compliant. I not sure that you used the right BP level profile
(so that the actions are covered) also to do you analysis, also I think that
forgot about the SOAP actions that we have on the different requests and the
fact that all messages now end with a RSTRC (not an RSTR).
At the last call we took a action item to look at the WSDL and figure out which
messages we were going to describe as samples and in what format.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Geoff Bullen ---05/31/2008 02:24:13
PM---Issue 169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Issue 169
From:
Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Friday, May 30, 2008 5:25 PM
To: ws-sx@lists.oasis-open.org
Cc:
Marc Goodne
Subject: [ws-sx] NEW Issue: Sample wsdl in conflict w WS-I BSP in WS-Trust
1.3, 1.4
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 BSP
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:
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html
WS-I BS text:
5.6.7 Wire Signatures for Operations
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 wire signature.
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in wire
signatures that are different from one another.
The Profile defines the "wire signature" of an operation in a
wsdl:binding to be the fully qualified name of the child element of the
soap:Body of the SOAP input message it describes. For the case of an empty
soap:Body this name is an empty string.
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.
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)