Con l'occasione dello speciale sul .NET Framework 3.5 vorrei scrivere alcune considerazioni che ho in testa da diverso tempo, nella fattispecie sugli aggiornamenti a WCF introdotti in questa versione.

Più o meno all'inizio di quest'anno, sui blog di illustri tecnici del settore SOA (Don Box, Steve Maine, Nicholas Allen ed altri), si è acceso uno scambio di messaggi su REST (REpresentational State Transfer) e parallelamente su POX (Plain Old Xml) e JSON (JavaScript Object Notation).

Per completezza del discorso, mi permetto di descrivere REST come un protocollo di scambio dati di alto livello, basato sulla distribuzione delle risorse di una applicazione attraverso richieste http su URI univoco, ad esempio: http://IP/Application/Customer/ => per una lista di clienti e http://IP/Application/Customer/1 => per i dettagli dell'oggetto Customer con ID = 1.
Studiato essenzialmente per un ambito http, REST si appoggia agevolmente ad una rappresentazione dei dati in semplice XML, da esso il legame con POX.

Devo dire che le discussioni su REST mi hanno lasciato letteralmente basito. Per anni non si è fatto che ascoltare di SOAP prima ancora dei webservice di asp.net , e sembrava che il vangelo delle applicazioni distribuite fosse già stato scritto in SOAP.
Inoltre Microsoft,e secondo me con coerenza, ha rilasciato un Foundation apposito (WCF) che riassume tutte le proprie tecnologie di integrazione, creando un flessibile modello ad oggetti su cui letteralmente "gettare le Fondamenta" delle applizioni SOA, appoggiandosi su SOAP ed implementando tutti gli standard WS-* che negli anni erano stati introdotti.
Ho intuito subito che WCF fosse un grande "prodotto", occupandosi degli aspetti di comunicazione di medio livello ed essendo sviluppato con una incredibile flessibilità: veramente un punto di partenza per poter pensare di introdurre nei progetti reali, soprattutto in quelli a medio costo, un approccio service-oriented o comunque per dare una apertura alla interoperabilità verso altre applicazioni, per aggiungere qualità ai progetti.
Parallelamente ho visto anche che il modo JAVA si sta muovendo con buon interesse verso WCF aumentando il mio entusiasmo, perchè adottare, studiare ma soprattutto proporre ai clienti una soluzione che si basa su un Framework che ha buone prospettive di crescita e diffusione qualifica le mie scelte e la mia credibilità.

Ed invece ho letto con stupore che i tecnici con esperienza hanno bisogno ancora di REST, di XML Plain, e che tra l'altro il nuovo paradigma delle webapplication, AJAX, basandosi su javascript sfrutta addirittura la rappresentazione dei dati JSON.
Mi è sembrato veramente un passo indietro e mi è venuto qualche dubbio, allora Microsoft è stata troppo precoce nell'introdurre il modello di WCF, o per lo meno, allora è troppo presto adottarlo?

Approfondendo lo studio di WCF ho compreso che la flessibiltità del framework consente un ambito applicativo senza limiti, dalla "reliability" al semplice scambio di stringhe, consolidando quindi la mia intuizione sulla qualità del Foundation e verso una sua indubbia adozione.

L'introduzione di alcune caratteristiche che vedo nelle CTP del Framework 3.5 mi confortano sulla qualità del comportamento di Microsoft, che risponde alle esigenze del mercato degli sviluppatori, ma non diminuiscono i mei dubbi.
Mi riferisco a "WebHttpBinding" , un nuovo binding con caratteristiche studiate appositamente per l'impiego negli ambiti che ho citato precedentemente, REST, AJAX/JSON con il relativo nuovo "DataContractJsonSerializer"; per inciso WCF consente già un impiego REST sotto configurazione di un customBindig e scrivendo un paio di classi per manipolare le richieste e le URI , ma è comunque interessante che Microsoft sia intervenuta su questa esigenza rilasciando un aggiornamento specifico per questo tipo di scenari oggetto di tante discussioni.

Ed infatti la mia riflessione si amplifica anche in virtù di questo comportamento di Microsoft: se in WCF hanno pianificato la strada dell'integrazione tra applicazioni, e potrei dire per semplificare, attraverso classi proxy, per quale motivo stanno dando così risalto ad un "modello" di livello inferiore, in cui si deve ancora controllare le URI (spezzettarle,validarle), intercettare i messaggi, validare i dati scambiati, ecc.?

La mia piccola risposta imputa proprio alle ragioni di "mercato", forse per evitare quel giudizio e quell'accusa di forzare gli standard di fatto che molto spesso viene fatta a Microsoft; scambiandosi JSON , in fondo, tutti sono più tranquilli...

Buon lavoro a tutti.

p.s. curiosa la classe SyndicationFeed , un figlio di REST che consente la pubblicazione di dati automaticamente nel formato rss e atom.