Les solutions permettant de modéliser, stocker et parcourir de façon efficiente des graphes ont profité de plusieurs éléments qui les ont rendues populaires ces dernières années.

Le premier élément aidant à leur démocratisation est l’explosion des réseaux sociaux. Un cas d’usage évident, facile à comprendre même  si, étrangement, les solutions mises en œuvre ne sont pas forcément de « type graphe » (par exemple avec FlockDB chez Twitter).

Le second est lié au mouvement NoSQL qui a aidé à diffuser l’idée que la base relationnelle n’est pas la seule solution de stockage et de requêtage.

Enfin, et même si la théorie des graphes n’est pas neuve, les algorithmes sous-jacents et certaines implémentations ont atteint un niveau de maturité permettant la « commoditisation » de ces technologies, les aidant du même coup à sortir de zones très spécifiques.

Alors qu’est-ce qu’un graphe? A quoi cela peut-il bien servir? Et finalement comment travaille-t-on avec  en termes d’API et  de solution ?

A travers deux exemples simples, voici une introduction aux graphes, leur stockage et leur analyse, en utilisant Neo4j, une base de données graphe, et Gephi, un outil open-source de visualisation et d’analyse de graphe.

(Lire la suite…)

Le framework CXF est aujourd’hui probablement le meilleur framework pour implémenter des web services selon la spécification JAX-WS en Java. Ayant réalisé un projet d’envergure autour de CXF, cet article n’a pas pour but d’être une initiation à ce framework car les tutoriaux de base de la documentation sont très bien faits ( http://cxf.apache.org/docs/index.html). Nous allons plutôt, dans une série d’articles, tenter de vous présenter quelques « tips avancés » sur CXF.

Une grande qualité de CXF est d’être un framework très modulaire de par sa conception autour d’un bus et d’une chaîne d’intercepteurs.

Lorsqu’on met en place un ensemble de WebServices, on peut être amené à effectuer un traitement commun à tous ces web services. Par exemple, rattraper les exceptions et maîtriser la soap:foault qui sera renvoyée au client. Ce type de traitement peut être réalisé de diverses façons, mais une bonne pratique est d’utiliser des intercepteurs.

La documentation officielle explique très bien les bases de la mise en place d’intercepteurs.
CXF découpe en phases le cycle de vie d’un message depuis son arrivée en passant par son traitement jusqu’à la réponse à celui-ci. C’est sur ces phases que l’on « branche » les intercepteurs afin qu’ils puissent traiter un message en fonction de son étape de cycle de vie.
On peut aussi spécifier explicitement que l’on branche un intercepteur avant ou après un autre intercepteur sur la même phase.

(Lire la suite…)

Nous avons eu récemment en interne un retour aux sources autour de la POO, et des principes SOLID. Celui-ci a donné lieu à compte rendu, dont la dernière phrase fut le point de départ d’une longue file de message que je vais tenter de résumer ici. Et pour les amoureux de la lecture,  vous trouverez la copie intégrale à la fin de cet article.

La phrase en question : Il faut éviter de réaliser du SurDesign : Pourquoi mettre une interface lorsqu’il n’y a qu’une seule implémentation, pourquoi factoriser du code s’il n’est utilisé qu’à un seul endroit ?

(Lire la suite…)

Avec l’expansion des services en lignes via le cloud ou tout simplement l’interconnexion des SI, le besoin d’exposer des services vers l’extérieur est croissant. Les WebServices sont une solution maintenant éprouvée depuis longtemps pour répondre à ce besoin.

Que l’on utilise SOAP ou REST un problème se pose toujours : comment faire pour sécuriser l’accès à mon SI alors que j’en ouvre une porte en exposant mon métier ?
Souvent utilisés au sein même d’un SI pour gérer des problématiques d’intégration ou d’hétérogénéité des technologies, les Web Services sont aussi de plus en plus souvent exposés sur le web ou à des partenaires.

Lorsque c’est possible, on voit souvent la mise en place d’un canal sécurisé type VPN entre les différents acteurs. Toutefois cela n’est pas toujours possible et cet article a pour but de vous présenter des notions de base liées à la sécurité des web services.

Ayant réalisé des missions, pour OCTO, aussi bien d’architecture que de développement autour ce sujet je vais tenter, via une série d’articles, de vous initier à ce domaine.
La majorité des WebServices de nos clients étant en SOAP je me concentrerais beaucoup plus sur ces derniers.
Cet article se voulant une initiation je ne suis pas rentré dans des détails très techniques, il a uniquement pour but d’attirer l’attention sur la vulnérabilité des protocoles de Web Services.

(Lire la suite…)

Dans la première partie nous avons vu comment avec JEE 6 nous pouvions représenter nos données et écrire des services (via EJB) permettant de les exploiter.
Nous allons maintenant voir comment les exposer d’abord via un WebService REST puis via JSF 2.

Exposition des données : REST

On connaissait déjà l’exposition simplifiée de services REST en JEE5. La spécification JAX-RS 1.1 apporte toutefois quelques nouveautés fort appréciables.
L’écriture du WebService n’a en soit pas vraiment changée, exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Path(value = "/formationsrest")
public class FormationsRestService {
 
 
	@EJB
	FormationManager formationManager;
 
	@GET
	@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
	public List<formation> getFormations() {
		return formationManager.getAllFormations();
	}
 
}
</formation>

La nouveauté intéressante réside dans le code de la méthode getFormations(). Si vous reprenez le code de FormationManager de la partie 1, elle ne fait que retourner une liste d’entités JPA, pourtant on précise bien ici que notre méthode produit du XML ou du JSON. Et si on appel ce service avec l’url choisie, on verras bien du XML ou du JSON sortir.

En fait il suffit de rajouter une annotation sur notre entité JPA : @XmlRootElement

(Lire la suite…)

Java Enterprise Edition 6 est sortie depuis quelques temps déjà. Cette plateforme a été évoquée dans de nombreuses conférences à Devoxx 2010 et un certain nombre de livres traitent déjà du sujet. Les retours sont à peu près tous les mêmes : Java EE devient enfin plus léger et productif !
Les serveurs d’applications, en particuliers Glassfish et JBoss, implémentent maintenant nativement les spécifications de JEE6 et la blogosphère a déjà bien décortiqué chacune d’entres elles. De plus une partie des nouveautés provient de frameworks JEE déjà éprouvées tels que JBoss Seam. Bref démarrer un projet avec JEE 6 semble aujourd’hui tout à fait viable voir attrayant.

Néanmoins même si on peut admirer les nouvelles possibilités de la plateforme, un certain nombre de questions peuvent se poser aux personnes responsables de projets basés sur Java.
On peut se demander ou est l’intérêt pour un projet de migrer ou de démarrer sur cette nouvelle version, sous entendu :

• Qu’est ce que ça va m’apporter par rapport à un JEE5 déjà bien éprouvé et testé sur des projets d’envergures ?
• Quel sera le coût de migration pour mon projet existant, ou quel sera le coût d’apprentissage de cette plateforme par rapport à d’autres ?

J’ai donc voulu répondre par moi même à ces questions et me suis lancé dans le développement d’un PoC pour tester les fonctionnalités principales de ce nouvel environnement.
Comme presque tous les articles et livres traitant de JEE 6 se basent sur Glassfish 3 et que j’ai vu plus de JBoss chez les clients d’OCTO, j’ai choisi ce dernier pour mes tests. Tous les exemples tournent sans donc sans problèmes sur JBoss AS 6.

Une des grosses difficultés rencontrées avec JEE 5 était la testabilité et plus concrètement les tests d’intégration qui nécessitaient toujours plus ou moins de déployer un conteneur lourd ralentissant fortement l’exécution des tests. L’article s’agrémente donc d’un certain nombre d’exemples de tests JUnit (présentant surtout la façon de procéder) pour vous faciliter l’écriture des vôtres.

Le contexte

Notre application aura pour rôle de gérer des formations. Nous aurons donc deux types de données : Formation et Participant.
Bien que l’application soit amenée à évoluer l’article se limitera à ce contexte simplifié pour faciliter la lecture de l’article.

(Lire la suite…)

En auditant des applications pour des clients d’OCTO, je me suis aperçu que la gestion des exceptions est un élément qui fait souvent défaut au même titre que la gestion des transactions.
Ce billet était à l’origine des notes personnelles qui avaient pour but de me servir de piqure de rappel et je me suis dit qu’un article de blog serait peut être utile à tous.
Ce sujet prête souvent à discussions et il faut parfois adapter au cas par cas, néanmoins avoir un cadre de bonnes pratiques peut s’avérer très utile.

Tout d’abord, voici un schéma présentant la hiérarchie (Lire la suite…)