[DWR] Direct Web Remoting: Easy AJAX for Java

DWR (Direct Web Remoting) è una libreria Java open-source (Apache Software License v2) che permette a Java (lato back-end) e JavaScript (lato front-end) di interagire e chiamarsi a vicenda nel modo più semplice possibile.
DWR si integra con Spring, Struts, Hibernate e altri framework.

 

Ecco lo slogan di DWR: “DWR is Easy Ajax for Java“.

Ecco il sito ufficiale di DWR: http://directwebremoting.org

Cosa fa DWR? DWR permette di generare codice JavaScript che permetta ai web browser di chiamare in sicurezza codice Java come se venisse eseguito localmente. Effettua una operazione di marshalling virtuale che include collections, POJOs, XML e binary data (come immagini e file PDF).
Mette a disposizione anche una funzionalità di Reverse Ajax, che permette a codice Java in esecuzione sul server di utilizzare/richiamare API lato client per pubblicare aggiornamenti su determinati gruppi di browser.

Questo tipo di interazione è, dunque, bidirezionale – browser che chiama il server e server che chiama il browser.
DWR supporta Comet, Polling e PiggyBack (spedendo i dati in una normale request) come modalità per la notifica da server a browser.

Come funziona? Il meccanismo di interazione bidirezionale avviene tramite chiamate RPC (Remote Procedure Call).
Nella seguente figura, viene mostrato un primo diagramma che rappresenta come DWR altera il contenuto di una select HTML con il risultato di un evento JavaScript (il client chiama il server per farsi restituire i risultati):


Il Reverse Ajax di DWR (disponibile dalla versione 2.0) permette a codice Java in esecuzione sul server di intercettare quali client stanno visualizzando determinate pagine, in modo da inviare loro (tramite JavaScript) dei risultati (meccanismo di comunicazione inverso – da server a client):


DWR è composto da due parti principali:

  • una servlet Java in esecuzione sul server che processa le richieste e manda le risposte indietro al browser
  • JavaScript in esecuzione sul browser che manda le richieste e può dinamicamente aggiornare il contenuto della pagina

DWR genera dinamicamente codice JavaScript da classi Java ed effettua il marshalling dei dati scambiati in modo bidirezionale, eseguendo il tutto lato server.
Il metodo di remoting functions (Reverse Ajax) da Java a JavaScript fornisce un meccanismo RPC molto simile a RMI o SOAP, con il vantaggio che l’esecuzione avviene su un browser senza necessità di plugin addizionali.

Download di DWR: http://directwebremoting.org/dwr/downloads/index.html

Installazione di DWR: http://directwebremoting.org/dwr/introduction/getting-started.html#fiveSteps

Chiamate remote con DWR (handling delle chiamate asincrone AJAX con metodi di callbacks)

DWR genera funzioni proxy Javascript che rispecchiano i metodi Java definiti lato back-end. Le funzioni di callback vengono invocate quando i dati (il risultato) viene ritornato dal server.
Ci sono due modalità per poter effettuare le chiamate usando DWR: il primo permette di “appendere” alla chiamata delle opzioni e il secondo associa una funzione di callback ad una lista di parametri. Vediamole:

1. Call Options Object
Supponiamo di avere un metodo Java nella classe Remote:

//Lato JAVA
public class Remote {
    public String getData(int index) { ... }
}

//Lato Javascript la chiamata avverrebbe nel seguente modo:
<script type="text/javascript" src="[WEBAPP]/dwr/interface/Remote.js"></script>
<script type="text/javascript" src="[WEBAPP]/dwr/engine.js"></script>
...

Remote.getData(42, {
   callback:function(str) {
     alert(str);
    }
  });
}

Come si vede a riga 11, la lista dei parametri da passare alla funzione getData (lato Java) si trova prima della definizione della funzione di callback della chiamata (lato Javascript) sull’interfaccia Remote.
L’interfaccia Remote.js (definita nella pagina web a riga 7) permette di mappare lato front-end la classe Java Remote e richiamare su di essa i metodi direttamente dalla pagina web.
La funzione di callback intercetta la risposta del server, eseguendo una operazione (in questo caso, stampando un alert).

E’ possibile definire anche altri parametri nella funzione di callback, come il timeout della chiamata o un errorHandler, per intercettare eventuali errori nella comunicazione.

Ecco la lista delle “call options” possibili: http://directwebremoting.org/dwr/documentation/browser/engine/index.html

Remote.getData(42, {
   callback:function(str) { alert(str); },
   timeout:5000,
   errorHandler:function(message) { alert("Oops: " + message); }
});

 

2. Simple callback functions
Un approccio alternativo è quello di “appendere” una funzione di callback alla parameters list:

function handleGetData(str) {
     alert(str);
}

Remote.getData(42, handleGetData);

oppure

Remote.getData(42, function(str) { alert(str); });

Vediamo ora una cosa  molto interessante:

 

Creazione di oggetti JavaScript che matchano oggetti Java
Definiamo il JavaBean Person come segue:

//Lato Java: JavaBean
public Person {

  private String name;
  private int age;
  private Date[] appointments;
  // getters and setters ...

}

Supponiamo di passarlo come parametro di una funzione della classe Java Remote:

//Lato Java
public class Remote {

  public void doSomethingWithPerson(Person p) {
     // Some Java code that does something with Person p.
  }

}

Lato JavaScript, DWR ci permette di creare un oggetto JavaScript che matcha quello Java e passarlo al metodo della classe Remote tramite la sua Interfaccia Remote.js:

//Lato JavaScript
var myJSPerson = {
   name:"Fred Bloggs",
   age:42,
   appointments:[ new Date(), new Date("1 Jan 2008") ]
};

Remote.doSomethingWithPerson(myJSPerson);

Vi lascio approfondire DWR invitandovi a leggere la documentazione e gli esempi riportati sul sito ufficiale.

 

REVERSE AJAX
Di seguito parliamo di nuovo del meccanismo del Reverse Ajax, funzionalità molto utile e distintiva della libreria DWR. Le applicazioni scritte in AJAX usano varie tecniche per refreshare il contenuto di una pagina nel browser. Essenzialmente, effettuano un reversing del normale flusso di comunicazione: è il server che chiama il browser.

DWR implementa tre meccanismi di Reverse Ajax:

  • POLLING: il browser fa una richiesta al server a intervalli regolari (ad esempio, ogni 3 secondi chiede l’aggiornamento di una pagina)

Reverse Ajax - Polling

  • COMET, long lived HTTP (o sload load technique): il server aspetta che il browser lo contatti. Ma l’inizio della risposta alla richiesta del browser avviene lentamente (molto lentamente). Ciò permette al server di mantenere il canale di comunicazione aperto per passare informazioni addizionali quando sono pronte per essere inviate al browser. In poche parole, quando il dato è pronto, il server manda la risposta al client e ciò evita al browser di effettuare continuamente il polling verso il server.

  • PiggyBack: qui il server ha un aggiornamento da inviare, ma aspetta che il browser lo interroghi per poterglielo consegnare. In poche parole, la consegna della risposta del server avviene su esplicita richiesta del browser, con delle interrogazioni successive a quella che ha iniziato la comunicazione.

Reverse Ajax - PiggyBack

Ognuno dei tre metodi descritti ha dei benefici: il Polling è semplice da implementare, ma può facilmente sovraccaricare il server. Invece, Comet migliora un pò quest’ultimo aspetto (very low latency).
Comunque, sia Comet che Polling richiedono connessioni extra, così che converrebbe utilizzare il piggyback ( minore overhead, ma maggiore latenza nella comunicazione).

Leggi l’articolo “Comet low latency data for browser” per maggiori info:
http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/

Lascia un commento

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


quattro × 2 =