Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe


Poster un commentaire

Premier contact avec Windows Server AppFabric partie III

Cet article est la suite d’une série qui a démarrée ici:

https://amethyste16.wordpress.com/2014/07/20/premier-contact-avec-windows-server-appfabric-partie-i/

 

Il ne sera peut être pas inutile de lire également cet article auparavant qui donne les bases pour comprendre comment héberger WCF dans IIS:

https://amethyste16.wordpress.com/2014/08/14/windows-activation-service-was/

Mais ce n’est pas indispensable pour lire la suite.

 

Windows AppFabric propose des outils pour améliorer l’hébergement des services WCF et Workflow avec WAS.

On pourrait bien entendu héberger le service directement avec WAS. Mais il n’est pas inutile de disposer de certains services tels la surveillance du service, suivi des exceptions… Surtout en production. Ce sont les genres de services justement apportés par Windows AppFabric en plus d’une simplification du déploiement.

Allons y donc!

Lire la suite

Publicités


Poster un commentaire

Windows Activation Service (WAS)

Il est possible d’héberger des services WCF de 3 façons (au-moins):

  1. Dans IIS
  2. Dans une application console, Windows Service ou Winform
  3. Avec le service WAS hébergé par IIS

 

Hébergement IIS

J’ai écris une série d’articles qui montre les différentes façons d’héberger un service WCF dans IIS. Le premier de la série est:

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

 

Hébergement dans un AppDomain
L’hébergement dans une application de type application console se réalise avec une instance de ServiceHost

Note: Les autres hébergement utilisent aussi ServiceHost en interne, il est juste masqué à l’utilisateur

Voici un article avec un exemple:

http://msdn.microsoft.com/fr-fr/library/system.servicemodel.servicehost(v=vs.110).aspx
ServiceHost est un conteneur pour héberger WCF et fournir une description du service accessible via Wsdl. Il gère aussi un cycle de vie via divers événements comme Closed, Closing…

Ce type d’hébergement est appelée self-hosting car on doit alors tout prendre en charge:

  • Instancier le service et initialiser l’environnement
  • Gérer son paramétrage
  • Gérer la montée en charge
  • Gérer le recyclage et le cycle de vie
  • Gérer les logs et les exceptions
  • Gérer le monitoring

Seuls IIS et WAS propose ces extensions de services de façon intégrées. C’est ou ce n’est pas utile à votre application. Comme toujours, le besoin prime.

Si vous choisissez cette option, je recommande fortement d’utiliser un service Windows. L’application console (voir WinForm) a ses adeptes, mais je n’en comprends même pas l’intérêt en production.

 

Hébergement WAS

WAS est arrivé avec IIS 7. Il s’agit donc d’une extension de IIS.

L’intérêt de l’hébergement WAS est que l’on n’a pas la dépendance avec Http. On peut donc utiliser n’importe quel protocole WCF (TCP, MSMQ…), mais on garde les services standards de IIS (monitoring, cycle de vie, gestion temps morts…).

Important: WAS n’est disponible qu’en mode pipeline intégré.

 

IIS a apporté quelques modifications dans l’architecture IIS justement pour pouvoir supporter WAS. On parle d’écouteurs de protocole, d’adaptateurs et de gestionnaires de protocoles:

  • Ecouteurs de protocole (protocol listeners)
    Un service dont le rôle est de recevoir des requêtes dans un protocole donné. On a toujours l’écouteur Http hérité de IIS 6 (http.sys), mais on en a de nouveau avec WAS
  • Adaptateurs (listeners adapter)
    C’est un adaptateur au sens développé dans cet article:
    https://amethyste16.wordpress.com/2014/07/02/comparaison-des-patrons-proxy-adaptateur-et-facade/
    Son rôle est de traiter la requête reçue dans un protocole, mettre éventuellement la requête dans une queue et enfin la router vers le worker process qui pourra la traiter à l’aide d’un gestionnaire de protocole.
  • gestionnaires de protocole (protocol Handlers)
    Le gestionnaire instancie (si nécessaire) un ServiceHost pour le protocole demandé et lui passe la requête à traiter.

Une petite infographie et ce sera sans doute plus clair. Elle est tirée de l’article de Michele Leroux Bustamante cité plus bas:

2014-08-14_17-30-59

 

Comme on le voit, la nouvelle architecture permet à IIS de traiter n’importe quelle requête de n’importe quel protocole de façon homogène.

 

Si vous souhaitez en savoir plus (et notamment comment activer WAS dans IIS), lisez cet excellent article de Michele Leroux Bustamante:

http://www.codemag.com/Article/0701041

J’ai bien aimé également cet article écrit aussi par une femme:

http://searchwindowsserver.techtarget.com/definition/Windows-Process-Activation-Service-WPAS

 

Un exemple d’hébergement WAS:

http://msdn.microsoft.com/fr-fr/library/ms733109(v=vs.110).aspx

http://www.wcftutorial.net/wcf-was-hosting.aspx

 

 

Maintenant le moyen le plus simple d’exploiter WAS reste Windows AppFabric. A suivre justement un article sur ce thème.

 


Poster un commentaire

Edit: Les modèles d’hébergement de Web Api et SignalR

Edit: j’ai ajouté OwinHost à la version précédente de l’article ainsi que les cas du service Windows.

 

Pour reprendre la terminologie WCF, on parle de self-hosting au sujet d’une application qui n’est pas hébergée par IIS, mais par un autre processus.

Web API et SignalR font partie de ces applications agnostiques quant au choix de leur hôte. Cet article a pour objet de monter comment mettre en œuvre concrètement l’hébergement de Web API dans 5 environnements différents:

  1. IIS
  2. Application Console
  3. Azure Worker Role
  4. OwinHost.exe
  5. Service Windows

 

Le déploiement de SignalR est strictement identique.

Lire la suite


Poster un commentaire

Alors asmx ou svc?

Cet article est le quatrième d’une série:

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

 Les services Web est une ancienne technologie d’avant l’arrivée de WCF. Le principal avantage des services web est la facilité de mise en œuvre. Pas ou très peu de paramétrage.

Cette technologie est maintenant considérée comme obsolète et il est préférable d’utiliser des services WCF.

Les services WCF remplacent totalement les services Web, mais vont bien au-delà :

·         Hébergement dans d’autres hôtes que IIS ou Was (Console, Winforms, Service Windows…)
Les Service Web sont dépendant de la pile des appels d’Asp.Net.
Vous pouvez vous en convaincre en ajoutant à votre projet HostAsmx un fichier Global.asax et en plaçant un point d’arrêt dans BeginRequest par exemple.
A chaque appel du service le point d’arrêt est invoqué.

Les services WCF emportent leur propre pile d’appel (les bindings) qui est indépendante de l’hôte. Il est toutefois possible d’ajouter à la pile d’appel WCF la pile d’appel Asp.Net en fixant le paramètre de configuration aspNetCompatibilityEnabled à true.

·         Asmx est limité à des connexions http, WCF gère n’importe quel protocole

·         Apports de WCF comme la sécurité, authentification, divers formats de sérialisation…
Je parle d’apports natifs, on peut le faire en Web Service, il faut juste fournir son propre code.
Avec WCF il ne s’agit que d’une question de codage.

·         La sérialisation en WCF est également plus performante que celle des services Web

La vraie difficulté de WCF est celle inhérente à WCF : c’est vite compliqué et verbeux, mais depuis WCF 4.0 de nombreuses possibilités de configurations par défaut permettent de se rapprocher de la simplicité d’asmx.

Si vous souhaitez en savoir plus ce PDF devrait répondre à vos questions :

http://www.bishoylabib.com/2009/08/comparing-asmx-and-wcf.html

Ou encore :

http://blog.psychocoder.net/2011/04/15/differences-between-asp-net-web-service-and-wcf-services-part-ii

 Pour un nouveau projet vous devez donc résolument utiliser svc a priori. Dans le cas où tout cela vous semble compliqué alors que sur le fond seul un environnement Web vous intéresse, penchez-vous vers des frameworks simplificateurs comme les Web Api.

C’est une des nouveautés de .Net.


Poster un commentaire

Se passer de fichier svc

Cet article est le troisième d’une série:

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

En général ce fichier ne contient pas grand-chose, juste quelques configurations qui pourraient tout aussi bien trouver leur place dans le fichier de configuration.

C’est justement une des nouvelles fonctionnalités de WCF 4.

Comme précédemment créons un projet Web appelé Host. Ajoutons aussi une référence à System.ServiceModel.

Dans le répertoire Services on va ajouter IDemoWcfService ainsi que DemoWcfService.cs. La seule différence est que l’on n’a pas de fichier svc. On en profite pour adapter les espaces de noms.

Ouvrons le fichier web.config et ajoutons cette déclaration.

<system.serviceModel>

    <serviceHostingEnvironment>

        <serviceActivations>

            <addrelativeAddress=« Services/DemoWcfService.svc« service=« Host.Services.DemoWcfService«  />

        </serviceActivations>

    </serviceHostingEnvironment>

</system.serviceModel>

 C’est terminé, le service est prêt à être consommé à l’adresse ~/services/DemoWcfService.svc.

Si on souhaite rendre publiable les métas données afin que le client construise automatiquement le proxy, il faut ajouter un behavior selon une des méthodes indiquées sur la page qui s’affiche :

<behaviors>

        <serviceBehaviors>

          

            <behaviorname=«  »>

                <serviceMetadatahttpGetEnabled=« true«  />

            </behavior>

        </serviceBehaviors>

    </behaviors>

Et hop :

bb

Coté code client rien de très différent:

nn

Bien sûr un point de communication adapté à notre contexte doit être configuré. On le fera comme précédemment avec un SeviceHostFactory déclaré ainsi :

<serviceHostingEnvironment>

    <serviceActivations>

        <add

factory=« System.ServiceModel.Activation.WebScriptServiceHostFactory« 

relativeAddress=« Services/DemoWcfService.svc« 

service=« Host.Services.DemoWcfService«  />

    </serviceActivations>

</serviceHostingEnvironment>

 

Et tout doit fonctionner.


Poster un commentaire

Programmation avec un fichier svc

Programmation avec un fichier svc

Cet article est le deuxième d’une série:

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

Démarrons de la même façon avec un projet web vide appelé par exemple HostSvc (mais on pourrait recycler le projet précédent, svc et asmx cohabitent sans problèmes).

Les services déclarés avec un fichier svc sont également appelé Service WCF. Ils utilisent en effet la plomberie WCF.

Notre premier service

Cette fois nous allons créer un service WCF DemoWcfService. Pour l’instant les choses semblent similaires à ce que nous avons précédemment vu avec les Web Service:

a

Et :

z

Un fichier svc réduit à une seule ligne de directive :

<%@ ServiceHost Language= »C# » Debug= »true » Service= »HostSvc.Services.DemoWcfService » CodeBehind= »DemoWcfService.svc.cs » %>

Cela ressemble pas mal à un fichier asmx, la directive est différente, c’est ServiceHost.

Et puis un code behind avec sa déclaration dans la directive. On pourrait également mettre le code directement dans le fichier svc, mais ce n’est pas considéré comme une bonne pratique.

On remarque également l’apparition d’une interface décorée de divers attributs :

[ServiceContract]

publicinterfaceIDemoWcfService

{

    [OperationContract]

    void DoWork();

}

Le code behind est lui très simple :

publicclassDemoWcfService : IDemoWcfService

{

    publicvoid DoWork()

    {

    }

}

On décortiquera plus loin, commençons par vérifier que tout cela marche, mais je vais transformer un peu le service pour le rendre plus intéressant.

L’opération DoWork retourne une String :

[ServiceContract]

publicinterfaceIDemoWcfService

{

    [OperationContract]

    string DoWork();

}

Et bien sûr :

publicclassDemoWcfService : IDemoWcfService

{

    publicstring DoWork()

    {

        return« Bonjour à qui le lira! »;

    }

}

Tester le service

Microsoft fournit un outil de test des clients WCF relativement rudimentaire : wcftestclient.exe que l’on peut lancer depuis une ligne de commande.

http://msdn.microsoft.com/fr-fr/library/bb552364.aspx

et :

http://a1ashiish-csharp.blogspot.com/2012/01/cnet-how-to-test-wcf-web-service-in.html

Mais je le trouve un peu trop rustique et recommande d’autres outils comme SoapUI ou WCFStorm qui a une interface très intuitive en plus.

Note : OK c’est payant. Et alors ? Dans un bilan on doit aussi se demander ce que ça rapporte. C’est le genre de subtilité que certains ne comprennent pas.

Si l’outil de test de Microsoft daigne démarrer vous obtenez ceci :

e

Pour tester on peut double cliquer sur DoWork() puis le bouton Invoke :

r

L’onglet Xml nous affiche la requête et la réponse reçue.

Bref c’est plutôt cool, ça marche du premier coup !

Note : Si le service de test ne démarre pas, cette lecture peut vous aide :

http://msdn.microsoft.com/en-us/library/bb552363.aspx

Il n’est pas non plus interdit de déployer dans IIS et invoquer :

http://localhost/HostSvc/services/demowcfservice.svc

t

Normalement on doit pouvoir tester une opération avec l’url :

/Services/DemoWcfService.svc/DoWork

Pour que ça marche on doit décorer l’opération avec WebGet :

namespace HostSvc.Services

{

[ServiceContract(Namespace = « DemoWcfService »)]

publicinterfaceIDemoWcfService

{

    [OperationContract, WebGet()]

    string DoWork();

}

}

Note : Il faudra référencer la dll System.ServiceModel.Webb.dll

L’attribut WebGet indique qu’une opération de service peut être appelée par le modèle de programmation REST.

Et on obtient :

u

Si un format JSON ne vous convient pas, on peut sérialiser en Xml avec WebGet.

Consommer le service depuis une page web

Justement écrivons en une. Pour cela on a besoin d’une page web, Default.aspx.

Avant de se lancer dans l’aventure du code client examinons de plus près un détail dans la description du service WCF en cliquant sur le deuxième lien de la page vue tout à l’heure :

y

L’espace de nom n’est pas JavaScript-Very-Cool, on va changer les choses en éditant IDemoWcfService et le modifiant légèrement :

[ServiceContract(Namespace = « DemoWcfService »)]

publicinterfaceIDemoWcfService

{

    [OperationContract]

    string DoWork();

}

Et cette fois la vie est plus rose:

o

Côté client on reprend le même code Htmlque le projet asmx et on pose un ScriptManager :

<asp:scriptmanagerID= »Scriptmanager1″runat= »server »>

    <Services>

        <asp:ServiceReferencePath= »~/Services/DemoWcfService.svc »/>

    </Services>

</asp:scriptmanager>

Les adeptes du copier-coller ferons attention à bien changer le nom du service.

Côté JavaScript, les choses ressemblent à ça :

<script>

    function onClick() {

        var proxy = new DemoWcfService.IDemoWcfService();

        proxy.DoWork(OnComplete);

        returntrue;

    }

 

    function OnComplete(args) {

        alert(args);

    }

</script>

On instancie un proxy. Puisque seul le contrat est porté à la connaissance d’un service Wcf, on a bien IDemoWcfService et non pas DemoWcdService.

Côté client le code est identique au cas des Web Services, on passe par un proxy puis on invoque la méthode du service qui nous intéresse et que le proxy expose.

A ce stade vous constaterez toutefois que ça ne marche pas ! Il manque un truc.

Ça ne marche pas parce que comme toujours avec WCF on doit configurer un point de connexion (endpoint).

On peut donc le faire classiquement directement dans le fichier de configuration, nous verrons comment plus loin.

Les versions récentes de WCF proposent des simplifications.

On peut aussi utiliser une des fabriques (ServiceHostFactory) prédéfinies pour créer pour nous l’environnement nécessaire. C’est ce que nous allons faire en éditant le fichier svc :

<%@ServiceHostLanguage=« C#« Debug=« true« Service=« HostSvc.Services.DemoWcfService« CodeBehind=« DemoWcfService.svc.cs« 

    Factory=« System.ServiceModel.Activation.WebScriptServiceHostFactory« 

    %>

WebScriptServiceHostFactory est un ServiceHostFactory personnalisé qui embarque toutes les configurations nécessaires pour que le service WCF fonctionne dans IIS en ajoutant automatiquement un WebScriptEndpoint au service.

Si vous avez besoin d’en savoir plus :

http://msdn.microsoft.com/fr-fr/library/bb410780.aspx

Dans tous les cas, vous devriez constater que tout fonctionne maintenant.

On pourrait, comme pour les web service, consommer le service en JQuery. Le code est en tout point similaire à celui développé dans la section asmx. POST et sérialization JSON.

Consommer le service depuis une application console

On va réutiliser l’application console créée dans la section sur les web services.

Important : WebScriptServiceHostFactory n’est pas prévu pour ce scénario. Il faudra créer à la main les endpoints comme nous le verrons dans la section qui suit.

Depuis le projet console, on fait Add Service Reference :

p

On change le namespace par défaut et on clique sur Discover/Services in solution :

On sélectionne le service svc :

q

On termine avec OK. Diverses transformations sont apportées par VS. Il apparaît un répertoire Service References :

s

Si vous souhaitez voir le code du proxy, cliquez sur le bouton Show All Files et développez MonserviceWcf puis Reference.svcmap.

d

Ne pas modifier ce code à la main. En cas d’accident on peut le régénérer avec la commande du menu contextuel Update Service Reference.

Notez au passage que le fichier de configuration est inchangé.

On peut à tout moment modifier les caractéristiques de cette référence via le menu contextuel Configure Service Reference:

f

On teste avec le code suivant :

using (var proxy2 = new MonServiceWcf.DemoWcfServiceClient())

{

    string message2 = proxy2.DoWork();

    Console.WriteLine(message2);

}

Notez que la classe proxy a héritée du suffixe Client.

Le fichier de configuration

Son contenu va dépendre de la version de .Net avec laquelle on travaille.

En .Net 4.0 il présente cette allure :

g

En réalité on pourrait parfaitement le supprimer, toute la configuration est faite automatiquement par la factory déclarée dans le fichier svc qui se charge de créer des endpoints par défaut. Dans notre cas le binding est basicHttpBinding. On pourrait donc tout à fait ajouter ceci :

<services>

    <servicename=« HostSvc.Services.DemoWcfService« >

        <endpointaddress=« /Services/DemoWcfService.svc« 

            binding=« basicHttpBinding« 

            contrac</services>

Notez bien l’adresse relative, sinon cela ne marche pas. Cela vient du multipleSiteBindingEnabled qui vaut true.

Cette option nous permet d’héberger plusieurs services avec la même adresse de base avec le même protocole.

Intéressons-nous tout d’abord au behavior.

h

SeviceMetaData fournit des informations relatives à la publication des métas données du service. C’est le service MEX auquel on accède via la commande wsdl de la querystring.

httpGetEnabled indique que l’on peut accéder à MEX via une requête http de verbe GET, c’est-à-dire via cette adresse :

http:/localhost :XXXXX/Services/DemoWcfService.svc?wsdl

Le service MEX est utile pour permettre à un client de découvrir automatiquement les opérations d’un service en fournissant un fichier descriptif au format SOAP.

ServiceDebug spécifie les informations de débogage.

Reste AspNetCompatibilityEnabled. C’est un peu long à expliquer, mais ce très bon article que j’ai bien envie de traduire un de ces jours, le fera pour moi:

http://blogs.msdn.com/b/wenlong/archive/2006/01/23/516041.aspx


Poster un commentaire

Programmation des asmx

Programmation des asmx

Cet article est le deuxième d’une série.

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

Notre premier service

Les services Web sont hébergés dans IIS comme le suggère le nom, on a donc besoin de créer un projet Web vide, appelons le HostAsmx.

J’aime bien poser mes services dans un répertoire dédié, par exemple Services. Dans ce répertoire ajoutez un item Web Service que nous appellerons DemoWebService.asmx.

Vous faites Add/New Item et choisissez Web Service :

a

On arrive à ceci :

z

VS nous a donc créé un fichier asmx plus un fichier de code behind avec l’extension cs. Le fichier asmx est celui-ci, juste une directive de WebService :

 <%@ WebService Language= »C# » CodeBehind= » DemoWebService.asmx.cs » Class= »HostAsmx.Services. DemoWebService  » %>

 On pourrait, je ne le conseille pas, supprimer le code behind et y mettre directement le code C#.

Le code behind ressemble à celui-ci :

e

Nous le reverrons plus loin, notons juste qu’il expose une seule opération : HelloWorld, pour l’instant testons ce service.

Note : une bien meilleure pratique reste tout de même d’héberger le code behind dans une librairie dédiée. Le fichier asmx se contentera de la référencer.

Tester le service

Le plus direct est de faire F5 pour lancer le fichier asmx. On aboutit sur une page similaire à celle-ci :

r

Il y a autant de lien que d’opérations prises en charge dans le code behind, une seule ici. Si je clique sur ce lien j’arrive sur une page de test.

a

L’affichage obtenu en cliquant sur Appeler dépend du mode de sérialisation.

On pourrait aussi réclamer la description du service en cliquant sur le lien correspondant de la première page :

z

Il s’agit d’un fichier au format SOAP qui peut permettre à une application cliente de créer un proxy afin de communiquer avec notre service. En faisant défiler cette page vous retrouverez la description de l’opération HelloWorld.

On obtient ce genre d’information en invoquant le service avec une querystring comportant juste WSDL. Dans mon cas l’url ressemble à ça :

http://localhost:35196/Services/DemoWebService.asmx?WSDL

 Les services asmx activent par défaut le service de découverte, mais nous verrons que pour les services WCF il faut faire l’activation explicitement.

Note : si vous souhaitez déployer le projet sur IIS, plutôt que IIS Express ou Cassini, il faudra lancer VS en mode administrateur.

Consommer le service depuis une page web

Evidemment en pratique ce n’est pas ainsi que l’on consomme un Web Service. On va en principe consommer un Web Service depuis une page web par exemple.

La page appelle le service via un objet spécialisé appelé : un proxy. Un proxy est une classe qui va fournir une abstraction côté client d’une classe serveur. En gros tout se passe comme si le client instancie la classe de service côté serveur et appelle ses méthodes. Dans les coulisses la classe proxy active une plomberie qui va exécuter le code appelé côté serveur.

Reste à créer ce fameux proxy.

 Ajoutons une page appelons la Default.aspx.

Il y a principalement deux façons de créer un proxy : avec Ajax ou avec JQuery. Bon Ok, il y en a d’autres, mais ce sont les deux mieux outillées.

On verra JQuery plus loin, attaquons avec Ajax. Ajax met à notre disposition le composant ScriptManager qui entre autre tâche est capable de créer pour nous un proxy client vers le service et en toute transparence.

Pour en savoir plus sur le ScriptManager :

http://msdn.microsoft.com/fr-fr/magazine/cc163354.aspx

http://www.wrox.com/WileyCDA/Section/Using-the-ASP-NET-AJAX-ScriptManager.id-305492.html

 On configure le ScriptManager ainsi :

    <asp:scriptmanagerrunat= »server »>

        <Services>

            <asp:ServiceReferencePath= »~/Services/DemoWebService.asmx »/>

        </Services>

    </asp:scriptmanager>

 

Et c’est terminé en fait !

Un peu de codeHtml  tout de même, par exemple ceci :

<inputid= »Button1″type= »button »value= »button »onclick= »return onClick();« />

Puis dans une balise script:

function onClick() {

    HostAsmx.Services.DemoWebService.HelloWorld(OnComplete);

    returntrue;

}

 

function OnComplete(args) {

    alert(args);

}

 Notez bien la première ligne dans onClick, c’est ici qu’à lieu l’appel au service Web. Le ScriptManager a créé pour nous, dans les coulisses, un proxy DemoWebService qui expose l’opération HelloWorld. Le code JavaScript  est similaire à celui que l’on pourrait écrire côté serveur, c’est l’intérêt du proxy.

 Si vous testez vous recevez normalement un message d’erreur qui peut être celui-ci:

Erreur d’exécution JavaScript: « HostAsmx » est indéfini

Et oui, pour être appelé via Ajax on doit ajouter un attribut ScriptService à notre service :

e

Comme l’indique la documentation MSDN cet attribut : indique qu’un service Web peut être appelé à partir d’un script.

On ne peut faire plus clair. Pour en savoir plus :

http://www.codeproject.com/Articles/521723/Webservice-and-Scriptservice

 Et cette fois tout fonctionne !

Notons plusieurs détails :

·         On reçoit le retour du service Web non pas directement, mais dans ne méthode de rappel (OnComplete dans notre exemple). L’appel d’un service Web est en effet asynchrone.

·         On pourrait également ajouter une méthode appelée spécifiquement en cas d’échec de la communication avec le service.

·         Ouvrez également le fichier web.config. Vous ne remarquez rien ? C’est normal, il n’y a rien de spécial dedans. C’est une des grandes forces des Web Services, ça fonctionne et c’est tout.

  On ne va pas se quitter tout de suite, essayons de consommer notre service depuis JQuery.

JQuery offre deux méthodes intéressantes : JQuery.ajax() et JQuery.JSON(). On va essayer avec la première.

Je créée donc une page Default2.aspx identique à la première en ce qui concerne le code Html du moins.

<body>

<formid= »form1″runat= »server »>

 

<div>

    <inputid= »Button1″type= »button »value= »button »onclick= »callSvc();« />

</div>

</form>

</body>

Par défaut le service web est appelé en POST, si on préfère GET il suffit de décorer l’opération avec  l’attribut :

[ScriptMethod(UseHttpGet = true)]

 Et dans ce cas on appelle le service ainsi :

function callSvc() {

    $.ajax({

        type: « GET »,

        url: « /Services/DemoWebService.asmx/HelloWorld »,

        data: «  »,

        contentType: « application/json; charset=utf-8 »,

        dataType: « json »,

        success: function (data, status) {

            alert(data.d);

        },

        error: function (request, status, error) {

            alert(request.responseText);

            //alert(status);

            //alert(error);

        }

    });

}

 

Notez que le retour vient de la propriété « d » de data ainsi que la façon dont on appelle la méthode.

Par défaut la sérialisation est JSON comme indiqué dans le script, mais si on préfère XML il suffit de décorer notre méthode ainsi :

 [ScriptMethod(ResponseFormat = ResponseFormat.Xml)]

 

Les détails sont ici :

 http://msdn.microsoft.com/fr-fr/library/system.web.script.services.scriptmethodattribute.aspx

 

 Et le script d’appel devient:

 

function callSvc() {

    $.ajax({

        type: « POST »,

        url: « /Services/DemoWebService.asmx/HelloWorld »,

        data: «  »,

        contentType: « text/xml; charset=utf-8 »,

        success: function (data, status) {

            alert(data.text);

        },

        error: function (request, status, error) {

            alert(request.responseText);

            //alert(status);

            //alert(error);

        }

    });

}

 

Cette fois c’est la propriété « text » de data qui nous intéresse.

Un dernier point. La déclaration de contentType est en pratique facultative, la plomberie JQuery fait une détection automatique.

Consommer le service depuis une application console

Nous allons créer un projet appelé ConsoleClient.

 On doit là aussi créer un proxy. Pour cela on dispose de l’outil svcutil.exe, mais on peut aussi demander à VS de faire le boulot et c’est ce que nous allons faire.

Jusqu’à VS 2008 on disposait du menu Add Web Reference pour créer un proxy vers un service asmx. Ce menu a depuis migré dans une des options de Add Service Reference afin de souligner que Add Web Reference est maintenant une méthode obsolète.

 On choisit ConsoleClient puis dans le menu contextuel du projet Add Service Reference. Cette fenêtre s’ouvre :

t

Cliquer sur Advanced :

y

On clique sur Add Web Reference :

u

Puis enfin Web Service in this Solution. On sélectionnera le service exposé par Hostasmx puis on clique sur Add Reference. On peut aussi modifier le nom du service, nous allons garder localHost.

i

Le projet a été quelque peu modifié.

o

Le paramètre URL Behavior = Dynamic indique que les paramètres de la référence web sont copiés dans le fichier de configuration et non pas codés en dur.

p

Pour tester vous n’avez plus qu’à saisir le code suivant :

localhost.DemoWebService proxy = new localhost.DemoWebService();

string message = proxy.HelloWorld();

 

Console.WriteLine(message);

 Extrêmement simple comme vous le voyez.

Note : Je vois beaucoup de développeurs écrire laborieusement Console.WriteLine….. Sachez qu’il existe un snipet qui fait le boulot, son nom est cw.

 Revoyons le code-behind

Penchons-nous maintenant sur le code behind que revoici :

[WebService(Namespace = « http://tempuri.org/ &raquo;)]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[System.ComponentModel.ToolboxItem(false)]

// To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line.

[System.Web.Script.Services.ScriptService]

publicclassDemoWebService : WebService

{

 

    [WebMethod]

    publicstring HelloWorld()

    {

        return« Hello World »;

    }

}

La classe WebService offre des possibilités supplémentaires comme l’accès à Session ou Application. Si vous n’en avez pas besoin… il suffit de ne pas la déclarer, elle n’est pas obligatoire.

En fait, n’importe quelle classe décorée de l’attribut WebService et exposant des méthodes publiques décorées de l’attribut WebMethod est un service Web.

Essayer est la meilleure façon de s’en convaincre…

A ces détails près vous constaterez que le code est un code tout à fait normal, la classe DemoWebService pourrait parfaitement être consommée directement.