L'8 di agosto è stata pubblicata la versione definitiva del "Basic Profile" WS-I. Si tratta del primo documento che definisce le regole "uniche" per garantire interoperabilità fra i differenti servizi. Finalmente si è arrivati ad una decisione molto importante, secondo me la più importante, e cioè dare una risposta alla classica domanda: RPC/encoded o document/literal ?

Tanto per ricordare che cosa significano, riprendo i concetti definiti nella specifica WSDL 1.1

"If use is encoded, then each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by the encodingStyle attribute. The part names, types and value of the namespace attribute are all inputs to the encoding, although the namespace attribute only applies to content not explicitly defined by the abstract types. If the referenced encoding style allows variations in it’s format (such as the SOAP encoding does), then all variations MUST be supported ("reader makes right").

If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style)."

In parole povere con la codifica encoded non possiamo usare un bel Dataset come parametro, con la literal si.

La risposta sta nel punto 5.6 della specifica ed esattamente nello statement R2705, che dice:

R2705 A wsdl:binding in a DESCRIPTION MUST use either be a rpc-literal binding or a document-literal binding.

Per gli sviluppatori ASP.NET questa non può essere che una buona notizia, dato che è il default ;-)