The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Fat client over HTTP - how to do it ?

I have  fat client app written in VB6 (with a rich UI and a lot of Activex components) which connects to MS SQL 2000 server as a backend database via ODBC.

I need to port this application to run over the web. It will run in a corporate intranet where the browser will be IE and Activex security is not a concern. The only thing is that it needd to communicate via HTTP accros firewalls.

Constraints:
- the app UI is very rich and has to stay that way
- can't use .NET or Java
- must use IIS as web server
- my developers know VB6 but they're not really knowldgeable about html/javascript/asp stuff
- don't have too much time
- don't have too much money


Here are my choices:
1- Rewrite everything as a web app using loads of javascript in the browser and connect from the web server to the db via clasic ADO.
2 - Rewrite everything as a web app using Activex in the browser and connect from the web server to the db via clasic ADO.
3 - Rewrite the fat client to connect to SQL server over http via SQLISAPI.

Option 1 means I have to find someone very skilled at javascript and possibly buy some already made javascript widgets.  The cost is high and it will take a while to rewrite everything from scratch.
Option 2 has the chance to be slightly less costly since I can re-use the Activex in the browser but I still have to create a whole new app. And also have to find the right skills for this.
Option 3 will allow me to reuse 80-90% of the existing code and skills thus it will require the less amount of investment.

Option 1 and 2 have also the disadvantage of a new developer having to learn the whole business logic which can lead to unexpected delays.

So option 3 looks like the way to go in the immediate future, although my dream would be a lightweight dhtml client w ajax (that's option 1) but this just won't happen anytime soon.

I'm thinking to basically replace the ADO calls in the VB app with calls over http to SQLISAPI but have no idea how.
As far as I understand SQLISAPI acts like a convertor transforming SQL queries into XML and viceversa. On the client side I would need to rewrite evrything to use XML and do HTTP calls with wininet.dll, is that correct ?

My question is how to do this ? Is this realistic ?

Any links to code samples or whitepapers explaining this would be highly appreciated.
Stefan Send private email
Wednesday, December 21, 2005
 
 
"
[SNIP]
It will run in a corporate intranet where the browser will be IE and Activex security is not a concern.

Constraints:
- can't use .NET or Java
- don't have too much time
- don't have too much money
[SNIP]
"

Please have a look at the above lines once again and see if anything is wrong.
If you do see something wrong, then just gather some courage to tell the clients that what they are asking for may not be feasible. If your app is already doing it's job, then why break it. And please do realise that porting a fat client app onto a thinner client will require a major review of what might break during the conversion.

On contrary, if you dont see anything wrong, there are a load of project post-mortems you could read, project rescuers to talk to and then decide on how to continue...
Vineet Reynolds Send private email
Wednesday, December 21, 2005
 
 
Thanks for the quick reply.

The reality this business operates in requires to relocate part of it's workforce into remote areas. The remote users can't use VPN to connect to the database - because of various reasons - so they can't use the existing 2 tier model.
So fat clients running over http/proxies/firewall seems to be the fastest/easiet thing.
The language/platform thing is another element I don't have any control over and I'm not really willing to go into a debate about.

So, my question is a technical one not really a business one.
If anybody has any ideas about how this would work -technically speaking .....
Stefan Send private email
Wednesday, December 21, 2005
 
 
"So fat clients running over http/proxies/firewall seems to be the fastest/easiet thing."

You hit it spot on. Let me filter it for you - rewrite only that portion of the fat client that does the networking. Hopefully you have separated the networking from the database access and business logic. Given that, you only need to code the server to support Http requests (sent from the fat client for remote users), as well as normal requests(the existing method used in the VPN). Should work.
Vineet Reynolds Send private email
Wednesday, December 21, 2005
 
 
Umm I dont know if this will sound funny, but I think you may not even need to code anything (atleast for the time being).

Ever thought of a "Terminal Server" based setup for supporting the remote users?? You could buy some time off by supporting remote users this way, until they really want a corporate intranet based solution.
Vineet Reynolds Send private email
Wednesday, December 21, 2005
 
 
Yeah - you're using a piledriver to squash a spider.

Terminal Services was MADE for your application.  Just plug one in and you don't have to rewrite a single line of code - as long as your app doesn't put pre-named tempfiles into fixed directories or anything stupid like that.
Karl Perry Send private email
Wednesday, December 21, 2005
 
 
That's the problem - I can't use TS simply because TS doesn't use HTTP. The clients will have to access the server from ANY network that has internet access. That means it has to go through proxies /firewalls like any web traffic.
Sorry for the confusin, the description of the typical intranet doesn't apply here, that's my fault for calling it corporate intranet.

The bottom line is that I want to do a 3 tier architecture and I was wondering if anybody did that.
Something like this http://msdn.microsoft.com/library/en-us/xmlsql/ac_xml1_64md.asp but using a VB exe instead of  html in  the browser.
Stefan Send private email
Wednesday, December 21, 2005
 
 
OK... I'll take a crack at it. It sounds like you need to setup IIS and create a webservice that will handle communication to the database. In reality, the best way I see you doing this is via .Net and VB.net. I know you mentioned no .Net but this would only be on the IIS server  and is pretty simple.

In your client you will need to modify/build/buy the means to talk to the web service via soap etc. This can happen via HTTP on port 80. I'm assuming the only open port on the companies firewall.

You might try searching for:

VB + SOAP
WebServices + .Net + asmx

etc etc.

Hope this helps some...
TownDrunk
Wednesday, December 21, 2005
 
 
I'd look at using xmlrpc. From http://www.xmlrpc.com/ ,  "It's remote procedure calling using HTTP as the transport and XML as the encoding."

Google turned up http://www.yoursurfice.com/Content/XMLRPCCOM/XMLRPCCOM.htm , which is a COM object that implements an xmlrpc client and server.

That's about as much as I can suggest. You should be able to turn the server side VB code into COM objects that you can access from something in IIS. Would dotnet (asp.net) be acceptable there? I know nothing of IIS / windows server side programming, its probably possible to access COM components from classic ASP.

Wednesday, December 21, 2005
 
 
TownDrunk
Wednesday, December 21, 2005
 
 
The way I have handled this in the past is to write a fat client and an application server.

The fat client sends all requests to the server using homegrown XML-RPC (some kind of XML protocol over HTTP). I use XMLHTTP for the HTTP POST, which has the added benefit of supporting HTTPS.

The application server is responsible for unpacking the XML request, hitting the database as necessary, and returning a reply in XML. If all you are doing is moving the SQL calls from the client to the server, the server should not be complicated at all. You don't need IIS, or ISAPI, although it might make your job easier then writing a small application server.
MBJ Send private email
Wednesday, December 21, 2005
 
 
BTW, SOAP is an option, but you do not need to use it unless you want to. There are plenty of web apps that use simple XML over HTTP without SOAP.
MBJ Send private email
Wednesday, December 21, 2005
 
 
.NET should be fine on the server I can live with that, it's on the clients I can't use it.

I only need to talk to the db over http, I don't really want to make any remote COM/API calls or anything like that. I don't want to write my own server, just a connector should be enough - like an asp page or something like that.
Sounds like SOAP is the way to go. As far as I understand SOAP tends to be more complex than XMLRPC. But if I want to go with XMLRPC I would need to build my own call listener to access OLEDB on the SQL server side. Since MS SQL Server 2000 already comes with the XML gateway it makes sense to use it and then I'll have to take care only of the client side.
Stefan Send private email
Wednesday, December 21, 2005
 
 
By sticking onto the browser based client setup, you are forcing the architecture to have a thin-client architecture.

Do look at the following link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/termserv/termserv/embedding_the_remote_desktop_activex_control_in_a_web_page.asp

If you really want to save time and money, go for terminal services until your folks can learn and get a fat client app up and working.
The firewall/proxy is still an issue, I'll get back to you after some research on how to get past it using RDP.
Vineet Reynolds Send private email
Thursday, December 22, 2005
 
 
First the good news. SQL Server 2000 does have an "official" way to connect over HTTP: SQLXML. So no additional server component is required.
Now the bad news. SQLXML usually returns  responses as XML data. If your existing application uses ODBC, I assume you are using ADO recordsets for all your data access. You'll have to translate all your RecordSet.Open calls to something like XMLHTTP.open calls, and then take the results and possibly translate them back to ADO recordsets so as to keep most of your existing code intact. It's possible: I did it some years back, although for a project smaller than yours. But it's nasty, and takes time to get just right.
Raj Chaudhuri Send private email
Thursday, December 22, 2005
 
 
A long time ago there was a thing called Remote Data Services which was for exactly this - transporting COM native types and ADO Recordsets over HTTP. You write a DLL that runs in IIS and instantiate it on the client with a simple CreateObject(...,<URL), then you can treat it as a normal COM DLL, so long as you only pass native types and Recordsets.

However it never was that well supported and seemed to die a death. Worked fine though.
Larry Lard Send private email
Thursday, December 22, 2005
 
 
"A long time ago there was a thing called Remote Data Services which was for exactly this - transporting COM native types and ADO Recordsets over HTTP. You write a DLL that runs in IIS and instantiate it on the client with a simple CreateObject(...,<URL), then you can treat it as a normal COM DLL, so long as you only pass native types and Recordsets.

However it never was that well supported and seemed to die a death. Worked fine though"

Yep right. It was in 1997. It died because it was supposed to compete with the normal GET-POST model of the internet.
Have a look at it here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdhowrdstutorial.asp

And if I'm not wrong, this was a pretty nasty tutorial.
Vineet Reynolds Send private email
Thursday, December 22, 2005
 
 
RDS seems to be even better. I mean easier in terms of the changes required on the client side.

I don't know why I didn't even considered that in the 1st place. I was under the impression RDS was somehow being phased out and discouraged by MS. Seems to be exactly what I need -3 tier architecture.
Stefan Send private email
Thursday, December 22, 2005
 
 
+1 for terminal services, Citrix, etc. 

RDS-type solutions are likely to have serious performance problems.  I'd be willing to bet the application is chatty as hell, hitting the database whenever you touch certain widgets, etc.  This will be dog-slow over a remote link.

Remote client apps are architected to batch up requests, cache data, etc.  It's not simply a matter of replacing the data source.

Just accept the fact that you'll have to either rewrite the app or deploy it on TS before you piss away a lot of time and money on half-measures.
dave
Thursday, December 22, 2005
 
 
"RDS-type solutions are likely to have serious performance problems."

That's nothing. I've done some research on why MS stopped encouraging RDS. Bottomline - huge security problems. majority of the website defacements in '99 was because of 2 bugs - CFM bug and the IIS RDS exploit.
The RDS exploit is outlined here:
http://www.microsoft.com/technet/security/bulletin/ms98-004.mspx

Forget RDS, use SOAP or something better and secure.
Your client might not like the idea of remote control from a hostile network, even though it sounds great without the security aspect cutting in.
Vineet Reynolds Send private email
Thursday, December 22, 2005
 
 
The RDS vulns were easy to lock down though, and you could turn off the default BO so only your own could be instantiated.

I don't want to come across as some kind of RDS evangelist, I'm just saying it worked, I shipped stuff based on it, but it was clear that it wasn't in the vision for the future of MS' remote data access tech. As someone has said, you're probably looking at significant reengineering anyway.
Larry Lard Send private email
Thursday, December 22, 2005
 
 
One cheesy solution is to have your ASP page pass through the queries to SQL Server using ADO, and then use the ADO rs.Save() function to save the recordset in XML format. You can then send that XML back to your client and reopen the recordset using rs.Open() on the client. The client will have to use ADO as opposed to ODBC. Probably not real fast, but it should work.
MBJ Send private email
Thursday, December 22, 2005
 
 
First, someone mentioned ASP and rs.save. I love this. In fact, you can set it to stream a binary recordset to client side VBScript. I've done some cool stuff with that.

Second, You can configure Terminal Server to use port 80, or any other port for that matter. It involes changing the listening port on the PC (a reg setting) and putting :portnum after the address when you configure the connection.

On top of that, Citrix offers something-- i think it's called nFuse-- which provids A WEB-BASED INTERFACE TO ANY APP. I think it uses a Java Applet to basically create a citrix-session in your browser. I've never used it but it was pitched to me before. looked cool.
Shane Harter Send private email
Thursday, December 22, 2005
 
 
Thanks for all the replies.

As for using terminal server this will work only if I create an http tunnel with a client on the remote and a forwarding listener on the local DMZ.
FYI, for those who vigorously favor TS and all that stuff, the TS client although it can run in the browser as a Java applet or Activex and although it can be configured to listen on port 80, it uses the RDP protocol and so it won't be able to get passed through most of the proxies/firewalls which are allowed to forward http only.
Stefan Send private email
Thursday, December 22, 2005
 
 
I know you've already heard it above, but let me clearly point out that you have more than 3 choices:

4.  Reconfigure the network so you can make VPN work; connect your users over VPN.
5.  Reconfigure your network so a Terminal Server is available on the DMZ so people can run your fat app inside the network firewall.
6.  Combination of #4 - VPN, and #5 - set up Terminal Server for optimal performance (but perhaps not necessary).
7.  Rewrite your app as a web-based app; explain that this may be faster/more beneficial than an HTTP retrofitting of your existing app.  I don't know, you could at least point it out as an option.

Please note that the network configuration can change, believe it or not!  Also note that options #4 and #5 involve someone else changing the network, which means you have to convince someone that it's worth it to change the network around, which is hard.  But at the very least, #4 - VPN - should be worth it, period.  VPN is invaluable.  Also please note that there are cheaper (but more technologically hack-ish) VPN-or-Terminal-Server-like options for small businesses.
pds Send private email
Friday, December 23, 2005
 
 
"Regardless of how you connect to a Remote Desktop server, if either your client or your server is behind a firewall or proxy server, you won't be able to connect unless you open up the necessary port, 3389, to permit the Remote Desktop Connection capability to pass through.

Here server means the computer that's actually serving up the Remote Desktop session. This could be a Windows XP Professional-based computer running Remote Desktop Services, or earlier versions of Microsoft Windows NT/2000 Server running Terminal Services, or even a Windows NT 3.5-based computer running Citrix."

Heck, you don't even have to worry about security if your clients use 128bt SSL over a low bandwidth connection. I dont see how the existing security is going to be retained/enhanced with all that client side coding that's going to be done.
Vineet Reynolds Send private email
Friday, December 23, 2005
 
 
"won't be able to connect unless you open up the necessary port, 3389, to permit the Remote Desktop Connection capability to pass through."

------ sorry. whoever said this just doesn't know what they're talking about. I'm writing this right now from home, connected to my work PC using Remote Desktop on PORT 3386. The way I set it up, port 3389 is one PC, port 3388 is another, 3387, etc, etc, etc.

You can use whatever port you want. You just have to change the listening port on the PC you want to connect to. It's a reg setting. Off the top of my head:

HKLM > System > Control > Curr Ctrl Srt > Terminal Server > Win Stations > RDP-TCP

change the PortNumber key to whatever you want.

Then, in the remote desktop client, if you select port 80, connect to:

123.1.2.3:80

It's just that simple. Yours will be the only PC listening for an RDP connection on that port.
Shane Harter Send private email
Friday, December 23, 2005
 
 
I was trying to differentiate between HTTP and RDP traffic being blocked or unblocked by the firewall/proxies. It really doenst matter after all. It's just the TCP/UDP ports that need to be opened.
Yes, you can change the ports at the client and server end, but it wont differentiate between HTTP and RDP traffic unless it's a "big brother" firewall.
Vineet Reynolds Send private email
Friday, December 23, 2005
 
 
Just use remobjects. http://remobjects.com

Remoting for the real world.

Friday, December 23, 2005
 
 
Since when does remobjects support VB6?

Spammer. ;-)
MBJ Send private email
Monday, December 26, 2005
 
 
Stephan,

Further to the idea of using Terminal Services or similar, you may like to investigate a product called "FirePass".  It's a VPN solution which is, in effect "zero install" on the client machine (it's just an ActiveX in IE).  It uses HTTP (with SSL) and allows all TCP/IP traffic to be securely tunnelled over that HTTP link - including Terminal Services.

I'm fairly sure that the combination of FirePass and Terminal Services would suit you very well.  Here's the web site: http://www.f5.com/products/FirePass/ (I can only see "Enterprise" products on the site at the moment.  I've seen cheaper FirePass models too, so email me if you can't find them on-line.  Some of my work colleagues install them, so I can ask around for you if you like.)
John Rusk Send private email
Tuesday, December 27, 2005
 
 
Hi Stephan,

I've recently been playing with a VPN product, which is free, and really quite cool. In your situation I think it'll work.

www.hamachi.com

It's a peer-to-peer VPN client (no server) that goes through pretty much any firewall / router, and "just works". No configuration. Basically it'll only take you a few minutes to fire it up and see if it works for you.

Also it's very secure - endorsed by Steve Gibson no less (www.grc.com).

BTW - I'm not affiliated in any way, just a happy user.

Cheers
Bruce
Bruce Johnson Send private email
Thursday, December 29, 2005
 
 
Wont products like the one at http://barracudaserver.com/examples/BarracudaDrive/HttpsTunnel/ help? Basically you want to figure out how to tunnel your database connection requests over HTTP using existing software (and there are a number of these).
Grok2
Friday, January 06, 2006
 
 
Here is an interesting article describing how you would do something like this -- the article uses SSH though to tunnel the database requests...you could do a similar thing with SSL based products.
Grok2
Friday, January 06, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz