Yearly Archives: 2005

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.