Dive into Information Technology

Negli ultimi anni si sta assistendo lentamente ad un mutamento della consolidata architettura a tre livelli che caratterizza le applicazioni web. Il consolidamento di tecnologie lato client e i nuovi paradigmi architetturali della parte server stanno modificando il posizionamento della logica di presentazione.

La storica “battaglia dei browser” negli anni ‘90 (Microsoft vs Netscape) e le sue successive ripercussioni, hanno fatto sì che la progettazione delle applicazioni web delegasse al client il solo compito di visualizzare pagine HTML, opportunamente popolate e controllate dalla parte server dell’architettura. Il popolamento dei template in base ai dati provenienti dai livelli sottostanti e il controllo del flusso di presentazione sono tutt’oggi compiti che sono affidati alle tecnologie lato server che ne sostengono efficacemente il design, lo sviluppo e l’esecuzione.

Nel tempo però i due domini architetturali (client e server) hanno subìto e continuano a subire dei cambiamenti.
Molte delle divergenze della citata battaglia si sono appianate e parallelamente sono nati dei veri e propri framework che astraggono i problemi relativi al cross-browsing esponendo opportune API.
Tutt’oggi le potenzialità e l’affidabilità del lato client sono aumentate notevolmente e sono in continua crescita.
E’ giusto allora cominciare a pensare che la logica di presentazione cominci a porsi sempre più l’obiettivo di essere dove gli compete, cioé sul client, ambiente vitale della parte “View”.

Questa pretesa di maturità del client d’altronde è coerente con ciò che sta accadendo dalla parte server.
Mi riferisco alle architetture Service Oriented (SOA) mediante le quali la business logic è esposta sempre più come servizio accessibile con interfacce standard. I principi di scambio dati strutturati ed in formato standard tra domini architetturali distinti dovrebbero sempre più essere adottati in riferimento al Presentation Tier.
Inoltre, avere un livello di presentazione “autonomo” nella logica ben si sposa con il principio di basso accoppiamento delle SOA. Qualcuno parla di “front-end Service Oriented“.

Ajax già tutt’oggi permette di accedere direttamente a dei Data Service e visualizzare dinamicamente sulla pagina il risultato della loro elaborazione. Inoltre le possibilità che cominciano ad emergere in merito alla gestione controllata del caching del browser (vedi precedente articolo sulle Offline Web Applications) permette di spostare sempre più il baricentro della logica e del controllo, lasciando al server l’importante compito di fornire accesso a dati opportunamente strutturati. Tutto ciò permette di avere un incremento di velocità nell’applicazione e un carico sulla rete caratterizzato probabilmente dalla stessa latenza ma da una quantità dati certamente inferiore.

Allo stato delle cose però questo mutamento architetturale porta con sé delle incertezze.
Innanzitutto il fatto che inserire logica lato client la rende di fatto “accessibile” a tutti e ciò potrebbe far storcere il naso in diverse situazioni.
C’è poi da dire che, con questo genere di approccio, lo stato dell’applicazione viene mantenuto dal client e anche questo conduce a possibili problemi di sicurezza.
Infine, si dovrebbe garantire di poter ottenere lo stesso grado di ubiquità che offrono le attuali applicazioni web , cioè la possibilità di potervi accedere in maniera coerente da diverse piattaforme e terminali.

Risorse in Rete:

• http://www.dojotoolkit.com/
• http://www.openajax.org/index.php
• http://javascriptmvc.com/
• http://unclescript.blogspot.com/2008/01/end-of-web-frameworks.html
• http://unclescript.blogspot.com/2008/02/end-of-web-server-frameworks-part-ii.html
• http://www.infoq.com/articles/rationalizing-presentation-tier
• http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html