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/

dimanche, 27 mai 2007

Expressivité du langage et avantage compétitif



RailsConf est terminé et Martin Fowler poste ses impressions. La tendance de fond est là, le pouvoir d'expressivité des langages dynamiques leurs assurent une diffusion de plus en plus importante. Martin Fowler indique ainsi que 40% de leurs nouvelles affaires aux états-unis utilisent la plate-forme Ruby, il y a bien sûr un biais de par le positionnement de Thoughtworks, la compagnie pour laquelle travaille Mr Fowler, sur cette technologie mais je pense que cette tendance se confirme bien.
La plate-forme Java a clairement une carte à jouer et Sun l‘a bien compris. Aussi bien au niveau technique avec l‘intégration de la JSR-223 à Java 6 et JRuby qu‘au niveau promotion avec le sponsoring de Sun pour RailsConf.



La sortie de JRuby en version définitive donnera sûrement le coup d'envoi d'un engouement encore plus vif. Il est à noter que Groovy a quelques longueurs d'avance en terme d'implémentation. De manière plus générale la plate-forme d'exécution Java peut devenir le socle de base de beaucoup d'infrastructure ainsi que l'environnement hôte d'autres langages. La richesse de la plate-forme Java est conservée mais avec une ouverture vers des outils mieux adapté à d'autres tâches (Ruby et Rails pour le développement Web par exemple, un petit clin d'oeil à l'ami Gilles qui est parti avec cette technologie pour son projet).

Le pouvoir d'expressivité est pour moi un des principaux avantages compétitifs des languages de programmation, à cette comparaison, les languages dynamiques sont clairement gagnant. Attention néanmoins à ces métriques qui peuvent donner à des Domain-Specific-Language une mesure d'expressivité très importante mais avec peu de souplesse. D'où d'ailleurs l'interêt des techniques de meta-programming de ces languages dynamiques qui permet de bénéficier du meilleur des deux mondes.

La prédominance des langages de programmation avancés, comme les langages dynamiques, dans l'échelle de l'évolution est donc en marche même si elle reste lente.

Technorati Tags:

Posted at 7:07 PM in fr/Technologies/

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/

mardi, 28 novembre 2006

La guerre des langages

Sujet polémique s‘il en est, le choix d‘un langage de programmation peut paraitre secondaire. Néanmoins, un langage apporte toujours ses paradigmes qui influenceront les programmeurs qui l‘utilisent. Les paradigmes de programmation les plus courants en informatique de gestion sont la programmation impérative et objet. La programmation fonctionnelle est, quant à elle, restée cantonnée à des domaines bien précis (universitaires, geeks, etc.). Le plus connu et le plus ancien, Lisp, n'a jamais réellement percé. Paul Graham raconte néanmoins son succès avec Lisp.

Le paradigme fonctionnel fait une percée récemment

Cette percée a pour origine :

  • Le succès de langages intégrant une approche fonctionnelle. Ce n‘est pas le langage lui même qui est populaire mais les possibilités qui lui sont associés. Ruby est populaire grâce au fabuleux framework web Rails, Javascript grâce au phénomène Ajax.
  • La facilité de l‘approche fonctionnelle pour l‘exécution parallèle de traitements. Google et son implémentation du fameux Map and Reduce en est un parfait exemple (même s'il est implémenté en C++ et je reviendrais plus loin sur ce point). Avec la généralisation des machines multi-processeurs, ce sujet va devenir de plus en plus important à l‘avenir.

Les lacunes du langage Java

Ces projecteurs braqués sur la programmation fonctionnelle ont fait ressortir les lacunes du langage phare de ces dernières années : Java. Bien que disposant de paradigmes de programmation nombreux et aboutit – à savoir impératif, orienté-objet, générique depuis la version 5.0 et multi-plateforme – Java manque cruellement du paradigme fonctionnel. Le paradigme de programmation concurrent est comblé par une superbe librairie intégrée à la plate-forme depuis la version 1.4 : java.util.concurrent. Enfin, Java est assez conservateur concernant le typage avec un typage fort et statique.
En résumé les lacunes du langage Java sont (et je parle bien du langage et non de la plate-forme..) :

  • typage fort et statique trop conservateur : Bruce Tate a fait un excellent article décrivant les différents types de binding (mécanisme de liaison entre une déclaration et une implémentation, souvent via un type) à l'oeuvre dans tout langage de programmation et fait le parallèle avec les frameworks "courant" en java que sont Spring et Hibernate. Il décrit ces frameworks comme mettant en oeuvre des mécanismes (interprétation de bytecode à la volée, dynamic proxy, décoration de classe) que l'on trouve nativement dans les langages dynamiques. Je ne peux pas m'empêcher d'afficher le dessin du Dr Larson, qui résume très bien le coeur du problème :
  • aucun paradigme fonctionnel : une fonction en Java est forcément associée à un type et n‘est pas traitée comme un objet de premier ordre. Il n‘est pas possible, en Java, de passer une fonction à une autre fonction sans passer par un type (la notion de fermeture n'existe pas). Steve Yegge, toujours lui, a signé un billet brillant sur ce sujet : Exécution dans le royaume des noms.

La puissance de la plate-forme Java

La plate-forme Java, et non uniquement le langage, reste une des plate-formes d'exécution les plus puissante. L'éco-système Java est l'un des plus riche à l'heure actuelle avec un nombre de librairies externes extrêmement élevé. Les caractéristiques avancées de la plate-forme avec Java EE sont dans certains environnement incontournable (clustering, transaction distribuée, sécurité, messagerie, services web, etc.). Reste néanmoins une certaine complexité de mise en oeuvre qui est atténuée par la dernière version de cette plate-forme : Java EE 1.5. La plate-forme Java reste très adaptable même si le processus est parfois long et contraignant. La JSR-223 vise justement à définir les interfaces d'interaction avec un langage dynamique (dit langage de script) tandis que la JSR-241 définit un langage fusionnant les caractéristiques de ruby, python et smalltalk (ambitieux !). D'autres part, des projets comme JRuby, sponsorisé par Sun, ou Groovy, visent à utiliser la machine virtuelle Java comme un conteneur d‘exécution pour ces langages.

Les compétiteurs

Java subit actuellement une poussée forte de la part de langages plus avancées. Cette poussée est bien sûr du aux capacité des langages eux-mêmes mais également à leurs plate-formes.
Ces compétiteurs se dénomment donc Ruby, Javascript ou Groovy. Je laisse de côté Smalltalk , Python et Lisp à qui ils manquent la petite "étincelle" pour devenir réellement populaire. Je laisse également de côté les 8512 moins 7 autres langages de programmation que l‘humanité a engendré….

Ruby

Rubyest la star du moment, notamment grâce à un framework web dénommé Ruby on Rails, qui a su exploiter toutes les possibilités du langage dynamique Ruby et être très pragmatique (configuration par convention, génération de code, structure de répertoire standard). Sun a embauché les deux développeurs principaux du projet JRuby visant à offrir un interpréteur Ruby écrit en Java et permettant une interaction entre ces deux langages. Grails peut être considéré comme un exemple des interactions possibles entre un langage dynamique et un langage “hôte” plus ancien.

Groovy

Groovy a pour force sa proximité avec la syntaxe Java et son intégration déjà très forte avec la JVM. La JSR-241 s'occupe de sa standardisation. L'équivalent de Rails est disponible avec Groovy et se nomme Grails.

Javascript

Javascript est un langage avancé malgré un à priori "gadget pour le web" et est revenu sur le devant de la scéne grâce au phénomène Ajax.

Oubliez le langage et concentrez vous sur la conception

Cet état des lieux des langages de programmation n‘est pour moi qu‘une introduction à l‘activité essentiel qu‘est la conception. Les langages et des différents paradigmes doivent être considérés comme un outil intellectuel et non comme une simple manière d‘implémenter un traitement. Quelque soit l‘implémentation que vous choisirez vous arriverez toujours à combler, avec plus ou moins de facilité, les lacunes du langage que vous utilisez. Ainsi vous pouvez mettre en oeuvre une approche fonctionnelle avec Java par passage d‘objet interfacé, faire du meta-programming avec de la reflection et de la génération de byte-code à la volée (ce que fait Hibernate par exemple), faire du late binding avec Spring.

L‘exemple le plus flagrant reste l‘implémentation du moteur de recherche Google qui utilise des techniques du paradigme fonctionnel sur la manière d‘aborder un problème (exécution parallèle de traitement sur un volume de données très important). L'implémentation est faite en...C++, langage loin de suivre le paradigme fonctionnel. Autre exemple assez connu, l'implémentation du système de fenêtrage X a été conçu de manière orienté objet mais implémenté avec le langage C non objet.

Je prédis un bel avenir aux langages dynamique, c‘est dans l‘ordre logique de l‘évolution des langages vers un pouvoir d‘expressivité toujours plus grand. Lequel l‘emportera…difficile à dire, je pense que Ruby a de beaux atouts et bénéficie du support (léger..) de Sun. Javascript et Groovy ont une syntaxe proche de Java et peuvent être des outsiders. Attendons de voir.

J‘ai intentionnellement omis C# de cette comparaison car il est extrêmement similaire à Java et n‘est donc pas pertinent dans cette comparaison. D‘autres part, cela m‘évite de rentrer dans la traditionnelle guerre Java vs .Net.

Technorati Tags:

Posted at 8:32 PM in fr/Technologies/

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/

dimanche, 15 octobre 2006

Implémentation de ce site web

Mes besoins lors la mise en place de mon site personnel sur lequel vous naviguez sont les suivants :

  • Me permettre de diffuser mes publications en français et en anglais
  • Etre sous forme de blog pour l‘interactivité et l‘organisation
  • Héberger mon CV
  • Pouvoir diffuser des documents plus long hors blog afin qu‘ils aient une bonne lisibilité par une largeur plus grande
  • Etre simple d‘administration et d‘utilisation
  • Etre implémenté en Java pour faciliter les modifications (c‘est un language que je connais trés bien)
  • Avoir un design sympa

J‘ai donc abouti à la sélection des composants logiciels suivants :

  • Serveur sous Ubuntu linux pour la souplesse et la puissance de cette distribution
  • Blojsom pour l'outil de Blog. Il a nécessité néanmoins des modifications pour intégrer deux langues de publication. Son but est d'être très simple, il stocke les billets dans des fichiers, ce qui me permet de les modifier avec un simple éditeur de texte (jedit en l'occurence). J'ai également ajouté le plugin Xilize à Jedit qui me permet d‘écrire les articles avec un langage très simple que je transforme en XHTML d‘un click.
  • Sitemesh pour la décoration des documents HTML simple avec le même design de page
  • Apache en frontal avec une redirection vers Tomcat qui héberge les composants précédent.
  • subversion pour le partage des sources et des billets entre mes différentes machines
  • Awstats pour les statistiques web et Munin pour le monitoring du serveur
  • Mon.itor.us pour le monitoring extérieur du serveur
  • Design Leaves trouvé sur le site Open Source Web Design et intégré dans un template Blojsom écrit en Velocity.

La machine qui héberge le tout est un de mes anciens PC fixe reconverti en serveur silencieux. Cette machine ne possède donc que le strict minimum :

  • CPU Athlon thunderbird à 800 Mhz
  • 768MO de RAM
  • Un disque dur de 200 Go
  • Un gros ventilateur silencieux Zalman avec potar pour réduire la vitesse au minimum l‘hiver et pouvoir augmenter un peu l‘été
  • Un lecteur de CD
  • Une alimentation sans ventilateur Antec Phantom.
  • Il n‘y a PAS de carte graphique, carte son, clavier, souris, écran, etc... toute l'administration est faite à distance en SSH

Le tout est branché sur mon routeur qui expose le port 80 sur la DMZ lui-même branché sur la freebox. Le fournisseur d'accès Freeme fournit un débit montant de 100ko/s largement suffisant pour mes besoins actuels.

Posted at 8:28 PM in fr/Technologies/
portage salarial freelance