Ajax e controlli asincroni

Ajax รจ l’acronimo di “Asynchronous JavaScript and XML”, ossia un meccanismo asincrono basato sull’oggetto HTML XMLHttpRequest inserito nelle specifiche W3C nel 2004 per inviare in modo asincrono richieste al server e ricevere le relative risposte. Inizialmente pensato per informazioni strutturate con il farraginoso XML, si รจ evoluto per supportare il piรน leggero e versatile JSON.

L’obiettivo delle richieste asincrone รจ di consentire all’utente di proseguire con l’attivitร  sulla pagina web mentre il serve elabora le informazioni che via via il client invia al server, come esito dell’elaborazione delle attivitร  svolte dall’utente.

I clienti di posta Gmail, Yahoo, Outlook,… funzionano con questa tecnologia, cosรฌ come tutte le applicazioni disponibili sul web (es: strumenti office). Il paradigma di programmazione cambia rispetto ai siti web “tradizionali” e si va verso un modello “Rich Client” che per le applicazioni web viene denominato “RIA – Rich Internet Application”. In caso estremo l’applicazione si compone di una “single page application”. Ossia una singola pagina web che contiene tutti i javascript per dare alla pagina il comportamento dinamico, si tratta di fatto di applicazioni client/server realizzate utilizzando i browser come ambiente “runtime” per il client.

Questa piccola premessa perchรฉ ho de domande che non trovano risposte, vorrei condividerle per vedere se qualcuno ha una risposta.

1) Perchรฉ molti si sforzano di rendere i controlli AJAX sincroni inventandosi throbber, overlay o altri archibugi ce rendono le applicazioni inusabili? A mio avviso non si puรฒ rendere asincrono ciรฒ che nasce sincrono e non si puรฒ rendere sincrono ciรฒ che nasce asincrono. Ho visto un’applicazione letteralmente resa inusabile da una clessidra che compare a ogni click dell’utente.

2) Perchรฉ a distanza di ben 12 anni da quando esistono le potenzialitร  delle XMLHttpRequest nascono ancora applicazioni web che completamente sincrone. Il sincronismo va bene se il backend รจ un mainframe (elevata potenza di calcolo senza parallelismo) non se il backend รจ un sistema distribuito (basse prestazioni a singolo core, elevata capacitร  di parallelismo). Di recente un collega mi ha parlato di un suo cliente con una procedura di SSO che impiega oltre 55sec per terminare il processo di logon. Mi ha spiegato,che oltre all’autenticazione il sistema deve recuperar le informazioni utente da altri 6 sistemi di cui 3 di terze parti e la fa in modo sincrono, serializzando le richieste. Il dubbio che ci รจ venuto ma se un sistema “terze parti” non รจ raggiungibile? Ci siamo guardati.. “Eh va in time-out.” (forse non lo fa ma ci saranno sicuramente problemi)

Se qualcuno ha una risposta a questi due punti mi aiuta a dormire meglio (scherzo dormo bene lo stesso ๐Ÿ™‚ ).


Commenti

Lascia un commento

Il tuo indirizzo email non sarร  pubblicato. I campi obbligatori sono contrassegnati *

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.