Utilizzare Message Queuing per scalare le applicazioni

di Ugo Lattanzi, in .NET Framework,

Per chi non lo conoscesse, Microsoft Message Queuing (MSMQ) è un protocollo di comunicazione tra server differenti introdotta da Microsoft fin dai tempi di Windows 95.
La caratteristica principale che rende vincente questa tecnologia, consiste nel fatto che si ha la certezza che il messaggio venga recapitato al server di destinazione.

Successivamente andremo ad analizzare l'architettura di questa tecnologia in modo da capirne meglio il funzionamento e cosa il .NET Framework ci mette a disposizione per utilizzarla.

Storia di MSMQ

Per capire l'evoluzione di Microsoft Message Queuing e poter progettare l'applicazione è necessario conoscere le caratteristiche offerte dalle varie versioni, che variano a seconda del sistema operativo di cui disponiamo nella nostra Server Farm.

La tabella seguente ci mostra l'evoluzione del protocollo nell'arco degli anni:

VersioneSistema OperativoCaratteristiche
1.0Windows 95, Windows NT 4.0, Windows 98 e Windows MeSupporta l'integrazione con code pubbliche di Active Directory, Crypting a 128bit e certificati digitali, supporto per il multi-thread.
2.0Windows 2000Introduzione dell'Internet Messaging (HTTP, SOAP-Formatted message), supporto su IIS, alias di code e multicasting, Triggers.
3.0Windows XP e Windows Server 2003
4.0Windows Vista e Windows Server 2008Subqueues, supporto per i "poison message", code transazionali da code remote.

Scenari di utilizzo

L'utilizzo di questa tecnologià può entrare in gioco in tutti quei contesti applicativi in cui si ha la necessità di rendere scalabile un'applicazione.
Per scalabilità si intende la capacità di un software di "crescere" e "decrescere" in funzione delle necessità e delle disponibilità.

Spesso si confonde il termine scalabilità con performance, ma questo non è vero! Il grafico seguente mostra la curva di andamento di un software scalabile e uno non scalabile.

Come possiamo vedere dal grafico si ha una buona scalabilità quando, all'aumentare del numero di richieste, non si ha un grave rallentamento nella risposta, al contrario con il rallentamento di risposta una volta raggiunto il punto di rottura, l'applicativo comincia ad avere un decadimento della scalabilità. Il punto di rottura ovviamente cambia da applicazione ad applicazione, ed è calcolabile soltanto con dei test approfonditi, per esempio nella versione 1.1 del .NET Framework si era calcolato che il punto di rottura dell'utilizzo dei DataSet era di 10.000 elementi, oltre questo valore i DataSet aveva un degrato prestazionale.

Per poter raggiungere questo traguardo non è soltanto necessario scrivere del buon codice, ma anche progettare un'architettura in grado di poter scalare, ed è proprio qui che MSMQ ci viene in aiuto, permettendoci di lavorare in modalità asincrona ed avere la certezza che la nostra messaggistica arrivi sempre a destinazione.

4 pagine in totale: 1 2 3 4

Attenzione: Questo articolo contiene un allegato.

Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti