Christophe Heubès

Comme annoncé sur le blog de Xebia france dans le billet "Spring Integration - L'avènement des 'lightweight ESB' ?", SpringSource a annoncé fin 2007 le lancement de Spring Integration, une implémentation légère des Enterprise Integration Patterns.
Le projet est aujourd'hui dans sa phase finale (la version courante est 1.0.0.M4). Mark Fisher apporte les dernières touches à Spring Integration : bugfix, refactoring, configuration, documentation, samples, ...

L'occasion d'une introduction à Spring Integration, la plate-forme de messaging de SpringSource.

Les mois de mai et juin ont été l'occasion de dérouler sur le blog de Xebia France une série intitulée "Les 10 pièges de la SOA". Cette série, à l'initiative de mes collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington a pour objectif de faire partager nos expériences issue de l'implication des consultants Xebia dans des projets SOA (Service Oriented Architecture).

La liste complète de ces pièges peut être ordonnée en trois catégories :

Les pièges liés à l'implémentation :

• N° 10 - Le syndrome "Not Invented Here"
• N° 09 - Le Versioning
• N° 08 - La sécurité

Les pièges liés à l'architecture et au design :

• N° 07 - Mauvaise granularité des services
• N° 06 - La SOA ne résout pas automatiquement la complexité
• N° 05 - Big Design Up Front (BDUF)
• N° 04 - Mauvaise utilisation des Modèles de Données Canoniques (pivots)
• N° 03 - Le manque de compétences

Les pièges liés à l'organisation :

• N° 02 - Propriété des composants et Financement au projet
• N° 01 - Ignorer les impacts culturels

Comme toujours dans ce genre de "classement", cette liste n'est ni exhaustive ni définitive.

---

Article original : "Les 10 pièges de la SOA" sur le le blog de Xebia France.

Les méthodes agiles et les architectures orientées services courent après la même quête : l’agilité du système d’information.

Sont-elles pour autant conciliables ? Les SOA peuvent-elles profiter des méthodes agiles ? Les unes et les autres sont-elles vraiment conciliables ?

Premiers éléments de réponse sur TV4IT par Guillaume Bodet, directeur technique de Xebia (interviewé par Cyril Dhénin).

Les ESB (Enterprise Service Bus) visent, d’une part à assurer l’interconnexion et d’autre part à gérer la médiation des communications et des interactions entre services et applications d’un SI. Quoique non indispensables, ils n’en demeurent pas moins une brique à forte valeur ajoutée dans le cadre d’une mise en place d’une architecture orientée service (SOA) mature.

Néanmoins les ESB sont aujourd’hui victimes de leur succès et il est souvent difficile de décrypter leur rôle exact.

L’objectif de ce livre blanc est de présenter les fonctionnalités que l’on peut attendre d’un ESB et comment il peut répondre aux besoins d’adaptation inter-applications d’une SOA.

Télécharger le Livre Blanc Comprendre et savoir utiliser un ESB dans une SOA.

Dans le cadre du séminaire "Les ESB dans la SOA : Comprendre & Savoir utiliser" donné par Xebia le 09/10/2007, Manuel Eveno et moi même vous proposons une série d’articles présentant différents cas d’utilisation d’un ESB :

• Cas d’utilisation d’un ESB (1/6) : Le couplage lâche
• Cas d’utilisation d’un ESB (2/6) : Composition / agrégation de services
• Cas d’utilisation d’un ESB (3/6) : Gestion de version
• Cas d’utilisation d’un ESB (4/6) : Gestion de la QoS
• Cas d’utilisation d’un ESB (5/6) : Intégration avec une solution d’orchestration
• Cas d’utilisation d’un ESB (6/6) : Médiation intra-domaine et inter-domaines
• Cas d’utilisation d’un ESB (Bonus) : Exposition de services

La mise en œuvre d'une architecture orientée services (SOA) est un bien vaste chantier. Elle impacte toutes les composantes du SI et doit impliquer tous les acteurs de la DSI et même au-delà. De plus, elle suppose une profonde mutation des façons de penser et de concevoir le SI.
Autour de cette problématique titanesque, la question de la bonne approche pour la mise en place d'une SOA a donné lieu à bien des écrits et des théories chacune sous tendant des positions souvent trop dogmatiques.

Dans l'article "Mise en Å“uvre d'une SOA : Les clés du succès", je présente :

• Les différentes approches
• Les clés du succès

"Mise en Å“uvre d'une SOA : Les clés du succès" sur le blog de Xebia France.

Lors de la réalisation d’un service pour une architecture SOA, il arrive de devoir introduire, dans certaines situations, les notions de contexte ou de session.

Manuel Eveno nous expose, dans son billet "Service Stateful vs. Service Stateless", quels sont les impacts de tels mécanismes et nous montre qu’il suffit d’appliquer la célèbre méthode KISS (Keep It Simple, Stupid) pour s’en sortir.

Service Stateful vs. Service Stateless sur le blog de Xebia France.

Dans l'article "Why support services are critical, but not important", Steve Jones exhorte les services IT à bien faire la différence entre les services métiers, qui sont "importants", et les services de support, qui sont "critiques".

Même si l'exemple du tour de France est un peu tiré par les cheveux, c'est une nouvelle occasion de rappeler que l'objectif des SOA est de mettre l'IT au service du métier.

C'est pourquoi, seuls les services apportant de la valeur à l'entreprise (les services métiers) doivent être considérés comme importants.

Les services applicatifs et/ou techniques (libre à chacun de définir son découpage horizontal et de nommer ses typologies de services comme il l'entend) restent des services de support, au sens où ils supportent les processus et services métiers qui sont construits par assemblage (orchestration) de ces services. Ils sont donc critiques, puisque de leur bon fonctionnement dépend celui des services métiers, mais ils ne sont pas importants puisqu'ils n'apportent pas de valeur ajoutée au métier.

Le débat est en ce moment très animé autour d'une hypothétique standardisation de la pile des standards SOA.

L'occasion de retomber sur un article d'Aurélien Pelletier : "SOAP is the EJB of XML???". Ce billet à plus de deux ans mais la question est plus que jamais d'actualité à l'heure où de plus en plus de voix s'élèvent autour des solutions alternatives, aux EJB d'une part, aux Web Services d'autre part. Elle mérite d'être posée, élargie et remise en perspective : Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?

C'est ce que je m'efforce de faire sur le blog de Xebia France dans le billet "Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?".


Le billet complet : Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?.

CXF est un projet de l'incubateur Apache porté par IONA. CXF est l'héritier de la populaire librairie SOAP XFire et de l'ESB Open Source IONA Celtix.

Evénement annoncé comme il se doit sur TSS ("Apache CXF 2.0 Released - build services using frontend APIs like JAX-WS") qui liste les principales fonctionnalités de la release.

Comme nous l'expliquait Cyrille Leclerc dans son billet "La bataille des ESB Apache : Synapse vs. Service Mix vs. CXF", la multiplication des projets ESB au sein de la fondation obscurcie la stratégie SOA et ESB d'Apache.