Yearly Archives: 2005

Le problème avec SOA

Voici un bon billet parlant de SOA

“It strikes me that making this particular SOA dream a reality is not about specs nor is it about tools, it’s about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”

Voilà, tout est dit, mettre en place une architecture orienté service ce n’est pas un problème technique mais fonctionnel. Une SOA c’est etre capable de définir des interfaces qui pourront être réutilisées alors que les spécifications des applications les utilisants vont évoluer.

Ca suppose que ces interfaces soient définies par quelqu’un qui connaisse extrémement bien le métier de l’entreprise.
Ca suppose que l’on dépasse la vision projet pour passer à une vision entreprise.
Ca suppose que l’entreprise ait au préalable une organisation bien structuré. Les services d’une SOA sont la modélisation du fonctionnement de l’entreprise, si l’entreprise fonctionne mal sans SOA elle ne fonctionnera pas mieux avec.

D’ailleur google ne s’y trompe pas, quand on chercher architecture orientée services on trouve cette très bonne description par mega

EJB design patterns

J’avais besoin de me rafraichir un peu les idées sur le EJB command design pattern et maître google m’a dégôté une très bonne ressource. Un powerpoint de 116 slides qui explique assez en détail les différents design patterns utiles lorsque l’on fait (encore) des EJB:

EJB design patterns par  Vijay Bhatt

Un indispensable si vous devez faire des EJB.
Et oui, ils sont bons ces indiens…

Code et Commentaires

“Un code sans commentaire est un mauvais code,
un bon code n’a pas besoin de commentaire…”

Si je me souviens bien ça doit venir de The Pragmatic Programmer, une lecture hautement recommendable.

Je suis tombé sur ce billet qui illustre assez bien l’idée, plutôt que de mettre de tonne de commentaires dans le code pour respecter “les normes”, mieux vaux passer un peu de temps à refactorer son code pour qu’il n’y ait plus besoin de commentaire. Il est beaucoup plus dur (mais plus efficace aussi) de trouver les 3 mots qui vont former un nom de méthode explicite que de mettre 3 lignes de commentaires au dessus de doStuff().

Attention, je n’ai pas dis qu’il ne fallait pas de commentaires dans le code, mais juste la où il y en a vraiment besoin.

XML <=> javabean = Xstream

Voici le plus court chemin pour aller d’une structure XML à des javabeans et vice-versa: Xstream.

L’outil est impressionnant  de facilité et d’efficacité. Attention il s’agit d’un sérialisateur/désérialisateur => les structures objet et xml  doivent se correspondre. Il sait traiter les types simples tout comme les collections ou les maps. Une limite, il ne reconnait pas les attributs d’un élément mais seulement les sous éléments.

Dans le même genre il y a aussi jox

Si vous voulez faire du “mapping” xml < => objet, du xml databindings, il va falloir se tourner vers des solutions plus lourdes se basant sur un XML schema comme:
– Castor XML
– XMLBeans
– ou Jaxb

Ce ne sont pas les seules solutions, en voici une liste assez complète, selon un sondage sur manageability castor XML serait la solution la plus utilisée.

Inversion of control ou Dependency injection ?

L’année 2005 promet d’être celle des conteneurs légers basés sur l’Inversion of control et des notions de programmation orienté aspect.

Inversion of control comme le décrit Michael Spille ou Dependency injection terme inventé par Martin Fowler? La lecture de ces deux articles permet d’avoir les idées assez claires sur la question. Pourtant j’ai toujours eu le sentiment qu’il restait certains éléments m’échappant concernant ces concepts. Par exemple, quelle est la nature de la relation entre Ioc et depency injection si ce n’est pas la même chose?

Je viens de finir la lecture de “J2EE development without EJB” par Rod Johnson (à lire absolument pour tout architecte J2EE) et j’y ai, entre autre, trouvé la réponse à cette question.

L’Inversion of control est le principe selon lequel ce n’est pas à un objet lui-même de déterminer les dépendances dont il a besoin. Mais c’est à un élément externe et centralisé de déterminer pour l’objet les implémentations des autres objets qu’il va utiliser.
Cette technique permet d’assurer le découplage des objets ainsi qu’une grande souplesse dans les possibilités de paramétrage.

L’Ioc est un principe, il existe plusieurs manières de l’implémenter, on en distingue 2 :
– Dependency lookup
– Dependency injection

Le pattern dependency lookup consiste à utiliser un singleton couplé à une factory ou à un registry pour résoudre les dépendances entre objet. Si vous utilisez un service locator, une factory ou JNDI vous faites déjà de l’inversion of control. Mais cette approche présente un défaut : votre objet a au minimum une dépendance avec JNDI, un singleton ou votre factory.

Le pattern Dependency injecty permet de résoudre ce problème et de supprimer quelques lignes de code superflues. C’est le container qui va assembler les objets entre eux et résoudre les dépendances. Vos objets n’ont plus à “trouver” leurs dépendances, elles sont déjà là. Vos objets sont parfaitement découplés, ils ne dépendent plus d’aucune API.
Il existe un débat pour savoir si il vaut mieux utiliser des setters ou un constructeur pour faire l’injection de dépendance, il est quelque peu stéril, ça n’a pas grande importance. Utilisez la méthode qui vous convient le mieux. Si vous utilisez trop de setter ou si le constructeur d’un de vos objets a trop de paramètres c’est sans doute révélateur d’un problème de conception, un objet doit avoir un nombre limité de responsabilités, dans l’idéal une seule.

Voilà pour moi c’est enfin entièrement clair, et vous?