Con l'avvento di WCF, AJAX e Silverlight il .NET Framework negli ultimi anni si è arricchito di una serie di tecnologie specifiche per creare applicazioni web basate su servizi. Infatti queste tecnologie (WCF in primis) consentono non solo di creare l'insieme dei servizi lato server, ma anche e soprattutto forniscono il supporto necessario per realizzare i client in grado di invocare questi servizi.

Se da un lato AJAX propone un meccanismo di invocazione asincrona di funzionalità lato server, dall'altro Silverlight (come del resto anche Flash) rappresenta la tecnologia di riferimento per la realizzazione di applicazioni RIA (Rich Internet Application), in grado di elevare il livello di interazione utente, andando oltre i limiti imposti da HTTP. Dal momento che in entrambi i casi sia la logica applicativa che le regole di business rimangono ancora lato server, sempre più spesso diventa necessario strutturare le applicazioni web affinchè siano in grado di operare secondo una logica distribuita.

Questo articolo si propone di fornire una serie di indicazioni utili alla progettazione di applicazioni web basate su servizi. Partendo dalla definizione di servizio, vedremo come strutturare una service-based application, indipendentemente dal tipo di tecnologia utilizzata per la realizzazione del client. Andremo ad identificare i componenti primari che permettono di definire l'architettura di un'applicazione di questo tipo e, per ciascuno di essi, forniremo una serie di considerazioni e linee guida utili al disegno e allo sviluppo.

Cosa è un servizio

Quando si parla di servizi, la prima cosa che viene in mente sono i web service. In realtà il concetto di servizio sottointende qualcosa di valenza più generale, di cui i web service rappresentano semplicemente la casistica più conosciuta. Per dare una definizione, possiamo dire che un servizio è un'interfaccia pubblica che fornisce accesso ad una serie di funzionalità sulla rete. Come tale, un servizio è totalmente disaccoppiato dai suoi utilizzatori, dal momento che per un client esso rappresenta un'entità invocabile remotamente tramite lo scambio di messaggi. La comunicazione avviene in base ad un agreement esplicitato sotto forma di un contratto, all'interno del quale trovano spazio informazioni quali l'insieme delle operazioni invocabili, il tipo dei dati scambiati, i protocolli, ecc. Solitamente la definizione di questo contratto è contenuta in un documento pubblico in formato XML noto col nome di WSDL (Web Services Definition Language), utilizzato dai client per generare l'oggetto proxy di invocazione.

Come detto, un client interagisce con un servizio tramite lo scambio di messaggi, la cui forma dipende dal protocollo di comunicazione (HTTP, TCP, ecc.) e dalle tecnologie in gioco. Sostanzialmente il formato dei messaggi può essere o testuale o binario. Spesso esso è rappresentato da un documento XML formattato secondo una notazione comune come, per esempio, SOAP. In questi casi, essendo l'obiettivo primario l'interoperabilità, il ricorso ad uno standard condiviso tra client e servizio rappresenta una scelta obbligata. In altre situazioni, laddove è richiesta una maggiore efficienza nei meccanismi di comunicazione, privilegiando gli aspetti peculiari di una particolare tecnologia, la scelta ricade inevitabilmente su formati proprietari che possono garantire migliori performance.

Indipendentemente dal formato dei messaggi, dalla tipologia del canale di trasporto e dal contratto esposto, un servizio rappresenta sempre un'entità esterna rispetto al contesto del client che lo invoca (out-of-process). Client e servizio sono pertanto associati a processi separati, per lo più attivi in nodi fisici diversi. I due contesti sono tra loro disgiunti e ben distinti, lo stato interno dei processi e gli aspetti implementativi non sono condivisi. L'unico punto di contatto è rappresentato dal contratto esposto dal servizio.

Architettura di un'applicazione web basata su servizi

In generale una service-based application è un tipo di applicazione che espone una serie di funzionalità sotto forma di servizi secondo la definizione data nel paragrafo precedente. I dettagli implementativi e il contesto in cui questi servizi operano devono necessariamente rimanere sconosciuti ai client che li invocano. Le scelte architetturali che caratterizzano internamente un'applicazione di questo tipo non devono pertanto influenzare, vincolare o limitare le scelte di disegno dei client, qualunque essi siano (applicazioni RIA, AJAX od altro). Un discorso analogo vale anche in senso contrario. La coesistenza tra l'ambiente server e i diversi client è regolamentata unicamente dai contratti dei servizi esposti, dal momento che in essi sono contenute le informazioni utili a definire le logiche e i meccanismi di comunicazione ed interazione.

Al suo interno un'applicazione web basata su servizi può essere progettata secondo le logiche già note ed utilizzate per le applicazioni web layered in-process. Per quanto concerne l'ambito server, l'idea è ancora una volta quella di individuare una serie di livelli logici in cui condensare funzionalità omogenee. Tuttavia, rispetto ad un'applicazione web layered in-process, in una service-based application non esiste lo strato di presentazione lato server. Esso è sostituito dal cosiddetto Services Layer, destinato ad esporre i servizi e a contenere le relative interfacce (vedi figura 1).

Se ci pensiamo bene, questa differenza è giustificata dal fatto che in un'applicazione di questo tipo lo strato di presentazione in generale è rappresentato dal client che invoca i servizi esposti lato server. Nel caso delle applicazioni web esso può essere un'applicazione RIA realizzata con Silverlight o Flash o un'applicazione AJAX basata su qualche framework Javascript come jQuery e affini. Ciò che è evidente è che lo strato di presentazione è out-of-process rispetto al resto dell'applicazione ed è distribuito ed eseguito in un nodo fisico diverso rispetto a quello del server (il computer su cui gira il browser).

In un'applicazione web basata su servizi la scelta del formato dei messaggi scambiati tra lo strato di presentazione e il Services Layer dipende dalle possibilità offerte dalla tecnologia usata per realizzare il client e dal binding scelto per i servizi presenti lato server. Anche se solitamente la scelta ricade su messaggi testuali (in formato SOAP, JSON, POX od altro) che viaggiano su un canale di trasporto HTTP/HTTPS come una normale richiesta web, nel caso delle applicazioni RIA sono possibili anche meccanismi di comunicazione più a basso livello, che sfruttino una logica di interazione di tipo push. Del resto sia Silverlight che Flash sono in grado di gestire una comunicazione basata su un socket TCP, permettendo così la creazione di connessioni persistenti tra il client e l'ambiente server.