Dojo + WCF [2eme Partie]

Publié par Fabrice Michellonet sous le(s) label(s) , le 20 avril 2009

Dans le précèdent billet, je vous avais proposé d’invoquer un service WCF en utilisant les XmlHttpRequest à la sauce dojo (xhrGet et xhrPost).

Bien que cette façon de faire soit bien plus rapide et « élégante » que lorsqu’on doit écrire soit même ce type de code js (avec support des navigateurs browser etc…), il existe une méthode encore plus simple.

Bien, revenons quelques instants sur les services web publiés aussi bien sous forme d’ASMX qu'en WCF, ils ont la bonne idée d’être accompagnés d’une nomenclature les décrivants ; Vous l’aurez compris je parle bien ici du wsdl.

L’intérêt majeur que je vois dans le wsdl est que cela permet de générer automatiquement un proxy qui saura communiquer avec le service web ciblé. D’ailleurs, c’est grâce à cette description que visual studio génère la classe proxy lorsque vous ajoutez une référence web dans votre solution.

L’idée derrière les classes du namespace dojox.rpc est d’avoir ce même comportement en JavaScript, c'est-à-dire, la possibilité d’interroger un service pour connaitre ses caractéristiques et de générer automatiquement un proxy JavaScript simplifiant son utilisation.

Excellent me direz-vous, nous avons déjà le wsdl... arf c’est la que le bas blesse, le xml (et plus spéciale une définition wsdl) n’a jamais été le format le plus simple et le plus rapide à traiter en JavaScript. Par contre, comme vous le savez déjà le json est le format fétiche du web.

C’est donc à partir d’une définition en json respectant le formalisme nommé smd (pour Simple Method Description) que le Framework dojo va vous permettre de générer le proxy JavaScript qui correspondra à votre service web.

Bien trêve de discussion adaptons notre précédent exemple pour l’adapter a cette technique de génération de proxy. Créons la définition du service : 


{
    "transport": "POST",
    "envelope": "URL",
    "target": "http://localhost/WCFDojoRpc/ClockService.svc/",
    "services": {
        "GetTime": {
            "transport": "GET",
            "target": "GetTime",
            "parameters": []
        }
    }
}

On y retrouve facilement les informations relatives a l’adresse du service et la méthode disponible. Pour plus de détail, je vous laisse vous reporter au groupe de travail qui s’intéresse au format smd.

Modifions quelque peu notre script :


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Dojo & WCF</title>

    <script src="http://ajax.googleapis.com/ajax/libs/dojo/1.3.0/dojo/dojo.xd.js" type="text/javascript"></script>

    <script type="text/javascript">
        dojo.require('dojo.parser');
        dojo.require("dojox.rpc.Service");

        var clockProxy;

        dojo.addOnLoad(
            function() {
                clockProxy = new dojox.rpc.Service("definition.json");
                GetTime();
            }
        );

        function GetTime() {
            clockProxy.GetTime()
                .addCallback(
                    function(data) {
                        dojo.byId('ServerTime').innerHTML = data.d;
                    }
                )
                .addErrback(
                    function(data) {
                        alert(data);
                    }
                );
        }    
        
    </script>
</head>
<body>
    <input type="button" value="Time?" onclick="GetTime();" />
    <div id="ServerTime"></div>
</body>
</html>

Comme vous le voyez nous avons principalement retiré l’utilisation des xhrPost, que nous avons remplacés par une simple ligne new dojox.rpc.Service("definition.json"); qui génère le proxy JavaScript automatiquement a partir de la définition en json.

Bien évidement le service WCF reste identique a celui présenté dans la première partie de cet article.

Je retire deux conclusions partielles de l’utilisation des smd :

  • Il est certain que la possibilité de décrire un service facilite ensuite la vie du développeur coté js.
  • Il est dommage de devoir utiliser autre chose que le wsdl qui est généré pour nous, surtout lorsqu’on est un développeur .NET.

Le top serait d’avoir une description smd générée automatiquement à chaque modification de notre service WCF et que ce soit intégré dans le pipeline WCF. C’est ce que je me propose de vous montrer lors de la troisième partie de cet article.

0 commentaire(s)
top