views:

815

answers:

2

I'm trying to build a webservice with ASP that will be given three parameters: a string, a date/time and another string. After making the method, the wsdl contains this:

<s:element name="TimesheetAudit">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="employeeNumber" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="periodEndDate" type="s:dateTime"/>
<s:element minOccurs="0" maxOccurs="1" name="timesheet" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>

The black box calling my web service is complaining that there is a mismatch in the number of parameters. I am assuming this is because my webmethod is technically taking 1 parameter, a complex type, instead of three.

Is this the problem? If so, what can I do to overcome it?

Edit: The consumer is the black box in this case, I must mold my web service to match the caller. Adding

[SoapDocumentMethod(ParameterStyle = SoapParameterStyle.Bare)]
to my method signature gives the following error:
' does not conform to WS-I Basic Profile v1.1. Please examine each of the normative statement violations below. To turn off conformance check set the ConformanceClaims property on corresponding WebServiceBinding attribute to WsiClaims.None.
R2204: A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute. 
  -  Part 'input' of message 'TimesheetAuditSoapIn' from service description with targetNamespace='http://www.netdes.com/'.
  -  Part 'TimesheetAuditResult' of message 'TimesheetAuditSoapOut' from service description with targetNamespace='http://www.netdes.com/'.

+1  A: 

It is difficult to be sure without more information about what exactly the client is expecting, but it could be a parameter style issue.

By default, an ASP.NET web service uses the "Wrapped" parameter style, which means that all of the parameters get wrapped in a single element that is sent inside the SOAP body.

You can change the method declaration to use the "Bare" parameter style, which puts all the parameters directly inside the SOAP body, without a wrapper element. This is achieved via the ParameterStyle property on the SoapDocumentMethodAttribute on the web method.

See this MSDN entry for details.


In response to conformance error: You can disable WS-I conformance checking by putting the following in your web.config:

<configuration>
  <system.web>
    <webServices>
      <conformanceWarnings>
        <remove name='BasicProfile1_1'/>
      </conformanceWarnings>
    </webServices>
  </system.web>
</configuration>

Conformance is normally a good thing, but it's not required. Since you aren't in control of the definition in this case, you don't have much of a choice.

It is also possible that the client is expecting an RPC-style web service instead of a document-style web service. (This would be controlled with a SoapRpcMethodAttribute instead of a SoapDocumentMethodAttribute.) If you still have no luck after turning off the conformance warning you might try changing to RPC-style and see if that works.

And if there's any way you can get a definition (either source or, better yet, a WSDL used to produce the source) for the client so that you can tell what exactly it's expecting, it would help. If you can get a WSDL you can have .NET generate the web service method for you in the correct format.

Eric Rosenberger
A: 

It sounds like you're the one building the web service host, so you get to run the show, right?

If you can launch Visual Studio, click File, New Website, add a web service to it, use the auto-generated WSDL and successfully connect to it from a test harness, then the consumer of that web service ought to be able to read that same WSDL and connect to it as well as you. The important thing is that you have a test harness that works.

If that's the case, then the black box problem lies on their end of the wire, not yours.

AndrewDotHay