Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :

• Ce qu’est un ESB et les besoins des systèmes en terme d’intégration.
• Les plates-formes de cloud computing et leurs différents modèles.

Les ESB

Les tentatives pour couvrir la définition et l’utilisation des ESB ont fait couler beaucoup d’encre. Revenir brièvement sur le sujet s’avère donc un exercice très difficile. Néanmoins, on pourrait le synthétiser de la sorte (pour plus d’approfondissement, n’hésitez pas à consulter notre livre blanc sur le sujet) :

Un ESB est une plate-forme d’intégration basée sur des standards ouverts. Elle combine les fonctions d’échange de messages, de transformation, de routage et d’exposition de services, afin de permettre de relier efficacement et de coordonner les différentes composantes d’un système d’information étendu. À bien des égards, un ESB pourrait être un point de départ pour l’émergence d’une SOA orientée événement ou « Event-Driven SOA ».

Quelles motivations pourraient pousser une telle plate-forme à migrer vers les nuages ? Essayons de les appréhender en s’intéressant de plus près à ce nouvel environnement d’exécution.

Le cloud computing

Wikipedia définit le cloud computing, selon le livre blanc de notre cher SYNTEC, comme un concept se déclinant sous trois formes :

• IaaS : infrastructure as a Service. C’est le niveau le plus bas. Le fournisseur assure dans ce cas les infrastructures matérielles nécessaires à la demande et selon les besoins de scalabilité et de stockage de l’application. Le client doit prendre en charge tous les aspects OS, pile logicielle et configuration pour tirer profit de l’élasticité des infrastructures fournies. On pourra citer comme exemple Amazon EC2.
• PaaS : plate-forme as a Service, niveau intermédiaire. Le fournisseur met à disposition une pile logicielle spécifique à ses infrastructures matérielles. Il assure derrière la disponibilité de votre application en lui allouant dynamiquement les ressources nécessaires selon les variations de sa charge. Un des exemples les plus célèbres est Google App Engine
• SaaS : Software as a Service, niveau le plus haut du concept. Le client consomme le logiciel hébergé par la plate-forme sur une base de paiement par utilisation (pay per use). SalesForce a été un des pionniers de ce type de service.

Notons que le principe du « pay per use » s’applique aux différentes déclinaisons citées ci-dessus. Il représente un des avantages principaux du cloud computing. Il permet la rationalisation des coûts et l’élimination du gaspillage en exploitation, licences, …

Et comme il y a toujours un « Mais », celui du cloud computing a toujours été la sécurité des données et dans une moindre mesure le lock-in par rapport aux fournisseurs. Ce qui a donné naissance à une nouvelle variante, les clouds privés. Les entreprises désireuses de tirer profit du concept et ne voulant pas confier leurs données stratégiques à Amazon, Google et consorts, ont opté pour cette alternative. Elles gardent ainsi la main sur l’exploitation et la gouvernance de leurs infrastructures existantes tout en les mutualisant entre leurs différentes filiales.

Les premières applications à avoir été mises dans les nuages ont été les commodités telles que les solutions de stockage, les CRM, quelques modules d’ERP (par exemple l’offre Business ByDesign de SAP)…

Quels arguments pour les ESB dans les nuages ?

À la suite de ce bref tour d’horizon, deux arguments semblent se dégager en faveur d’un déploiement des ESB dans le cloud :

1. Les ESB, de par leur adoption de standards ouverts, pourraient être un jour considérés comme des commodités, ce qui en fait un bon candidat pour le cloud. Cependant, les tentatives de standardisation, telles que JBI, n’ont à ce jour pas rassemblé un nombre critique d’acteurs et l’offre actuelle du marché reste composée de solutions hétérogènes, adoptant des architectures différentes.
2. Un déploiement dans les nuages permettrait une intégration pervasive inter-SI, rendant les échanges entre les départements d’une même entreprise plus directs. Cela permet aussi de faciliter l’intégration des éventuelles nouvelles applications en mode SaaS avec le reste du parc applicatif.

Par ailleurs, porter son bus dans les nuages induira des défis différents selon si l’on choisit un cloud privé ou public. Dans le premier cas, ils seront plutôt du côté de l’exploitation traditionnellement orientée vers la gestion des bases de données, des serveurs d’applications et des serveurs web et il faudra donc se munir d’un framework approprié pour la gestion d’ESB dans son cloud privé tel que Stratos. Dans le deuxième cas, ils seront plus nombreux. On citera principalement, la sécurité, la gouvernance et l’ouverture des firewall afin de pouvoir communiquer avec une plate-forme publique externe.

Perspectives

Les ESB dans les nuages ne sont qu’à leur début et la pertinence de ce portage est loin encore de faire l’unanimité. Certaines parties affirment même que les ESB n’ont pas leur place dans le cloud. Le débat promet d’être intéressant et animé.

Références

• Le système d’information durable
• Entreprise service bus
• ESBs in the cloud: Tricky in the early going
• What’s Next for the ESB? End of the Line, or Cloud Broker
• RunMyProcess

Parmi ces nouveaux produits, iBeans est probablement le plus intriguant. Le principe même de ce framework: une solution d’intégration pour applications Web avec l’idée que les iBeans interviennent là où Mule ESB s’arrête.

Après une apparition discrète en phase beta, MuleSoft dévoile peu à peu des informations sur iBeans depuis deux mois. C’est dans ce contexte que Ross Mason a présenté iBeans à Devoxx 2009 à Anvers.

Qu’est-ce qu’un iBean ?

Un iBean est un composant similaire à ceux offerts par Spring ou EJB. Il se distingue par son rôle : il est uniquement dédié à une tâche d’intégration. Il sera ainsi responsable d’exposer une interface simple pour accéder à un service distant.

Ces tâches de développement sont habituellement effectuées à l’aide d’un ensemble d’APIs dans des composants généralistes. Le framework de MuleSoft se propose donc ici d’apporter un environnement spécifique à ce type de tâche.

Le rôle décrit ici semble au premier abord être celui d’un ESB. Les iBeans sont pourtant destinés à résider au sein d’une application Web. Ross Mason explique que lors du développement d’une telle application, il est souvent nécessaire de s’intégrer avec plusieurs services distants. Or, un ESB n’est pas toujours présent dans l’environnement de l’application pour la délester de ces tâches et lui fournir un service simple et facilement utilisable. Au-delà des services internes à l’entreprise, l’application peut aussi avoir besoin de consommer des services sur Internet tels que Twitter ou Amazon Web Services (AWS). Dans ces deux cas de figure, iBeans apporte une réponse en simplifiant l’intégration directement au niveau de l’application.

Le repository central

Un des buts principaux des iBeans est d’être réutilisable, éventuellement au-delà des frontières de l’entreprise. Par exemple, un iBean permettant d’accéder à Twitter pourrait probablement être réutilisé dans la plupart des applications ayant besoin d’utiliser ce service. C’est pour cette raison que MuleSoft a mis en place un repository central pour que les développeurs puissent partager les iBeans qu’ils créent.

Dans la pratique, il s’agit d’un repository Subversion sur lequel des iBeans peuvent être publiés. Les iBeans sont alors mis à disposition sous forme d’artefacts Maven.

Architecture

Les iBeans sont des composants ayant un cycle de vie distinct du conteneur applicatif (Spring, Guice, …) auquel ils s’intègrent. Ainsi, chaque injection d’iBean entraîne la création d’une nouvelle instance.

Ces composants sont développés à l’aide d’annotations qui permettent de s’intégrer à des channels. Chaque channel apporte le support d’un protocole particulier. Actuellement les channels disponibles sont : HTTP / REST, JMS, FTP, SMTP, POP3, JDBC et XMPP. D’autres types de channels arriveront à l’avenir, et il est bien sûr possible d’en développer soi-même.

La particularité est que le framework n’est pas destiné à être intégré dans le war de l’application Web, mais directement au sein de Tomcat. Ross Mason le justifie principalement par la mutualisation que cela permet.

Création des iBeans

Le framework iBeans propose au développeur un ensemble d’annotations pouvant être utilisées pour créer de nouveaux iBeans facilement. Un iBeans peut invoquer un service synchrone et recevoir ou envoyer un message asynchrone.

Invoquer un service

L’invocation d’un service distant est simple avec iBeans. L’exemple suivant montre comment invoquer l’API REST de Twitter :

public interface MyTwitterIBean {
    @Call(uri="http://twitter.com/statuses/show/{id}.json")
    String statusesShow(@UriParam("id") String id);
}

Il s’agit d’une simple interface avec une méthode. L’annotation @Call sera détectée par le framework qui trouvera le paramètre d’URL à utiliser grâce à l’annotation @UriParam.

Envoyer un message

Il est également possible d’envoyer un message asynchrone. L’exemple suivant montre comment programmer un envoi régulier de messages JMS :

public class JmsScheduleSendBean
{
    private AtomicInteger count = new AtomicInteger(1);
    @Schedule(interval = 1000)
    @Send(config = "jms-publish")
    public Object send()
    {
        return "New Message " + count.getAndIncrement();
    }
}

L’annotation @Send indique que l’objet retourné par la méthode doit être envoyé sur la queue JMS jms-publish. L’annotation @Schedule programme une invocation de la méthode toutes les secondes.

Recevoir un message

Enfin, il est possible de recevoir un message asynchrone. Toujours dans le cas de JMS, la réception de message s’effectue grâce à l’annotation @Receive :

public class JmsReceiveAndSendBean
{
    @Receive(config = "jms-receive")
    @Send(config = "jms-result")
    public String receive(String message)
    {
        return message + " Received";
    }
}

Dans cet exemple, les messages reçus sur la queue jms-receive entraineront l’invocation de la méthode receive() avec le contenu du message JMS en argument. Des transformers seront utilisés pour effectuer une éventuelle adaptation de type. Enfin, la chaîne de caractère retournée par la méthode sera ici renvoyée en tant que message sur la queue jms-result.

Transformers

Afin d’effectuer des conversions de type automatiques, il est possible de définir des transformers. Là aussi, c’est grâce à une annotation que cette définition va se faire. L’exemple suivant montre un transformer simple :

public class SimpleTransformer {
    @Transformer
    URL toUrl(String string) throws MalformedURLException {
        return new URL(string);
    }
}

Il n’est pas nécessaire d’inscrire cette classe auprès du framework, celui-ci se chargera de la découvrir grâce à son annotation et déduira les entrées et sorties de la transformation à l’aide des paramètres d’entrée et de sortie de la méthode.

L’utilisation du transformer se fera également automatiquement dans les iBeans lorsque le type reçu par un service et le type renvoyé par sa méthode correspondante ne sont pas compatibles.

Intégration aux frameworks applicatifs

iBeans peut s’intégrer aux conteneurs d’injections de dépendances courants tels que Spring et Guice. De par le choix architectural qui a été fait de le destiner uniquement à Tomcat, l’intégration à EJB n’est assez logiquement pas possible.

Une fois la configuration effectuée, les composants applicatifs peuvent se faire injecter un iBean à l’aide de l’annotation @IntegrationBean.

Intégration Javacript

Cette possibilité est originale pour un framework d’intégration mais n’est pas sans rappeler DWR et Seam Remoting. Il s’agit ici de pouvoir invoquer un iBean déployé sur un serveur depuis le navigateur, en Ajax, via un appel Javascript. L’exemple ci-dessous montre une telle invocation :

<script type="text/javascript">
    var ibeans = new IBeansClient();
    creds = ibeans.config.get("twitter.user", "twitter.pass");
    ibeans.twitter.setCredentials(creds[0], creds[1]);
    ibeans.twitter.getFriendTimeline(readTweets);
    funtion readTweets(tweets, error) {
        // do stuff
    }
</script>

Le futur pour iBeans

Les possibilités offertes par iBeans sont intéressantes, mais le projet n’en est qu’à ses débuts. Ross Mason annonce de nombreuses possibilités supplémentaires à venir :

• Intégration à GWT / GXT, Grail, Play framework, JSF, et Struts 2
• Support des Web Services avec JAX-WS et JAX-RS
• Configuration centralisée
• Mule ESB 3.0 sera capable d’embarquer iBeans ce qui permettra une capitalisation plus importante sur les composants développés
• iBeans s’intégrera avec Mule Data Integrator, la solution graphique de mapping de données sous Eclipse proposée par MuleSoft

Conclusion

Les tâches qu’iBeans permet de réaliser ne sont pas inédites : elles pouvaient déjà être effectuées au sein d’un ESB. Son positionnement de solution d’intégration pour application Web le différencie de ce type de produit, mais il va tout de même à la rencontre des lightweight ESB, tels que Spring Integration et Apache Camel, qui se développent depuis plusieurs années.
On pourra malgré tout trouver l’API proposée par iBeans plus agréable que celle de ces deux concurrents directs dans le cadre d’intégrations au sein d’applications Web. Mais c’est surtout la ré-utilisabilité des iBeans qui semble réussie : les interfaces annotées peuvent très facilement être encapsulées dans un artefact Maven, pour être ensuite importées en dépendance dans les applications intéressées, puis injectées dans les composants métiers, sans configuration additionnelle.

Le choix de MuleSoft d’intégrer iBeans directement à Tomcat peut surprendre. On s’attendrait plutôt à retrouver ce framework au sein du war de l’application. Ross Mason reste flou sur les raisons de ce choix. Si des raisons techniques peuvent le justifier, on peut surtout imaginer des raisons commerciales : l’éditeur distribue ainsi iBeans avec Tcat Server et dispose , avec Mule ESB, de deux produits très séduisants pour l’entreprise.

RIA

• GChart 2.5 pour GWT

SOA

• jBPM 4.0 est disponible
• Avez-vous besoin d’un ESB ?

Le coin de la technique

• Making Good Software, bonnes pratiques du développement logiciel

Evènements de notre communauté en France et à l’étranger

• Sun fait évoluer sa certification programmer

RIA

GChart 2.5 pour GWT

Afficher des résultats sous forme d’histogramme ou de camembert se résume pour bon nombre de projets Java à l’import de JFreeChart, la librairie de référence pour faire des diagrammes en Java (démo).

Pour les projets GWT, une autre API fait beaucoup parler d’elle en ce moment (entre autres sur Ajaxian et onGWT) et cette API est GChart 2.5. Son objectif est simple : réaliser rapidement de beaux graphiques.

Une démo nous montre les capacités de l’outil en termes de rapidité d’affichage. Le code source de chaque exemple est aussi disponible (source du graphique Estimated Future Oil Prices).

Pour la release note technique (plus de compatibilité GWT 1.4, navigateurs testés, objets et méthodes dépréciés, bugfix…), tout se trouve sur cette page. Il ne reste plus qu’à tester ! Les retours d’expériences sont bienvenus dans les commentaires.

SOA

jBPM 4.0 est disponible

Tom Baeyens annonce sur son blog la disponibilité de la version finale de jBPM 4.0 respectant ainsi le calendrier prévu.

jBPM n’avait pas connu d’évolution majeure depuis 2005, cette nouvelle version constitue donc un évènement majeur pour les utilisateurs de jBPM. Les nouveautés apportées sont importantes :

• Nouvelle version du plugin Eclipse (GPD) permettant la définition graphique de processus suivant la notation BPMN
• Introduction de JBoss PVM (Process Virtual Machine), un moteur de workflow générique utilisé par jBPM pour l’implémentation des différents langages de définition de processus qu’il propose (jPDL, BPEL et Pageflow)
• Refonte des schémas de base de données utilisés pour les rendre plus évolutifs
• Intégration native à Spring
• Amélioration des performances
• Simplification de l’installation

Cette nouvelle version est d’ores et déjà disponible sur le repository Maven de JBoss. Par ailleurs, l’ensemble des apports de jBPM 4 seront passés en revue lors du JBoss World 2009 en septembre prochain, ainsi qu’à Devoxx 09 en novembre.

Avez-vous besoin d’un ESB ?

Ross Mason, fondateur de MuleSource a publié sur son blog une liste de points à vérifier avant de mettre en place un ESB. L’article, au titre plutôt racoleur (To ESB or not to ESB), à fait du bruit sur Twitter. D’ailleurs, en aparté, pour avoir nous-mêmes fait circuler ce lien, nous avons été surpris d’avoir été répondu par un certain @shakesp.

Pour en revenir au cœur du sujet, les points qui nous semblent intéressants sont simples à retenir :

• Commencez à penser à un ESB pour intégrer 3 applications, à plusieurs ESB si vous en avez plus que 10
• Avez-vous absolument besoin de plusieurs protocoles de communications ?
• Avez-vous de réels besoins d’intégration ? Découpage, routing, agrégation de messages …

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

Une fois n’est pas coutume, nous vous proposons cette semaine la découverte d’un blog tout récemment ajouté dans nos RSS : Making Good Software. Ce blog établit des listes de bonnes (et mauvaises) pratiques du développement logiciel. Non pas que son contenu soit extraordinaire, puisque vous en connaissez probablement déjà les plus gros points, mais il a le mérite de les rappeler : toute ressemblance avec personnes existantes ou ayant existé ne suivant pas ces règles ne saurait être que fortuite

Dans un premier article, une liste des 5 erreurs non techniques les plus répandues chez les développeurs, dont nos 2 préférés qui vous feront probablement penser à quelqu’un de votre open-space:

• Ego surdimensionné :  » je suis le meilleur développeur au monde, et ça me permet d’avoir toujours raison  » (ou la fameuse conversation à sens unique)
• Manque de discipline :  » j’essaye de tout faire en même temps, mais je ne termine jamais rien  » (définition de done plus que douteuse)

Un autre article vous donne une liste de 10 points à suivre pour écrire du bon code :

• Factorisez votre code, pour simplifier la correction d’anomalies et le refactoring
• Ecrivez des méthodes les plus courtes possibles
• Travaillez le nom des vos objets, variables et méthodes, il s’agit de la meilleure des documentations
• Une seule responsabilité par classe,
• Travaillez l’organisation de votre code, par groupes physiques de fichiers et groupes logiques de fonctions
• Faites des tests unitaires, quand vous aurez fini, faites-en encore plus
• Refactorez le plus tôt et le plus souvent possible
• Auto-documentez votre code
• Privilégiez le code par interface
• Faites des revues de code régulières

Dans un autre article l’auteur décrit une matrice permettant de noter votre code en fonction de sa simplicité et de son extensibilité.

Et pour finir, histoire de ne pas commenter l’ensemble des billets du blog, les 7 étapes pour corriger un bug : de la recherche de l’erreur, à l’analyse des dommages collatéraux.

Evènements de notre communauté en France et à l’étranger

Sun fait évoluer sa certification programmer

Sun teste une nouvelle version de sa certification SCJP (Sun Certified Java Programmer). La grosse nouveauté de cette révision : l’examen contiendra dorénavant une partie programmation. Cette certification, que certains appellent ‘pensez comme un compilateur Java’ évolue donc pour adopter une approche plus pragmatique.

• Les demandes d’ New Sun Java Programmer Plus Certification, SCJP vs SJPPC

SOA

• Fuji, le futur d’OpenESB

Le coin de la technique

• Concevoir des APIs efficaces
• JavaFX : informations et controverses
• Sortie de Wicket 1.3.6
• @Inject standardisation de l’injection de dépendances
• Sortie de Tapestry 5.1
• Trucs et astuces Json – Restfull

Evènements de notre communauté en France et à l’étranger

• Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

• Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
• Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
• Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
• Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

• Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
• N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
• S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
• L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

• la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
• les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

• Release note
• Site Maven du projet

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

• Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
• Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
• Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
• Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
• Ajouter un cache : améliorer les performances et la scalabilité de votre système.
• Implémenter la sécurité : utiliser une authentification web.
• Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
• Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

Evènements de notre communauté en France et à l’étranger

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

Java Business Integration est une norme édictée dans la JSR-208 : basée sur une approche orientée composant, JBI définit la manière de router les messages entre composants. Elle définit les composants et leur rôle, les messages qui circulent dans le bus, les canaux de communication entre les composants ainsi que les patterns d’échange.

ServiceMix est une implémentation de la norme JBI.

Architecture de JBI

Le schéma ci-dessous présente l’architecture générale de JBI.

L’ensemble des éléments de ce schéma sera décrit dans la suite de cet article.

Notion de composants

Catégories de composants

JBI définit deux types de composants : Les Binding Components (BC) et les Service Engines (SE).

• Les Binding Components (BC)
  Les Binding Components permettent l’accès depuis l’extérieur au bus JBI. Ils peuvent à la fois exposer des services ou consommer des services disponibles sur des applications hors de l’ESB.
• Les Service Engines (SE)
  Les Services Engines exposent et consomment des services disponibles uniquement à l’intérieur du bus JBI. Ils ne peuvent accéder au monde extérieur.

Les rôles des composants JBI

Un composant JBI peut proposer des services suivant deux types de rôles :

• Rôle  » Provider  » :
       - Ce rôle est endossable par les Binding Components ou les Service Engines.
       - Un service de type provider fournit des services exposés en interne du bus JBI.
       - Exemples :
            - Un composant de transformation va offrir des services de transformations sur le bus JBI.
            - Un composant Web Service va permettre d’invoquer un Web Service extérieur à partir du bus JBI.
• Rôle  » Consumer  » :
       - Ce rôle n’est endossable que par les Binding Components.
       - Un service de type  » consumer  » écoute les messages provenant de l’extérieur et initie les échanges JBI à partir des messages qu’il reçoit.
       - Exemples :
            - Un composant va exposer un Web Service vers l’extérieur et envoyer chaque message qu’il reçoit dans le bus JBI.
            - Un composant va attendre des messages sur une file JMS et envoyer chaque message qu’il reçoit dans le bus JBI.

Un composant peut fournir à la fois des services consumer et provider.

Les composants : conteneurs de services

Les composants (BC & SE) une fois installés dans le bus JBI proposent des services. Les composants proposent différents services en fonction de leur technologie.

Exemple : Le composant de type SE servicemix-saxon offre des services de transformation XSL et XQuery, le composant de type BC permet d’exposer et d’invoquer des services externes au bus JBI, etc.

Ces services doivent être en quelque sorte configurés et instanciés pour s’exécuter. Les composants agissent ainsi comme des conteneurs pour des instances de service.

Les instances des services sont packagées sous la forme de Service Unit (SU). Ces services units sont ensuite déployés dans le bus JBI qui va installer chaque instance dans le composant (BC ou SE) fournissant le service.

Les services units doivent être packagés sous la forme de Service Assembly (SA) pour être « déployable ».

JBI définit un packaging standard (une archive Zip) et des descripteurs (fichier jbi.xml) pour l’installation et le déploiement des composants afin de permettre leur portabilité sur tous les ESB conformes à sa spécification, sans modification. Le package d’installation contient tout ce qui est nécessaire à l’installation d’un composant (librairies …).

Interaction entre les composants ServiceMix

Le Normalized Message Router (NMR)

JBI définit un concept de bus interne permettant la communication entre les composants : c’est le Normalized Message Router (NMR).

Les éléments qui composent ce NMR sont :

• NormalizedMessage : Cette interface de la spécification définit la structure standard d’un message. Ce format est utilisé pour représenter un message en entrée ou en sortie ainsi qu’un message d’erreur. Les messages transitent forcément sous la forme de message XML (implémentant l’interface javax.xml.transform.Source). Un message peut aussi contenir des propriétés et des attachements (binaires ou non).
• MessageExchange : Cette classe représente un appel transitant à l’intérieur du bus JBI. L’échange contient le message d’entrée, l’éventuel message de sortie ou d’erreur (sous la forme de NormalizedMessage) et véhicule aussi les informations de l’appel (ex : destinataire) et le statut (actif, fini, en erreur). Il existe plusieurs types de MessageExchange, chacun suivant un pattern d’échange défini dans JBI.
• DeliveryChannel (DC) : JBI fournit à chaque composant (BC ou SE) un channel d’échange avec le NMR. Les composants utilisent ce channel pour échanger des messages au travers du NMR.

L’implémentation des mécanismes de routage du NMR dépend de chaque solution d’implémentation de JBI. ServiceMix fournit une implémentation d’un NMR sous la forme de flow. Il existe trois types de flow dans ServiceMix : Le SedaFlow (défaut), le JMSFlow et la JCAFlow.

Le SedaFlow stocke les messages en mémoire, le JMSFlow utilise des queues JMS comme implémentation des DeliveryChannel et le JCAFlow se base sur un connecteur JCA pour stocker les messages.

Message Exchange Pattern (MEP)

JBI définit aussi des patterns d’échanges de message. Chaque composant supporte selon la technologie qu’il représente tout ou partie de ces patterns d’échanges.

Chaque MEP définit l’enchaînement, le sens et le nombre de messages échangés ainsi que l’évolution du statut de l’échange de manière précise.

Au travers du DeliveryChannel, les composants interagissent avec le NMR de deux façons :

• En acceptant des échanges (MessageExchange) : le composant reçoit un échange émis par un composant.
• En envoyant des échanges (MessageExchange) : le composant initie ou poursuit un échange après avoir traité les messages de l’échange.

Un Binding Component de type consumer initie un échange en créant une instance d’un objet MessageExchange et en le mettant à disposition des autres composants au travers du NMR. Un autre composant va accepter l’échange, effectuer un traitement puis envoyer l’échange (éventuellement mis à jour) vers le NMR, etc.

L’échange se termine quand l’un des composants positionne l’échange au statut ‘Done’ ou ‘Error’.

Les échanges entre les composants sont décrits au travers des patterns suivants. Il existe 4 MEPs différents basés sur les types d’invocations One-way et Request-Response. Ils permettent de moduler les types de communications entre les composants :

• In-Only (One-Way) : Le message est envoyé au destinataire. Aucun moyen n’est mis en œuvre pour s’assurer qu’il est bien arrivé ou non.
• Robust In-Only (One-Way) : Le message est envoyé au destinataire et un message (de type acknowledge) est retransmis à l’expéditeur en cas d’erreur.
• In-Out (Request-Response) : Un message nécessitant une réponse est envoyé au destinataire.
• In Optional-Out (Request-Response) : Un message est envoyé au destinataire et peut parfois nécessiter une réponse.

En exemple voici, un échange de type InOut décrit par des diagrammes de séquence UML, le premier finissant normalement, le second finissant en erreur.

Schéma d’un échange In Out se terminant normalement

 

Schéma d’un échange In Out se terminant en erreur

Cette présentation de JBI se termine ici, prochainement nous étudierons quelques exemples de mise en œuvre avec ServiceMix.

L’occasion d’une introduction à cette plate-forme de messaging.

Objectifs et principes

Spring Integration vise à simplifier le développement de solutions d’intégration d’entreprise et à faciliter l’adoption par les utilisateurs de Spring des principes EDA (Event Driven Architecture). Pour ce faire, les objectifs de Spring Integration sont :

• De fournir un modèle simple pour implémenter des solutions complexes d’intégration d’entreprise.
• De faciliter la mise en place de modèles d’échanges asynchrones orientés messages au sein d’une application basée sur Spring.

D’autre part, Spring Integration (comme toutes les briques du portfolio Spring) suit les principes suivants :

• Couplage lâche entre composants pour faciliter la modularité et la testabilité.
• Respect de la séparation des préoccupations (separation of concerns) entre la logique métier et la logique d’intégration.
• Points d’extension abstraits mais clairement définis afin de promouvoir la réutilisation et la portabilité.

Les composants

Le système de messaging proposé par Spring Integration suit le modèle « pipes-and-filters« . Dans ce modèle, les filtres (filters) représentent n’importe quel composant capable de produire et / ou de consommer des messages. Les tubes (pipes) sont quant à eux responsables du transport des messages entre les filtres. Dans ce modèle, les composants sont ainsi faiblement couplés entre eux.

Les messages

Le composant central de Spring Integration est bien évidemment le message. Un message est un wrapper générique qui emballe n’importe quel objet java et un ensemble de méta-données (utilisées par le framework pour prendre en charge cet objet).

Un message est donc constitué :

• D’un identifiant unique.
• D’un en-tête (header) qui regroupe ses méta-données : Time stamp, date d’expiration, identifiant de corrélation, adresse de retour, …, couples arbitraires de clés / valeur.
• De sa charge utile (payload) qui peut donc être n’importe quel objet java.

Les messages sont définis par l’interface Message<T>. L’implémentation par défaut est fournie par la classe GenericMessage<T>. Deux implémentations spécialisées sont proposées : StringMessage (message dont le payload est une String) et ErrorMessage (message dont le payload est un Throwable).

Les sources et les targets

L’interfaçage entre le système de messaging et le monde extérieur se fait par le biais de sources et de targets.

En entrée, l’interface Source<T> définit un modèle d’adaptateur pour la conversion d’Object en Message<T>. Ainsi, les implémentations de l’interface Source<T> permettent l’ingestion de messages dans le système.

Spring Integration propose un ensemble d’implémentations parmi lesquelles : ByteStreamSource, FileSource, JmsSource ou encore FtpSource …

En sortie, l’interface Target<T> définit un modèle d’adaptateur pour la conversion de Message<T> en Object. Ainsi, les implémentations de l’interface Target<T> permettent l’envoi de messages vers l’extérieur.

Spring Integration propose un ensemble d’implémentations parmi lesquelles : ByteStreamTarget, FileTarget, JmsTarget ou encore MailTarget …

Les Message Channels

Au sein du système de messaging, les messages transitent au travers de channels. Les channels représentent la partie « pipes » du modèle « pipes-and-filters« .

Les channels sont définis par l’interface MessageChannel. Ils peuvent (entre autres) être définis dans un fichier de configuration de contexte Spring. Par exemple :

<channel id="myChannel" />
<channel id="stringOrNumberChannel"
	datatype="java.lang.String,
			java.lang.Number"/>

Les Message Endpoints

La partie « filters » du modèle « pipes-and-filters » est quant à elle représentée par les endpoints.
Les endpoints sont le point d’accostage entre le code applicatif et l’infrastructure de messaging. Ils prennent en charge cette connexion de manière non invasive au travers d’une configuration déclarative. L’objectif est ici d’isoler le code applicatif de l’infrastructure qui le supporte (« separtion of concerns »).
On distingue trois types de endpoints:

Les endpoints sources
Un endpoint source est un adaptateur qui permet de connecter une source vers un channel. Il est responsable de la réception des messages en provenance d’une source et de leur transmission à un channel. La réception des messages depuis la source par le endpoint est contrôlée par scheduling.

Les endpoints targets
À l’inverse, un endpoint target est un adpatateur qui permet de connecter un channel vers une target. Il est responsable de la réception des messages depuis un channel et de leur envoi vers une target. De la même façon, la réception des messages en provenance du channel est contrôlée par scheduling.

Les Handler endpoints
Les handler endpoints permettent quant à eux les interactions de type request / reply. Ils jouent ainsi le rôle de « Service Activator ».

Les endpoints peuvent (entre autres) être définis par annotation. Par exemple :

@MessageEndpoint(input="inputChannel", output="outputChannel")
public class MyHandlerEndpoint {
    @Handler
    public String handle(Message<T> input) {
        // Invocation d'un service applicatif ...
        Message<T> output;
        // Construction du message de retour ...
        return output;
    }
}

Notons qu’il n’est pas obligatoire de travailler avec des Message<T> (cette façon de faire simplifie juste l’accès au header). Le endpoint précédant, pourrait également s’écrire :

@MessageEndpoint(input="inputChannel", output="outputChannel")
public class MyHandlerEndpoint {
    @Handler
    public String handle(Foo input) {
        // Invocation d'un service applicatif ...
        Foo output;
        // Construction du message de retour ...
        return output;
    }
}

Ici, l’extraction du payload du message (de type Foo) est prise en charge par Spring Integration.

Les Handlers

Alors que les sources et les targets proposent un modèle d’adapteur unidirectionnel, les handlers fournissent un modèle d’adapteur bi-directionnel, offrant ainsi la possibilité d’implémenter des scenarii de type request / reply.

Les handlers sont définis par l’interface MessageHandler. La prise en charge des messages se fait par invocation d’une méthode arbitraire sur un POJO.
Parmi les implémentations fournies par Spring Intégration, nous retiendrons :

Le Message Router Handler
Ce handler implémente l’ Integration Patterns Message Router. Il permet ainsi de router un message en provenance d’un channel d’entrée vers un ou plusieurs channels de sortie.

La méthode de handling peut être configurée (entre autres) par annotation de différentes façons :

// Route le message reçu vers le MessageChannel retourné.
@Router
public MessageChannel route(Message<T> message) {...}

// Route le message reçu vers l'ensemble des MessageChannel retournés (broadcast).
@Router
public List<MessageChannel> route(Message<T> message) {...}

// Route le message reçu vers le channel portant le nom retourné.
@Router
public String route(Foo payload) {...}

// Route le message reçu vers l'ensemble des channels dont les noms sont retournés (broadcast).
@Router
public List<String> route(Foo payload) {...}

Le Message Splitter Handler
Ce handler implémente l’ Integration Patterns Splitter. Il permet ainsi de découper le message reçu en plusieurs messages.

La méthode de handling peut être configurée (entre autres) par annotation de différentes façons :

// Reçoit un payload de type Order et le découpe en message dont le payload et de type OrderItem.
@Splitter(channel="output")
List<OrderItem> extractItems(Order order) {
	return order.getItems()
}

@Splitter(channel="output")
public List<Message<T>> split(Message<T> input) {...}

Les messages résultants se voient affecter un identifiant de corrélation (automatiquement ou explicitement) qui permettra de les agréger.

Le Message Aggregator Handler
Ce handler va de pair avec le Splitter. Il implémente l’ Integration Patterns Aggregator. Il permet ainsi de recomposer un message à partir de plusieurs messages.

La méthode de handling peut être configurée (entre autres) par annotation de différentes façons :

@Aggregator(defaultReplyChannel="output")
public Message<T> aggregate(Collection<Message<T>> input){
	...
}

La barrière d’agrégation se base sur une CompletionStrategy pour déterminer quand un groupe de message est complet pour agrégation. La stratégie par défaut se base sur un nombre de messages.

Le Message Bus

Les aspects runtime de Spring Integration sont assurés par le Message Bus.

Le Message Bus est une extension logique de l’Application Context Spring pour le domaine du messaging. Il joue le rôle de registre pour les Message Channels et les Message Endpoints.
Il prend notamment en charge :

• Le scheduling des différents pollers.
• La création des pools de threads.
• La gestion du cycle de vie de l’ensemble des composants du messaging.

Pour bien commencer

• Le site du projet Spring Integration.
• La documentation de référence.
• Les billets de Mark Fisher sur le blog de Spring Source.

Et rendez-vous prochainement sur notre blog pour un premier sample.

Le premier de ces pièges est le syndrome « Not Invented Here » (NIH). Ce syndrome se rencontre dans bien des domaines de l’IT. Dans le cadre de la mise en œuvre d’une architecture orientée services (SOA), il se manifeste tout particulièrement à deux niveaux :

• La réutilisation de services.
• La mise en place d’un tiers d’intermédiation.

La réutilisation de services

Un des objectifs sous-tendus par la mise en œuvre d’une SOA est la réutilisation de services.
Si le département A construit un service get_personal_details (qui retourne, entre autres, l’adresse complète), il y a peu d’arguments qui plaident en faveur de la construction par le département B d’un service get_address. Il existe pourtant plusieurs raisons qui peuvent amener le département B à construire ce service :

1. Les équipes du département B n’ont pas connaissance du service get_personal_details. Cela dénote généralement l’absence d’un annuaire / registre de services (ou sa mauvaise gestion). Nous discuterons ce point dans un autre billet de cette série.
2. La façon dont le département B conçoit son application ne la pousse pas à penser réutilisation. C’est en général ce qui arrive quand on applique un « Big Design Up Front » (une démarche de conception complètement Top down). Ce point sera également discuté en détail dans un autre billet de la série.
3. Les équipes du département B ont connaissance du service get_personal_details, mais elles décident de ne pas l’utiliser. Soit parce qu’elles ne savent pas précisément ce qu’il fait (on retombe alors dans le premier cas), soit parce qu’elles ne font pas confiance au département A quant à ses capacités à réaliser ce service correctement, soit, encore, parce qu’elles préfèrent avoir un contrôle total de l’implémentation de ce service.

La troisième raison est un cas typique du syndrome NIH. Il est alors urgent de réunir les deux départements autour d’une table afin qu’ils discutent de la responsabilité de ce service et qu’ils trouvent un terrain d’entente sur lequel chacun se trouve en confiance.
Ce genre de comportement est malheureusement assez courant. Mais, c’est quelque chose qui peut, en général être réglé au cas par cas une fois que le dialogue et la confiance ont été rétablis.

La mise en place d’un tiers d’intermédiation

Le deuxième cas de figure dans lequel on rencontre le syndrome NIH lors de la mise en œuvre d’une SOA est bien plus difficile à résoudre. C’est celui qui amène une direction informatique à construire son propre bus de service (ESB). Cela peut arriver principalement de deux manières :

1. Au début des années 2000, l’intégration applicative basée sur les messages a fait émerger le besoin d’un socle de services techniques réutilisables (transport, routage, transformation, …). Ce besoin a conduit, dans de nombreuses entreprises, à la construction de frameworks de messaging maisons, le plus souvent au dessus d’un backbone de messages comme MQ Series. Ces frameworks ont rendu de fiers services par le passé, mais de par leur nature, ils sont aujourd’hui très fortement couplés aux applications qu’ils supportent (ou l’inverse), entravant ainsi l’introduction des standards ESB dans l’infrastructure du SI.
2. Au-delà de ce phénomène, aujourd’hui encore, certains écrivent leur propre ESB. En effet, bon nombre d’architectes ont l’impression que les ESB sont un produit marketing fortement poussé par les éditeurs et les voient comme quelque chose d’inutile. Cette vision des choses est un peu exagérée, et il faut avoir de très bonnes raisons (et les épaules solides) pour écrire ces propres services de transport / routing / transformation. Ce qui revient à implémenter son propre ESB !

Dans les deux cas, sortir de cette situation implique beaucoup de travail. Ces systèmes propriétaires sont au cœur des systèmes, leur suppression demandera donc beaucoup de temps.
L’acquisition d’un ESB (commercial ou open source) implique la mise en œuvre d’un plan de migration dans lequel les services devront être migrés un à un pour utiliser cet ESB plutôt que l’ancien système. Un pont devra être donc maintenu entre l’ancien système et l’ESB pour la durée de la migration. De ce fait, il est probable que le débranchement de l’ancien système ne soit pas effectif avant longtemps …

Perspectives

Avant de commencer à écrire ses propres services ou son propre bus de message, il est donc souhaitable d’étudier ce dont on dispose. Il y a de grandes chances qu’un service ou une plateforme « temporaire » reste en activité très longtemps …

Actualité éditeurs / SSII

• Google App Engine, écrivez vos propres applications Google
• Polémique : Gartner Group nous révèle que Windows Vista s’écroule sous son propre poids

Le coin de la technique

• Polémique : Java est en train de perdre la bataille du web moderne
• Java EE Next Generations, les prédictions de Rod Johnson
• Sortie de Maven 2.0.9
• Camel 1.3 : les lightweight ESB progressent
• Netcraft Web Survey : Jetty progresse alors que Tomcat stagne
• IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !
• Java Web Frameworks Survey

Evènements de notre communauté en France et à l’étranger

• Kirk Pepperdine au Paris JUG

Actualité éditeurs / SSII

Google App Engine, écrivez vos propres applications Google

Google a annoncé la semaine passée la mise à disposition d’une plateforme d’hébergement pour applications Web, Google App Engine. La plateforme est pour l’instant en preview release, seuls 10 000 développeurs on pu s’enregistrer pour y accéder.

App Engine met à disposition des développeurs (pour l’instant gratuitement, mais le service sera bientôt payant) les outils utilisés par Google pour ses propres applications :

• Stockage de données avec BigTable et Google File System (GFS)
• Scalabilité et répartition de charge
• APIs Google, pour gérer l’authentification, envoyer des mails, et dialoguer avec le système de stockage de données
• Ainsi qu’un environnement de développement local

Les développements sont pour l’instant effectués en Python, mais d’autres langages devraient prochainement être supportés. Si vous souhaitez promouvoir votre langage favori, c’est par ici que ça se passe (la demande de support de Java est actuellement en tête devant celles de Ruby et PHP).

Depuis la mise à disposition de ses services Amazon Simple Storage Service (S3), Amazon Elastic Cloud (EC2 – nuage de serveurs), et SimpleDB (base de données), nous savions que ce n’était qu’une question de mois avant de voir la riposte de Google.
Mais les services de Google et Amazon ne sont pas en concurrence frontale. Là où Amazon met à disposition des briques logicielles, Google met à disposition un environnement complet. On pourrait imaginer une application utilisant l’App Engine de Google en façade d’un nuage (EC2) pour le traitement par batchs.
A quand la réponse de Microsoft?

Quelques articles qui nous ont paru intéressants sur le sujet

• ZDNet : Google announces App Engine: Should Amazon worry?
• BusinessWeek : Google App Engine Goes Up Against Amazon, But That’s Not the Point
• BioloGeek : Google App Engine – avantages et inconvénients

Polémique : Gartner Group nous révèle que Windows Vista s’écroule sous son propre poids

Gartner Group nous annonce dans Windows collapsing under its own weight; Radical change needed que Windows 7 sera radicalement différent de Vista, ce sera le premier système d’exploitation modulaire de Microsoft.

Scoop ? Pas vraiment, Gartner nous l’avait déjà annoncé en Février 2007 dans Is Vista the last monolithic release?. En revanche, la nouvelle annonce nous dévoile quelques détails sur Windows 7.

Le coin de la technique

Polémique : Java est en train de perdre la bataille du web moderne

TV4IT nous avait invité à participer à son débat Java est mort, vive Java ? (part 2, part 3).
The Server Side relance le débat cette semaine avec Java is losing the battle for the modern web …. Derrière ce titre bien trouvé de guerre moderne, comme d’habitude, Java se ferait sortir du monde des applications web par des architectures LAMP sur des moteurs en C ; même la JVM ne trouve pas grâce aux yeux des cassandres.

Rien de nouveau dans les polémiques millénaristes si ce n’est un avis pessimiste sur l’avenir du prochainement disponible JavaFX face au prometteur Microsoft Silverlight et à l’omniprésent Adobe Flex. Comment JavaFX arrivera-t-il à prendre des parts de marché aux solutions d’Adobe et de Microsoft ? Quelle promesse de valeur ajoutée convaincra les clients de changer de technologie ?

Java EE Next Generations, les prédictions de Rod Johnson

Rod Johnson nous livre dans The Biggest Loser’s Next Contestant: Java Bloatware sa vision des prochains serveurs d’applications Java.

C’est l’occasion de comprendre la ligne directrice du framework Spring et en particulier de Spring Dynamic Modules for OSGi(tm) Service Platforms, Spring Integration et Tomcat (récemment rapproché de Spring par le rachat de Covalent).

Nous passerons les habituelles piques contre les serveurs d’applications Java EE qualifiés cette fois de « morbidly obese legacy platforms ». Au delà de ces critiques lassantes, nous retiendrons :

• L’avenir de Java EE ne passera plus seulement par les spécifications du JCP mais aussi par celles d’organismes (cf OSGI, SCA, etc.)
• Les serveurs d’applications de demain seront modulaires et beaucoup plus compacts
• Les ESB et les serveurs d’applications vont converger
• Ces évolutions augurent un renouveau de la compétition sur la marché des serveurs d’applications
• Spring se positionne avec sa stack associée au serveur Tomcat dont on peut s’attendre une évolution rapide (OSGI-fication ?)

Sortie de Maven 2.0.9

La dernière version de Maven est disponible, voici les points les plus innovants :

• MNG-3395 : le super pom 2.0.9 contient désormais les versions par défaut pour les plugins de base de Maven. Cette fonctionnalité était grandement attendue, elle devrait résoudre les problèmes de stabilité rencontrés sur les projets qui ne fixent pas dans leur pom parent les versions des plugins, puisque dans ce cas les plugins étaient mis à jour automatiquement dès leur mise en ligne sur le repository. Le travail effectué par Don Brown avec sa branche maven-db a en partie payé!
• MNG-1412 et MNG-3111 : l’ordre des dépendances dans les fichiers classpath générés est désormais déterminé par l’ordre de déclaration dans le pom, les dépendances héritées étant ajoutées à la fin.
• MNG-3415 : une erreur lors du téléchargement d’un artefact ne devrait plus corrompre les métadonnées du repository local. On ne devrait plus avoir besoin de supprimer une partie du repository local dans ce cas.
• Un projet peut désormais importer les dépendances de plusieurs projets grâce au scope « import ». Sur un gros projet multi-modules c’était quasiment impossible, puisqu’un module ne peut hériter que d’un seul parent. Bien évidemment si on utilise cette fonctionnalité Maven 2.0.9 devient obligatoire pour builder le projet.

A noter que les 2 premiers points peuvent changer le comportement de votre build, attention aux risques de régression! La liste complète des corrections et améliorations est en ligne.

Camel 1.3 : les lightweight ESB progressent

James Strachan nous présente les nouveautés d’Apache Camel 1.3, le prédécesseur du toujours pas releasé Spring Integration dans le domaine des lightweight esb [1].
On remarquera l’amélioration de la testabilité, la meilleure intégration aux POJOs et le support de Microsoft Message Queuing (MSMQ) et d’AMQP.

Si cette release est une bonne nouvelle pour les utilisateurs des Enterprise Integration Patterns, elle est en revanche une source de confusion pour les utilisateurs d’Apache ServiceMix 3, le conteneur JBI également inclus dans la stack IONA FUSE, dont la valeur ajoutée par rapport à Camel est aujourd’hui difficile à trouver. La présentation du futur ServiceMix 4, qui intégrera OSGI, CXF et Camel, aidera les utilisateurs surpris à comprendre comment s’articulera la suite ActiveMQ-Camel-CXF-ServiceMix.

[1] cf. Xebia Blog : Spring Integration – L’avènement des ‘lightweight ESB’ ?

Netcraft Web Survey : Jetty progresse alors que Tomcat stagne

Alors que LightHttpd empiète poliment sur les plates-bandes de Apache Http Server avec seulement 2% des parts de marché de son aîné, le conteneur de Servlets open source Jetty rivalise sans complexe avec le très établi mais stagnant Apache Tomcat : le nombre de serveurs Jetty représente 80% de celui de serveurs Tomcat (cf webtide blog: Jetty has 80% of Tomcats public servers).

Comment Jetty a-t-il rattrapé Tomcat aussi vite ? Les innovations de Jetty sont certes intéressantes (OSGI, Ajax Comet Push, etc) mais il faut surtout voir l’attention que Jetty porte à sa communauté de développeurs en proposant un produit très léger et facile à intégrer alors que Tomcat s’est quelque peu endormi sur ses lauriers. Espérons que le récent rachat de Covalent par Spring Source redynamisera la communauté Tomcat.

Source : Webtide blog : Jetty Improves in Netcraft survey

IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !

Billy Newport nous annonce que la grille de données qu’il a supervisée, IBM ObjectGrid, s’appellera dorénavant Websphere eXtreme Scale

Simple détail de marketing ou signe de « Big Is Beautiful » chez IBM ? Hormis ses qualités qui font d’ObjectGrid une grille de données de tout premier plan [1], ObjectGrid se singularisait dans le portfolio Java d’IBM par une grande indépendance à la stack Websphere (les 6 petits Mo du client ObjectGrid s’exécutent indépendamment de Websphere, même sur une JVM Sun) et par un format de documentation très novateur avec un wiki Confluence plutôt qu’un classique Infocenter.

Billy Newport avait été visionnaire en prédisant dès juillet 2005 l’avènement du lightweight Java dans End of the Java Web Frameworks Survey road for invasive middleware?. Espérons que son message continuera à influencer Big Blue et qu’ObjectGrid ne disparaîtra pas dans l’imposante stack Websphere.

[1] cf. l’EntityManager à la JPA qui n’a pas d’égal pour manipuler les POJOs des la grille

Java Web Frameworks Survey

Peter Karich présente dans Java Web Frameworks Survey un comparatif des huit frameworks Web qui suivent :

• Click Framework
• Echo2
• GWT
• JSP
• Thinwire
• Wicket
• WingS
• ZK Framework

L’application était un simple bouton avec une zone de texte, dans laquelle on devait mettre un morceau de code permettant de dessiner un graphique. Pour le graphique, la librairie gnuplot a été utilisée.

Le comparatif nous permet de découvrir certains frameworks peu connus. Selon l’auteur, le framework Click présente des similarités avec Wicket et propose des aspects plus simples. Mettre en place sa première page avec Echo n’est pas très compliqué. En revanche GWT demande un certain coût d’entrée… (Nous avions partagé certaines de ces conclusions dans notre Web Framework Contest en Octobre dernier.

La conclusion de cette étude est que comme souvent chacun de ces frameworks a ses forces et ses faiblesses, et que si vous devez en choisir un il faut se poser les bonnes questions: un support est-t-il disponible ? Il y a t’il une communauté active? Quelles sont les possibilités d’intégration à une application existante ?

Evènements de notre communauté en France et à l’étranger

Kirk Pepperdine au Paris JUG

Kirk Pepperdine est venu présenter au Paris JUG les enjeux de performances en Java. En attendant que la présentation de Kirk soit disponible, les points essentiels :

• L’émergence des processeurs multi-coeurs révèle des problèmes de concurrence d’accès qui n’apparaissaient pas auparavant : une application peut s’exécuter moins vite sur un processeur multi-coeur à cause d’apparition de goulets d’étranglement (synchronisation, etc).
• Les APIs java.util.concurrent introduites avec Java 5 (en même temps que la clarification du modèle mémoire) simplifient le développement d’applications hautes performances.
• Les bases de données ne sont pas encore optimisées pour les architectures multi-coeurs et sont concurrencées frontalement par les grilles de données (Terracotta, Coherence, etc) qui elles exploitent les opportunités de parallélisme.
• Diagnostiquer un problème des performances d’une application Java nécessite d’étudier simultanément les quatre couches de « The Box » [1] : Hardware, JVM, Application et People.
• Les premiers outils pour ce type de problèmes sont le Gestionnaire des Tâches sous Windows et vmstat/top sous Unix/Linux car ils donnent une vision d’ensemble (IO, CPU Système, CPU Applicative, etc).

D’autres blogs parlent de la venue de Kirk Pepperdine : Le touilleur Express : Présentation de Kirk Pepperdine au Paris Java User Group, David Gageot: Troisième rencontre du Paris Java User Group.

Merci encore aux organisateurs du Paris JUG et rendez-vous le 13 mai pour des présentations sur la Productivité des développements Java (Guillaume Duquesnay) et Maven (Arnaud Heritier).

[1] cf InfoQ : The Box: A Shortcut to finding Performance Bottlenecks par Kirk Pepperdine

Le concept du plat de spaghetti est familier à quiconque a eu l’occasion de travailler sur des architectures distribuées à grande échelle (ou à petite échelle d’ailleurs). Le principe en est simple : à force de multiplier les interactions point-à-point entre des composants ou systèmes hétéroclites, on tisse une véritable toile de dépendances croisées qui, à une vitesse surprenante, conduit l’ensemble du système à la sclérose. Faire évoluer un composant (ou service) devient une tâche impossible, impactant un nombre croissant (et souvent inconnu) de systèmes tiers qui en sont les clients et, du coup, les victimes.

Le schéma suivant résume l’idée :

En règle générale, on cherche donc, lorsque l’on conçoit une architecture distribuée, à adhérer au paradigme ravioli plutôt qu’à celui spaghetti. Dans l’architecture ravioli, chaque composant est petit, et faiblement couplé aux autres ; il encapsule de la viande et d’autres aliments pour le système ; on peut enlever ou changer un raviolo (oui, au singulier, c’est raviolo, ne serait-ce que pour faire plaisir à une charmante italienne de ma connaissance) sans impacter les autres ravioli. A l’occasion, je vous parlerai plus en détail de la Théorie Générale des Pâtes Appliquée au Génie Logiciel (Pasta Theory on Software, en anglais)…

Pour revenir aux problèmes d’architecture, les ESB sont à première vue un moyen simple de s’affranchir du modèle point-à-point au profit du modèle spoke-hub, en d’autres termes de transformer à peu de frais votre plat de spaghetti en plat de ravioli. Le schéma suivant illustre cette évolution :

Présenté de la sorte, l’ESB fait figure de composant magique. Mais cette vision – que certains n’hésitent pas à exploiter sans vergogne dans leurs arguments commerciaux – néglige la nature duale du couplage dans une architecture distribuée.

En effet, lorsque deux composants (ou systèmes ou services ou applications) établissent une communication point-à-point, ils établissent une dépendance à deux niveaux :

• au niveau technique : les deux systèmes doivent trouver un protocole de communication partagé – et ceci est vrai quelle que soit la sémantique d’échange, synchrone ou asynchrone
• au niveau fonctionnel : les deux systèmes doivent s’entendre sur un format d’échange

Appliqué tel quel, un ESB ne fait que résoudre la problématique de couplage au niveau technique – et c’est rarement le niveau le plus critique (les protocoles de remoting ne changent qu’exceptionnellement, et leurs évolutions assurent le plus souvent la rétrocompatibilité).

Si le couplage fonctionnel n’est pas pris en compte, l’ESB ne fait que déplacer le problème – et nous obtenons notre fameux Enterprise Spaghetti Bus :

D’aucuns prétendront que cette situation est préférable, puisqu’elle permet de gérer la complexité en un point unique, et d’utiliser les services de transformation offerts par l’ESB pour gérer les évolutions dans les formats déchange ; l’argument est probablement recevable sur le court terme, tant que le nombre de services et de versions permet une combinatoire de taille raisonnable. Mais il ne fait aucun doute que rapidement, cette combinatoire va exploser – et avec elle le coût d’évolution de chaque service.

La parade à l’Enterprise Spaghetti Bus existe : elle consiste à définir un format pivot, ou modèle canonique, auquel se conforme les producteurs et consommateurs de services. La mise en conformité – c’est-à-dire la conversion du format de données interne dans le format canonique – peut être réalisée par chaque sous-système, ou par l’ESB (la première solution a ma préférence, mais ce n’est pas le sujet du moment). Chaque composant est désormais uniquement couplé au modèle canonique, et la figure rassurante du plat de ravioli semble de nouveau à portée de main.

Reste un problème épineux auquel tous ceux qui tentent de mettre en place une architecture orientée services sont potentiellement confrontés : qui définit et maintient le (ou les) modèle(s) canonique(s) ? Les apôtres de l’urbanisation bureaucratique et de la gouvernance centralisée tendent à promouvoir un long et coûteux travail de modélisation transverse en amont. Je crois cette approche fondamentalement erronée : au mieux, elle risque d’aboutir à un report sans fin de la mise en oeuvre ; au pire, elle conduit à la mise en place d’un modèle rigide, excessivement complexe, mal adapté aux besoins réels des applications et hermétique au changement. Incrémentaliste convaincu, je crois au contraire que le modèle canonique doit être construit de façon progressive et collaborative, en prenant en compte les besoins à mesure qu’ils se présentent ; cela suppose que l’architecture intègre les évolutions du modèle canonique – faute de quoi le problème, une nouvelle fois, aura juste été déplacé. Il doit donc être possible de refactorer le modèle canonique – une opération que les ESB, précisément, rendent possible. Mais ceci est une autre histoire…

SpringSource vient d’annoncer le lancement de Spring Integration, une implémentation légère des Enterprise Integration Patterns. Le lendemain, le projet Apache ActiveMQ annonçait la sortie de sa version 5 qui ajoute le support de ces mêmes Enterprise Integration Patterns grâce à l’intégration d’Apache Camel, un framework léger de routage et de médiations utilisable soit par configuration XML Spring, soit par un Domain Specific Language (DSL) Java. Ces deux approches open source se caractérisent dans le monde des ESB par :

• Une grande légèreté : on ne parle plus de conteneur, d’APIs sophistiquées de connecteurs, de registre de services, de structures de données complexes mais de simples messages composés d’un body souvent sous forme de Plain Old XML (POX) et de headers en mode clef/valeur.
• L’éloignement des standards chers aux grand éditeurs (Java Business Integration – JBI et Service Component Architecture – SCA) pour se cantonner à des Plain Old Java Objects (POJO). On notera tout de même que ces nouveaux frameworks de routage utilisent massivement les API Java EE pour les connecteurs et les transactions (JDBC, JMS, JCA, JTA, etc).

Exemples de configuration de routes avec Apache Camel

Camel Route Configuration With Java DSL

from("file:src/data")
   .choice()
      .when(xpath("/person/city = 'London'"))
         .to("file:target/messages/uk")
      .otherwise()
         .to("file:target/messages/others");

Camel Route Configuration With Spring 2.0 XML Conf

<beans ...>
   <camel:camelContext id="camel">
      <camel:route>
         <camel:from uri="file:src/data" />
         <camel:choice>
            <camel:when>
               <camel:xpath>/person/city = 'London'</camel:xpath>
               <camel:to uri="file:target/messages/uk" />
            </camel:when>
            <camel:otherwise>
               <camel:to uri="file:target/messages/others" />
            </camel:otherwise>
         </camel:choice>
      </camel:route>
   </camel:camelContext>
</beans>

Une rupture radicale avec les précédents ESB ?

Plus qu’une rupture, cet allègement s’inscrit dans une tendance :

• La vague POJO/POX a déjà déferlé sur l’informatique de gestion en Java (SpringFramework, etc) et on pouvait l’attendre sur les technologies d’intégration d’applications.
• JBI 1.0 a rencontré un succès très limité et les travaux actuels sur la version 2.0 suscitent des doutes (cf InfoQ : JBI 2.0 at JavaOne) :
       - Apache ServiceMix se détache progressivement de son objectif initial de conteneur JBI pour devenir en version 4 un « lightweight SOA/ESB container based on OSGI ».
       - Mule ESB ne s’intéresse toujours pas à JBI (cf Mule and JBI).
• La banalisation des connecteurs (JCA, JMS, SOAP, etc) et des conteneurs OSGI [1] (conteneur d’assemblage et d’exécution de composants) a permis de démocratiser le développement des ESB en laissant ces projets se concentrer sur les fonctionnalités de bus.
• L’essor des Domain Specific Languages et la simplicité d’utilisation des configurations XML Spring 2 offrent des alternatives et un retour de balancier face à l’approche du « tout graphique » incarnée par BPEL.

Perspectives pour 2008

On peut attendre en 2008 des mouvements autour des lightweight integration frameworks et des standards :

• Les Lightweight Enterprise Integration Patterns Frameworks vont progresser rapidement et garder leurs distances avec les standards JBI et SCA. Le premier enjeu sera de proposer un middleware d’exécution pour ces frameworks (middleware de message, application server, etc).
• Mule ESB, l’ESB Open Source ‘historique’ devra rattraper son retard en offrant des fonctionnalités spécifiques aux Enterprise Integration Patterns.
• Les grands éditeurs vont continuer leurs investissements sur leurs standards : IBM et BEA sur SCA, Sun sur JBI.
• JBI 2.0 devra trancher deux questions très délicates :
       - Java Module System & Superpackage versus OSGI : Si les premiers sont le standard choisi par Sun, le deuxième, OSGI, fait l’unanimité dans la communauté des middlewares (commerciaux et open source) qui a déjà décidé de l’utiliser.
       - SCA : risquer la marginalisation en ignorant ce standard qui rassemble tous les grands de l’Enterprise Java [2] ou le rejoindre quitte à se faire absorber.

Ressources

• Apache Camel Project
• Spring Integration announcement
• Mule 2 and Beyond by Ross Mason, CTO and Co-founder, MuleSource Inc.
• Mule and JBI in Mule ESB wiki.
• ServiceMix V4 presentation by Guillaume Nodet, Apache ServiceMix PMC Chair and IONA Principal Engineer.
• Should I deploy Enterprise Integration Patterns in the broker or another application in ActiveMQ wiki.
• Can JBI 2 succeed where JBI 1 did not ? by Darryl K. Taft

[1] OSGI est déjà utilisé par Websphere ESB, intégrable dans Spring avec Spring Dynamic Modules for OSGi(tm) Service Platforms, prévu dans ServiceMix 4, planifié pour Mule ESB après la v2.
[2] IBM, BEA, Oracle, SAP, etc

Le cas d’utilisation d’un ESB présenté aujourd’hui est L’exposition de services.

Problématique

Intégrer les applications existantes introduit bon nombre de problématiques. Certains types d’application ne peuvent pas exposer facilement des services (Mainframe, CICS, AS/400, etc.), d’autres offrent des coûts de développement trop élevés ou encore le coût des briques d’accès pour chaque service est rédhibitoire, …

Principe de mise en œuvre

L’ESB ici va permettre d’exposer les services d’une application existante. Sa connectivité lui permet d’interroger les systèmes existants pour créer les services du SI.

Dans le cas où les services de l’ESB ont véritablement vocation à durer dans le temps et constitue, finalement, une « extension » de l’application dont il expose les services, on aura tendance à créer une instance de l’ESB distincte du rôle de médiateur habituel.

Le cas d’utilisation d’un ESB présenté aujourd’hui est La médiation intra-domaine et inter-domaines.

Problématique

Comment gérer un ESB quand plusieurs domaines métiers, fortement autonomes, l’utilisent pour intégrer leurs applications ?

Principe de mise en œuvre

Les différents domaines d’une organisation sont amenés à échanger les uns avec les autres. Ces domaines correspondent à des équipes différentes, des plannings différents voire à des budgets différents. L’introduction d’un ESB aux frontières des domaines permet de décorréler et de découpler les appels entre ces différents domaines. Les domaines peuvent évoluer à leur vitesse avec leur technologie en suivant leurs propres contraintes et éventuellement avec leur vision des données métiers (bien qu’une vision unifiée des données au niveau du SI, lorsqu’elle est possible, simplifie grandement les problèmes de communication).

De même lors d’échange B2B, un ESB peut être placé comme « douanier » entre les applications internes et les applications des partenaires. L’ESB va gérer encore une fois la conversion des protocoles, des formats de données, centralisé les aspects sécurité et traçabilité dans les échanges.

Le cas d’utilisation d’un ESB présenté aujourd’hui est l’intégration avec une solution d’orchestration.

Problématique

Comment déployer un workflow complexe, hébergeant les processus métier de très haut niveau ?

Principe de mise en œuvre

Pour éviter de lier trop fortement l’orchestrateur de processus avec les services qu’il appelle, il est recommandé d’insérer un ESB qui joue encore une fois le rôle de médiateur.

Exemples :

• Il convertit les données échangées au format défini par la conception du processus (alignement avec les besoins métiers).
• Il peut exposer tous les services avec la même technologie pour simplifier la réalisation du processus.
• Il crée un nouveau service en agrégeant deux services existants (ce nouveau service sera éventuellement réintégré ultérieurement dans une des briques du SI à l’occasion d’une phase de rationalisation).

Le cas d’utilisation d’un ESB présenté aujourd’hui est la gestion de la QoS (Quality of Service).

Problématique

La QoS (Quality of Service) d’un service est considérée comme un ratio entre son temps de réponse moyen et la fraîcheur des données qu’il manipule (la QoD : Quality of Data).
L’ESB est en mesure (en s’appuyant éventuellement sur un moteur de règles) de déterminer quelle implémentation invoquer en fonction de la QoS désirée.
L’ESB pourrait aussi être utilisé pour de la « géolocalisation » de services. Imaginons un service qui soit déployé x fois dans différentes régions ou différents pays. L’ESB peut déterminer à partir du message qui transite quel est le service le plus approprié.

Principe de mise en œuvre

Il existe deux implémentations du même service :

• L’implémentation A est au plus proche des données métiers qu’il manipule (le référentiel). De ce fait il travail avec des données fraîches (mises à jour en temps réel). En revanche, son éloignement de l’ESB implique un temps de réponse long.
• L’implémentation B est au plus prêt de l’ESB. Les temps de réponse sont donc très courts. En revanche, il ne travaille pas avec le référentiel de données mais avec un cache mis à jour chaque nuit. Les données qu’il manipule peuvent donc potentiellement être périmées.

Le cas d’utilisation d’un ESB présenté aujourd’hui est la gestion de version.

Problématique

Comment limiter l’impact d’une montée de version d’un service dans une architecture intégrée, quand un nombre quelconques d’applications dépendent de la version courante de ce service ?
Ou, à l’inverse, comment déployer en avance de phase une application cliente d’une version d’un service non encore publiée ?

Principe de mise en œuvre

La gestion de version permet de faire évoluer différents systèmes à des rythmes qui leur sont propres.
Plusieurs situations peuvent se présenter :

• Les versions sont incompatibles entre elles (il n’est pas possible d’effectuer une transformation vers la version la plus récente) : le choix d’une version se fait par routage.
• La nouvelle version est une extension compatible avec la version précédente : L’ESB effectue l’appel vers la nouvelle version en appliquant une transformation du format d’entrée, du format de sortie ou des deux formats. Ceci évite de maintenir dans l’application cible deux versions d’un même service.

Le cas d’utilisation d’un ESB présenté aujourd’hui est la composition / agrégation de services.

L’ESB expose un service de niveau N qu’il construit par composition ou agrégation de plusieurs services de niveau N-1 (voire N).

Il s’agit ici d’un assemblage simple de service, et non d’orchestration ou de processus.

Ce genre de situation peut se produire quand l’application qui fournit les services ne peut exposer facilement ou rapidement des services conformes à la définition métier qui en a été faite. Il est courant de voir développer des applications dites « frontales » qui endossent l’interfaçage avec l’application ou le progiciel concerné. Ces applications frontales peuvent tout à fait trouver leur place dans un ESB.

Le cas d’utilisation d’un ESB présenté aujourd’hui est le couplage lâche.

Problématique

Le couplage technique ou fonctionnel est l’un des risques les plus critiques lors de la mise en œuvre d’une architecture orientée service (SOA).
Le service invoqué peut être exposé dans une autre technologie, utiliser une autre représentation des données, être asynchrone ou en cluster, etc. L’ESB va prendre en charge ces adaptations pour libérer l’application appelante des adhérences avec l’application qu’elle appelle. Le problème d’adhérence est bien sur reporté dans l’ESB mais on considère qu’il est plus facile et plus rapide d’effectuer des modifications dans l’ESB que dans les applications du SI.
Ainsi, la mise en place de couplage lâche entre services facilite grandement la monté de version, la migration ou l’externalisation d’un service puisque ces actions n’impactent plus tous les appelants mais seulement l’ESB.

Principe de mise en œuvre

Les responsabilités de l’ESB sont ici les suivantes :

• Exposition : Le consommateur ne connaît que l’ESB. Il invoque le service que ce dernier lui expose. Cette invocation se fait sur un protocole et avec un format de données qui sont indépendant du fournisseur de service.
• Routage : L’ESB détermine le fournisseur de service à invoquer (éventuellement en s’appuyant sur un registre ou annuaire de services).
• Transformation : l’ESB réalise une médiation de format vers celui pris en charge par le fournisseur de service.
• Invocation : C’est l’ESB qui invoque le fournisseur de service.

La stratégie SOA et ESB de la fondation Apache s’obscurcit encore un peu avec l’annonce de la version 1.0 du ‘médiateur de Web Service’ Apache Synapse.

On trouve aujourd’hui chez Apache trois projets focalisés sur les ESB et si les motivations techniques sont surement très intéressantes, les enjeux financiers sont eux passionnants.

D’un côté le projet ws.apache.org avec son fer de lance Axis (dont le démarrage très buggé de la version 2 a dérouté) est porté, pour ne pas dire trusté, par la startup WSO2 (cf. la liste des committers de Axis2).

Ensuite, on trouve des nouveaux venus chez Apache qui sont encore dans l’incabuteur. On y retrouve le poids lourd CXF porté par IONA ; CXF est l’héritier de la populaire librairie SOAP XFire et de l’ESB Open Source IONA Celtix. Enfin, l’ESB ServiceMix qui est pour sa part porté par Logic Blaze (cf. liste des committers).

Et pour finir, cerise sur la gâteau, le broker de message ActiveMQ que porte aussi Logic Blaze, s’aventure dans le routage et les médiations avec son sous-projet Camel !

 
Ou cela va-t-il donc nous mener ? Tout cela semble bien compliqué au premier abord mais le dénouement sera probablement assez rapide.

Le plus simple, ServiceMix et ActiveMQ.

Tous deux portés par Logic Blaze, l’homogénéité est sauve et nous pouvons espérer qu’ActiveMQ se focalisera sur son rôle de middleware de messages quand ServiceMix développera sur les fonctionnalités ESB/SOA.

Ensuite, CXF by IONA versus ServiceMix by Logic Blaze ?

IONA vainqueur par KO grâce à son rachat de Logic Blaze en avril 2007.

Enfin, Axis2-Synapse by WSO2 versus CXF-ServiceMix by IONA ?

Si IONA joue le rôle de David lorsqu’il affronte les Goliath IBM et BEA sur les produits SOA commerciaux, en revanche, IONA joue ici le rôle de Goliath face au petit WSO2 et la bataille se joue en ce moment.

Notre merveilleux tabloid The Server Side est aux premières loges et nous pouvons y apprécier les truculents coups de canif entre Sanjiva Weerawarana (starring WSO2) et James Strachan (starring IONA). Les deux rings actuellement utilisés sont les annonces TSS : Apache Synapse 1.0 released et TSS : WSO2 ESB 1.0 Released.

Qui sortira vainqueur ? Y-a-t-il de la place pour deux acteurs chez Apache ? Nous ne nous aventurerons pas à nous prononcer mais nous noterons quand même que dans le camps IONA, Celtix, XFire et ActiveMQ ont déjà fait leurs preuves alors que dans le camps WSO2, Axis2 a perdu la position dominante de son prédécesseur Axis1 (cf. notre billet de la semaine dernière sur le projet SOAP Glassfish Tango).

Et l’intérêt des usagers Apache dans tout ça ? Réjouissons nous de voir autant de valeur mise en open source par des éditeurs commerciaux et amusons nous de voir des éditeurs s’affronter par Open Source interposé.