Discussion :

[Micky17]

Bonjour !

Je me retrouve actuellement à devoir gérer plusieurs solutions informatiques d'une société, mais je peine à comprendre l'utilité de certaines choses qui ont été mises en place et souhaiterais simplifier un peu tout ça.
Il y a 3 applications qui tournent :
- 1 application bureau sous WinDev, qui possède sa propre base de données sur le serveur interne de la société
- 1 application mobile sous WinDev Mobile qui possède sa propre base de données locale qui est une "copie simplifiée" de celle de l'application bureau.
- 1 application Web sous WebDev qui possède sa propre base de données hébergée par un hébergeur, qui est également une "copie simplifiée" de celle de l'application bureau.
Ces différentes applications communiquent entre elles via un WebService codé en WinDev.

Actuellement, voici comment se présente le lien entre ces applications au travers d'un schéma plus parlant :


N'étant pas encore assez expérimenté, je peine à comprendre l'utilité de dupliquer les bases de données et d'utiliser un WebService...
Je comprends l'utilité de la base de données locale de l'application mobile, en cas de perte de connexion réseau.
Mais je ne comprends pas pourquoi l'application Web n'utilise pas la base de données de l'application bureau, et pourquoi il y a un WebService en plein milieu ! J'imagine que le WebService est là pour sécuriser le tout ?
J'ai peur de devoir mettre à jour 4 applications et 3 bases de données à chaque fois que je veux toucher à l'analyse de l'application bureau par exemple

Voici ce que je souhaiterais mettre en place pour simplifier les choses :


Pourriez-vous me donner votre avis s'il vous plaît, sur ce que vous feriez à ma place ?

PS : jusqu'à présent je n'avais travaillé qu'avec WinDev, je découvre WebDev et WinDev Mobile, j'ai peut-être raté un chapitre et mes questions sont stupides !

Merci beaucoup !!!

[Lo²]

Bonjour,

Avant de supprimer le webservice, il faudrait regarder ce que ça fait

Ensuite, selon mon expérience, il est beaucoup plus facile de gérer un webservice pour interroger une base via une appli mobile, plutôt qu'une connexion directe.
Pour le site web, la base simplifiée est sûrement là en cas de maintenance ou d'indisponibilité du serveur principal. Je dirai que son utilité est sensiblement le même que l'appli mobile, pouvoir être utilisé même si le serveur principal n'est pas dispo.

[Micky17]

Merci beaucoup Lo² pour ta réponse !

Le WebService réalise tout simplement des SELECT, INSERT, ou UPDATE, rien d'autre (i.e. pas de calculs, pas de traitements, seulement une interface entre 2 BDD grosso modo).
Exemples :
- Au lancement de l'appli mobile, on appelle le WebService qui va interroger la BDD du serveur web, pour récupérer des informations.
- Puis à un moment on va faire des INSERT ou UPDATE sur le serveur web en repassant par le WebService.
- Et sur l'appli bureau, à un moment donné, on va interroger la BDD du serveur web, pour récupérer des informations et les INSERT dans la BDD du serveur principal.

Indépendamment de la disponibilité du serveur principal, il semblerait que la base de données de l'appli Web ne serve pas à grand chose en fin de compte. Je vais donc essayer de supprimer cette BDD (et donc l'appli mobile ira chercher / déposer des informations sur le serveur principal en passant par le WebService puisque tu penses que c'est mieux ainsi).
Je me retrouverais donc avec une étape de moins de maintenance, c'est à dire une seule "vraie" base de données au lieu de deux, ce qui me simplifierait grandement la maintenance de l'ensemble.

Et comment t'y prendrais-tu par exemple, si tu devais mettre à jour la structure de ta BDD du serveur principal du coup, vu que l'appli Web, l'appli bureau et le WebService seraient liés à la BDD ? Tu génèrerais une nouvelle version de tous ces composants en même temps que la mise à jour de la structure de la BDD ?

Merci encore pour ces précisions qui m'aident beaucoup, je suis un peu perdu par la complexité du système et mon peu d'expérience...

[Lo²]

Ouh là, je n'ai donné qu'un avis sur le sujet ^^

Et comment t'y prendrais-tu par exemple, si tu devais mettre à jour la structure de ta BDD du serveur principal du coup, vu que l'appli Web, l'appli bureau et le WebService seraient liés à la BDD ? Tu génèrerais une nouvelle version de tous ces composants en même temps que la mise à jour de la structure de la BDD ?

Je dirai que c'est le côté complexe de cette architecture.
Actuellement, est-ce que les projets :
- ont une analyse chacun ?
- ont une analyse commune ?
- n'ont pas d'analyse ?

[Micky17]

Un avis est toujours utile quand on est perdus :p

Les projets mobile et web partagent la même analyse.
Le projet bureau a une analyse indépendante.

Je peux très bien continuer dans ce système là, mais il me paraît très voir trop complexe pour le peu d'utilité qu'il apporte.
Pour moi, si plusieurs applications doivent taper dans la même base de données, il ne devrait pas y avoir plusieurs bases de données (ou plusieurs analyses) et un WebService. Car plus on ajoute d'éléments différents, plus la création d'une nouvelle version d'une des applications génère des effets de bord dans toutes les autres applications / analyses et ça devient vraiment laborieux de modifier quelque chose.

Merci pour ton aide !

[tbc92]

Précision n°1 : je n'ai quasiment jamais utilisé Webdev ni Windev Mobile et quasiment pas de Webservice... donc mon avis est un avis de novice.

Ceci dit, j'ai un diagnostic diamétralement opposé au tien. L'intérêt du Web Service ici, c'est qu'il fait tampon. Si tu modifies la structure des données pour l'appli Windev, tu peux parfaitement continuer à fonctionner sans modifier l'appli Windev-Mobile ou l'appli Web. Ca simplifie nettement les évolutions. Même si les utilisateurs de l'appli Mobile ont une vieille version, ils savent lire les données de la base centrale, grâce au Web-Service.

[Ry_Yo]

Bonjour,

De ce que je comprends du schéma, l'idée derrière cette architecture est une conception 3-tiers :
- La couche Data : HFSQL
- La couche Application : Webservices
- La couche Présentation : Site web et appli mobile (normalement l'appli windows aurait dû aussi passer par le WS)

Donc cela ne me choque pas.
Ca reste propre, la couche présentation appelle la couche application pour obtenir les infos.

Quand à votre problématique de modification d'analyse, si vos projets respectent le n-tiers, ce n'est pas forcément un problème, une fois encore, cela dépend comment a été implémenté le modèle n-tiers. Car la couche Présentation n'a pas à connaitre la structure de la BDD, elle n'a à connaitre uniquement "les objets" donnés par la couche application.

Cordialement.

[kunnskap]

Tu sais parfois, les BDD se retrouvent dupliquées parce que "on a pas le temps ça va plus vite" m'enfin la dette technique c'est un autre sujet...je connais bien le problème. Et ça facilité pas le travail ni la productivité.

De manière générale, si tu peux te retrouver avec une seule base de données c'est le top, mais il faut un webservice: on accède pas à la base en direct depuis les terminaux clients, c'est pas propre et surtout c'est difficile à maintenir. Un webservice offre une couche de protection et d'abstraction indispensable, sur laquelle tu pourras a l'avenir greffer ce que tu veux: un partenaire qui aura accès à quelques informations de la base, une appli que tu auras développée avec un autre langage...

La base de données locale sur le mobile pour prévenir les déconnexions, oui, bonne idée. Est-elle forcément nécessaire cependant? Les applis risquent-elles vraiment de se retrouver sans connexion au point de devoir déporter la base en local pour parer à ça?
Ne jamais oublier que tout ce que tu codes, mets en prod, devra être maintenu.

L'idée chez moi c'est toujours la même: unification. Je le vois régulièrement, que ça manque, même dans la bouche de ceux qui trouvent des défauts à ce mode de conception. Ils emploient souvent les termes "regrouper", "centraliser" dans leurs phrases et bien que leurs point de vue sur l'unification soient différents des miens ils la réclament aussi implicitement...car le bordel d'une décentralisation est dur à gérer, couteux à maintenir et handicapant pour les employés, et ils le voient bien.

[Micky17]

Merci à tous pour vos réponses / explications !

Je comprends mieux à présent pourquoi l'architecture a été conçue comme ça.
Avec ces explications maintenant je comprends très bien l'intérêt d'un WebService.
Et si j'ai bien compris, il aurait fallu que la structure ressemble à ça, grosso-modo :


Il y aurait donc eu une seule base de données, et tous les appels BDD des applications auraient dû passer par le WebService.
Si encore une fois j'ai bien compris, pour avoir une architecture un peu plus fonctionnelle et moins pénible à maintenir :
1) Je dois mettre à jour le WebService pour qu'il soit branché uniquement sur la BDD du serveur principal.
2) Je dois brancher le site Web sur le WebService.
3) Je pourrai alors supprimer la BDD de l'hébergeur (celle du site Web donc).
4) Si tout s'est bien passé jusque là, je branche l'appli bureau sur le WebService également.
5) J'adapte toutes les applications pour qu'elles envoies / récupèrent des objets du WebService au lieu de passer en brut les noms des tables et champs de la BDD.

Et ensuite, lorsque j'aurai des modifications à faire, je n'aurai qu'à mettre à jour la structure de la BDD du serveur principal, et le code du WebService, au lieu de changer toutes les couches "présentation".

Va y avoir du boulot, mais si déjà si j'arrive jusqu'au point 4 ce sera beaucoup moins complexe !!!


Merci mille fois !