Discussion :

[Mickael Baron]

La société So@t, société d'ingénierie et de conseil en informatique vous propose un article sur l'architecture WOA (Web Oriented Architecture).

Il s'agit plus précisément d'une rétrospective de la présentation de Habib Guergachi lors de Devoxx France 2012 dont le titre était : « Web Oriented Architecture, une transmutation des pratiques de construction des systèmes d'information ».

http://soat.developpez.com/articles/...darchitecture/

Vous pouvez profiter de ce message pour partager vos commentaires.

Mickael

[Ludo.G]

Merci, article intéressant.

Pour le moment j'ai un peu de mal à y voir autre chose qu'une archi SOA simplifiée au WEB, mais ca m'a donné envie d'approfondir un peu.

[montesq]

Si je comprends bien, WOA c'est reprendre le principe SOA mais avec du REST à la place du SOAP, non?
Je suis fervent défenseur du REST, cependant, je ne suis pas sûr de comprendre ce que la notion de WOA implique de plus que les principes REST. J'ai un peu l'impression de voir apparaître un nouveau buzzword...

[Reward]

Je vais parler pour mon cas, et plus précisément pour mon domaine d'activité, l'industrie et l'informatique industrielle.

Si sur le papier ce concept a l'air sympa, dans la réalité du monde industriel que je fréquente, c'est juste impossible. Ce n'est pas demain la veille que le web sera l'épine dorsale d'un quelconque système. Le mentalité et les pratiques à ce jour consistant plutôt à le cloisonner voir à le rejeter.

[gagaches]

Ce que je vois dans le "WOA", c'est l'usage global d'un SOA (typé REST plutôt que SOAP) distribué.

Le SOA a un mécanisme { webservice, donnée } mais a été pensé comme figé dans une structure client-serveur classique.

Alors que là, on associe chaque ressource disponible à un couple {webservice, données} pour y accéder dans une philo plus proche du "P2P".

=> c'est l'inversion du sens de production-consommation des données

On ne fabriquerait plus un FRONT -> METIER -> DONNEES
(sens consommateur)

Mais plutôt, on fabriquerait une DONNEES -> WEBSERVICE
(sens producteur)

A la couche métier ensuite d'accumuler les informations nécessaires à son fonctionnement.

Ça me fait aussi penser à la philosophie actuelle sur Open Data

[Traroth2]

Dommage qu'il n'y ait pas de bibliographie. C'est un peu difficile d'approfondir à partir de cet article...

[thierryler]

A noter que les billets de blog, à propos de Devoxx France 2012, sont disponibles ici : http://blog.developpez.com/recap/jav...x-france-2012/

[Jean Meurtrier]

En gros le "WOA" c'est du SOA REST asynchrone. Est-ce révolutionnaire?
En quoi est-ce en opposition avec la POO? En quoi cela remplace-t-il JEE? Justement JAX-RS n'est-il pas un bel outil pour faire du "WOA"?

[thierryler]

J'ai assisté à cette présentation. Je suis ressorti de la salle en me disant que c'était vraiment une super présentation, avec un speaker super bon. Et quand j'ai voulu dresser un bilan, ça m'a semblé moins clair. Finalement, je reste juste sur le conseil de faire du REST asynchrone. Il n'explique pas vraiment pourquoi ni comment. Faudrait le croire sur parole. Pourtant j'en ai quelques uns derrière moi des projets, et ils fonctionnent sans REST ni asynchrone ! En y réfléchissant bien, ça ressemble à de la pub déguisée pour sa boite.

[Nithril]

Ces trois types de projet sont à cotés de la plaque. En S+1 il met des concepts, des concepts fondés soit disant sur "HTML". REST n'est en rien fondé au HTML. Mais S+1 seul, ça ne fait rien. Pour mettre en œuvre S+1 il faut ... S-0. Il faut du Spring, du JEE ou autre.

Il ne faut pas mélanger "webapp" et "site internet".

Son exemple sur les dépots bancaires montrent combien son argumentaire est bancal, mélangeant allégrement présentations, services. Bien entendu que l'aspect transactionnel et workflow existe toujours en WOA, comment pourrait on gérer autrement une transaction bancaire ? Sauf qu'il omet de le préciser confrontant une approche WOA qu'il présente comme plus simple avec une approche "classique" qu'il complexifie à dessein.

[montesq]

REST n'est en rien fondé au HTML.

Non, ce que je comprends c'est que la logique métier est fournie par les services REST et que l'affichage est réalisé directement en HTML.
Du coup l'appli web peut afficher et mixer des données fournies par des services REST codés en Java, PHP, Ruby, Python...

Mais S+1 seul, ça ne fait rien. Pour mettre en œuvre S+1 il faut ... S-0. Il faut du Spring, du JEE ou autre.

Oui, effectivement les services REST peuvent être implémentés via JEE/Spring. Néanmoins, de la même façon qu'on distingue des différences de productivité entre l'architecture S-1 et S-0, l'architecture S-0 n'est a priori pas la plus simple pour mettre en place une architecture REST. N'est-ce pas cette même constatation qui a amené le JCP a créé le profil web? On peut aussi évoquer l'initiative du framework Play! (qui s'insipire de RoR)

Il ne faut pas mélanger "webapp" et "site internet".

Explique donc la différence? Twitter : webapp ou site internet? Amazon : webapp ou site internet? DVP : webapp ou site internet?...

A la limite, si tu assimiles site internet à "site statique/site vitrine" et webapp à site "dynamique" alors je comprends la différence entre ces 2 "domaines". Mais depuis 5/10 ans la quasi totalité des sites "vitrines" utilisent des CMS et peuvent être considérés comme des webapps...

[Nithril]

Non, ce que je comprends c'est que la logique métier est fournie par les services REST et que l'affichage est réalisé directement en HTML.
Du coup l'appli web peut afficher et mixer des données fournies par des services REST codés en Java, PHP, Ruby, Python...

Oui, effectivement les services REST peuvent être implémentés via JEE/Spring. Néanmoins, de la même façon qu'on distingue des différences de productivité entre l'architecture S-1 et S-0, l'architecture S-0 n'est a priori pas la plus simple pour mettre en place une architecture REST. N'est-ce pas cette même constatation qui a amené le JCP a créé le profil web? On peut aussi évoquer l'initiative du framework Play! (qui s'insipire de RoR)

Le profil web a aussi été créé pour répondre à un besoin de simplification de la stack JEE autant coté concepteur (des stacks JEE) que coté développeur. Il n'a pas été créé devant la nécessité d'ajouter à JEE des technos REST; elles y étaient déjà présentes.

Les technos évoquées en S-0 (Spring et JEE) permettent toutes de faire du REST simplement et rapidement. Je dirais même qu'au contraire ce sont principalement ces technos qui sont utilisées pour faire "S+1" quand on développe en Java. Play! lui a une approche similaire à Spring ou à JAX-RS. Je ne retiendrais de Play! que sa capacité à faire du chargement à chaud. Capacité qui peut être ajouté à Spring/JEE en s'équipant.

Bref, je fustige le fait de mettre en S-0 Spring ou JEE. C'est trop facile et par trop réducteur.

Explique donc la différence? Twitter : webapp ou site internet? Amazon : webapp ou site internet? DVP : webapp ou site internet?...

A la limite, si tu assimiles site internet à "site statique/site vitrine" et webapp à site "dynamique" alors je comprends la différence entre ces 2 "domaines". Mais depuis 5/10 ans la quasi totalité des sites "vitrines" utilisent des CMS et peuvent être considérés comme des webapps...

Je confronte site internet et webapp (surement un abus de langage) vis à vis des contraintes techniques et donc des technos utilisables.
site internet : site présent sur le net, accessible à tous
application web : application autonome

Mon propos est avant tous d'indiquer qu'a chaque cas d'utilisation sa techno et qu'il existe des frameworks plus adaptés à certains besoins que d'autres.

[montesq]

Bonjour à tous,

Je remonte le topic car je suis actuellement une formation et le formateur n'est autre que ... Habib Guergachi! C'est marrant les coïncidences...

L'explication de texte est donc la suivante:
Le SI en S+1 est le modèle "cloud". L'entreprise S+1 ne fait plus que consommer des services internes et externes. Quelle est la techno dans laquelle sont réalisés ces services? On s'en fout, puisque de toute façon l'intégration de ses services sera réalisée au moyen d'une API de type REST... Pour les API externes, la question ne se pose définitivement pas, concernant les services internes, l'idée est d'utilisée à un instant T le framework qui répondra le plus rapidement/facilement aux besoins tout en gardant un haut niveau de qualité afin de garantir une maintenabilité aisée (en évitant de se ruer sur JEE car on vient juste de renouveler les licences Websphere et qu'avec java, on peut tout faire, même le café).

Les spécificités et "l'orchestration" des services de l'entreprise S+1 sont alors déportés directement dans le browser de l'utilisateur (HTML + Javascript), ce qui est le plus déconcertant .
Par exemple, je suis voyagiste, l'utilisateur veut aller 1 semaine dans un hôtel au Maroc, mon site récupère d'un côté la liste des hôtels disponibles à partir d'un service exposé par Foo INC. et de l'autre côté la liste des vols venant du service de Bar SA. Une fois que le client a choisi son hôtel et son vol et réglé, la réservation est envoyée à Foo et Bar.

Inévitablement cette approche doit faire hérisser les poils de nombreux architectes JEE car elle est contradictoire avec les méthodes employées jusqu'alors mais il s'agit pourtant des méthodes reconnues et mises en place chez les Facebook, Twitter et autres LinkedIn. Après, chacun choisi son camp

[thierryler]

Pour le moment, je reste sur ma faim. Je voudrais bien avoir des exemples précis et complets. Pour l'instant, j'ai juste l'impression que c'est intéressant mais qu'il n'en dit pas assez pour me convaincre.

[montesq]

Un exemple concret:
Je développe une application pour vendre des billets de concert. Dans le détail d'un concert, je veux afficher un lien pour que l'utilisateur puisse enregistrer l'évènement dans son agenda.
En S0, je vais donc créer une action struts qui va descendre les n couches de mon architecture pour enfin appeler un webservice qui se chargera de créer l'évènement dans le calendrier de l'utilisateur.
En S+1, mon lien utilise directement l'API REST de l'agenda de l'utilisateur (par ex google calendar) : donc au moment où l'utilisateur clique sur le lien, on fait en JS un POST à une URL de type: https://www.googleapis.com/calendar/...2zgxQnMb7v3XaM et on passe en paramètre les informations concernant l'évènement (date début, date de fin, participant...)

Tu peux remplacer mon appli de vente de billets par ton CRM préféré et si google ne te plaît, tu utilises n'importe quel gestionnaire de calendrier disposant d'une API REST de ton choix. Ainsi, quand le commercial enregistre un nouveau RDV client, le code javascript envoie un ordre pour enregistrer le RDV dans le CRM ET un ordre de création du RDV dans l'agenda...

[thierryler]

En gros, ce que tu m'expliques, c'est qu'au lieux de faire une action struts, je vais faire une action javascript ? Ça veut dire que je dois embarquer une sacrée quantité de choses dans mes pages. Mais pourquoi pas...

Par contre, si je fais la même chose avec un système de réservation de billet d'avion, ça va me faire un léger problème de sécurité, non ? A moins qu'Air France soit d'accord de voir ses codes de connexion transiter sur le Web, facilement dé-codables...

Et quid des transactions ? Imagine par exemple que je passe un ordre d'achat en bourse de 100 actions à 5€ pièce. En woa, du coup, ça va donner quoi ? sachant qu'il faut que ça débite mon compte quand l'ordre passe uniquement et que ça doit alimenter tout un tas d'autres systèmes...

[montesq]

En gros, ce que tu m'expliques, c'est qu'au lieux de faire une action struts, je vais faire une action javascript ? Ça veut dire que je dois embarquer une sacrée quantité de choses dans mes pages. Mais pourquoi pas...

Oui biensûr la logique fonctionnelle doit bien se retrouver quelque part, elle se trouve à présent côté javascript...

Par contre, si je fais la même chose avec un système de réservation de billet d'avion, ça va me faire un léger problème de sécurité, non ? A moins qu'Air France soit d'accord de voir ses codes de connexion transiter sur le Web, facilement dé-codables...

Oui effectivement, dans ce cas là pour des raisons de sécurité ce n'est pas le client (son browser) qui va directement envoyer l'ordre de réservation au système de billet d'avion mais le "voyagiste" en fournissant ses identifiants auprès d'Air France. Par contre, l'échange d'information se faisant en https, il n'y a pas de problème de sécurité (de la même façon que tu payes par CB sur internet).
Il n'est pas exclu que des services appellent eux-mêmes d'autre services (même si c'est à éviter autant que faire se peu pour des raisons de scalabilité). En l'occurrence le service d'enregistrement du paiement de la commande devra appeler les services de réservation des billets d'avion et de réservation de l'hôtel...

Et quid des transactions ? Imagine par exemple que je passe un ordre d'achat en bourse de 100 actions à 5€ pièce. En woa, du coup, ça va donner quoi ? sachant qu'il faut que ça débite mon compte quand l'ordre passe uniquement et que ça doit alimenter tout un tas d'autres systèmes...

Cette question n'est par relative à l'architecture WOA... Comment faire du transactionnel, si tu dois t'intégrer avec 2 systèmes de 2 fournisseurs différents?
Le principe transactionnel est une réponse technique dans un contexte d'architecture "simplifié". Il faut donc traiter fonctionnellement ces situations et prévoir les opérations "de compensation" si nécessaire (ce qui n'est pas forcément simple!)
Par ex: si on encaisse le paiement de réservation d'un billet d'avion alors qu'il s'avère qu'entre temps il n'y a plus de billet disponible, il faut prévoir d'annuler le paiement et de signaler à l'utilisateur le problème

[thierryler]

Oui effectivement, dans ce cas là pour des raisons de sécurité ce n'est pas le client (son browser) qui va directement envoyer l'ordre de réservation au système de billet d'avion mais le "voyagiste" en fournissant ses identifiants auprès d'Air France.

Ok, donc c'est mon action struts qui le fait, à l'ancienne.

Comment faire du transactionnel, si tu dois t'intégrer avec 2 systèmes de 2 fournisseurs différents?

Comme avec n'importe quelle transaction.

Par ex: si on encaisse le paiement de réservation d'un billet d'avion alors qu'il s'avère qu'entre temps il n'y a plus de billet disponible, il faut prévoir d'annuler le paiement et de signaler à l'utilisateur le problème

Je vois bien le truc : le client paye. Le compte est débité. La réservation échoue (car le proxy déconne par exemple). Le client en est informé, ou non. Le client prend un billet sur un autre vol. Son compte est débité. Le client est en découvert. Le client est interdit bancaire... Le site rembourse enfin. Le client pleure.

Et là je n'ai pas l'impression de jouer l'avocat du diable. Je ne suis juste pas convaincu.

En S+1, mon lien utilise directement l'API REST de l'agenda de l'utilisateur (par ex google calendar) : donc au moment où l'utilisateur clique sur le lien, on fait en JS un POST à une URL de type: https://www.googleapis.com/calendar/...2zgxQnMb7v3XaM et on passe en paramètre les informations concernant l'évènement (date début, date de fin, participant...)

C'est juste un lien vers gcalendar... On peut imaginer qu'en woa, apres la réservation, il y aurait une sorte de onload dans le BODY qui lancerait un get sur cette url. C'est bien ça ?

[montesq]

Ok, donc c'est mon action struts qui le fait, à l'ancienne.

Dans ce cas présent, je ne vois effectivement pas d'autre solution technique si ce n'est de faire cela directement au niveau du service...
Sur ce point, il n'y a pas de différence entre les 2 architectures.

Comme avec n'importe quelle transaction.

Càd? Comment fais-tu un rollback sur un appel de webservice?

Je vois bien le truc : le client paye. Le compte est débité. La réservation échoue (car le proxy déconne par exemple). Le client en est informé, ou non. Le client prend un billet sur un autre vol. Son compte est débité. Le client est en découvert. Le client est interdit bancaire... Le site rembourse enfin. Le client pleure.

1° Il faut voir avec le fournisseur du service de paiement, pourquoi le remboursement serait plus long que l'encaissement.

2° On peut voir aussi le problème dans l'autre sens: faire la réservation avant d'enregistrer le paiement et annuler la résa si le paiement n'a pas fonctionné...

Enfin, on est confronté au même type de problème si Air France annule (physiquement) le vol que tu as réservé, crois-tu qu'il y a plus de chance que ton compte soit crédité instantanément?
Quelle est la probabilité la plus forte entre le fait qu'Air France annule son vol et que le service de résa ne soit plus disponible quelques secondes (voire 100aine de ms) après avoir vérifié que la place était toujours dispo?

C'est juste un lien vers gcalendar... On peut imaginer qu'en woa, apres la réservation, il y aurait une sorte de onload dans le BODY qui lancerait un get sur cette url. C'est bien ça ?

Oui, ou alors quand tu soumets le formulaire de réservation clique sur le bouton "enregistrer", le JS appelles le service d'ajout de l'évènement dans le calendrier, puis (de façon séquentielle) il envoie les infos de réservation au service de confirmation de la résa

[thierryler]

J'ai le sentiment qu'Air France n'est pas gênée de ne pas te rembourser tout de suite après l'annulation d'un vol. Ca doit même être prévu (je suppose) dans les contrats de ventes. Et t’inquiète pas, ils ont l'habitude ;-)

Revenons sur le cas que tu proposes avec gcalendar. Parce que je voudrais bien comprendre et je ne pense pas être le seul.

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