Università degli Studi del Sannio

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università degli Studi del Sannio"

Transcript

1 Università degli Studi del Sannio Facoltà di Ingegneria Relazione di Fine Master SVILUPPO DI UNA APPLICAZIONE JAIN SLEE COMPLIANT Relatore Prof. Eugenio Zimeo Candidato Compagno Giancarlo Anno Accademico 2003/

2 Alla mia famiglia 2

3 Capitolo 1: Il Project Work Aziendale Introduzione Contesto di riferimento Strutturazione del lavoro Capitolo 2: JAIN SLEE Introduzione I Modelli di JSLEE Modello a componenti Modello ad eventi SBB Activity e Activity Context Resource adaptors Capitolo 3: Service Delivery Platform di riferimento Introduzione La SDP di riferimento Capitolo 4: L applicazione Delivery & Charging di SMS Introduzione L Architettura della applicazione JSLEE Scelte di progetto Il Sistema Proposto Il ruolo dell Activity e Activity Context Gestione degli eventi provenienti dall esterno Appendice A: La piattaforma J2EE...39 A.1 Introduzione A.2 La piattaforma Java 2 Enterprise Edition A.2.1 Enterprise Java Beans A Session Bean A Entity Bean A Message-Driven Bean A.2.2 Servlet A.2.3 Interazione tra J2EE e JSLEE Appendice B: Come installare l applicazione...50 B.1 Introduzione B.2 Materiale di supporto per L Application Server J2EE e il Client http B.3 Processo di installazione dell Application Server J2EE e del Client HTTP B.4 Materiale di supporto per L Application Server Rhino_sdk B.5 Processo di installazione dell Application Server Rhino_sdk Ringraziamenti...74

4 Capitolo 1: Il Project Work Aziendale 1.1 Introduzione Lo scopo di questo PWA è affrontare, attraverso la realizzazione di un prototipo di SDP (Service delivery platform) per il Delivery di Short Message, problematiche inerenti alle realizzazione di servizi per TLC, in particolare all ambito dei Servizi a Valore Aggiunto, utlizzando il paradigma di progettazione e programmazione delle specifiche JAIN SLEE. A tal fine si è potuto usufruire del contributo dell operatore telefonico Wind, attraverso le documentazioni fornite e l interessamento dimostrato per questo lavoro. L architettura di riferimento offerta da Wind, ha permesso di evidenziare alcune delle principali problematiche che presenta un prodotto come un SDP. Si è quindi cercato di realizzare un prototipo che corrispondesse alle interfacce della SDP fornita da Wind, concentrandosi sulla realizzazione di alcune funzionalità principali. I test svolti su tale lavoro sono stati di natura funzionale, e non prestazionale, in quanto non era questo lo scopo dell applicazione. Questa applicazione software ha come obbiettivo, quello di presentare una applicazione basata su specifiche JAIN SLEE. Per la realizzazione si è utilizzata l infrastruttura software JAIN SLEE compliant e la documentazione messa a disposizione da OpenCloud (compagnia alla guida, insieme a Sun, del working group che lavora alle specifiche JAIN SLEE). Il contesto di riferimento è il mercato italiano delle telecomunicazioni, che sta vivendo un intensa fase di

5 competizione tra operatori. Da un lato vi è infatti battaglia tra operatori fissi e mobili per le quote di mercato dei tradizionali servizi voce; dall altro entrambi i segmenti si sfidano nello sviluppo di strategie di crescita per aumentare l incidenza dei servizi a valore aggiunto (VAS). 1.2 Contesto di riferimento Per capire meglio quelli che sono i numeri e le motivazioni che spingono gli operatori di telefonia mobile verso la ricerca di nuove architetture per l implementazione e il rilascio di servizi a valore aggiunto, utilizzeremmo lo studio condotto dalla scuola di ingegneria gestionale del Politecnico di Milano sulla diffusione in Italia dei servizi, tramite i telefoni, Mobile VAS. Uno scenario complesso, del quale il Politecnico ha analizzato da un lato i principali fenomeni di trasformazione in atto e, dall'altro, ha tentato di delineare alcune possibili direzioni di sviluppo. Per servizi a valore aggiunto in realtà, sono semplicemente di tutte quelle applicazioni, differenti dal tradizionale servizio voce, che i possessori di telefonini utilizzano. Tra queste, SMS, MMS, video, giochi Java, suonerie polifoniche, screensaver e browsing su Internet. I semplici messaggi di testo, gli SMS, rappresentano ancora la killer application per i telefoni cellulare. Tuttavia, l'osservatorio, che ogni anno, a partire dal 2000, tiene sotto controllo il mercato, ha registrato una riduzione di quelle aziende che offrono servizi basati su questo media, che sono passate da 339 dell'anno 2002 a 143 dell anno

6 2003. Il fatto è dovuto principalmente all'interruzione di servizi basati sui cosiddetti dialer, quelli che si attivano tramite pc e che consentono di scaricare applicazioni una volta installato un software. La maggior parte dei servizi offerti dagli SMS, inoltre, oggi, è a pagamento (91%). Tra questi fondamentalmente gli utenti scaricano servizi di personalizzazione del proprio cellulare (loghi e suonerie) e di intrattenimento, tutti offerti più che altro dagli operatori di telefonia mobile (Telecom Italia Mobile, Vodafone Omnitel, Wind, 3). Figura 1.1: Tipologia di contenuto per gli sms

7 I contenuti più apprezzati sono l'infotainment (servizi che offrono informazione ed entertainment) e tutti quelli riconducibili sotto la voce Personalizzazione (loghi, suonerie e wallpaper). Il loro peso è, rispettivamente, del 34% e del 27%. Seguono, in terza posizione, i servizi di comunicazione e di community (chat, contenuti da inviare ecc., 17%). I giochi (15%) e i servizi di voting (4%) pure rappresentano quote interessanti. Se guardiamo alla tecnologia utilizzata, la maggior parte di questo mercato è costituito dai servizi basati su Sms (64%). Iniziano tuttavia a far sentire il loro peso altre tipologie di servizi, in particolar modo quelli di Micro-Browsing (20%) e i servizi di Download, in cui rientrano suonerie polifoniche, wallpaper, video e giochi Java (14%, di cui il 3% fa capo ai giochi Java). Gli MMS stentano ancora a decollare (2%) benché molti siano convinti che un domani saranno sfruttati per tutte le loro potenzialità, in particolare quelle legate al video. I servizi via MMS attualmente esistenti nel nostro Paese sono 101, contro i degli SMS e sono offerti quasi esclusivamente dagli operatori. Gli MMS sono tutti a pagamento e costano tra i quattro centesimi e i due euro. Forse è il costo ancora troppo elevato a indurre gli utenti a farne un utilizzo limitato. Il download di suonerie, screensaver, video e giochi Java, tutti servizi a pagamento, stranamente sta riscontrando grande successo. Sono i giochi disponibili, mentre solo 64 i servizi di suonerie e 50 di video. La maggior parte di questi servizi vengono attivati tramite telefono fisso e non via cellulare e costano tra i due e i sei euro

8 ciascuno. Ultimamente, però, vi si accede anche attraverso il mobile portal (come quello di 3, per esempio). E' proprio grazie al portale mobile che sono esplosi i servizi di browsing, basati cioè sulla navigazione dei portali di 3 e Vodafone Live! dell'omonimo gestore. I servizi di questo tipo nell'ultimo anno si sono triplicati, passando da 353 a Nel 2003 sono nati anche i primi servizi di consultazione a pagamento (14%), un obiettivo che gli operatori si erano prefissati fin dai tempi del Wap. Un altro trend in crescita nel corso del 2003 è stato l'utilizzo dei numeri brevi (es di TIM, di Vodafone ecc) da parte di molte aziende che offrono servizi via cellulare. Il numero breve è stato ampiamente sfruttato per iniziative di diverso genere, dal televoto, per esempio, al versamento di un contributo per venire in aiuto ai connazionali, e via dicendo. Un servizio in forte espansione nei prossimi anni, prevedono gli esperti. Il volume d'affari dei servizi a valore aggiunto è stimato a circa 400 milioni di euro, con un incremento del 61% rispetto al 2003 e un aumento del fatturato degli operatori di telefonia mobile del 100%. Il futuro è condizionato dall'evoluzione dei terminali, ai quali gli operatori imputano colpe e responsabilità per qualsiasi cosa non funzioni, e dal costo dei servizi che attualmente è troppo elevato perché sia sfruttato dalla massa. C'è ancora spazio per ulteriori applicazioni, come i sistemi di localizzazione (GPS) e lo sviluppo di servizi per le auto.

9 Figura 1.2: Mobile VAS Rapporto 2003 Intanto, però, ogni operatore ha e continua a credere nella propria filosofia, consentendo sì all'utente di scegliere la linea che più preferisce, ma creando al contempo, ancora più confusione dovuta alla mancanza di interazione e di compatibilità l'una con l'altra. Pertanto, Vodafone Omnitel ha e promuove il suo Vodafone Live!, un portale mobile che offre servizi a pagamento, un Wap abbellito, insomma. TIM punta su MMS e sul nuovo servizio di Tv sul cellulare - servizio che ha già sollevato polemiche per il timore di dover pagare un canone Tv per la visione di programmi televisivi sul cellulare -, mentre 3 regala il videofonino - la sua filosofia è cellulare gratis per tutti -per usufruire dei servizi video (videochiamata, videomessaggio, videogoal) che differenziano il quarto operatore italiano dai restanti competitor. Wind, infine, ha importato il sistema i-mode dal Giappone, puntando tutto sul traffico telefonico.

10 1.3 Strutturazione del lavoro Il lavoro svolto ha richiesto essenzialmente - una fase di studio delle API JAIN SLEE, cioè le API del Service Logic Execution Enviroment, l ambiente dedicato ad ospitare la logica dei servizi di cui verranno riportate le principali caratteristiche del modello di programmazione utilizzato da JAIN SLEE e le motivazioni che hanno portato alla sua definizione. - una fase di studio delle problematiche da prendere in considerazione durante lo sviluppo di una SDP utilizzando come spunto le soluzioni proprietarie di un operatore di TLC. - una fase per lo sviluppato un servizio di messaggistica, in particolare un servizio di gestione degli Short Message di tipo Application-To-Person, che tenesse conto di un contesto architetturale reale in cui potrebbe essere collocato, conforme alle specifiche JAIN SLEE, per poter testare da un punto di vista funzionale il modello di programmazione utilizzato da un Application Server JAIN SLEE compliant.

11 Capitolo 2: JAIN SLEE 2.1 Introduzione La nascita della piattaforma JSLEE deriva dalla esigenza degli sviluppatori di affidare, alcuni aspetti non strettamente legati all implementazione del servizio, ma dipendenti dalla natura intrinseca di servizio asincrono e con bassi livelli di latenza al Container. La piattaforma JSLEE, Jain Service Logic Execution Environmet, può essere basata su un Application Server standard come J2EE oppure su un AS proprietario specializzato in applicazioni di TLC o ancora può essere realizzato un AS compliant con le specifiche JSLEE. JAIN JSLEE è un set di specifiche Java pubbliche, facenti parte delle API JAIN. Come ogni prodotto basato su Java, un applicazione conforme alle specifiche JAIN SLEE segue la filosofia di Java Write Once, Run Anywhere La sua funzione è di importanza centrale in quanto esso costituisce l ambiente logico e di esecuzione in cui le applicazioni sono impiegate per utilizzare le varie risorse di rete definite da altre API JAIN. Le specifiche SLEE sono pensate per Application Server scalabili, che possano girare su un cluster al fine di migliorare le prestazioni e sostenere grandi carichi di lavoro. Le applicazioni possono così essere distribuite su più macchine, ma questo risulta del tutto trasparente allo sviluppatore, il quale dovrà preoccuparsi solo ed esclusivamente della 11

12 logica del servizio, mentre l ambiente si occuperà di tutto il resto. L ambiente gestisce tutti gli aspetti legati alle performance, alla concorrenza, alle transazioni, ai fallimenti, alla persistenza, all indipendenza dalla locazione, per cui gli sviluppatori non devono comprendere dettagli come il multi-threading, il connection-pooling e altre complesse API di basso livello, così che lo sviluppo di applicazioni sia il più semplice e veloce possibile. Il modello definito è un modello a componenti, per strutturare la logica applicativa dei servizi come una collezione di componenti object-oriented riusabili, e per poterli comporre in servizi di più alto livello e più sofisticati. Ciascun componente contiene solo la logica applicativa, mentre tutto il resto, compresa la gestione del suo ciclo di vita, è a carico del contenitore. Figura 2.1: I livelli dell architettura JAIN SLEE Il livello più alto è quello di gestione (management layer) e specifica il meccanismo tramite cui un amministratore gestisce l ambiente e i servizi (il ciclo di vita del sistema,

13 l installazione dei servizi nella piattaforma, la loro attivazione, etc.) e uno sviluppatore di servizi definisce dei dati necessari ad un particolare servizio. Al livello sottostante si trovano i servizi applicativi veri e propri, cioè i componenti e tutto ciò che li riguarda strettamente, in un contesto in cui l ambiente gestisce in automatico tutto ciò che serve alla loro esecuzione. Il livello sottostante è quello in cui sono collocate le componenti messe a disposizione dello sviluppatore da parte dell ambiente: questo comprende il servizio di routing degli eventi, un set di facilities, dei meccanismi per definire e utilizzare profili, etc. Al livello più basso ci sono i resource adaptors, che sono i componenti attraverso i quali è realizzata effettivamente l interazione tra le applicazioni e l esterno. I resource adaptors adattano le risorse esterne ai requisiti di SLEE, facendo in modo che queste comunichino con l ambiente tramite eventi e mettendo a disposizione delle applicazioni le API per comunicare con le risorse esterne. In tal modo si realizza l indipendenza del modello di programmazione dal particolare protocollo di rete, dalla particolare API o topologia di rete. 2.2 I Modelli di JSLEE La definizione delle richieste sotto forma di eventi ha permesso di progettare e ottimizzare le specifiche di SLEE per applicazioni orientate agli eventi. La differenza tra sistemi orientati agli eventi e sistemi così detti enterprise ha motivato la definizione delle specifiche JAIN SLEE nell ambito del Java Community Process.

14 Queste differenze hanno portato alla definizione delle caratteristiche principali di JAIN SLEE: - Modello a componenti - Modello ad eventi Il modello a componenti di SLEE richiama il modello degli Enterprise JavaBeans, EJB, ma, oltre alla fondamentale differenza che la programmazione degli EJB non è basata su eventi, SLEE non ne eredita tutte le caratteristiche della J2EE poiché deve essere un ambiente leggero, specializzato in elaborazioni veloci, a bassa latenza e ad alte prestazioni che non richiedono le complete funzionalità offerte dalla piattaforma Enterprise Modello a componenti Il principio fondamentale su cui si basa il modello a comportamento è la possibilità di definire e comporre servizi semplici per realizzare servizi complessi. Con tale approccio è possibile riutilizzare e estendere facilmente i servizi semplici per comporre servizi nuovi. Un componente in SLEE, che permette di implementare un servizio, è chiamato Service Building Block (SBB) ed è ospitato da un contenitore, il quale a tempo di esecuzione si occupa della gestione del suo ciclo di vita, dell interazione con le risorse esterne e degli aspetti che riguardano la concorrenza, la sicurezza, la persistenza e le transazioni. Affinché l ambiente possa fornire questo supporto, l SBB deve rispettare precisi vincoli di programmazione (ad esempio deve implementare una specifica interfaccia, la sintassi

15 dei nomi dei metodi che gestiscono gli eventi deve rispettare un particolare formato etc.) e deve essere accompagnato da un deployment descriptor (un file XML conforme ad una specifica DTD), destinato a contenere delle informazioni che servono all ambiente nel momento in cui avviene l installazione del componente per poter generare il codice che implementa la logica di supporto. Un applicazione è realizzata componendo un insieme di SBB, e mostra verso l esterno un interfaccia costituita dal set di eventi che essa è in grado di gestire tramite i suoi componenti. Chiaramente ciascun SBB può essere composto con altri in modo diverso, e questo permette un riuso facile dei componenti preesistenti e lo sviluppo veloce di servizi nuovi tramite la composizione di vecchie componenti con altre, eventualmente sviluppate ad hoc Modello ad eventi Un SBB è in grado di riceve e gestire richieste che si presentano sotto forma di eventi, che contengono informazioni legate alla sorgente dell evento. Ogni SBB è in grado di gestire gli eventi di cui è a conoscenza e per il quale è legato una richiesta di elaborazione. Gli eventi sono inoltre utilizzati dagli SBB per comunicare tra di loro in modalità asincrona. Quindi ciascun SBB è in grado di gestire un certo insieme di eventi, tramite dei metodi appositi, ed è in grado di generare un altro insieme di eventi. Un applicazione basata su eventi tipicamente non ha un thread di esecuzione attivo ma ha dei metodi che sono invocati quando occorrono gli eventi ed un handler che riceve tutti gli eventi e, tramite un ampia sezione di switch, smista il particolare evento occorso in

16 base al tipo di evento. Nel caso di SLEE esiste un event router che, in maniera del tutto trasparente, si occupa dello smistamento degli eventi ai consumatori che dovranno gestirli; lo smistamento consiste nell invocazione del metodo, di ciascun consumatore, dedicato alla gestione dell evento. Il modello ad eventi utilizzato da SLEE è del tipo publish/subscribe (simile a quello utilizzato da JMS), in base al quale un entità che si sottoscrive per ricevere gli eventi di un certo tipo, riceverà automaticamente questi eventi nel momento in cui un altra entità li pubblica. La caratteristica fondamentale del modello publish/subscribe è il forte disaccoppiamento che c è tra il produttore e il consumatore dell evento. 2.3 SBB Ogni SBB identifica una componente di servizio che è caratterizzata principalmente dal tipo di eventi che è in grado di gestire e dal tipo di eventi che è in grado di generare. Per ciascun evento che è in grado di gestire possiede un metodo handler ad hoc, che implementa la logica da eseguire in seguito all occorrenza dell evento; per ciascun evento che è in grado di generare ha un metodo astratto che sarà poi implementato automaticamente dal sistema in fase di installazione. Un SBB può avere anche un interfaccia locale, che specifica un insieme di metodi invocabili sincronamente dall istanza di un altro componente SBB interno allo stesso albero di istanze (vd. Paragrafo successivo). E importante distinguere tra SBB Entities e SBB Objects:

17 - Una SBB Entity è una istanza di un componente SBB; è una entità logica, che rappresenta lo stato persistente di un SBB (tramite i campi CMP, Container Managed Persistent) e che mantiene le relazioni con le altre entità. La sua rappresentazione potrebbe essere nella memoria del processo in esecuzione, in una memoria replicata, in un disco di storage, etc. - Un SBB Object è un istanza di una classe astratta SBB; è un oggetto Java che si può trovare in diversi stati del suo ciclo di vita (ad es. not exist, pooled e ready). Esso è legato ad una particolare SBB entity per la durata di una invocazione di metodo, nella quale opera per conto della SBB entity e può accedere al suo stato persistente (come se facesse da cache), ma dopo l invocazione del metodo è possibile che l SBB entity esista ancora ma che non abbia un SBB object legato ad essa. Più SBB objects possono rappresentare la stessa SBB entity, ma, pur potendo risiedere nella stessa JVM o in JVM diverse, essi devono operare sulla stessa SBB entity. 2.4 Activity e Activity Context Un Activity è l astrazione di un flusso di eventi generato da una risorsa; questi eventi occorrono in seguito al cambiamento dello stato interno all entità o alla risorsa. Per esempio una chiamata telefonica può essere un Activity. n oggetto Activity è un oggetto Java che può generare eventi e che può mettere a disposizione metodi da usare per interagire con l Activity stessa; tipicamente esso rappresenta una risorsa esterna, infatti ciascun tipo di resource adaptor può definire uno o più tipi di oggetti Activity. Per esempio, un oggetto JccCall è un oggetto Activity che rappresenta una chiamata

18 telefonica (che è l Activity). Un Activity Context è un entità logica all interno di JSLEE che rappresenta ed incapsula al suo interno un oggetto Activity sottostante. Esso funge da bus, su cui vengono generati e da cui vengono ricevuti gli eventi e conserva implicitamente le relazioni tra i produttori e i consumatori che interagiscono con esso. Gli SBB consumatori si sottoscrivono per ricevere gli eventi attaccandosi ad un Activity Context; per cui se un certo SBB gestirà eventi relativi a quel particolare Activity Context 2.5 Resource adaptors Per permettere a SLEE di comunicare con l esterno, (come già avviene per l Application Server J2EE) la platform mette a disposizione una serie di resource adaptors che adattano le risorse esterne ai requisiti di SLEE: la comunicazione dall esterno verso SLEE avviene tramite la generazione di eventi a seguito dei cambiamenti dello stato della risorsa e tramite la consegna di questi eventi all event router; nel senso opposto avviene tramite l invocazione da parte dell applicazione dei metodi messi a disposizione dalla risorsa per usufruire delle sue funzionalità. Esistono diversi tipi di risorse, diverse implementazioni di ciascun tipo e possono essere rese operative in SLEE diverse istanze di uno stesso tipo di risorsa; a tal proposito definiamo i seguenti concetti: - Resource adaptor type: definisce le caratteristiche comuni ad un insieme di resource adaptors, cioè definisce le interfacce Java implementate dai resource adaptors dello stesso tipo e i tipi di eventi generati dai resource adaptors dello stesso tipo.

19 - Resource adaptor: è un implementazione di un resource adaptor type (possono esistere più implementazioni dello stesso resource adaptor type). Un resource adaptor consiste di un insieme di classi Java e di un deployment descriptor. - Resource adaptor entity: è una istanza di un resource adaptor. Possono essere istanziate più istanze dello stesso resource adaptor nella stessa piattaforma. La funzione importante del resource adaptor entity è di propagare a SLEE un evento originato dalla risorsa che rappresenta.

20 Capitolo 3: Service Delivery Platform di riferimento 3.1 Introduzione La applicazione che si è implementata è quella relativa alla gestione del servizio di Short Message di tipo application-to-person. La scelta di implementare questo tipo di servizio deriva dalla necessità di realizzare un sistema concettualmente semplice che servisse principalmente a testare le specifiche JAIN SLEE da un punto di vista funzionale. Il modello di programmazione di JSLEE è ottimizzato per applicazioni nell ambito delle telecomunicazioni, per cui la versione commerciale di un AS conforme ad esse, dovrebbe garantire delle performance migliori rispetto agli AS attualmente utilizzati L implementazione a disposizione è stata fornita sotto Non Disclosure Agreement da Open Cloud, l azienda che, insieme a Sun, è alla guida del gruppo di esperti che ha definito le specifiche JSLEE. Questa versione non può essere utilizzata in un ambiente operativo reale, ma hanno il solo scopo di rendere possibile lo sviluppo di un servizio testandone il comportamento da un punto di vista funzionale. L implementazione che è stata utilizzata è la Rhino_Sdk, Rhino Single node Development Kit. Rhino è il nome dell implementazione commerciale di Open Cloud della piattaforma JSLEE 20

21 Tale piattaforma mette a disposizione dei Resource Adaptor aggiuntivi rispetto alla JSLEE Reference Implementation, in particolare il RA per J2EE. 3.2 La SDP di riferimento L infrastruttura utilizzata come riferimento per lo sviluppo dell applicazione è mostrata a grandi linee nella Figura 3:1 External Provider SOAP (https) Internal services Access & Authentication layer SOAP HTTP-XML Front End layer Operation & management Sistema post-pagato Magistratura Service Execution Platform SNMP NFS Revenue Assurance Service Assurance Rendicontazione SQL FTP Logging system Middleware Core: Network delivery adapters Billing Adapter CORBA SQL Borsellino elettronico OSA Partay gateway SMS-GW MMS-GW Delivery Server Gaming Platform IVR Streaming HTTP, EAIF, UCP, LDAP, GSM - GPRS NETWORK GSM GPRS mobile users Figura 3:1: SDP di riferimento

22 La componente centrale è la Service Execution Platform della SDP mentre il Front End layer è il Service Exposure Layer. Il sistema interagisce con i componenti di rete veri e propri tramite i Gateway, che hanno il compito di semplificare questa interazione, traducendoi protocolli di basso livello in protocolli più accessibili allo sviluppatore dei servizi Le componenti a destra rappresentano gli apparati di tariffazione, quelle a sinistra i sistemi di post-elaborazione dei dati di traffico, mentre in alto a destra è riportata la componente per la gestione dei servizi implementati nella piattaforma. I blocchi in alto rappresentano le componenti che effettuano la richiesta di servizio alla SDP: possono essere componenti di servizio interne o esterne. Nel caso in cui siano esterne, i Provider esterni dovranno utilizzare un interfaccia apposita, tipicamente basata su Web Services, per accedere alle funzionalità messe a disposizione dal sistema. La componente di Front End è strettamente collegata alla Service Execution Platform poiché è la sua interfaccia verso l esterno ed ha essenzialmente il compito di rendere l accesso alla SDP indipendente dal sistema operativo e dal linguaggio di programmazione del client Infine in basso è visibile il Gataway, componente che si occupa dell invio fisico dell SMS. E da notare come sia il Front End, sia il Gataway presentino una interfaccia che utilizza il protocollo HTTP per la comunicazione con le componenti esterne.

23 Capitolo 4: L applicazione Delivery & Charging di SMS 4.1 Introduzione In questo capitolo si presenteranno i dettagli dell applicazione, in particolare gli SBB che realizzano la logica del servizio e gli altri elementi che entrano in gioco nello sviluppo di un applicazione conforme a JSLEE. Prima comunque verrà fornita una architettura di massima dell applicazione conforme con la descrizione della SDP del capitolo 3

24 4.2 L Architettura della applicazione JSLEE L architettura utilizzata per realizzare il servizio può essere rappresentata su grandi linee con la Figura 4.1. Figura 4:1 Architettura JAIN per SMS Application-to-person E composta da un Application Server J2EE e da un Application Server JSLEE che comunicheranno, attraverso un Resource Adaptor per le informazioni da J2EE a JSLEE e attraverso richieste HTTP per il viceversa. Il Container J2EE è utilizzato per installare le Servlet,che si occupano di comunicare con le applicazioni esterne attraverso il protocollo HTTP, e gli EJB, che attraverso il Resource Adaptor J2EE, comunicheranno con l Application Server JSLEE.

25 Il Front End dedicato appositamente alle funzionalità di interfaccia con l esterno presenta verso le applicazioni una interfaccia http semplice, è in stallato nell Applicaiton Server J2EE. A seguito di una richiesta HTTP, il Front End affida ad un EJB il compito di interagire con la piattaforma JSLEE per avviare effettivamente il servizio corrispondente alla richiesta. Ciò è possibile utilizzando l AS J2EE per ospitare gli EJB e sfruttando due componenti, indispensabili per l interazione tra EJB ed SBB: un Connector installato sull AS J2EE e un Resource Adaptor installato sull AS JSLEE (forniti insieme alla piattaforma Rhino_Sdk). L ambiente JSLEE riceve, dunque, gli eventi dagli EJB e li consegna agli SBB destinati ad elaborarli che, di conseguenza, interagiscono con i componenti di rete per soddisfare la richiesta di servizio. Lo scopo di questo lavoro è quello di realizzare una Service Execution Platform (SEP) integrabile con la architettura della SDP vista nel capitolo precedente., per cui l architettura generale utilizzata è composta dagli stessi elementi della SDP di riferimento, ma con i componenti centrali, legati alla logica del servizio sostituiti dagli analoghi elementi realizzati con le tecnologie JAIN. E importante notare che è stato necessario sviluppare anche il Front End in quanto, anche se rappresentato come una componente esterna rispetto al SEP, è fortemente legato all architettura del SEP. Quindi i componenti che si occupano della tariffazione, della trasmissione degli SMS e del ogging conservano le stesse interfacce e gli stessi comportamenti.

26 Anche la comunicazione tra il SEP e l SMS GW è basata sul protocollo HTTP pertanto la soluzione ideale per la comunicazione verso l esterno sarebbe stato un Resorce Adaptor http secondo il modello JSLEE Non avendo a disposizione né un http Resource Adaptor, né le specifiche dell architettura dei RA, si è risolto il problema della comunicazione con l esterno tramite il J2EE RA. Analizzando i dettagli delle interazioni http, gli SBB dovrebbero reagire agli eventi provenienti dalla sessione http tramite il RA; in direzione opposta, invece, è possibile per un SBB effettuare direttamente e ogging amente (cioè senza dover, per esempio, generare un evento che l ambiente traduca poi in richiesta sincrona) una richiesta http verso una risorsa esterna. Per questo motivo si è scelto che le richieste http dall interno verso l esterno siano effettuate direttamente dagli SBB, mentre le richieste provenienti dall esterno, in questo caso dal SMS GW, siano ricevute da una Servlet apposita, che ricorre agli EJB per inviare l evento corrispondente a JSLEE.

27 In definitiva l architettura rappresentata in Figura 4.1 si modifica assumendo l aspetto riportato in Figura 4:2 Figura 4.2: Architettura definitiva per SMS Application-to-person Il comportamento del SMS GW è stato emulato facilmente tramite una Servlet per poter testare l applicazione Per quanto riguarda il componente di tariffazione (Charging), come detto sopra, si è preferito evitare la sua emulazione, pur tenendolo presente in fase di progettazione dell applicazione. Per quanto riguarda la fase finale, di memorizzazione dell esito di ciascuna richiesta in un sistema di ogging, è stato considerato un database dedicato alla registrazione dei dati

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Applicazione: OIL Online Interactive helpdesk

Applicazione: OIL Online Interactive helpdesk Riusabilità del software - Catalogo delle applicazioni: Gestione ICT Applicazione: OIL Online Interactive helpdesk Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

Linguaggi & Tecnologie Multimediali: TV interattiva e mobile TV

Linguaggi & Tecnologie Multimediali: TV interattiva e mobile TV Linguaggi & Tecnologie Multimediali: TV interattiva e mobile TV Realizzazione di applicazioni interattive multichannel (SMS, MMS, WAP) attraverso la piattaforma Pecan. Tesi di fine corso di Marco Mura

Dettagli

Framework. Impianti Informatici. Web application - tecnologie

Framework. Impianti Informatici. Web application - tecnologie Framework Web application - tecnologie Web Application: tecnologie 2 Java-based (J2EE) Sviluppata inizialmente da Sun Cross-platform e open source Gestire direttamente le funzionalità dell applicazione

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Applicazione: GAS - Gestione AcceSsi

Applicazione: GAS - Gestione AcceSsi Riusabilità del software - Catalogo delle applicazioni Gestione ICT Applicazione: GAS - Gestione AcceSsi Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi Nome

Dettagli

DD - Design Document

DD - Design Document Politecnico di Milano Progetto di Ingegneria del Software 2 DD - Design Document Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 1 gennaio

Dettagli

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE Internet e la Banca Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Gruppo AIVE 1 Scenario Le BANCHE in Italia, al contrario delle concorrenti europee, hanno proposto, sul mercato dei nuovi

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

Sommario. Servizi SMS a valore aggiunto per dispositivi mobili. Osservatorio Mobile VAS (Value. Added Service)

Sommario. Servizi SMS a valore aggiunto per dispositivi mobili. Osservatorio Mobile VAS (Value. Added Service) Servizi SMS a valore aggiunto per dispositivi mobili Nicola Provenzano Dip.. di Ingegneria dell Informazione, Pisa nicola.provenzano@iet.unipi.it Mobile VAS Servizi SMS VAS SMS Center Kannel Content Server

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Architetture per le applicazioni web-based. Mario Cannataro

Architetture per le applicazioni web-based. Mario Cannataro Architetture per le applicazioni web-based Mario Cannataro 1 Sommario Internet e le applicazioni web-based Caratteristiche delle applicazioni web-based Soluzioni per l architettura three-tier Livello utente

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

Applicazione: SIPER Servizi In linea per il PERsonale

Applicazione: SIPER Servizi In linea per il PERsonale Riusabilità del software - Catalogo delle applicazioni Gestione Personale Applicazione: SIPER Servizi In linea per il PERsonale Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei

Dettagli

Windows Azure. introduzione. 16 Maggio 2013. Gianni Rosa Gallina giannishub@hotmail.com. Fabrizio Accatino fhtino@gmail.com

Windows Azure. introduzione. 16 Maggio 2013. Gianni Rosa Gallina giannishub@hotmail.com. Fabrizio Accatino fhtino@gmail.com 16 Maggio 2013 Windows Azure introduzione Gianni Rosa Gallina giannishub@hotmail.com Twitter: @giannirg Blog: http://giannishub.cloudapp.net/it/ Fabrizio Accatino fhtino@gmail.com Twitter: @fhtino Sito

Dettagli

Corso Android Corso Online Sviluppo su Cellulari con Android

Corso Android Corso Online Sviluppo su Cellulari con Android Corso Android Corso Online Sviluppo su Cellulari con Android Accademia Futuro info@accademiafuturo.it Programma Generale del Corso di Sviluppo su Cellulari con Android Programma Base Modulo Uno - Programmazione

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA

POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA POLITECNICO DI TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica TESI DI LAUREA Architetture Web basate su Enterprise JavaBeans in ambiente Open Source Relatori Ing. Fulvio Corno

Dettagli

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Un ambiente di esecuzione che gestisce o naming di oggetti, sicurezza, concorrenza, transazioni, persistenza, distribuzione oggetti (location

Dettagli

APPENDICE A Servlet e Java Server Page

APPENDICE A Servlet e Java Server Page APPENDICE A Servlet e Java Server Page A.1 Cosa è una Servlet e come funziona Una servlet è un particolare tipo di applicazione Java, in grado di essere eseguita all'interno di un web server e di estenderne

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Punti fondamentali sulla tecnologia del sistema ABScard

Punti fondamentali sulla tecnologia del sistema ABScard Punti fondamentali sulla tecnologia del sistema ABScard Architettura ABSCARD Pagina 1 di 13 INDICE GENERALE 1 Architettura...3 1.1 Introduzione...3 1.1.1 Sicurezza...4 1.1.2 Gestione...5 1.1.3 ABScard

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Cloud Computing: alcuni punti fermi per non smarrirsi fra le nuvole

Cloud Computing: alcuni punti fermi per non smarrirsi fra le nuvole Cloud Computing: alcuni punti fermi per non smarrirsi fra le nuvole Stefano Mainetti stefano.mainetti@polimi.it L ICT come Commodity L emergere del Cloud Computing e i nuovi modelli di delivery Trend n.

Dettagli

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014 Meet O Matic Design Document Autori: Matteo Maggioni Luca Mantovani Matricola: 721923 721014 1 Indice 1 Introduzione 4 2 Architettura 4 3 Definizione della base di dati 6 3.1 Tabelle, campi e chiavi primarie.................

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Versione 1. (marzo 2010)

Versione 1. (marzo 2010) ST 763-27 - Soluzione tecnica di interconnessione per i servizi SMS e MMS a sovrapprezzo Allegato 1 - Linee guida per l interfaccia di accesso tra operatore telefonico ed il CSP Versione 1 (marzo 2010)

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

UX model e Architetture di SI web-based. B. Pernici D. Ardagna

UX model e Architetture di SI web-based. B. Pernici D. Ardagna UX model e Architetture di SI web-based B. Pernici D. Ardagna Conallen, cap. 7,9 Bibliografia Modellazione concettuale: UX model Primo passo di analisi UX: user experience Schermate Modellare la navigazione,

Dettagli

Standard Tecnologici Regione Basilicata ALLEGATO C03

Standard Tecnologici Regione Basilicata ALLEGATO C03 Standard Tecnologici Regione Basilicata ALLEGATO C03 UFFICIO S. I. R. S. Standard Tecnologici ver. 2.1 ultimo agg.: 06/06/2012 CONTROLLO DEL DOCUMENTO Data APPROVAZIONI Autore Redatto da: 27/05/2012 Dott.

Dettagli

Il Progetto SITR. L architettura applicativa

Il Progetto SITR. L architettura applicativa Il Progetto SITR Il progetto prevede la realizzazione di un Sistema Informativo Territoriale e di una Infrastruttura dei Dati Territoriali unica, scalabile e federata (SITR IDT) costituiti da risorse tecnologiche

Dettagli

D. Rosaci. Java2 Enterprise Edition

D. Rosaci. Java2 Enterprise Edition D. Rosaci Java2 Enterprise Edition Cos è J2EE? È una piattaforma per lo sviluppo di applicazioni enterprise, basata su un modello di applicazione distribuito a più livelli (multi-tiered) Per applicazione

Dettagli

UNA RELEASE ROBUSTA E COLLAUDATA IN CONTESTI NAZIONALI ED INTERNAZIONALI EVOLUZIONE DELLA PIATTAFORMA ASSICURATIVA ALL IN ONE

UNA RELEASE ROBUSTA E COLLAUDATA IN CONTESTI NAZIONALI ED INTERNAZIONALI EVOLUZIONE DELLA PIATTAFORMA ASSICURATIVA ALL IN ONE L offerta di Value+, in origine focalizzata sulla gestione dei Rami Vita e dei Fondi Pensione attraverso il sistema invita, diffuso in Italia e all estero, si è arricchita nel corso degli anni estendendosi

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

Introduzione ad Architetture Orientate ai Servizi e Web Service

Introduzione ad Architetture Orientate ai Servizi e Web Service Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ad Architetture Orientate ai Servizi e Web Service Corso di Sistemi Distribuiti Stefano Iannucci iannucci@ing.uniroma2.it Anno

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2 DIB 1 Sommario Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 2 Architettura a 3 Livelli DIB 3 Architettura a 3 Livelli Presentazione Gestione dell interazione degli

Dettagli

Protocolli e architetture per WIS

Protocolli e architetture per WIS Protocolli e architetture per WIS Web Information Systems (WIS) Un Web Information System (WIS) usa le tecnologie Web per permettere la fruizione di informazioni e servizi Le architetture moderne dei WIS

Dettagli

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 IaaS, Infrastructure as a Service: Business: vendita di host a consumo Contesto IaaS/PaaS Gestione: limitata al parco degli Host vari Gestori Monitoraggio

Dettagli

- mezzi di acquisizione dei dati provenienti da un utente chiamante (105), e relativi

- mezzi di acquisizione dei dati provenienti da un utente chiamante (105), e relativi 1 RIASSUNTO Sistema di instradamento automatico (100) di richieste di connessione telefonica, preferibilmente applicato ad una centralina di smistamento, appartenente ad una infrastruttura base di una

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.6 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

Dettagli

Business Simulation in ambiente web

Business Simulation in ambiente web Business Simulation in ambiente web Da soluzione Stand Alone ad un ambiente condiviso Lecco, Novembre 2013 Documento riservato. Ogni riproduzione è vietata salvo autorizzazione scritta di MAS Consulting

Dettagli

Framework di Middleware. per Architetture Enterprise

Framework di Middleware. per Architetture Enterprise Framework di Middleware per Architetture Enterprise Corso di Ingegneria del Software A.A.2011-2012 Un po di storia 1998: Sun Microsystem comprende l importanza del World Wide Web come possibile interfaccia

Dettagli

Programmazione server-side: Java Servlet

Programmazione server-side: Java Servlet Programmazione server-side: Java Servlet Corso di Applicazioni Telematiche A.A. 2006-07 Lezione n.11 parte II Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Cos

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Sme.UP Web Application

Sme.UP Web Application Sme.UP Web Application Web Application Web.UP Una interfaccia web per i vostri dati gestionali Il modulo applicativo Web.UP fornisce al progettista di siti Internet una serie di potenti strumenti per l'integrazione

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 24/09/2014 Indice 1. Aspetti di Data Management CouchBase 2. Aspetti Architetturali Infrastruttura

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Progettazione di interfacce web indipendenti dal dispositivo

Progettazione di interfacce web indipendenti dal dispositivo Progettazione di interfacce web indipendenti dal dispositivo Candidato Izzo Giovanni, Matr. 41/1305 Relatore Prof. Porfirio Tramontana 1 Panoramica su contesto ed obiettivi Il contesto della tesi è legato

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l.

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l. 2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011 Andrea Carnevali R&D Director GESINF S.r.l. Il progetto 2G è il nome della piattaforma che consentirà l evoluzione tecnologica

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Applicazione: Piattaforma di Comunicazione Unificata

Applicazione: Piattaforma di Comunicazione Unificata Riusabilità del software - Catalogo delle applicazioni: Amministrativi/Contabile Applicazione: Piattaforma di Comunicazione Unificata Amministrazione: Regione Piemonte - Direzione Innovazione, Ricerca

Dettagli

Tecnologie di Sviluppo per il Web

Tecnologie di Sviluppo per il Web Tecnologie di Sviluppo per il Web Programmazione Web: Architetture versione 2.2 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima pagina) G. Mecca mecca@unibas.it

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

REGIONE BASILICATA UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi

REGIONE BASILICATA UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi Autori: Dott.ssa Domenica Nardelli (P.O.C. Area Applicativa Ufficio SIR) Data di creazione: 03 Ottobre 2005 Ultimo aggiornamento: 03 Ottobre

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Architetture di Cloud Computing

Architetture di Cloud Computing Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architetture di Cloud Computing 1 Cloud computing Sommario Principali requisiti richiesti dal cloud clomputing

Dettagli

Identity Access Management nel web 2.0

Identity Access Management nel web 2.0 Identity Access Management nel web 2.0 Single Sign On in applicazioni eterogenee Carlo Bonamico, NIS s.r.l. carlo.bonamico@nispro.it 1 Sommario Problematiche di autenticazione in infrastrutture IT complesse

Dettagli

SNMP Watch Dog (Specifiche)

SNMP Watch Dog (Specifiche) SNMP Watch Dog (Specifiche) Progetto di Esame di Reti di Calcolatori Corso di laurea in Ingegneria delle Telecomunicazioni Realizzato da Scocco Gianfranco, matricola n. 21 03 50701 SNMP Watch Dog Sistema

Dettagli

EyesDGTV. Your digital terrestrial television. Soluzioni Informatiche

EyesDGTV. Your digital terrestrial television. Soluzioni Informatiche EyesDGTV Your digital terrestrial television Soluzioni Informatiche Cos è EyesDGTV è la soluzione che Betacom propone per la televisione digitale terrestre. Basata su tecnologie consolidate, quali J2EE

Dettagli

JSIS JSIS L architettura JSIS

JSIS JSIS L architettura JSIS JSIS JSIS L architettura JSIS La piattaforma JSIS Java Solution Integrated Suites, interamente realizzata dai nostri laboratori di sviluppo software, è una soluzione che integra la gestione di diverse

Dettagli

The project. http://www.interdatanet.org

The project. http://www.interdatanet.org Università degli Studi di Firenze Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni (DET) Laboratorio di Tecnologie della Telematica (LTT) The project http://www.interdatanet.org WORK

Dettagli

19 aprile 2013. Activ1st Descrizione prodotto

19 aprile 2013. Activ1st Descrizione prodotto 19 aprile 2013 Activ1st Descrizione prodotto Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

Architetture basate su componenti

Architetture basate su componenti Luca Cabibbo Architetture Software Architetture basate su componenti Dispensa ASW 440 ottobre 2014 Affida le cose speciali agli specialisti. Robert Spinrad 1 -Fonti [POSA4] Pattern-Oriented Software Architecture

Dettagli

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo La progettazione dell architettura si concentra sulla scelta dell hardware, dell infrastruttura di rete, e dei componenti software che andranno a costituire il sistema. Gli obbiettivi tecnologici che il

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Introduzione al mondo della persistenza. Dott. Doria Mauro doriamauro@gmail.com

Introduzione al mondo della persistenza. Dott. Doria Mauro doriamauro@gmail.com Hibernate Introduzione al mondo della persistenza Dott. Doria Mauro doriamauro@gmail.com La questione della persistenza Il modo dei database è complesso e le tecniche e le tecnologie sono molte. Per anni

Dettagli

3 Caratteristiche del servizio

3 Caratteristiche del servizio 3 Caratteristiche del servizio Il GPRS offre all utente la possibilità di inviare e ricevere dati in modalità a commutazione di pacchetto, con diverse modalità e qualità. Il servizio di trasporto è particolarmente

Dettagli

EJB Components. Leonardo Mariani Esercitazione di Sistemi Distribuiti. Oggetti Distribuiti

EJB Components. Leonardo Mariani Esercitazione di Sistemi Distribuiti. Oggetti Distribuiti EJB Components Leonardo Mariani Esercitazione di Sistemi Distribuiti 1 Oggetti Distribuiti 2 Middleware Esplicito 3 Middleware Implicito 4 Tipica Applicazione J2EE 1/2 5 Tipica Applicazione J2EE 2/2 6

Dettagli

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration COSA FACCIAMO SEMPLIFICHIAMO I PROCESSI DEL TUO BUSINESS CON SOLUZIONI SU MISURA EXTRA supporta lo sviluppo

Dettagli