Introduction à Windows Communication Foundation

Par Daniel Tizon

Sur cette page

Construire des Architectures Orientées Service avec WCF

Description d’un service WCF

L'hébergement d'un service WCF

La consommation d'un service WCF

Conclusion

Introduction

Windows Communication Foundation (WCF), nom de code Indigo, est la toute dernière des technologies de Communication inter-applications proposée par Microsoft.

Comme tous les composant très attendus du Framework .NET 3.0, Windows Communication Foundation est disponible directement dans Windows Vista, dernier né des systèmes d’exploitation de Microsoft pour lequel il a été spécialement conçu. Windows Communication Foundation peut également être utilisé par des applications hébergées sur des plateformes Windows XP SP2 ou Windows 2003 par simple installation du Framework .NET 3.0.
Pour rappel, le Framework .NET 3.0 n’est qu’une extension des bibliothèques de classes du Framework .NET 2.0, le Common Langage Runtime (CLR) restant inchangé.

Si on analyse les technologies de communication fournies avant WCF, on s’aperçoit qu’elles répondent chacune à un besoin particulier de communication, tantôt synchrone ou asynchrone, transactionnelle ou non, très performantes et propriétaires ou moins performantes, moins fonctionnelles mais interopérables. Ce choix doit être réalisé très tôt par l’architecte applicatif car il conditionnera non seulement les capacités de communication de l’application mais également la façon dont sera structuré le code.

Contrairement à ces précédentes technologies telles que COM, DCOM, MSMQ, .NET Remoting, Web Services XML, ou EnterpriseServices, WCF se veut être un modèle uniforme, faiblement couplé et adapté à toutes les situations et besoins de communications.

Construire des Architectures Orientées Service avec WCF

Résolument positionnée comme composant majeur dans la construction d’Architectures Orientées Services (SOA) sur les plateformes Microsoft, WCF répond positivement aux objectifs.

Les solutions orientées services sont des solutions faiblement couplées. Les parties ne font aucune supposition sur les parties adverses

• Services isolés
• Indépendant de la localisation
• Indépendant du transport, du protocole et du format
• Indépendant des plateformes et de l’implémentation
• Doit pouvoir fonctionner quel que soit les dispositifs de montée en charge mis en place
• Doit pouvoir fonctionner même lorsque l’une des parties n’est pas disponible (asynchrone)

Haut de page

Description d’un service WCF

Concrètement, un service WCF est un élément logiciel qui répond à des communications réseau. La description d’un service WCF est similaire à celle d’un Web Service au sens qu’il doit préciser où il se trouve, comment il communique et ce qu’il fait. Pour un Web Service, cette description doit être consignée dans un fichier WSDL. Ces informations sont définies dans les éléments service, binding et portType. Dans la terminologie de WCF, ces informations s’appellent Address, Binding et Contract. Ces termes sont plus facilement mémorisables puisque se traduisant par les acronymes A, B, C.

Un service WCF peut exposer un ou plusieurs points de communication, chacun d’eux étant constitué d’une adresse, d’un binding et d’un contrat.

Le contrat

Le contrat permet au service de décrire explicitement la liste des opérations qu’il expose. La définition du contrat est très simple pour un développeur .NET puisque cela consiste à déclarer une interface au sens langage .NET, de définir un certain nombre de méthodes et de la décorer de quelques attributs.

[ServiceContract()]
 public interface IService1
 {
 [OperationContract]
 string MyOperation1(string myValue);
 [OperationContract]
 string MyOperation2(DataContract1 dataContractValue);
 }

Il est à noter que seules les méthodes décorées de l’attribut [OperationContract] pourront être exposées par le service.

Le contrat définit la liste des opérations implémentées par le service. Il peut également spécifier des comportements orthogonaux par l’ajout de propriétés sur les attributs ServiceContract ou OperationContract pour préciser notamment :

• La fourniture d’un contrat bidirectionnel permettant non seulement d’initier une communication du client vers le serveur, mais aussi du serveur vers le client.
• Le support d’une session pour conserver l’état entre l’appel de plusieurs opérations
• L’attente ou non d’un message d’acquittement suite à l’exécution d’une opération ne retournant pas de résultat
• Une implémentation explicite de l’opération en mode asynchrone. Notons que ce choix ne préjuge en rien la façon dont le client devra effectuer son appel.

L’étape suivante consiste à implémenter le service à proprement dit. Il suffit pour cela de créer une classe qui implémente le contrat. Dans le cas où une structure de données doit être échangée entre le fournisseur et le consommateur de service, il devient intéressant de spécifier un ou plusieurs contrats de données (DataContract)

public class service1 : IService1
 {
 public string MyOperation1(string myValue)
 {
 return "Hello: " + myValue;
 }
 public string MyOperation2(DataContract1 dataContractValue)
 {
 return "Hello: " + dataContractValue.FirstName;
 }
 }
 
 [DataContract]
 public class DataContract1
 {
 string firstName;
 string lastName;
 
 [DataMember]
 public string FirstName
 {
 get { return firstName; }
 set { firstName = value; }
 }
 [DataMember]
 public string LastName
 {
 get { return lastName; }
 set { lastName = value; }
 }
 }

Lors de l’implémentation du service, il est possible de préciser des comportements supplémentaires tels que :

• Le support d’un appel concurrent multi threads ou non
• La coordination d’une transaction sur le service initiée depuis le client, en précisant le niveau d’isolation
• La conservation du contexte au niveau d’une méthode, de la session, ou en mode singleton
• L’impersonification sur l’exécution d’une méthode

Le Binding

Un binding permet de décrire le protocole de communication utilisé pour se connecter à un point de communication d’un service WCF. Le binding définit plusieurs axes paramétrables dont le protocole de transport mais pas uniquement !

• Méthode de transport utilisé pour la communication entre les applications situées sur une même machine ou non. (HTTP, HTTPS, TCP, MSMQ, named piped)
• Format d’encodage (Text, Binaire, MTOM)
• Contraintes de sécurité
• Contraintes de garantie de remise
• Support des transactions

Afin de faciliter le choix parmi les nombreuses combinaisons possibles, WCF est livré avec neuf bindings prédéfinis, adaptés à la plupart des scénarios classiques. En voici quelques-uns.

BasicHttpBinding: un binding interopérable s’appuyant sur HTTP et SOAP conçu pour la connexion à des Web Services conformes à la spécification WS-I Basic (permet d’exposer un Web Service classique)

WSHttpBinding: un binding interopérable et sécurisé conçu pour la connexion à des services conformes aux specifications WS-* (permet d’exposer un Web Service conforme aux spécifications les plus récentes, dont WS-Security ou WS-ReliableMessaging)

WSDualHttpBinding : un binding interopérable et sécurisé conçu pour une communication bidirectionnelles de messages SOAP entre applications.

NetNamedPipeBinding: un binding conçu pour des applications .NET installées sur la même machine et qui utilisent WCF de chaque côté pour communiquer.

NetMsmqBinding: un binding conçu pour des applications .NET qui utilisent WCF pour communiquer par le biais des files de messages MSMQ.

L’adresse

Toute communication avec un service Windows Communication Foundation (WCF) se fait en passant par un point de communication. Un point de communication consiste en une adresse, un binding et un contrat. L’adresse spécifie où se trouve le service. Elle est définie par une URI. Bien qu’un point de communication puisse être spécifié de façon impérative dans le code ou déclarativement dans le fichier de configuration, la méthode déclarative est à privilégier. Les choix effectués en développement pour le binding et l’adresse étant bien souvent différent de ceux utilisés lors du déploiement du service, il est préférable de les rendre facilement modifiables par configuration plutôt que d’être obliger de modifier le code et de le recompiler suite à des changements.

Un même service WCF peut exposer plusieurs points de communication et donc être accessible depuis plusieurs adresses.

Voici un exemple de point de communication utilisant le contrat IService1, le binding WSHttpBinding, et l’adresse «http://localhost:8080/service1»

<endpoint address="http://localhost:8080/service1" 
 binding="wsHttpBinding"
 contract="WCFServiceLibrary1.IService1"/>

Haut de page

L'hébergement d'un service WCF

Un service WCF peut être hébergé par n’importe quelle application .NET. On utilise habituellement une application console ou Windows Forms pendant la phase de développement d’un service pour faciliter sa mise au point.

Voici l’exemple de code permettant d’héberger notre service dans une application console.

using System;
 using System.Collections.Generic;
 using System.Text;
 using System.ServiceModel;
 namespace WCFServiceHost
 {
 class Program
 {
 static void Main(string[] args)
 {
 MyServiceHost.StartService();
 Console.WriteLine("Le service est lancé...");
 Console.ReadKey();
 MyServiceHost.StopService();
 Console.WriteLine("Le service est arrêté...");
 }
 }
 }
 internal class MyServiceHost
 {
 internal static ServiceHost myServiceHost = null;
 internal static void StartService()
 {
 myServiceHost = new ServiceHost(typeof(WCFServiceLibrary1.service1));
 myServiceHost.Open();
 }
 internal static void StopService()
 {
 if (myServiceHost.State != CommunicationState.Closed)
 myServiceHost.Close();
 }
 }

Pour lancer le service, il n’y a que deux lignes de code à écrire:

• Créer une instance de la classe ServiceHost, en lui passant dans le constructeur le type du service.
• Appeler la méthode Open()

Les informations de binding et adresse sont définies dans le fichier de configuration app.config suivant :

Les informations de binding et adresse sont définies dans le fichier de configuration app.config suivant :
 <?xml version="1.0" encoding="utf-8" ?>
        <configuration>
          <system.serviceModel>
            <services>
              <service name="WCFServiceLibrary1.service1" behaviorConfiguration="httpGetEnabledBehaviors">
                <host>
                  <baseAddresses>
                    <add baseAddress="http://localhost:8080/service1"/>
                  </baseAddresses>
                </host>
                <endpoint address="" 
                          binding="wsHttpBinding"
                          contract="WCFServiceLibrary1.IService1"/>
              </service>
            </services>
            <behaviors>
              <serviceBehaviors>
                <behavior name="httpGetEnabledBehaviors" >
                  <serviceMetadata httpGetEnabled="true" />
                </behavior>
              </serviceBehaviors>
            </behaviors>
          </system.serviceModel>
        </configuration

Afin de ne pas avoir à copier sur le client le contrat de service (ServiceContract) et le contrat de données (DataContract) manuellement, le « serviceBehavior » httpGetEnabled permet de les exposer sur http comme le font les Web Services .ASMX pour leur fichier WSDL.

Fenêtre d’exécution du serveur :

Pour un hébergement en production, il est préférable de passer par une application de type « Service Windows », Internet Information Services (IIS), ou encore « Windows Process Activation Service (WAS) » WAS est le nouveau mécanisme d’activation de processus disponible dans Windows VISTA et qui sera également disponible dans « Windows Server Longhorn ». IIS 7.0 utilise WAS pour accomplir l’activation basée sur des messages transmis par http. Utiliser directement WAS pour l’hébergement des services WCF permet de bénéficier des mêmes avantages de robustesse ou de monitoring fournis par IIS non seulement sur http, mais aussi sur TCP, MSMQ et les Named Pipes.

Haut de page

La consommation d'un service WCF

Une application cliente doit connaître les contrats qui correspondent au service auquel elle doit accéder. La meilleure approche consiste à utiliser l’outil Svcutil. Cet utilitaire est capable de récupérer les contrats, de générer le code proxy client permettant de faciliter la manipulation du service WCF et de générer le fichier de configuration client

svcutil http://localhost:8080/service1 /out:c:\proxy.cs /config:c:\app.config 

il suffit ensuite de créer un nouveau projet .NET , d’ajouter une référence sur la dll WCF System.ServiceModel.dll, d’incorporer les fichiers générés par svcutil, et de jouer avec une instance de la classe proxy.

 class Program
        {
        static void Main(string[] args)
        {
        Console.WriteLine("Lancement du client\nAppuyez sur une touche.");
        Console.ReadKey();
 
        Service1Client obj = new Service1Client("Endpoint1");
        string resultat = obj.MyOperation1("Daniel");
        Console.WriteLine("Résultat appel opération1 :{0}", resultat);
 
        WCFServiceLibrary1.DataContract1 objData = new WCFServiceLibrary1.DataContract1();
        objData.FirstName = "Bill";
        objData.LastName = "Gates";
        resultat = obj.MyOperation2(objData);
        Console.WriteLine("Résultat appel opération2 :{0}", resultat);
 
        Console.ReadKey();
       
        }
        } 

On peut remarquer que dans le constructeur de la classe proxy on peut spécifier un paramètre qui correspond au nom du point de communication défini dans le fichier de configuration.

 <?xml version="1.0" encoding="utf-8" ?>
        <configuration>
          <system.serviceModel>
            <client>
              <endpoint name="Endpoint1"
                        binding="wsHttpBinding"
                        address="http://localhost:8080/service1"
                        contract="IService1"/>
            </client>
          </system.serviceModel>
        </configuration

Voici le résultat de l’exécution de l’application sur le client

Haut de page

Conclusion

Nous avons vu au regard de cet article la puissance et la simplicité du modèle de programmation des services avec WCF.

Windows Communication Fondation est la nouvelle couche de communication qui rend obsolète la façon de programmer les WebServices, le .NET Remoting ou MSMQ que nous avions jusqu’à présent sur la plateforme .NET.

Windows Communication Foundation séduira les architectes en tant que plateforme de communication pour développer des Architectures Orientées Services.

Les développeurs y trouveront un moyen de consommer n’importe quel services de la même manière, quelque soit le protocole de communication sous-jacent. WCF permet aux développeurs de se concentrer sur le service en lui-même puisque toute la tuyauterie de communication est maintenant fournie de base sous forme déclarative et indépendante de l’implémentation du service.

Enfin, WCF est non seulement adaptée pour la communication entre applications 100% .NET et WCF, mais reste également le meilleur choix pour assurer une interopérabilité cross-plateformes avec les tous derniers standards de communication.

Daniel Tizon Microsoft Regional Director Daniel TIZON est consultant formateur en technologies .NET à Winwise depuis 5 ans. Spécialisé sur les technologies ASP .NET et WCF, ainsi que sur la gamme de produits Visual Studio 2005 Team System, il rédige régulièrement des articles et anime des conférences sur ces sujets. Vous pouvez le contacter par mail ou accéder à son blog.

Haut de page