Di AJAX se ne è già parlato abbastanza (dopotutto è la buzzword del momento 
) ed io non ho intenzione di dire nulla di nuovo in proposito, visto che è gia stato quasi detto tutto ed il contrario di tutto. Quello di cui voglio discutere qui è l'utilizzo di una tecnologia asincrona come AJAX in un contesto un pò più grosso, come può essere un moderno sito web (intranet, extranet o public website che sia).
L'idea di utilizzare una qualsiasi architettura che renda asincrone alcune chiamate al server è, per quello che mi riguarda, qualcosa che diventerà sempre più una normalità, ma che può portare ad alcuni problemi di scalabilità ad un sito piuttosto affollato.
Pensiamo ad esempio ad un sito eCommerce (tanto per essere originali, ma basterebbe anche un qualsiasi sito di una società piuttosto grossa che non faccia necessariamente eCommerce ma funga da "semplice" punto di contatto interattivo con il cliente). Tipicamente un sito del genere poserà le sue solite basi su un database. Orbene, se è vero che la stragrande maggioranza delle operazioni è in lettura, c'è da tenere conto anche che una buona parte delle operazioni fatte dall'utente è una scrittura. Non che l'utente ne sia conscio o lo faccia volontariamente, ma normalmente siti del genere abbastanza evoluti tengono traccia di parecchie informazioni - sia commerciali che di marketing, di configurazione e di personalizzazione, anonime oppure no - che comportanto una certa continutà di scrittura / modifica dei dati nel database.
Lasciando stare le operazioni di lettura che possono essere rese asincrone per rendere l'interfaccia utente più veloce e gradevole, concentriamoci sulle operazioni di scrittura che, tra l'altro, sono anche quelle più problematiche dal punto di vista della scalabilità. Per amor della precisione entriamo un pò nel dettaglio per apprezzare il perchè di tale affermazione. Database come SQL Server 2000 e 2005 utilizzano una tecnica conosciuta come locking per far si che su una stessa risorsa non possa essere scritta da due o più utenti contemporaneamente (altrimenti si avrebbe un problema conosciuto come lost update che sarebbe piuttosto spiacevole da affrontare ). Benchè la dimensione della risorsa sia gestita in automatico dal SQL Server in modo che sia la più piccola possibile (in pratica è poco probabile che sia bloccata l'intera tabella per l'aggiornamento di una sola riga), il locking comunque c'è e, in database affollati, la probabiltà di query che si contendano l'accesso ad una singola risorsa esiste eccome! Nei casi di un "contenzioso" il meccanismo del locking mette in attesa gli utenti (più precisamente le transazione) fino a che l'utente che per primo ha aquisito il lock non lo rilascia al secondo e cosi via.
Ottimo per la consistenza dei dati ma le prestazioni percepite dall'utente ne soffrono senza dubbio. Se inoltre il tempo di attesa è davvero lungo, la nostra connessione potrebbe andare in timeout e dare un errore.
Bene. Torniamo ora ad AJAX. Se il sito in questione è molto utilizzato, l'invio dell'ordine, ad esempio, potrebbe risultare notevolmente lento (o, nel peggiore dei casi, non avvenire, restituendo un errore). Se rendo asincrona questa cosa, lo stress a carico del sistema (del database in particolare, che magari è uno solo che serve una batteria di web server), non fà altro che aumentare ancora in quanto le pagine web, non dovendo più aspettare la risposta da parte dal database possono ridare subito il controllo da all'utente.
Ok, so già cosa state pensando: "Ma l'invio dell'ordine non è qualcosa che farei con AJAX". Benone (anche se non ci vedrei nulla di male...andate avanti e leggerete il perchè), ma pensiamo a tutti gli altri casi in cui scriviamo su db: la rilevazione di un clik su un link, la visualizzazione di un banner, il click su una promozione....Ma non sono forse queste tutte cose che sarebbe bene fare in modo asincrono? Credo che siate tutti concordi come me che la risposta non può che essere affermativa.
AJAX però non basta....in quanto un semplice errore di time-out ci farebbe perdere alcune informazioni, magari preziose, come quelle dell'ordine.
Ecco quindi che è necessario che il database possa evadere velocemente tutte richieste giunte in modo asincrono dal web e processarle immediamente se in grado di farlo, oppure tenerle in coda in modo da processarle appena possibile. In poche parole la ricezione della richiesta da parte del sito web deve essere asicrona anche da parte dal database. In SQL Server 2005, la tecnologia per fare questo si chiama - come magari già saprete - Service Broker.
Dato che il Broker è transazionale, possiamo tranquillamente affidargli anche dati importati, in quanto le prorietà ACID delle transazioni ne garatiscono la consistenza e la persistenza.
Per un database che serve siti (o applicazioni) di una certa dimensione (sia come quantità di dati che di visitatori), questa tecnologia sarà di vitale importanza in quanto permetterà di scalare in modo ottimale durante i picchi di lavoro, senza quindi rallentare il sito, utilizzando in modo intelligente i tempi "morti" per evadere la richieste in coda, il tutto senza dover acquistare macchine oltremodo potenti solo per gestire i momenti caldi.
E questo è solo il punto di partenza! Una volta creato tale "buffer" tramite il Broker è possibile ottimizzare, eventualmente, il tutto in modo ancora più spinto, utilizzando il versioning al posto che il locking (tramite il nuovo livello di isolamento snapshot) così da avere una situazione di readers-do-not-block-writers e viceversa, permettendo al Broker di scalare in modo ancora più veloce.
Ah, sapete qual'è la cosa davvero bella? Che tutto questo (AJAX a parte) è totalmente trasparente all'applicazione! (Se l'avete fatta bene neh! Chi ha detto "Stored Procedure" ? 
)