Incoerenza SOAP? Delphi 2010 (Win32) Server e Client .NET che sostituiscono 'out-parameter' e 'result'

Question

Qualcuno potrebbe far luce su questo comportamento? Sembra che Delphi SOAP imposti il ​​risultato della funzione come ultimo argomento, ma WSDL.exe legge il primo argomento come risultato della funzione.

Ho la seguente metodo in un servizio SOAP Delphi, in cui viene utilizzata la stringa risultato per la gestione degli errori di base:

function LoadCustomer(CustomerID: Double; out CustomerName: String): String; 

Il WSDL generato è simile al seguente:

<message name="LoadCustomer2Request"> 
    <part name="CustomerID" type="xs:double"/> 
</message> 
<message name="LoadCustomer2Response"> 
    <part name="CustomerName" type="xs:string"/> 
    <part name="return" type="xs:string"/> 
</message> 

Per qualche ragione , WSDL.exe genera il seguente codice C# che scambia le stringhe CustomerName e 'Result':

public string LoadCustomer(double CustomerID, out string @return) { 
     WindowsFormsApplication1.ServiceReference1.LoadCustomerRequest inValue = new WindowsFormsApplication1.ServiceReference1.LoadCustomerRequest(); 
     inValue.CustomerID = CustomerID; 
     WindowsFormsApplication1.ServiceReference1.LoadCustomerResponse retVal = ((WindowsFormsApplication1.ServiceReference1.ISKiWebInterface)(this)).LoadCustomer(inValue); 
     @return = retVal.@return; 
     return retVal.CustomerName; 
    } 

Answer 1

Quando SOAP era prevalentemente basato su problemi rpc, questi problemi venivano spesso. Non esiste un ordine specifico per determinare quale parte è il risultato della funzione (operazione). L'importatore di Delphi usato per [e probabilmente lo fa ancora ??] identifica il 'risultato' con il nome della parte. E potresti (può ??) specificare un elenco di nomi delimitati da virgole da usare. Se nessuna delle parti corrisponde ai nomi, se c'è una sola uscita, è il risultato.

La specifica SOAP. alla fine includeva aggiunte per risolvere questo problema. Quello pertinente nel tuo caso è l'attributo 'parameterOrder' (c'è anche rpc: risultato per i dati SOAP effettivi). Tuttavia, difficilmente si vedono WSDL che utilizzano l'attributo. Ma, credo che WSDL.EXE presta attenzione a quell'attributo. Potete trovare ulteriori informazioni su parameterOrder qui:

http://www.w3.org/TR/wsdl#_parameter

Quello che vorrei suggerire di fare è quello di salvare il WSDL generato da Delphi in un file; e aggiorna il più tardi per includere l'attributo parameterOrder (*). Per esempio, nel caso che hai fornito, ti consigliamo di trovare il portType che mappa l'interfaccia e aggiornare l'operazione come segue:

<portType name="InterfaceName"> 
    <operation name="LoadCustomer" parameterOrder="CustomerId, CustomerName"> 
     <input message="tns:LoadCustomer2Request"/> 
     <output message="tns:LoadCustomer2Response"/> 
    </operation> 
    </portType> 

Poi, l'importazione che WSDL aggiornato con WSDL.exe dovrebbe darvi qualcosa lungo le linee di:

public string LoadCustomer(out string CustomerName, double CustomerID) { 
    object[] results = this.Invoke("LoadCustomer", new object[] { 
       CustomerID}); 
    CustomerName = ((string)(results[1])); 
    return ((string)(results[0])); 
    } 

si dovrebbe anche vedere il seguente attributo sopra il metodo per confermare che 'ritorno' è il risultato infatti:

[return: System.Xml.Serialization.SoapElementAttribute("return")] 

vorrei sug Gestiamo un QC che richiede che il parametroOrder sia generato dalla logica WSDL di Delphi.

Acclamazioni,

Bruneau

PS: (*) E 'anche facile per aggiornare la logica di generazione WSDL per emettere parameterOrder. E 'stato un tempo moooolto da quando sono stato in quel codice ma è abbastanza semplice (se non ricordo male :)