Caching WCF Client-Side

[preti]

Bonjour à tous,
Dans le cadre d’un projet de transformation de données (biztalk 2009)
j’ai développé plusieurs functoids pour faire du mapping de valeur
(type string). Ces functoids appellent une méthode d’un service wcf
pour récupérer une valeur selon un ou plusieurs paramètres. Après
quelques test je me suis rendu compte que ces appels étaient très
couteux.
Je souhaiterai donc pouvoir faire du caching côté client (aujourd’hui
mes functoids, demain une autre appli faisant appelle au même
service). Ceci de la manière la plus générique possible. Serait-il
possible de développer un behavior custom ou quelque chose du genre ?
(en ce qui concerne le caching j’utiliserai l’application block dédié
à cela).

Merci d’avance pour vos idées !

[DUVAL Olivier]

Bonjour,

  Si c'est WCF avec des appels REST, voir pt être du côté du WCF REST Starter Kit prv 2 (http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24644) qui propose un attribut [WebCache], comme avec ce que nous avions pour les WS SOAP / asmx et le CacheDuration.

  @+

2009/10/5 preti <pre...@gmail.com>

--
Olivier DUVAL
http://olivier-duval.info

[preti]

De plus je souhaite vraiment un cache coté client, ne plus passer par
un appel pour accéder à mon service mais directement avoir accès au
cache si l'info est dispo

[preti]

Alors non, c'est pas avec REST :-)

On 5 oct, 15:06, DUVAL Olivier <zork...@gmail.com> wrote:

[Yann Schwartz]

Tu peux essayer d'intercepter avec un IOperationBehavior ou
IParameterInspector, mais il est nettement plus simple (*) d'utiliser
de l'interception classique au niveau du proxy pour ce genre de chose
(via ton framework d'IOC/AOP favori). Comme de toute façon il faut
gérer au niveau du proxy les communicationexceptions et la stupide
implémentation du Dispose() des channels wcf, ce n'est pas vraiment
beaucoup plus compliqué.

Sinon, les problèmes soulevés par le cache ne résident pas dans
l'implémentation, mais dans les heuristiques d'invalidation (quand
doit-on oublier ce qu'on a mémorisé). L'application block de cache
aide un peu pour ça techniquement, mais les choix ne sont pas sans
conséquences et dépendent fortement de ton applicatif.

(*) Je suis peut-être le seul à avoir un problème avec WCF, mais
chaque fois que j'ai dû étendre WCF (couche de sécurité custom, cache,
gestion des FaultContract, compression en TCP, etc.) je me suis tapé
la tête contre le clavier devant l'extrême rigidité et complexité du
mode d'extension. Aucune doc à peu près cohérente sur la séquence
d'appels, deux mille trois cents interfaces à implémenter pour ajouter
un malheureux comportement (genre before/after), pas de contexte quand
on en a besoin. Je crois que ça vient des funestes fondations WS-
staresques de WCF. Suffit de voir à quel point MS a galéré pour
implémenter REST au-dessus de WCF, ce framework qui paraît-il était
tellement universel qu'il permettait de modéliser n'importe quel type
de communication (du moment que c'était WS-*)

[Mathias Kluba]

@Yann: lol j'ai déjà remarqué que tu avais une dent contre WCF... je
n'ai pas trop compris pourquoi, mais c'est sans doute car je n'ai pas
essayé de l'étendre :)
En tout cas, je ne connais pas d'équivalent pour facilité la
communication en .Net, tout en offrant du WS, sécu par Certificat,
Dual Channel, communication binaire ou pipe, et du P2P (de plus, je
trouve l'outil de génération de conf plutôt pas mal, même s'il n'est
pas intégré à VS...)
Ouf... pour une fois que je ne critique pas MS! Le manque de WCF dans
Mono fait aussi partie des choses qui m'empêcherons d'envisager la
solution libre... Quelqu'un connait une ALTernative à WCF?

Pour en revenir au cache: j'ajoute parfois de l'AOP avec Spring.AOP
pour ajouter de l'intelligence. Par exemple: retry de connection et
d'appelle de méthode en cas d'exception WCF.
Comme le dit Yann, il faut penser à l'éviction: comment libérer des
données du cache.

[Yann Schwartz]

On Oct 5, 10:06 pm, Mathias Kluba <mathias.kl...@gmail.com> wrote:
> @Yann: lol j'ai déjà remarqué que tu avais une dent contre WCF... je  
> n'ai pas trop compris pourquoi, mais c'est sans doute car je n'ai pas  
> essayé de l'étendre :)
> En tout cas, je ne connais pas d'équivalent pour facilité la  
> communication en .Net, tout en offrant du WS, sécu par Certificat,  
> Dual Channel, communication binaire ou pipe, et du P2P (de plus, je  
> trouve l'outil de génération de conf plutôt pas mal, même s'il n'est  

> pas intégré ,VS...)

> Ouf... pour une fois que je ne critique pas MS! Le manque de WCF dans  
> Mono fait aussi partie des choses qui m'empêcherons d'envisager la  
> solution libre... Quelqu'un connait une ALTernative à WCF?

Il y a des choses bien en WCF (les contrats, la config), des choses
moins bien (la config...) et des choses proprement wtf-esques
(l'extensibilité, la difficulté de tester, l'usage systématique de WS-
* quand tu voudrais te contenter de quelque chose de léger). Dès que
tu sors de http, en t'éloignant un peu des configs par défaut, tu
t'aperçois que c'est le désert. Le remoting est mort, mais WCF en TCP
est parfois exaspérant. Cela dit, les configs par défaut sont
généralement acceptables.

[Vincent Bourdon]

Hello,

Ton client c'est quoi exactement ? Une appli .net ou une applic html/JS dans un navigateur ?

2009/10/5 Yann Schwartz <abolib...@gmail.com>

[SerialSeb]

Bien sur tu peux passer un certain temps a essayer de reproduire un
cache client avec WCF. Tu finira avec une copie de ce que HTTP fait
gratuitement.

La solution la plus simple c'est de ne pas utiliser de service WCF
pour ca, exposer ces informations en http, et utiliser le caching
existant en http.

Au pire tu peux faire ca avec WCF REST, si tes besoins d'architecture
REST sont tres limites, au mieux il y a d'autres frameworks pour faire
du http *cough*openrasta*cough*.

Seb

> > Olivier DUVALhttp://olivier-duval.info- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

[SerialSeb]

Allez, y a suffisemment dans cet email pour dsicuter...

> tout en offrant du WS,

WS sont un outil, pas une fin en soi.
> sécu par Certificat,  

https fonctionne tout a fait bien avec des client certificates.

> Dual Channel

Utilise habituellement pour faire du pub sub, solutionne par d'autres
outils de facon bien mieux architecte (nServiceBus, MassTransit, etc)

> communication binaire

HTTP peut faire du binaire si necessaire. Pourquoi faire du TCP
directement quand tu peux faire du HTTP en binaire... Le domaine
d'application est tres reduit.

> ou pipe,

Voir plus haut. A voir s'il y a un interet, la plupart des applis que
j'ai cree utilisent HttpListener sur localhost pour la comm, bien plus
facile a gerer / debugger.

> et du P2P

Quelqu'un a deja utilise ca sur une appli d'entreprise? IPv6 et DHT
sur un reseau d'entreprise, sans compter Toredo et al, c'est des mois
de discussion pour un resultat ma fois tres mineur, non?

Je connais bien le marketing MS sur tous ces points. De ce que j'ai vu
dans la plupart des projets sur lesquels j'ai travaille c'est que la
plupart des applications pour lesquelles WCF est preconise sont un
bricolage sur une architecture a revoir.

Suis pas bricoleur pour deux sous quand on parle d'architecture
distribuee. EDA et ReST ought to be enough for everyone :)

Seb

[Yann Schwartz]

On Oct 6, 2:01 pm, SerialSeb <s...@serialseb.com> wrote:
> Allez, y a suffisemment dans cet email pour dsicuter...
>
> > tout en offrant du WS,
>
> WS sont un outil, pas une fin en soi.

Et un outil qui ressemble souvent à un tournevis pour enfoncer des
clous.

> > Dual Channel
>
> Utilise habituellement pour faire du pub sub, solutionne par d'autres
> outils de facon bien mieux architecte (nServiceBus, MassTransit, etc)

D'autant que le pub sub marche pas bien en dual channel (la fiabilité
est toute relative, et le vrai pub/sub par broadcast est une misère à
implémenter en WCF). +1 pour les solutions de messaging.

>
> > communication binaire
>
> HTTP peut faire du binaire si necessaire. Pourquoi faire du TCP
> directement quand tu peux faire du HTTP en binaire... Le domaine
> d'application est tres reduit.

Sauf si on a besoin d'une très faible latence (d'où le choix de TCP)
et d'une bande passante réduite. Pour ce dernier point, il est
carrément préférable de partir sur du protocol buffer que sur du
binary (protobuff propose un formater protocol buffer pour WCF
d'ailleurs).

Seul gros avantage de WCF/TCP : le streaming. Je sais que des
extensions de http traînent ici ou là et que des joyeusetés comme MTOM
rendent théoriquement possible la chose, mais le streaming TCP en WCF
est plutôt bien fait.

>
> > ou pipe,
>
> Voir plus haut. A voir s'il y a un interet, la plupart des applis que
> j'ai cree utilisent HttpListener sur localhost pour la comm, bien plus
> facile a gerer / debugger.

Les communications par pipe sont intéressantes dans les scénarios où
on aurait fait du remoting local (oui, c'est un peu oxymoronesque, je
sais). Cela dit, 99% du temps, http est good enough.

> Je connais bien le marketing MS sur tous ces points. De ce que j'ai vu
> dans la plupart des projets sur lesquels j'ai travaille c'est que la
> plupart des applications pour lesquelles WCF est preconise sont un
> bricolage sur une architecture a revoir.

Ca marche pas mal par défaut, mais le paradoxe de WCF est d'être
terriblement centré sur WS-* tout en regardant de haut la couche de
transport (http). Ce qui est d'ailleurs le péché originel des web
services.

[preti]

Un functoid (biztalk 2009)

On 6 oct, 10:29, Vincent Bourdon <evilz...@gmail.com> wrote:
> Hello,
> Ton client c'est quoi exactement ? Une appli .net ou une applic html/JS dans
> un navigateur ?
>

> 2009/10/5 Yann Schwartz <abolibibe...@gmail.com>

[preti]

Tout d'abord merci pour vos réponses.
J'ajouterai que je suis d'accord avec vous, il me semble que les
reliquats ws restent bien présents sur WCF.
Pour ma part, j'ai décidé de reporter à plus tard la généricité
d'accès au cache et placer cette info au niveau functoid (fin du
sprint approche :-) )

Merci à vous tous.

[SerialSeb]

> > HTTP peut faire du binaire si necessaire. Pourquoi faire du TCP
> > directement quand tu peux faire du HTTP en binaire... Le domaine
> > d'application est tres reduit.
>
> Sauf si on a besoin d'une très faible latence (d'où le choix de TCP)
> et d'une bande passante réduite. Pour ce dernier point, il est
> carrément préférable de partir sur du protocol buffer que sur du
> binary (protobuff propose un formater protocol buffer pour WCF
> d'ailleurs).

Tout a fait d'accord pour protocol buffer. Ceci dit, tu as des
chiffres a partager sur le transfert d'un document binaire sur tcp
compare a http? Je ne suis pas sur pourquoi tcp serait plus rapide que
http, qui n'est apres tout que tcp avec headers. Bande passante
reduite, certes, on touche a des domaines ou d'autres protocoles sont
sans doute mieux adaptes. Ceci dit, il est tres rare que la bande
passante reduite soit un cout suffisent pour justifier le niveau de
complexite / difficulte de debug d'une solution pure binaire TCP.

> Seul gros avantage de WCF/TCP : le streaming. Je sais que des
> extensions de http traînent ici ou là et que des joyeusetés comme MTOM
> rendent théoriquement possible la chose, mais le streaming TCP en WCF
> est plutôt bien fait.

Mais il n'y a pas besoin d'extensions dutout. Le streaming en http est
supporte depuis le debut. Il y a difference entre HTTP et asp.net. Tu
peux faire du streaming en http avec des donnees binaires, ca
s'appelle chunked encoding.

Il est malheureux que la pauvre implementation proposee par MS soit un
point de reference de ce que peut faire la technologie :)

S

[Yann Schwartz]

On 7 oct, 13:48, SerialSeb <s...@serialseb.com> wrote:
> Tout a fait d'accord pour protocol buffer. Ceci dit, tu as des
> chiffres a partager sur le transfert d'un document binaire sur tcp
> compare a http? Je ne suis pas sur pourquoi tcp serait plus rapide que
> http, qui n'est apres tout que tcp avec headers.

Je me suis peut-être mal exprimé, je pensais plus à la latence qu'à la
bande passante. A part les API qui attendent ou exposent un encodage
base64, l'overhead est effectivement négligeable.

> > Seul gros avantage de WCF/TCP : le streaming. Je sais que des
> > extensions de http traînent ici ou là et que des joyeusetés comme MTOM
> > rendent théoriquement possible la chose, mais le streaming TCP en WCF
> > est plutôt bien fait.
>
> Mais il n'y a pas besoin d'extensions dutout. Le streaming en http est
> supporte depuis le debut. Il y a difference entre HTTP et asp.net. Tu
> peux faire du streaming en http avec des donnees binaires, ca
> s'appelle chunked encoding.

Après vérification, le streaming est également supporté en WCF version
httpbinding. Donc effectivement, TCP ne présente pas d'avantage
délirant de ce point de vue.

>Il est malheureux que la pauvre implementation proposee par MS soit un
>point de reference de ce que peut faire la technologie :)

Quand on doit implémenter WCF ou assurer le support sur une appli
utilisant déjà WCF il est parfois difficile de ne pas prendre comme
point de référence la pauvre implémentation proposée par MS.