Communicatie tussen ASP en VB

[Verwijderd]

Ik ben op zoek naar een manier om asp met een vb applicatie te laten communiceren. Ik wil asp logrecords laten gegenereren en dat deze worden doorgegegven aan een vb app die deze via winsock verstuurd naar een centrale server.

Ik dacht in eerste instantie aan een tussen DB maar dat blijkt geen optie. (Het idee was ASP laten schrijven en VB laten lezen). Dit idee is afgekeurd omdat het realtime moet zijn en er geen vertraging tussen mag zitten.

Ik heb zitten denken aan een MultiUse ActiveX exe maar ik heb het vermoede dat alles dat je aanroept binnen asp in een soort afgeschermde IIS omgeving draait waar vb geen grip op heeft.

Dus mijn concrete vraag: Ik zoek een manier om een queue te vormen waarin ik gegevens (logrecords) kwijt kan. ASP schrijft deze en VB leest ze. Er mag geen vertraging in zitten en binnen vb moet er een event binnen komen als de queue 1 of meer items bevat.....

Ik hoop dat iemand eerder met dit probleem heeft geworsteld en mij kan helpen.

[Verwijderd]

En VB COM component schrijven..?
Die kan je aware maken van dat ie in een ASP is aangeroepen en je kan em uiteraard vanuit een ASP aansturen..

niet dat ik je probleem verder begrijp hoor

[Verwijderd]

Ik schaam mij op het moment diep, maar COM is toch de achterligende werking van ActiveX?

[Verwijderd]

Mja ActiveX wordt voor wel meer gebruikt.. wat je daar wijzer van wordt weet ik ook niet.

Maar als je in VB een nieuwe DLL aanmaakt heet dat inderdaad een "ActiveX DLL".
Niet dat je een DLL-zonder-ActiveX aan kan maken.. ActiveX zegt me niet zoveel dus..

[LauPro]

Je kan het idd wegbergen in een dll met class. Je moet dan je dll registreren (gaat meestal al automatisch) en dan roep je hem aan met 'dllnaam.klassenaam' waarin je alle achterliggende functies kan plaatsen. Het voordeel was voor mij dat de code niet kan worden gejat .

[Verwijderd]

Nee, maar wat ik al aan probeerde te geven in mijn openingspost is dat ActiveX dll's (en exe's) binnen IIS in een beveiligde omgeving draaien. Dit houd in dat een "normale" vb applicatie er dan niet bij kan...

Maar iig bedankt

[Verwijderd]

LauPro schreef op 13 January 2003 @ 14:20:
Je kan het idd wegbergen in een dll met class. Je moet dan je dll registreren (gaat meestal al automatisch) en dan roep je hem aan met 'dllnaam.klassenaam' waarin je alle achterliggende functies kan plaatsen. Het voordeel was voor mij dat de code niet kan worden gejat .

Ik heb al eerder gewerkt met DLL's. Ik ben geen goeroe maar ik weet dat dit mij nu (op de manier die ik ken) niet gaan helpen.

[Verwijderd]

Verwijderd schreef op 13 januari 2003 @ 14:21:
Nee, maar wat ik al aan probeerde te geven in mijn openingspost is dat ActiveX dll's (en exe's) binnen IIS in een beveiligde omgeving draaien. Dit houd in dat een "normale" vb applicatie er dan niet bij kan...

Maar iig bedankt

Wat bedoel je met 'er bij kunnen'?

Zowel IIS als een VB applicatie kunnen een dll gebruiken..

[Verwijderd]

Verwijderd schreef op 13 januari 2003 @ 14:26:
[...]

Wat bedoel je met 'er bij kunnen'?

Zowel IIS als een VB applicatie kunnen een dll gebruiken..

Ja, mee eens. Maar deze 2 instances zien elkaar niet. De bedoeling is om een gezamelijke queue te krijgen.

Als het wel zou kunnen dan zou mijn probleem idd zijn opgelost.

Ik heb het nu een paar keer geprobeerd te testen maar het lukt mij niet het zo op te zetten dat zij beschikken over een gezamelijke gegevensverzameling.

[Matthijs Hoekstra]

Ik zou voor een MSMQ (message queue) gaan. Als je op Windows 2000 zit een COM+ Queued component maken in VB. Vanuit ASP roep je deze aan. Onder water gebruikt een queued component MSMQ. Super snel en 'bijna' realtime.

Als je dat niet wilt, kun je je ASP ook in een message queue berichten laten zetten wlke je met een VB app kunt uitlezen

[Verwijderd]

Ah zo.

Dan moet je iets maken zodat ze elkaar wel zien...
Als je een DLL in COM+ hangt kan je gebruik maken van de SPM bijvoorbeeld. Dat slaat properties op in het dllhost.exe proces waar je dll in draait (moet je wel een server package maken). Deze properties zijn hetzelfde voor elke gebruiker van die dll.
Als je dan in je VB app die SPM periodiek laat uitlezen kan je changes verwerken. Zoiets kan je natuurlijk ook door een database doen maar dan zit je met een periodieke query op je database..

Die message queue oplossing kan ook wel maar dan moet je je VB app nog steeds de database laten pollen om te kijken over iets nieuws te beleven is.. dat wil je niet een paar keer per seconde. Een paar keer per seconde in de SPM kijken is geen probleem.

Je kan ook zorgen dat je DLL maar 1 keer geinstancieerd kan worden (=een singleton) dan gebruiken beide apps dezelfde geinitialiseerde DLL en kunnen ze dus ook properties delen.

[Verwijderd]

Verwijderd schreef op 13 January 2003 @ 14:37:
Ah zo.

Dan moet je iets maken zodat ze elkaar wel zien...
Als je een DLL in COM+ hangt kan je gebruik maken van de SPM bijvoorbeeld. Dat slaat properties op in het dllhost.exe proces waar je dll in draait (moet je wel een server package maken). Deze properties zijn hetzelfde voor elke gebruiker van die dll.
Als je dan in je VB app die SPM periodiek laat uitlezen kan je changes verwerken. Zoiets kan je natuurlijk ook door een database doen maar dan zit je met een periodieke query op je database..

Interesant verhaal. Ik ben aan het googlen om er meer info over te vinden. De kreten die je gebruikt laten bij mij nog geen kwartje vallen.

Die message queue oplossing kan ook wel maar dan moet je je VB app nog steeds de database laten pollen om te kijken over iets nieuws te beleven is.. dat wil je niet een paar keer per seconde. Een paar keer per seconde in de SPM kijken is geen probleem.

Ik had geen idee dat het bestond Het is een leuke techniek maar voor dit geval lijkt het mij niet de beste oplossing

Je kan ook zorgen dat je DLL maar 1 keer geinstancieerd kan worden (=een singleton) dan gebruiken beide apps dezelfde geinitialiseerde DLL en kunnen ze dus ook properties delen.

Dit is wat ik al een tijdje aan het proberen ben. In een normale situatie gaat dit lukken, maar door de isolatie die IIS veroorzaakt gaat dit denk ik niet lukken.