Architecture java contre framework légers

Quand on voit la pile complète d'une application Java standard hébergée par un framework MVC, on peut à juste titre être tenté de qualifier ce montage d'usine à gaz ou encore mieux de Rube Goldberg machine.


(Détails )




Or il n'en est rien de tout ca. Chaque couche a sa justification. Un spécialiste JEE arriverait facilement à faire la démonstration du bien fondé de cet échafaudage : ET IL AURAIT RAISON. Le langage JAVA n'est pas pire qu'un autre : il reprend les lignes directrices du C++ à son compte.
Java et JEE mettent en pratique chacun à leur façon cette formule: diviser pour résoudre.
En java: diviser en objet pour résoudre le problème.
En JEE: diviser en couche pour assurer l'indépendance des parties clientes, web métier et données.
Avec un système comme ca, tout le monde trouve son compte:

Les vendeurs de serveur : ce n'est pas pour rien si c'est un fabriquant de serveur qui à eu l'idée de promouvoir ce modèle.

Les sociétés de service : une tel architecture justifie des ressources en nombre, des experts par couche. Cest aussi la certitude de trouver des developpeurs et de banaliser les ressources.

Les informaticiens: une filière reconnue, normée favorise la fluidité du marché du travail dans ce domaine. C'est un confort , une assurance pour un bon déroulement de carrière.

Les DSI: ils ont le sentiment de faire des choix 'raisonnables' , d'investir dans des techniques sures,pérennes et évolutives. Une filière technologique unique , étoffée par un ecosystème fort et couvrant tout le cycle de vie du logiciel.

Avec une telle armada, java aurait du être hégémonique vis à vis des autres langages.
Il n'y a rien de mieux que JEE pour réaliser de manière industrielle des applications métiers traditionnelles.

Alors pourquoi aller contre cette évidence ?.

Le principal reproche à l'ensemble Java/JEE est le coût global d'un projet. Une application est forcement 'lourde' en terme de ressources machines et humaines.

Les développeurs JAVA.

Dans la réalité les développeurs Java ne sont pas aussi interchangeables et banalisés que çà. Le cycle de formation d'un développeur Java est au moins deux fois plus long que celui d'une autre filière (6 mois PHP , 1 an pour le Cobol 2 ans pour le Java/JEE). Avec une remise à niveau tous les 3 ans. La tentation est alors grande de rogner sur le cursus de formation.
Un poste d'architecte applicatif est nécessaire avec un découpage en couche complexifié par le morcellement de l'approche objet. Or les personnes capables de maitriser toute la pile du système et l'architecture globale d'un projet sont très rares et donc chères .
Un investissement dans une équipe complète de développement Java/JEE ne se justifie vraiment que pour des industriels du logiciel. Quel est votre métier: fabriquer du logiciel ou fabriquer des voitures , vendre des aspirateurs ? .

Les applicatifs à produire.

Les applicatifs issus de cette filière se prête mal aux nouvelles contraintes :
Temps de réalisation court pour éviter l'effet tunnel.
Dans l'industrie automobile le temps entre la prise de décision de lancer un nouveau modèle et la sortie du véhicule des chaines doit être le plus court possible. Dans un projet informatique, cette contrainte est identique.
Les 'clients' élaborent des spécifications qui vont fixer les besoins à un instant donné. Hélas, ces besoins évoluent, les donneurs d'ordre vont avoir tendance à anticiper cette évolutions dans l'expression de leurs besoins . Seule une approche itérative avec un cycle court et une mise ne production rapide par 'morceaux' est capable de répondre correctement à ces besoins.

Explosion du volume de données.

L'idée de traiter massivement ses données par un seul serveur est obsolète. La parallélisation est devenue une nécessité. Dans ce mode de traitement, la communication inter-processus , le style de programmation et le traitement des erreurs sont stratégiques. Or Java n'est le langage le mieux adapté pour cela. Plutôt que de faire évoluer Java, les experts préfèrent redessiner un langage à partir de java et de sa très bonne JVM : le SCALA (utilisé par twitter) .

Passage au web 2.0

Pour l'avenir, les développeurs Java......script seront des ressources demandées. Avec javascript, les applications métiers en web surclassent les applications lourdes. Jquery, prototype ou script.aculo.us sont des librairies qu'il faut connaitre. Javascript, et un framework léger (Rails , symphony etc ) sont largement suffisants pour répondre aux besoins de nos utilisateurs.

Un jeune doit il se former à java ou basculer directement vers d'autres technologies ? . La bonne stratégie est de sortir des sentiers battus et de ne pas faire comme tout le monde. Pour une raison bien simple , il sera confronté un jour ou l'autre au java et sa culture alternative sera un plus. d'autant que l'approche MVC par un framework léger permet par la suite d'appréhender plus facilement des architectures complexes.

Demain il y aura trop de developpeurs Java, dans des pays divers et à des prix cassés. en revanche , les architecte-maquetteurs ( développement Agile) seront les rois du marché.

Un autre framework #ruby : #padrino-framework

Padrino est un framework qui comble le vide entre Sinatra qui est un microframework et Rails qui est la solution complète de framework.
(ici le site Padrino)
Padrino s'appuie sur une architecture Sinatra (post ici:http://germanlinux.blogspot.com/2010/01/interface-sinatra-en-ruby-pour-twitter.html) . Ce qui est réalisé conventionnellement avec Rails (route,controleur) est ici à prevoir par le développeur.
Les points forts de Padrino :
* Il est multi-application : il est facile de 'monter' une application dans une arborescence. Un gros projet est découpé en sou- ensembles, qui seront agrégés dans Padrino.
* Il fournit des générateurs pour des taches d'administrations simples, incluant l'authentification des utilisateurs.

Pour suivre Padrino sur twitter.

#Rango en #ruby pour singer django

Rango est un autre framework applicatif en Ruby. Il se situe entre Sinatra qui est le framework ultralight en Ruby et rails qui est LE framework complet. Comme Sinatra,il utilise la couche Rack pour le serveur WEB. Son originalité vient du fait qu'il utilise les concepts de DJANGO le framework en Python.
Ainsi dans l'univers Rails l'architecture MVC se traduit par Modèle Vue et Contrôleur (et le modèle au modèle). En Rango comme en Django , la vue correspond au Template , le contrôleur à la vue.
Rango implémente des templates et l'héritage des templates. Il dispose de générateurs ou des modèles de comportement. Ainsi, comme avec Django, il est très facile de developper une application qui necessite une vision utilisateur et une vision administrateur de site.

Clic pour élargir

Modèle SOA vs ROA

Deux mondes s'affrontent : d'un coté l'informatique en Entreprise de l'autre l'informatique d'Internet destinée à l'utilisateur final.
La frontière n'est pas étanche ,et parfois des technologies se diffuse de part et d'autre, comme par exemple le web 1.0 et les services de messagerie.

Ce schémas illustre mon propos:





Il y a quelques années , le modèle SOA (AOS) était vu comme le modèle qui répondait au mieux au mouvement de la général de mondialisation (globalisation - restructuration ) . Une entreprise X rachetait une entreprise Y , elle devait pouvoir intégrer le système d'information de Y à moindre coût.
Dans un monde SOA , le service informatique 'rentre dans le rang' , il ne dicte plus ses lois (organisation, processus ) au reste des services.
Hélas les retours sur investissement est long ,difficile et hasardeux.

De l'autre coté du fossé , on trouve un autre monde en perpétuelle agitation avec des effets de mode, des coups de poker. Internet est massivement orienté 'ressources' (uri/url ). Plus le système est léger mieux c'est ! (KISS : Keep It Simple and Stupid).

On trouve donc deux philosophie : une prônant les services ,l'autre les ressources :



L'émergence des frameworks légers (en complexité pas en fonctionnalité offerte) comme Rails ou Django dans un premier temps sur Internet et maintenant dans l'entreprise est un signe fort qui n'est pas neutre dans le choix des statégies à mettre en place.
Les applications RestFull (à base de CRUD , AJAX ) sont les seules à pouvoir offrir à l'entreprise un ROI rapide et sûr. Elles evitent les effets tunnel d'un projet qui sera terminer et qu'il faudra immediatement modifier pour plaquer aux évolutions. Les entreprises doivent se préparer à la vague déferlante du WEB 2.0 dans l'entreprise et commencer à se familiariser avec le SAAS (cloud) qui est massivement SAAR (R comme ressource) .
(ici un comparatif Rails/django ). La cote de popularité des langages illustre mes propos : Javascript à le vent en poupe , ainsi que Python , Ruby et PHP (qui n'a pas encore son killer framework ), alors que JAVA piétine voir le The TIOBE Programming Community index.