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.

Dojo + WCF [1ere Partie]

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

Voila déjà plusieurs mois, j’avais une discussion sur les architectures SOA avec Christophe et surtout comment les mettre en œuvre avec les Framework (Ajax) Javascript. A l’époque il démarrait une refonte de sa galerie de photos perso LCCFamilly et souhaitait qu’elle soit Full Ajax.

Sur ce même principe, je me propose aujourd’hui de vous montrer comment interroger un WebService WCF à partir du Framework Dojo ; Faisons un service qui nous donne l’heure et la date courante formatée selon la locale du serveur. On commence par déclarer l’interface de notre service.


[ServiceContract(Namespace="http://www.devolis.com/2009/04/WCFDOJO")]
public interface IClockService
{
[OperationContract]
[WebInvoke(Method = "POST")]
string GetTime();
}

Notez l’utilisation du verbe POST ; Il convient d’éviter le verbe GET comme la peste si vous utilisez Internet Explorer comme client de votre WebService. En effet, sa gestion du cache, fait qu’il n’effectue que le premier appel, puis se contente de renvoyer ce qu’il a en cache.

Puis passons à l’implémentation à proprement dit du service


/// AspNetCompatibilityRequirements n'est utile que si le webservice est hosté dans IIS
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class ClockService : IClockService
{
public string GetTime()
{
return DateTime.Now.ToString();
}
}

Ok, a ce moment précis, il vous est déjà possible de tester le WebService en créant rapidement un projet console et en ajoutant une WebReference sur ce dernier... Je vous laisse le faire de votre coté :)

Passons à notre page web :


<!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');
</script>

<script type="text/javascript">

function GetTime() {
dojo.xhrPost({
url: "ClockService.svc/GetTime",
handleAs: "text",
contentType: "application/json; charset=utf-8",
load: function(response, ioArgs) {
dojo.byId('ServerTime').innerHTML = dojo.fromJson(response).d;
return response;
},
error: function(response, ioArgs) {
alert("Error :" + ioArgs.xhr.status);
return response;
}
});
}

</script>
</head>
<body onload="GetTime();">
<input type="button" value="Time?" onclick="GetTime();" ///>
<div id="ServerTime"></div>
</body>
</html>

Comme vous pouvez le constater, le code est assez concis. Apres avoir déclaré l’utilisation de Dojo 1.3 à partir du CDN de Google, j’ai déclaré une fonction GetTime() qui par le biais d’un XmlHttpRequest (xhr) va demander au WebService de lui retourner le DateTime actuel ; les données sont attendues sous forme de JSon.

Vous remarquerez aussi la construction de l’url d’appel, il s’agit du nom du Service suivit par le nom de la méthode.

Si vous exécutez maintenant la page web, vous recevrez une erreur http 405. En effet pour l’instant Dojo et WCF ne parlent pas encore la même langue. Dojo parle en JSon et WCF en Soap... il va nous falloir configurer le service.

Voici la globalité du ServiceModel que vous trouverez dans votre web.config ou app.config en fonction du type de projet choisit.


<system.serviceModel>

<behaviors>
<serviceBehaviors>
<behavior name="MetaDataBehavior" >
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>

<endpointBehaviors>
<behavior name="ClockServiceBehavior">
<enableWebScript/>
</behavior>
</endpointBehaviors>
</behaviors>

<services>
<service name="WCF_TEST.ClockService" behaviorConfiguration="MetaDataBehavior">
<endpoint address=""
behaviorConfiguration="ClockServiceBehavior"
binding="webHttpBinding"
name="ClockService"
contract="WCF_TEST.IClockService"/>
</service>
</services>

</system.serviceModel>

La principale différence avec la configuration standard est au niveau du binding du endpoint. Par défaut le binding est définit en tant que wsHttpBinding (messages soap) ; Pour parler Json il nous faut choisir le binding webHttpBinding (JSon).

Voila, relancez la page web… tadam… c’est magique.

Dans la prochaine partie de cet article je tacherais de vous montrer comment éviter d’avoir à écrire les blocs de javascript xhrPost en passant par dojo.rpc

Christophe, t’as plus qu’a réécrire LCCFamily :)

Microsoft Web Platform Installer

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

Il y a quelques jours, je suis tombé un peu par hazard sur la page Microsoft Web Platform Installer.

De quoi s'agit-t-il? Sans avoir testé mais d'après les infos qui sont distillées sur ce mini site, cela prend la forme d'un installeur qui vous aidera à mettre en place :

  • Le framework .NET evidemment
  • Le serveur web IIS 7
  • La base relationnelle SQL Serveur
  • Les outils de dev : Visual Studio et Expression Web
  • Et tout un tas d'applications web opensource comme DNN, BlogEngine.NET etc...
  • Et tenez vous bien vous trouverez même des applications qui fonctionnent sous PHP (Acquia Drupal, WordPress etc...)

Personnellement tout cela me fait penser aux initiatives qui furent lancées il y a une petite dizaine d'années en arrière avec des installateurs comme EasyPhp et compagnie... encore une fois, l'histoire se répète!! mais pour le coup, il me semble que c'est plutôt une bonne chose.

Une petite question me traverse l'esprit tout d'un coup; on ne parle pas une seule seconde de WSS dans tout ça... pourtant ça risque bien de faire un peu d'ombre... non?

Quel Framework Ajax choisir ?

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

Dojo est désormais passé en version 1.3 avec son lot de nouveautés que je vous laisse découvrir ici.

Mais ce qui est plus excitant encore (et qui est presque passé inaperçu) c’est la mise à disposition de TaskSpeed, un outil de benchmark des principaux Framework Ajax actuellement disponible [JQuery, Dojo, Prototype, MooTools].

Mais comment benchmarker des Framework qui n’offrent pas tous les mêmes fonctionnalités ? (JQuery n’offre pas de composants graphique par exemple). TaskSpeed propose de les noter sur leur plus petit dénominateur commun, c'est-à-dire la manipulation du DOM HTML.

Sur le site, il est possible à tout un chacun de visualiser les résultats d’une bonne quinzaine de métrique par Framework. J’ai moi-même réalisé le test avec mon navigateur préféré Firefox... (Jérôme, y’a des gens qui ont fait le test avec Opéra... je te jure y’a pas que toi qui l’utilise :) ).

Et le vainqueur est... Dojo bien sur.

Moyenne par rapport au navigateur Résultats FF Résultats IE

Le dernier est JQuery… Au fait, qui peut me rappeler pourquoi Microsoft à choisit ce Framework pour l’intégrer dans son offre Ajax ?

Afin d’assurer la plus grande transparence, il est possible de voir le code exécuté pour chaque test en cliquant simplement sur la cellule au croisement d’un Framework et d’un browser.

PS : Pour ceux qui se demandent comment sont faits les graphs… il s’agit de dojox.gfx.

PS2 : Je vous laisse aussi découvrir par la même occasion quel est le pire navigateur lorsqu’il s’agit de manipuler le DOM.