Title: RE: wrapped services
Yes and no. The normal programming model for .NET is an RPC-style invocation -- and that's regardless of whether the message is formatted using doc/literal or rpc/encoded. The really important thing to grok here is that the application program really shouldn't be concerned with whether it uses doc/literal or rpc/encoded. The SOAP runtime is responsible for marshalling and unmarshalling the messages, so it handles the process of creating doc/literal or rpc/encoding messages. From the service agent developer's point of view, all he needs to do is choose one versus the other (and based on WS-I BP, the developer should choose doc/literal). The SOAP runtime should do the rest.
 
As I said, the .NET parameterStyle attribute tells .NET how to generate the <types> section of the WSDL document when it's generating the WSDL from the service code. My recommendation is NEVER use "bare". Always use "wrapped". Most SOAP implementations don't know how to deal with multiple child elements of the soap:body -- and "bare" generates a different child element for each paramater, so "bare" will definitely cause interop problems.
 
Frameworks like Axis don't need to be concerned with what goes on inside .NET. They just need to properly interpret the WSDL file. As long as it generates a SOAP message that corresponds to the WSDL input message it should work.
 
Anne
----- Original Message -----
Sent: Wednesday, July 30, 2003 1:11 PM
Subject: RE: wrapped services

So the "wrapped" style is intended to emulate RPC over doc/literal -- no?  And, frameworks like Axis have to work off assumptions that the data coming in will not only be a complexType, but also have a name == "parameters"?
 
Cory
-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 12:06 PM
To: [EMAIL PROTECTED]
Subject: Re: wrapped services

You might find this link a little more enlightening:
 
.NET supports two ways to generate the schema for doc/literal messages:
- bare
- wrapped
 
In bare, the generated <types> definition contains a different element for each .NET method parameter, so that the resulting SOAP message would look something like this:
<soap:body>
  <ns1:param1 xmlns:ns1="someuri">param1</ns1:param1/>
  <ns1:param2 xmlns:ns1="someuri">param2</ns1:param2>
</soap:body>
 
This format is not WS-I BP compliant. WS-I BP permits only one direct child element of the <soap:body> element.
 
In wrapped (the default), the generated <types> definition contains a single element (a complex type) that contains subelements for each .NET method parameter, so that the resulting SOAP message would look something like this:
<soap:body>
  <ns1:input xmlns:ns1="someuri">
     <ns1:param1>param1</ns1:param1>
     <ns1:param2>param2</ns1:param2>
  </ns1:input>
</soap:body>
 
In both cases there's a schema for the input message.
 
But keep in mind that wrapped versus bare applies only to generation of the service. For clients, .NET will generate a SOAP message that conforms to specification defined in the service's WSDL file. If you're using doc/literal, the .NET wsdl.exe tool will read the schema definition in the <types> section and construct the message accordingly.
 
Anne
 
----- Original Message -----
Sent: Wednesday, July 30, 2003 12:08 PM
Subject: RE: wrapped services

Davanum Srinivas [mailto:[EMAIL PROTECTED]] wrote:

> Not really - http://msdn.microsoft.com/library/default.asp?url="">

Okay, I read it, but I don't understand what it means.  "Wrapped" is the default.  And that means, "Parameters sent to and from an XML Web service method are encapsulated within a single XML element followig the Body element of the XML portion of a SOAP request or SOAP response."

Within a single XML element?  It's going to send everything as attributes rather than nested elements??

Google has not yet turned up an example of what a SOAP request coming from ASP under .NET looks like by default.  All I want is some sample ASP code and the resulting outgoing SOAP message.  Surely it's out there somewhere...

--
Wendy Smoak
Applications Systems Analyst, Sr.
Arizona State University, PA, IRM

Reply via email to