VB Version 6.0 - how do I put my program on the Web? 1

[polyquoter]

I've written an executable in VB version 6.0 - the Enterprise edition is what I have. This program uses Access databases and some crystal reports.

Now my client would like to make this program or a version of it run on the internet. I'm having trouble finding out how to do this or where to look to find out how to do this. I only find information about adding ActiveX controls to the form and so on. I'd like to see an example of how this is done or at least find some more detailed instructions.

Thanks........

 

[chiph]

polyquoter -

Since your app is a VB6 Windows application, the most you can do is distribute it via the web (aka put a link to download it on a web site). Although, depending on how you architected it, you might be able to re-use some DLLs or classes.

If they want a true Web-based application, you're looking at a re-write using technologies such as ASP, COM+, IIS, etc.

Chip H.

 

[dilettante]

Actually there are just bunches of ways to do this, but chiph is correct as usual.

Either you make it all available as a download, including the database, and basically lose multiuser capability (everyone gets his own Access database locally) or else you partitiion the application into a user interface at the client and logic and data piece back at the server.

It is amazing the number of choices you have beyond this though.

I'd guess you start by deciding what your client technology is going to be. The three basic options are:

1.) HTML/DHTML page(s)
2.) ActiveX control(s) hosted within a web page
3.) Java applet

I'd rule out the latter for a whole bunch of reasons, starting with the fact you're a VB programmer.

Most everything else is some variation of those three. I haven't messed with VB web classes but I think they come down to basically option (2.) above. Same thing is true for .HTA (HTML Application) clients - this is really just a "trusted" version of (2.) that can be installed locally as an application just like an EXE and show up on the START menu.

Next you need to figure out your "glue" or wire protocol. If you're gonna call it a "web" application you're pretty much stuck with using IIS or a similar web server to host your logic (which will connect to your database). With (2.) and (3.) you could even use plain TCP sockets to get to your main ("middle tier&quot logic piece - but why work so hard? This would require you to build a custom multiuser socket server, build your own security and management stuff, etc. Yecch!

So you basically use either (1.) or (2.) and communicate with an ASP application at the server via HTTP POSTs and responses. Even to use SOAP as your protocol you'd probably opt for the standard HTTP wrapper and thus end up writing ASP pages.

Now, your ASP pages can be pretty thin if you like, basically just invoking your VB code as one or more objects with one or more methods.

The upshot though is that you are looking at a major rewrite and rethink unless you built your application with this in mind in the first place. State-management is one issue, and then there is the idea of reworking your application to be transaction oriented instead of event-driven.

This is a new ballgame.

I have seen people wimp out though, and go with a 4th option. I think it is crap because it eats resources like crazy (including bandwidth).

This is the Terminal Server or Citrix-like option.

1.) You carefully adjust your VB application so that it can run on one machine multiple times under different user contexts. This doesn't have to be a HUGE deal though, but it is important.
2.) Then you host the VB application on an NT 4 Terminal Server Edition box or a Windows 2000 Advanced Server box.
3.) Get enough client licenses for all your users to connect to it.
4.) Then the users can use either the stand-alone Terminal Services client program to connect or use the "Terminal Services Advanced Client" which is really the stand-alone client application repackaged as an ActiveX control in a web page. Then the users download the thing from a web server and you call it "web based" (yecch).

But this way the user interacts ("over the web" but not really using web technology except to host the control) with your VB program (or even the whole server - they can run anything you allow there) as if logged on at the server machine's console.

Of course now you need a REALLY BIG server because it has to be able to run maybe 100 copies (or however many users you have) of your VB application at the same time. This is NOT a scalable solution and isn't really putting your application "on the web" (ok, I've beat it to death now, I know).

Good luck deciding.

Remember, option (2.) lets you present VB forms to the user in their browser (if it can do ActiveX controls, basically IE only). The downside is you need to learn more about DHTML to make it work than option (1.) because you have to deal with <OBJECT> tags and most likely a lot of script.

If you want VB forms at the client I think you might want to look into &quot;web classes&quot; - though I suspect VB.Net has replaced these entirely with the &quot;web forms&quot; concept.

 

[polyquoter]

These are some great options that you've give me this morning. I'm working with an NT server guru so I'm going to share this with him. We will be partners in this venture anyway. Thank you very much.

 

[dilettante]

By the way...

If this will only run &quot;in house&quot; and not truly over the Internet you still have DCOM as an option for connectivity. This is the most &quot;native&quot; way to do this in the first place.

I assume though that you really want outsiders to run this thing. Then you have security problems trying to use DCOM. If nothing else, somebody's firewalls are going to be unhappy and block it.

There is a flavor of DCOM tunneling through port 80, but I believe people gave up on this because of some hacker exploits it opened up. Also, a lot of users are behind proxy servers that don't like this approach, and once again block it.

So I think you really are back to either SOAP over HTTP, or a standard ASP application which amounts to something &quot;ad hoc&quot; over HTTP using POSTs and responses.

But at least try reading up on web classes. This might be the easy way out.

 

[polyquoter]

What we really want is for certain Sales Reps to be able to gain access from their internet connection and place orders into our system. Some of them have Mac's and not windows so we felt this would be a way to overcome the Mac thing. No we don't want the whole world to have access - just 20 to 30 outside employees.

I distributed CD's with my VB program and set up a dial up into our server and transfer type program so they could send in orders. Company thought that wasn't good enough though and there was the Mac problem.

Thanks just wanted to give you more of my particular details.

 

[efrost2]

If all you need to do is have users submit orders via a browser and then write those orders to a db - this is trivial via HTML and ASP. Then once you have the oders on the backend db you can do whatever processing you would normally do.
As far a security goes there are several options:
1. Have IIS use NT authentication (requires that users have an account on the server or domain)
2. Get a third party component or write your own (its not that difficult)
3. Configure IIS to use client certificates (pretty involved)

Hope this helps.

 

[dilettante]

I wouldn't say TRIVIAL. I always think that every time I start a project, then I find two big time eaters: feature-creep and documentation.

But if you have significant logic written in VB already you can salvage a lot of it by having the ASP pages invoke a VB DLL instead of recoding it all in VBScript.

Whole new user interface to build though.

I looked closer at WebClasses and found a lot to be impressed by. Too bad ASP.Net trashed it. I'm not complaining about what .Net replaced WebClasses with, just that - well I like what I see there and hate to see it dropped by the side of the road. I'm pretty sure WebClasses was the entire inspiration behind ASP.Net - which does very much the same thing as WebClasses but &quot;hides&quot; more of the details and improves on a bunch of things.

I agree with efrost2 re. using NT authentication - your Mac guys can log on via Basic HTML authentication with an NT user/pw you give them.

The &quot;component&quot; he talks about sounds like what I described as salvaging your existing VB code.

I find almost nobody bothers with client certs because of all the headaches and heartaches. But be sure and give your users a VERY convenient way to change PWs.

But I won't say this is a trivial thing to get started with - though very doable.

Good luck to you.

 

[chiph]

dilettante -

I had forgotten about the Terminal Services / Citrix solution, basically because of the same problems you outlined (need a big honking server, a little tougher to deploy, and sometimes there are multi-user interactions). Thanks for reminding me of it.

I think the easiest way to salvage what polyquoter has written thus far is to use a thin &quot;veneer&quot; of ASP pages that call into his existing code. And since he's got Mac clients, no fancy javascript & vbscript -- just good basic HTML. His projected user counts are pretty low (20-30), so he can probably keep whatever database (MS Access?) he's using.

Very do-able. Just a little unanticipated work, is all.

Authentication might be an issue, but if the data isn't that sensitive, and he's not that concerned about someone being an impersonator, then an application-defined userid/password is probably OK. I myself would want client certificates, but that's just me.

For anyone who's lurking on this thread -- this is a good reason not to put very much code into your forms. Put all the good stuff into classes & modules, and leave your forms as thin as possible.

Chip H.