Monthly Archives: January 2005

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?

A use case for AOP

This week I had a nice training/presentation of a product call Docato, it’s an XML content management system based on a pure xml database: X-hive. The product is pretty good, it’s pure java and based on open standard.

One of the nice feature is the way you can extend it. With most software products you need to customize them to meet your customer requirements. Most products can be extended and customized by using hooks that are predefined by the vendor.

In the case of Docato they showed us how to extend it using AspectJ an aspect oriented framework. Using AOP means you can define your own hook to extend the product. This is very effective and powerfull. To work well it means that the product has a clean architecture and provide a good documentation of it’s internal API.

I think this a great use of AOP.

Domotique .Net et SOA même combat…

Julien Brunet nous offfre un lien vers un rapport de magistère: Étude et réalisation
d’une plate-forme domotique sur .Net

Ca peut paraitre surprenant mais ce rapport contient notament une description très claire, et à mon sens très juste, d’une Architecture orienté service

Aujourd’hui, les logiciels « Change On Demand » sont devenus très populaires, les besoins changent vite et il faut s’adapter le plus rapidement possible. De nombreux producteurs de logiciels, proposent dorénavant cette solution évolutive. Une des approches pour réaliser ce genre de produit est une Architecture Orientée Services. Celle-ci est devenue très répandue avec l’explosion des Services Web.Cette approche consiste à diviser le logiciel répondant à un problème, en un ensemble d’entités proposant des services. Chacune de ces entités peut utiliser les services proposés par d’autres entités. On obtient ainsi un réseau de services interagissant entre eux. Cette architecture s’appuie sur une architecture à composants ( implémentation « réelle » des services [Cervantes2004] ) et suit l’évolution logique des architectures logicielles [Endrei2004] ( figure 1) :

Les approches orientées services se caractérisent par :
• une transparence sur la localisation des services
• une indépendance des protocoles de communication
• une indépendance vis à vis des langages de programmation

L’infrastructure sous-jacente cache aux services ces détails. Il est aussi possible de substituer un service utilisé par un autre plus performant si celui-ci apparaît, ou par un service ayant un temps de réponse plus faible. Une architecture orientée services est basée sur 3 acteurs principaux : l’annuaire de services, le fournisseur de services et le demandeur de services. La figure 2 illustre les interactions entre ces 3 acteurs.
Lorsqu’un service est activé, il s’enregistre auprès de l’annuaire (1 ). Ainsi, lorsqu’un autre service a besoin de lui, il peut le retrouver dans l’annuaire ( 2 ) et se lier à lui ( 3 ), pour ensuite pouvoir l’invoquer.

Pour le reste lisez le rapport en plus vous aurez des schémas très clairs.