The Butterfly Effect (2)

Une question que l’on m’a déjà posé plus d’une fois: comment partager des variables de session entre une application ASP et une application ASP.Net ?

Ce cas de figure se présente principalement dans le cas de gros projets de migration durant lesquels il est nécessaire de conserver une couche existante (ASP) parallèlement à la nouvelle couche en Dotnet.

Je ne vais pas m’étaler longtemps sur le sujet mais voici une méthode en quelques étapes:

Identifier la session

Dans tous les cas, il y a une ‘première’ requête. Cependant, il est rarement possible de déterminer à l’avance, avec certitude, dans quelle application l’utilisateur va faire la première requête.

Les deux mécanismes de session se basent respectivement sur une valeur stockée dans un cookie. Ce dernier contient en effet un identificateur de session permettant à l’application ASP Classique ou ASP.Net de faire le lien entre le client et toutes ses variables de session.

La problématique ici est que chacun des deux mécanismes possède son propre identificateur. Il faut donc créer un ‘lien’ entre les deux mécanismes. Ce lien peut être une chaîne texte, un nombre généré aléatoirement ou tout simplement l’un des deux identificateurs de session qui va être considéré comme le ‘maître’. Ce ‘maître’ , que je nomme ‘masterid’ est alors placé dans un cookie. L’application appelée va donc vérifier si un masterid est disponible, le cas échéant, elle le créera.

En image:

Stockage des clés-valeurs de session

Les applications web dynamiques consomment généralement une base de données. Nous allons donc l’utiliser, elle est là pour ça!

Le but ici est donc simplement de placer toutes les combinaisons de clés-valeurs faisant référence à un client au sein de la base de données. Voici une proposition de structure de table:

Récupération / Stockage des clés/valeurs de session

Chaque mécanisme (ASP classique et ASP.Net) doit disposer de ses propres méthodes de modification et d’accès aux variables de session. L’exemple suivant pourrait convenir:

SessionInit()
Effectue le processus décrit plus haut, consistant à initialiser un “masterid” s’il n’est pas détecté ou à récupérer celui présent dans le cookie du client.

SessionSetValue(key, value)
Insère la combinaison clé-valeur dans la base de données. Dans le cas où la clé est déjà stockée dans la table, une mise à jour sera effectuée.

SessionGetValue(key)
Extrait la valeur de la clé indiquée à partir de la base de données.

Conclusion

Nous avons ici un mécanisme simple de gestion partagée de variables de session entre une application de type ASP classique et ASP.Net. Bien entendu, cette méthode peut être étendue à toute autre technologie ‘web dynamique’ telle que PHP ou JSP par exemple.

La solution proposée reste très ‘basique’ dans la mesure où aucun souci réel de sécurité n’a été discuté (complexité et sécurité du masterid?) et seule des combinaisons clé-valeurs de type ‘texte’ peuvent être utilisées. Dans la majeure partie des cas cependant, cela suffira largement.

Si vous souhaitez cependant faire évoluer votre mécanisme de partage de sessions vers une version offrant plus de fonctionnalités, il vous reste à examiner la proposition tout droit venue de chez Microsoft: How to Share Session State Between Classic ASP and ASP.NET.

Une faille critique semble avoir été découverte dans le processus d’authentification integré dans la technologie ASP.Net. Plus d’infos d’ici quelques heures, lorsque j’aurai moi-même constaté les dégâts…

Dès la semaine prochaine, un stagiaire en développement Dotnet rejoindra mes rangs auprès de mon employeur. Le stage durera trois mois et mon boss m’a officiellement demandé de me charger de son coaching.

D’après le curriculum vitae que j’ai pu avoir sous les yeux, il a suivi avec succès des cours de certification Dotnet (cursus MCAD partiellement accompli) et effectué plusieurs stages de développement JAVA (orientation web).

Je ne pense donc pas le ‘tester’ à proprement parler car je n’adhère pas du tout à cette pratique mais plutôt à le placer directement dans un projet en attente jusque-là, en lui donnant des directives et si nécessaire, en l’assistant jusqu’à travailler en binôme au départ (mais cela ne devrait pas être nécessaire).

Etant spécialisés dans le développement d’applications web de gestion de contenu/connaissance/informations, nous avons pour cela un moteur de site ‘Intranet/Extranet’ offrant toute la couche de base (gestion de sites, départements, comptes, rôles, autorisations, applicatifs, plugins, journalisation et audit, gestion des styles css, configuration, etc.) nécessaire au développement de modules métiers tels que de la gestion RH, outils collaboratifs, gestion électronique de documents, etc.

Il m’a semblé de par mes premières expériences dans le monde du développement que le fait d’être intégré dans un projet déjà bien rôdé permettait de combiner les conditions les plus désagréables de travail (on ne comprend rien au projet et on a l’impression que tout a été mal fait) à un rendement extrêmement élevé d’acquisition de nouvelles compétences.

D’autre part, j’envisage de le faire passer par un cycle complet de développement appliqué à un micro-projet (le module): analyse, conception, élaboration des tests, développement, documentation, intégration, déploiement et suivi des évolutions.

Comment gérer le premier contact ? Faut-il lui donner un maximum d’indépendance ou l’encadrer de manière raisonnable ? Qui devrait effectuer l’analyse du module selon le cahier de charges, lui ou moi ? Dois-je le laisser utiliser ses propres outils ou l’intégrer aux nôtres ? Relation ‘égale’ ou plutôt ‘hiérarchique’ ? J'ai déjà eu à coacher des collaborateurs mais ils ont toujours été plus jeunes que moi, quels changements lorsqu'il s'agit d'un père de famille ?

Je ne cherche pas réellement des marches à suivres dans la mesure où ce n'est pas une 'première' expérience mais j'en profite cette fois-ci de récolter des conseils, si vous en avez !