Discussion :

[HadanMarv]

Bonjour,

J'écris ici, n'étant pas certain que ce soit l'endroit approprié pour une tel réflexion.
Notre système d'information, à l'image de beaucoup d'autres, tourne autour d'une application principale, ou plutôt devrais-je dire autour d'une base de données quasi unique.
Une douzaine d'application se servent en données de manière quotidienne sans quasi aucun contrôles. Vous me direz tant qu'il s'agit de récupération ce n'est pas catastrophique bien que pour moi cela me semble déjà dingue.
Deux choses principales me choquent :
1. deux de ces applications insèrent de la données (sans contrôles non plus) voir en suppriment...
2. à chaque modification de la structure du modèle originel, la maintenance est sympathique je puis vous l'assurez.

Depuis presque deux ans, j'ai mis en oeuvre pour une nième application connexe, une couche applicative qui régente les échanges les échanges entre cette nième application et la base de données principales du SI. Après de nombreuses réunions et réflexions, cette couche applicative (basé sur des services pour le moment) va être utilisé par plusieurs applications.
Au commencement, de la nième application, les deux projets étaient en Java, je ne m'étai pas trop questionné sur la bonne manière à employer, à tort.
J'ai développé la couche service, inclus ce jar, dans ma nouvelle appli et développé la logique de la seconde application.

Ainsi cela pose la question de l’implémentation pour la mise à disposition de ces services. Pour le moment je suis parti sur du webservices.
Mais comme les technologies sont différentes (Java, Php, Python), je souhaiterai poussé la réflexion encore plus loin.
Je m'explique.

Si on développe du webservices, je devrai en théorie, ne plus inclure le jar dans ma nième application et utilisé les webservices que je vais devoir mettre à disposition.
Cela dit, j'ai utilisé beaucoup de facilité que cela m'offrait (suivi des transactions JPA, lazy-loading, etc...).
Avec la mise en place tout çà deviendra de fait impossible. De plus, si on veut pousser le concept plus loin, il faudra dans l'idéale, même plus exposé les objets de la DAO.
Mais peut-être que je fais fausse route ?

Toujours est-il que cela m'oblige à revoir la structure même de la nième application, ce qui n'est en soit pas un vrai problème et même salvateur car cela permet après deux ans de vie de l'application de revoir certaines portions du code écrites trop vite.
Le passage par une couche webservices oblige-t-il à passer par une couche d'abstraction de la DAO ?
Comment exposer les constantes pour ne pas avoir à les maintenir dans la couche services et dans les autres projets Java sans pour autant exposer la logique métier et donc le lien avec la DAO ?

J'ai bien d'autres problématiques encore mais je pense que c'est déjà bien assez pour ce post.

D'avance merci de vos réponses.

HadanMarv

[HadanMarv]

Sujet complexe j'en conviens mais je m'étonne que cela ne sollicite pas quelques remarques ou réflexions.
Est-ce incompréhensible ?

HadanMarv

[souviron34]

Bonjour

J'étais absent depuis plus de 3 semaines, donc désolé du retard mis à répondre..


Je dirais que là, à mon avis, vous mélangez le fond et la forme.. Je sais, c'est facilité, que dis-je, c'est quasi-inclus, dans les langages objets, et dans les Java en particulier justement avec les .jar, ou C++ et les factory, les model patterns, etc..

En gros, à mon avis - que je ne partage pas avec de nombreuses personnes, notez-le bien - une vrae architecture n'est PAS liée au langage choisi...

Le langage peut (ou non) faciliter l'implémentation, mais une bonne architecture est indépendante du langage.


Dans votre cas (j'ai eu un peu le même à un moment donné), il y a 2 problématiques distinctes..

• L'une est l'architecture désirée.
• L'autre est le passage de l'actuelle à la désirée.

Pour ce faire, ce que moi je verrais c'est effectivement une architecture "service" (bien que je ne connaisse rien aux WebServices ou autres).

En fait, ça revient à unifier l'accès à la BD. Or, à l'heure actuelle si je comprend bien, vous n'avez déjà qu'une seule BD, donc un seul moteur (comme Oracle, Access, ou autres), mais divers outils vont chercher diverses données, la plupart en lecture, mais certains en écriture/deletion. (mais peut-être que certains outils accèdent directement la BD sans le passage par un moteur ??)

Ce que je ferais dans un premier temps, c'est un "tampon", un moteur, un service si tel est le cas, qui sera simplement à insérer avant le vrai moteur de BD. Vous remplacerez les appels directs à la BD dans les applis par les appels à ce tampon, en ne faisant pour l'instant que transférer directement au vrai moteur. En faisant ça, vos applis seront déjà "préparées" au changement, tout en voyant rien de vraiment différent. Déjà modifier ceci représente une étape importante, et même essentielle, même si fondamentalement pas très compliquée.

Ensuite, vous pourrez à loisir complexifier la fonctionalité de ce tampon, par rapport aux demandes et à la BD réelle, à la vérification de deletion ou au signalling inter-applications. et appli par appli éventuellement.


En gros, l'architecture est :

• une base
• un moteur (global) de dialogue
• un dialogue entre les applis et ce moteur

Le dialogue applis/moteur doit être normalisé, que ce soit via les possibilités d'appels ou les requêtes/réponses (ça peut être un sous-ensemble de SQL, un protocole à vous, etc.. et/ou via un service extérieur, via des classes ou des fonctions..)


C'est juste mon "pansement" , mais sans avoir aucune notion de ce qui se fait aujourdhui dans les langages Web..

[Gruik]

Hello

Comme souviron, je ferais une application "serveur" qui serait le seul interlocuteur avec la bdd et qui disposerait des webservices dont ont besoin chaque application (c'est peut etre ce que tu as fait mais ce n'est pas explicite, ou alors j'ai mal compris).
Pour la migration, ça peut se faire progressivement, des applications continueraient de taper en direct pendant que d'autres commenceraient à utiliser les services.

Le passage par une couche webservices oblige-t-il à passer par une couche d'abstraction de la DAO ?

(j'espère ne répondre à côté car je ne suis pas bien au fait de ce que tu appelles couche DAO)
Ça dépend de la nature des services en fait, si il s'agit que d'opérations CRUD, alors il y a moyen de mapper ces opérations sur la couche DAO en place ; une matière de rendre abstrait le fait qu'on passe soit par la BDD en direct soit par les services ; c'est sur que c'est élégant et ça change pas les appels (mais je pense que vouloir une telle abstraction est illusoire).
Mais maintenant si les services sont de plus "haut niveau" et sont déjà une abstraction de la base en vue de faire en ensemble d'opérations bien définies (et pas forcément des accès a des entités concrètes), il faudra changer le code de ces applications en fonction (ça devrait les simplifier et rendre le tout plus cohérent). Maintenant ça veut pas forcément dire qu'on utiliserait directement les outils du langage pour faire les appels, mais peut être faire un objet ou un ensemble d'objets s'occupant de ça et harmonisant/facilitant l'appel de ces services.

Comment exposer les constantes pour ne pas avoir à les maintenir dans la couche services et dans les autres projets Java sans pour autant exposer la logique métier et donc le lien avec la DAO ?

Je pense que t'es obligé de maintenir les appels dans chaque application si il y a modification du service. Si j'ai bien compris tu prends exemple des constantes, mais juste un changement de paramètre de méthode de service c'est la même histoire. Pour gérer ça on voit souvent un système de version de webservices (une url differente pour chaque version), et le serveur doit pouvoir fonctionner avec les anciens services et les nouveaux. On peut aussi simplement rajouter de nouvelles methodes dans les services en place, et qui sont la nouvelle version à appeler.

[el_slapper]

+1 avec les intervenants précédents. Il y a plein d'avantages à forcer les applis à passer par des modules d'accès(peu importe la forme technique qu'ils prennent), suffisemment pour compenser largement le cout.

Avantage 1 : tous les accès sont centralisés, et identifiés.
Avantage 2 : il est plus facile d'optimiser les accès : on sait à tout moment quelles sont les requêtes executées, sans avoir besoin de scanner tout le code.
Avantage 3 : on limite la redondance de code. Je suis sur qu'en dur, les accès les plus fréquents sont codés un peu partout, avec des syntaxes variées, et une efficacité elle aussi irrégulière.

Les webservice sont une des innombrables manière de faire. Si vous maitrisez, ça me parait être OK.