Steve
Maine's post on "single-parameter service interfaces" - and the
assertion that such interfaces are more in keeping with the SOA theme - got me
thinking just a bit about the real relationship between [WebMethod] methods and
the associated WSDL.

Recall that WSDL port types consist
of operations that define (at most) an input message and an output
message. WSDL messages consist of "parts" - and for
literal formatting with “wrapped“ parameter style (the default for
ASMX), you will have a single "part". The part in turn refers to an
XML schema-defined element. (Here is a concrete
example to look at.)

Notice that at this point, we haven't said anything about whether a) we have
multiple parameters to our service interface, with a mapping between those
parameters and child elements in the WSDL-referenced schema or b) we have a
single (xml document) parameter to our service interface that is expected to
conform to the WSDL-referenced schema (or for that matter, a single parameter
consisting of a serializable class.)

But the WSDL operation definition is quite clear - there is only one
message associated with each of the potential directions (input, output, and
fault.) The operation definition doesn't care whether the underlying code
that supplies implementation shreds the associated schema types to and from
method parameters!

And in an important way, it doesn’t matter. From the client's
perspective, I can submit an xml document (or serialized object) to an
operation defined on a port type, as long as that xml document conforms to the
associated schema. The client isn't forced to take a parameter-oriented
view of a web service interface regardless of whether or not the server
implementation is "parameterized". Likewise, from the server's
perspective, a web service interface could be implemented with consumption of
(compliant) xml documents - without forcing that view on the client (who might
very well prefer a parameter-style proxy to be generated from WSDL.)

This point remains true even if I was using “bare“ parameter style (i.e.
if I had multiple message parts) or if I was using RPC formatting (i.e. if I
had a parent element for my parameters named after the web service method.)

Of course, your philosophical bent will lead you to either the
WSDL-first path (for the document view) or the ASMX
path-of-least-resistance (for the parameter view.)

And, handling the open content case that
Steve discussed is only possible with a document-oriented
approach. (XmlAnyElementAttribute
could assist with the case where you want to rely on serialized/deserialized
objects to stand in for raw xml documents.)

Note that the parameterized view exhibits some aspects of being a
leaky abstraction. SOAP 1.1 allows for missing values
("Applications MAY process requests with missing parameters but also MAY return
a fault.") - and so does the XmlSerializer. This means that you can
wind up with malformed requests, and not know it. (Is your service really
going to be ok with treating missing parameters the same as freshly initialized
data types?) Since ASMX offers no schema validation by default, you
really need to rely on a
schema-validation SoapExtension to solve this problem.