Java

Java

Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3

Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3

Le projet Apache Camel est un framework d’intégration basé sur l’implémentation de patterns d’intégration d’entreprise connus. Il permet d’implémenter des règles de routage et de médiation à partir d’un DSL Java ou bien via des configurations Spring au format Xml.

Apache Camel utilise la notion d’URIs, ce qui permet de travailler facilement avec différents types de transport ou modèles d’échange de messages, tels que HTTP ou JMS. De la même manière, Apache Camel est capable de travailler avec différents formats de données (Csv, Xml, Json, …).

L’utilisation des composants fournis out of the box permet de travailler avec de nombreux protocoles et formats de données. Mais qu’en est-il lorsqu’un connecteur vient à manquer?

Pour répondre à cette question, le projet Apache Camel propose une API complète permettant d’implémenter soi-même des composants adaptés à son besoin.

Objectif

L’objectif de cet article est de présenter comment initier le développement d’un composant Apache Camel.

Pour cela, nous mettrons en place un composant qui permettra de dialoguer avec l’Apple Push Notification Service, dans le but d’envoyer des notifications aux différents terminaux Apple (iPad, iPhone, iPod Touch).

Le composant proposera à la fois des endpoints de type producer et de type consumer qui permettrons respectivement d’envoyer des notifications et de lire un flux feedback d’informations en provenance de l’APNS.

En pré-requis, un ensemble de endpoints devra utiliser une même instance de la classe ApnsService proposée par la librairie java-apns, qui permet de dialoguer avec les serveurs d’Apple. La firme à la pomme préconise en effet de créer un nombre limité de connexions, et de réutiliser celles-ci pour communiquer avec ses serveurs. Nous utiliserons également le scheme apns pour déclarer les URIs qui représenteront les endpoints gérés par nos composants.

Présentation de l’APNS

L’Apple Push Notification Service est disponible pour les applications destinées aux iPhones, iPads et iPods touch. Il permet d’envoyer des notifications de 3 types : texte, image ou badge.

Pour envoyer une notification, un provider (une application serveur en général) doit en premier lieu envoyer la notification à l’Apple Push Notification Service qui se chargera à son tour de diffuser la notification aux terminaux concernés.

La notification est composée d’un token (identifiant unique d’un terminal) et d’un payload (contenu de la notification).

Simple notification APNS

L’APNS propose en complément de l’envoi de notifications, un flux feedback d’informations permettant de connaître la liste des terminaux pour lesquels les notifications n’ont pu être délivrées de façon répétée (généralement, lorsque l’application a été désinstallée).

Pour qu’une application iOS soit en mesure de recevoir des notifications, elle doit en premier lieu fournir à l’application serveur (celle qui va envoyer les notifications aux serveurs Apple) toutes les informations nécessaires notamment son token d’identification. Cette opération peut-être réalisée, par exemple, via un simple appel HTTP.

Séquence d'enregistrement

API Java de connexion à l’APNS

De nombreux projets permettent de dialoguer avec l’APNS via différents langages de programmation. Actuellement deux implémentations existent pour le langage Java :

Historiquement, l’implémentation javapns est apparue avant java-apns. Cependant nous choisirons d’utiliser la librairie java-apns qui a pour avantage de proposer des fonctionnalités complètes (gestion de pool de connections, capacité de reconnexion, …), ainsi qu’une API élégante et différentes facilités d’écriture de tests unitaires.

Les endpoints Camel

Le développement d’un endpoint Apache Camel implique d’implémenter une ou plusieurs des méthodes suivantes selon les besoins :

Méthode Description
createProducer() Crée un producer permettant d’envoyer des messages à un endpoint
createConsumer() Crée un consumer implémentant le pattern Event Driven Consumer pour consommer des messages depuis un endpoint
createPollingConsumer() Crée un consumer implémentant le Polling Consumer pour consommer des messages depuis un endpoint

L’Event Driven Consumer

Solution Event Driven Consumer

Ce modèle événementiel de consommation des messages correspond au modèle de consommation par défaut des messages par les composants Camel.

Le Polling Consumer

Solution Polling Consumer

Le polling consumer propose 3 types de méthodes:

Méthode Description
receive() Attend qu’un échange soit disponible et le retourne (potentiellement indéfiniment)
receive(long) Attend un échange jusqu’à un timeout défini. Renvoie null si aucun échange n’a été reçu dans le temps imparti
receiveNoWait() Tente de recevoir un message sans attendre de timeout et retourne null si aucun échange n’est disponible

Le composant camel-jms implémente cette notion de polling-consumer pour s’intégrer à Apache Camel.

Générer un squelette de composant

Partir de zéro pourrait s’avérer compliqué. Heureusement le projet Apache Camel met à disposition l’archétype Maven: camel-artefact-component.

mvn archetype:create 
-DarchetypeGroupId=org.apache.camel.archetypes 
-DarchetypeArtifactId=camel-archetype-component 
-DarchetypeVersion=2.3.0 
-DgroupId=org.apache.camel 
-DartifactId=camel-apns

L’exécution de la ligne de commande précédente va créer un squelette de composant sur lequel s’appuyer pour développer notre composant:

Contenu généré par l'archetype Maven

L’archétype va générer la structure nécessaire au développement du composant Camel. Cependant il sera nécessaire de personnaliser le composant nouvellement créé pour qu’il corresponde au nommage souhaité :

  • ‘META-INF/services/<PACKAGE_NAME>/direct’ devra être renommé selon le scheme de l’URI de votre composant (Dans notre cas: ‘apns’).
  • Les différentes classes générées seront préfixées par ‘Apns’ plutôt que ‘Direct’.

Il est possible de supprimer les classes qui ne seraient pas utilisées dans le cas où le composant serait uniquement destiné à consommer des messages ou à bien en produire.

Après renommage, le résultat obtenu doit être le suivant :

Vue composant APNS

Importer son composant dans Eclipse

Pour cela, il est possible d’utiliser la commande suivante:

mvn eclipse:eclipse

Le fichier pom.xml

Il est conseillé d’hériter du projet parent camel-parent:

	 
<parent>
	<groupid>org.apache.camel</groupid>
	<artifactid>camel-parent</artifactid>
	<version>2.4.0</version>
</parent>

Le composant camel-parent déclare en effet un certain nombre de dépendances nécessaires, ainsi que le type bundle qui permet d’OSGifier son composant. Ceci permettra aux utilisateurs/développeurs de le déployer dans un conteneur OSGi, tel qu’Apache ServiceMix.

Nous allons donc déclarer le packaging du composant, ainsi que différentes propriétés nécessaires à l’OSGificiation comme suit:

<packaging>bundle</packaging>
...
<properties>
	...
	<!-- OSGi bundles properties -->
	<camel .osgi.import.pkg><strong></strong></camel>
	<camel .osgi.private.pkg>!</camel>
	<camel .osgi.export>${camel.osgi.export.pkg}*;version=${camel.osgi.export.version}</camel>
	<camel .osgi.export.version>${project.version}</camel>
	<camel .osgi.import>${camel.osgi.import.pkg}</camel>
	<camel .osgi.symbolic.name>${groupId}.${artifactId}</camel>
</properties>

Il est également nécessaire de déclarer les dépendances Camel dont nous aurons besoin, ainsi que les dépendances nécessaires à l’implémentation du composant:

<dependencies>
	...
	<!-- Camel -->
	<dependency>
		<groupid>org.apache.camel</groupid>
		<artifactid>camel-core</artifactid>
		<version>${camel.version}</version>
	</dependency>
	<dependency>
		<groupid>org.apache.camel</groupid>
		<artifactid>camel-spring</artifactid>
		<version>${camel.version}</version>
	</dependency>
	<dependency>
		<groupid>org.apache.camel</groupid>
		<artifactid>camel-test</artifactid>
		<version>${camel.version}</version>
		<scope>test</scope>
	</dependency>
	...
	<!-- APNS -->
	<dependency>
		<groupid>com.notnoop.apns</groupid>
		<artifactid>apns</artifactid>
		<version>${apns.version}</version>
		<exclusions>
			<exclusion>
				<groupid>ch.qos.logback</groupid>
				<artifactid>logback-classic</artifactid>
			</exclusion>
		</exclusions>
	</dependency>
	...
</dependencies>

Le projet Apache Camel propose le plugin camel-maven-plugin que nous allons déclarer dans notre fichier pom. Celui-ci permet de lancer en ligne de commande une instance standalone d’Apache Camel et de démarrer les routes qui sont déclarées dans le classpath via le fichier Spring suivant: ‘META-INF/spring/camel-context.xml’.

<!-- allows the route to be ran via 'mvn camel:run' -->
<plugin>
	<groupid>org.apache.camel</groupid>
	<artifactid>camel-maven-plugin</artifactid>
	<version>${camel.version}</version>
</plugin>

Plusieurs entrées repository et pluginReposity doivent également être déclarées dans le pom afin que Maven puisse importer différentes dépendances et plugins nécessaires à notre projet:

<repositories>
	<repository>
		<id>open.iona.m2</id>
		<name>IONA Open Source Community Release Repository</name>
		<url>http://repo.open.iona.com/maven2</url>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
		<releases>
			<enabled>true</enabled>
		</releases>
	</repository>
	<repository>
		<id>open.iona.m2-snapshot</id>
		<name>IONA Open Source Community Snapshot Repository</name>
		<url>http://repo.open.iona.com/maven2-snapshot</url>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
		<releases>
			<enabled>false</enabled>
		</releases>
	</repository>
	<!-- java-apns repository -->
	<repository>
		<id>notnoop-repos</id>
		<url>http://notnoop.github.com/m2-repo</url>
	</repository>
	...
	<repository>
		<id>apache.incubating.releases</id>
		<name>Apache Incubating Release Distribution Repository</name>
		<url>http://people.apache.org/repo/m2-incubating-repository</url>
	</repository>
</repositories>
<pluginrepositories>
	<pluginrepository>
		<id>open.iona.m2</id>
		<name>IONA Open Source Community Release Repository</name>
		<url>http://repo.open.iona.com/maven2</url>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
		<releases>
			<enabled>true</enabled>
		</releases>
	</pluginrepository>
	<pluginrepository>
		<id>open.iona.m2-snapshot</id>
		<name>IONA Open Source Community Snapshot Repository</name>
		<url>http://repo.open.iona.com/maven2-snapshot</url>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
		<releases>
			<enabled>false</enabled>
		</releases>
	</pluginrepository>
	<pluginrepository>
		<id>maven-repository.dev.java.net</id>
		<name>Java.net Maven 2 Repository</name>
		<url>http://download.java.net/maven/2</url>
	</pluginrepository>
</pluginrepositories>

Conclusion

Nous avons vu dans cette première partie comment initier le développement d’un composant Camel à l’aide de l’archétype Maven camel-archetype-component.

Dans un prochain billet, nous verrons comment implémenter les différentes classes d’un composant Camel. Puis nous conclurons dans une troisième et dernière partie, par la présentation des méthodes permettant de tester notre composant afin de fournir un livrable de qualité.

Liens utiles

Le site google code du composant camel-apns présenté dans cet article:

Parties suivantes de l’article :

Nokia donne son « Mobile Runtime » Java à la fondation Symbian

Nokia donne son « Mobile Runtime » Java à la fondation Symbian

Dans un effort de rendre plus accessible le développement d’applications Java pour les mobiles basés sur le système Symbian, Nokia vient d’annoncer, ce 15 juillet, faire don de son « Mobile Runtime for Java Applications » (JRT) à la fondation Symbian (créée en 2008 justement, suite au rachat de Symbian Software Limited). Avec le don de son JRT, Nokia met à disposition pas moins d’1 million de lignes de code Java et C++ correspondant à son runtime, son installeur d’applications, ses API, ses tests et sa documentation. Le tout est mis à disposition sous license Eclipse Public License (EPL) et est disponible comme partie intégrante du dernier Symbian^3 Product Development Kit.

Nokia annonce le support de la norme MIDP 2.1 (JSR 118), ainsi que ses nombreuses JSR, dont l’architecture MSA. Rien de bien nouveau, jusqu’à présent, serait-on tenté de dire. D’un point de vue graphique, la plateforme Symbian^3 apporte le support d’une accélération graphique hardware, ainsi que deux API non standard : la classique Nokia UI API en version 1.4, ainsi qu’une implémentation de l’Eclipse Standard Widget Toolkit (eSWT) UI API en version 1.0.3.

En complément du langage Java, Le SDK Symbian^3 propose d’écrire des applications natives en utilisant le langage C++ et le support intégré du tookit graphique Qt. Un support de développement basé sur les technologies Web est également disponible, il permet de construire des applications basées sur le Nokia’s Web Runtime (WRT) et l’outil PhoneGap, qui permet de tirer parti de différentes fonctionnalités de l’OS habituellement uniquement accessibles par les applications natives.

Pour les curieux, une roadmap de développement permet de se faire une idée des fonctionnalités des futures version de la plateforme.

Quelle stratégie pour Nokia en 2010?

Dès 2008, Nokia avait préparé sa riposte face à la sortie de la plateforme mobile Android de Google. Déjà détenteur de 48% de la société Symbian Limited, Nokia avait racheté les parts restantes auprès de ses concurrents de l’époque (Sony-Ericsson, Panasonic, Siemens, …) pour un montant avoisinant les 250 millions d’euros. Ce rachat qui n’était qu’une première étape devait permettre à Nokia de faire don de la plateforme Symbian à la fondation éponyme. A la même époque les autres acteurs de l’environnement Symbian devaient faire de même: Sony-Ericsson et Motorola devaient, entre autre, fournir la technologie UIQ à la fondation. Le but de la fondation Symbian était donc de créer, à partir de ces différentes contributions, une plateforme mobile unifiée ouverte à la communauté.

En l’espace de 2 ans, le paysage des plateformes mobiles a cependant bien changé: l’iOS d’Apple est devenu un leader emblématique, même s’il commence à se faire disputer le titre par la plateforme Android de Google, tandis que Microsoft tente revenir dans la course pour les fêtes avec son nouveau système Windows Phone 7. En parallèle, de nouveaux acteurs apparaissent tel que Samsung avec son système Bada, ou bien Baidu qui souhaite copier son grand frère Google avec un OS ayant pour ambition de conquérir le marché chinois …

Près de 2 ans après la présentation de sa stratégie pour contrer Google, l’annonce de la sortie de Symbian^3 par Nokia ressemble beaucoup à une tentative désespérée de raccrocher le wagon. Il n’est plus l’heure pour Nokia de redorer son blason, mais plutôt de sauver les meubles dans un secteur où les évolutions se font à coup de bottes de sept lieues. Pour s’en convaincre, il suffit de comparer le paysage des plateformes mobiles aujourd’hui avec celui de 2008. Malgré un parc important d’appareils mobiles déployés et sa communauté de développeurs, Nokia est toujours à la recherche d’un business model efficace. Ses talents d’innovation et de fabricant de combinés haut de gammes semblent être un lointain souvenir tant la concurrence a pris de l’avance rapidement. La stratégie de Nokia est-elle la bonne ? Nokia est en tout cas, aujourd’hui, au pied du mur. Le géant scandinave annonce pour la fin d’année des appareils compatibles avec la toute dernière version de la plateforme Symbian, comme le Nokia N8. Dans un marché en mouvement permanent, cela sera-t-il suffisant ?

Sortie d’Apache Camel 2.4

Sortie d’Apache Camel 2.4

Deux mois seulement après la sortie d’Apache Camel en version 2.3.0, une nouvelle version 2.4.0 vient tout juste de sortir. Elle vient compléter un changelog déjà très fourni sur la version précédente et apporte son lot de corrections, améliorations et nouveautés :

  • Un support plus poussé d’OSGI avec la prise en charge de la norme Blueprint et la création d’un namespace XML adapté permettant de définir des routes Camel. Ce namespace est pour le moment uniquement exploitable via l’implémentation Blueprint ‘Apache Aries’ utilisée par le projet ‘Apache Karaf’. A noter que la définition d’errorHandler n’est pas possible pour le moment.
  • Un moteur de routage asynchrone non bloquant complet: tous les patterns d’intégration sont supportés ainsi que différents composants: JBI, NMR, CXF, Jetty et Netty.
  • La version de Spring utilisée par Camel passe à la 3.0.3 marquant ainsi la fin du support de la branche 2.0 (La version 2.5 étant encore supportée). Le support de Spring Security pour sa part change également de version et passe à la 3.0.3.RELEASE.

La version 2.3.0 proposait déjà de nombreuses améliorations majeures telles que le support des Property placeholders qui manquaient cruellement, ainsi que le support d’un nombre conséquent de nouveaux composants (camel-exec, camel-nagios, camel-netty, camel-spring-spring-security, camel-crypto, …).

Le projet Camel devrait à coup sûr continuer à faire parler de lui dans les prochains mois, tout en s’imposant un peu plus comme un acteur majeur dans le milieu des frameworks d’intégration.

Intégration de Grails avec Google App Engine

Intégration de Grails avec Google App Engine

En navigant sur le blog « Le Touilleur Express« , je suis tombé sur un article passionnant décrivant l’intégration de Grails avec Google App Engine. Bien que l’article ait quelques mois, il n’en reste pas moins intéressant, et permet de se faire une bonne idée de la chose.

Une vidéo issue des « Google IO 2009 » présente Groovy, Grails, ainsi que son intégration avec le Googles App Engine. La vidéo parle d’elle même. Si vous connaissez déjà Groovy, vous pouvez sauter le premier tiers de la vidéo pour se focaliser sur l’intégration avec GAE.

Le lien vers l’article de Grails + Google App Engine:

Une introduction à Grails:

Un tutorial en trois parties basée sur une démo originale de Wicket:

Liens:

Si vous avez déjà créer une application basée sur Grails et tournant sur Google App Engine, n’hésitez pas à en faire part dans les commentaires.

Sortie de la librairie Logging4ME – v1.0.2

Sortie de la librairie Logging4ME – v1.0.2

Logging4ME sort en version 1.0.2 et propose maintenant de paramétrer le système de log grâce à un fichier de configuration XML et l’usage de Kxml.

Voici ci-dessous un exemple de fichier de configuration :

< ?xml version="1.0" encoding="UTF-8" ?>

<logging4me xmlns="http://logging4me.helyx.org/logging4me-1.0.0.xsd" thresholdLevel="DEBUG" debugMode="false">

	<!-- Layouts -->
	<layout name="pl" class="org.helyx.logging4me.layout.pattern.PatternLayout">
		<property name="pattern" value="|%T|%L|%C|%D{yyyy/MM/dd, HH:mm:ss.ZZ}| " />
	</layout>
	
	<!-- Appenders -->
	<appender name="console" class="org.helyx.logging4me.appender.ConsoleAppender">
		<property name="thresholdLevel" value="INFO" />
		<property name="layout" value="pl" />
	</appender>

	<!-- Categories -->
	<category name="org.helyx.logging4me" level="DEBUG" />
	
</logging4me>

Ainsi qu’un fichier d’exemple de chargement de la configuration XML avec J2ME:

		LoggerConfigurer loggerConfigurer = new XmlConfigurer("/org/helyx/logging4me/test/logging4me.xml");
		loggerConfigurer.configure();

Liens utiles du projet:

  • Le site du projet est à l’adresse suivante: http://basics4me.helyx.org/ .

    Vous y trouverez toutes les informations liées au développement du projet: Sources, Javadoc, Couverture de test, métriques, rapports Maven, …

  • Un wiki est disponible ici. Il propose des informations complémentaires: Exemples, Intégration de la librairie à votre projet, …
  • Pour télécharger le projet, cela se passe à l’adresse suivante: http://wiki.helyx.org/doku.php?id=basics4me:downloads
  • Un BugTracker est disponible à l’adresse suivante pour remonter toute anomalies ou suggestions : http://issues.helyx.org
  • Le projet est inscrit sur ohloh à l’adresse suivante: http://www.ohloh.net/p/Basics4ME.

Si vous souhaitez utiliser cette librairie pour votre développement, n’hésitez à me faire part de vos retours par mail, via le bugtracker, ou bien les commentaires du blog.

Sortie de la librairie J2ME Logging4ME

Sortie de la librairie J2ME Logging4ME

Je travaille depuis un certain temps sur différents projets J2ME, et certains d’entre eux arrivent aujourd’hui à maturité. Le temps est donc venu de les releaser et de proposer une première version publique.

La sortie de la librairie Java pour J2ME Basic4ME a déjà fait l’objet d’un post il y a quelques jours.

Aujourd’hui, c’est au tour du projet Java pour J2ME « Logging4ME » d’être présenté et releasé:

Logging4ME est une librairie de logging spécialement adaptée pour J2ME, distribuée sous license Apache, et sa première version publique est la 1.0.1.

La librairie a été pensée dès le début des développements pour être spécialement adaptée aux problématiques J2ME. Elle est donc parfaitement compatible avec l’environnement J2ME/MIDP, et propose de nombreuses fonctionnalités classiques des librairies de log:

  • Une API de log classique et simple utiliser
  • Support de tous les niveaux de logs
  • Gestion des catégories de logger par hiérarchie ou bien par mot clé
  • Gestion de l’additivité pour la gestion des catégorie de loggers par hiérarchie
  • Configuration des layout, dont l’implémentation « PatternLayout », permettant de configurer finement l’affichage des logs
  • Support des Appenders, dont le « ConsoleAppender », et le « FileAppender »
  • Possiblité d’étendre les fonctionnalités de la librairie (Custom Layout, custom Appender)

Il existe déjà différentes implémentations de gestion des log adaptées pour J2ME. Microlog fait aujourd’hui référence pour l’éco-système J2ME, cependant il faut bien trouver chaussure à son pieds. Logging4ME propose donc une implémentation nouvelle, simple et légère de gestion des logs.

Listing des projets de gestion des logs pour J2ME:

  • Microlog
  • log4me – Note: Le projet semble abandonné (Pas mis à jour depuis Août 2006)
  • Jadabs-Log4j-J2ME – Note: Le projet semble abandonné (Pas mis à jour depuis Nomvembre 2004)
  • Et bien sûr: Logging4ME

Liens utiles du projet:

  • Le site du projet est à l’adresse suivante: http://logging4me.helyx.org/ .
    Vous y trouverez toutes les informations liées au développement du projet: Sources, Javadoc, Couverture de test, métriques, rapports Maven, …
  • Un wiki est disponible ici. Il propose des informations complémentaires: Exemples, Intégration de la librairie à votre projet, …
  • Pour télécharger le projet, cela se passe à l’adresse suivante: http://wiki.helyx.org/doku.php?id=logging4me:downloads
  • Un BugTracker est disponible à l’adresse suivante pour remonter toute anomalies ou suggestions : http://issues.helyx.org
  • Le projet est inscrit sur ohloh à l’adresse suivante: http://www.ohloh.net/p/Logging4ME.
  • Si vous souhaitez utiliser cette librairie pour votre développement, n’hésitez à me faire part de vos retours par mail, via le bugtracker, ou bien les commentaires du blog.

Sortie de la librairie J2ME Basics4ME

Sortie de la librairie J2ME Basics4ME

Basics4ME est une librairie J2ME qui propose de fournir différentes fonctionnalités à ce jour manquantes dans les différentes versions de MIDP.

La version 1.0.5 correspond à la première release publique de cette librairie. Le projet est distribué sous licence Apache. La librairie tire certaines fonctionnalités directement du projet Apache Harmony, ce qui est un gage de la qualité du code fourni dans cette librairie.

Ce projet est né du besoin de regrouper au cours du développement d’un projet annexe de certaines fonctionnalités vraiment basiques manquantes dans les librairies de base J2ME/MIDP. Basics4ME n’a pas de dépendances vers d’autres librairies, les classes proposées sont donc utilisables sans difficultés.

Vous trouverez dans la librairies Basics4ME entre autre un support adapté pour J2ME des classes suivantes: :

  • ‘java.util.Properties’, permet l’accès à des fichiers de propriétés, très utile pour le support de préférences ou de l’I18N
  • ‘java.io.BufferedInputStream’, permet la lecture par buffer pour la lecture optimale de contenu
  • ‘java.io.BufferedReader’, permet la lecture par ligne d’un contenu texte

Les classes Properties et BufferedReader sont des classes nécessaires dans un très grand nombre de projets. Basics4ME fournit donc un support pour J2ME/MIDP.

J2ME imposant certaines limitations, vous ne retrouverez pas ces classes dans le pacakge java.*, mais dans le package de base du projet: org.helyx.basics4me.* . Les fonctionnalités y sont classées par packaging.

Liens utiles du projet:

  • Le site du projet est à l’adresse suivante: http://basics4me.helyx.org/ .
    Vous y trouverez toutes les informations liées au développement du projet: Sources, Javadoc, Couverture de test, métriques, rapports Maven, …
  • Un wiki est disponible ici. Il propose des informations complémentaires: Exemples, Intégration de la librairie à votre projet, …
  • Pour télécharger le projet, cela se passe à l’adresse suivante: http://wiki.helyx.org/doku.php?id=basics4me:downloads
  • Un BugTracker est disponible à l’adresse suivante pour remonter toute anomalies ou suggestions : http://issues.helyx.org
  • Le projet est inscrit sur ohloh à l’adresse suivante: http://www.ohloh.net/p/Basics4ME.

Si vous souhaitez utiliser cette librairie pour votre développement, n’hésitez à me faire part de vos retours par mail, via le bugtracker, ou bien les commentaires du blog.

Seam 2 est enfin sorti!

Seam 2 est enfin sorti!

Non, je ne recommencerai pas avec un jeu de mot pourri sur les Sims, d’ailleurs, je me suis promis de me flageller si j’écrivais encore un jeu de mots aussi « null » (oula, celui là, mérite au moins des coups de fouet) digne des grosses têtes.

Il y a plus important que les jeux de mots, puisque le framework qui se veut résoudre tous les problèmes du développement web en Java vient de sortir en version 2. Et il faut dire que les choses ne sont pas pas faites à moitié, puisque Seam 2 propose entre autre, eh oui, tout arrive une intégration totale avec maven (au diable les générateur type RoR .. Gem et compagnie, vive le Java!), un support du scripting, une intégration totale avec Eclipse et le JBossIDE 2.0, un support complet des Web Services, et j’en passe! Quelle bête de travail ce Gavin! Faut dire qu’il ne chôme pas depuis Hibernate! A croire qu’ils marchent au fouet chez RedHat! … ou bien au RedBull :D

Vous trouverez bien sûr toutes les informations complémentaires sur le site de JBoss à l’adresse suivante:

A noter que JBoss est sorti en version 4.2.2.

Un site très intéressant à visiter:

Il fonctionne avec Seam 2 et présente, on dira l’entourage professionnel proche de Gavin King et leurs projets (Que des pointures).

Atomikos – Le gestionnaire de transaction JTA qu’il vous faut!

Atomikos – Le gestionnaire de transaction JTA qu’il vous faut!

En Java, il est possible de développer des applications faisant appel à des standards J2EE … ou non, d’utiliser l’ensemble des ressources mise à disposition par des serveurs d’applications J2EE… ou non, d’exploiter les technologies EJB … ou non. Cependant, Sun a toujours poussé à utiliser les serveurs d’applications J2EE pour déployer les applications d’entreprises pour en exploiter toutes les technologies proposées par SUN.

Bref, on a le choix de développer des applications qui exploitent les technos J2EE un peu comme on l’entend, mais si on les déploie pas dans un serveur d’applications, on ne pourra pas tirer partie de toutes les ressources offertes par ces derniers. Cela pour procurer un certain nombre d’avantages (Test hors conteneur possibles et simples à mettre en oeuvre), mais on aura plus de mal à assembler toutes les pièces du puzzle.

Par exemple, si vous ne voulez pas développer d’EJB, vous pouvez toujours utiliser des services Pojo Spring. De même si vous ne voulez pas gérer la persistence avec les EJB, vous pouvez toujours en la gérer avec Hibernate ou bien JPA.

De même qu’on peut exploiter des ressources J2EE lorsqu’on déploie une application dans un serveur J2EE, on peut le faire également hors conteneur, mais ceci devient très vite compliqué. Ces possibilités qui n’étaient pas envisageables il y a encore peu de temps, sont encore difficiles à mettre en oeuvre à cause du manque d’exemples et de documentations.

Même s’il est simple d’utiliser des technos telles que des Pools de Threads et de Connections, des MQ ou des DataSources, de gérer des transactions, il est en revanche plus difficile par exemple de gérer des applications clusterisées ou bien de mettre en oeuvres des transactions gérant plusieurs ressources sans serveurs d’applications. Les gestionnaires de transactions JTA permettre de répondre besoin de gérer des transactions gérant plusieurs ressources. Cependant, on les trouve en général uniquement dans des serveurs d’applications, donc même si on construit une applications autour de technos non dépendantes des serveurs d’applications, il faut quand même les déployer dans des serveurs d’applications J2EE, si on veut on veut profiter de transactions 2PC (Two Phase Commit). Nous voila revenu au point de départ: Comment se passer complètement d’un serveur d’applications pour gérer des transactions 2PC?

Les gestionnaires de transactions JTA fournissant une implémentation indépendante sont les suivants:

  • Bitronix
  • Atomikos
  • JOTM
  • JBoss Transactions
  • Jencks (Via les librairies de Géronimo)
  • Le Gestionnaire de trnasaction de Géronimo

Cependant, après vérification :

  • JOTM semblerait à l’abandon, et
  • Jencks, bien qu’intéressant, semble difficile à mettre en oeuvre (De ma propre expérience, peu de matériel et d’explications sont fournies au final pour supporter différentes ressources), ActiveMQ est cependant bien supporté. Personnellement, je n’ai as réussi à mettre en oeuvre des transactions 2PC avec Oracle et ActiveMQ.
  • JBoss Transaction et le Gestionnaire de trnasaction de Géronimo

Pour ma part, je n’ai pas testé Bitronix, et je ne peux donc pas donner d’avis, mais il semblerait qu’Atomikos soit une très bonne solution pour les raisons suivantes:

  • Il supporte un grand nombre de ressources XA (JMS, JDBC, JCA, JMX)
    • Jms: ActiveMQ, OracleAQ, SonicMQ, …
    • JDBC: Tout driver et Bases de donnée XA « compliant »: Oracle par exemple, ainsi qu’un certain nombre de driver ou Base de données pas complétement « Compliant » (MySQL par exemple).
  • Le projet est mature (6 ans d’existance)
  • Le projet est Open-Source, mais propose un support professionnel
  • Il existe un support communautaire plus développé via un forum de support mis en place par la société qui le développe.
  • Une document très fournie sur JTA et les API atomikos
  • Atomikos peut être mis en oeuvre facilement via Spring.
  • Atomikos propose des consommateurs de messages bien plus intéressants que ceux proposés par défaut dans spring. En effet, la classe ‘DefaultMesssageListenerContainer’ poll les ressources JMS (Génération très lourde de traffic – Connections, session, consumer transaction – pour simuler la réception de message. C’est un peu comme si on disait que du pop par intermittance de 10 secondes était du Push Mail pour imager), alors que la classe QueueServerSessionPool attend que le serveur push les messages JMS, ce qui est le pattern de fonctionnement par défaut de JMS pour écouter l’arrivée de messages asynchrones)

Grâce à Atomikos et Spring, il devient possible de déployer simplement une application J2EE hors conteneur tout en gérant des ressources XA telles qu’une base Oracle via un gestionnaire ORM par exemple ou bien un broker JMS tout en gérant ces ressources via des transactions 2PC.

On pourrait facilement imaginer une application Web déployer dans un conteneur Web (Tomcat par exemple) qui contiendrait les technos suivantes:

  • Spring 2 pour l’injection de Dépendence et la glue techniques de l’application
  • Atomikos pour gérer les transaction 2PC (JTA/XA)
  • JPA utilisant des ressource JDBC XA « Compliant » (Oracle, SQLServer, Informix, FirstSQL Enterprise) ou non mais supportés (MySQL / HyperSonic)
  • Un Broker JMS XA « Compliant » (SonicMQ, MQSeries, ActiveMQ, Oracle AQ)
  • Un FrameWork Web quelconque: Struts 1.x/2.x, …
  • D’autres Technos fournies par Spring par exemple: WebService via XFire…

Voici de quoi se mettre un peu de lecture sous la dent:

Le site du projet:

Le forum de support du projet:

Un article sur le site OnJava proposant une introduction sur JTA/XA et Spring:

Intégration entre Seam et Maven

Intégration entre Seam et Maven

Suivant de plus ou moins près l’évolution des Frameworks Web Java, je me suis intéressé à l’évolution de Seam (Jboss – Gavin King) . L’utilisation de Maven étant devenu pour moi un Best Practice, je me suis demandé comment me passer des outils de bases fournis par le framework Seam pour la création de projets et l’intégration dans les IDE.

Je me suis mis à chercher un support pour Maven et je suis tombé sur 2 sites suivants:

Ces 2 sites tentent de fournir tout le matériel nécessaire à l’utilisation de Seam et de Maven:

  • Création de projets pour Seam
  • Intégration avec les IDE

Le rachat de JBoss par Red Hat, vise à fournir une stack complète de développement et de production J2EE, via l’utilisation de l’ensemble des outils JBoss. Récemment, JBoss a ainsi passé un accord avec la société Exadel pour mettre en open-source les plugins développés pour Eclipse, à savoir, tous le nécessaire pour développer des applications JSF et Seam, plus d’autres outils (entre autre les RicheFaces). L’intégration de ces outils aux JBoss Tools (ensemble de plugins fournis par JBoss pour l’IDE Eclipse, visant à aider aux développements d’applications pour JBossAS, et les autres projets JBOSS) est en cours, et l’ensemble des plugins seront bientôt mis à disposition. Cependant vous ne trouverez pas de distribution Eclipse fournie par Jboss avec tous ces outils intégrés directement, pour cela il faudra aller vous du côté de Red Hat Developer Studio (RDHS).

Liens intéressants:

Livres sur le frmaework Seam: