mardi 25 mars 2008

Essentiel Java


Non, vous n'êtes pas seul à trouver des limites à l'approche : avec-1-framework-c-est-mieux.

Voyez plutôt cet article sur architectes.it : Une alternative à J2EE

L'idée de Pirmin Lemberger est de définir un label Essentiel Java, qui permet de qualifier le code source d’une application. Ce label donnera l'assurance du respect de principes de simplicité et de sobriété.

Voila quelques excellents arguments qu'il développe :
Envisageons donc la tâche consistant à assimiler un ensemble réaliste de technologies. Pour fixer les idées disons : J2EE + Spring + Hibernate + Struts. A l’évidence cette tâche n’est pas inhumaine mais elle nécessite, même pour une tête bien faite, plusieurs années de pratique quotidienne. On le constate, cette durée excède de loin la durée des dites technologies.

Et :
Loin de simplifier quoi que ce soit, la seule présence d’un framework induit alors un mode de transmission oral du savoir-faire d’un ou deux experts transformés de fait en petits gourous. Mode de transmission qui s’avère souvent redondant, confus et inefficace. Dans ces cas de figure, le travail du concepteur d’une application s’apparente d’avantage à celui d’un archéologue que celui d’un ingénieur.


Enfin :
... la comparaison objective de plusieurs frameworks relève carrément de l’impossible lorsqu’ils sont déjà complexes individuellement. Dans ces conditions un choix rationnel est difficile. Dans le meilleur des cas, des considérations commerciales objectives l’emportent. Plus souvent l’idéologie et le conformisme intellectuel naturel à l’esprit humain prennent le dessus.

Les problèmes évoqués, sont bien là.
Les décideurs ont besoin de répères et les frameworks (tout comme les techno, style XML.. ou les méthodes, style CMMI) les rassurent.
Les créateurs de frameworks ont aussi tout intérêt à diffuser largement leurs idées, pour des raisons commerciales, d'ego, de satisfaction intellectuelle.

Mais au final, quel est le gain réel pour l'utilisateur, en prenant en compte ce qu'il a gagné "en puissance de feu" en retirant le temps passé à apprendre ledit framework?

Concernant l'idée de Pirmin Lemberger, est-ce que l'utilisation d'un label permettra de définir qu'une application est simple et sobre? Je comprends l'idée de définir un sous-ensemble d'API qui seraient dans le périmètre "Essential Java", mais le problème est qu'il est soumis à interprétation. Pour certains (dont je ne fais pas partie), JSF est simple et standard. Pour d'autres, Log4J (dont je fais partie) est simple et non standard.

Où situer la limite?

The beginning is the end is the beginning


A quoi sert le blog noframeworks?

Ce blog veut donner des exemples pratiques sur la pratique et la théorie informatique, à 3 niveaux : analyse, conception et développement. Par exemple, je projette de parler d'analyse du domaine métier, de pattern d'architecture & de conception et des bonnes pratiques de développement.

Ces billets n'engageront que moi, et me permettront de mettre à plat ce que je pense.

Ce que je constate, c'est la fuite en avant de la communauté Java, vers toujours plus d'outillages, toujours plus de frameworks. Ces outils, certes très intéressants, sont complexes à appréhender, fragilise la compréhension du code, puisqu'il ne devient plus explicite, et tend à enfermer le développeur en lui promettant l'inverse.

A l'inverse, vous avez les patterns, qui eux sont connus et stables dans le temps, ou les standards Java qui sont gravés dans le marbre de l'histoire.

La question est : à l'heure actuelle, si je veux faire un développement Java Web, quelle architecture puis-je retenir, qui combinent, simplicité et facilité de maintenance?

Suis-je obligé d'utiliser les Spring, Seam, Struts, Hibernate, GWT, ... pour faire une application de qualité?

Il me semble que la communauté Java souffre d'un excès d'outils, de "modes" (bon, c'est un signe de vitalité, en même temps...) et qu'il serait utile d'apporter des réponses claires, précises et simples, quand cela est possible.

Voila, le but de noframeworks.

jeudi 6 mars 2008

L'architecture à 5 couches

Une pratique répandue dans l'architecture d'une application de gestion, est d'utiliser une solution à 5 couches.

Qu'est-ce qui caractérise une application de gestion ?

Une application de gestion, comme son nom l'indique, doit gérer des données. Ce qui implique l'utilisation d'une base de données (la plupart du temps relationnel). Cela implique également une interface pour permettre à des gestionnaire de voir et modifier ces données.

Tout n'est pas assimilable à une application de gestion. Il y a des besoins d'informatiques embarqués, d'informatiques industriel, des logiciels utilitaires, etc.. Dans ces cas là, le découpage en 5 couches ne s'appliquent pas.

Pourquoi distinguer des couches?

Le but de la conception en général, est d'attribuer des responsabilités. Définir des couches est un moyen de séparer les responsabilités et ainsi, de minimiser l'impact du changement.

Maintenant que l'avertissement est donné, je vais clarifier le rôle de ces 5 couches.



  1. la couche Présentation
    Cette couche est l'apparence visuelle de l'application, telle qu'elle sera perçue par l'utilisateur finale. C'est ici que vous aurez les images, les pages JSP, etc..
  2. la couche Coordination
    Ici vous avez les contrôleurs du pattern MVC. C'est à dire des composants qui interceptent les interactions de l'utilisateur et qui gère la cinématique (ou logique) des écrans.
  3. la couche Service
    La couche Service regroupe tous les services, ou réalisation de cas d'utilisation. L'idée est d'exposer ces services pour différentes applications clientes. On peut retrouver dans cette couche les Web Services d'une architecture SOA ou les service RESTful. On peut également trouver des EJB session, si le SI est en pure Java.
  4. la couche Métier (ou Domaine)
    La couche Métier reprend tous les objets métiers de l'application considérée. C'est ici qu'est portée la logique des règles de gestion sur ces objets. On peut trouver des EJB session, mais non exposés au monde extérieur.
  5. la couche Persistance
    La couche Persistance est la couche qui sert de communicateur avec la base de données. Son avantage est le rôle de sas de sécurité entre l'application et la base de données. Si la structure de données change, seule (en théorie) cette couche est à modifier. On trouve ici des entités persistantes (JPA, Hibernate ou EJB entity).
Chaque couche a seulement la permission d'appeler la couche suivante (ainsi, la couche Présentation, ne peut utiliser/récupérer/instancier/etc.. que des objets de sa propre couche ou de la couche Service, et à l'autre bout, la couche Persistence ne peut utiliser que des objets de sa propre couche)

Les raisons d'être des couches. L'avantage de la couche Métier est que les règles de gestion (RG) sont regroupés à un seul endroit. La couche persistance n'est pas parasitée par ces RG. Elle peut par exemple récupérer une entité en base, et la couche Métier peut la déclarer invalide (si elle casse une RG) et lancer une exception.

L'avantage de la couche Service est qu'elle orchestre l'appel aux objets métiers, nécessaires pour l'accomplissement du service (et donc du cas d'utilisation). De ce fait, elle gère l'aspect transactionnel des choses, c'est à dire l'assurance qu'un service s'effectue en totalité ou pas du tout. C'est donc la couche Service, qui doit demander une connexion à la base de données, et la configurer pour ouvrir (si besoin est) une transaction.

L'avantage de la couche Coordination, est qu'elle orchestre l'appel aux différents services, par le pilotage d'un processus. De ce fait, elle peut elle aussi gérer l'aspect transactionnel mais au niveau inter-applicatifs.

Par exemple, imaginons qu'on ait un service S1, qui fasse un travail d'update sur une base de données B1. Et qu'un service S2, fasse un autre travail d'update sur une base de données B2. Si l'on a une exigence que les 2 bases soient cohérentes l'une par rapport à l'autre, et si jamais une modification sur B2 n'a pas pu avoir lieu, il faudra défaire la modification sur B1.

C'est donc à cette couche Coordination de gérer cela, en détricotant elle-même les modifications antérieures.

Enfin, nous pouvons trouvons une couche Transverse, contenant tous les objets accessibles par l'ensemble des autres couches. Cette couche contiendra des objets valeurs et différentes classes utilitaires (de date, de chaîne de caractères, etc..)