Discussion :

[CUCARACHA]

Salut,

Je travaille actuellement sur une SOA qui sera déployée dans une batterie de serveurs. Cette application est destinée à recueillir et traiter des données à caractère médical, d'où l'architecture un peu compliquée.

Il y a 4 types de serveurs:

• 1 serveur de base de données (DMZ2)

• 2 serveurs de webservices (DMZ2)

• 1 serveur pour les requêtes webservices public

• 1 serveur pour les frontaux web

• 3 serveurs frontaux (DMZ1)

• 1 serveur pour relayer les requêtes webservices vers la DMZ2

• 2 serveur pour les frontaux web

Sachant que l'on fournira 2 types d'accès Web via une interface que nous avons créé ou webservice pour nos "gros" clients, et que seules les informations confidentielles sont dans le serveur de bases de données, les informations relatives au contenus (CMS) sont stockées localement sur les frontaux web, ma question est la suivante :

Lorsqu'une communication est établie entre un navigateur et un frontal web, est-ce que le loadbalancer est capable d'identifier la connexion et de systématiquement rediriger tous les applels en provenance de ce client vers le même frontal web afin que ce dernier fasse de même vers le serveur de webservice ou est-ce aléatoire, auquel cas, il est nécessaire de concevoir différemment une partie de la persistance ?

D'avance merci pour votre aide,

Laurent

[SaumonAgile]

La navigation est un mode déconnecté par essence. Rien ne dit que les requêtes subséquentes arriveront sur le même serveur.
Je ne vois pas non plus comment tu peux avoir ce genre de problèmes pour ta persistence. Les "frontaux" partagent les mêmes sessions utilisateurs, à moins que tu ne les aies mal configuré.

[CUCARACHA]

Salut,

Merci pour ta réponse. Je suis en phase de conception. Je pars d'un existant monoserveur et je dois migrer vers une architecture multiserveurs.

En fait, tu as répondu à ma question car je ne savais pas que les serveur avaient la possibilité de partager les sessions utilisateur. Reste à savoir comment ça se configure.

Pour les frontaux web, personnellement, je préfère ne pas utiliser de variable de session. J'utilise une autre méthode qui conserve ces variables sur le client afin de pouvoir y accéder via javascript.

Pour les webservices public, c'est différent car je ne sais pas si leur utilisation implique celle de variables de session. Idem, dans la mesure du possible, je préfère éviter.

Bonne journée

Laurent

[Keihilin]

En fait, tu as répondu à ma question car je ne savais pas que les serveur avaient la possibilité de partager les sessions utilisateur. Reste à savoir comment ça se configure.

Assez simplement je crois. Il faut juste déterminer l'un des serveurs comme point central de gestion des sessions.

J'utilise une autre méthode qui conserve ces variables sur le client afin de pouvoir y accéder via javascript.

Cookie ? QueryString ?

Attention quand même au niveau de la sécurité...

[CUCARACHA]

Reuu,

En fait j'ai deux familles de données.

• La première englobe tous les éléments de type contenu. Ces éléments ne sont pas confidentiels.
• La seconde sont les éléments permettant d'identifier le client, ces éléments sont cryptés, ils m'évitent d'avoir à repasser dans ma série de couches qui permettent de recharger tous les objets nécessaires au fonctionnement des pages.

Les données confidentielles sont transmises à chaque demande, elles ne sont stockées sur le client que sous la forme de pages HTML. Les données sont affichées dans une IFrame afin d'éviter de transporter sur la même page les informations nominatives et les informations qualificatives.

N'hésite pas à me suggérer des idées si cette description t'en inspire. Concernant l'utilisation des IFrame (No Trolling out of scope).

Merci encore pour ton aide,

Laurent

[Keihilin]

Les données confidentielles sont transmise à chaque demande, elles ne sont stockées sur le client que sous la forme de pages HTML. Les données sont affichées dans une IFrame afin d'éviter de transporter sur la même page les informations nominatives et les informations qualificatives.

Je n'ai pas une vision d'ensemble suffisante pour te proposer une alternative, mais d'instinct, cette solution à base d'iframes ne m'inspire qu'une confiance limitée; les possibilités de "bidouilles" sur le client avant un retour au serveur me paraissent trop importantes.

D'autre part, et sans partir dans du troll, n'oublie pas que les iframes ne sont pas supportées par tout les navigateurs...Est-ce que tu as une maîtrise à 100% des clients ? Aucun risque que certains accèdent à l'application avec Safari ou autre ?

[CUCARACHA]

Salut,

Safari supporte très bien les IFrames comme Opera, Firefox, Netscape (Qui n'est que FF et IE) et Internet Explorer.

Concernant les "bidouilles" c'est blindé. Les requetes en provenance du client sont accompagnées d'une hashkey, la moindre modification dans une des variables bloquerait automatiquement le processus de transmission. Si le "bidouilleur" arrive à pirater ce processus, il n'obtiendrait que des séries de chiffres innexploitables puisque non rattachées à des personnes.

++

Laurent

[Keihilin]

Dans ce cas, quelle est l'utilité de l'iframe ?

Pourquoi ne pas simplement utiliser des champs cachés dans la page ?

[CUCARACHA]

Re,

La construction des pages est faite par un CMS. Toute la couche de présentation, à l'exeption de la présentation des données confidentielle, est construite par cet outil.

Les éléments confidentiels sont issus d'une "brique logicielle" équivalent d'un webpart en plus puissant (accepte des pages de toutes origines technologiques et sont intégrées soit sous la forme de composants web personnalisés soit sous la forme de pages affichées dans des frames ou des iframes.

La page qui contient l'IFrame indique certaines informations nominatives, Nom, Prénom, adresse, n° de tel etc... Je ne veux pas que ces informations soient transmises dans la même page que celle qui contient les données médicales. D'ailleurs c'est limite illégal.

Je pourrais aussi n'afficher que les informations médicales sans mettre les informations nominatives et séparer les deux interfaces mais c'est simplement moins ergonomique.

Je crois que nous nous éloignons du sujet initial qui est de gérer les flux d'informations entre les différentes couches physiques de l'application et non celles qui sont affichées sur le poste "individuel" du client.

Les informations qui doivent absolument rester confidentielles sont celles sont mises à la disposition de nos clients institutionnels via les webservices.

Bien à toi

Laurent