Blog de Beler Ingénierie

Introduction

Les services Web sont devenus, depuis quelque temps, la norme de facto pour intégrer des applications internes ou offrir une interface externe aux clients. Il est plus facile de transmettre des données entre différentes plates-formes en utilisant ce moyen; plus facile de composer le message, plus facile à déboguer, plus facile à comprendre. Ainsi vous pouvez intégrer des parties du système écrites en Java, .NET, PHP etc. en utilisant un protocole bien connu et des messages textes (généralement en XML). Les codages binaires (c’est à dire spécifiques, non-textuels) sont véhiculés plus rapidement, mais elles sont réservées à certaines plateformes. Vous ne pouvez pas utiliser des formats binaires .NET pour communiquer avec une application Java. Voici ce dont il s’agit avec RPC et, plus récemment, avec SOA¹ : l’intégration de modules via des services Web.

Points communs

Les deux protocoles² fonctionnent parfaitement avec HTTP³ , le protocole de transfert de données entre clients et serveurs utilisé sur le Web. HTTP est un protocole simple, bien connu, donc cela peut être considéré comme un avantage : facile à comprendre, implémenté sur la plupart des plateformes, il n’est pas d’habitude bloqué par les pare-feu.

Les messages sont dans le format XML⁴ , un format texte facile à comprendre.

Pourquoi choisir REST ?

REST est léger et simple : les messages sont courts, faciles à décoder par le navigateur et par le serveur d’application.

REST est auto-descriptif) : vous pouvez naviguer à travers ses ressources comme vous le feriez avec une page Web. Il y a une URL intuitive unique pour chaque ressource. On peut facilement en déduire la structure des ressources sans avoir besoin de beaucoup de documentation.

REST est « stateless » (il n’est pas adapté aux transactions longues et complexes) : il est parfait pour les opérations simples (créer, lire, mettre à jour, effacer).

REST peut être géré en cache (antémémoire) : les ressources simples, identifiables sont aussi faciles à mettre en cache qu’un article sur un site Internet. L’adaptation aux variations de charge et la performance que cela apporte ne doivent pas être négligées.

Pourquoi ne pas choisir REST ?

REST est généralement critiqué pour son manque de complexité exigée pour les transactions d’affaires : sécurité, support transactionnel.

REST est considéré en quelque sorte comme un artifice du « web 2.0″ plutôt qu’une vraie solution d’entreprise.

Pourquoi choisir SOAP ?

SOAP a été conçu comme un mécanisme d’appel de procédure distante. On utilisera SOAP en toute confiance pour appeler une méthode sur un autre serveur et recevoir la réponse dans un mode contractuel.

SOAP supporte le transactionnel : il supporte les transactions ACID, de sorte qu’il peut gérer un commit à deux phases sur des ressources transactionnelles distribuées (WS – Atomic Transactions ).

SOAP a quelques caractéristiques de sécurité supplémentaires : il supporte l’identification à travers des intermédiaires, plus que SSL ne peut offrir.⁵

SOAP est formel : les méthodes à distances et leurs résultats sont bien spécifiées via des contrats.

SOAP est fiable : il dispose des mécanismes pour garantir la fiabilité de la transmission et de la réception de données.

SOAP offre de nombreux outils : étant donné qu’il a d’abord été publié par Microsoft en 1998, beaucoup de fournisseurs ont créé des outils au fil des années. Aussi la plupart des plates-formes de développement sont pourvues d’un moyen facile d’exploiter une fonction distante via SOAP.

Pourquoi ne pas choisir SOAP ?

SOAP a été à l’origine imaginé pour faire un protocole RPC qui passe les pare-feu (remplaçant donc le DCOM de Microsoft avec XML sur HTTP).

SOAP est considéré trop complexe et verbeux pour les besoins ordinaires.

SOAP est d’habitude utilisé dans des framework propriétaires. Bien que cela fournisse un point d’entrée apparemment plus facile (quelquefois basé sur un assistant) pour créer des services Web, sa complexité rend ardu le débogage des messages, donc tout l’avantage du XML lisible par l’utilisateur est perdu assez vite.

SOAP nécessite une compréhension claire des APIs spécifiques au site. Son utilisation est comparable à l’utilisation d’un nouveau framework. Il demande du temps et de la documentation.

L’interopérabilité de SOAP a diminuée au fil des années, avec des normes différentes et les implémentations des fournisseurs de logiciels. Désormais il est certain que REST est de loin plus interopérable.

Dernières réflexions

Il est généralement admis que l’objectif de SOAP était seulement d’aller à mi-chemin dans l’utilisation du Web comme un modèle pour la distribution de données : protocole HTTP et format XML. REST a poursuivi le chemin en ajoutant le dernier élément qui manquait à SOAP : le simple et efficace schéma d’adressage URL au sein de l’espace de nommage global du Web. N’importe qui sachant utiliser le Web peut utiliser REST. C’est aussi simple que cela.

Une tendance claire dans l’industrie est l’augmentation des APIs REST (les géants du Web, Yahoo, Google, Amazone et eBay offrent à leurs clients des APIs REST). SOAP a commencé à s’effondrer sous son propre poids et restera probablement comme une solution réservée à certains scénarios d’entreprises spécifiques (tels que les transactions bancaires).

Beaucoup de caractéristiques pour lesquelles SOAP est préféré existent en fait dans REST (bien que cela prenne un peu plus d’effort initial pour les mettre en oeuvre) : la sécurité via HTTPS, l’authentification via basic auth, les sessions via les cookies. Cependant, jusqu’à ce que ces besoins et leurs solutions deviennent bien connus et faciles à aborder par les développeurs, SOAP aura sans aucun doute sa place.

Dans la plupart des scénarios, REST est la voie à prendre. Considérez seulement SOAP si vous avez besoin (ou si vous croyez que vous avez besoin) de certaines fonctions WS-* spécifiques (transactions distribuées, fédération d’identification, routage de message).

---

¹ Il y a une différence subtile: alors que RPC traite de l’appel de fonctions distantes, SOAP s’occupe plutôt de transférer des messages.

² Techniquement, REST est seulement une architecture, pas réellement un protocole alors que SOAP est un Framework de protocole, plutôt qu’un protocole concret.

³ SOAP peut travailler aussi sur d’autres protocoles, tels que SMTP, bien que ce soit rarement vu en pratique. REST fonctionne seulement sur HTTP.

⁴ REST n’est pas limité à XML: beaucoup d’implémentations utilisent JSON, un format encore plus léger, moins verbeux.

⁵ Bien qu’Open ID devienne une alternative pour la fédération d’identification dans le monde de REST.

Séparer les problématiques : intêret principal du développement 3-tiers

Pourquoi ? Parce qu’il est plus facile de gérer le développement d’un grand projet en divisant l’application en modules; et donc une équipe de développeurs en sous-équipes, chacune se voyant confier la responsabilité d’un module de l’application.

On peut se passer de cette organisation dans le cadre de petites applications. En revanche, les applications moyennes ou importantes sont pratiquement impossibles à gérer sans appliquer des règles claires.

Avec le temps, on a vu émerger certaines tendances adoptées par l’industrie et dont le but est précisément de gérer la complexité au sein des applications ASP.NET. Mais l’architecture et le développement d’applications ASP.NET modernes et professionnelles ne peuvent être menés à bien sans utiliser les expériences accumulées au fil du temps par la communauté.

WCSF (Web Client Software Factory) : l’alternative

Microsoft a monté une équipe dédiée à la création de modèles pour les architectes d’applications et les développeurs. Le groupe Modèles et Méthodes fournit à la communauté des développeurs ASP.NET professionnels deux frameworks qui capitalisent des années d’expérience des meilleures sociétés de développement au niveau mondial : La Web Client Software Factory (WCSF) et l’Enterprise Library. La façon dont ces deux librairies s’utilisent dans une conception 3-tiers dépend du type de projet. Elles sont en fait complémentaires au modèle 3-tiers, et participent à la tendance actuelle de dépasser une approche purement 3-tiers, vu que la logique d’interface devient de plus en plus encombrée.

Web Client Software Factory propose une alternative à l’organisation induite par ASP.NET MVC, sur les aspects de la testabilité et de la séparation approfondie des problématiques. En prenant en considération le classique ASP.NET (WebForms), on peut parvenir à une modularité raisonnable, en suivant les modèles WCSF, surtout pour les sites Web transactionnels métier (à l’opposé de MVC qui convient mieux aux sites Web orientés contenu).

Le point majeur de la technologie ASP.NET MVC est le concept Model View Controller : il permet de diviser l’interface utilisateur en modules à l’intérieur de couches logiques, supprimant ainsi les fichiers source d’interface utilisateur volumineux, caractéristiques des projets ASP.NET classiques et connus pour la lourdeur de leur maintenance.

Bien que cela ne soit pas aussi simple qu’ASP.NET MVC, l’utilisation du classique ASP.NET conjointement au modèle MVP (Model View Presenter) présente beaucoup d’avantages qui ne doivent pas être négligés pour les projets importants.

S’ils conjuguent cet atelier et leur savoir, les développeurs professionnels ASP.NET en entreprise n’ont plus d’excuse si l’organisation de leurs projets présente des failles : finies les interfaces utilisateurs lourdes, compliquées (où l’essentiel de la logique est intégrée aux fichiers cachés derrière le code des pages aspx) !

C’est ainsi que les efforts faits au début pour structurer le code source deviendront payants : il est désormais possible d’avoir une base de code gérable, comprise par tous les nouveaux développeurs qui viendront rejoindre l’équipe. Elle assure également la cohérence entre projets, où chaque application reposera sur un socle commun.

Comment est-ce lié au 3-tiers ?

3 tiers et MVP (Model View Presenter) sont des modèles complémentaires que l’on retrouve ensemble dans la plupart des projets ASP.NET. Pour obtenir une idée de MVP, voici une cartographie des objectifs des modules dans trois architectures ; 3 tiers physique, 3 tiers logique (du point de vue de l’application) et MVP (le modèle utilisé dans WCSF).

Attention : ce tableau est simplifié à l’extrême afin d’avoir une idée simple du fonctionnement 3-tiers.

Enterprise Library : pour suivre les best practices

Au-delà de la simple séparation de modules en composants 3 tiers, il existe également un autre besoin.
L’autre outil incroyablement utile pour organiser les aspects de l’application réside dans l’utilisation des blocs applicatifs standards offerts par Microsoft. L’équipe Patterns et Practices a mis au point la 5ème version de la librairie destinée au développement des applications d’entreprise sous Windows : Enterprise Library. Ainsi, la couche métier et la couche d’accès à la base de données (les niveaux 2 et 3 de l’architecture 3 tiers) suivent solidement les bonnes pratiques de l’industrie pour que rien ne soit laissé sans surveillance. En outre, la « plomberie » de chaque application peut être développée de manière standard et appropriée, en utilisant les autres blocs :

• Le bloc de cache qui optimise le temps de réponse en gérant les données les plus souvent utilisées, pour diminuer les pics de trafic de la base de données
• Le bloc de cryptographie, qui gère efficacement le cryptage des informations sensibles
• Le bloc de journalisation qui aide les développeurs et les équipes IT lors des diagnostics
• Le bloc de validation, la manière commune pour créer et utiliser des règles de validation pour les objets métiers.

Il existe également des blocs, spécialisés pour les architectures et les scénarios professionnels : Unity for DI (Dependency Injection)/IoC (Inversion of Control), Policy Injection for AOP (Aspect Oriented Programming – implémentant des notions transverses – sécurité, cache, journalisation – dans toute l’application).
Ces blocs agissent comme des plugin : ils peuvent être configurés, remplacés, modifiés en fonction des scénarios métiers envisagés par le client et l’équipe de développement.

Conclusion

ASP.NET 4.0, conjointement à Visual Studio 2010 et au framework .NET 4.0 bénéficient des dernières versions, modernisées du groupe Modèles et Méthodes de Microsoft. En tirant parti de ces solutions, les équipes de développeurs seront sûres de suivre les meilleures pratiques de l’industrie lors du développement d’applications Web structurées, évolutives, et faciles à maintenir.

Beler Ingénierie : ne pas laisser de place au hasard.
Les développeurs de Beler essaient en permanence d’améliorer leurs connaissances autour des dernières technologies. C’est d’autant plus important que les architectures et les tendances s’empilent au gré des itérations des nombreuses technologies applicatives.

Les jeux sont faits !

Le W3C a tranché : il existe enfin un standard, et même un bon, pour le Web, le HTML 5.

Il y a de plus en plus de normes dans tous les domaines : des pneus automobiles jusqu’aux chargeurs de téléphones portables. Il eût été dommage que le développement échappe à cette tendance : voila des années que la communauté des développeurs demandait une normalisation pour l’affichage des pages Web.
Mais face à l’explosion de l’Internet, les géants de l’édition ont toujours essayé d’imposer leur interprétation du HTML, espérant ainsi rallier le maximum d’internautes à leur navigateur et surtout donner l’impression qu’il s’agissait du meilleur possible.

Les différences entre les navigateurs, telles que l’alignement des éléments, l’ordre d’affichage des objets superposés, le déclenchement des évènements… transformaient parfois la programmation Web en cauchemar : « Ça marche un IE 8 et pas sur Firefox !?». Résultat : duplication de code, fonctions spécifiques selon les navigateurs cibles, avec les temps et les coûts associés.

Ces jours-ci, plus de 15 ans après sa création, le consortium W3C a établi deux dates clés : mai 2011 «the last Call » et juillet 2014, la recommandation officielle du langage, pour tous les dispositifs, systèmes d’exploitation et navigateur. Même si 2014 peut paraître encore éloigné, on peut examiner la réaction impressionnante des géants du marché.

Les géants s’adaptent : HTML 5 est de toutes les releases

Déjà en 2010, Google avait sorti plus de cinq versions de Chrome autour de HTML 5 culminant avec la version 10 du 8 mars 2011, qui intègre deux petits jeux sympatiques en HTML 5.

Le 14 mars 2011, Microsoft a officiellement lancé Internet Explorer 9, avec d’importantes améliorations sur les performances Java Script, le rendu des pages et surtout, sur la compatibilité et les performances en HTML 5.

Quelques jours après, Mozilla sort la version 4.0 de son Firefox (avec HTML 5 évidement !) qui fait exploser les compteurs : 40 millions de téléchargements dans moins d’une semaine.
Conclusion : cette fois, on a bien un standard et c’est HTML 5.

HTML 5 : au-delà du standard, des nouveautés très intéressantes

- Support natif audio / vidéo par des tags spécifiques
- Stockage local des données (localStorage) : plus facile a utiliser et plus rapide que les cookies !
- HTML5 Embedded SQLite Database (aussi connu sous le nom de Web SQL Database) : ou comment manipuler des données comme dans un SQL classique à partir de JavaScript !
- Les CANVAS, pour designer à volonté : des points, des lignes, des graphiques, transformer et manipuler des images directement dans le code HTML/JavaScript (Attention Flash et Silverlight !)

Toutes ces nouvelles fonctionnalités donnent la possibilité de créer de véritables applications en HTML 5, qui fonctionnent même en mode offline.
Chez Beler nous avons déjà développé des Web app pour iPhone en HTML 5 dans le domaine médical, dont une dédiée au suivi d’une pathologie rare. L’intêret est que le même code tourne sur iPhone (Web App) et peut être accédé depuis le serveur par d’autres smartphones via leur navigateur. Les mises à jour sur les évolutions des critères de diagnostic sont immédiates et ne font pas l’objet d’une nouvelle version sur l’App Store.

HTML 5 serait-il donc le gagnant face à Flash et Silverlight ?

En effet, pourquoi encore installer un add-on alors que le browser lui-même est devenu suffisamment puissant pour faire le travail ? Même si cela parait tout-à-fait possible, l’affirmation semble prématurée. D’autant qu’Apple refuse catégoriquement d’intégrer le support de Flash/Silverlight  sur les iPhone/iPad, alors que HTML 5 est déjà géré par Safari.

Et la communauté .NET ?
Elle a aussi réagi très rapidement pour ne pas manquer ce rendez-vous avec HTML 5 : avec Visual Studio 2010/2008 équipé de l’outil HTML 5 Intellisense, on dispose avec  .NET 4 Framework et le ASP.NET MVC HTML5 Toolkit, d’une très bonne trousse à outils pour créer des applications Web puissantes, robustes et riches.

Alors lançez-vous en HTML 5 !

Ca y est, votre entreprise veut créer son prochain produit pour navigateurs et vos développeurs vous affirment dans un premier temps «On devrait utiliser ASP.NET» pour vous asséner ensuite «non plutôt MVC». >

Sachant que les deux solutions sont des technologies .NET publiées non moins toutes les deux par Microsoft, c’en est à se demander si la question est légitime : est-ce qu’on ne devrait pas simplement utiliser celle dont on peut tirer le meilleur parti chaque fois que c’est possible ?

Pourquoi utiliser Web Forms ?

ASP.NET Web Forms est livré avec .NET, et pratiquement tout le monde l’appelle, à juste titre, ASP.NET.
Contrairement à l’ASP classique il est composé de contrôles, et il imite le développement Windows Forms. Avec tous ses avantages et ses inconvénients.

Vous pouvez concevoir votre application comme une application bureautique événementielle et dynamique, et vous le ferez rapidement en utilisant les contrôles existant ou en intégrant ceux des parties tierces.
ASP.NET est recommandé pour les applications professionnelles traitant des volumes important de données, car vous passerez l’essentiel de votre temps à coder en C# ou en VB.NET côté serveur, développement qui n’exige pas de peaufinage en Javascript.

ASP.NET Web Forms convient donc très bien, pour la migration d’applications bureautiques en mode saas.

Inconvénients : perte de contrôle et abstractions

La perte de contrôle sur l’affichage du code HTML a pour conséquence un support médiocre des standards à venir (par exemple, des balises dégradées en HTML 5 seraient toujours affichées par les contrôles existants), et l’existence de contrôles dans les pages peut rebuter certains concepteurs de sites web.

L’abstraction dynamique impliquant une baisse de performance (des volumes importants Viewstate transférés entre le client et le serveur à chaque clic), ces applications conviennent mieux aux développements Intranet. Si vous ne le souhaitez pas, il vous faudra travailler activement autour de Viewstate.

L’abstraction « événementielle » induit qu’il y a peu de chance de trouver, sur votre page web, des éléments à mettre en favoris (des éléments possédant leur propre URL), et si c’est le cas, l’URL peut ne pas fonctionner plus tard en cas de perte de son état dynamique.

Et ASP.NET MVC ?

ASP.NET MVC (Modèle Vue Controleur) n’est pas le premier framework pour ASP.NET [1] et il est la preuve qu’ASP.NET est une plate-forme très extensible. Il est cependant le seul qui soit intégralement supporté par Microsoft, intégré dans Visual Studio.

Model-View-Controller est le nom d’un modèle logiciel utilisé pour les développements d’interfaces graphiques, capable d’analyser très convenablement le modèle requête/réponse passif HTTP.

Pourquoi utiliser ASP.NET MVC ?

Les URL : Vous pouvez démarrer le site en concevant des URL optimisées pour les moteurs de recherche, sans extension et non liées à la manière dont vos fichiers sont stockés sur le serveur. Elles peuvent servir de signets, à moins que vous vous y opposiez de manière active.

Les Vues : Elles sont beaucoup plus faciles à concevoir car elles ne contiennent aucune référence à des contrôles (pas de balises cachées).

En même temps que les vues faciles à concevoir, vous pouvez choisir votre framework Javascript : Microsoft Ajax, jQuery ou tout autre framework maitrisé par vos développeurs. Vous avez les mains libres.

C’est pourquoi MVC parait être le meilleur choix pour les sites Internet grand public qui ne contiennent pas des formulaires importants à traiter avec des règles métier, ou qui ne demandent pas d’analyser, trier et filtrer des jeux de données.

Inconvénients : code à écrire et absence de contrôles

Pouvoir utiliser tout type de framework Javascript signifie qu’en fait aucun n’est intégré : il vous faudra écrire du code, ce qui vous prendra plus de temps.

Ne pas posséder de notion de « contrôles » signifie également qu’il vous faudra plus de temps pour développer une application événementielle. Dans ce cas, Web Forms est un meilleur choix.

Conclusion

Etudiez les deux, utilisez celui qui conviendra le mieux !

[1] http://www.castleproject.org/monorail/
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks