Progettazione ed implementazione di un tool per lo sviluppo di applicazioni in Esperanto

Transcript

1 Università degli studi di Napoli Federico II Facoltà di Ingegneria Corso di laurea in Ingegneria Informatica Capri Feb Progettazione ed implementazione di un tool per lo sviluppo di applicazioni in Esperanto Relatore Ch.mo Prof. Domenico Cotroneo Correlatore Ing. Armando Migliaccio Candidato Marco Zaccheria Matricola 41/2798

2 ::. Contesto Capri Feb Nomadic Computing: quali sono le problematiche? Scalabilità Eterogeneità Fault tolerance Carico computazionale leggero Context adaptation Un middleware classico non è adatto ad ambienti di questo tipo Esperanto: il problema può essere risolto Supporto alla mobilità Supporto alla dinamicità

3 Middleware di tipo service oriented Comunicazione tramite un ORB (simile a CORBA) Modello a spazi di tuple ::. Caratteristiche di Esperanto Capri Feb Ma c è molto di più Capacità di adattare il funzionamento al contesto La comunicazione va a buon fine anche in caso di cadute temporanee di collegamento (disaccoppiamento nello spazio e nel tempo) Handover (un device può cambiare dominio applicativo) Inoltre la differenza tra servente e cliente tende ad assottigliarsi Oltre ai normali paradigmi tipici delle architetture di tipo Client-Server, la comunicazione può essere iniziata da un server verso più clients che detengono l implementazione del servizio

4 ::. Esperanto: problematiche Capri Feb La comunicazione con Esperanto avviene tramite l utilizzo di una coppia di moduli Stub e Skeleton (lato cliente e lato servente) CLIENT stub skeleton SERVER skeleton stub In Esperanto la differenza tra client e server si assottiglia, in quanto non è sempre il client ad iniziare la comunicazione e non è sempre il server a implementare i servizi distribuiti. Il codice è complesso (caratteristiche innovative) E fondamentale uno strumento per la generazione automatica del codice Fino ad oggi la programmazione in Esperanto avveniva tramite un processo di programmazione manuale dei moduli Stub e Skeleton

5 ::. Obiettivo Capri Feb Realizzare un tool di supporto al programmatore per Supportare il programmatore nella fase di descrizione dei servizi Generare delle descrizioni intermedie dei servizi (E-IDL e tuple XML) Generare automaticamente il codice degli Stub e Skeleton necessari Fornire gli strumenti necessari alla compilazione del codice Il tutto tramite Una interfaccia semplice nella comprensione e nell utilizzo Una struttura descrittiva isomorfa al linguaggio E-IDL

6 ::. E-Serv : l idea Capri Feb Services Vincoli strutturali (è necessario che ) un servizio abbia come figli solo funzionalità una funzione abbia come figli solo operandi un operando non abbia figli su uno stesso livello ci siano solo nodi dello stesso tipo Function 1 Serv 1 Function 2 Serv n Function L Operand 1 Operand 2 Operand M Vincoli sugli attributi (è necessario che ) per ogni servizio si possa indicare il suo nome per ogni funzione si possano indicare il nome, la tipologia e il tipo del parametro di ritorno per ogni operando si possano indicare il nome, il tipo e il verso (a scelta tra in, out e inout) E-serv è realizzato in Java

7 Centro commerciale intelligente ::. Un esempio completo: ShoppingMall Capri Feb I negozi offrono servizi relativi ai prodotti in vendita I clienti interagiscono tramite dispositivi mobili Alcuni servizi : Un negozio può informare tutti i clienti sulle proprie promozioni Un negozio può inviare un offerta ad un particolare cliente, il quale può accettare o rifiutare impostanick() inviaofferta() Negozio inviapromozione() Client impostanick() nameserver Può Esperanto fornire nativamente gli strumenti per implementare tali funzionalità? Client

8 ::. Paradigmi Push-Based Capri Feb Tipologia One-Way Il client richiama la funzione sullo Stub Lo Stub trasmette il messaggio Lo Skeleton consegna il messaggio al Server Client Stub ORB Skeleton Server Tipologia Request/Response Il client richiama la funzione sullo Stub Lo Stub trasmette il messaggio Lo Skeleton consegna il messaggio al Server Client Stub ORB Skeleton Server Lo Skeleton trasmette la risposta Lo Stub consegna al Client la risposta

9 La comunicazione è di gruppo ::. Paradigmi Pull-Based Capri Feb Concetto di GRUPPO ATTIVO Tipologia Notify Il server richiama la funzione sullo Stub Lo Stub trasmette il messaggio Gli Skeleton dei client appartenenti al gruppo attivo consegnano il messaggio Server Stub ORB Skeleton Client 1 Skeleton Client n Tipologia Solicit/Response Il server richiama la funzione sullo Stub sollecitando un gruppo di client Lo Stub trasmette il messaggio Gli Skeleton consegnano il messaggio Gli Skeleton trasmettono la risposta Server Stub ORB Skeleton Client 1 Lo Stub alla scadenza di un Time-Out consegna al Server le risposte Skeleton Client n Non è detto che tutti i client rispondano, o che lo facciano in tempo!

10 ::. E-Serv : interfaccia utente Capri Feb Pulsanti per l apertura e creazione dei progetti Pulsanti per il salvataggio dei progetti Pulsanti per la generazione Pannello per la visualizzazione delle descrizioni Pulsanti per la gestione dell albero Albero dei servizi Progetto

11 ::. Gestione dell albero dei servizi Capri Feb nodo service nodo function nodo operand Operazioni Inserimento nuovo nodo Rimozione nodo esistente Modifica nodo esistente Tutte le operazioni sono guidate dall interfaccia grafica; Non sono ammessi valori illeciti per i campi della descrizione; Le operazioni variano in base al nodo selezionato.

12 ::. Gestione dei files di progetto Capri Feb E-serv permette di salvare la struttura dell albero dei servizi in un file di progetto. Apertura file Salvataggio file Creazione di un nuovo progetto Il file di progetto è salvato in formato XML

13 ::. Approccio alla generazione del codice Capri Feb Ogni file del codice sorgente viene generato tramite una sostituzione di punti di entrata (entry-points) all interno di descrizioni generali di codice (prototypes). Processo di generazione Linee di codice indipendenti dalla struttura dei servizi Linee di codice variabili in base alla struttura dei servizi Codice %ENTRY% Gli header files vengono creati tramite una sostituzione immediata delle entries I files.cpp vengono creati in due fasi tramite dei prototype di secondo livello

14 ::. Sostituzione delle entries: esempio pratico 14 Generazione del header file di uno stub lato client Capri Feb %FUNCTION_LIST% %service_name% shoppingmall bool impostanick(const string& nick) throw (EsperantoException); Prototype_StubC_h namespace stubc { class %service_name% _ptr; class %service_name% { public: %FUNCTION_LIST% private: %service_name%(const PeerId& service); namespace stubc { class shoppingmall_ptr; class shoppingmall { public: bool impostanick(const string& nick) throw (EsperantoException); private: shoppingmall(const PeerId& service);

15 Eserv: strumento per la descrizione dei servizi Simile a IDL, ma più semplice e intuitivo Guidato (non si possono commettere errori di descrizione) ::. Conclusioni e sviluppi futuri Capri Feb Non è necessario conoscere la sintassi di alcun linguaggio di descrizione Ma Minore efficacia di un compilatore E-IDL nel caso in cui ci siano parecchie regole di mapping Possibili sviluppi futuri Aumentare le regole di traduzione e i parametri dei servizi Generare il codice in altri linguaggi OO (primo tra tutti Java) Aggiungere la funzionalità di compilazione di codice E-IDL (manca solo il Parser!)