Web Enabling a VB application 1

[VB400]

I know that the answer to this question is not a simple one but any help or references will be greatly appreciated.

We have an n-tier application:

- User desktops have Business Object DLL and UI
- Application Server has Data Services DLL running in MTS
- DB Server running DB2/400 (or any other DBMS)

If a new user needs to use this application, we have to go through an installation process on that user's desktop. This installs the UI, Business Object DLL and all references for the Data Services tier.

How can we make this application available on the web?

First, Do we have to ftp our application to our website which is provided by our ISP or do we run it directly from our equipment? If we have to ftp everything to the ISP website, then how do run MTS and register the DLL, etc.? If on the other hand we run everything from our site then what would we need to do so that the web users can reach us from the web?

Second, I'd imagine that we'd have to rewrite the UI (or maybe not). The current UI is developed using VB forms, which I've never seen on the web and so I'm thinking that we'd have to write another front end. If this is the case then what are some of the common tools used?

I would like to start by developing a very simple web app to use one function from our application, if I can get that to work then I'll continue with the rest of the app.

I know that this is a very complex topic but any help to get me started will be greatly appreciated.

Thanks in advance!

 

[mohmehran]

As you know, there are a lot of choices to move your app to the web. If you want to minimize the changes, you can change your VB application into an ActiveX document using VB Add-Ins. This converts your forms to something called UserDocument, which will be displayed in IE. But this method is not efficient, since it will require a lot of bandwidth to transfer the data between client and the web server.

A more efficient way is to change user interface and implement it using ASP. As you may know, ASP is a server-side scripting language and uses VBScript as its structure. So you can use your VB knowledge to learn it.

If you have put your business logic into a COM (ActiveX dll or exe), then you are in luck. Since you can call your business functions from ASP files and the rest of the system will not be changed so much.

 

[VB400]

Thanks Mohmehran,

So basically, the back-end and the Business Objects tiers can remain the same and all I have to do is create a new front-end.

What is the best way to get started with creating ASPs? Is this part of VB or is it a standalone product? Can FrontPage be used (will it work with this type of architecture)?

Another question from the original post is "where does all of this stuff reside?". If it stays on our machines that how do web users find it and if it has to be uploaded to our ISP's servers then how does that work (in terms of running MTS, the DBMS, etc.)

The only web development I've done is a very simple page that displays static hard-coded information -- no database access or components of any kind. So, as you can see, I need help getting started with this technology.

Thanks for any help you can give!

 

[MikeLacey]

"you can change your VB application into an ActiveX document using VB Add-Ins"

Is that a standard VB add-in? This might be an option for me as I don't serve apps over the Internet, just our internal network.

 

[mohmehran]

ASP files are clear text, but there are some prodocts out there that help you code in ASP. You can use Microsoft Visual InterDev 6.0 (Part of Visual Studio 98) to write ASP files.

For more info on ASP language, you can refer to MSDN. About books, take a look at

http://www.wrox.com,

since they have nice books on ASP (Professional ASP 3.0 is the best)

ASP files reside on Web Server and they produce HTML format to be sent to the client browser. So the server does not need to know where the client resides. Clients should know the URL of the ASP file on the server, for example:

http://www.mycompany.com/mypage.asp

As I told you before, if you don't want to change your application, you can use ActiveX documents (But I don't recommend using them in The Internet, since they are too slow)

 

[VB400]

I understand what you've explained so far regarding the various tiers, I'm just not clear on WHERE these tiers will actually reside. I know that nothing will reside on the client machines (other than a browser) and I also understand that the UI will be some sort of HTML based interface. I still can't picture where the Business Object DLL, the data-services DLL, MTS and the actual database will reside.

For simple web pages, we normally ftp the files over to the ISP's servers. I can't imagine that we would ftp and run MTS itself and the database (be it SQL Server or DB2/400) to the ISP.

 

[mohmehran]

Let's continue with a sample:

Your clients will be using browser and their connection to your site is via Internet or an Intranet.

You install a web-server machine in your company and put your ASP files on it.

You will need an application server that runs on a server. (This can be the same machine as your web server) MTS also will run on this machine.

You need a database server also.This can be the same as your the web server, or another machine.

NT Web hosts usually have some sort of database installed on their servers. (Access/SQL Server) But if you want to register your COM components on their computers, you will need to have a dedicated or a collocated server. Then you can connect to your server remotely and register your business objects on your server. Most of the times, all of these computers are actually one, but sometimes the database server is a separate machine.

 

[MikeLacey]

"you can change your VB application into an ActiveX document using VB Add-Ins"

Is that a standard VB add-in? This might be an option for me as I don't serve apps over the Internet, just our internal network.

 

[onetomany]

It is standard in enterprise edition. I believe that it is also available in Professional but I'm not 100%. You will have to register the dll for the wizard. It should be in your vb98/wizards folder and named axdocwiz.dll. When you run this wizard some of the code from your original project will not be valid and may have to be rewritten.





Seth

 

[VB400]

So, basically the entire application (all tiers) could reside on this one machine in our shop. This answers my question regarding the registeration of the various components and the running of MTS.

We have MTS currently running on an NT Workstation and assume we'll use Access as the database on the same machine, could this be used as a "web server machine"? If so, what software do we need to make it a "web server" machine?

If we want to have this application available on the internet, then how does a customer on the web find our server? It is my understanding that the ISP hosts our site on THEIR server. For example, if you type

http://www.xyz.com,

it will locate this URL on the ISP's server. Would the ISP route the user to our machine somehow?

 

[mohmehran]

You need to have one of the available commercial or shareware web servers. Regarding your requirements, I think the best solution is Microsoft IIS (Internet Information Server). If your ISP machine is running Windows 2000, you have already IIS 5.0 installed. If not, you can buy IIS from Microsoft and ask your ISP to install it.

Do you have a domain registered on the Internet now? And are you hosting it on any web-host out there?

 

[VB400]

Yes, I just registered our domain name but it just has an "Under Construction" banner.

Based on what you're saying though, I would ask the ISP to install IIS on their server (if they don't have it), but what about all the COM components, MTS and the database itself -- would they have to install all of them as well?

 

[mohmehran]

As I wrote you before, most ISPs support databases, but about regisering COM components, most of them require you to have a dedicated server (that is a server that no one else uses it) to register your own components. Check this with your ISP.

 

[johnk]

I have read that Visual Studio 6.0 will include the capability for our existing VB forms to be compiled so that they will throw off html (XML?) instead of displaying forms in the tier in which they reside. If so, could we not run our client tier modules on a "web server" tier and avoid most of the reprogramming?

Of course that would be months away. And probably too good to be true anyway. [sig]<p>John Kisner<br><a href=mailto: > </a><br><a href= > </a><br> [/sig]

 

[johnk]

What about the state vs. stateless issue? In our &quot;conventional&quot; multi-tier structure the calling module instantiates an object in a lower tier, and that object stays aware of the particular calling &quot;party&quot; and its associated data &quot;state&quot; until closed by that party.

I have no experience with web enabled apps, but when we convert existing apps won't we need to make some fundamental modifications to identify caller and preserve multiple sets of state data? [sig]<p>John Kisner<br><a href=mailto: > </a><br><a href= > </a><br> [/sig]

 

[VB400]

John, I didn't even think about that!

I assumed that when a web user logs in, a whole new &quot;thread&quot; would be created at the UI level. Any calls by the UI to the Business Object DLL (and any subsequent levels) would stay within that thread.

Am I missing your point? [sig][/sig]

 

[mohmehran]

As you know, web sites can have a lot of traffic, and web-server's memory is limited. So you can't instantiate a new object for each user and manage state. That's why most of the web-based apps are said to be state-less. So when a web-server receives a request, it does not normally know which user is this, unless specified by the client (in the request), or some server-side features like using Session object in ASP. But still it is recommnended that web apps are desinged stateless.

Suppose that a user enters your site, your server allocates resources to it, and then user closes his browser. How should your server know anout this? And if you are using a timeout policy, how much should you wait? And what id the user had gone to lunch?

This even extends to the your COM components. It's better to use stateless objects, that is objects without properties. You should only use methods and their paramateres to do diffferent tasks. This will make your app more scalable.

So although there are a lot of ways to minimize the changes, you can not avoid performance considerations in your new app. Keep in mind that your app has not been developed having a web-solution in mind and if you think that your site will have considerable visitors (say 100 concurrent users), I think that you should redesign the structure of your system.
[sig][/sig]