Il vous sera demandé des métriques sur vos sources comme le loc (number of lines of code), nombre de classes, nombre de commentaires, nombre de packages, visibilité des attributs/méthodes/classes, ...

Il existe des outils comme JavaNCCS, JMetra. Utilisez ANT.

<taskdef name="javancss"

classname="javancss.JavancssAntTask"

classpath="${CLASSPATH}"/>

<javancss srcdir="${build.src}"

generateReport="true"

outputfile="${test.results.root}/javancss_metrics.xml"

format="xml"/>

Remarquons qu’il existe plusieurs plugins Eclispe qui donne plusieurs métriques sur le projet en cours de développement. Vous pouvez utiliser celui-ci http://metrics.sourceforge.net/

1.9 Généricité

Faites en sorte que vos développements soient génériques et applicables à d’autres domaines d’application

2 Déploiement

Séparez bien le développement (les sources) du déploiement (paramêtrage, exécutables)

2.1 Automatisation

Lors de la démonstration finale, vous avez moins d’un quart d’heure pour déployer vos serveurs sur une dizaine de machine. Il vous faudra donc automatiser la procédure. Utilisez ANT.

Quelques tâches qui vous seront utiles

<get>, <ftp>, <signjar>, <checksum>, <scp> …
Remote ANT http://sourceforge.net/projects/remoteant/ qui exécute un projet sur un site distant (par SOAP)

2.2 Configurabilité

Eviter d'avoir des chemins absolus dans vos fichiers de properties (class java.util.Properties)

Pensez à la portabilité des chemins (UNIX, Windows).

Evitez de fixer les adresses et noms (DNS) de serveurs.

2.3 Hiérarchisation

Vous aurez intérêt à organiser les serveurs à déployer en réservant un répertoire par serveur contenant un fichier de propriété et un java.policy interdisant l'accès à d'autres répertoires que les répertoires de travail et limitant les connexions réseaux, un build.xml (target start, stop, clean), un répertoire lib contenant les .jar signés nécessaires à l'exécution.

Chaque répertoire doit pouvoir être deployé sur une machine distante n'ayant pas de disque partagé (ie C: des PCs des salles de TP)

La partie J2EE de SensorBean est deployé sous la forme d'un .ear

2.4 Performance

Il vous sera demandé de mesurer les performances de vos serveurs Web (celui embarqué dans chaque passerelle OSGi et celui du serveur J2EE) avec Apache JMeter (http://jakarta.apache.org) et de donner des métriques pour des charges de travail qui vous définirez.

En phase d'évaluation de performance, pensez à désactiver vos loggers au moyen d'une variable static final (l'optimiseur de javac supprime le test et la section de code)

final static LOGGER=false;

...

if(LOGGER){

logger....;

// no bytecode inserted

}

2.5 Arrêt (Shutdown) du serveur

Un Ctrl-C n'est pas génial et pas tellement automatisable sous DOS

Prévoyez une procédure pour arrêter proprement vos serveur.

Remarque : la méthode addShutdownHook(Thread hook) de la classe java.lang.Runtime permet d’effectuer des traitements lors de la terminaison de la JVM.

Runtime.getRuntime().addShutdownHook(

new Thread() {

public void run() {

System.out.println("Hook called");

}

);

2.6 Sécurité

Chaque serveur a son propre fichier java.policy qui limite des accès du serveur aux ressources de la machine : les fichiers de configuration sont en lecture seule, les répertoires de travail en lecture/écriture. On peut aussi limiter les connexions réseaux.

Les classes des objets d'une banque doivent être signées avec le certificat de l'équipe de développement de la banque.

La signature est automatisée par une tâche ANT (avant le déploiement).

3 Distribution finale

Comporte un build.xml avec une target dist et un petit manuel de configuration et d'administration dans un répertoire doc

4 Conseils

N'oubliez pas que ce qui est temporaire a tendance a être définitif !

Organisez vous en équipe avec des spécialités identifiées pour chaque membre (chef de projet, architecte, spécialiste méthodes, spécialiste outils (ANT), …

Gardez en mémoire les étapes suivantes.