Windows Communication foundation WCF Windows Communication foundation

Service Oriented Architecture SOA Les architectures des applications informatiques modernes repose sur le paradigme de blocs de services. Ces blocks de services doivent être accessibles et consommables rapidement et avec le moins de contraintes techniques spécifique (indépendance de technologie et de plateforme). Une première réponse a été apportée par les services web, mais il existe d’autres technologies.

Technologies distribuées chez Microsoft COM DCOM. COM+ (transaction, appel asynchrone) MS Message Queue (MSMQ). Enteprise services (wrapper .Net de COM+) Web Services. .Net Remoting (natif .net). …

Problématique Toutes ces technologies sont fortement couplées à l’infrastructure de communication du service qu’elles exposent. Le choix du protocole de communication est de la décision du développeur et non celui de l’administrateur système. L’évolution d’une infrastructure à une autre n’est pas forcement simple à mettre en place. Le code source contient la logique de communication.

Objectif de WCF WCF n’est pas un nouveau protocole de communication, mais tentative une unification Proposer un modèle de programmation unifié pour l’ensemble des technologies distribuées de Microsoft. Permettre de construire des applications indépendantes du mécanisme de communication sous-jacent. WCF est une réponse structurée et intégrée au framework .net

Modèle de programmation unifié ASMX SOAP .NET Remoting Interopérabilité avec d’autres plateformes Extensibilité Disponibilité transparente Programmation par attribut Programmation orienté message Support des protocoles WS-* Enterprise Services System.Messaging WSE

Structure d’un service WCF Un hôte qui héberge le service et procure l’environnement d’exécution. Un contrat de service qui définit via une interface et des entités les opérations implémentées par le service. Le service qui implémente l’interface. Des points de terminaison (end point) qui permettent d’exposer le service.

WCF dans le .net Framework Le framework 3.0 Implémentation de WPF. Implémentation de WCF. Implémentation de WF. Implémentation de CardSpace. Le framework 3.0 repose sur le même runtime que le framework 2.0. Intégré en natif dans VisualStudio 2008 mais pris en charge dès VS 2005.

Définition des contracts QUOI (que mets a disposition votre service) Les opérations implémentées par le service. La structure des données utilisées par le service. Les attributs DataContract et DataMenber permettent de spécifier les éléments a intégrer dans l’entité du contrat.

Définition des Bindings COMMENT (quel protocole sont utilisés) Définition du protocole de transport. Définition de l’encodage des messages. Définition des information de cryptage et de sécurité.

Définition des Adresses OU (localisation du service) Url utilisée pour accéder au service.

Points de terminaisons Ils sont composés d’au moins trois éléments (ABC) Address. Localisation du service. Binding. Protocole de communication (transport, encodage, securite, …). Contract. Contenu du service.

Les applications clientes Les applications qui consomment un service WCF ont besoin de connaitre: Le canal d’envoi. Le contrat mis en œuvre. Les entités (si présente) L’adresse du service.

TP 2 Réalisation d’une application d’hébergement du service. Gestion des exceptions dans le service.

Hébergement d’un service

Les différents modes d’hébergement Dans IIS (principalement pour les applications web). Dans une application Windows (principalement pour les tests et le développement). Dans un service Windows (pour des applications intranets et orientée process)

Hébergement des services La classe ServiceHost est responsable du chargement du service et de la configuration des points de terminaisons. IIS interagit avec cette classe de manière automatique. Les services et applications Windows doivent implémenter cette classe. La classe ServiceHost expose des événements et des propiétés permettant de suivre son état.

Les différents états d’un service Created : L’instance du service à été créer. Opening : Le service est en cours d’ouverture. Opened : Le service et est à l’écoute. Closing : Le service est en cours de fermeture, il fini le traitement des requêtes en cours. Closed : Le service est fermé et n’accepte plus de requête. Faulted : Le service a rencontrer une erreur fatale, est doit être fermé.

Transition d’états Lorsque l’instance de l’objet ServiceHost est créé celui-ci est dans l’état Created. Dans cet état le service peut être configurer. L’appel de la méthode Open (ou BeginOpen) démarre le service et le passe en état Opening. Durant l’état Opening le service tente de créer les piles de canaux pour chaque points de terminaisons définis. Sur une exception se produit le service passe en état Faulted. Si tous les canaux sont ouverts avec succès le service passe dans l’état Opened. En état Opened le service traite les requêtes des clients et les dirige vers le service. Si une exception est générer a ce stade le service passe en état Faulted. En état Faulted les service ne traite plus aucune demande de requête client, a ce stade vous pouvez toujours examiner les propriétés du service pour tenter de déterminer la cause de l’exception. Vous devez impérativement faire avorter le service (abord()) pour l’arrêter correctement. Il est possible de revenir en état Openned depuis cet état. Vous arrêtez un service via l’appel de la méthode Close (ou BeginClose) ou Abord, le service passe alors en état Closing, il n’accepte plus de nouvelle requête entrante, mais termine le traitement de requêtes en cours, sauf dans le cas de la méthode Abord. Dans l’état Closed, le service est éliminé de l’objet ServiceHost et ses ressources sont libérées. Cela explique qu’il faille rappeler le constructeur du service pour le redémarrer.

Diagramme de transition d’état

Gestion des instances de service Il est possible de modifier la façon dont le runtime WCF crée une instance du service, grâce à la propriété InstanceContextMode de l’attribut ServiceBehavior. Exemple: [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)] Public Class Service: Iservice… PerCall :Une instance de service est créée à chaque appel d’une opération. PerSession :Une instance de service est démarrée pour chaque session cliente. Single : Une instance unique du service est créée pour tous les services et toutes les sessions, elle est créée lors du premier appel.

Traitement des exceptions dans un environnement SOA

Les sources d’exception dans WCF Erreur dans le traitement coté serveur. Réseau physique indisponible ou défaillant. Mauvais formatage des messages par le client. Indisponibilité du serveur. Indisponibilité du client.

Spécificité de l’environnement SAO Le Framework .net offre déjà un service de gestion d’exceptions, mais celui-ci est natif à l’environnement et n’offre aucune ouverture sur des plateformes non Microsoft, ce qui contraire à la notion de SOA. WCF doit donc être capable de formater les exceptions et de les propager dans un format compréhensible par le plus grand nombre d’environnement.

Utilisation des exceptions SOAP Une partie de la spécification SOAP décrit la mise en forme et le traitement des erreurs (SOAP Fault) en format SOAP. Cela permet de propager des erreurs entre le service et le client. WCF propose une classe System.ServiceModel.FaultException qui implémente cette spécification SOAP pour renvoyer des messages d’erreurs aux applications clientes. Throw new FaultException(« erreur de connexion à la base de données », new FaultCode(« DataBaseAccess »)); Toute les opérations de service sont susceptibles de renvoyer au client un message FaultException. Générer une exception via FaultException, ne permet pas de typer les exceptions, le client doit analyser la valeur de FaultCode, mais celui-ci peut être n’importe quelle chaine de caractères. Le client n’a donc aucun moyen de connaitre les types d’exceptions pouvant être lever par l’appel à une méthode de service. L’utilisation de FaultException s’apparente donc à l’utilisation de Exception pour lever une exception.

Exceptions fortement typées WCF implémente un mécanisme de gestion d’exceptions typées. L’utilisation de l’attribut FaultContract, dans la définition des opérations de contrat, permet de spécifier au client la liste des exceptions susceptibles d’être levées par la méthode de service. [FaultContract(typeof(DataSourceFaultException))] [OperationContract] List<Categorie> GetCategories(); La définition des FaultContract doit donc être sérialisable et le schéma de données doit être inclus dans le contrat de données exposé par le service. [DataContract] public class DataSourceFaultException { [DataMember] public string Data; public string Message; public string Source; } Les exceptions fortement typées non spécifiées dans les opérations de contrats ne sont pas propagées vers le client.

Gestion des exceptions inattendues Les exceptions inattendues sont des exceptions qui se produisent sur le serveur et qui ne sont pas catchées. Vous pouvez indiquer à WCF de générer des FaultException lorsqu’une exception inattendue est levée. Dans le code via l’attribut [ServiceBehavior(IncludeExceptionDetailInFaults=True)] devant la classe implémentant le service. Dans le fichier de configuration dans la balise serviceBehavior. Il est fortement déconseiller d’utilisé l’attribut car cela nécessite la recompilation du code pour modifier le comportement du service.

Gestion des messages inattendus Les clients WCF communiquent généralement avec le service par l’intermédiaire d’un objet proxy, généré à partir du contrat de service du service, a un instant T. Avec l’évolution de votre service, il peut arriver, si les proxys des clients ne sont pas mis à jours, qu’une méthode ne soit plus disponible ou que son prototype ait été modifié dans le service. Dans ce cas le service est incapable de répondre à la demande du client, car elle ne correspond plus à une opération de contrat. La classe ServiceHost de WCF offre la possibilité de surveiller les demandes clients qui n’aboutissent pas via l’événement UnknownMessageReceived. Cette événement permet de connaitre les clients non à jours, mais surtout les tentatives frauduleuse d’accès à votre service.

TP 3