Développer un projet aujourd’hui : Publication des données (4/9)

Article
10/20/2021

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..

Cet article est le troisième d’une série qui se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret.
Dans ce volet, nous nous intéressons à la publication des données sur le réseau pour les rendre accessibles à des services ou application clientes.

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:

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

Et les tutoriels correspondants qui arriveront au fil de l’eau:

CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First

CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services

Sommaire de l'article

Rappel de l’architecture visée
Choix de la technologie de publication des données
- WCF RIA Services
- WCF Data Services
WCF Data Services : Comment ça marche ?
La mise en oeuvre
Architecture réalisée à ce stade

Rappel de l’architecture visée

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

Pour faciliter la mise en pratique de la série de tutoriels, nous commencerons par mettre en place un fonctionnement On Premises (un hébergement sur des serveurs classiques), pour faire migrer la solution 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.

Choix de la technologie de publication des données

A ce stade, nous avons réalisé le stockage et couche d’accès aux données (mapping ORM).

Pour que les données soient accessibles par des applications clientes, il faut les mettre à disposition sous la forme d’un service. Il y a différentes manières d’effectuer cette opération en fonction des plateformes clientes adressées.
Dans notre cas, nos clients seront:

des services métiers (services web au sens large)
une application Silverlight
une application Silverlight pour Windows Phone
d’autres applications potentielles à venir, par-exemple en Html5

Chez Microsoft, les 2 principales technologies de services orientées données sont :

WCF RIA Services
WCF Data Services (OData)

WCF RIA Services

En résumé, cette technologie permet de masquer la communication entre le client et le serveur et de reporter automatiquement les règles métiers de validation des données côté client.
C’est une technologie de haut niveau qui améliore la productivité du développement Silverlight puisque les règles métiers ne sont codées qu’une seule fois côté serveur.

Pour découvrir et comprendre RIA Services, voici quelques articles et vidéos :

WCF RIA Services est dédié à Silverlight classique uniquement, ce qui exclut son utilisation sur Windows Phone. Mais il offre également des endpoints plus limités de type SOAP, JSON, OData (en lecture seule) pour laisser la possibilité à d’autres plateformes de consommer les données. Je vous conseille les excellents articles de David sur le sujet : Comment exposer une application WCF RIA Services à d’autres clients ?

WCF Data Services

WCF Data Service est une implémentation pour .Net de OData.
Mais c’est quoi à la fin OData ?
En résumé, cette technologie permet de mettre des données en ligne, de manière très interopérable c’est à dire accessibles de la même manière par toutes sortes de plateformes clientes.

On bénéficie d’un typage fort des données ainsi que du requêtage à la source.

Par-rapport à WCF RIA Services et en caricaturant, on pourrait dire que l’on troque la productivité contre l’interopérabilité.

Pour notre cave à vins, je préfère utiliser WCF Data Services pour les raisons suivantes:

Sur mon client WP, je ne peux pas me permettre d’utiliser le endpoint OData de WCF RIA Services, car celui-ci propose un accès aux données en Read Only uniquement . Or j’aurai besoin d’accès en lecture/écriture sur mes données….

Côté client : je souhaite partager un maximum de code entre les plateformes, ou au moins utiliser une seule technique pour accéder à mes données plutôt que de devoir en apprendre plusieurs.

Or, avec RIA Services, mes clients utiliseront RIA Services lui-même (pour Silverlight), mais aussi les endpoints SOAP, JSON en fonction des plateformes applicatives.

Côté serveur : si tous mes clients utilisent le même point d’entrée, mon jeu de tests unitaires et fonctionnels en sera réduit d’autant

Ce choix est tout à fait discutable et les arguments sont à mettre en balance avec la productivité apportée par WCF RIA Services. Si notre application principale en Silverlight, était très complète en terme d’accès aux données et que les applications sur devices nomades reprennent simplement quelques vues de synthèse, on pourrait faire un choix différent.

Tout est une question de compromis et le choix se fait en fonction des contraintes, des priorités et des besoins d’évolutivité de votre projet.

Pour aller plus loin, je vous conseille la vidéo de la session dédiée à ce sujet que nous avons présentée aux Techdays avec David Rousset : Choisir une technologie d’accès aux données distantes qui compare WCF, WCF Data Services et WCF RIA Services.

WCF Data Services : Comment ça marche ?

A partir de notre couche d’accès aux données Entity Framework (cf article précédent), il est très facile de publier les données au format OData grâce à WCF Data Services.
En effet, WCF Data Services va simplifier le développement côté serveur, en fournissant un template de projet adapté dans Visual Studio et en créant automatiquement le service à partir du contexte de données Entity Framework associé.
Côté client, nous pourrons utiliser ce service très facilement en ajoutant une référence à celui-ci dans Visual Studio, ce qui génère automatiquement les classes proxy incluant le contexte de données.
On exprime ensuite directement des requêtes Linq sur le contexte de données qui seront tranformées automatiquement dans les URIs OData correspondantes, lors de l’exécution.

C’est du charabia ? C’est normal, vous verrez tout cela dans le tutoriel qui vous guidera pas à pas.

Il est noter que WCF Data Services peut tout à fait publier des sources de données autres que Entity Framework comme on peut le voir sur le diagramme suivant:

Avec WCF Data Services, vous pourrez moduler les droits d’accès à vos données en fonction de vos entités (par-exemple, on pourrait imaginer une entité “producteurs” qui serait en lecture seule).
Vous pouvez également aller beaucoup plus loin en définissant des méthodes d’interception des requêtes. Ce mécanisme vous permet d’adapter le résultat de la requête en fonction du contexte ou de règles métier.
On pourra par-exemple faire en sorte que seul l’auteur d’une review ait le droit le la modifier, mais que tout le monde ait le droit de la consulter.

Nous aborderons ce sujet dans l’article consacré à l’authentification avec Access Control Services.

A travers SQL Azure Labs, Sql Azure fournit également une ouverture au format OData de ses données, mais :

vous zappez la couche ORM faite par Entity et vous obtiendrez donc un mapping 1 classe <-> 1 table
l’accès aux données est public ou contrôlé par ACS
vous perdez la possibilité d’intercepter les requêtes pour adapter vous-même les résultats en fonction de l’utilisateur authentifié ou de votre besoin métier

En gros, vous perdez en souplesse, mais vous gagnez en rapidité de développement.

La mise en oeuvre

Voici le tutoriel associé pour mettre WCF Data Services en pratique dans le contexte de notre cave à vins.

Au final, nous obtenons un service web qui à partir d’une URI Http (REST) correspondant à une requête CRUD (Create/Read/Update/Delete), effectue l’opération demandée sur les données stockées en base.
Pour une requête de sélection, le service renvoie la collection d’objets résultante sous la forme d’un flux XML (Atom ou JSON).

Nous pouvons donc utiliser un navigateur web comme un client de ce service, et requêter les données directement.
Ainsi, si l’on tape l’URL du service dans le navigateur : https://localhost:33880/CaveAVinsOData.svc/on obtient l’index des collections publiées pour notre projet de cave à vins:

Architecture réalisée à ce stade

Version On Premises

Un service web WCF Data Services a été mis en place. Pour l’instant il est hébergé dans IIS (ou plutôt dans le serveur de test de Visual Studio !).
Grâce à lui, les données sont accessibles en OData par toute plateforme cliente qui sait communiquer en http et parser du XML : difficile de faire plus interopérable .

Version Cloud

Dans la version Cloud à venir, c’est Azure qui hébergera ce service sous la forme d’un web role comme nous le verrons dans l’article consacré à la migration.

En résumé, les différences de la version Cloud sont:

Base de données Sql Azure au lieu de Sql Server

Ajout du web role qui permet de configurer l’hébergement du service dans Azure

Tout est en place pour permettre la manipulation de ces données à partir de services métiers ou d’applications clientes.

C’est ce que nous verrons un peu de vacances !