Développer un projet aujourd’hui : Architecture et découpage (2/9)

  • Article

 

Stéphanie Hertrich

Article par Stéphanie Hertrich

Mon rôle est d'animer les relations techniques avec le public développeur. Autrement dit, de renforcer, clarifier, l'accès aux nouvelles technologies de développement par les développeurs et équipes projet.

J'ai une expérience métier de 13 ans dans l'édition de logiciels pour des sociétés industrielles proches de l'informatique embarquée. De par mon profil développeur .Net et chef de projet, j'ai longtemps fait partie de l'audience typique des événements MS.
Ma fonction chez Microsoft me permet de rester au plus près des aspects technique et développement qui me tiennent à cœur. J'aborderai des sujets aussi variés que Sharepoint (côté dev), WPF, WCF, MEF, … au gré de l’actualité et des sujets que j’affectionne.

Retrouvez-moi sur mon blog ainsi qu’en session aux MS Days, TechDays et autres rencontres palpitantes..

 

Dépassé par les technos ? Pas le temps de faire de veille ? Trop de boulot pour passer du temps à vous former sur ce qui ne vous concerne pas directement ?
Un nouveau projet à démarrer ?

Et quand bien même vous décideriez de remettre le pied à l’étrier et rattraper le temps perdu, par où allez-vous commencer ?
Creuser les technos une à une, sans savoir vraiment comment elles se positionnent dans le cadre d’un projet concret…avouons que c’est assez décourageant.

Cette suite d’articles se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret.
Notre prétexte métier est un projet de gestion de cave à vins, avec des applications pour le poste de travail et pour Windows Phone.
Retrouvez la description du besoin dans le premier article de la série.

Articles:

  1. Développer un projet aujourd’hui : comment faire, par où commencer ?
  2. Architecture et découpage du projet
  3. Le Stockage des données
  4. La publication des données
  5. Les services métier
  6. L’application Windows Phone basique
  7. L’application Silverlight
  8. Ajout de la fonction d’aide à l’achat
  9. Ajout des notifications sur les vins en promotions

Une série de tutoriels accompagnera ces articles pour mettre en place la solution from scratch.

Sommaire de l'article

  • Les cas d’utilisation
  • Architecture
    • Les applications clientes
    • L’accès aux données
    • Cas d’utilisation et services métier
    • Notifications des vins en promotion
  • Hébergement des données, des services et des applications
  • Récapitulatif

 

Les cas d’utilisation

A ce stade, nous pouvons en tirer le schéma suivant, qui reste plus fonctionnel que technique:

Affinons quelque peu ce besoin en nous intéressant aux cas d’utilisation des applications :

La gestion de sa cave à vins (ajouter/supprimer une bouteille/choisir une bouteille dans sa cave) se fera plus naturellement à partir du téléphone, tout simplement parce qu’on l’a toujours sous la main : pas besoin de démarrer la machine, ouvrir une session, démarrer l’application…soyons honnêtes, une cave à vins sur une application PC sera rarement à jour. De plus, l’ajout d’une bouteille dans la cave se fait en prenant la bouteille en photo, donc encore une fois avec le téléphone.
De la même manière, les notifications de promotions sont pertinentes sur le téléphone, puisque c’est bien lorsque l’on part faire ses courses que l’on a envie de connaitre les promotions du moment.
A l’inverse, le grand écran de notre poste de travail sera très pratique pour se balader dans le catalogue complet des vins et visualiser une grande quantité de données selon des critères et des filtres que l’on aura précisé.

Dans un premier temps, nous répartissons donc nos cas d’utilisations entre les 2 plateformes, de la manière suivante :

Avec Visual Studio 2010 Ultimate, vous avez la possibilité de créer des diagrammes d’architecture, bien pratiques pour la gestion et la documentation de votre projet.
A ce stade, il est recommandé de faire un diagramme de Use Case (disponible aussi dans la version Premium de Visual Studio) qui reste très général. Le but est de garder une trace des fonctionnalités principales de chacune des applications, qui pourront être complétées par des use cases plus détaillés au fil de l’analyse.
Cela permet également de se poser les bonnes questions !
Ici par-exemple, le vendeur de vin va pouvoir lancer des campagnes de promotions, mais…nous n’avions pas prévu de composant permettant au vendeur d’interagir avec le système…
Ce genre d’oubli arrive assez fréquemment, et les diagrammes de use cases sont l’occasion de clarifier le besoin et les différents éléments du système, en accord avec le marketing ou le client.
C’est d’autant plus important de ne rien oublier, que l’on doit commencer souvent bien vite (trop vite) à plancher sur un chiffrage .

Nous ajoutons donc un élément du système en charge de la gestion des promotions : Promotions Service.

Maintenant que le besoin est identifié, voyons comment architecturer notre développement.

Architecture

Les applications clientes

Nous avons besoin d’évaluer les possibilités en terme de technologie pour le développement des applications.
Plusieurs technologies pourraient potentiellement répondre à mon besoin:

  • WPF
  • Silverlight
  • Html5

WPF

J’élimine immédiatement WPF car cette techno présente plusieurs inconvénients dans notre cas:

  • Je ne peux pas développer en WPF sur Windows Phone, donc cette techno serait réservée à l’application PC.
  • Comme notre application est publique, il vaut mieux partir sur une technologie web, c’est à dire une application qui ne nécessite pas d’installation spécifique et qui s’exécutera dans un navigateur. Ce n’est pas le cas de WPF pour lequel il faut prévoir une procédure de déploiement (jeu d’installation).

Un gros avantage d’une technologie web, est que les mises à jour successives de l’application sont transparentes pour l’utilisateur. Dans le cas d’une application lourde, il faudrait notifier les utilisateurs à chaque nouvelle version, pour qu’ils réinstallent l’application (quoique cette procédure peut être allégée si on utilise des mécanismes tels que ClickOnce).
WPF reste une technologie de choix pour le développement d’applications d’entreprise, qui pourront bénéficier du maximum de fonctionnalités avec un accès complet à .Net et aux périphériques locaux.

Silverlight

Avec Silverlight 5, on atteint un bon compromis fonctionnel et technique grâce à une technologie web qui se rapproche de plus en plus de WPF : mode out of browser, accès aux API non managées par P/Invoke, mode plein écran, accès aux ressources locales de la machine et au disque dur pour les applications signées…
Silverlight fonctionne dans les principaux navigateurs (IE, Safari, Firefox, Chrome) et tourne aussi sur Mac.
Sur Windows Phone, Silverlight est la techno de développement la plus adaptée pour les applications et permet donc de mettre à contribution les mêmes connaissances sur les 2 plateformes.
Avec Mango – la nouvelle version de Windows Phone disponible à l’automne 2011 -, c’est la version 4 de Silverlight qui sera disponible. (Elle prend mieux en charge certains éléments dont nous aurons besoin comme le client WCF Data Services pour l’accès aux données).

Html5

Html5 apporte quant à lui la facilité de déploiement sur des plateformes hétérogènes et donc une excellente portabilité. Malheureusement, cette technologie pêche encore grandement par son manque d’outillage. Ses spécifications ne sont pas encore finalisées et si les plateformes clientes sont adressées facilement, c’est bien la compatibilité de l’application avec les différents navigateurs qu’il va falloir vérifier. Cela doit être pris en charge directement dans notre code et entraine un surcout sensible de la phase de tests.
En effet, l’interopérabilité d’Html5 se paie par le fait que le rendu final dépend de l’implémentation qui est faite par le navigateur…et qui serait donc potentiellement différent (ou pas !) pour chaque navigateur. Là où le plug-in Silverlight garantit un rendu identique cross-browser, Html5 nécessite d’être testé sur chaque navigateur et même sur chaque version d’un même navigateur. En fonction des résultats, il faudra prévoir des mécanisme de “fallback” dans le code, c’est à dire de mode dégradé pour les éléments Html5 mal interprétés ou non supportés.

Dans tous les cas, même si je décide de partir sur Html5 pour développer une application unique disponible sur mes différents devices (PC, tablette, téléphone, …), le facteur de forme sera très différent en fonction du device et je serai certainement obligée de faire un développement spécifique pour la partie UI pour garantir une bonne expérience utilisateur.
Au final, ce que l’on a vraiment intérêt à factoriser ce sont les cas d’utilisation communs, le modèle, l’accès aux données et aux services métier !!!

Choisir aujourd’hui, ne signifie pas que l’on se trompe pour demain

Aujourd’hui, sans hésiter, je me tourne vers Silverlight puisque cette technologie me permet de développer pour Windows Phone ainsi que pour PC/Mac.
La productivité est excellente grâce à des outils, frameworks et contrôles très évolués et les techniques de développements me sont familières (.Net, XAML, …).
Les ergonomies de chacune des applications seront différentes mais les cas d’utilisation communs pourront être factorisés.
Rien ne m’empêche de développer une nouvelle application par la suite, dans une technologie différente (application Html5 pour une tablette par exemple), qui saura tirer parti du code fonctionnel que j’aurai écrit côté serveur.
Ainsi, on garde la notion d’interopérabilité au mieux entre les clients ayant des plateformes compatibles (assembly ou code commun), et au minimum entre le client et le serveur (services web interopérables, http REST, …).

D’où l’intérêt de bien réfléchir à la répartition du code métier entre le client et le serveur.

L’accès aux données

Nous aurons besoin de stocker les données et de faire en sorte qu’elles soient accessibles facilement par les différentes applications.
Donc besoin d’une couche de stockage + une couche de publication des données sur le réseau.

Cela consiste à utiliser une base de données (SQL Server par-exemple), à faire un mapping objet/relationnel de celle-ci et à mettre ces collections d’objets à disposition des services métier et des applications clientes.

On souhaite une technologie d’accès aux données interopérable : c’est bingo avec OData et WCF Data Services qui permet justement de publier des données manipulables et requêtables à la source par toutes sortes de plateformes clientes. Petite piqure de rappel : Mais c’est quoi à la fin OData ?

Toute plateforme qui sait communiquer via http et parser un flux xml sera capable de requêter et manipuler ces données.
La publication des données en OData nous permet de respecter la notion d’interopérabilité entre les clients et le serveur, ce qui laisse la possibilité à de futures applications d’y accéder facilement quelle que soit la plateforme utilisée.

Plus de détails sur cette partie dans l’article qui lui est consacré.

Cas d’utilisation et services métier

Restent à positionner les services fonctionnels qui s’appuieront sur la couche d’accès aux données et qui seront utilisés par les différentes applications clientes.
Le but sera de pouvoir réutiliser au maximum les cas d’utilisation communs dans les 2 applications pour ne pas coder, tester et maintenir n fois la même fonction dans n applications. La répartition de ces services entre le côté client et le côté serveur se fera lors de l’analyse plus poussée dans les articles suivants.

Les services développés côté serveur devront pouvoir être utilisés par les différentes plateformes clientes (services web interopérables).

Pour la partie cliente, les versions de Silverlight ne sont pas les mêmes sur les différentes plateformes qui partageront du code :

  • pour WP7, on utilise une version basée sur Silverlight 3
  • pour Mango qui sortira cet automne, mais dont les outils de développement sont déjà disponibles en version bêta, c’est Silverlight 4
  • pour le poste de travail, c’est Silverlight 4 ou Silverlight 5 en version bêta

A cet effet, le nouveau type de projet : Portable Library permet de partager du code métier entre différentes technologies (WPF, XNA, Silverlight, WP). Choisissez les plateformes cibles concernées par la librairie qui ne pourra ensuite référencer que des assemblies .Net communes à ces plateformes. En gros cela correspond aux fonctionnalités bas niveau du système en passant par la sérialisation, les ObservableCollection (top pour partager des ViewModel ), mais en excluant tout ce qui attrait à l’UI. Nous verrons ce point plus en détail lorsque nous aborderons l’architecture en couches de nos applications clientes.

Notifications des vins en promotion

 

Selon notre cahier des charges, les alertes promotionnelles sont destinées à l’application Windows Phone.
La plupart des smartphones supportent des mécanismes de notifications asynchrones. C’est le cas pour Windows Phone avec les notifications Push.
Ce mécanisme permet à une application WP de réagir en fonction d’informations provenant d’un service Microsoft de Push, lui-même prévenu par un service métier fait maison, se chargeant de déterminer et envoyer des évènements de notification. Les notifications Push à destination d’une application arrivent indépendamment du fait que celle-ci soit ou non en cours d’exécution. Ce fonctionnement permet de bénéficier d’une notion d’asynchronisme dans une application sans pour autant vider la batterie du téléphone avec un thread en tâche de fond.

Hébergement des données, des services et des applications

J’ai besoin de serveurs, mettant à disposition mes données et services, en faisant en sorte qu’ils soient disponibles tout le temps. Tout ce petit monde se doit de se porter comme un charme, peu importe le nombre d’utilisateurs. Au démarrage, il y aura certainement peu de clients, mais comme mon concept et mes applications sont révolutionnaires , mon système doit pouvoir supporter la montée en charge. Pour le moment en tout cas, je n’ai aucune idée de la manière dont je devrais dimensionner mes serveurs.
En fait, ce qui m’arrangerait, c’est de ne pas avoir de serveurs à installer, maintenir, configurer. Après tout, ce n’est pas mon métier, je préfère mon concentrer sur les applications.

C’est justement ce que permet de faire Windows Azure, la plateforme Cloud de Microsoft.
Qui dit plateforme, dit que toute la partie infrastructure est déjà prête à l’emploi, mettant à disposition un environnement, un framework de développement et des services.
Par-rapport à un développement qui est hébergé sur un serveur au sens classique du terme, on utilisera des éléments inhérents à la plateforme Azure, en terme de stockage et de publication.
Vous me direz, la belle affaire, mais pourquoi y aurait-il des différences entre mon développement classique et un développement Azure ?
Eh bien justement, tout simplement pour pouvoir garantir la possibilité au système de monter en charge, de supporter les pannes matérielles, sans impacter sa disponibilité. Avec un développement classique hébergé sur un serveur, vos données sont stockées localement. Il faut prévoir au minimum des mécanismes de redondance pour supporter une panne matérielle. Si vous avez besoin de plus de ressources et décidez d’ajouter un serveur, comment allez vous répartir la charge sur ces serveurs, partager les données, sans interrompre l’accès à vos services ?

Avec Azure, le principe est de ne pas faire de stockage local sur une machine (on parle en fait d’instance), mais sur des éléments persistants fournis pas la plateforme Azure, qui seront accessibles par les différentes instances quel qu’en soit le nombre. Si une instance redémarre, le système fonctionne toujours et c’est transparent pour l’utilisateur.
Finalement, on s’abstrait de la notion de machine et on se concentre sur les applications et les services ainsi que les systèmes de stockage.

Les questions d’hébergement, de redondance, d’installation et de maintenance de serveurs n’existent plus en tant que tel. On a intégré ce besoin d’élasticité et de disponibilité directement au niveau de la conception des applications. Notre application et nos services sont prêts une fois pour toute à fonctionner aussi bien au ralenti qu’à pleine charge, en fonction du nombre et de la taille des instances qui leur auront été attribués. La tarification se fait en fonction des critères de volume, bande passante, nombre et taille des instances : plus d’information sur la tarification.

Autre avantage : l’environnement Azure est intégré dans Visual Studio, ce qui permet au développeur de travailler dans un seul et même outil que ce soit pour le développement ou le déploiement de ses applications.

Aucun dépaysement pour le développeur en ce qui concerne le stockage de données puisque la base de données SQL Azure s’utilise exactement comme son cousin SQL Server. On peut utiliser les outils classiques de SQL Server pour administrer une base de données “dans les nuages”, simplement en précisant la chaine de connexion SQL Azure correspondante.

Pour tester gratuitement Azure et SQL Azure pendant 30 jours, profitez de l’offre Azure Pass.

Pour faciliter la mise en pratique des tutoriels qui accompagnent ces articles, nous commencerons par mettre en place les données dans SqlServer, pour les faire migrer plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement dans Azure.

Récapitulatif

On se retrouve avec le diagramme d’architecture “grosses mailles” que voici:

  • L’hébergement des données, des services et applications se fera dans Windows Azure et SQL Azure
  • La publication des données sera faite en OData avec WCF Data Services pour rester interopérable avec une grande variété de plateformes clientes
  • Les applications clientes seront développées en Silverlight
  • Nous nous efforcerons de conserver un maximum de code commun entre les 2 applications grâce à la Portable Library.
  • Les promotions seront notifiées sur le téléphone par un service de gestion des promotions et des notifications Push

Y’a plus qu’à !

Passez aux articles suivants:

  1. Développer un projet aujourd’hui : comment faire, par où commencer ?
  2. Architecture et découpage du projet
  3. Le Stockage des données
  4. La publication des données
  5. Les services métier
  6. L’application Windows Phone basique
  7. L’application Silverlight
  8. Ajout de la fonction d’aide à l’achat
  9. Ajout des notifications sur les vins en promotions