Discussion :

[montesq]

Déjà peut-on dire que gcalendar fonctionne en REST ? On appelle bien une URL avec des paramètres mais il faut être connecté...

Oui, REST est stateless, mais cela ne veut pas dire qu'on ne peut pas sécuriser des appels REST (sinon la portée serait très limitée)
C'est écrit dans la description de l'API: https://developers.google.com/google-apps/calendar/ : "This document describes how to use RESTful calling style"

Tu peux par exemple voir l'explorer d'API:
https://developers.google.com/apis-e...ist.list?_h=4&

[thierryler]

OK avançons donc. Je pense ne pas être le seul que ce sujet intéresse. Tu peux nous proposer d'autres exemples simples et concrets de services REST utilisables en WOA, svp. ?

[montesq]

https://dev.twitter.com/docs/api
https://developer.linkedin.com/rest
https://developers.facebook.com/docs/reference/api/
http://docs.amazonwebservices.com/Am...I/APIRest.html
http://dev.viamichelin.fr/web/api-rest

Bon je m'arrête là, c'est vrai que je n'ai pris que les énormes sites qui font références sur le web, après chacun choisi son camp

Pour finir, Soap est mort, c'est google qui le dit:
https://developers.google.com/soap-search/

[thierryler]

Ce sont des services assez ciblés, que j'aurais tendance à classer dans la même catégorie.

Tu n'aurais pas des exemples de services qui feraient "sérieux" ? Désolé, je n'ai pas trouvé de meilleur mot. Je pense à des trucs bancaires, assurance, financier, sécurités, transport, etc.

En fait, pour l'instant j'ai l'impression que le woa s'applique à des situations qui ne nécessitent pas de synchro. Par exemple j'envoie un message à Twitter et il apparaîtra quand bon lui voudra.

[montesq]

Je n'ai pas le temps de chercher de suite (et je ne suis dans aucun de ces milieux), mais voici quelques éléments de réponse:
https://developer.axabanque.fr/api/index.html

Ceci dit, les secteurs que tu cites ne sont pas forcément ceux qui innovent le plus dans l'IT.
Facebook, linkedin, Twitter sont en train de défricher le terrain pour permettre une adoption plus large dans le futur...

[souviron34]

En fait, pour l'instant j'ai l'impression que le woa s'applique à des situations qui ne nécessitent pas de synchro. Par exemple j'envoie un message à Twitter et il apparaîtra quand bon lui voudra.

et ça, c'est pas vraiment nouveau et ne nécessite pas quelque chose de nouveau.. Asyncrhonous communications via sockets est la base depuis plus de 25 ans

[kastelpaol]

Bonjour,

Autres avantages des architectures Web qui n'ont pas été évoqués ici :

- L'absence de stockage de session coté serveur qui permet d'éviter l'affinité de session pour les architecture haute disponibilité à répartition de charge sur plusieurs serveurs (quand l'utilisateur a créé sa session sur le serveur 1, toutes les requêtes suivantes doivent être dirigées vers ce serveur pour retrouver la session).
Cela permet de gagner en performances : pas d'analyse de cookie, d'adresse ip pour savoir sur quel serveur aller, le répartiteur de charge fonctionne plus rapidement.
Le serveur d'application peut être plus léger, on peut même se passer de moteur de servlet (ex play framework), et même avec des gros serveurs d'applications type websphere, on a moins de mémoire consommée car il n'y pas de session à stocker.
Enfin l'application est plus robuste car quand un serveur tombe, le flux est traité par n'importe quel autre serveur disponible et l'utilisateur n'a pas à se reconnecter pour créer une nouvelle session.

Bien entendu cela ne veut pas dire qu'il y a pas de session utilisateur, elle est simplement gérée/stockée coté navigateur. En clair pour les sites non sensibles, dans un jeton cryptographique si les données sont à protéger.

- La scalabilité : Une architecture WOA est plus scalable qu'une architecture classique grâce à la suppression de l'affinité de session et à l'utilisation de bases NOSQL qui suppriment/limitent la pose de verrous (relaxation transactionnelle). La scalabilité est donc quasiment infinie, "il suffit" d'ajouter des serveurs et des nœuds à la base NOSQL pour augmenter les capacités à traiter une plus grande volumétrie.
Généralement aussi on ne retrouve pas les problèmes de dimensionnements de pool/datasources et autres containers qui limitent la monté en charge (en cas d'affluence sur un site il faut redimensionner tous ces pools).

- Enfin avantage de réaliser l'orchestration de services sur le navigateur par opposition à le faire coté serveur : Si un des partenaires ralentit (augmentation des temps de réponse), des threads vont attendre jusqu'au timeout paramétré et en attendant ils sont bloqués et indisponibles pour traiter d'autres requêtes.
Sur un site fortement sollicité, on peut arriver à rendre tout le service indisponible même si le service défaillant est mineur ou peu important.
En WOA c'est le navigateur qui attend, aucun thread bloqué coté serveur, les utilisateurs qui n'ont pas besoin du service en question fonctionnent correctement.

Bien évidemment ce n'est pas sans contrepartie, la conception est plus complexe à cause des mécanismes de compensation fonctionnelle à créer, des cas d'erreurs à gérer correctement. Mais on y gagne en robustesse en disponibilité et en expérience utilisateur.

[thierryler]

L'absence de stockage de session coté serveur qui permet d'éviter l'affinité de session pour les architecture haute disponibilité à répartition de charge sur plusieurs serveurs (quand l'utilisateur a créé sa session sur le serveur 1, toutes les requêtes suivantes doivent être dirigées vers ce serveur pour retrouver la session).

Effectivement. Et l'utilisateur n'a donc plus besoin de refaire le processus de connexion et d'initialisation de ses paramètres... Sur ce point, je ne vois pas en quoi ce serait un avantage, du coup, de changer de serveur. D'autant qu'on peut supposer que la charge est globalement uniformément répartie sur l'ensemble des serveurs (en fonction de la charge de chacun) lors de l'arrivée de l'utilisateur. Changer de serveur ne change donc en aucun cas la charge globale. Mais effectivement, on peut dire que les sessions étant supprimées après traitement, on va gagner en mémoire. mais on va reperdre à chaque requête... En outre, le serveur peut te donner une page et continuer à préparer les suivantes pendant le temps mort...

La scalabilité : Une architecture WOA est plus scalable qu'une architecture classique grâce à la suppression de l'affinité de session et à l'utilisation de bases NOSQL qui suppriment/limitent la pose de verrous (relaxation transactionnelle). La scalabilité est donc quasiment infinie, "il suffit" d'ajouter des serveurs et des nœuds à la base NOSQL pour augmenter les capacités à traiter une plus grande volumétrie.

Parce que quelque chose empêche de faire du nosql avec une archi classique ? Ah bon ?... Et parce que Nosql tient mieux la charge qu'un pool Oracle ? Dans quelles proportions ?

Enfin avantage de réaliser l'orchestration de services sur la navigateur par opposition à le faire coté serveur : Si un des partenaires ralentit (augmentation des temps de réponse), des threads vont attendre jusqu'au timeout paramétré et en attendant ils sont bloqués et indisponibles pour traiter d'autres requêtes.

Ah bon ?... là non plus je n'ai pas le droit de faire d'Ajax (pas exemple) avec une archi classique ?

Bien évidemment ce n'est pas sans contrepartie, la conception est plus complexe à cause des mécanismes de compensation fonctionnelle à créer, des cas d'erreurs à gérer correctement.

Pas forcément si grave en fait... mais effectivement il y a un risque.

Mais on y gagne en robustesse en disponibilité et en expérience utilisateur.

A démontrer...


PS : tu le lances dans quoi, toi, le play ? genre la techno ultime que tout le monde connait, qui n'a pas de point faible et qui ne coûte pas du tout super cher.

[kastelpaol]

Salut Thierry,

Évidemment que tu peux prendre quelques principes sur une architecture classique. En général on commence par quelques services REST sur serveurs d'applications classiques invoqués par de l'AJAX pour voir si on gagne quelque chose. Les bases NOSQL c'est pour les puristes ou ceux qui doivent supporter une très forte charge et/ou une très forte volumétrie de données car c'est difficile d'abandonner les transactions, le two phase commit et les relations entre entités des bases relationnelles.

Je peux dire que les problèmes de scalabilité, d'affinité de session, de dimensionnement des pools je suis dedans jusqu'au cou... Et pourtant les sites de ma boite (quelques dizaines de milliers d'utilisateurs simultanés en pointe) sont loin des géants du web qui font de la WOA (plusieurs dizaines de millions d'utilisateurs simultanés) et pourtant c'est déjà difficile à maintenir dispo et l'infra coute très cher. C'est pour cela que je m’intéresse à ces principes.

Au niveau du coût, je ne pense pas que ce soit moins cher à court terme, on y gagne en infra (machines, licences) car on peut remplacer les gros serveurs AIX, Z/OS, HP, cluster Oracle et autres équivalents par des serveurs plus petits et plus nombreux et supprimer la plupart des licences logicielles. En revanche, là où ça coute plus cher, ce sont les RH car il est nécessaire d'embaucher des très bons développeurs et concepteurs d'application et les projets ne sont pas forcement plus courts. Pour moi le vrai gain est sur la disponibilité et les performances que l'on offre aux utilisateurs et sur la capacité à évoluer à moyen/long terme.

Donc techno ultime, certainement pas. Cependant si les gros acteurs du Web se sont lancés la dedans ce n'est pas pour rien, ils ne peuvent pas faire autrement. Et si on dit que gmail et Amazon ne sont pas des sites sérieux avec des vraies "transactions" métier qui doivent impérativement aller au bout, ce serait un peu exagéré...

Je parlais de play car c'est le seul que je connais un peu et je sais qu'il motorise depuis peu une partie de linkedin mais il y en a d'autres (Ruby on Rails, Django, ...).

bye

[thierryler]

Tu aurais des chiffres, même approximatifs, pour illustrer les différences ? Pour donner un ordre d'idée surtout.

[souviron34]

- L'absence de stockage de session coté serveur qui permet d'éviter l'affinité de session
...
- La scalabilité :
..
- Enfin avantage de réaliser l'orchestration de services sur le navigateur par opposition à le faire coté serveur :

Euh.. Regarde l'architecture d'un serveur X et du protocole X :

• scalabilité
• ajout de service se fait par xhost+
• pas de stockage de sessions : DISPLAY=adresse_ip

Quant aux services standards, toute architecture multi-serveurs correctement pensée quel que soit le modèle, par exemple bêtement les grappes à base de sockets, ont des fichiers de config (listes) du côté client..

[kastelpaol]

Bonjour,

Tu aurais des chiffres, même approximatifs, pour illustrer les différences ? Pour donner un ordre d'idée surtout.

Quelques chiffres, ce n'est pas très précis et souvent se sont des estimations. En tous cas ça n'a rien à voir avec ce je vois dans mon entreprise ^^

Facebook (avril 2012)
http://blog.lefigaro.fr/medias/2012/...iffres-et.html
=> Il n'y a pas le nombre d'utilisateurs simultanés en pointe mais il est indiqué 526 millions d'utilisateurs quotidien. C'est pas mal

http://www.toutfacebook.fr/20-statis...ook-debut2012/
=> 250 millions de photos stockées par jour ! Mille milliards de pages vues par mois.

Chiffres Google
http://www.webrankinfo.com/dossiers/.../chiffres-cles
=> 850 teraoctets de données pour le cache (chiffre 2006, ça a du exploser depuis)

Chiffres généraux nombre de serveurs
http://www.scriptol.fr/web/serveurs.php (un peu obsolète car date de 2010)

Ce ne sont pas des ordres de grandeur gérables avec les architectures Web classiques.

Euh.. Regarde l'architecture d'un serveur X et du protocole X :

• scalabilité
• ajout de service se fait par xhost+
• pas de stockage de sessions : DISPLAY=adresse_ip

Quant aux services standards, toute architecture multi-serveurs correctement pensée quel que soit le modèle, par exemple bêtement les grappes à base de sockets, ont des fichiers de config (listes) du côté client..

La WOA est quand même plutôt adaptée au Web, c'est à dire tout ce qui s'affiche dans un navigateur avec tous les avantages que cela procure (plus ou moins un standard mondial, pas de client lourd à installer, etc..). Le protocole X n'est pas comparable car il faut déployer le client ce qui n'est pas adapté au Web. De plus, je me trompe peut être mais je ne vois pas 20 millions d'utilisateurs utiliser en même temps la même application X pointant sur la même base de données relationnelle, ne serait-ce que pour la quantité d'informations (à cause du déport d'affichage en mode BMP) qui doit circuler sur le réseau.

Idem pour les grappes de sockets, qui seraient plutôt adaptées à des clients lourds si j'ai bien compris de quoi tu parles. Même si ça pourrait changer avec l'arrivée des websockets dans les navigateurs.

[thierryler]

Je voulais dire des chiffres pour comparer woa et classique.

[kastelpaol]

Je voulais dire des chiffres pour comparer woa et classique.

Des comparaisons de performances/coûts des deux modèles, non je n'ai pas encore eu l'occasion de comparer et je n'ai pas encore trouver d'éléments sur Internet mais effectivement ça pourrait être intéressant de le faire.

[ironbirdy]

http://blogs.gartner.com/nick_gall/2...-web-services/

[wiztricks]

Salut,

Ce genre de présentations sont très bien pour familiariser les décideurs avec de nouveaux buzz words et essayer de les rassurer en leur montrant que ces technos. s’intègrent bien aux savoirs faire existants.
Ça permet de déblayer le terrain pour que les techos puissent aller se former et qu'on puisse les proposer plus facilement dans des solutions.

Si vous en attendiez plus, vous serez déçus.
Normal, entrer dans les détails techniques pour répondre aux questions des techos est le meilleur moyen pour que les décideurs pensent: immature, complique, pas pour nous,...

- W