Questo articolo fa parte di una serie di mie riflessioni sull’innovazione technology-driven, cominciata qui.
I servizi all’interno di una architettura di Enterprise mobility possono essere classificati a seconda dello stile architetturale con cui sono stati sviluppati.
Component-based services: sono servizi costruiti con le prime tecnologie client-server (J2EE, .NET, …) con protocollo di comunicazione basato su Remote Procedure Call (su reti locali) e XML su HTTP per intranet ed internet. L’XML è una grammatica che per la descrizione e la formattazione di pagine web (layout), ipertesti e documenti strutturati, quindi è il linguaggio con cui sono stati sviluppati i primi siti WEB evoluti. L’HTTP è il più semplice metodo per la trasmissione di informazioni sul WEB. il punto di debolezza di questo stile architetturale sta nella necessità di attendere il caricamento di tutta la struttura XML prima di consentire un’interazione all’utente.
SOAP-based WEB Services: servizio costruito in architettura WEB Services Simple Objects Access Protocol con protocollo di comunicazione basato su XML su HTTP. È una evoluzione dello stile precedente, in cui i componenti software sono sviluppati con metodologie object oriented. Ai fini del mobile computing non risolvono le debolezze intrinseche dell’XML.
RESTful WEB Services: servizio costruito in architettura WEB Services REpresentational State Transfer con protocollo di comunicazione basato su HTTP/HTTPS. Evolve ulteriormente il modello, abbandonando l’XML in favore di componenti software molto più leggere e versatili, nella costruzione delle quali impone, rispetto a SOAP, maggiori vincoli ai componenti software, ai connettori ed ai dati, per garantirne l’esecuzione in ambienti distribuiti frammentati.
Pur mantenendo un modello client-server, lo stile RESTful impone che nessun tipo di contesto client sia memorizzato nel Servizio e che ogni richiesta che arriva dal client contenga tutte le informazioni necessarie per eseguire la richiesta. Questo è il concetto di Stateless, che consente ad un client di eseguire chiamate in sequenza ad istanze diverse del Servizio, collocate anche su unità elaborative differenti, senza “perdere il filo” applicativo.
Cacheable significa che il servizio deve consentire al client di conservare localmente alcuni dati contenuti nelle risposte, per eliminare interazioni ridondanti, aumentando la scalabilità e le prestazioni.
Layered significa che il client non sa e non gli serve sapere se è collegato direttamente al server finale o ad un server intermedio, che può essere introdotto per migliorare il bilanciamento di carico operativo o per motivi di sicurezza e di reliability.
Uniform interface, è quello che contraddistingue I sistemi client/server, consentendo al server di evolvere indipendentemente dal client, garantendo la compatibilità all’indietro.
Dovreste aver abbastanza chiari i vantaggi di uno stile architetturale di tipo RESTful per un ambiente distribuito di tipo mobile. Se ripercorriamo i vincoli, lo vedrete più facilmente:
Limitata capacità hw e sw del dispositivo: semplicità architetturale: modello client-server con interfacce standardizzate.
Limitata banda trasmissiva e batteria: i WebServices SOAP-based utilizzano messaggi XML che richiedono maggiore banda e potenza elaborativa rispetto ai msg JSON utilizzati dai WS RESTful
Frammentazione dei dispositivi e limitate dimensioni dello schermo: SOAP supporta solo il formato dati XML, mentre REST supporta: HTML, plain text, XML, JSON, PDF, Atom, …
Prestazioni e scalabilità: Cacheable significa migliori prestazioni; Stateless significa migliore scalabilità.
Potrebbe essere interessante per voi verificare, quando ipotizzate di partire con un progetto di mobile computing, quanti e quali dei servizi applicativi del sistema informativo aziendale sono stati già migrati su una service oriented architecture e con quali stili architetturali. Per approfondimenti, leggete qui.
luigiatauro.com 