I’ve posted this question here. but didnt get any answers. So I’m posting it here as well.
I’ve a question on the WSDL.
I’ve a WSDL that has two methods as below:
<portType name="TestService">
<operation name="add">
<input
wsam:Action="http://service.psvm.com/testservice/TestService/addRequest"
message="tns:add"
name="InputNums" />
<output
wsam:Action="http://service.psvm.com/testservice/TestService/addResponse"
message="tns:addResponse"
name="Result" />
</operation>
<operation name="subtract">
<input
wsam:Action="http://service.psvm.com/testservice/TestService/subtractRequest"
message="tns:subtract"
name="InputNums" />
<output
wsam:Action="http://service.psvm.com/testservice/TestService/subtractResponse"
message="tns:subtractResponse"
name="Result" />
</operation>
</portType>
As you can see, both the operations add and subtract have input & output messages with the same names “InputNums” and “Result” respectively.
When I try to validate this WSDL, I get the following error:
The name ‘InputNums’ specified for this input element is not unique.
The name of an input element must be unique from the names of all
other input and output elements defined in the ‘TestService’ port
type.
I’ve read the WSDL spec here which doesn’t give the reasons clearly(at least to me). It says:
The name attribute of the input and output elements provides a unique
name among all input and output elements within the enclosing port
type. In order to avoid having to name each input and output element
within an operation, WSDL provides some default values based on the
operation name.
In order to avoid naming each input/output elements, WSDL provides defaults. But why is that a RULE? Shouldn’t it be a warning?
Can’t the developer provide the names by him/herself if he/she wants to?
Further, I don’t understand why this is a problem, since when the clients invoke the web service, they invoke with specific operation names called ‘add’ or ‘subtract’.
My question finally is – As long as the operation names are different why should the parameter names matter?
Can some one please explain the consequences of having the WSDL like this, if any ?
I think that a better answer might come if you would describe
why not?. What does it do to you if instead you stick with the defaults? And if you want to name them, why not follow the rule?This is not to say that you are not somewhat right. In fact, WSDL 2.0 dropped this attribute entirely. So I guess that people working on the spec didn’t find any evidence in the implementations based on the 1.1 note indicating any practical use of this rule; so in that spirit, they’ve dropped it, along with the attribute. I am pretty sure that these names have no use even with RPC style bindings.
I could see why, in the early days, someone would put this rule: it is consistent with the rest of the rules for names; and I guess it was argued that subsequent binding specs may find some use for these names being unique.
If someone would argue my point by asking why it wasn’t enforced in the XSD for WSDL 1.1, same as other name rules, I would answer that XSD cannot express this constraint (since it is across two different selectors that could match at the same time).
I really think it is important why do you care. All tools that I tested (.NET and JAX-WS) don’t really mind it: they’re able to do their contract-to-code bindings. WS-I BP 1.x and 2.x doesn’t seem to even address it. All of this and seeing WSDL 2.0 dropped it all together, tells you that you are right, it is/was useless.
I also know tools that will not validate a WSDL such as yours; on the other hand, .NET won’t even squeak.
Nonetheless, if you care about a validation result that’s picky beyond being practical, then you’ll just have to stick with the rule… or ignore it.