Vous trouverez sur ce site mes publications concernant les technologies de l'information. Le contenu est disponible en français et en anglais.

dimanche, 7 octobre 2007

Actifs architecturaux

Peter Eeles a publié sur L' eZine Rational Edge un excellent article concernant les “actifs” qu‘utilise l‘architecte de systèmes logiciels dans le cadre de son travail. Je trouve cet article extrêmement intéressant car il formalise bien ces actifs que l‘on utilise implicitement. Cette formalisation fournit une bonne base pour structurer notre capital de connaissance et de réalisation. Le point central de cet article est la description de chacun des éléments du méta-modèle.
Quels sont donc ces actifs qui compose ce capital ?

  • Les patterns: d‘architecture, de conception et de programmation
  • Les styles architecturaux
  • Les architectures de référence
  • Les frameworks techniques (une implémentation JEE, d‘un portail) et applicatifs (progiciels comme SAP ou Siebel, ou la partie “fonctionnelle“ d‘un portail)
  • Les applications “historique“
  • Les librairies de composants

Peut on identifier d‘autres actifs ? pour ma part je rajouterais l‘actif “implémentation exemple ou de référence” que l‘on peut éventuellement classer comme un exemple d‘implémentation d‘une architecture de référence (par exemple le Pet Store de Sun ou le Virtual Shopping Mall d'Oracle).

Les caractéristiques de granularité et de complétude identifiées par Peter Eeles pour catégoriser ces actifs sont intéressantes. Ces axes se situent néanmoins au niveau modèle. Si l‘on instancie ce modèle et que l‘on aboutit à un ensemble de composants d‘architecture, une caractéristique importante pour ces composants d‘architecture au sens large (pattern, composant logiciel, style architectural) est la maturité et le retour d‘expérience que l‘on a vis à vis d‘un composant en particulier.

Au final, je pense qu‘un effort de formalisation est toujours le bienvenu pour structurer des connaissances sur un domaine. Que cette formalisation soit partagée par tous est encore plus appréciable, d‘où l‘intérêt de voir l'OMG proposer une spécification sur tous ces actifs ré-utilisable du système d‘informations.
Reste, comme le dit Peter Eeles, à travailler sur le cycle de vie de cette base d‘actifs : comment les créer ? comment les ré-utiliser ? comment mettre en place une organisation et une culture de ré-utilisation et de partage. On touche là à la caractéristique centrale d‘un métier de la connaissance comme le notre : la capacité de l‘architecte à mettre en musique de manière créative ses connaissances et son expérience, bref ce qui fait sa compétence. Pour conclure ce billet, j‘ajouterais que c‘est cette part créative, toujours trop faible à mon goût, qui fait l‘intérêt de notre métier.

Technorati Tags:

Posted at 11:27 AM in fr/Architecture/

dimanche, 10 juin 2007

Concepts fondamentaux SOA

La mise en oeuvre d‘une Architecture Orientée Services, SOA pour utiliser le terme à la mode, est maintenant fréquente. Ces mises en oeuvres font sainement mûrir les réflexions sur ce sujet. Après une première phase de diffusion et d'explication sur ce qu'est le SOA, une certaine acceptation se met en place. Ainsi on trouve par exemple les grands principes qui guident cet architecture , les bénéfices espérés, une méthode de mise en oeuvre et bien sûr les implémentations des vendeurs qui aideront à la mettre en oeuvre (le verbe “aider” est important car ces outils ne sont pas magique).

Architecture en couche

Cette architecture permet tout d‘abord de se poser des vrais questions de fonds sur la formalisation du métier de l‘entreprise et place l‘architecture du système en première ligne et cela est bien salutaire.

Ce qui est également intéressant à mon sens est le changement de paradigme qui s'opère avec cette architecture. Je m'intéresse fortement aux niveaux d'abstraction des concepts que l'on manipule et le SOA apporte clairement un niveau d'abstraction élevé très appréciable. Quels sont les concepts que l'on peut considérer comme fondamentaux des architectures SOA ?

  • Les concepts formant un processus qui sont : l'activité, la transition, la synchronisation. Ces concepts sont important car ils permettent de mettre l'accent sur la modélisation d'un traitement à un niveau macro avec une possibilité d'implémentation quasi-directe. Cela va de pair avec le retour en grâce des langages fonctionnels , on peut ainsi dire que la fonction reprend le pas sur la donnée qui avait été mise un peu trop en avant avec l‘approche objet.
  • L'événement : concept fondamental d'une modélisation dynamique digne de ce nom et quelque peu délaissé au sein d' UML . BPMN , quant à lui, intègre mieux ce concept.
  • La composition : l‘approche objet a essentiellement apporté une vision structurelle de cette notion. Une approche plus dynamique est fournie par le style architectural "Pipe-and-Filter".
  • Le service : le service est l‘élément unitaire de cette architecture car c‘est lui qui est l‘interface du système unitaire sous-jacent (et si possible implémenté avec une approche objet).
  • Les données : cela peut paraitre évident mais ce concept très large a tellement évolué ces dernières années dans ses implémentations que je me permet de le faire rejaillir en tant que concept fondamental. Le web et le langage XML y sont pour beaucoup dans ces évolutions. L'article d'Adam Bosworth concernant les changements de fond en cours dans la structuration de données en est une excellente vision. Il ne faut pas oublier non plus que ces données se déplacent et proviennent de source hétérogènes, la norme SDO vise précisement à faciliter ces manipulations lors de la mise en oeuvre.

Ces cinq grands concepts forment ainsi pour moi les fondations des architectures SOA. On trouve également quelques concepts transverses mais qui restent pour moi secondaires et moins structurants (les registres de services, les moteurs de règles, la gestion des services et leur surveillance, etc.). Un principe qui reste néanmoins très important lors de l'implémentation, mais qui n'aide donc pas à la modélisation, est le respect des standards ( XML , WS-* ou web avec REST , etc.).

Ce billet m‘est inspiré par celui de Gregor Hope sur les patterns SOA, je le rejoins sur les trois premiers concept mais à mon sens l‘approche déclarative ne fait pas de rupture de paradigme car elle est en place depuis longtemps (SQL en est l‘exemple le plus fameux)..

Technorati Tags:

Posted at 3:18 PM in fr/Architecture/

mercredi, 28 février 2007

10 principes de conception et SOA

Suite à ma publication sur les principes génériques de conception, je suis tombé sur cet article de Stefan Tilkov à propos des 10 principes SOA.
Pour chaque principe SOA, voici le parallèle que je fait :

  • “Explicit boundaries” : Dans son contenu, tout service doit être auto-suffisant et ne pas dépendre d‘un contexte partagé. Bref, principe de réduction des états.
  • “Shared Contract and Schema, not Class“ : Minimisez les dépendances structurales, ici par utilisation de document XML.
  • “Policy-driven“ : Ce principe décrit l‘accord entre fournisseur et consommateur, autant d‘un point de vue fonctionnel que technique. Je n‘ai pas décrit cette notion, notamment technique, car c‘est une des fondations des principes SOA. L‘adaptation à des environnements techniques hétérogènes.
  • “Autonomous” : Ici je dirais plutôt protection des variations.
  • “Wire formats, not Programming Language APIs“, “Document-oriented“, “Loosely coupled“, “Standards-compliant“, “Vendor independent” : Tous ces principes ont trait à la minimisation des dépendances par : utilisation de format et de protocoles standard, utilisation d‘un format de données plus évolutif, utilisation de standard et non utilisation de fonctionnalités propriétaires.
  • “Metadata-driven” : utilisation de registre et si possible auto-description des services par leur nommage.

Technorati Tags:

Posted at 11:40 PM in fr/Architecture/

10 principes de conception

Je viens de publier un article à propos des principes génériques de conception de systèmes logiciels. J‘ai essayé à travers cet article de résumer des grands principes, certains bien connus comme l‘encapsulation, d‘autres trop souvent oubliés comme la protection des variations. J‘espère que ces principes vous seront utiles comme ils le sont pour moi.

Plan de l'article :

Technorati Tags:

Posted at 11:08 PM in fr/Architecture/

mercredi, 1 novembre 2006

REST : une architecture échelonnable

Lors de la définition d‘une architecture, nous devons choisir quels seront les concepts ou principes majeurs qui la soutiendront. Ces concepts forment le style architecturale. Ils peuvent être évalués de manière qualitative suivant différents aspects, mais un aspect “validant” majeur reste l‘échelonnabilité (traduction de l‘anglicisme scabilité), c‘est à dire : est ce que le système construit peut supporter une charge importante sans reconception majeure ?
La scalabilité en informatique s‘obtient notamment par une utilisation non exponentionnelle des ressources au fûr et à mesures de la montée en charge. La réduction des états gérées par le système fait partie des réponses possibles à ce problème. C‘est d‘ailleurs pourquoi les langages fonctionnels sont intéressant, mais cela fera l‘objet d‘un futur billet.

Ainsi le style architectural REST -Representational State Transfer) répond admirablement bien à ce challenge. Ce style architectural est celui du web. Ce style est basé sur le protocole stateless HTTP qui propose quatres "verbes" GET, POST, PUT et DELETE sur des ressources Ces verbes sont très proches de l'acronyme CRUD bien connu en base de données. Chacun représente une action bien particulière qui modifie ou non l‘état du système considéré. Ainsi :

  • GET : cette action est idempotente et ne modifie pas l‘état du système. L‘équivalent d‘une lecture de données.
  • POST : modifie l‘état du système et n‘est pas idempotente, exemple : l‘ajout d‘un article à un panier ou la validation d‘un panier. Les données ne sont pas compris dans l‘URI.
  • PUT : crée ou modifie une ressource particulière mais est idempotente.
  • DELETE : supprime une ressource.

REST fut proposé initialement par Roy Thomas Fielding pour sa thèse de doctorat.
REST est donc un style architectural simple et très robuste, validé par le web, et qui peut être combiné à la toute puissance du langage XML.
Ce billet m‘est inspiré par ceux d‘Eliotte Rusty-Harold qui pose quelques questions d'ordres pratiques très intéressantes sur REST et l‘utilisation du protocole HTTP.

Le style REST est effectivement simple mais est il suffisant pour batir des interactions complexes et éviter de déporter une logique applicative trop importante sur le client ?
Un exemple très intéressant est donné par cet article qui fournit une transcription REST d‘un service de mail, cet exemple illustre toute l‘importance d‘une identification correcte des ressources. Le parallèle avec l‘approche objet est par ailleurs très net quant à la représentation des ressources.

Quelques liens de mes bookmarks pour aller plus loin sur REST :

Technorati Tags:

Posted at 11:04 PM in fr/Architecture/
portage salarial freelance