Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

WCF Service pour Silverlight

[new:23/06/2010] Le Framework .NET, au travers de Visual Studio, nous offre la possibilité de créer de nombreux types de services distants : des Web services classiques, des WCF services et des “Silverlight-enabled WCF services”. Quelle différence y-a-t-il entre ces différents “services” et pourquoi choisir les services particuliers WCF pour Silverlight ?

Web Service classique vs. WCF Service

La première question importante est de savoir quelles sont les différences entre ces deux modes de services distants.

Web Service classique

Le Web service classique est un mécanisme de transfert de données aujourd’hui parfaitement standardisé et largement utilisé quelle que soit la plateforme. Utilisant un support XML pour les données, n’importe quelle plateforme peut consommer un Web service de n’importe quelle autre plateforme.

“L’invention” des Web services fut un bond énorme en avant vers un Internet collaboratif, plus ouvert, et surtout ouvert aux applications qui deviennent des utilisateurs comme les autres du réseau. Les humains peuvent utiliser le Web avec ses pages HTML (peu importe la technique qui sert à les produire) et ses plugins riches (Flash, Silverlight). Les applications deviennent des acteurs du réseau en pouvant elles aussi communiquer, échanger des informations dans un format qui leur être propre et plus facile à interpréter qu’une page HTML.

avantages

Créer des Web Services “classiques” aujourd’hui, et même sous .NET, a tout son sens car seuls les services se présentant de cette façon sont “universellement” reconnus et utilisables.

Si vous devez créer des services exploitables par des applications tierces, des plateformes différentes, alors il faut utiliser les services classiques.

De plus créer des Web services classiques sous .NET est d’une facilité déconcertante.

Inconvénients

Cet universalité a un prix :  Les données pouvant être échangées ou transmises sont limitées à des types sérialisables de façon tout aussi universelle. Les objets complexes .NET ne peuvent pas être transmis directement. Pour des applications .NET de bout en bout, c’est un gros inconvénient et une lourdeur inutile à supporter.

De plus, il existe des variantes, des approches différentes voire même des standard parallèles. Par exemple JSON est un format qui s’oppose au XML classique pour la représentation des données. Néanmoins Silverlight sait comprendre JSON, il reste donc possible d’exploiter ce format particulier de “Web service classique” sans aucun souci côté application SL.

Syntaxe et mise en oeuvre

Elle est d’une légèreté sans pareil. Un blogger comparait les services Web “classiques” à un Cesna 150 et les services WCF à un 747. On fait plus de choses et plus fines avec dernier mais l’apprentissage est aussi beaucoup plus difficile…

Pour faire un service Web classique le bloc-notes est suffisant. Un simple fichier avec l’extension ASMX et des méthodes décorées avec l’attribut [WebMethod] et hop! le service est immédiatement utilisable…

la mise en oeuvre est tout aussi déroutante puisqu’il suffit que le fichier ASMX soit accessible sur un serveur IIS et ça marche tout seul.

De nombreux articles ont détaillé la conception des services Web classiques, et ce depuis des années, je renvoie ainsi à Bing le lecteur qui souhaite retrouver les articles français qui lui permettront de mettre en place facilement de tels services.

Services WCF

WCF (Windows Communication Foundation) est une brique essentielle du Framework .NET qui fédère de très nombreuses techniques de communication qui existaient auparavant et qui offre une API unifiée et objectivée. En ce sens WCF “annule et remplace” tout ce qui se faisait jusqu’à lors (le graphique ci-dessous montre ces techniques).

WCF

On voit tout en haut du cercle “ASMX”. Oui, WCF est conçu pour remplacer totalement les Web Services classiques tels que ceux discutés plus haut. Mais WCF remplace aussi :

  • MSMQ. Microsoft Message Queuing. Protocole essentiellement basé sur les messages et permettant à des application consommatrices de recevoir des messages depuis des applications productrices. Ajouté dans Windows 95, MSMQ est toujours disponible sous Windows 7 et a même été ajouté à Windows CE depuis la version 3.0.
  • WSE. Web Services Enhancements. Un toolkit Microsoft pour .NET permettant d’exploiter les dernières spécifications des WS classiques. Releasé pour le Framework 1.0 jusqu’à WSE 3.0 pour VS 2005. Depuis, toutes les nouvelles fonctionnalités sont intégrées dans WCF.
  • COM+ (Entreprise Services). Ancêtre du Remoting .NET. Première technique Win32 de communication fiable entre applications locales et distantes sous Windows. Efficace et puissant, COM+ était malgré tout une techno complexe et peu aisée à mettre en œuvre.
  • .NET Remoting. Une technologie assez simple et très puissante permettant de faire communiquer des applications .NET de façon objet. Successeur de COM+ sous .NET, .NET Remoting est typiquement un outil dit “3 tiers” ou “n-tiers” dans la lignée de ce que Borland appelait à l’époque DataSnap, issu lui-même de MIDAS. Java avait aussi son J2EE dans le même esprit.

Comme on le voit ici, WCF est un effort énorme et louable de Microsoft de mettre enfin de l’ordre dans un foisonnement de technologies toutes plus ou moins délicates à manipuler. C’est, entre autres choses, ce qui m’a fait aimer Microsoft depuis sa période .NET : un changement radical d’état d’esprit visant plus d’homogénéité et de cohérence dans les outils de développement et considérant enfin le développeur comme un “client” respectable à qui il faut offrir de beaux outils et de belles plateformes pour le séduire.

Les apports de WCF

WCF n’est pas qu’un agrégat de technologies variées. Il ne s’agit pas de mettre un nom unique sur des API qui resteraient spécifiques ou teintées de leurs origines. WCF est une technologie neuve, à part entière. Si elle remplace de nombreuses autres solutions c’est parce qu’elle les a “réinventées” dans un tout complet. De fait WCF n’est pas que la somme des technologies qu’elle remplace, elle apporte beaucoup de choses en plus de ce qu’elle remplace.

Par exemple, WCF est généralement de 25 à 50% plus rapide que les équivalents de la génération précédente pour les mêmes tâches. WCF est taillé pour être “scalable” et peut prendre en compte des configurations lourdes multi-processeurs. Les serveurs WCF peuvent être réalisés, au choix, sous la forme de code hébergé sous IIS mais aussi sous forme de Services Windows ou même de simples applications consoles ou autres.

WCF offre un mode de programmation par attribut clair, une configuration souple par fichier XML. WCF offre aussi un DataContractSerializer qui autorise la sérialisation d’objets .NET complexes ce qui est un avantage énorme sur les services Web classiques. WCF peut utiliser toute une palette de canaux de transmission pour véhiculer ses messages : HTTP, TCP, MSMQ, Named Pipe, etc.

Avantages

Remplace un fatras de technologies disparates et pas forcément agréables à utiliser. S’inscrit dans la “logique .NET” et “l’esprit .NET”. Offre toutes les fonctionnalités pour réaliser des choses simples comme des montages complexes (assure donc la possibilité d’une monté en charge maîtrisée). Autorise deux applications .NET, même de nature différente, à dialoguer et à échanger des objets .NET complexes.

Inconvénients

Il y en a peu, mais un mérite d’être indiqué par honnêteté : WCF, par la surface qu’elle couvre, est une technologie “à tiroir” où il est possible de se perdre un peu. Maîtriser WCF réclame un investissement plus important que faire un Web Service classique, c’est une évidence, surtout si faire du Web Service est l’utilisation principale qu’on fera de WCF.

Néanmoins WCF est totalement intégré à .NET, sa manipulation est facilité par Visual Studio, et lorsqu’il s’agit de programmer des applications Silverlight, purement .NET, la question du choix entre service classique ou WCF se pose à peine, c’est WCF qu’il faut préférer.

Syntaxe et mise en œuvre

Le coté tentaculaire de WCF fait qu’il serait peu sérieux de vouloir résumer en deux lignes sa syntaxe et sa mise en œuvre comme je l’ai fait plus haut pour les services classiques. Il existe des livres entièrement consacrés à WCF, si vous devez vous orienter vers du 3-tiers (ex .NET Remoting) par exemple, je vous conseille vivement d’investir dans cette littérature !

“Silverlight-Enabled” WCF Services

Quel serait donc ce troisième choix de services WCF “Silverlight-enabled” ?

C’est assez simple, il s’agit juste d’une facilité de développement, de mécanismes de configuration gérés automatiquement par Visual Studio pour rendre le service WCF utilisable facilement avec Silverlight sans trop s’encombrer de toutes les spécificités de WCF.

Par exemple, le fichier Web.Config de l’application ASP.NET hébergeant le service est modifié de telle sorte que le canal de communication du service soit basicHttpBinding, c’est à dire un mode HTTP puisque les applications Silverlight sont des applications Web qui passent par HTTP. Un autre réglage concerne la compatibilité avec ASP, puisque le service est intégré à une application Web ASP.NET. Le paramètre aspNetCompatibilityEnabled est ainsi initialisé à True.

C’est finalement peu de choses, mais du coup cela facilite grandement l’intégration d’un service dans une application Silverlight.

Conclusion

Silverlight permet la consommation de services distants de plusieurs natures. Du service Web classique au service WCF.

Choisir la technologie du service distant réclame de comprendre les avantages et les inconvénients de chacune des possibilités.

La complexité de WCF tente certains développeurs à préférer les services classiques, beaucoup plus simples à maîtriser à et mettre en œuvre. C’est toutefois se priver de la richesse de WCF et d’un dialogue objet .NET très supérieur qualitativement à ce que peut offrir un service classique.

Visual Studio, en offrant un mode “Silverlight-enabled” pour les services WCF simplifie le paramétrage et la prise en main. Il suffit juste d’ajouter des méthodes au service… De plus, en choisissant les services WCF vous laissez la porte ouverte à des extensions, des améliorations qui seraient impossibles à réaliser avec des services classiques ce qui obligerait à “casser” le code existant. Mieux vaut partir du bon pied et bien chaussé. Les tongs c’est rapide à mettre, mais ce n’est pas fait non plus pour aller très loin…

Stay Tuned !

blog comments powered by Disqus