Web­fra­me­works : aperçu et clas­si­fi­ca­tion

Aujourd’hui, toujours plus d’ap­pli­ca­tions de bureau migrent vers le Net. Elles de­vien­nent donc des ap­pli­ca­tions Web dis­po­nibles pour les uti­li­sa­teurs sim­ple­ment depuis leurs na­vi­ga­teurs. Des exemples clas­siques sont les webmails ou browser games. Pour les en­tre­prises, le modèle de licence Software-as-a-Service (SaaS) s’est largement établi. Il existe main­te­nant des ap­pli­ca­tions Web pour gérer sa relation client (CRM), envoyer des news­let­ters, planifier ses projets, manager son personnel ou encore écrire sa comp­ta­bi­lité. Ainsi, les petites en­tre­prises peuvent bé­né­fi­cier de modèles adaptés à leurs besoins et accéder à ces services avec une simple connexion à Internet. Les coûts de main­te­nance et d’ad­mi­nis­tra­tion sont alors minimes et les uti­li­sa­teurs peuvent bé­né­fi­cier d’un maximum de flexi­bi­lité.

Pour le dé­ve­lop­pe­ment d’ap­pli­ca­tions Web, les pro­gram­ma­teurs ont en principe recours à ce que l’on appelle les fra­me­works Web ou WF pour Web framework en anglais. Mais qu’est-ce qu’un framework exac­te­ment ? Et quelle est leur utilité pour les ap­pli­ca­tions Web ?

Sous le terme de framework, on entend une structure qui sert de base pour le dé­ve­lop­pe­ment de logiciels. Pour écrire un nouveau software, commencer tout depuis zéro cons­ti­tue­rait une grande perte de temps. Il existe ainsi des solutions pour mettre en place ra­pi­de­ment des fonctions standard de dé­ve­lop­pe­ment, qui s’appuient sur des codes de pro­gram­ma­tion qui ont fait leurs preuves. En pro­gram­ma­tion orientée objet, les fra­me­works sont composés de classes qui servent de structure de cons­truc­tion pour le dé­ve­lop­pe­ment des objets logiciel. Un framework re­pré­sente dif­fé­rentes classes et constitue ainsi la structure de base de con­cep­tion des logiciels. Si le framework sert de structure de base pour une ap­pli­ca­tion Web, on parle alors de Web ap­pli­ca­tion framework (ou plus court : Web­fra­me­work).

Pour servir de base de dé­ve­lop­pe­ment aux logiciels, les fra­me­works Web doivent mettre à dis­po­si­tion des struc­tures claires et simples, qui per­met­tent aux dé­ve­lop­peurs de mettre en place des ap­pli­ca­tions Web en très peu de temps. Pour être fa­ci­le­ment uti­li­sables, les fra­me­works Web doivent nor­ma­le­ment être basés sur les 3 grands principes de con­cep­tion suivants :

• Don’t repeat yourself (DRY) : le précepte don’t repeat yourself re­com­mande d’éviter les re­don­dances dans le dé­ve­lop­pe­ment de votre logiciel. Les in­for­ma­tions ré­pé­ti­tives, comme les du­pli­ca­tions de codes, doivent être évitées car elles ont un impact négatif sur le fonc­tion­ne­ment général du logiciel. Si des portions de codes re­don­dantes doivent être ajustées, de nom­breuses mo­di­fi­ca­tions vont devoir être ef­fec­tuées à dif­fé­rents endroits du code de pro­gram­ma­tion.
  
  
• Keep it short and simple (KISS): simple et court, c’est le principe de base du paradigme KISS. Il repose sur une logique de par­ci­mo­nie : si plusieurs solutions sont dis­po­nibles pour un objet, c’est l’approche qui comporte le moins d’hy­po­thèses et de variables qui sera choisie. Pour utiliser un framework ou résoudre un problème spé­ci­fique, il est pré­fé­rable d’utiliser le moins de code possible.
  
  
• Con­ven­tion over Con­fi­gu­ra­tion: plus les con­fi­gu­ra­tions sont nom­breuses et plus la prise en main va être la­bo­rieuse. Les con­ven­tions per­met­tent en revanche de minimiser la com­plexité des framework Web. Ces derniers doivent ainsi favoriser des processus qui ont déjà fait leurs preuves avec des pa­ra­mé­trages standard, et proposer en option d’autres pos­si­bi­li­tés de con­fi­gu­ra­tion.

Si ces principes de con­cep­tion sont respectés, les fra­me­works Web vont apporter de nombreux avantages à votre dé­ve­lop­pe­ment logiciel. L’in­tro­duc­tion d’un framework limite toutefois les dé­ve­lop­peurs. Ces limites struc­tu­relles sont parfois perçues comme des in­con­vé­nients. Voici un aperçu des avantages et in­con­vé­nients des Web­fra­me­works.

En adoptant un framework web, les dé­ve­lop­peurs visent avant tout à faire des économies de temps et d’argent. L’idée est ainsi de réu­ti­li­ser des codes. Cela s’appuie sur des fonc­tion­na­li­tés de base comme sur des accès aux banques de données, des templates pour pages Web, des processus de cache ou des fonctions de sécurité, qui sont mis à dis­po­si­tion par le framework sous forme de modules de codes préconçus. De ce fait, il faut investir moins d’effort pour des codes de dé­ve­lop­pe­ment spé­ci­fiques d’une nouvelle ap­pli­ca­tion Web. Les fra­me­works Web étant pour la plupart proposés en tant que logiciels libres gratuits, vous n’aurez pas à compter de frais d’achat.

De plus, les fra­me­works fa­vo­ri­sent la gé­né­ra­tion de codes sources propres. Les parties de pro­grammes dis­po­nibles grâce aux fra­me­works passent pour la plupart par des cycles de dé­ve­lop­pe­ment et sont con­ti­nuel­le­ment op­ti­mi­sées. La com­mu­nauté se compose donc de testeurs et de co-dé­ve­lop­peurs. Pour les projets d’une certaine envergure, les failles de sécurité des nouveaux com­po­sants sont alors ra­pi­de­ment dé­cou­vertes et résolues. S’ensuit en général un échange entre dé­ve­lop­peurs et uti­li­sa­teurs sur les forums, qui est géré en partie par les équipes support.

Sur le Net, on trouve un nombre important de fra­me­works pour le dé­ve­lop­pe­ment Web. Ces derniers se dif­fé­ren­cient gran­de­ment en ce qui concerne leurs principes de con­cep­tion ou la diversité de leurs fonctions. Les fra­me­works Web peuvent donc être très dif­fé­rents d’un four­nis­seur à l’autre. Les dé­ve­lop­peurs se re­trou­vent ainsi face à de grands dilemmes pour trouver la structure adéquate à leur projet. Il est alors né­ces­saire de faire des compromis et d’adapter son projet selon les limites du framework. Les framework étant conçus comme solution uni­ver­selle, les dé­ve­lop­peurs utilisent dans de très rares cas toutes les fonctions de la structure établie. Selon la con­cep­tion du framework, une ap­pli­ca­tion va parfois comporter plus de code que né­ces­saire. On parle alors de co­de­bal­last.

Comme in­con­vé­nient majeur, on note notamment la dé­pen­dance des dé­ve­lop­peurs aux fra­me­works Web choisis, à un four­nis­seur spé­ci­fique ou à la com­mu­nauté de dé­ve­lop­peurs. Suivant les cas, les fra­me­works sont soumis à des con­di­tions de licence spé­ci­fiques. De plus, des problèmes peuvent ap­pa­raître lorsque les pro­gram­ma­tions com­plé­men­taires sont mises en place. Pour que les dé­ve­lop­peurs puissent se fa­mi­lia­ri­ser avec les pos­si­bi­li­tés d’uti­li­sa­tion des pro­grammes et leurs struc­tures, un temps d’adap­ta­tion est parfois né­ces­saire. Ce temps est tout de même à re­la­ti­vi­ser comparé à celui que vous gagnez en utilisant par la suite les fonctions pré­con­çues et les modules de code. Les dé­trac­teurs craignent toutefois que les savoirs de base ne se perdent. En effet, les uti­li­sa­teurs qui pro­gram­ment uni­que­ment à partir de bases fra­me­works se penchent vrai­sem­bla­ble­ment moins sur les langages de pro­gram­ma­tion utilisés.

Les codes sources de la plupart des fra­me­works Web étant ac­ces­sibles librement, chacun a la pos­si­bi­lité de s’en faire une idée. Attention, si pour une en­tre­prise, une ap­pli­ca­tion est dé­ve­lop­pée sur la base de modules de codes ac­ces­sibles de manière libre, l’ap­pli­ca­tion va être plus trans­pa­rente pour les hackers que des ap­pli­ca­tions où le code source n’est pas public. Restez donc vigilants.

Comme tous les fra­me­works en général, les framework d’ap­pli­ca­tion Web utilisent des bi­blio­thèques lo­gi­cielles (libraries) et outils de dé­ve­lop­pe­ment Web. Alors que les bi­blio­thèques mettent sim­ple­ment des fonc­tion­na­li­tés uniques à dis­po­si­tion, un framework peut être considéré comme une structure in­te­rac­tive pour processus stan­dar­di­sés, soit une partie presque complète d’ap­pli­ca­tion.

Les com­po­sants de base d’un framework logiciel utilisent des classes et leurs méthodes associées. Il s’agit ici de blocs de codes qui décrivent les pro­prié­tés des objets de logiciels et leurs com­por­te­ments. Certains de ces com­po­sants sont statiques et non mo­di­fiables. D’autres peuvent être adaptés par les uti­li­sa­teurs, comme avec les méthodes. Vous avez même la pos­si­bi­lité d’ajuster la structure de pro­gram­ma­tion à une mission spé­ci­fique. Pour les com­po­sants flexibles d’un framework, le nom « Hot Spots » s’est imposé. Les parties statiques sont quant à elles nommées « Frozen Spots ».

Les fra­me­works Web pour­sui­vent gé­né­ra­le­ment le concept de l’inversion de contrôle (IoC pour l’anglais Inversion of Control). Il s’appuie sur un principe dit d’Hollywood pour la pro­gram­ma­tion orientée objet, à savoir : « Don’t call us, we call you! » (Ne m‘appelez pas, je vous ap­pel­le­rai »).

Pour sim­pli­fier, l’IoC signifie que la prise en charge de l’exécution du programme ne repose pas sur les com­po­sants qui sont dé­ve­lop­pés et exécutés sur la base du framework, mais sur le framework lui-même. Ce dernier en­tre­prend les fonctions d’un programme principal qui coordonne les flux de contrôle. D’autres com­po­sants, qui sont im­plé­men­tés par les uti­li­sa­teurs dans le framework et ainsi en­re­gis­trés, sont à dis­po­si­tion si besoin. On peut comparer clas­si­que­ment ceci à un casting d’Hollywood : « nous savons main­te­nant qui tu es, et nous re­vien­drons vers toi si besoin ».

Pour pouvoir exécuter la fonction cen­tra­li­sée de pilotage, les fra­me­works Web pré­sen­tent une interface spé­ci­fique qui doit être im­plé­men­tée par tous les com­po­sants mis en place. Grâce à ce principe de con­cep­tion, le framework est en mesure de mouvoir à tout moment les com­po­sants installés et d’installer des méthodes de callback. Ceci permet au framework d’injecter si besoin des in­for­ma­tions aux com­po­sants ou de provoquer un com­por­te­ment spé­ci­fique grâce aux méthodes. Alors que les classes et leurs éléments liés sont bien codés pour les processus clas­siques de dé­ve­lop­pe­ment de logiciel et donc déjà fixes pour la com­pi­la­tion, le concept d’inversion de contrôle d’un logiciel permet de générer des objets dy­na­miques pendant le process.

L’IoC est considéré comme un modèle de con­cep­tion général pour le dé­ve­lop­pe­ment de logiciel. On y trouvera plus spé­ci­fi­que­ment les modèles De­pen­dency Injection (également dit injection de dé­pen­dance) et De­pen­dency Lookup.

La majorité des fra­me­works d’ap­pli­ca­tion Web se base sur un motif d’ar­chi­tec­ture appelé Modèle-vue-con­trô­leur (MVC). Ce dernier vise à une sé­pa­ra­tion stricte de la logique d’ap­pli­ca­tion et de couches de pré­sen­ta­tion et se décompose en trois domaines, à savoir le modèle, la vue et le con­trô­leur.

• Modèle : le modèle est la partie du framework qui comporte les données à afficher, ainsi que la logique d’ap­pli­ca­tion et les règles. Les mo­di­fi­ca­tions que vous souhaitez ef­fec­tuées sont exécutées avec la méthode dédiée.
  
  
• Vue : ce module a pour mission de re­pré­sen­ter les données procurées par le modèle. Ainsi, la vue sollicite le statut du modèle par la méthode et est informée des mo­di­fi­ca­tions. Une autre tâche de la vue est de recevoir les entrées uti­li­sa­teurs (touches, clics de souris) et de les trans­fé­rer au con­trô­leur.
  
  
• Con­trô­leur : le con­trô­leur constitue l’interface entre le modèle et la vue. Il gère ici une ou plusieurs vues, analyse les entrées uti­li­sa­teurs et réagit en con­sé­quence, par exemple en trans­met­tant des données au modèle ou des mo­di­fi­ca­tions à la vue.

Le motif d’ar­chi­tec­ture du MVC cor­res­pond en quelques sortes à un principe d’or­ga­ni­sa­tion de code. La sé­pa­ra­tion des res­pon­sa­bi­li­tés modèles, vues et con­trô­leurs permet de sim­pli­fier les mo­di­fi­ca­tions futures, les ex­ten­sions mais aussi les réu­ti­li­sa­tions de chaque composant. Le temps de pro­gram­ma­tion est ainsi con­si­dé­ra­ble­ment réduit pour adapter par exemple un logiciel à dif­fé­rentes pla­te­formes (Windows, Mac, Linux), car seul le con­trô­leur et l’affichage doivent être ajustés.

Les motifs de con­cep­tion arrivent sous la forme de JSP (Java Server Pages) -Model-2, même pour les Web­fra­me­works basés Java. Ainsi, une page JSP cor­res­pond à la vue, une servlet au con­trô­leur et un Java Bean au modèle.

Le marché pour les ap­pli­ca­tions Web est très varié. Les ap­pli­ca­tions à dis­po­si­tion des uti­li­sa­teurs sur un na­vi­ga­teur se dif­fé­ren­cient selon les domaines et la diversité de leurs fonctions, pas seulement en termes de taille et d’apparence mais aussi au niveau de la con­cep­tion du logiciel. Ceci est dû à la diversité des fra­me­works Web à dis­po­si­tion, car ces derniers s’appuient sur dif­fé­rentes tech­no­lo­gies et dif­fé­rentes approches de con­cep­tion software. Se con­fron­tent les approches mul­ti­pages et monopages, les approches centrées serveur ou client, ou encore les fra­me­works Web basés sur les actions ou sur les com­po­sants.

Les ap­pli­ca­tions à multiples pages reposent sur des pages HTML, qui peuvent en principe être ouvertes en entrant leur URL dans le na­vi­ga­teur, et qui sont liées par des liens hy­per­textes. L’interface uti­li­sa­teur d’une ap­pli­ca­tion monopage repose en revanche sur une seule et unique page HTML, sur laquelle dif­fé­rentes données uti­li­sa­teurs s’affichent. L’URL d’une ap­pli­ca­tion monopage ne change pas au cours de la na­vi­ga­tion.

Le modèle de pro­gram­ma­tion des ap­pli­ca­tions Web clas­siques se réfère à celui du World Wide Web, dont l’ar­chi­tec­ture s’appuie sur l’HyperText Transfer Protocol (HTTP). Si une ap­pli­ca­tion est ouverte par un uti­li­sa­teur, un ou plusieurs serveurs ainsi qu’un programme client (en général un na­vi­ga­teur Web) vont être impliqués. Suivant la manière dont la com­mu­ni­ca­tion entre le serveur et le client est établie, on pourra parler d’ap­pli­ca­tion centrée serveur ou client.

• Orienté client : si au démarrage d’une ap­pli­ca­tion, l’ensemble de l’interface uti­li­sa­teur HTML avec sa logique d’ap­pli­ca­tion est chargé pour le client, on parlera d’ap­pli­ca­tion centrée client. Les mo­di­fi­ca­tions sur l’interface dues aux données uti­li­sa­teurs sont dans ce cas opérées par des langages de pro­gram­ma­tion orientés client comme Ja­vas­cript. L’approche client in­ter­vient dans un premier temps pour le dé­ve­lop­pe­ment d’ap­pli­ca­tions monopages et sont suivies par des fra­me­works Ja­vas­cript comme AngularJS [En savoir plus sur AngularJS sur angularjs.org] (https://angularjs.org/) ou EmberJS [vers le site de EmberJS] (http://emberjs.com/).
  
  
• Orienté serveur : pour les ap­pli­ca­tions côté serveur, la logique d’ap­pli­ca­tion se concentre na­tu­rel­le­ment sur le serveur qui crée l’interface uti­li­sa­teur et la délivre aux clients. Pour les mo­di­fi­ca­tions sur l’interface uti­li­sa­teur, des langages de pro­gram­ma­tion côté serveur sont également à dis­po­si­tion et le dé­ve­lop­pe­ment est en grande partie in­dé­pen­dant des in­cer­ti­tudes côté client. Cette approche est adoptée en principe pour les ap­pli­ca­tions mul­ti­pages pour les­quelles des af­fi­chages de pages dif­fé­rents vont pouvoir être consultés par le serveur si besoin. Une telle con­cep­tion implique certes un temps de char­ge­ment plus long mais réduit les processus sur l’appareil du client. Pour de nom­breuses ap­pli­ca­tions, un transfert de la logique de commande est évité pour des raisons de sécurité. Une approche centrée serveur peut être mise en place avec des fra­me­works tels que Django, Zend et Ruby on Rails.

Une approche de pro­gram­ma­tion centrée serveur in­ter­vient surtout pour les fra­me­works qui sont dé­ve­lop­pés selon des struc­tures mul­ti­pages et des in­ter­faces HTLM clas­siques. L’interface seule est re­pré­sen­tée dans l’ap­pli­ca­tion Web et va naviguer en règle générale sur le browser. Les ap­pli­ca­tions Web de la sorte s’exécutent in­dé­pen­dam­ment du système d’ex­ploi­ta­tion ou du na­vi­ga­teur Web utilisé. La logique de commande sera gérée par le serveur selon le concept requête / réponse HTML classique.

Les ap­pli­ca­tions Web centrées clients sont parfois désignées comme des rich clients ap­pli­ca­tion ou rich internet ap­pli­ca­tion (RIA). Ce type d’ap­pli­ca­tions im­plé­mente les in­ter­faces uti­li­sa­teurs avec la logique d’ap­pli­ca­tion dans le client. L’interface est en principe com­plè­te­ment chargée au lancement. Con­trai­re­ment aux ap­pli­ca­tions Web clas­siques, les serveurs centrés clients per­met­tent de mettre en place certaines pro­prié­tés, telles que la commande Drag & Drop, la dis­po­ni­bi­lité offline et l’accès au disque dur, alors que ces dernières sont plutôt connues des ap­pli­ca­tions de bureau.

Les fra­me­works Web peuvent être classés en deux ca­té­go­ries sur le plan du pilotage. Alors que les fra­me­works basés sur les actions (action-based) s’appuient sur le schéma HTTP requête/réponse, le framework Web basé sur les com­po­sants (component-based) en fait abs­trac­tion. Les fra­me­works basés sur les actions : avec les fra­me­works basés sur les actions, le con­trô­leur sert d’instance centrale, qui accepte les requêtes clients, les valide et envoie une action ap­pro­priée. Pour chaque action possible, un objet logiciel qui comprend la logique d’ap­pli­ca­tion doit être traité au préalable par le dé­ve­lop­peur de l’ap­pli­ca­tion. L’objet provient alors en principe de classes abs­traites. Si l’action est exécutée, le con­trô­leur actualise le modèle de données et transfère le résultat à la vue qui de son côté génère la réponse et l’envoie au client. Les fra­me­works Web basés sur les actions s’appuient fortement sur le modèle MVC et peuvent également être appelés « fra­me­works basés sur les requêtes » du fait de l’in­tro­duc­tion strictes du schéma requête/réponse. On trouvera parmi les plus clas­siques :

• Django
• Ruby on Rails
• Symfony
• Spring MVC
• Co­deIg­ni­ter

Comme les actions possibles d’un framework Web basé sur les actions est défini par le dé­ve­lop­peur même, on parle d’approche white box. Elle procure une grande liberté aux dé­ve­lop­peurs, mais exige toutefois une bonne com­pré­hen­sion des fra­me­works, car les dé­ve­lop­peurs prennent en charge les cons­truc­tions HTML, CSS et Ja­vaS­cript. Fra­me­works Web basés sur les com­po­sants : Con­trai­re­ment à l’approche orientée action, les fra­me­works Web basés sur les com­po­sants sortent du schéma réponse/requête HTTP : l’interface uti­li­sa­teur de l’ap­pli­ca­tion Web est con­si­dé­rée comme un re­grou­pe­ment de com­po­sants. Pour chacun de ces com­po­sants qui sont reliés aux objets logiciels du côté serveur, des réactions précises sont définies pendant le dé­ve­lop­pe­ment de l’ap­pli­ca­tion Web. Elles succèdent à des évé­ne­ments provoqués par une in­te­rac­tion uti­li­sa­teur avec un composant. On parle de ce fait également de Web­fra­me­works orientés évé­ne­ments. Des exemples clas­siques sont :

• Lift 
• Apache Tapestry
• Ja­va­Ser­ver Faces
• Apache Wicket

L’idée de base dans l’approche basée sur les com­po­sants est de grouper les actions ap­pa­ren­tées. Un composant Ac­count­Con­trol­ler re­pré­sente par exemple des actions comme login, logout ou ge­tAc­count. Un objet logiciel peut par con­sé­quent être res­pon­sable de plusieurs actions. Les fra­me­works Web basés sur les com­po­sants proposent en règle générale un grand choix de com­po­sants réu­ti­li­sables, qui dis­si­mu­lent au dé­ve­lop­peur les détails du schéma réponse/requête sous-jacent. On parle alors de Black box. Les web­fra­me­works de ce type sont donc ap­pro­priés aux dé­ve­lop­peurs qui sou­hai­tent s’appuyer dans un premier temps sur des com­po­sants pré­dé­fi­nis. Pour avoir en revanche plus de liberté en HTTP, HTML, CSS et Ja­vaS­cript, un framework Web basé sur les actions est en revanche davantage conseillé.

Les framework ayant une grande influence sur les fonctions et pos­si­bi­li­tés de con­cep­tion de l’ap­pli­ca­tion Web ainsi que sur votre workflow, le choix d’une structure de pro­gram­ma­tion ap­pro­priée va être la première des grandes étapes de votre travail. Cette décision va dépendre de votre projet et de vos con­nais­sances tech­niques.

Il est fon­da­men­tal de poser des questions sur le type d’ap­pli­ca­tion et l’ar­chi­tec­ture que vous souhaitez mettre en place (centré serveur ou client). Ces deux aspects vont avoir un impact direct sur l’uti­li­sa­tion et l’in­tui­ti­vité de votre ap­pli­ca­tion Web pour les uti­li­sa­teurs.

Vos con­nais­sances en langage in­for­ma­tique et la dis­po­ni­bi­lité des in­fras­truc­tures né­ces­saires vont également être à prendre en compte dans votre recherche de framework Web. Pour les langages de pro­gram­ma­tion largement utilisés comme PHP (par exemple Zend, Symfony, CakePHP ou Co­deIg­ni­ter), Java (par exemple Ja­va­Ser­ver Faces ou Apache Wicket) ou Python (par exemple Django), il existe un large choix de web­fra­me­works bien do­cu­men­tés. Quant à Ruby, sa po­pu­la­rité dans le monde de la pro­gram­ma­tion se doit à Ruby on Rails vers lequel de nombreux dé­ve­lop­peurs se sont tournés. Les fra­me­works Web centrés clients utilisent en revanche le plus souvent le langage de script Ja­vaS­cript.

Les dé­ve­lop­peurs, qui ont par le passé programmé dans un premier temps des ap­pli­ca­tions bureau, trouvent souvent le framework orienté action sur le schéma requête/réponse plus complexe qu’un dé­ve­lop­peur Web classique. Dans ce cas, un framework basé com­po­sants peut faciliter leur approche.