Techdays 2008: Nom de code Astoria

Astoria: nom de code d'ADO.Net Data Services
Présentée par Mitsuru furuta et pierre lagarde

La webcast de cette session n'est pas encore disponible, c'est dommage car Mitsuru est très interessant.

Ce framework fait partie d'asp.net futures disponible en CTP1. La release est prévue pour mi 2008. Lire le blog de l'Astoria Team pour suivre leur actualité.

Résumé de la session

L'idée de départ est d'exposer sur le web des sources de données requêtables au lieu d'exposer un nombre important de services web.
La réponse technique est de distribuer des expressions Linq par http en s'appuyant sur une architecture REST, rien que ça. Comme on va le voir, cela suppose de pouvoir faire du select/insert/update/delete via une expression Linq dans l'url sur des sources de données...

Côté serveur, Astoria utilise un service WCF générique se branchant sur l'interface IQueryable et s'appuie sur le framework Linq. Les sources de données peuvent donc être de tout type, il suffit d'utiliser le bon provider (LinqToObject, LinqToXml, LinqToSql, LinqToEntities).

Le service implémente IRequestHandler, qui porte les attributs WCF:

[ServiceContract]
public interface
IRequestHandler
{
[WebInvoke(UriTemplate = "*", Method =
"*")]
[OperationContract]
Message ProcessRequestForMessage(Stream
messageBody);
}

Pour le transfert, on s'appuie sur une architecture REST avec les formats ATOM et JSON. JSon est natif depuis le FK3.5 pour WCF.

Côté client, c'est la fête car on s'adresse aussi bien au client léger via le navigateur qu'au client riche type silverlight, WPF, winforms.

Astoria s'occupe de générer les classes proxies pour accéder au service, de même que lorsque l'on ajoute une référence à un web service. Dans ce cas, on peut manipuler la source de données côté client exactement de la même manière que côté serveur via du "LinqToHttp" avec un WebDataContext (au lieu du DataContext de linqtosql ou de l'ObjectContext d'entity framework). On code de la même manière dans les deux couches.

Le paramètre du service générique, pour pouvoir répondre à toutes les requêtes possibles sur un modèle donnée, prend comme paramètre l'expression Linq, qui est donc sérialisée/désérialisée.

L'architecture REST permet de faire du CRUD selon les types de requêtes HTTP:

POST	Create/Update/Delete
GET	Read
PUT	Create/Update
DELETE	Delete

On peut appeler le service par javascript, une bibliothèque est fournie afin de simplifer la vie du développeur. Les appels cross domain sont interdits par javascript, le service astoria doit alors être exposé dans le même domaine pour que ça marche.

L'appel peut également être fait via le code behind.

Pour des questions de sécurité, on a un mécanisme d'interception des requêtes côté serveur par attribut :

[QueryInterceptor("Products")]

L'idée est d'intercepter l'expression linq (donc non encore exécutée côté source de données puisqu'on échange du IQueryable) et de la modifier pour filtrer les données sensibles, par exemple en implémentant du Membership. Cette notion d'interception est reprise dans la session "linq avancée" mais sous un angle de factorisation de code.

En plus du schéma, on peut également exposer des méthodes métiers simplement avec l'attribut:

[WebGet()]

tant que la méthode retourne du IQueryable. On peut donc appeler des méthodes métier par URL.
Ou encore exposer des types customs qui ne sont pas forcément persistés avec des requêtes s'appuyant sur LinqToObject et en les exposant avec la méthode AsQueryable(). La démo montrait comment exposer les process actifs de la machine.

Pour modifier les données, il faut implémenter l'interface IUpdatable.

La version CTP a encore quelques limites, pas de Group By par exemple, mais l'équipe y travaille.


La mise en pratique

Lorsque l'on installe la CTP, chose amusante, on le retrouve sous le répertoire

Microsoft ASP.NET 3.5
Extensions\MicrosoftAjaxLibrary\System.Web.Extensions\3.6.0.0

On est donc en présence du framework 3.6 et non 3.5 donc attention dans le web.config à pointer sur les bonnes versions de l'assembly System.Web.Extensions.

Après avoir installé la CTP, on peut se laisser guider par le starter du site (lire "ADO.Net Data Service" au lieu de "web data service").

Bien que tout repose sur du WCF, il n'est pas nécessaire de spécifier le paramétrage WCF dans le web.config car par défaut il prend un endpoint de binding HTTP.

Pour un premier test, exposez toutes les sources en utilisant "*":

public static void InitializeService(IWebDataServiceConfiguration
config)
{
config.SetResourceContainerAccessRule("*",
ResourceContainerRights.AllRead);

}

Appelez enfin l'URL de la classe .svc crée et ensuite allez lire ce document pour des exemples de syntaxe de requêtage.