Les grandes tendances de Devoxx 2011

La plus grand conférence de la communauté Java avec JavaOne a eu lieu à Anvers en Belgique au mois de Novembre. Cette année, les thèmes principaux de Devoxx étaient (sans ordre particulier):

  • Le futur de Java
  • Les langages alternatifs sur la JVM
  • HTML5
  • JavaFX
  • Android
  • Un peu de Cloud, de NoSQL et d’architecture haute performance

Nous avons aussi eu droit à une grande annonce pour une nouvelle conférence qui démarre en 2012 : Devoxx France!

Bien sûr, OCTO était sur place. Dans cet article, nous ne couvrirons pas toute la conférence en détail, de nombreux blogs l’ont déjà très bien fait. Nous allons néanmoins vous résumer les grandes tendances de cette édition et vous donner nos impressions à froid.

La suite de cet article en anglais, international oblige! Lire la suite…

Les systèmes mutualisés : démarrer et ne pas se perdre

Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

  • Les systèmes mutualisés : enjeux et risques
  • Les systèmes mutualisés : comment réaliser une gouvernance efficace
  • Les systèmes mutualisés : démarrer et ne pas se perdre

Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.

Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.

La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :

  • Définir le modèle de production et développement
  • Définir la frontière entre le cœur et le spécifique
  • Définir le niveau de mutualisation
  • Concevoir un produit adapté pour maitriser la part du spécifique
  • Assurer l’intégration dans des environnements divers
  • Adopter une démarche itérative et incrémentale

(Lire la suite…)

Utilisation avancée de CXF : les intercepteurs

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…)