O in altre parole, se questo è il problema:
We have a big problem concerning the use of Web Services (J2EE platform) written with the RPC/literal mode.
Inside the document “Building Interoperable Web Services – WS-I Basic Profile 1.0”, I read:
“The Basic Profile allows WSDL descriptions to have RPC-Literal bindings. However, the Add Web Reference wizard in Visual Studio.NET does not support WSDL descriptions with RPC-Literal bindings. ……Alternatively, you can edit the WSDL description to convert it to a Document-Literal binding….”
It seams that the only way to use that such web services is to write manually the proxy. (That is what we did)
Even the WSDL.exe or the R2D.exe (based on the wsdl.exe) does not work with efficiency.
Questa potrebbe essere la soluzione:
I had the very same problem a half a year ago.
Instead of creating the proxy manually, I've changed the wsdl file: RPC/Literal is a subset of Document/Literal, therefore every RPC/literal message can be constructed using an Document/Literal proxy. By changing the bindings to the corresponding Document/Literal bindings allows you to use wsdl.exe for generating the proxies.
Potrebbe essere utile leggere questo articolo:
There are two popular programming models for Web services today: RPC and messaging. The WSDL 1.1 specification unnecessarily defines two SOAP message styles, RPC and document, that supposedly correspond to the two programming models. I say unnecessarily because the correlation between programming model and message format is entirely artificial. For example, I can use an RPC programming model to send and receive document-style messages. In fact, Microsoft® .NET-based Web services (.asmx) does exactly that by default. I can also directly send an RPC-style SOAP message using some XML API (e.g. DOM or XmlReader) and then dispatch the received response message to some other routine to process it.
Despite this, there's a strong tendency among tools vendors to infer the programming model from the message format defined in the service's WSDL. I can certainly understand using the message format as a hint for the suggested programming model, but it's a mistake to use it to dictate the programming model. As a Web service consumer, I certainly don't want the service to dictate the programming model I use. Rather, I want the freedom to choose whatever platform, language, and programming model to invoke that service. Tools vendors need to realize that consumer (client) developers are capable of choosing the programming model independent of what service developers recommend.
The rest of this article explains the two SOAP message formats and shows how WSDL describes these formats. It also explains why only one message format is needed and suggests decoupling the programming model from the message format.
Qui trovate il resto: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/rpc_literal.asp
posted @ martedì 4 maggio 2004 21:34