Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

108 giugno
, anno 2006

AJAX ci porterà le Servlet Asincrone?

Proposto un nuovo modello per la Servlet API

Avatar

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia.
Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise
Edition Technology, lavora presso un importante business solution provider.
Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri,
quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005.
Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.

MokaByte

AJAX ci porterà le Servlet Asincrone?

Proposto un nuovo modello per la Servlet API

Massimiliano Bigatti

Massimiliano Bigatti

  • Questo articolo parla di: Architetture dei sistemi, Java, Programmazione & Linguaggi

Con il rapido sviluppo delle tecnologie collegate ad AJAX, le modalità di interazione con il Web Server stanno cambiando. In particolare, cresce il numero di richieste inviate dal client, necessarie per la dinamicità propria di AJAX. Le Servlet asincrone potranno essere una risposta?

L‘idea nasce dal blog di Greg Wilkins, autore fin dal 1995 di software Open Source. È in quell‘anno
infatti che inizia lo sviluppo del server HTTP Jetty e del relativo Servlet Container. Ora Jetty è
parte di CodeHaus (http://www.codehaus.org/). Greg ha contribuito inoltre a JBoss e ad Apache
Geronimo. Come esperto di tecnologie Web e Servlet in particolare, ha voluto condividere le sue idee
sull‘evoluzione che dovrebbero avere le servlet, dopo la finalizzazione della versione corrente, la
2.5.
Il problema scatenante è il nuovo modello di chiamata a “cometa”, utilizzato dalla nuova generazione
di applicazioni Web che utilizzano AJAX. In origine, infatti le applicazioni AJAX utilizzavano un
modello di tipo “polling”: il client, a intervalli regolari, inviava richieste al server allo scopo di
mantenere aggiornata e/o validata l‘interfaccia utente. Con lo stile a “cometa” il client apre una
connessione HTTP, che viene lasciata aperta dal Web Server. In questo modo il server ha la possibilità
di inviare informazioni al client in modalità  push. In sostanza, si utilizzano connessioni HTTP long-
lived, a lunga durata. Questo è un modo più efficiente di utilizzare le risorse, ma anche questo
modello non è privo di problemi. L‘analogia con la cometa risiede nel fatto che la prima richiesta può
essere considerata come la testa di una cometa e la sua scia rappresenta il tempo in cui la
connessione HTTP rimane aperta.

Le novità  proposte

I casi d‘uso che Greg profila, soprattuto in merito allo stile di programmazione a “cometa”, sono i
seguenti:

  • input non bloccante. L‘abilità  di ricevere dati da un client senza bloccare l‘esecuzione se i dati arrivano lentamente. Effettivamente, questo aspetto non è centrale per l‘API asincrona, visto che la maggior parte delle richieste perviene in un singolo pacchetto. Inoltre la gestione può essere postposta fino all‘arrivo del primo pacchetto contenente dati effettivi. L‘obiettivo sarebbe comunque l‘evoluzione delle API delle servlet verso applicazioni che non debbano implementare alcun input/output.
  • output non bloccante. È la caratteristica di inviare dati al client senza bloccare l‘esecuzione se il client o la rete sono lenti. Sebbene la necessità  di output asincrono è molto maggiore rispetto alla necessità  dell‘input asincrono, Greg non ritiene neanche questo un elemento essenziale. Grandi buffer possono permettere al Servlet Container di inviare la maggior parte delle risposte in modo asincrono. Inoltre, per risposte di dimensioni ragguardevoli sarebbe meglio evitare del tutto che il codice dell‘applicazione gestisca l‘input/output.
  • ritardare la gestione della richiesta. Lo stile “cometa” delle Web Application AJAX possono richiedere che la gestione di una richiesta venga ritardata fino a quando non avviene un timeout o un qualche tipo di evento. Il ritardare la risposta alle richieste è utile anche in quei casi in cui sia necessario recuperare una risorsa remota o lenta da caricare prima di poter servire la richiesta o in qui casi in cui sia necessario temporeggiare per evitare troppi accessi simultanei. Attualmente l‘unico modo per supportare questo punto, e che sia anche conforme alle specifiche, è di attendere all‘interno della servlet. Questo però comporta un consumo di risorse e di thread.
  • ritardare la chiusura della risposta. Applicazioni Web AJAX che utilizzano lo stile cometa potrebbero richiedere che una risposta sia lasciata aperta per permettere l‘invio di dati addizionali quando avviene un evento asincrono. Anche in questo caso, l‘unico modo standard in cui si può fare ora è di attendere all‘interno della servlet, consumando un thread e altre risorse.
  • gestione del codice 100 (Continua). Un client potrebbe richiedere un handshake dal server prima di inviare il corpo della richiesta. Se questo viene inviata automaticamente dal contenitore diventa impossibile utilizzare il codice di ritorno 100. Se l‘applicazione è in grado di decidere se inviare un codice 100, un‘API asincrona potrebbe evitare che un thread venga consumato durante il ritorno al client.

Tutti questi casi possono essere riassunti come: “alcune volte è solo necessario fermarsi ad attendere
qualcosa”, sapendo che un‘attesa all‘interno del metodo Servlet.service() è costoso, per i seguenti
motivi:

  • è necessario un thread.
  • Se l‘input/output è iniziato sono necessari i relativi buffer.
  • Se sono stati ottenuti i Reader/Writer, sono necessari i relativi converititori di caratteri.
  • La sessione non può essere passivata.
  • Tutto quanto allocato dalla catena dei filtri servlet deve essere mantenuto.

Le soluzioni

Ad oggi esistono alcune implementazioni che cercano di affrontare questo problema:

  • Jetty ha il meccanismo della Continuazione, studiato per le applicazioni comet;
  • BEA ha un meccanismo di risposte future;
  • Glassfish ha un layer NIO estensibile per I/O asincrono al di sotto del modello delle servlet;
  • Gli sviluppatori di Tomcat hanno appena iniziato lo sviluppo al supporto di applicazioni

comet.

Greg rileva come la cosa ironica è che, mentre la versione 2.5 delle Servlet risolve moli problemi di
portabilità , AJAX ne sta introducendo di nuovi. Ed effettivamente la versione 2.5 non ha portato molte
novità , ma tante chiarificazioni orientate alla portabilità . AJAX pone delle nuove problematiche che
il JCP dovrà  affrontare.
Non è ancora chiaro come si possa standardizzare una soluzione, ma Greg rileva cosa NON dovrebbe
essere:

  • una API su una servlet specifica. Nel momento in cui il Servlet Container ha identificato la specifica servlet da invocare, molte delle operazioni collegate sono state svolte. Inoltre, siccome i filtri e i dispatcher sono in grado di redirigere la richiesta, qualsiasi API asincrona strettamente legata a una servlet dovrebbe seguire lo stesso percorso.
  • Basata sulla tecnologia Continuations di Jetty. Sebbene questa sia una utile astrazione è necessaria una soluzione più a basso livello in grado di offrire una maggiore efficienza e permettere ulteriori funzionalità .
  • L‘esposizione di canali o in generale API NIO al programmatore della servlet. Questi dettagli di implementazione dovrebbero essere nascosti all‘utilizzatore; inoltre, in taluni casi si potrebbero impiegare tecnologie diverse da NIO.

La soluzione su cui sta lavorando Greg è diversa. Si basa su un oggetto coordinatore che può essere
mappato a percorsi URL proprio come i filtri e le servlet. Il coordinatore dovrebbe essere richiamato
dal contenitore in risposta a eventi asincroni e si dovrebbe occupare del coordinamento delle chiamate
sincrone ai servizi.

Conclusioni

Se l‘idea di Greg si dimostrerà  rispondente alle nuove sfide che pone lo stile di programmazione a
“cometa”, ne verrà  implementato un prototipo in Jetty 6, e da qui potrebbe passare al JCP, per essere
standardizzato.

Bibliografia

[1] http://www.theserverside.com/news/thread.tss?thread_id=40560

[2] http://www.mortbay.com/MB/log/gregw/?permalink=asyncServlets.html

[3] http://www.codehaus.org/

[4] http://docs.codehaus.org/display/JETTY/Continuations

[5] http://blogs.pathf.com/agileajax/2006/05/comet_socket_hu.html

[6] http://alex.dojotoolkit.org/?p=545

[7] http://www.irishdev.com/NewsArticle.aspx?id=2166

 

Facebook
Twitter
LinkedIn
Avatar

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia.
Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise
Edition Technology, lavora presso un importante business solution provider.
Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri,
quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005.
Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.

Massimiliano Bigatti

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia. Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise Edition Technology, lavora presso un importante business solution provider. Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri, quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005. Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.
Tutti gli articoli
Nello stesso numero
Loading...

Sviluppare Applicazioni AJAX

II parte: realizzare applicazioni AJAX utilizzando il progetto Open Source Sarissa

Offshore

I parte: le metodologie agili e i progetti offshore

JFreeChart: una libreria Open Source per la generazione dinamica di grafici

II parte: un esempio completo di applicazione web

SOA: Dalla teoria alla pratica

IX parte: Esempio (I)

AJAX, Java e Rich Internet Applications

Interfacce grafiche ricche basate su Javascript/XML vs. approcci ‘pure Java‘

Architetture e tecniche di progettazione EJB

VII parte: ottimizzazione CMP

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte