Introduzione
Il deployment è l'ultima e la più corta tappa [1] del processo di sviluppo, ma non è meno importante di altre. Sun Microsystems dà allo sviluppatore di Java tecnologie molto potenti per semplificare il processo del deployment: Java Web Start [2] per le applicazioni J2SE ed il J2EE Enterprise Archive (EAR) per le applicazioni J2EE. Questo articolo descrive come integrare nel build script di Apache Ant [4] la procedura di deployment ed automatizzarla completamente.

La tecnologia Java Web Start aiuta moltissimo ad implementare il processo del deployment sui desktop. Il deployment sui diversi J2EE server varia molto. Quasi ogni server ha il proprio tool per eseguire l'operazione. Così J2EE Reference Implementation include deploytool, BEA WebLogic Server - weblogic.deploy, SilverStream Application Server - SilverCmd, e per JBoss Application Server occorre copiare l'archivio in una cartella predefinita. L'articolo è incentrato a come configurare il processo del deployment sul più famoso J2EE application server con sorgenti aperte - JBoss. Ma l'informazione trattata può essere facilmente applicata a qualunque altro J2EE application server.

Dipendenza dalla piattaforma
Malgrado la predominanza dei desktop che girano sulla piattaforma Windows, il mercato dei server, fino ad ora, è presentato di più con la piattaforma Unix. Pertanto prima parliamo del caso in cui il deployment server gira su questa famiglia di sistemi operativi.

Deployment a JBoss su Unix
Prendiamo come un esempio un'applicazione web J2EE che gira su JBoss. L'applicazione tra gli altri componenti include anche un'application client. JBoss ha introdotto il supporto dei application client dalla versione 3.2.0. L'invio dell'application client si fa all'esterno del J2EE application server. Così occorre avere il JAR dell'application client, non solo incluso in EAR, ma anche a parte. Questa particolarità crea la necessità di tenere le copie sincronizzate dello stesso JAR.

Figura 1 - Deployment del EAR che contiene l'application client a JBoss.

Per il caso descritto lo script potrebbe essere qualcosa del genere:

<target name="jboss_deploy" depends="jboss_build_all" >
<!--
Questo target è in dipendenza della libreria jsch*.jar.
L'ultima versione della libreria si può scaricare
dal sito: http://www.jcraft.com/jsch/index.html
-->
<property name="deployment.host" value="test-server" />
<property name="jboss.home" value="/u01/jboss-3.2.5" />
<property name="app.home" value="/home/jboss/app" />
<!--
Per motivi di sicurezza è meglio non scrivere i
dati dell'utente interno allo script, ma
specificarli nella linea di comando.

<property name="user" value="jboss" />
<property name="pwd" value="jboss" />
-->

<!-- Può essere: "all", "default", "minimal" -->
<property name="jboss.conf" value="default" />

<!-- Deployment di .ear a JBoss -->
<scp todir="${user}:${pwd}@${deployment.host}:${jboss.home}/server/${jboss.conf}/deploy"
file="${dist}/${application.name}.ear"
trust="true"
/>

<!-- Deployment delle librerie all'albero di applicazione -->
<scp todir="${user}:${pwd}@${deployment.host}:${app.home}/lib"
trust="true" >

<fileset dir="${dist}" >
<include name="app_client_lib.jar" />
<include name="${ejb.name}.jar" />
<include name="${app_client.name}.jar" />
</fileset>
</scp>
</target>

Lo script copia i file sul server Unix usando il task scp [4] di Ant.

Figura 2 - Deployment alla macchina di Unix usando scp

Il task scp è opzionale, perciò prima di usarlo è necessario aggiungere alla cartella "lib" di Ant la libreria jsch*.jar. L'ultima versione della libreria si può scaricare dal sito: http://www.jcraft.com/jsch/index.html .

Altre possibilità
Non abbiamo toccato i server Windows fin ora perché il task scp può copiare i file solo sulla macchina di Unix. E' ovvio che se il deployment server è lo stesso sul quale si lancia lo script si può usare il task copy [4] che lavora su tutte le piattaforme. Se invece, il server è su una macchina diversa, una delle soluzioni potrebbe essere fare la copia usando ftp [4]. Per questo sul server è necessario attivare il servizio di ftp. Questa possibilità rimane valida per tutte e due le piattaforme.

Figura 3 - Deployment usando ftp.

C'è anche la possibilità di usare cartelle condivise e copiare i file usando uno script esterno lanciandolo con il task exec [4]. Se il build server è sulla macchina di Unix, lo shell script esterno può copiare i file necessari usando SAMBA. Invece, se il build server gira sul Windows la stessa procedura può essere fatta usando BAT script che chiama xcopy.

Figura 4 - Deployment alla macchina di Windows usando xcopy.

Sicurezza
Il processo di deployment automatico deve essere configurato con tanta attenzione per la sicurezza. La configurazione temeraria può creare un buco di sicurezza nel tuo sistema. E' meglio evitare di scrivere negli script i dati dell'account e di sicuro non usare un'account potente come il root. Meglio creare un account dedicato solo per l'operazione del deployment limitandolo al massimo possibile e dando l'accesso a scrivere solo nelle cartelle necessarie.

Conclusione
Il deployment automatizzato usando il build script porta i seguenti vantaggi:

1. Il processo di deployment diventa ancora più veloce e facile da fare automatizzando due ruoli J2EE: l'application assembler e il deployer.
2. Il deployment automatico garantisce integrità del processo che è importante quando la procedura di deployment consiste in più passi.

Bibliografia
[1] Philippe Kruchten - The Rational Unified Process An Introduction, Addison-Wesley, 2000, ISBN 0-201-70701-0
[2] Sun Microsystems, Inc. -Java Web Start Technology, http://java.sun.com/products/javawebstart/
[3] Paul Allen - J2EE Unleashed, Sams, 2001, ISBN 0-672-32180-7
[4] Apache Software Foundation - Apache Ant 1.6.2 Manual, 2004

Yury Fedorov laureato in Tecnologie Informatiche, lavora da più di 6 anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo ora si occupa in particolare di aspetti architetturali per progetti rivolti al mercato e-business. Ha numerosi certificati di Brainbench e in particolare Master Java, Internet Professional Web Developer Client-side e Internet Professional Web Developer Server-side.