http://www.community.borland.com/article/borcon/files/4132/paper/4132.html
RPC|Encoded vs. Document|Literal
The biggest problem in interoperability is the fact that some servers use Document|Literal encoding, which most others use RPC|Encoded. Delphi servers only understand RPC|Encoded packages, but Delphi Clients can talk to both RPC|Encoded and Document|Literal servers.
To communicate with a Doc|Lit server (Most .NET web services are doc|lit) you must set HTTPRio1.Converter.Options.soLiteralParams to true. This ensures that parameters encoded with "literal" are not unwound, which is necessary in doc|lit cases where a parameter name might be encapsulated under a sub tag under the XML element representing the function.
In Delphi 7, Document encoding is supported in one way - you can make Delphi 7 client applications (consumers) for Document based webservices. What you cannot do is write Document based servers. If you're writing a client for a document based server, you can import the WSDL and Delphi's WSDL Importer will recognize that this is a document based server and generate necessary code for the conversion. FOr instance it will add the following call to the initialization section of your imported .pas file:
InvRegistry.RegisterInvokeOptions(TypeInfo(DataServiceSoap), ioDocument);
This ensures that an Invoke call that uses the interface DataServiceSoap will be formatted using Document rules (not RPC). You can also use ioLiteral for doc-lit services. Using ioLiteral also ensures that your input and output types won't be "unwound" - this needs some explanation. In RPC encoding, each method call is preceded by a method node in the XML datapacket. In Literal encoding, the method name is skipped and the parameters are unwound into XML. This and many small differences are actually handled directly by the Delphi SOAP runtime itself, so you don't have to worry about them individually. But, use a proxy server to actually find out what's happening behind the scenes in case there's a problem.