ITMI20082289A1 - Architettura di applicazioni distribuite - Google Patents

Description

DESCRIZIONE

del brevetto per invenzione industriale dal titolo:

“ARCHITETTURA DI APPLICAZIONI DISTRIBUITEâ€

La presente invenzione à ̈ relativa ad un’architettura di applicazioni distribuite.

È ben noto che le applicazioni distribuite per calcolatore hanno raggiunto, nel panorama attuale, un’importanza cardinale e una diffusione addirittura pervasiva, in particolare per quanto concerne le applicazioni cosiddette “webbased†o, più semplicemente, applicazioni web, che operano attraverso Internet. In questo tipo di architettura, come noto, un motore o nucleo dell’applicazione (server applicazioni) risiede su una macchina centrale che à ̈ collegabile in modo dinamico a macchine utenti remote (client) attraverso un server web, per rendere disponibile, a richiesta, un certo insieme di servizi o funzioni. Le macchine client dialogano con il server applicazioni attraverso un’interfaccia grafica utente (GUI, “Graphical User Interface†). In altre parole, l’interfaccia permette all’utente di eseguire azioni (come premere un pulsante, selezionare un comando da un menu o inserire dati) che scatenano eventi associati (ossia avviano l’esecuzione di determinate funzioni o procedure da parte del server applicazioni) e modificano lo stato dell’applicazione.

Lo sviluppo di applicazioni web può oggi avvalersi di numerose diverse tecnologie, sia per il lato server, sia per il lato client. In pratica, quando il progettista inizia a studiare l’architettura di un’applicazione web, deve innanzi tutto affrontare il problema di come disporre le componenti logiche tra i diversi livelli dell’infrastruttura web e, conseguentemente, deve decidere quali tecnologie sia più conveniente utilizzare (tecnologia server, tecnologia client, refresh completo o parziale delle pagine). Di fatto, la scelta fra le tecnologie disponibili ha un impatto notevole sul successivo progetto delle componenti server e client.

Lo sviluppo di applicazioni web differisce quindi in modo sensibile dallo sviluppo di applicazioni di tipo desktop. Per queste ultime, infatti, il progettista ha normalmente a disposizione un unico contesto di riferimento e un unico linguaggio di programmazione, di norma orientato agli oggetti, sia per realizzare le componenti lato client che per realizzare quelle lato server. Inoltre, quasi sempre sono disponibili librerie grafiche che contengono oggetti complessi interattivi come pulsanti (Button), caselle di testo (TextBox), caselle di inserimento (InputBox), menu e così via, e consentono di sfruttare a pieno le potenzialità grafiche dei moderni sistemi operativi.

Attualmente, per costruire applicazioni web che seguano le direttive W3C (“World Wide Web Consortium†) à ̈ necessario utilizzare le tecnologie HTML/JavaScript. Queste tecnologie, per quanto potenti, soffrono tuttavia di alcuni problemi. Il linguaggio HTML (“HyperText Markup Language†), in particolare, à ̈ basato sul concetto di pagina e così, nelle applicazioni web tradizionali, anche l’interfaccia grafica à ̈ essenzialmente basata sui concetti di pagina e di navigazione tra pagine. Inoltre, gli elementi grafici interattivi presenti nelle pagine HTML non sono nativamente correlati con corrispondenti eventi (esecuzione di funzioni) sul lato server. Il progettista deve quindi preoccuparsi di creare di volta in volta una correlazione fra gli uni e gli altri, gestendo direttamente le conseguenze delle interazioni degli utenti con gli oggetti grafici dell’interfaccia.

Anche se, per alcuni tipi di applicazioni, un approccio di questo genere può risultare appropriato, in altri casi la strutturazione dell’applicazione per pagine à ̈ poco efficace e rende assai laboriosa o addirittura impossibile l’implementazione di alcune importanti funzioni. Ad esempio, l’approccio per pagine à ̈ poco adatto a realizzare controlli di sicurezza sulle attività dell’utente, che potrebbero richiedere la sospensione del flusso di esecuzione di un processo in attesa di un’azione di conferma. Per fare un esempio, si pensi alla situazione in cui un utente ha aperto un modulo di ordine a fornitore e, dopo aver effettuato delle modifiche, tenta di chiudere il modulo senza effettuare un salvataggio. Come misura di sicurezza per evitare la perdita di dati, sarebbe necessario includere nel codice di chiusura del modulo una funzione che permette di sospendere temporaneamente l’esecuzione per avvertire del mancato salvataggio e chiedere conferma di un’opzione fra diverse alternative proposte (come chiusura senza salvataggio delle modifiche, salvataggio delle modifiche e annullamento della chiusura). Una misura di questo tipo impedirebbe la prosecuzione del codice e una perdita irrimediabile di informazioni senza un’azione consapevole dell’utente.

Nelle applicazioni desktop complesse l’interfaccia grafica à ̈ basata sul concetto di finestra, che à ̈ molto più flessibile di quello di pagina. In particolare, più finestre, eventualmente nidificate, possono essere aperte contemporaneamente in modo indipendente ed ogni finestra può contenere diverse componenti grafiche interattive, tra cui ulteriori finestre. Come notato, però, gli attuali strumenti di sviluppo di applicazioni web, che non sono concepiti a questo scopo, sono rigidi e richiedono che gli strumenti per la comunicazione degli eventi, per l’esecuzione delle procedure sul server e per l’aggiornamento dell’interfaccia grafica siano definiti direttamente dal progettista. Da un lato, quindi, ogni singolo progetto comporta complessità e carico di lavoro maggiori, mentre, dall’altro, aumenta anche il rischio di errori che possono non essere rilevati in fase di debug.

Scopo della presente invenzione à ̈ quindi di fornire un’architettura di applicazioni distribuite che sia flessibile nella gestione e permetta di trattare gli oggetti grafici interattivi in modo trasparente, ossia senza la necessità di definire in sede di progetto anche gli strumenti e le procedure per la comunicazione degli eventi correlati ai componenti grafici interattivi, per l’esecuzione dei comandi associati ai componenti grafici interattivi e per l’aggiornamento dell’interfaccia grafica in risposta all’esecuzione dei comandi.

Secondo la presente invenzione viene realizzata un’architettura di applicazioni distribuite come definita nella rivendicazione 1.

La presente invenzione verrà ora descritta con riferimento ai disegni annessi, che ne illustrano alcuni esempi di attuazione non limitativo, in cui:

- la figura 1 à ̈ uno schema a blocchi di un’architettura di applicazioni distribuite secondo una forma di realizzazione della presente invenzione;

- la figura 2 mostra un particolare dell’architettura di figura 1;

- la figura 3 à ̈ uno schema a blocchi più dettagliato di un elemento dell’architettura di figura 1;

- la figura 4 à ̈ uno schema a blocchi ulteriormente dettagliato di un primo particolare dell’elemento di figura 3;

- la figura 5 à ̈ uno schema a blocchi ulteriormente dettagliato di un secondo particolare dell’elemento di figura 3;

- la figura 6 à ̈ uno schema a blocchi ulteriormente dettagliato di un terzo particolare dell’elemento di figura 3;

- la figura 7 à ̈ uno schema a blocchi ulteriormente dettagliato dell’elemento di figura 3 in una configurazione d’uso;

- la figura 8 à ̈ uno schema a blocchi ulteriormente dettagliato di un quarto particolare dell’elemento di figura 3;

- la figura 9 à ̈ un Sequence Diagram UML relativo a una prima procedura nell’architettura di figura 1;

- la figura 10 à ̈ un Sequence Diagram UML relativo a una seconda procedura nell’architettura di figura 1; e

- la figura 11 à ̈ un Sequence Diagram UML relativo a una terza procedura nell’architettura di figura 1.

Con riferimento alla figura 1, il numero 1 indica un’architettura di applicazioni distribuite nel suo complesso. L’architettura 1 comprende un piattaforma server 2, un server web 3 e una o più piattaforme client 5, ciascuna dotata di un navigatore web (web browser) 7 per la connessione con la piattaforma server 2, attraverso il server web 3. In figura 1, per semplicità à ̈ illustrato una sola piattaforma client 5 collegata alla piattaforma server 2. La piattaforma server 2 e il server web 3 possono essere implementati mediante una stessa macchina o macchine distinte.

La piattaforma server 2 comprende un server applicazioni 8 e ospita una pluralità di applicazioni A, una delle quali à ̈ schematicamente rappresentata in figura 1. Di ciascuna applicazione A sono attivabili una pluralità di sessioni S1, …, SN. Il server applicazioni 8 comprende un motore server 10, che à ̈ residente sulla piattaforma server 2, e un motore client 11. Il motore client 11 à ̈ caricabile sulla piattaforma client 5 dal server applicazioni 8 in risposta a una richiesta di avvio dell’applicazione A, inoltrata da un utente attraverso la piattaforma client 5 (in figura 1, il motore client 11 à ̈ indicato a tratteggio all’interno del blocco che schematizza il server applicazioni 8, per indicare che esso viene inviato alla piattaforma client 5 alla richiesta di avvio di un’applicazione e successivamente risiede lì). Come sarà spiegato in dettaglio più avanti, il server applicazioni 8 riceve dalla piattaforma client 5 una richiesta di avvio applicazione, crea una nuova sessione dell’applicazione specificata e carica sulla piattaforma client 5 il motore client 11 e le informazioni di inizializzazione necessarie.

La piattaforma client 5 comprende periferiche di controllo 12, ad esempio una tastiera e un dispositivo di puntamento, che permettono a un utente di interagire con l’architettura 1 attraverso il navigatore web 7.

Il navigatore web 7 à ̈ provvisto di un’interfaccia utente grafica 13, che permette di visualizzare e gestire componenti grafici interattivi di client 14. I componenti grafici interattivi di client 14, di cui alcuni esempi sono mostrati in figura 2, possono includere finestre, pulsanti, caselle di inserimento, caselle di testo, menu a tendina e così via, e permettono all’utente di impartire comandi (ad esempio premendo un pulsante) e inserire dati (ad esempio introducendoli in una casella di inserimento), utilizzando le periferiche di controllo 12. L’interfaccia utente grafica 13 rileva un “evento†e genera e rende disponibile al motore client 11 un messaggio evento EM che identifica in modo univoco il componente grafico interattivo di client 14 interessato e l’azione eseguita. Per “evento†si intenderà qui e nel seguito qualsiasi azione dell’utente su uno qualsiasi degli componenti grafici interattivi di client 14 presenti nell’interfaccia utente grafica 13, in particolare l’invio di comandi (pressione di un pulsante, selezione di una voce di un menu ecc.) e l’invio dati (inserimento di valori da assegnare a variabili). Ovviamente, il tipo di azioni che può essere eseguito su un componente grafico interattivo di client 14 à ̈ definito dal componente grafico interattivo di client 14 stesso (ad esempio, un pulsante definisce come tipo di azione la pressione; un menu definisce come tipi di azione la visualizzazione e la selezione delle voci). Un evento richiede una sorgente (sul lato client) e un ascoltatore (sul lato server). Si noti che, tramite un messaggio evento EM, il navigatore web 7, di tipo convenzionale, si limita a comunicare al motore client 11 il verificarsi dell’evento stesso (ad esempio, un messaggio evento EM può indicare che un pulsante à ̈ stato premuto, ma non quali azioni devono essere intraprese affinché tale evento sia riportato al motore server 10).

Qui e nel seguito, per “comando†si intende generalmente la richiesta di eseguire una procedura o metodo oppure la richiesta di assegnare un valore a una variabile. I-noltre, per “metodo†di un oggetto si intende una porzione di codice caricata in un’area di memoria della piattaforma server 2 allocata per l’oggetto e definente una procedura tale da causare una modifica dello stato dell’oggetto stesso o di un altro elemento dell’architettura, quando eseguita.

Il motore client 11 comprende, inoltre, un modulo trasmissione comandi 11a e un modulo esecutore 11b.

Il modulo trasmissione comandi 11a à ̈ configurato per inviare messaggi di istruzione al motore server 10 in risposta a un evento e per ricevere dal motore server 10 modifiche dell’interfaccia utente grafica 13 in risposta all’esecuzione di comandi associati ad eventi.

Il modulo esecutore 11b attua le modifiche dell’interfaccia utente grafica 13 ricevute dal modulo trasmissione comandi 11a.

Come mostrato in figura 3, il motore server 10 comprende mezzi di avvio applicazioni 15, mezzi di gestione sessioni 17, per gestire diverse sessioni delle applicazioni A, mezzi di gestione esecuzione 18 per gestire il flusso di esecuzione principale, sospendendo l’esecuzione quando richiesto, e mezzi di gestione eventi 20.

Con riferimento alla figura 4, i mezzi di avvio applicazioni 15 comprendono una pluralità di funzioni server (o servlet) SL, che possono essere invocate da un terminale remoto, come ad esempio la piattaforma client 5. Tra queste, in particolare, sono incluse una funzione di avvio remoto SL_RWA, che lancia l’esecuzione di una nuova sessione di una applicazione specificata dal terminale remoto, e una funzione di esecuzione comandi SL_EX, che instrada le richieste di esecuzione comandi, con i relativi parametri, verso gli oggetti corrispondenti ai comandi specificati. La funzione di avvio remoto SL_RWA può essere invocata tramite una chiamata http CA in cui à ̈ indicato il nome della classe principale dell’applicazione A contenente la dichiarazione del metodo Main. La chiamata http può essere del tipo:

http://[ServerName]/[Directory]/SL_RWA?Name=[CN] dove [ServerName]/[Directory] à ̈ l’indirizzo URL dove si trova la funzione di avvio remoto SL_RWA e al parametro Name à ̈ assegnato come valore il nome classe CN della classe principale con la dichiarazione del metodo Main dell’applicazione A.

I mezzi di gestione sessione 17 (figura 5) comprendono una classe sessioni SC, che a sua volta include una funzione di avvio locale RA, e una collezione di oggetti sessione SO1, …, SOK, che sono istanze della classe SC. Ciascuno di essi contiene un identificatore di sessione SID univoco. In pratica, la funzione di avvio remoto SL_RWA, ogni volta che viene invocata, chiama nella classe sessioni SC la funzione di avvio locale RA, che crea un nuovo oggetto sessione SO per la nuova sessione dell’applicazione A lanciata (a tratteggio in figura 5).

I mezzi di gestione esecuzione 18, a cui si riferisce la figura 6, comprendono un modulo costruttore 21 e una pluralità di classi principali, istanze delle quali definiscono oggetti nelle applicazioni in esecuzione sulla piattaforma server 2.

Una prima classe principale à ̈ la classe controllo base BC (“BaseControl†), che contiene le proprietà di base e i metodi necessari alla definizione grafica e alla comunicazione tra la piattaforma server 2 e la piattaforma client 5 di eventi relativi a qualsiasi componente grafico interattivo. Come si vedrà, l’applicazione A crea una pluralità di componenti grafici interattivi di server (indicati con BC1, …, BCM in figura 7) come istanze di classi che ereditano dalla classe controllo base BC (ad esempio una classe Finestra (“Form†), una classe Pulsante (“Button†), una classe Casella di inserimento (“InputBox†), una classe Casella di testo (“TextBox†), una classe Menu a tendina (“DropDown†), ecc). I componenti grafici interattivi di server BC1, …, BCM possono essere annidati e formare una struttura ad albero, come nell’esempio di figura 7. In particolare, un componente grafico interattivo di server primario, qui indicato con BC1, à ̈ di tipo “Form†e contiene tutti gli altri componenti grafici interattivi di server (indicati con BC2, …, BCM) relativi a una sessione dell’applicazione A. Sempre nell’esempio di figura 7, il componente grafico interattivo di server BC2 può essere una finestra (“Form†) che contiene un pulsante (ossia il componente grafico interattivo di server BC3).

Una seconda classe principale à ̈ la classe identificatori H (“Handles†). In ciascuna sessione dell’applicazione A, ad ogni componente grafico interattivo di server BC1, …, BCM à ̈ associato in modo univoco un rispettivo oggetto identificatore H1, …, HM, che à ̈ un’istanza della classe identificatori H. Gli oggetti identificatori H1, …, HM sono organizzati in modo da formare una collezione di tipo “hash table†e, in pratica, permettono l’accesso diretto ad ogni singolo componente grafico interattivo di server BC1, …, BCM. L’accesso ai componenti grafici interattivi di server BC1, BC2, …, BCM viene così ottimizzato. Un nuovo oggetto identificatore H1, …, HM viene automaticamente istanziato e aggiunto alla collezione dal modulo costruttore 21 ogni volta che viene creato un nuovo componente grafico interattivo di server BC1, …, BCM.

Inoltre, lo stesso oggetto identificatore H1, …, HM associato a un rispettivo componente grafico interattivo di server BC1, …, BCM (o un’etichetta legata all’oggetto identificatore H1, …, HM e atta a identificare univocamente il rispettivo componente grafico interattivo di server BC1, …, BCM) può essere trasmesso e associato anche a un componente grafico interattivo di client 14, determinando così una corrispondenza biunivoca che, all’interno di una stessa sessione dell’applicazione A, permette di legare un evento sul lato client alla modifica di una proprietà o alla chiamata di un metodo in un componente grafico interattivo di server BC1, …, BCM sul lato server.

Una terza classe principale à ̈ la classe risposte R (“Responses†). In ciascuna sessione dell’applicazione A, oggetti risposta R1, …, RN sono istanze della classe risposte R e definiscono modifiche da apportare all’interfaccia utente grafica 13 in risposta a un evento (ossia in risposta all’esecuzione di procedure attivate da un’azione dell’utente su uno dei componenti grafici interattivi di client 14). Più precisamente, ogni volta che l’esecuzione di un metodo richiede di modificare l’interfaccia utente grafica 13, il componente grafico interattivo di server BC1, …, BCM che ha eseguito il metodo crea uno o più oggetti risposta R1, …, RN dove le modifiche da effettuare sono collezionate (ad esempio il ridimensionamento di una finestra, l’aggiunta o la cancellazione di un comando). In pratica, i componenti grafici interattivi di server BC1, BC2, …, BCM modificati ritornano il codice HTML che rappresenta le modifiche e che dovrà essere inviato all’interfaccia utente grafica 13 sulla piattaforma client 5.

Una quarta classe principale à ̈ la classe interfacce di sessione WG. All’avvio di ogni sessione dell’applicazione A, il server applicazioni 8 crea un nuovo oggetto interfaccia di sessione WGP come nuova istanza della classe interfacce di sessione WG. L’oggetto interfaccia di sessione WGP contiene in pratica tutte le istanze delle classi controllo base BC, identificatori H e risposte R associati alla nuova sessione dell’applicazione A.

Il motore server 10 comprende poi almeno due moduli di controllo (modulo di controllo risposte 24 e modulo di controllo esecuzione 25) e due sincronizzatori (sincronizzatore risposte 27 e sincronizzatore esecuzione 28), illustrati in figura 7.

Il modulo di controllo risposte 24 riceve messaggi client/server MCS in arrivo dalla piattaforma client 5 e produce e invia messaggi server/client MSC. I messaggi client/server MCS ricevuti vengono inoltrati al modulo di controllo esecuzione 25, che provvede all’esecuzione dei comandi agganciati.

Il sincronizzatore risposte 27 e il sincronizzatore esecuzione 28 provvedono alla sincronizzazione delle attività del modulo di controllo risposte 24 e del modulo di controllo esecuzione 25, in pratica in modo da rendere la comunicazione degli eventi fra il motore server 10 e il motore client 11 indipendente dall’esecuzione dei comandi associati. Il funzionamento del sincronizzatore risposte 27 e del sincronizzatore esecuzione 28 sarà descritto in dettaglio più avanti.

I mezzi di gestione eventi 20, a cui si riferisce la figura 8, comprendono una classe identificatori eventi EH, una classe argomenti eventi EA e una classe delegate eventi ED. Queste classi sono realizzate in modo che ogni oggetto nel motore server 10 possa dichiarare in modo pubblico gli eventi da esso gestiti, come se fossero normali proprietà. Per esempio un componente grafico come un pulsante potrebbe dichiarare gli eventi Click e Doppio Click, lasciando sospeso l’aggancio di un codice esecutivo. Nel momento in cui viene creata un’istanza di una classe derivata dalla classe controllo base BC (un pulsante, in questo caso), agli eventi dichiarati viene assegnata un’istanza della classe identificatori eventi EH associata a uno specifico metodo da eseguire in risposta all’evento.

La classe identificatori eventi EH comprende in sostanza una collezione di istanze della classe delegate eventi ED, che includono puntatori a metodi in istanze di classi. Per lanciare un evento, viene utilizzato un metodo di invocazione I associato all’evento stesso. Nella chiamata del metodo di invocazione I vengono specificati come parametri un oggetto mittente, cioà ̈ l’istanza di un componente che ha scatenato l’evento, e un oggetto argomenti eventi, che à ̈ un’istanza della classe argomenti eventi EA e definente parametri aggiuntivi. Un componente in ascolto riceve i parametri passati tramite il metodo di invocazione I.

La tecnologia utilizzata per chiamare metodi sconosciuti al momento della compilazione prende il nome di Reflection ed à ̈ in sostanza un insieme di classi configurate per manipolare ed invocare in maniera dinamica istanze di classi a tempo di esecuzione.

Oltre alla classe identificatori eventi EH, alla classe argomenti eventi EA e alla classe delegate eventi, i mezzi di gestione eventi 20 comprendono una classe identificatori interruzione eventi CEH e una classe argomenti interruzione eventi CEA, che permettono di dichiarare eventi che possono essere fermati dai componenti in ascolto, come ad esempio l’evento di chiusura di una finestra.

La comunicazione fra la piattaforma server 2 e la piattaforma client 5 viene effettuata mediante un protocollo di comunicazione, secondo cui i messaggi client/server MCS e i messaggi server/client MSC sono strutturati come di seguito descritto.

I messaggi client/server MCS, che permettono la comunicazione al server applicazioni 8 di comandi associati a eventi, in una forma di realizzazione sono basati su tecnologia AJAX e includono chiamate http con una serie di parametri, tra cui:

l’identificatore di sessione SID di una sessione di un’applicazione;

l’identificatore H di un componente grafico interattivo di server BC1, …, BCM a cui il comando à ̈ destinato;

un tipo di comando (esecuzione di un metodo o modifica di una proprietà);

il nome del metodo da eseguire o della proprietà da modificare;

uno o più valori, corrispondenti ai parametri del metodo da eseguire o ai valori da assegnare alla proprietà da modificare.

I messaggi server/client MSC, che vengono costruiti e inviati dal modulo di controllo risposte 24, contengono tutti gli oggetti risposta R1, …, RN che dovranno essere processati dal motore client 11, suddivisi in sezioni. Ciascuna sezione comprende un oggetto identificatore H1, …, HM relativo a un componente grafico interattivo BC1, …, BCM (o un’etichetta associata all’oggetto identificatore H1, …, HM in modo univoco) un parametro relativo a un’azione da eseguire (ad esempio, ma non solo, aggiunta, cancellazione, spostamento, modifica di un componente grafico interattivo di client 14) e ulteriori parametri che dipendono dall’azione stessa.

L’architettura 1 opera nel modo seguente.

L’avvio di un’applicazione (l’applicazione A, per esemplificare), a cui si riferisce il Sequence Diagram UML (Unified Modeling Language) di figura 9, viene effettuato su richiesta della piattaforma client 5 che, attraverso il navigatore web 7, chiama la funzione di avvio remoto SL_RWA passando il nome classe CN della classe principale con la dichiarazione del metodo Main dell’applicazione A. La funzione di avvio remoto SL_RWA chiama a sua volta la funzione di avvio locale RA della classe sessioni SC, che crea e inizializza un nuovo oggetto sessione SO per la nuova sessione dell’applicazione A (si veda anche la figura 5). Il nuovo oggetto sessione SO viene aggiunto alla collezione degli oggetti sessione SO1, …, SOK. Inoltre, nella classe sessioni SC viene memorizzato il nome classe CN della classe principale contenente la dichiarazione del metodo Main da utilizzare per l’effettivo avvio dell’applicazione A. L’inizializzazione del nuovo oggetto sessione SO comporta anche la creazione e l’inizializzazione di una nuova istanza della classe interfacce di sessione WG (cioà ̈ un nuovo oggetto interfaccia di sessione WGP) che a sua volta crea e inizializza istanze di tutte le classi associate necessarie all’avvio (classe controllo base BC, classe identificatori H, classe risposte R), del sincronizzatore risposte 27 e del sincronizzatore esecuzione 28.

Terminata l’esecuzione della funzione di avvio locale RA, la funzione di avvio remoto SL_RWA chiama un metodo della classe interfacce di sessione WG che restituisce il codice HTML da inviare al navigatore web 7 per inizializzare l’interfaccia utente grafica 13 e caricare il motore client 11 sulla piattaforma client 5. Una volta caricato, il motore client 11 effettua una chiamata alla classe principale contenente la dichiarazione del metodo Main dell’applicazione A, utilizzando il protocollo descritto. In particolare, l’identificatore H passato come parametro nella chiamata à ̈ il valore nullo, che viene considerato come un indirizzamento direttamente all’oggetto interfaccia di sessione WGP associato alla sessione dell’applicazione A di cui à ̈ in corso l’avvio. In questo modo, viene creata un’istanza della classe principale dell’applicazione A e viene chiamato il metodo Main() utilizzando come parametro il corrispondente oggetto interfaccia di sessione WGP.

La figura 10 mostra un Sequence Diagram UML relativo al flusso di esecuzione principale dell’applicazione A nell’architettura 1 una volta esaurita la fase di avvio. Sul lato client, quindi, l’interfaccia utente grafica 13 à ̈ stata inizializzata e contiene componenti grafici interattivi di client 14 a cui corrispondono componenti grafici interattivi di server BC1, …, BCM nel server applicazioni 8. I componenti grafici interattivi di client 14 sono quindi disponibili all’utente per interagire con l’applicazione A.

In seguito a un evento, il modulo trasmissione comandi 11a del motore client 11 invia al motore server 10 un messaggio client/server MCS contente l’identificatore H di uno specifico componente grafico interattivo di server BCI, corrispondente al componente grafico interattivo di client 14 che ha scatenato l’evento, e il nome di un metodo da eseguire (o di una proprietà da modificare, secondo il tipo di comando da eseguire sul componente grafico interattivo di server BC1, …, BCM). La funzione di esecuzione comandi SL_EX viene chiamata dal motore server 10 e invia i parametri del comando da eseguire all’oggetto interfaccia di sessione WGP associato alla sessione corrente dell’applicazione A. L’oggetto interfaccia di sessione WGP, a sua volta, interroga l’identificatore H per ricevere in risposta un puntatore al componente grafico interattivo di server BCI, che effettua quindi una chiamata al metodo indicato nel messaggio client/server MCS ricevuto (o modifica una proprietà). Eventuali modifiche da apportare all’interfaccia utente grafica 13 vengono inserite nella collezione di oggetti risposta R1, …, RN della classe risposte R mediante un apposito metodo di aggiunta. Terminata l’esecuzione del comando associato all’evento, l’oggetto interfaccia di sessione WGP effettua una chiamata a un metodo della classe risposte R che restituisce il codice HTML rappresentativo delle modifiche da apportare all’interfaccia utente grafica 13. Il codice HTML così ottenuto viene utilizzato per costruire un messaggio server/client MSC di risposta all’evento scatenato, che viene inviato alla piattaforma client 5 attraverso la funzione di esecuzione comandi SL_EX. Il messaggio server/client MSC viene quindi inviato al modulo di trasmissione comandi 11a del motore client 11 ed eseguito dal modulo esecutore 11b, che determina le modifiche dell’interfaccia utente grafica 13 come specificato nel messaggio server/client MSC. In particolare, quando sul lato server viene aggiunto un nuovo componente grafico interattivo di server BC1, …, BCM (e viene ad esso assegnato un nuovo oggetto identificatore H1, …, HM) il modulo esecutore 11b crea un nuovo componente grafico interattivo di client 14, associandolo allo stesso oggetto identificatore H1, …, HM (eventualmente, tramite l’etichetta). Se invece l’esecuzione di un comando lato server ha determinato una modifica di un componente grafico interattivo di server BC1, …, BCM, la modifica indicata nel messaggio server/client MSC viene applicata al componente grafico interattivo di client 14 associato al corrispondente oggetto identificatore H1, …, HM.

In pratica, la creazione o la modifica (inclusa la cancellazione) di un componente grafico interattivo di server BC1, …, BCM, raccolta in uno o più oggetti risposta R1, …, RN, dà luogo automaticamente alla creazione o alla modifica di un corrispondente componente grafico interattivo di client 14, mediante la creazione di un messaggio server/client MSC che viene ricevuto, interpretato ed eseguito dal modulo di trasmissione comandi 11a e dal modulo esecutore 11b del motore client 11.

Viceversa, ogni azione di un utente su un componente grafico interattivo di client 14, ossia ogni comando impartito attraverso l’interfaccia utente grafica 13, viene automaticamente convertito in un comando che origina l’esecuzione di una procedura da parte di un corrispondente componente grafico interattivo di server BC1, …, BCM sul server applicazioni 8.

I componenti grafici interattivi di server BC1, …, BCM risultano così accoppiati a corrispondenti componenti grafici interattivi di client 14, in modo che le azioni sull’interfaccia utente grafica 13 siano automaticamente convertite in procedure dell’applicazione A eseguite o almeno innescate dai componenti grafici interattivi di server BC1, …, BCM; e in modo che le modifiche conseguenti all’esecuzione di tali procedure siano automaticamente convertite in modifiche di corrispondenti componenti grafici interattivi di client 14 nell’interfaccia utente grafica 13.

Di conseguenza, la gestione dei componenti grafici di client 14 remoti viene mascherata dall’architettura 1 e il progetto delle applicazioni web distribuite può in sostanza essere condotto come il progetto di un’applicazione locale (applicazione desktop), prescindendo dal fatto che l’esecuzione e il controllo dell’utente avvengono tramite macchine separate. Oltre alla maggiore flessibilità e al minor carico per il progettista nello sviluppo di applicazioni web, l’architettura 1 permette di eliminare gli errori nella gestione del trasferimento di comandi e modifiche dell’interfaccia grafica fra piattaforma server e piattaforma client. Questo compito, infatti, à ̈ sottratto al diretto controllo del progettista e realizzato in modo automatico dall’architettura 1.

La figura 11 à ̈ un Sequence Diagram UML che illustra la sospensione temporanea del flusso di esecuzione principale dell’applicazione A. Come accennato in precedenza, il motore server 10 si serve del modulo di controllo risposte 24 e del modulo di controllo esecuzione 25, coordinati dal sincronizzatore risposte 27 e dal sincronizzatore esecuzione 28.

In dettaglio, quando il modulo di controllo risposte 24 riceve una richiesta di eseguire un comando dalla piattaforma client 5, la chiamata viene passata a una prima istanza 25.1 del modulo di controllo esecuzione 25, che provvede all’esecuzione (Execute()). Inoltre, il modulo di controllo risposte 24 si pone in attesa (Wait()) e comunica il proprio stato di attesa al sincronizzatore risposte 27.

Selettivamente quando l’esecuzione della chiamata comporta una sospensione, ad esempio in attesa di una conferma da parte dell’utente, la prima istanza 25.1 del modulo di controllo esecuzione 25 si pone a sua volta in attesa (Wait()), informando il sincronizzatore esecuzione 28, e richiede al sincronizzatore risposte 27 di notificare (Notify()) la condizione di pausa anche al modulo di controllo risposte 24. In risposta alla notifica, il modulo di controllo risposte 24 si disattiva e la sua esecuzione termina, dopo aver inviato al motore client 11 tutti gli oggetti risposta R1, …, RN raccolti.

Successivamente, quando l’utente esegue l’azione richiesta, il motore client 11 invia un nuovo messaggio client/server MCS con la richiesta di effettuare una chiamata a un metodo corrispondente. In seguito alla richiesta, il modulo di controllo risposte 24 viene riattivato e passa la chiamata a una seconda istanza 25.2 del modulo di controllo esecuzione 25 (Execute()), mentre la prima istanza 25.1 à ̈ ancora attiva, in attesa. Quindi, il modulo di controllo risposte 24 si pone in stato di attesa (Wait()) e informa il sincronizzatore risposte 27 di conseguenza. La seconda istanza 25.2 del modulo di controllo esecuzione 25 esegue la chiamata, fino al termine. La seconda istanza 25.2 del modulo di controllo esecuzione 25 richiede al sincronizzatore esecuzione 28 di notificare (Notify()) il termine dell’esecuzione alla prima istanza 25.1 del modulo di controllo esecuzione 25, che viene “risvegliata†. La prima istanza 25.1 del modulo di controllo esecuzione 25 riprende e termina l’esecuzione, richiedendo al sincronizzatore risposte 27 di notificare (Notify()) termine dell’esecuzione al modulo di controllo risposte 24, che cede il controllo e termina a sua volta.

Si noti che il sincronizzatore esecuzione 28 opera come una pila di istanze, per consentire un numero arbitrario di sospensioni nidificate dell’esecuzione del flusso principale. In altre parole, se anche il metodo eseguito dalla seconda istanza 25.2 del modulo di controllo esecuzione 25 richiede un’azione da parte dell’utente, la seconda istanza 25.2 può avviare una terza istanza e mettersi in stato di attesa come descritto, fino al termine della procedura eseguita dalla terza istanza, e così via.

Risulta infine evidente che all’architettura descritta possono essere apportate modifiche e varianti, senza uscire dall’ambito della presente invenzione, come definito nelle rivendicazioni allegate.

Claims (11)

1. RIVENDICAZIONI 1. Architettura di applicazioni distribuite comprendente: un piattaforma server (2), avente un server applicazioni (8) residente; una piattaforma client (5), provvista di un navigatore web (7) per la connessione con la piattaforma server (2); almeno un’applicazione (A) residente sulla piattaforma server (2); e un’interfaccia utente grafica (13), caricabile sulla piattaforma client (5) e modificabile dal server applicazioni (8); caratterizzato dal fatto di comprendere: per ogni sessione dell’applicazione (A), componenti grafici interattivi di server (BC1, …, BCM) associati all’applicazione (A) e residenti sulla piattaforma server (2); componenti grafici interattivi di client (14), residenti sulla piattaforma client (5) e visualizzabili tramite l’interfaccia utente grafica (13); e mezzi di accoppiamento (H, H1, …, HM, 11a, 11b, 21, 24, SL_EX), configurati per accoppiare univocamente ciascun componente grafico interattivo di server (BC1, …, BCM) a un rispettivo componente grafico interattivo di client (14), in modo da causare l’esecuzione di procedure da parte dei componenti grafici interattivi di server (BC1, …, BCM) in risposta a comandi impartiti tramite rispettivi componenti grafici interattivi di client (14), e in modo da causare modifiche dei componenti grafici interattivi di client (14) in risposta a modifiche dei corrispondenti componenti grafici interattivi di server (BC1, …, BCM), prodotte dall’esecuzione delle procedure.
2. 2. Architettura secondo la rivendicazione 1, in cui il server applicazioni (8) comprende un motore server (10), residente sulla piattaforma server (2), e un motore client (11), caricabile sulla piattaforma client (5) in risposta a una richiesta di avvio dell’applicazione (A).
3. 3. Architettura secondo la rivendicazione 2, in cui i mezzi di accoppiamento (H, H1, …, HM, 11a, 11b, 21, 24, SL_EX) comprendono: un modulo costruttore (21), configurato per creare, per ogni componente grafico interattivo di server (BC1, …, BCM), un rispettivo identificatore (H1, …, HM) univocamente associato; e un modulo esecutore (11b), incorporato nel motore client (11) e configurato per creare un nuovo componente grafico interattivo di client (14), in risposta alla creazione di ciascun nuovo componente grafico interattivo di server (BC1, …, BCM), e per associare il corrispondente identificatore (H1, …, HM) al nuovo componente grafico interattivo di client (14).
4. 4. Architettura secondo la rivendicazione 2 o 3, in cui il server applicazioni (8) à ̈ configurato per creare almeno un rispettivo elemento di risposta (R1, …, RN), contenente una collezione di modifiche da applicare all’interfaccia utente grafica (13), in risposta a modifiche dei componenti grafici interattivi di server (BC1, …, BCM).
5. 5. Architettura secondo la rivendicazione 4, in cui i mezzi di accoppiamento (H, H1, …, HM, 11a, 11b, 21, 24, SL_EX) comprendono mezzi di controllo risposte (24, SL_EX), configurati per costruire messaggi server/client (MSC) contenenti gli elementi di risposta (R1, …, RN) e elementi identificatori (H1, …, HM) corrispondenti a componenti grafici interattivi di server (BC1, …, BCM) modificati in risposta all’esecuzione delle procedure.
6. 6. Architettura secondo la rivendicazione 5, in cui: l’interfaccia utente grafica (13) à ̈ configurata per generare, in risposta a un’azione su uno dei componenti grafici interattivi di client (14), messaggi evento (EM) indicativi dell’azione e del componente grafico interattivo di client (14) azionato; e i mezzi di accoppiamento (H, H1, …, HM, 11a, 11b, 21, 24, SL_EX) comprendono un modulo trasmissione comandi (11a), incorporato nel motore client (11) e configurato per ricevere dall’interfaccia utente grafica (13) i messaggi evento (EM) e per costruire messaggi client/server (MCS) indicativi dell’azione e del componente grafico interattivo di client (14) associati ai messaggi evento (EM) ricevuti.
7. 7. Architettura secondo una qualsiasi delle rivendicazioni precedenti, in cui il server applicazioni (8) comprende un modulo di controllo risposte (24), un sincronizzatore risposte (27) e un modulo di controllo esecuzione (25), e in cui: il modulo di controllo risposte (24) à ̈ attivabile da una richiesta di esecuzione comandi (MCS) dalla piattaforma client (5) e disattivabile, in risposta a una notifica dal sincronizzatore risposte (27), ed à ̈ configurato per attivare una prima istanza (25.1) del modulo di controllo esecuzione (25), in risposta alla richiesta di esecuzione comandi (MCS), per entrare in uno stato di attesa dopo aver attivato la prima istanza (25.1) del modulo di controllo esecuzione (25) e per comunicare il proprio stato di attesa al sincronizzatore risposte (27); e il modulo di controllo esecuzione (25) à ̈ configurato in modo che la prima istanza (25.1) esegua un comando associato alla richiesta di esecuzione comandi (MCS) e richieda al sincronizzatore risposte (27) di inviare una notifica al modulo di controllo risposte (24).
8. 8. Architettura secondo la rivendicazione 7 dipendente dalla rivendicazione 5, in cui il modulo di controllo risposte (24) à ̈ incorporato nei mezzi di controllo risposte (24, SL_EX) ed à ̈ inoltre configurato per creare un messaggio server/client (MSC) in risposta a una notifica dal sincronizzatore risposte (27), prima della disattivazione.
9. 9. Architettura secondo la rivendicazione 7 o 8, in cui una seconda istanza (25.2) del modulo di controllo esecuzione (25) Ã ̈ attivabile mentre la prima istanza (25.1) del modulo di controllo esecuzione (25) Ã ̈ attiva.
10. 10. Architettura secondo la rivendicazione 9, in cui il server applicazioni (8) comprende un sincronizzatore esecuzione (28) e in cui: il modulo di controllo esecuzione (25) à ̈ configurato in modo che la prima istanza (25.1) entri in uno stato di attesa, selettivamente quando l’esecuzione di un comando associato alla richiesta di esecuzione comandi (MCS) comporta una sospensione, comunichi il proprio stato di attesa al sincronizzatore esecuzione (28) e richieda al sincronizzatore risposte (27) di inviare una notifica al modulo di controllo risposte (24); e il modulo di controllo esecuzione (25) à ̈ inoltre configurato in modo che la seconda istanza (25.2) richieda al sincronizzatore esecuzione (28) di inviare una notifica alla prima istanza (25.1).
11. 11. Architettura secondo la rivendicazione 10, in cui il modulo di controllo esecuzione (25) Ã ̈ configurato per consentire la sospensione almeno della prima istanza (25.1) e terminare la sospensione almeno della prima istanza (25.1) in risposta a una notifica dal sincronizzatore esecuzione (28).