2014-04-17 6 views
7

Ho ereditato alcuni servizi Web che sono WSDL generati da ColdFusion 9. Il default CF9 è codificato RPC, quindi è quello che sono. Tuttavia, recentemente ho notato che le nuove versioni del framework .NET (o forse le versioni più recenti di Visual Studio) non amano i WSDL con codifica RPC. Nel test (in C#), ho verificato che VS 2013 consumava correttamente il servizio solo quando era nello stile letterale del documento.Quali sono le ripercussioni della modifica di un servizio Web WSDL generato da ColdFusion da RPC-encoded a document-literal?

Sono ovviamente aperto a cambiare lo stile per essere più universalmente utilizzabile, ma questo servizio Web è stato in circolazione per qualche tempo (ed è utilizzato da un numero di persone, ne sono sicuro), quindi voglio assicurarmi di avere una soluzione su quali potrebbero essere le possibili ripercussioni. Mi chiedo anche se è possibile ottenere ColdFusion per generare due diversi WSDL (o consentire l'impostazione della codifica al volo?). Fondamentalmente mi piacerebbe qualche consiglio sul modo migliore per rendere questo compatibile (pur mantenendo la compatibilità con le versioni precedenti). Grazie.

+0

Hai già letto qualche documentazione? http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-78a6.html – fyroc

+1

A meno che non manchi qualcosa da quella documentazione (che ho letto, oh, otto volte), si tratta di come generare il WSDL, che non è una mia domanda. La mia domanda riguarda il cambiamento dello stile di un WSDL esistente (e le ripercussioni di ciò). –

+0

Mi stavo solo chiedendo e dandoti un inizio poiché non c'erano ancora risposte. Non è stato pensato per essere una risposta o lo avrei postato come risposta. Dispiace per la confusione. – fyroc

risposta

0

Se si dispone di un secondo URL per il servizio Web in stile letterale del documento, è possibile estendere il proprio CFC esistente. Il tuo nuovo CFC avrebbe tutte le stesse funzioni e la stessa logica del servizio web principale. Eviterebbe anche un Non ci sarebbe nessun codice aggiuntivo da mantenere. L'unico sconosciuto per me è se questo creerà un sovraccarico aggiuntivo significativo.

<cfcomponent extends="yourExistingCFC" style="document" output="false"></cfcomponent> 

ho fatto provare a impostare il tipo di documento per documentare letterale in uno dei miei servizi web di test. SoapUI non è stato in grado di analizzare il WSDL letterale del documento una volta modificato, ma è possibile farlo con Visual Studio. Da questo, sarei restio a cambiare lo stile del documento del tuo CFC esistente, perché non puoi dire come tutti gli ambienti client gestiranno il cambiamento.

+0

Ah, intelligente. Ci proverò. E grazie per il test - il problema SoapUI è esattamente il motivo per cui ero esitante a cambiare il tipo. –

+0

Ho fatto come suggerito e sembra generare un documento WSDL letterale valido che viene utilizzato correttamente da Visual Studio. Sfortunatamente, però, genera un errore org.xml.sax.SAXParseException: Fine prematura del file quando effettivamente utilizzato. Ho testato e ricevuto lo stesso errore sia in C# che in ColdFusion. Tuttavia, se cambio il componente originale in stile letterale e copi il WSDL risultante in un file statico, aggiorna il componente esteso in modo che punti a quel file statico (con l'attributo 'wsdlfile') invece di generarlo automaticamente, lavori. Qualche idea su cosa sta succedendo? –

+0

Con il proprio WSDL statico il collegamento punta ancora al file del servizio Web esistente. Finché il sapone generato inviato da e verso il server ha lo stesso aspetto, non importa se il WSDL proviene. Non ero in grado di testare completamente il mio suggerimento prima di suggerirlo. Non sono sicuro perché le richieste fatte a un servizio esteso fallirebbero. – Twillen

Problemi correlati