Ç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.
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?
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 ;-)
Introduction sur les problématiques d'une architecture distribuée View more presentations from jetoile
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.
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.
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… ;-)).
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?
