2009-10-23 13 views
5

Ho lavorato per creare servizi WCF che funzioneranno indipendentemente dai client .Net. Grazie a Google e StackOverflow, sono stato in grado di creare sia semplici servizi xml che json senza wapter di Soap e un mucchio di cose WCF fantasiose che non mi servono. È stata un'esperienza dolorosa, quindi l'argomento di questa domanda. WCF è pazzo buggy sul lato client quando si utilizza WebGet e WebInvoke quando si aggiunge automaticamente il riferimento del servizio.Il client WCF (Aggiungi riferimento al servizio) odia WebGet e WebInvoke ... davvero, lo fa

Per controllare la comunicazione, sto creando un client WCF localmente e passando tutto attraverso Fiddler. In questo modo, che funzioni o meno, posso almeno vedere cosa sta cercando di inviare il client. E quando finalmente funziona, posso vedere i dati inviati da entrambe le estremità e quindi duplicare questa comunicazione in un client non- .Net.

Il mio problema attuale è che quando cambio il servizio in attesa di dati POST come json (comportamento enableWebScript), il client non ne ha idea, e tenta comunque di inviare gli oggetti come xml. Ho avuto un sacco di problemi con la configurazione del client che non viene automaticamente impostata correttamente quando si utilizza Aggiungi riferimento al servizio, quindi spero che sia qualcosa di semplice che posso aggiungere a app.config sul client. Quando si utilizza XML, gli oggetti che creo e utilizzo nel servizio sono automaticamente serializzati da xml dal client (che è più conveniente). È anche possibile fare come json nella versione attuale di WCF?

Si noti che sono riuscito a capire cosa devo fare manualmente e farlo funzionare in modo raw con Fiddler (generatore di richieste), così posso serializzare i miei oggetti nel codice e inviare i dati manualmente tramite post http ... è così che lo faccio nei miei clienti non -.Net comunque. Questa è più una domanda per capire meglio gli aspetti della WCF e perché mi mancano così tanti attributi sul lato client, dove c'è poca o nessuna documentazione disponibile per affrontare i problemi.

+0

Man .. Vorrei che avessi letto prima. Abbiamo attraversato praticamente lo stesso identico processo di pensiero. Mi aspettavo che il client REST "funzionasse" come fa il client SOAP. –

+0

Sei legato a WCF o hai la possibilità di tecnologia payload server/servizio? Da quando ho postato questo oltre due anni fa, ho resistito all'utilizzo di WCF per qualsiasi cosa. Ogni servizio che creo o consumo manualmente costruisce dati leggeri xml e/o json e lancio la mia sicurezza e qualsiasi altra cosa che WCF abbia cercato di rendere più conveniente per lo sviluppo. Penso che sia praticamente impossibile trovare una popolare web public api esposta come servizio WCF – Rich

+0

No, non siamo legati a WCF ma penso che potremmo provarlo per uno dei nostri servizi. Costruire i componenti lato server usando WCF è stato doloroso finché non abbiamo capito tutto. Anche se ... è stato bello non dover costruire gli endpoint a mano (abbiamo SOAP/REST/JSON tutto funzionante).Ora, mi rendo conto che utilizzeremo SOAP solo se utilizziamo un client .NET e lasciamo che altri consumino REST/JSON. –

risposta

3

I riferimenti di servizio WCF sono per i payload RPC che si auto-descrivono, ad esempio SOAP, wsHttp ecc. Ugualmente i client con tipicità WCF sono concepiti per funzionare solo con i payload RPC perché solo sono in grado di trasmettere tutte le informazioni di tipo ecc. richiesto per farlo funzionare correttamente.

Quando si utilizza webget e webinvoke si creano servizi non rpc (destinati a scrivere servizi REST) ​​che non sono anch'essi auto-descrittivi e pertanto non sono ideali per la funzionalità di riferimento del servizio.

È possibile scrivere un client .Net per questo, ma è molto più semplice scrivere su WebClient/WebRequest, formattare/leggere manualmente le richieste/risposte XML/Json (oppure utilizzare DataContractSerializer e DataContractJsonSerializer per dare una mano in questo).

1

SOAP è auto-descrittivo (tramite un WSDL).

WebGet/WebInvoke non espone alcun metadata che indicherebbe al client di utilizzare JSON anziché XML.

Problemi correlati