VB and php

[Beavis]

I have a VB model which I'd like to interface with a php-based website.  The site will pass variables to the visual basic code, which will do its thing and then return output variables back to the website.  Anyone have a suggestion on how to accomplish this?  Thanks

[tristanreid]

Yeah, I think what you want to do is make a COM object and call it from PHP. The last time I used PHP was not in this millennium, so I might remember wrong, but I think you just call it like

$myvar = COM("yourClassName");

$myvar->prop1 = smthng;

etc.



The way you create a COM object from your code is to make a new project of type class library, set the compile properties: turn on the "register for COM interop". You're probably better off googling the steps, there are probably some other details, but that's the gist of it.



-t.

[Beavis]

Thanks.  I don't see much via google.  Is there an official name for that?  Do you know where I can read more?

[Corey]

I am doing something similar with Ruby on Rails.  I ended up using the backgroundrb plugin, but the gist of the solution was to develop a new table in the database that was a queued list of jobs, and then have the website write to the list of jobs and the external application poll the list.  When the application finished the job, it would write back to another table of results.  Or maybe it was the same table ... I don't remember -- backgroundrb does it all transparently.  Anyway, to keep jobs straight between user-sessions and background clients, you just use a job-id.  This way, jobs can even be done asynchronously, where the background client just updates the table with its 'status', and the website polls the status of the job to presents it to the client (AJAX comes to mind...).



With this technology, I was able to create an auto-scaling EC2 cloud.  I used the PoolParty! library, which allowed easy auto-scaling in EC2 based on computational load.  When a new client booted up, it creates an HTTP POST to my website at a specific URL to register itself.  The website stores the address in a database.  When someone tries to run the process from the website, the web-server finds a random shard, shoves the job in their job-queue, and waits for the results.



What is nice about this setup is that my website front-end allows the user to specify multiple jobs to run at once -- so I can just queue the jobs with multiple background clients and have them all run in parallel.  You could probably do this using COM by booting multiple processes of your VBA code -- but then you don't get the whole 'parallel distributed' effect ... just concurrent on the web-server, which is limited to number of cores.



So ... to sum up: table of queued jobs with unique ids in database.  Application constantly polling database.  Website writes job to database.  Application runs job and writes result.  Website polls database to find % complete, or result.  There may be possible race-conditions if you have multiple clients polling the database, so the web-server should assign the job to a specific client -- meaning that the client only polls the database for new jobs assigned to it.

[Beavis]

So the Application that polls the database can be remote and will have access the MySQL database?   This is probably preferable from my standpoint also.  The site can then be placed on any old server and I don't need to reupload the VB code anywhere other than my own machine, or the machine running the VB application.....

[Corey]

Exactly. I actually had to hack at backgroundrb a little bit to get it to work -- and in my situation, I have each distributed server have its own database. Then, when the user runs the application via the web, the webserver connects to the backgroundrb server running on one of the distributed servers and pass it the job. The backgroundrb server then posts it to its own database, and one of a pool of workers grabs the job and runs it.



There are a couple of ways to do it, but having a central database that all external clients can poll works. Basically, I didn't want the external application to have write ability on my internal web box, so the web server polls the external database on each backgroundrb server for the results.



So, to summarize (because that was probably hard to follow).



Web server gets request to run application.

Web server looks through list of distributed background servers.

Web server chooses one at random and passes it information on the job.

The background server adds the job to its database, where a number of workers are polling.

One of the workers grabs the job and performs the task, updating the database with its status and results.

The web server polls the database (blocking or asynch) for the result, grabs the information, and renders the page out of it.



This scheme protects writing to the web server database.



If you are keeping it all within your network, you might not have to be so wary. But I am using EC2, so I wanted that extra layer of protection.