Ce qui ne marche pas, ou pas encore :

Les bibliothèques publiques de composants métier : la prolifération récente de schémas XML montre bien la difficulté de telles approches

Un certain niveau de déception l’emporte, surtout pour ce qui est d’un véritable marché ouvert des composants.

L’approche composant est un bon cadre structurant pour minimiser les coûts de développement à l’intérieur d’une organisation, sans négliger les très forts inhibiteurs culturels qui se manifestent dans la population des programmeurs vis à vis de cette approche perçue comme un frein à la créativité.

Devant le relatif échec du composant, réapparaissent des approches similaires qui passent du mode produit au mode service. Les composants ne sont plus de morceaux de code réutilisable, mais des services accessibles via le Web (« Services Web » : SOAP, UDDI, HTML). Une application devient alors la composition harmonieuse et dynamique de ces services, qui ne sont plus à réinventer « à la maison ». Cette approche semble assez utopique. Les services Web sont une technologie clef (voir au

§ 5.3 - ), en particulier pour l’intégration applicative, avec une granularité au niveau de « une application » mais leur utilisation à un niveau de granularité intra applicatif sera sans doute vouée à un succès limité. Un macro composant applicatif encapsulé par des services Web présente l’énorme avantage d’être accessible universellement en mode service par toute application moderne ou modernisée.

4.7 - FRAMEWORKS

L’architecture applicative désigne l’art et la manière d’utiliser au mieux les outils d’un modèle de composants pour implémenter les besoins fonctionnels de l’application. Le besoin d’une architecture applicative au dessus de l’architecture technique des modèles de composants est lié à la relative complexité de ces modèles, liée elle-même à leur puissance.

Ceci se matérialise par la notion de « Design Patterns». Le concept de « design pattern » existe bien avant Java et C#, mais prend actuellement toute sa valeur. Un certains nombre de patterns s’insèrent dans l’approche MVC*, comme Modèle – Vue - Contrôleur.

Le modèle MVC distingue trois fonctions :

• Le « modèle » implémente la logique métier,

• La « vue » implémente l’interface utilisateur,

• Le « contrôleur » régit les interactions entre la vue et le modèle.

Le modèle MVC isole proprement le métier et la présentation, et les parties statiques et dynamiques de la présentation.

Ces patterns peuvent ne pas rester sous forme papier et se matérialiser par l’intermédiaire des « frameworks ». (On pourrait utiliser en français l’expression

« cadre de programmation » pour traduire framework, mais ce n’est pas une pratique courante). Les frameworks les plus connus sont struts et cocoon, disponibles en logiciel libre. Des produits commerciaux apparaissent, comme Wakesoft.

Le framework inverse l’approche programmatique, par rapport à une librairie. Le programme est autonome et appelle une librairie. Le framework est très structurant et appelle les méthodes écrites par le programmeur selon les actions de l’utilisateur. Un framework est donc plus puissant qu’une librairie mais aussi plus coercitif.

Composants Composants

Framework

Serveur Applicatif

Il y a un seul framework pour un projet, au service de tous les composants applicatifs.

Techniquement, les frameworks aident à répondre aux questions suivantes :

• Où implémenter ma logique métier ?

• Comment utiliser les différents types de composants ?

• Comment gérer la persistance ?

Les avantages du framework sont un gain de temps et donc d’argent, et une diminution du risque.

Le prix à payer est l’investissement amont pour sélectionner l’outil et former les programmeurs. Cela induit une relative dépendance vis à vis du framework choisi.

4.7.1 - Les composants techniques des frameworks Ils répondent aux fonctions suivantes :

• Présentation :

o Présentation sur le serveur, o Navigation,

o Echanges XML.

• Logique métier : o Objets métier, o Cache des objets, o Logging.

• Données :

o Persistence,

o Mapping objet-relationnel.

Dans le paysage actuel de l’informatique, les notions de « design pattern » et de framework ne sont populaires que parmi les programmeurs Java et le monde du libre.

Le monde Microsoft semble peu enclin à utiliser ces concepts. Ceci peut s’expliquer culturellement par le fait que Visual .NET, pour prendre la dernière mouture de l’atelier logiciel de Microsoft, propose en lui-même un cadre de programmation assez directif, d’ailleurs conforme au modèle MVC et constitue donc en quelque sorte un framework. Le programmeur moyen est bien guidé, le programmeur expérimenté peut se plaindre d’être bridé.

Quoi qu’il en soit, les design patterns les plus utilisées sont les « design patterns for Java », les frameworks décrits ci-dessous étant tous écrits en Java.

4.7.2 - Struts

Struts est un framework qui structure les composants V et C du modèle MVC2.

Il ne s’intéresse donc pas à la logique métier. Il s'agit d'un projet du groupe Jakarta d'Apache* ayant débuté en mai 2000. Jakarta est le groupe de la fondation Apache en charge de développer, maintenir et fournir des solutions autour de la plate-forme Java.

4.7.3 - Cocoon

Il adopte aussi le modèle MVC mais est structuré autour de XML et XSL. Le contrôleur est un transformateur XSL*, étendu par le concept de XSP (XML Server Pages).

En conclusion, la notion de framework est encore peu connue et utilisée seulement par les programmeurs les plus avancés, ce qui est en quelque sorte paradoxal puisqu’ils seraient les mieux à même de s’en passer. Elle semble néanmoins pleine d’avenir pour améliorer la productivité.