RoR et Soap no sql [Résolu]

[k2kingston]

Bonjour,

Dans le cadre de mon travail, nous souhaitons migrer nos sites, actuellement en PHP, en Ruby on Rails.

Ne connaissant pas le Ruby ni Rails, je m'y suis mi et ai testé le langage et son framework web en suivant plusieurs tutoriaux, ça fonctionne sans problème, même la connexion à la base oracle. J'ai également eu l'occasion d'appeler une ou deux méthodes provenant d'un webservice SOAP avec succès via la gem Savon.

Cependant nous allons passer sur des webservices SOAP, et supprimer tous les accès directs à la base, ce qui signifie que les sites utiliseront ces WS uniquement.

1ère question : Est-ce une aberration d'utiliser un framework tel que Rails pour une application se basant uniquement sur des webservices ? SOAP ?

Dans le cas où c'est possible et que cela peut fonctionner, j'aimerai comprendre comment faire pour transformer en objet, utilisable par le framework, les résultats des appels aux méthodes du webservice SOAP, tel que le fait activerecord avec les requête SQL ou activeresources avec les webservices REST.

En résumé :
- Rails peu-til fonctionner avec SOAP uniquement ?
- Si oui, comment coder les models (et controller) en conséquence (si vous avez un exemple même ultra simple ça serait top)

J'espère avoir été assez clair et précis
Merci d'avance de votre aide !


.

[k2kingston]

Vraiment personne ne peut m'aider ?
Voulez-vous plus de détails ou ai-je commis une si grosse erreur dans mon post ?


.

[LXS]

Hello,

Non ce n'est pas une aberration de travailler ainsi

Si j'ai bien compris tu as:

1. un ou plusieurs back-end qui accèdent directement à Oracle (via un ORM mais pas forcémenent
2. un front-end sans base de donnée qui va se connecter aux endpoints SOAP du/des backend(s) puis faire le rendu des pages.

La stack Rails fonctionne bien dans ce genre de configuration.
J'observerai quand même un point de vigilance quant aux performances car un appel HTTP (suivi par un accès à ta base par le back-end) pour accéder aux données sera mécaniquement plus lent qu'un simple accès à ta base via le front-end.

Pour avoir déjà mis ça en place pour des sites à (très) forts trafics, nous nous en sommes sortis grâce aux caching et à la mise en place de techniques de cache warming dans un premier temps. Puis grâce à la mise en place d'un ESB qui permet au back-end de notifier le front-end des changements opérés dans les entités du domaine.

Bonne chance!

[k2kingston]

Bonjour LXS, merci m'avoir répondu

Qu'entends tu par "backend" et "frontend" ?

En fait notre but est de regrouper les différents sites en un seul : l'un deviendra la partie administration (backend ?) et les autres seront la partie publique (frontend ?) du site. Cependant il n'est pas prévu que le backend accède directement à la base de données.


En tout cas ça me rassure de voir qu'une telle config est réellement permise dans un environnement à fort traffic. Dans mon cas les sites n'ont pas vraiment de très gros traffic, de plus les sites, la base et le serveur webservices seront au même endroit, donc normalement il n'y aura pas de problème de perf si l'on ajoute comme tu le dis les mécanismes de cache


Aurais-tu un exemple d'un model & contrôler pour se servent d'une méthode
d'un webservice ?


.

[LXS]

Envoyé par k2kingston

Qu'entends tu par "backend" et "frontend" ?

Dans ce que je disais, le backend était la partie qui se connecte à la base. Le frontend regroupe tout ce qu'un utilisateur sur un navigateur verra.

Envoyé par k2kingston

En fait notre but est de regrouper les différents sites en un seul : l'un deviendra la partie administration (backend ?) et les autres seront la partie publique (frontend ?) du site. Cependant il n'est pas prévu que le backend accède directement à la base de données.

Du coup, tu as 2 frontends. On peut même parler de backoffice (admin) et frontoffice (partie publique).

Envoyé par k2kingston

En tout cas ça me rassure de voir qu'une telle config est réellement permise dans un environnement à fort traffic. Dans mon cas les sites n'ont pas vraiment de très gros traffic, de plus les sites, la base et le serveur webservices seront au même endroit, donc normalement il n'y aura pas de problème de perf si l'on ajoute comme tu le dis les mécanismes de cache

Rails fournit du prêt-à-porter qu'il faut ajuster (finement ou carrément en remplaçant de gros composants - comme ActiveResource par Faraday par exemple) pour monter en charge.

Envoyé par k2kingston

Aurais-tu un exemple d'un model & contrôler pour se servent d'une méthode
d'un webservice ?

Je ne peux pas te montrer les projets de mes clients mais le web doit bien en regorger.

a+

[k2kingston]

Merci LXS, pour ton aide précieuse.

A bientôt !


.