L’istallazione di resin è quanto di più semplice si possa pensare; dal sito della Caucho Tecnology (www.caucho.com) facciamo il download del pacchetto, facendo attenzione a scaricare la versione professional del server. Ora scompattiamo il file compresso in una directory a nostra scelta, chiameremo questa directory RESIN_HOME. Installiamo la JDK (alcune funzionalità dell’ultima versione di Resin necessitano della JDK 1.5) e settiamo la variabile d’ambiente JAVA_HOME.

Se siamo su un sistema Unix dobbiamo eseguire la classica sequenza di comandi di istallazione:

L’ application server Resin è scritto essenzialmente in Java; i moduli che vengono compilati nella sequenza di istallazione sono per il supporto OpenSSL e per la gestione avanzata delle socket tramite librerie JNI.

A questo punto siamo pronti per far partire il nostro server Resin; se siamo su Unix utilizziamo il comando httpd.sh che si trova nella directory RESIN_HOME/bin per lanciare il nostro server Resin in foreground, oppure https.sh start|stop|restart per lanciare, fermare,o restartare il nostro server in background. Se siamo su piattaforma Windows basta lanciare l’eseguibile httpd.exe che si trova nella RESIN_HOME. In entrambi i casi gli autori di Resin hanno scelto di wrappare il processo java in un eseguibile; su windows httpd.exe genera una piccola console con cui è possibile gestire lo stato del server Resin (start,stop) o uscire dal programma (quit):

Fig 1 - console  di gestione server

Su piattaforma Unix questo eseguibile è uno script PERL wrapper.pl che oltre a gestire lo stato del server si occupa di restartare Resin nel caso in cui cada il processo java.

Ora apriamo il browser all’indirizzo http://localhost:8080 e apparirà la pagina di default di Resin:

Fig 2 - pagina di default di Resin

Bene ora impariamo come configurare un server Resin; ci sono alcuni punti da tenere presenti nella filosofia di gestione di un server Resin

Come vedremo nel seguito dell’articolo è possibile anche aggiungere una nuova web application o un virtual host modificando appropriatamente il file resin.conf. Le direttive specifiche di Resin contenute nel resin-web.xml possono essere inserite anche nel web.xml, anche se questo rende questo file non standard per eventuali deploy su altri application server.

Resin può essere usato come server stand alone con funzioni di web server e application server o in alternativa si può usare un web server come Apache o IIS come front end per servire contenuti statici e Resin come application server di back end per l’elaborazione di contenuti dinamici. L’integrazione con Apache e IIS viene realizzata tramite un modulo plugin (mod_coucho per Apache o isapi_srun.dll per IIS) che ha il compito di selezionare le URL da passare all’application server, inoltrare le richieste e riprendere le risposte dal server Resin.

 Nel file resin.conf è presente un insieme di entry che definisce il deployment delle applicazioni su Resin; la directory di default per il deploy delle applicazioni è RESIN_HOME/webapps.Il context path di default delle applicazioni è RESIN_HOME/webapps/ROOT per le JSP, mentre è RESIN_HOME/webapps/WEB-INF/classes per le servlet e le calssi java.

L’istallazione di una web application su un server Resin può essere fatta in diversi modi:

• Deploy di un file WAR
• Creazione di una directory nella cartella webapps
• Configurazione attraverso il file resin.conf

 Se possediamo il file .war della nostra applicazione basterà copiarlo in questa directory per farlo deployare automaticamente in una directory con lo stesso nome del file war; proviamo ad esempio a deployare il file moltiplicazione.war (http://www.javaportal.it../../../../../JIP/Attachment/20050922/moltiplicazione.war.zip) se Resin è attivo sulla console possiamo vedere il deploy a runtime dell’applicazione al termine della quale possiamo anche vedere la URL con la quale è possibile visualizzare l’applicazione.

 
Fig 3 -  deploy a runtime dell’applicazione sulla console

Ora richiamiamo la webapp tramite il nostro browser alla url http://localhost:8080/moltiplicazione/ServletInput.html e proviamone l’efficienza.

Il secondo modo, e il più semplice, per deployare una nuova web application su Resin è quello di creare una sottodirectory in RESIN_HOME/webapps; se ad esempio creiamo la directory prova ;Resin interpreta la nuova directory come una web application vuota e prepara l’ambiente per inserire i componenti della webapp, quindi inserisce nella nuova directory la seguente porzione di file system:

 
La context root della nuova web application è RESIN_HOME/webapps/prova mentre le classi e le servlet dovranno essere deployate sotto RESIN_HOME/webapps/prova/WEB-INF/classes. Ora inseriamo nella cartella prova una qualsiasi JSP (diciamo index.jsp) e testiamo la aprendo il browser alla url http://localhost:8080/prova/index.jsp.

 Per i deploy automatici vengono applicati i parametri di default, ma se necessitiamo di una web application con dei settaggi particolari allora dobbiamo configurarla nel file resin.conf . Questo è il terzo modo per deployare una web application su Resin; se ad esempio nel file resin.conf inserisco al seguente entry:

  <host id="" root-directory=".">

      …

      <web-app id="/molti">

          <document-directory>apps</document-directory>

          <archive-path>webapps/moltiplicazione.war</archive-path>

      </web-app>

  </host>

In questo caso abbiamo creato una web application “molti” che sfrutta lo stesso war deployato in precedenza automaticamente sotto la webapps. Il war verrà deployato nela directory RESIN_HOME/apps; attenzione prima del deploy verrà cancellato tutto il contenuto di questa directory, quindi assicuratevi che non contenga file importanti; se tale directory non esiste verrà creata. Se infine non viene specificata la document-directory il war viene deployato in una directory della RESIN_HOME con lo stesso nome della web application, nel nostro caso in RESIN_HOME/molti

Resin permette di gestire i Virtual Host. Per chi non lo sapesse il virtual hosting è la possibilità di avere diversi domini erogati dallo stesso server. Ad esempio è possibile avere due domini www.miodominiouno.it e www.miodominiodue.it, completamente indipendenti, erogati dallo stesso server Resin. Esistono due modi per configurare un virtual host su Resin:

1. Dinamic Virtual Host
2. Standalone Virtual Host

 Per quanto riguarda il Dinamic Virtual Host nel file resin.conf  viene configurata la seguente direttiva:

<host-deploy path="hosts">

Con questa direttiva specifichiamo al server Resin che nella directory “hosts” contenuta nella RESIN_HOME metteremo tutti i nostri virtual host; da notare che la directory “hosts” non esiste di default nella RESIN_HOME, è quindi necessario crearla a mano. Il modo più semplice per creare un virtual host con Resin è quello di creare un sotto-directory in RESIN_HOME/hosts; Resin a runtime, oppure al riavvio, interpreta il nome della directory creata come il nome di un virtual host, e addirittura crea la struttura delle directory necessaria per deployare le applicazioni sotto il nuovo virtual host; se ad esempio creiamo la directory “miohost” dopo qualche secondo automaticamente Resin creerà la seguente porzione di filesystem:

La directory webapps, generata automaticamente da Resin, è delegata a contenere le web application che verranno invocate tramite il nome del nostro virtual host. Per il deploy di web application nel nostro virtual host valgono le stesse regole descritte precedentemente solo che in questo caso la directory di default sarà RESIN_HOME/hosts/miohost. Quindi prendiamo il nostro moltiplicazione.war utilizzato in precedenza e copiamolo nella directory

RESIN_HOME/hosts/miohost/webapps per farlo deployare; dopodichè inseriamo nel file hosts della nostra macchina la seguente riga:

 127.0.0.1 miohost

A questo punto apriamo il nosro browser alla url http://miohost:8080/moltiplicazione/ServletInput.html per testare il funzionamento del nuovo virtual host.

Da notare che non viene creata automaticamente la cartella ROOT; nonostante questo la context path di default per il nuovo virtual host è RESIN_HOME/hosts/miohost/ROOT. Per cui se vogliamo che una qualsiasi JSP, diciamo index.jsp, sia raggiungibile attraverso la url http://miohost:8080/index.jsp, dobbiamo creare a mano la cartella RESIN_HOME/hosts/miohost/ROOT e inserirvi la index.jsp.

 
La configurazione Standalone di un Virtual Host viene fatta inserendo i nel resin.conf le seguenti direttive:

<host id='miohost'>

   <root-directory>nuovihost/miohost</root-directory>

</host>

 Diversamente dagli altri Application Server che istanziano l’EJB container di default, Resin crea il container degli EJB solo se necessario. Quindi quando una web application utilizza degli EJB deve configurare all’interno del resin-web.xml l’ejb-server specificando dove si trova il descrittore degli EJB ejb-jar.xml e il nome JNDI necessario per reperire il Context:

<ejb-server jndi-name="java:comp/env/ejb">
  <ejb-descriptor>META-INF/ejb-jar.xml</ejb-descriptor>
</ejb-server>

Nella tabella seguente sono contenute le descrizioni di tutti i parametri di configurazione dell’ejb-server:

Fig 4 - i parametri di configurazione dell’ejb-server

Creiamo ora un EJB da deployare nel nostro container; il nostro EJB avrà un metodo che restituisce il numero totale di volete che l’EJB è stato invocato. Abbiamo quindi bisogno dei seguenti elementi:

•    Remote Interface
•    Home interface
•    Bean Implementation
•    Deployment descriptor

Nella RESIN_HOME/webapps creiamo una nuova directory “counter”; come spiegato precedentemente Resin crea automaticamente l’ambiente per il deploy della web application. Sotto counter/WEB-INF/classes inseriamo la cartella ktech che conterrà le classi del nostro EJB e infine creiamo la cartella counter/META-INF dove inseriremo il nostro deployment descriptor.
Innanzitutto scriviamo la Bean Implementation nel file CounterBean.java:

package ktech;

import javax.ejb.*;
import java.util.*;

public class CounterBean implements SessionBean {
  int count;

    private SessionContext ctx;        
    public CounterBean() {}
    public void setSessionContext(SessionContext c) {
        ctx=c;
    }

    public void ejbCreate() {}    
    public void ejbRemove() {}   
    public void ejbPassivate() {}
    public void ejbActivate() {}

  public int hit()
  {
    return ++count;
  }
}

Quindi la Home Interface in CounterLocalHome.java :

package ktech;
import javax.ejb.*;
public interface CounterLocalHome extends EJBLocalHome {
  CounterLocal create() throws CreateException;
}

e la Remote Interface in CounterLocal.java :

package ktech;
import javax.ejb.*;
public interface CounterLocal extends EJBLocalObject {
  int hit();
}

Ora per completare il deploy dobbiamo scrivere il Deploy Descriptor ejb-jar.xml :

<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
  <session>
    <ejb-name>counter</ejb-name>
    <local-home>ktech.CounterLocalHome</local-home>
    <local>ktech.CounterLocal</local>
    <ejb-class>ktech.CounterBean</ejb-class>
    <session-type>Stateful</session-type>
    <transaction-type>Bean</transaction-type>
  </session>
</enterprise-beans>  
</ejb-jar>

All’avvio di Resin possiamo leggere nella console le fasi di compilazione dell’EJB. Durante la compilazione viene creata dall’application server una directory work/ejb/_ejb/counter sotto counter/WEB-INF all’interno della quale viene deployato l’EJB. Ora non ci rimane che invocare l’EJB tramite una jsp che chiameremo counter.jsp:

<%@ page language="java" import="ktech.*, javax.naming.* " %>
<%

CounterLocalHome convHome;
CounterLocal conv;

HttpSession hs = request.getSession();
conv = (CounterLocal) hs.getAttribute("home");
if ( conv == null){
   try {
    Context ejb = (Context) new InitialContext().lookup("java:comp/env/ejb");
    convHome = (CounterLocalHome) ejb.lookup("counter");
    } catch (NamingException e) {
        throw new ServletException("java:comp/env/ejb",e);
    }
 conv = convHome.create();
 hs.setAttribute("home",conv);
 }
%> EJB chiamato : <%= conv.hit() %> volte <br/>
<a href="http://localhost:8080/counter/counter.jsp">Richiama</a>

 
Fig 5 - Le chiamate all' EJB si incrementano 

Resin supporta anche una modalità deploy automatico degli EJB; invece di utilizzare l’ejb-jar.xml come unico deploy descriptor viene utilizzato un file descriptor differente per ogni EJB con estensione *.ejb. Configurando il nostro ejb-server nel seguente modo:

<ejb-server jndi-name="java:comp/env/ejb" config-directory="WEB-INF"/>

diciamo all’application server di leggere tutti i file *.ejb contenuti nella directory WEB-INF ed effettuare il deploy. Il contenuto dei file *.ejb è identico a quello del file ejb-jar.xml tranne che per il fatto che viene descritto un unico EJB. Nel caso dell’esempio precendente scriveremo un file CounterBean.ejb di questo tipo:

<ejb-jar>
<enterprise-beans>
  <session>
    <ejb-name>counter</ejb-name>
    <local-home>ktech.CounterLocalHome</local-home>
    <local>ktech.CounterLocal</local>
    <ejb-class>ktech.CounterBean</ejb-class>
    <session-type>Stateful</session-type>
    <transaction-type>Bean</transaction-type>
  </session>
</enterprise-beans> 
</ejb-jar>

 La configurazione di un DataSource con Resin è molto semplice e può essere fatta sia a livello di server, e quindi all’interno del resin.conf, sia a livello di web application, e quindi nel resin-web.xml. Una tipica configurazione di un datasource per il DB MySQL è la seguente:

<database>
  <jndi-name>jdbc/mysql</jndi-name>
  <driver>
    <type>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</type>
    <url>jdbc:mysql://localhost:3306/dbname</url>
    <user>username</user>
    <password>password</password>
  </driver>
  ...
</database>

Nella configurazione dobbiamo specificare il nome JNDI con cui verrà reperito il DataSource, la classe che implementa il DataSource per lo specifico database (nell’esempio specifico viene utilizzata una versione avanzata dei driver per MySQL che fa uso dei Connector-J), la URL del database dove dbname è il nome dello schema che vogliamo utilizzare, user e password per lo schema precedentemente specificato. Un semplice esempio di codice per accedere al database è il seguente:

……
int contaRighe() throws ServletException
  {
  String DATASOURCE_NAME = "jdbc/mysql";
  int numeroRighe = -1;
  DataSource pool;
    try {
      Context env = (Context) new InitialContext().lookup("java:comp/env");
      pool = (DataSource) env.lookup(DATASOURCE_NAME);
      if (pool == null)
        throw new ServletException("`" + DATASOURCE_NAME + "' is an unknown DataSource");
    } catch (NamingException e) {
      throw new ServletException(e);
    }
    Connection conn = null;
    try {
      conn =pool.getConnection();
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery("SELECT COUNT(*) FROM `nomeTabella`");
      while (rs.next()) {
      numeroRighe = rs.getInt(1);
      }
      rs.close();
      stmt.close();
    } catch (SQLException e) {
      throw new ServletException(e);
    } finally {
      try {
        if (conn != null)
          conn.close();
      } catch (SQLException e) {
      }
    }
    return numeroRighe;
  }
……


In questo esempio abbiamo scritto un metodo che conta le righe di nomeTabella;
Di seguito riportiamo una tabella con la lista completa dei parametri di configurazione di un DataSource:

 Fig 6 -parametri di configurazione di un DataSource

Per una configurazione avanzata del DataSource possiamo impostare una serie di parametri del pool di connessione (pooling parameter), oppure dei parametri per verificare l’affidabilità della connessione con il database (reliability parameter) oppure utilizzare un sistema di caching degli ultimi statement utilizzati impostando il tag prepared-statement-cache-size ad un valore diverso da zero.

 Resin supporta l’utilizzo delle code JMS sia di tipo Point-to-Point (Queue) che Publish/Subscribe (Topics). In particolare vengono forniti due possibili implementazioni:

1.    Non Persistente in memoria
2.    Persistente su database

Nella prima soluzione le code JMS sono residenti in memoria; a fronte di una minore affidabilità le code JMS non persistenti forniscono un servizio più performante. Le code JMS persistenti invece utilizzano un database per lo storage dei messaggi, mantengono quindi i messaggi in coda anche in caso di interruzione del servizio.
Vediamo ora come configurare una coda JMS di tipo queue non persistente; nel notro resin-web.xml inseriremo le seguenti righe:

<resource jndi-name="jms/my-queue" type="com.caucho.jms.memory.MemoryQueue">
  <init>
    <queue-name>my-queue</queue-name>
  </init>
</resource>

oppure se vogliamo configurare un topics:

<resource jndi-name="jms/my-topic" type="com.caucho.jms.memory.MemoryTopic">
  <init>
    <topic-name>my-topic</topic-name>
  </init>
</resource>

Se invece vogliamo configurare una queue di tipo persistente dobbiamo prima definire il DataSurce dove verranno memorizzati i messaggi; supponiamo di utilizzare lo stesso DataSource definito nel paragrafo precedente:

<database>
  <jndi-name>jdbc/mysql</jndi-name>
  <driver>
    <type>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</type>
    <url>jdbc:mysql://localhost:3306/dbname</url>
    <user>username</user>
    <password>password</password>
  </driver>
</database>

 Dopodichè configureremo la queue persistente specificando il DataSource utilizzato per lo storage dei messaggi, in questo modo:

<resource jndi-name="jms/my-queue" type="com.caucho.jms.jdbc.JdbcQueue">
  <init>
    <queue-name>my-queue</queue-name>
    <data-source>jdbc/mysql</data-source>
  </init>
</resource>

Se invece vogliamo configurare un topic persistente:

<resource jndi-name="jms/my-topic" type="com.caucho.jms.jdbc.JdbcTopic">
  <init>
    <topic-name>my-topic</topic-name>
    <data-source>jdbc/mysql</data-source>
  </init>
</resource>

Al momento dell’avvio Resin crea automaticamente sul database specificato tre tabelle necessarie per la gestione della coda JMS:

•    resin_jms_consumer – Contiene la lista degli consumer registrati alle code JMS configurate
•    resin_jms_destination – Contiene la lista delle code JMS configurate
•    resin_jms_message – Contiene i messaggi inviati alle code JMS configurate

La gestione delle tabelle è totalmente a carico dell’application server Resin e quindi completamente trasparente.
Vediamo ora come sfruttare le code JMS appena create; come è noto i client che scrivono e leggono la coda JMS utilizzano una ConnectionFactory specifica per ogni tipo di Application server che viene reperita tramite JNDI dall’application server stesso. Quindi la prima cosa da fare è definire la ConnectionFactory nella nostra applicazione; quindi nel resin-web.xml inseriremo la seguente direttiva:

<resource jndi-name="jms/simple-factory" type="com.caucho.jms.ConnectionFactoryImpl"/>

Ora scriviamo una semplice jsp che invia un messaggio alla coda JMS:

<%@ page language="java" import="ktech.*, javax.naming.*, javax.jms.* " %>
<%

Context context = null;
Connection conn = null;
Session sess = null;
javax.jms.Queue queue = null;
MessageProducer sender = null;
TextMessage message = null;
String testo = "testo di prova";
String esito = null;

  try {
      context = new InitialContext();
     

ConnectionFactory

factory = (ConnectionFactory)context.lookup("java:comp/env/jms/simple-factory");
      conn = factory.createConnection();
      sess = conn.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
      queue = (javax.jms.Queue)context.lookup("java:comp/env/jms/my-queue");
      sender = sess.createProducer(queue);
      message = sess.createTextMessage();
      message.setText(testo);
      sender.send(queue, message);
      esito = "Riuscito";
  } catch (NamingException e) {
    e.printStackTrace();
    esito = "Fallito";
  }
 
%> Esito invio messaggio<%= esito %><br/>

 
Resin fornisce una serie di API per la gestione della sicurezza che le applicazioni possono utilizzare per proteggere le risorse senza implementare librerie ad-hoc. L’autenticazione si basa principalmente su 3 elementi: l’authenticator che definisce il tipo di autenticazione da utilizzare e le utenze, il login-config che definisce il tipo di login con cui accedere ai contenuti protetti, il security-constraint che definiscono le politiche di sicurezza.

Fig 7 - Autenticazione

digitando le opportune credenziali avremo accesso all’applicazione.

Fig 8 - Resin e gli altri Server Open Source

I valori esprimono il numero di risorse servite in un arco di tempo prestabilito.

 
In ambienti di produzione con traffico molto elevato si rende necessario l’utilizzo del cluster ovvero di un gruppo di istanze di resin che erogano il medesimo servizio collaborando tra loro. Il cluster oltre a distribuire il carico secondo determinate politiche di amministrazione, permette anche di gestire il failover facendo uso della persistenza e la distribuzione dello stato della sessione HTTP.

 
Abbiamo effettuato una rapida carrellata sulle principali feature dell’Application Server Resin ma Resin offre molte altre funzionalità che meritano di essere approfondite. Per questo potete consultare la documentazione contenuta sul sito www.caucho.com. Resin si sta imponendo all’attenzione del mercato per essere un prodotto agile e di facile utilizzo, corredato di tutte le funzioni necessarie, e anche per i suoi costi contenuti. Speriamo quindi di aver attirato la vostra attenzione su questo Application Server. Ringraziamo la Caucho Technology, ed in particolare Steve Montal, per il supporto fornito durante la stesura dell’articolo.