download tesi - MobiLab

More documents

Recommendations

Info

Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe del mercato è capire se le soluzioni attualmente sviluppate sono adatte ad un ambiente distribuito. L‟obiettivo di questa <strong>tesi</strong> è stato lo studio e la valutazione di alcuni prodotti software: RTI DDS, OpenSpliceDDS, JMS Apache ActiveMQ - CPP, AMQP OPENAMQ, AMQP QPID, CORBA. RTI DDS ed OpenSpliceDDS seguono lo standard OMG nella specifica DDS, entrambi implementano le DCPS API, ma solo OpenSplice implementa la DLRL. RTI DDS e OpenSpliceDDS benché sviluppando lo stesso standard lo implementano in modi differenti. RTI DDS ha un architettura decentralizzata che gli conferisce il vantaggio di non aver bisogno di un demone per lo scambio di messaggi, facendo risultare così ogni applicazione autonoma. Uno svantaggio di questo middleware è che alcuni dettagli della configurazione come l‟indirizzo di multicast, il numero di porta, i parametri relativi ai differenti tipi di trasporto e il modello reliability devono essere definiti nel livello applicativo e, ciò comporta un sovraccarico del lavoro da parte dello sviluppatore e una maggiore probabilità di commettere errori. OpenSplice DDS utilizza invece un architettura federata in cui c‟è un processo demone distinto per ogni interfaccia di rete, una shared- memory per collegare le applicazioni, che risiedono in un nodo computazionale, ma anche gli hosts con un insieme di servizi configurabili ed estendibili; utilizzando un‟architettura di tipo shared-memory, i dati sono fisicamente presenti una sola volta su ogni macchina, usando un demone si disaccoppiano le applicazioni dai dettagli di comunicazione e di configurazione del DCPS. Inoltre, in caso di presenza di più partecipanti DDS sullo stesso nodo, la scalabilità risulta maggiore rispetto agli altri modelli di architettura, infatti è possibile semplificare la configurazione delle policy per un gruppo di partecipanti aventi la stessa interfaccia di rete. Uno svantaggio di quest‟architettura è sicuramente la presenza di un unico point of failure e la necessità di eseguire ulteriori configurazioni. JMS Apache ActiveMQ è un message middleware implementa lo standard Java Message Service 1.1. L‟architettura di JMS Apache ActiveMQ può essere sia di tipo centralizzato che di tipo federato. Secondo l‟architettura centralizzata usa un singolo demone operante su un nodo designato per la gestione delle informazioni necessarie per creare e gestire le connessioni 74
Analisi delle prestazioni delle principali soluzioni per servizi publish/subscribe tra i partecipanti in un dominio. I dati passano direttamente dai Publisher ai Subscriber, mentre è necessaria la comunicazione con il processo demone per il controllo e l‟inizializzazione delle attività. Il vantaggio di quest‟architettura sta nella semplicità dell‟implementazione e della configurazione poiché tutte le informazioni di controllo risiedono in un'unica locazione. Lo svantaggio è senza dubbio, la presenza di un solo demone che costituisce un unico point of failure. Seguendo invece l‟architettura federata, per la comunicazione tra i vari client CMS si ha bisogno di un message broker per lo scambio dei messaggi su rete. Il broker utilizzato è Apache ActiveMQ e per interfacciare i vari client CMS a quest‟ultimo serve un API C++, per il trasporto dei messaggi viene utilizzato un protocollo di connessione come Stomp, JMS Apache ActiveMQ garantisce la possibilità di specificare QoS per ogni messaggio scambiato tra i vari client. CORBA TAO si differenzia da JMS in quanto i pubblishers sono disaccoppiati dai subscribers per mezzo di un canale l‟event channel che si occupa della diffusione degli eventi per più consumers. Una caratteristica importante di questo middleware è che supporta la federazione dei canali senza l‟uso di intermediari per trasmettere gli eventi da un canale all‟altro. E‟ possibile specificare per lo scambio di messaggi delle Qos stringenti utili proprio per applicazioni real-time e mission-critical. OpenAMQ e QPID sono entrambi message middleware basate sulle specifiche AMQP. L‟architettura di entrambi i middleware può essere assimilata ad una di tipo federata per la presenza di un demone che mette in comunicazione i vari client per lo scambio dei messaggi, ne deriva che assimilano vantaggi e svantaggi di questa architettura. Entrambi i middleware implementano QoS per lo scambio di messaggi in modo da rendere robusta la comunicazione. 75
Page 1 and 2:
Facoltà di Ingegneria Corso di Stu
Page 3 and 4:
Indice Introduzione 8 Capitolo 1. I
Page 5 and 6:
Indice delle figure Figura 1.1 Stru
Page 7 and 8:
Indice delle tabelle Tabella 2.1 Qo
Page 9 and 10:
Analisi delle prestazioni delle pri
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24: eciprocamente. Figura 1.6 Interazio
Page 25 and 26: Analisi delle prestazioni delle pri
Page 31 and 32: Figura 2.1 Schema concettuale del D
Page 53 and 54: Figura 2.10 Architettura TAO Analis
Page 65 and 66: Figura 2.16 Semantica AMQP. Analisi
Page 71 and 72: Affidabilità Analisi delle prestaz
Page 73: Analisi delle prestazioni delle pri
Page 77 and 78: VOLATILE Analisi delle prestazioni
Page 79 and 80: 3.2 I Test Figura 3.1 Schema Cluste
Page 83 and 84: Figura 3.3 Architettura decentraliz
Page 97 and 98: 3.6 Test CORBA TAO Analisi delle pr
Page 111 and 112: 3.8 Test OpenAMQ Analisi delle pres
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Conclusioni e Sviluppi Futuri Anali
Page 131 and 132:
Ringraziamenti Analisi delle presta
Page 133 and 134:
Page 135 and 136:
Bibliografia Analisi delle prestazi
Page 137 and 138:
show all

download tesi - MobiLab

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?