Introduction

Avant toute chose, je tiens à préciser que cet article ne se veut pas exhaustif, il ne couvrira donc pas la totalité du spectre de WCF, même si d'autres articles viendront compléter celui-ci. C’est avec l’arrivée du Framework 3.0 que Windows Communication Foundation a été mis en place. Ce dernier est issu d'une volonté d'unifier les moyens de communications pour les applications qu’elles soient Winform ou Webform. Plus tard l’utilisation des Services Web WCF, notamment dans l'implémentation d'accès à des bases des données pour des applications Silverlight s'est avéré indispensable. Quand je dis unification, je parle aussi de remplacement, puisque WCF vient se positionner dans les différents Scopes que couvraient Net Remoting, Services Web, RMI, etc.

Définition

WCF (de son ancien nom de code INDIGO) : Windows Communication Foundation est un composant qui permet de mettre en place une stratégie de communication pour vos applications. Il est l’un des 4 composants majeurs du Framework 3.0 (Windows Presentation Foundation, Windows CardeSpace, Worflow Foundation & Windows Communication Foundation), il avait pour but d’unifier et de simplifier les mécanismes autour des Services Web, Net Remoting, etc.… Si on y regarde de plus près, on peut aussi dire qu'il apporte une grande séparation du code. A l’époque où le développeur devait se soucier de tout. Ici la personne en charge du composant WCF ne se soucis que de l’implémentation du service Web, déléguant ainsi toute la partie configuration du Service WEB via le fichier de configuration à un administrateur réseau. Nous voilà donc avec un composant qui se doit d’être autonome et dont l’objectif est de fonctionner sans se soucier du client qui va le consommer. Tout au long de cet article vous allez rencontrer plusieurs fois le terme « SOA » (Services Oriented Architecture), le SOA repose sur trois fondements - pour plus d'informations vous trouverez ici un article le détaillant:

• Disponibilité
• Interopérabilité
• Sécurité

Pour une meilleure compréhension et une utilisation plus aisée, cet article vous montrera comment mettre en place un service WEB WCF, le configurer et le déployer sur un serveur de type IIS. A la fin de cet article vous trouverez également quelques problèmes que vous pourrez certainement rencontrer tout au long de votre développement.

Les bases

Avant de commencer, vous devez prendre connaissance des éléments ci-dessous. WCF repose sur un principe simple, si vous entrez dans ce monde vous allez régulièrement entendre les termes ABC du WCF. L’ABC est un acronyme qui veut dire Address, Binding et Contract.

Adresse

Il s’agit ici de l’adresse à laquelle le client va devoir se connecter afin de consommer le Service WCF. Attention : lors du développement de votre service, l’adresse n’est pas forcément la première chose dont vous vous préoccuperez, pourtant, il doit être votre premier point d’attention. En effet, si vous stockez votre service sur un serveur IIS, l’adresse n’est plus qu’une coquille vide puisque c’est la configuration de votre serveur Web qui prend le pas sur la configuration du Web Config de votre service. Si vous avez un paramètre dans cette zone alors que votre service est sur un IIS, ce paramètre doit correspondre à une adresse qui complète l’adresse de votre server IIS. Par conséquent, si vous mettez une information de la zone Address de votre fichier de configuration et que vous le déployez sur un serveur WEB, votre Service WEB pensera que vous l'informez de : "Adresse mon serveur WEB" + "Adresse de mon Service WCF". Gardez également à l’esprit que le comportement de votre service sera donc différent entre votre poste de développeur et l’endroit où il sera stocké. C’est pourquoi je vous suggère vivement de ne pas configurer votre Adresse en code Behind C# mais bien de la laisser dans le Web Config. Cela vous évitera une recompilation liée au déploiement.

Binding

Il s’agit du mode de transport des données. Vous devez d'abord savoir sur quel type de support vous allez stocker votre Service Web. Pour notre exemple nous avons choisi de le stocker sur un Server IIS 6. Cela implique que les seuls protocoles de communication acceptés seront des protocoles de type HTTP / HTTPS. Cette limitation ne s'applique pas au serveur de type 2008 R2. Le serveur IIS 7 et WAS (Websphere Application Server) permettent d'étendre l'utilisation de protocoles pour votre Binding.

• basicHttpBinding : Binding par défaut pour la création d'un Service. C'est d'ailleurs celui qui est utilisé pour notre exemple. Gardez également a l'esprit que la sécurité est désactivée par défaut.
• wsHttpBinding :
• wsDualHttpBinding : Il fournit la prise en charge de la mise en place de la communication en Dual Channel, notamment pour l'implémentation des "Callback".
• wsFederationHttpBinding :
• WebHttpBinding :
• netNamedPipeBinding :
• netTcpBinding :
• netMsmqBinding : MSMQ (Microsoft Message Queuing). Il fournit la prise en charge de la mise en attente des messages et active la prise en charge des applications Faiblement couplées.

En vert les « Binding » compatible IIS6 en rouge ceux qui ne sont accessible que si vous disposez d'un serveur IIS7.

Quand on parle de Binding, il faut avoir à l’esprit que cette partie de l’ABC, gère en fait deux sous-ensembles, le sous-ensemble transport des données et le sous ensemble formatage des données.

Le Transport : ne s'occupe que de la partie acheminement de la donnée.

Le Message : ne s'occupe que de la partie donnée (Cryptage, Formatage, etc.).

Contrat

L’une des parties les plus importantes du Service WCF. C’est lui qui expose à l’application utilisatrice du service les différentes méthodes, propriétés, etc., qui seront accessibles depuis le client. Pour exposer ces données, il suffit de décorer notre code. Vous devez donc créer une Interface dans laquelle vous allez décorer (Décoration = Préfixer avec des attributs) classes, méthodes, etc. C’est ensuite cette interface qui servira de point d’entrée entre l’application Consommatrice et votre Service.

• [ServiceContract] : se place devant la classe que vous souhaitez exposer aux clients qui consommeront votre Service WCF.
• [OperationContract] : se place devant toutes les méthodes que vous allez exposer aux clients qui consommeront votre Service WCF.
• [DataMember] : se place devant toutes les collections que vous souhaitez serializer.

Comme je le disais plus haut les informations liées au contrat sont stockées dans l’interface. Si vous regardez l’exemple ci-dessous vous verrez les attributs qui décorent notre classe et notre méthode sans ces Attributs, votre service Web n’exposera pas de Méthodes.

using System.Collections.Generic;
using System.ServiceModel;

namespace ProteusWcfLibrary
{
  [ServiceContract]
  public interface IProteusDataBase
  {
   [OperationContract]
   List GetNbPersonnes();
  }
}

Fonctionnement

Pour être opérationnel votre Services WCF doit au minimum disposer des éléments suivants : une Interface, une Classe héritant de l’interface et un fichier de Configuration. Chacun de ces éléments a un rôle bien précis dans l’opérabilité de votre Service, il faut faire attention à toutes les informations qui sont stockées dans ces fichiers.

L'interface

Il s’agit ici de la classe qui va contenir la structure de notre classe finale, c’est également ici que nous allons mettre en place la décoration par Attributs afin d’exposer nos classes et nos méthodes. Ici l’interface est le point d’entrée entre le client et le serveur. Vous pouvez prendre comme exemple l’encadré de l’interface « IWebService1 ».

La Classe

Elle hérite de l’interface que nous venons de créer, elle contient toute la problématique métiers et toute la partie codes de votre Service WCF. Étant donné qu’elle hérite de votre interface, elle récupère donc l’exposition que vous avez définie sur les méthodes. Il est évident qu’ici notre client se connectant à notre Web Service n’a aucune connaissance de l’implémentation de cette classe puisque tout passe par l’interface.

Le End Point

Nous avions déjà parlé de l’ABC, ici l’End Point, sans redéfinir ce point nous allons l'expliciter quelque peu. Il se compose donc de l’ABC

• Adresse : L’adresse à laquelle le Web Service sera disponible.
• Binding : Le mode de communication à utiliser pour parler avec le service.
• Contract : L’interface qui contient le contrat d’exposition des méthodes pour le service.

Regardons l’exemple ci-dessous, vous voyez deux points de terminaison. Comme nous l’avons dit plus haut notre Web Service a pour hébergement un serveur IIS vous voyez donc que le paramètre Adresse de notre premier End Point est vide. Le deuxième End Point concerne l’échange de données VIA MEX (nous y reviendrons plus tard)

http://localhost:8732/Design_Time_Addresses/ProteusWcfLibrary/ProteusDataBase/" /> 
contract="ProteusWcfLibrary.IProteusDataBase" />
contract="IMetadataExchange" />

Gardez bien à l’esprit que vous pouvez configurer plusieurs End Point dans votre fichier de configuration et ce dans l’optique de couvrir un plus grand scope et ainsi permettre de couvrir un plus grand nombre de client qui utiliseront votre service. Dans notre exemple nous déployons notre service sur un serveur IIS donc pas d’adresse, mais pour des questions de debugage vous devez laisser un End Point spécifique pour lancer et utiliser votre service depuis le poste de développement.

Le Web Config

Il contient toutes les données relatives à l’opérabilité de notre service, toutes les informations concernant l’hébergement, sont stockées dans ce fichier. Il est important de bien coder votre fichier de Web Config sans quoi vous vous heurterez à des exceptions lors de vos tentatives d’accès. Si vous souhaitez vous pouvez également coder en dur les éléments qui composent le Web Config (nous verrons cette solution plus loin dans ce document). Cependant il est peut être utile de garder une séparation du code et de la configuration. Partons du postulat que vous décidiez de stocker votre Service WCF sur une autre machine, garder l’utilisation d’un Web Config vous évitera une recompilation. Lorsque vous allez créer votre premier Service WEB votre Web Config devrait être relativement simple à maintenir de part le peu de ligne de code que vous pourriez y trouver. Cependant avec l’évolution de votre Librairie de services, vous risquez de vous retrouver avec un code très difficile à lire. Si c’est le cas, je vous conseille de procéder comme suit : ouvrir l’éditeur en cliquant droit sur votre fichier de config et sélectionnez « Modifier la configuration WCF »

L’interface vous permettra de configurer graphiquement l’ensemble des éléments de votre fichier de configuration.

Creation d’un Service WCF Step by Step

« Images »

Création du projet

« Images »

Faites un peu de ménage

Pour des raisons d’organisation, je crée un dossier interface et un dossier classe - cela est une habitude que j’ai prise - mais vous n’êtes pas obligé de faire de même.

Création du premier Service

Création de l’interface

On crée une nouvelle classe (interface) qui s’appellera «IWebService1». Comme nous l’avons vu dans les chapitres précédents c’est cette interface qui servira de liens entre le client qui va consommer votre service et votre service. N’oubliez pas de décorer la classe et la méthode sinon pas d’exposition !

using System.ServiceModel;

namespace NomDeLaLibrarie
{
    [ServiceContract]
    interface IMonPremierService
    {
        [OperationContract]
        string MaMethode(string _Var);
    }
}

Création de la classe

On crée une nouvelle classe qui va hériter de l’interface qui s’appellera : «WebService1». C’est classe qui va contenir la partie Métier de votre Service WCF. Ici vous n’avez pas vraiment de chance de générer des erreurs sauf si vous ne respectez pas le lien entre votre classe et votre interface.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace NomDeLaLibrarie
{
    public class MonPremierService : IMonPremierService
    {
        public string MaMethode(string _Var)
        {
            return "You have send : " + _Var;
        }
    }
}

Configuration du fichier App.config

On modifie le fichier de configuration. La partie la plus critique. Si vous codez mal votre fichier de configuration votre service ne démarrera pas et/ou pire il démarrera et fera planter le client quand il s’y connectera.

http://localhost:8732/Design_Time_Addresses/ProteusWcfLibrary/ProteusDataBase/" /> 
contract="ProteusWcfLibrary.IProteusDataBase" /> 
contract="IMetadataExchange" />

Revenons un peu sur ce fichier de configuration. Ici vous pouvez voir qu’il y a déjà deux End Point de configurés. Comme vous l’avez vu dans le chapitre précédent vous avez un End Point MEX (pour l’échange des métas) et un End Point qui utilise votre Interface pour exposer votre classe. Gardez à l’esprit qu’avant de basculer votre service coté Server IIS, que l'adresse référencée dans la balise n'est la qu'au titre du mode Design de votre service. A cet instant votre service WCF devrait pouvoir compiler sur votre poste de développement et vous devriez avoir la console de test.

Vous avez bien votre Interface qui est appelée avec le mode de communication que vous avez choisi (BasicHttpBinding), vous avez également la méthode que vous avez exposée et votre fichier de configuration. N’hésitez pas à profiter de cette interface pour tester la méthode de votre service. Votre WCF est Opérationnel. Maintenant il ne vous reste plus qu'a déployer votre service sur votre serveur IIS.

Conclusion

Au titre de ce chapitre, vous savez effectuer les opérations de base sur un Service WCF :

• Créer un Service WCF
• Configurer un Service WCF
• Déployer un Service WCF