Posts in soa

Devoxx 2012 : Versionner Son Service Dans Une Architecture SOA Et/ou Cloud

left-small

Ça y est… Devoxx est fini… :‘( Comme je l'ai dit dans un article précédent, je ne ferai pas de compte-rendu exhaustif de présentations auxquelles j'ai pu assisté à Devoxx.

Cependant, je tenais à revenir sur la présentation “Service Versioning in SOA and Cloud” par Ignaz Wanders (@ignazw) dont le synopsis était :

Keeping versioning under control is essential in the success of a SOA. However, there are no industry standards for service versioning, thus leaving the responsibility of implementing a service versioning system up to the architects and developers within the IT enterprise.


We often see design-type versioning, resulting in Big Bang governance strategies. A runtime versioning strategy may be, in fact, be preferable.


Every change must be built, and every change must be governed. A “cheap” build may lead to a large governance impact. But conversely, a small governance cost may lead to a large build impact. Both build and governance costs need to be taken into account and carefully balanced when choosing and implementing a service versioning strategy.

Dans cet article, je me contenterai de montrer quelques-uns des slides de la présentation de Ignaz Wanders qui définissent et synthétisent très bien les différentes stratégies possibles en partant de comment numéroter ses services pour arriver à une proposition qu'il aimerait avoir du coté du consortium OASIS avec un WS-Versioning. Les slides étant suffisant en eux-mêmes et n'ayant pas envie de répéter/déformer leur contenu, je ne mettrai donc que les photos prises pendant la conférence…

in architecture, devoxx, eip, java, soa Read on →

Découpage De Projets : Projet vs. Modules

left-small

Lorsqu'un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d'approches :

  • le découper fonctionnellement,
  • le découper techniquement.

En outre, en plus de ce type de découpage, il est également important de s'interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c'est ce dernier qui est utilisé, ou faut-il en créer plusieurs?

C'est de ce dernier point dont il sera question dans ce court article qui présentera l'avis que j'ai pu me faire concernant le découpage technique du projet ie. s'il vaut mieux le découper en projets séparés ou en module (au sens maven du terme).

Il s'agit d'une opinion très personnelle qui peut ne pas être partagée par tous mais je trouvais intéressant de fournir mon humble avis et de le marquer noir sur blanc. Si je venais à dire des bêtises, au moins, cet article servira d'amorce à la discussion ;–)

in architecture, avis, java, maven, réflexion, soa Read on →

Présentation Sur Les Problématiques Liées à Une Architecture Distribuée

Ci-dessous se trouve une présentation que j'ai donné sur les problématiques liées aux architectures distribuées. Pour information, c'est un retour d'expérience d'une mission qui date un peu puisque c'était en 2007 mais les préconisations restent identiques à ce jour.

Enjoy et n'hésitez pas à commenter ;–)

in architecture, java, présentation, soa

Orchestration Ou Routage?

left-small

Orchestration ou routage? Telle est la question qui se pose souvent… En effet, il est important de se poser la question sur la solution à adopter pour gérer, par exemple, des transformations ou du routage de messages dans un système asynchrone : s'agit-il de médiation technique ou de quelque chose de plus complexe (ie. de logique métier)?

PEtALS Link vient de mettre à disposition un livre blanc traitant du sujet en proposant différentes pistes pour choisir la solution d'implémentation.

D'ailleurs, j'en profite également pour mettre le lien vers la présentation de PEtALS ESB qui a eu lieu au JUG de Poitou Charentes.

in eip, esb, soa

Spring Integration vs. Apache Camel

left-small Lors d'un post précédent, j'avais parlé des EIPs (Enterprise Integration Patterns) en expliquant qu'il s'agissait de Patterns permettant de normaliser les échanges de messages dans un système asynchrone.

Dans cet article, je vais tenter de présenter succinctement deux de ses implémentations : Spring Integration et [Apache Camel](https://camel.apache.org/.

En fait, pour être plus précis, je vais plutôt tenter de présenter la vision que j'en ai ainsi que la façon dont je les ai compris.

Ainsi, ce post n'a pas pour objectif de les détailler de manière exhaustive car ils sont trop complets pour cela et qu'un seul post ne pourrait suffire à les aborder tous les deux (leurs documentations font d'ailleurs, pour Spring Integration, plus de 130 pages, et pour Apache Camel, plus de 580 pages… cqfd… ;–) ) mais juste, comme je l'ai dit précédemment dit, d'aider à comprendre leurs différences (quelles soient conceptuelles ou structurelles).

Je ne reviendrai pas sur les concepts des EIPs ni de JBI que j'utiliserai dans la suite et pour cela, je vous renvoie sur internet ou sur mes posts précédents (ici et ).

Concernant les versions utilisées, cela n'a pas vraiment son importance ici car je m'intéresserai surtout aux principes de ces deux frameworks mais à titre indicatif, il s'agit des versions 2.0 pour Apache Camel et 1.3.0 pour Spring Integration (il me semble qu'il n'y a pas de modifications flagrantes dans les versions courantes qui sont 2.2.0 pour Camel et 2.0.0.M2 pour Spring Integration).

in apache camel, eip, java, jbi, soa, spring integration Read on →

EIP : Qu'est Ce Que C'est

left Dans l'article sur JBI, j'ai mentionné à de nombreuses reprises le terme EIP. Cet article revient sur cette notion que je considère comme étant très importante surtout lorsque l'on doit jongler avec des messages asynchrones.

En fait, les EIP (Enterprise Integration Patterns) sont issus de l'excellent livre éponyme de G. Hohpe et B. Woolf chez Addisson Wesley. Ne pouvant que vous recommandez sa lecture si vous trempez dans cette problématique, cet article ne sera qu'une brève introduction à son contenu (il fait quand même plus de 600 pages, donc je ne vais pas prétendre le résumer… ;–)). Cet article se voudra très théorique et d'autres articles ultérieurs couvriront quelques implémentations d'EIP comme Apache Camel ou Spring Integration (et peut être, un jour, iBeans). En outre, il suivra le plan du livre dont il est tiré.

in eip, soa Read on →

JBI : Qu'est Ce Que C'est?

left Voilà mon premier article. Il a pour objectif de présenter JBI (Java Business Service) aussi connue sous le doux nom de JSR 208 (Java Specification Release).

Pourquoi un article sur JBI?

Vous pouvez vous demander pourquoi un article sur JBI? Les réponses sont simples : j'aime bien cette spécification et je trouve qu'elle a du potentiel et qu'elle est sous exploitée.

Bien sûr, me direz-vous, en tant qu'utilisateur d'un PEtALS ou ServiceMix, pourquoi devrais-je comprendre la technologie sous-jacente? Eh bien, c'est une affaire de goût : si vous préférez utiliser un produit comme une boite noire, passer votre chemin. Par contre, si vous voulez comprendre ce qui se passe à l'intérieur, j'espère que cet article pourra répondre à vos attentes.

Autre interrogation : pourquoi m'embêter à comprendre une technologie qui ne décolle pas (du moins de ma fenêtre) et sur laquelle les éditeurs ne communiquent pas énormément (c'est vrai qu'ils préfèrent communiquer sur ce qu'ils offrent et non comment ils le font) ? Là encore, question de goût et puis qui croyait en l'émergence du téléphone portable ou même de la télé réalité ? (personnellement, je ne croyais ni en l'un ni en l'autre…) cqfd… ;–)

Ce premier article a donc pour objectif de présenter JBI. Seront abordés ses concepts généraux avec une approche telle que celle décrite dans ses spécifications ainsi qu'un succinct retour sur ce que je pense de JBI..

Cependant, ne seront pas abordés, ici, les mécanismes utilisés en son sein ainsi que des notions de SOA (de très bon article abordent déjà SOA) même si, qui dit JBI dit SOA (la réciproque n'est pas foncièrement vrai…).

Il est à noter que dans cet article j'utiliserai souvent le terme de composant (peut être à mauvais escient) au lieu du terme service. Il s'agit d'un abus de langage lié au fait que j'ai tenté d'être le plus clair possible et que en évitant d'aborder trop de notions afin d'éviter de vous perdre ;–).

in java, jbi, soa Read on →