Mélange VB6 "code legacy" et une application Web

Question

Je travaille sur un nouveau site Web, écrit en VB.Net en utilisant ASP.NET MVC2, il est nécessaire d'appeler le code VB6 "hérité" pour diverses affaires complexes logique. Le VB6 est un framework composé de plusieurs dll et est très dynamique, nous émulant à peu près comment le framework est utilisé dans notre application cliente, ie l'application s'exécute (beaucoup de configuration d'état), un utilisateur se connecte (encore plus d'état) et puis charge un fichier (encore plus d'état).

J'ai reçu un «cadre d'interface de service Web» pour que l'application web puisse l'utiliser, ce «framework web» cache le code existant derrière une couche mince s'exécutant sous IIS. L'idée étant que le pool de threads fourni par IIS réduit l'utilisation de la mémoire etc. Je ne peux pas m'empêcher de croire que le gars qui a fourni ceci a manqué le point, puisque chaque instance est si dynamique qu'un pool de threads ne peut pas fonctionner , car une fois qu'un utilisateur se connecte en utilisant un objet particulier du pool, aucun autre objet ne pourra servir ce client (puisqu'il n'aura pas l'état)! En outre, l'ajout d'une interface de service Web et de la mise en place de SOAP associée est une surcharge considérable par rapport à l'appel direct des objets. La seule façon de le faire est une instance d'interface unique utilisée par tous les clients et bloquée par chaque appel jusqu'à sa fin, ou un thread par client avec chaque objet d'interface hérité créé dans un nouveau fil et vivant pour la vie du client.

Aucun d'entre eux n'est idéal, mais avec la quantité de code en question et le programme de migration prolongée vers .net (2+ ans et encore stateful) je ne peux pas penser à une alternative. Nous exécutons l'application client d'origine dans un environnement Citrix pour certains clients. Je pense donc que cela fonctionnerait bien avec le thread par client étant donné un serveur assez costaud et que les coûts du framework lui-même devraient être inférieurs à ceux de l'application client.

Des idées?

Answer 1

Voici une option mais ce ne sera pas joli.

Il semble que vous ayez besoin d'associer un objet à longue durée de vie (l'objet avec état à votre niveau backend) à des utilisateurs individuels.

Vous pouvez stocker cet objet dans l'état Application et l'associer à l'état de session des utilisateurs avec une clé. Vous devez fournir un wrapper pour garder une trace de tous. Lorsque la session meurt, vous pouvez capturer l'événement et détruire l'objet principal.

L'état de l'application est un magasin de clés/valeurs tout comme Session. Vous pouvez accéder à travers HttpContext.Application

La grande chute à ceci est que les objets que vous y mettez restent jusqu'à ce que vous les détruisiez pour que votre code d'emballage et de destruction de session soit sur place. Autre que cela, cela pourrait être un moyen rapide de se mettre en marche.

Comme je l'ai dit, ce ne sera pas optimal, mais ça marchera probablement.

Plus d'informations sur les implications: http://msdn.microsoft.com/en-us/library/bf9xhdz4(VS.71).aspx

EDIT:

Vous pouvez aussi faire ce travail dans un environnement agricole web. Stocker les informations nécessaires pour recréer votre objet hérité avec état dans l'état de session qui peut être partagé entre les machines à l'aide du fournisseur SQL intégré. Si un utilisateur rebondit sur un serveur où l'objet n'existe pas, l'encapsuleur d'état de l'application peut simplement le recréer à partir des informations sur l'état de la session.

Cela laisse juste comment nettoyer l'objet stateful sur les serveurs où il n'est pas nécessaire. Dans votre wrapper de récupération, mettez à jour une hashtable ou quelque chose avec le temps d'accès chaque fois que l'on accède à l'objet stateful donné. Avoir une routine de nettoyage périodique dans le wrapper detroy les objets avec état qui n'ont pas été accédés depuis un peu plus de la valeur de délai de session de votre application web.

Answer 2

Je vous suggère de jeter un oeil à ce cadre Visual WebGui. Je suis un employé de cette société et je ne pense pas que cela soit objectif, mais je pense que Visual WebGui a résolu certains des problèmes majeurs liés à la mise à l'échelle des applications et à la transformation de l'environnement mono-utilisateur en environnement multi-utilisateur. Ça vaut le coup d'oeil.