Model-View-Controller (MVC, talvolta tradotto in italiano Modello-Vista-Controllore) è un pattern architetturale molto diffuso nello sviluppo di interfacce grafiche di sistemi software object-oriented. Originariamente impiegato dal linguaggio Smalltalk, il pattern è stato esplicitamente o implicitamente sposato da numerose tecnologie moderne, come framework basati su PHP (Symfony, Zend Framework), su Ruby (Ruby on Rails), su Python (Django), su Java (Swing, JSF e Struts), su Objective C o su .NET. A causa della crescente diffusione di tecnologie basate su MVC nel contesto di framework o piattaforma middleware per applicazioni Web, l'espressione framework MVC o sistema MVC sta entrando nell'uso anche per indicare specificamente questa categoria di sistemi (che comprende per esempio Ruby on Rails, Struts, Spring, Tapestry e Catalyst).
Esempio:
Permette di impostare il valore di una delle proprietà di un JavaBean.
Attributi:
Esempio:
permette di assegnare il valore "parametro" alla proprietà "nomeProp" del bean di nome nomeBean.
3)
Prende il valore di una proprietà di una data istanza di JavaBean e lo inserisce nell'oggetto out implicito (in pratica lo stampa a video).
Attributi:
Soluzione a questo problema è rappresentata dai Java Beans, componenti software contenenti una classe Java, che possono venire inclusi in una pagina JSP, permettendo quindi un ottimo incapsulamento del codice, peraltro riutilizzabile. Al programmatore quindi sarà pressochè invisibile la sezione di codice puro, sostituito da richiami ai metodi delle classi incluse.
I Java Beans sono costituiti esclusivamente da codice Java, salvati con estensione .java e compilati (per esempio con il compilatore Java JDK) generando un file di estensione .class. Sarà il file .class che dovrà venire incluso nella pagina JSP. Da ricordare che in Java i file devono avere lo stesso nome della classe, lettere maiuscole e minuscole comprese.
BIRT ha due componenti principali: un designer di report basato su Eclipse ed un componente di runtime che è possibile aggiungere al proprio application server (io l'ho provato su Tomcat e va benissimo). Inoltre mette a disposizione un sistema che consente la generazione di grafici direttamente dalle applicazioni.
Con BIRT è possibile aggiungere alle applicazioni un’ampia varietà di report:
Obiettivi. Il progetto punta a ottenere importanti risultati di ricerca nell'area della logistica automobilistica, al fine di sviluppare un sistema innovativo (AUTOMA) per la gestione di hub di distribuzione di automobili.
Tale sistema, sfruttando le opportunità derivanti dalle tecnologie informatiche e delle telecomunicazioni, permetterà di giungere ad una ottimizzazione nei processi di gestione dei flussi di distribuzione di automobili nel porto di Gioia Tauro.
Inoltre, in prospettiva futura, i risultati del progetto saranno funzionali al consolidamento di un indotto in grado di intervenire sul completamento dei processi produttivi delle automobili contribuendo allo sviluppo ulteriore dell'intera area.
Aree di ricerca. Il progetto affronta una serie di ambiti di ricerca fondamentali:
L'approfondimento di queste linee di ricerca è indirizzato alla realizzazione di alcune funzionalità specifiche che dovranno essere caratterizzanti il nuovo sistema AUTOMA e che consentano di:
Piano di lavoro. La concretizzazione dei risultati della ricerca avviene attraverso uno specifico piano operativo articolato in più obiettivi realizzativi:
Partner. Il progetto, che dovrà essere realizzato in 30 mesi (Gen. 2006- Giu. 2008) , coinvolge i seguenti soggetti:
Obiettivo. Obiettivo fondamentale del progetto è quello di sviluppare un sistema innovativo (PROMIS) che conduca ad una ottimizzazione del processo di gestione dei terminali marittimi, fondato su una visione orientata ai processi delle attività di logistica integrata che avvengono all'interno di grandi hub portuali collegati a reti di trasporto intermodali.
Motivazioni. L'attività di un terminale marittimo per container necessita di un sistema di gestione informatizzato che assicuri alle compagnie di navigazione tempi di crociera più brevi, standard di servizio superiori e, allo stesso tempo, permetta di massimizzare l'utilizzo del personale e degli equipaggiamenti.
Sulla base dei risultati dell'attività di ricerca, si procederà alla progettazione e realizzazione di un dimostratore che, attraverso l'implementazione delle metodologie e delle tecniche sperimentate, consenta di verificare i margini esistenti per migliorare l'efficienza delle attività logistiche e conseguentemente l'economicità complessiva di tutta la gestione del terminal portuale.
Inoltre, in considerazione dell'impatto che le attività logistiche hanno sulle filiere produttive dell'indotto, si cercherà di approfondire lo studio delle metodologie per la facilitazione delle interazioni tra il porto e il mondo esterno. Tale attività dovrebbe portare alla creazione di un Collaborative Logistic Network (CNL) che favorisca l'affermarsi di nuovi e più efficienti modelli di business lungo tutto il ciclo che va dalla produzione alla distribuzione di beni.
Aree di ricerca. Date tali finalità, l'attività di ricerca sarà concentrata su alcune aree tematiche ritenute fondamentali:
Piano di lavoro. I risultati delle attività di ricerca saranno conseguiti sulla base di precisi obiettivi realizzativi (OR), sviluppati in un arco temporale di 30 mesi:
Partner. La realizzazione del progetto coinvolge i seguenti soggetti:
Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service (servizio web) è un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è quella di offrire un'interfaccia software (descritta in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language) utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta" (la più famosa è SOAP): tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML.
Proprio grazie all'utilizzo di standard basati su XML, tramite un'architettura basata sui Web Service (chiamata, con terminologia inglese, Service oriented Architecture - SOA) applicazioni software scritte in diversi linguaggi di programmazione e implementate su diverse piattaforme hardware possono quindi essere utilizzate, tramite le interfacce che queste "espongono" pubblicamente e mediante l'utilizzo delle funzioni che sono in grado di effettuare (i "servizi" che mettono a disposizione) per lo scambio di informazioni e l'effettuazione di operazioni complesse (quali, ad esempio, la realizzazione di processi di business che coinvolgono più aree di una medesima azienda) sia su reti aziendali come anche su Internet: la possibilità dell'interoperabilità fra diversi software (ad esempio, tra Java e Python) e diverse piattaforme hardware (come Windows e Linux) è resa possibile dall'uso di standard "aperti" (per un concetto assimilabile cfr. la voce "open source").
Il consorzio OASIS (Organization for the Advancement of Structured Information Standards) ed il W3C sono i principali responsabili dell'architettura e della standardizzazione dei Web Service; per migliorare l'interoperabilità tra le diverse implementazioni dei Web Service l'organizzazione WS-I sta inoltre sviluppando una serie di "profili" per meglio definire gli standard coinvolti.
La pila protocollare dei Web Service è l'insieme dei protocolli di rete utilizzati per definire, localizzare, realizzare e far interagire tra di loro i Web Service; è principalmente composta di quattro aree:
Ulteriori protocolli standard utilizzati sono:
La ragione principale per la creazione e l'utilizzo di Web Service è il "disaccoppiamento" che l'interfaccia standard esposta dal Web Service rende possibile fra il sistema utente ed il Web Service stesso: modifiche ad una o all'altra delle applicazioni possono essere attuate in maniera "trasparente" all'interfaccia tra i due sistemi; tale flessibilità consente la creazione di sistemi software complessi costituiti da componenti svincolati l'uno dall'altro e consente una forte riusabilità di codice ed applicazioni già sviluppate.
I Web service hanno inoltre guadagnato consensi visto che, come protocollo di trasporto, possono utilizzare HTTP "over" TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l'unica) lasciata "aperta" dai sistemi firewall al traffico di entrata ed uscita dall'esterno verso i sistemi aziendali e ciò in quanto su tale porta transita il traffico HTTP dei web browser: ciò consente l'utilizzo dei Web Service senza modifiche sulle configurazioni di sicurezza dell'azienda (un aspetto che se da un lato è positivo solleva preoccupazioni concernenti la sicurezza).
Un'ultima ragione che ha favorito l'adozione ed il proliferare dei Web Service è la mancanza, prima dello sviluppo di SOAP, di interfacce realmente funzionali per l'utilizzo di funzionalità distribuite in rete: EDI, RPC, ed altri tipi di API (Application Programming Interface) erano e rimangono meno conosciute e di facile utilizzo che non l'architettura dei Web Service.
Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA) si indica un'architettura software atta a supportare l'uso di servizi Web per soddisfare le richieste degli utenti così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business.
Indice |
Una SOA è progettata per il collegamento a richiesta di risorse computazionali (principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti, che possono essere utenti finali o altri servizi. L'OASIS (Organizzazione per lo sviluppo di standard sull'informazione strutturata) definisce la SOA così:
Un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.
Anche se esistono molteplici definizioni di SOA, solo il gruppo OASIS ha prodotto una definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali.
Il concetto di SOA (WebServices e non solo ) deriva dalla riconsiderazione delle strutture aziendali: organizzazioni rizomatiche che fonda le sue radici nella cultura biologica. L'evoluzione delle infrastrutture di comunicazione, che ormai sono pervasive consente di pensare l'interconnessione tra soggetti economici, come le aziende, come un processo dinamico, non fissato una volta per tutte.
Sebbene molte definizioni di SOA si limitino alla tecnologia o solo ai Web services, questo aspetto è predominante per i fornitori di tecnologia. Nel 2003 questi parlavano di Web services, e nel 2006 di Motori di Processo.
Nell'ambito di un'architettura SOA è quindi possibile modificare, in maniera relativamente più semplice, le modalità di interazione tra i servizi, oppure la combinazione nella quale i servizi vengono utilizzati nel processo, così come risulta più agevole aggiungere nuovi servizi e modificare i processi per rispondere alle specifiche esigenze di business: il processo di business non è più vincolato da una specifica piattaforma o da un'applicazione ma può essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
L'architettura orientata ai servizi si presenta particolarmente adatta per le aziende che presentano una discreta complessità di processi e applicazioni, dal momento che agevola l'interazione tra le diverse realtà aziendali permettendo, al contempo, alle attività di business di sviluppare processi efficienti, sia internamente che esternamente ed aumentarne la flessibilità e l'adattabilità.
Benché molte aziende offrano prodotti che possono formare la base di una SOA va sottolineato che la SOA non è un prodotto.
Non è affatto vero che un'architettura orientata ai servizi non sia legata ad una specifica tecnologia. Chi dice che può essere realizzata usando una vasta gamma di tecnologie, comprese REST, RPC, DCOM, CORBA, MOM, DDS non ha chiaro il vero valore e l'intrinseco significato delle SOA: nessuna di queste tecnologie è infatti capace di implementare entità che descrivano se stesse come è possibile fare usando i Web services mediante il linguaggio di definizione dei servizi WSDL. Infatti applicazioni di test che a run-time capiscano la semantica di un servizio e lo invochino senza "conoscere" nulla del servizio stesso "a priori", non esistono per nessuna delle tecnologie citate. La chiave sta nella totale assenza di business logic sul client SOA il quale è totalmente agnostico rispetto alla piattaforma di implementazione, riguardo i protocolli, il binding, il tipo di dati, le policy con cui il servizio produrrà l'informazione richiesta Service Level Agreement (SLA). Tutto a beneficio dell'indipendenza dei servizi, che possono essere chiamati per eseguire i propri compiti in un modo standard, senza che il servizio abbia conoscenza dell'applicazione chiamante e senza che l'applicazione abbia conoscenza, o necessiti di averne, del servizio che effettivamente eseguirà l'operazione.
SOA può anche essere vista come uno stile dell'architettura dei sistemi informatici che permetta la creazione delle applicazioni sviluppate, combinando servizi debolmente accoppiati e interoperabilità degli stessi. Questi servizi interoperano secondo una definizione formale, detta protocollo o contratto, come per i WSDL indipendente dalla piattaforma sottostante e dalle tecnologie di sviluppo (come Java, .NET, ecc). I servizi, per esempio, scritti in Java usando la piattaforma Java EE e quelli in C# con .NET possono essere utilizzati dall'applicazione sovrastante. Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in esecuzione su altre, come con i Web services, facilitando quindi la riusabilità.
SOA può supportare l'integrazione e la consolidazione di attività all'interno di complessi sistemi aziendali, ma non specifica o fornisce la metodologia o il framework per documentare capacità e potenzialità dei servizi.
I linguaggi di alto livello come BPEL e le specifiche come WS-CDL e WS-Coordination estendono il concetto di servizio, fornendo un metodo per definire e supportare la coordinazione dei servizi di rifinitura con quelli maggiori, che, di conseguenza, possono essere inclusi in flussi di controllo e processi aziendali implementati con applicazioni composte o portali.
La validità di un'architettura orientata ai servizi (SOA) è conseguenza degli elementi e degli standard su cui si fonda. In particolare vanno considerati i seguenti aspetti:
Incipit
Questo articolo è la traduzione della versione inglese intitolata “Ajax: A New Approach to Web Applications” scritta da Jesse James Garrett.
Introduzione
Qualsiasi progetto interattivo definito “affascinante” è destinato a diventare un’applicazione Web.
Dopo tutto, quando è stata l’ultima volta che abbiamo sentito qualcuno parlare di un progetto interattivo che non era presente sul Web? (Ok, oltre l’iPod.) Tutti i nuovi progetti innovativi sono destinati ad essere online.
Nonostante ciò, i progettisti web non possono fare altro che essere un po’ invidiosi dei colleghi che creano applicazioni Desktop.
Le applicazioni Desktop hanno una completezza e una velocità di risposta elevata che risultano essere fuori dalla portata del Web.
La semplicità che ha portato alla proliferazione del Web ha creato un divario tra le esperienze che noi possiamo fornire mediante le applicazioni Web e le applicazioni Desktop.
Quel divario oramai non esiste più. Basta dare uno sguardo a Google Suggest. Si può vedere come i termini suggeriti durante la digitazione vengano aggiornati quasi istantaneamente. Focalizziamoci su Google Maps. Ingrandiamo la mappa. Usiamo il cursore per trascinare e muovere la mappa. Ancora possiamo notare come qualsiasi cosa che accade è quasi istantanea, senza dover aspettare il ricaricamento della pagina.
Google Suggest e Google Maps sono due esempi del nuovo approccio alle applicazioni web che Adaptive Path chiama Ajax. Il nome è l’abbreviazione di Asynchronous JavaScript + XML e rappresenta una svolta fondamentale su ciò che sarà possibile fare sul Web.
Definiamo Ajax
Ajax non è una tecnologia. E’ l’insieme di più tecnologie indipendenti che insieme danno vita a potenti prospettive. Ajax incorpora a se:
Le classiche applicazioni Web lavorano in questo modo: molte delle operazioni non sono altro che una richiesta HTTP inoltrata al web server. Il server fa l’elaborazione - raccolta dati, manipolazione numeri, dialogo con eventuali sistemi legacy (datati) - e ritorna una pagina HTML al client. Questo è un modello adottato sin dalle origini del Web, considerato medium ipertestuale, ma come sanno i fanatici della User Experience, esso rende il Web ottimale per l’ipertesto ma non necessariamente così ottimale anche per le applicazioni software.
Figura 1: Il modello tradizionale delle applicazioni Web (alla sinistra) confrontato col modello Ajax (alla destra).
Questo approccio crea una miriade di soluzioni/quesiti tecnici che annebbiano quelli inerenti la User Experience. Mentre il server stà elaborando, l’utente cosa fa? Aspetta, e sarà costretto a farlo ad ogni richiesta.
Naturalmente, se noi progettavamo l’applicazione Web come un’applicazione software, questo non accadeva. Una volta che è stata caricata l’interfaccia, perchè l’interazione dell’utente deve fermarsi ogni volta che l’applicazione ha bisogno di processare il server? Perchè l’utente deve vedere l’applicazione dialogare con il server così pesantemente?
Ajax fa la differenza
Un’applicazione Ajax elimina la natura del Web ad essere contraddistinta da momenti alternati di dialogo-risposta che fanno attendere l’utente, introducendo un intermediario - un motore Ajax - tra l’utente e il server.
Può sembrare di aggiungere un livello all’applicazione che la rende meno veloce a rispondere, però è vero il contrario.
Invece di caricare una classica pagina web, ad inizio sessione, il browser carica il motore Ajax - scritto in Javascript e usualmente associato ad un frame invisibile. Questo motore è responsabile della comunicazione tra l’interfaccia utente e il server, mettendoli in comunicazione tra di loro. Il motore Ajax, indipendentemente dalla comunicazione con il server, permette all’interazione dell’utente con l’applicazione di essere asincrona. Così l’utente non è mai succube della finestra del browser bianca e dell’iconcina indicante il caricamento, aspettando che il server esegua le operazioni.
Figura 2: Modello di interazione sincrona di un’applicazione web (sopra) confrontato con il modello asincrono Ajax (sotto).
Ogni azione dell’utente che normalmente genera una richiesta HTTP prende la forma di una chiamata Javascript verso il motore Ajax. Ogni risposta che non richiede la chiamata diretta al server - come validare alcuni dati, modificare dati in memoria - è un lavoro compiuto dal motore Ajax. Se il motore ha bisogno di interagire con il server per rispondere - invio dati da processare, caricare un interfaccia aggiuntiva, ricevere nuovi dati - il motore rende queste richieste asincrone, usualmente utilizzando XML, senza bloccare l’interazione tra utente e applicazione.
Chi usa Ajax
Google stà facendo molti investimenti nell’utilizzare AJAX come nuovo approccio. La maggior parte dei prodotti di Google introdotti anni fa - Orkut, Gmail, Google Groups, Google Suggest e Google Maps - sono applicazioni basate su Ajax. (per una migliore trattazione tecnica sull’implementazione Ajax, si consiglia di vedere l’analisi di Gmail, Google Suggest e Google Maps) Molti altri stanno seguendo lo stesso approccio: molte funzioni di Flickr sono basate su Ajax e il motore di ricerca di Amazon A9.com usa tecniche similari.
Questi progetti dimostrano che Ajax non risulta essere pura tecnica ma anche un’ottima pratica per la creazione di applicazioni molto utili. Non è una delle tante tecnologie utilizzate solo nei laboratori. Le applicazioni Ajax possono avere dimensioni diverse, dalla più semplice come Google Suggest, alla più complessa come Google Maps.
Uno sguardo al futuro
La maggiore sfida che Ajax pone davanti ai nostri occhi non riguarda la risoluzione dei problemi tecnici da esso derivati, ma il dimenticare tutte le limitazioni che riguardavano il Web, per lanciarsi verso la creazione di applicazioni robuste, veloci e sempre più simili alle applicazione Desktop.
Post
Tutti i commenti
Post
Tutti i commenti
