Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using DCOM over the Internet 2

Status
Not open for further replies.

johnk

MIS
Jun 3, 1999
217
0
0
US
We have developed multi-tier apps in VB using DCOM. They work well on LANs and also using dial-up phone connection. We would like to use this fat client technology over the Internet.<br>
<br>
Is it practical to do so? Can you point me to specific how-to info?<br>
<br>
Thanks,<br>
<br>
JohnK
 
John,<br>
<br>
Have you looked at DHTML - its the microsoft internet fat client architecture. I have wrote two apps (intranets) base on DHTML and have found it good.<br>
<br>
C
 
Thanks, Calahans. I'll dive into some DHTML info.<br>
<br>
I just read the Editor's Note in Jan '00 VBPJ. Sounds like VB7 will allow us to install our (current) client side tier on the server and it will &quot;kick out&quot; HTML. Then any client with a browser can run our apps.<br>
<br>
Too good to be true?<br>
<br>
John
 
DHTML looks like a strong solution, specially for intranets.<br>
<br>
What I'm looking for at this time is a way to run our existing library of VB form based remote client tier apps using internet as the connection to the local based 2nd tier. For remote users we are using dial up phone connections. (Microsoft told us we were the first anywhere to make DCOM work over dial up phone connections).<br>
<br>
As to the VB7 generated HTML, while it sounds very interesting it obviously would transfer most of the client workload back to a server. Also, I expect it to require considerable rewriting of existing fat VB clients. So as far as running our existing apps it is, in fact, too good to be true.<br>
<br>
So I'm still looking for how to run existing multi-tier apps over the internet. Remember, my MIS tag means I may be unaware of obvious solutions.<br>
<br>
JohnK
 
Hi John,<br>
<br>
Why don't you look to ASP and 'thin client' intranets. If you use ASP you can register all you current business and DAL objects on the machine that you are running IIS on and not have to change any of the components (almost!).<br>
<br>
All you need to do is to write the ASP pages. ASP pages are a high breed between HTML and VBSCRIPT. Relatively easy to a VB programmer.<br>
<br>
I think it would definitely be worth investigation on your part. I think you could be programming ASP without a major investment.<br>
<br>
Calahan
 
John,<br>
<br>
We had exactly this prolbem. A fat VB app that we needed to run over a WAN.<br>
<br>
Speed was dreadful, obviously not acceptable. After some thrashing around we looked at Winframe.<br>
<br>
Winframe (have a look at <A HREF=" TARGET="_new"> allows users to run windows app's, apparently on their own PC, over slow connections. The first time I saw it was running the notepad application - with modem connected to a mobile phone. It pretty much solved all of our c/s speed problems.<br>
<br>
I use WF now even for local applications as it also takes away any upgrade problems - I only have to install new releases on the three servers and not the three hundred PC's that use them.<br>
<br>
Microsoft offer something called Windows Terminal Server which does thet same sort of thing but needs add-on bits to work effectively over slow connections.<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Thanks Mike,<br>
<br>
I just looked at the citrix site. Server based architecture takes me back to my mini & mainframe roots. I dearly miss the centralized nature of them. Some of our apps can be bought for less than $20K, so the minimum $6K Citrix license may be a little steep. May be well worth it anyway.<br>
<br>
What can you tell me about tiem & expense & aggravation, etc. to get going with this in your shop?<br>
<br>
John
 
Hi John,<br>
<br>
We didn't really have any technical problems implementing this at out site - just fiddly bits and the odd patch here and there. Very unspectacular - it just worked. If your app is particularly graphic intensive then performanc will suffer. Load on a leased lines seems to similar to a vt100 telnet session. We didn't have to change our app at all.<br>
<br>
&lt;grin&gt;We did have some problems with our Development Architecture Committee in the US&lt;/grin&gt; who got a bit soggy and hard to light when they figured out what we'd done - and that we'd recommended it to Cargill Holland who were doing the same. But WF in use pretty much all over Cargill US now so I guess we're forgiven.<br>
<br>
The expense - I used to spend my days fixing individual client setup's and travelling all over the UK to do so. I don't anymore, I haven't visited my (five) remote sites since we implemented WF.<br>
<br>
It's a product I find hard to criticsize. It makes your current windows apps run over a WAN/the internet with no change. It makes them easy to maintain and upgrade. The users would quit using the apps if we took WF away. All this and I don't even get a commission from Citrix for recommending them.<br>
<br>
Makes a change for me to be able to contribute something to you dcom guru's. &lt;smile&gt;<br>
<br>
Regards<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Mike,<br>
<br>
I don’t know how to say this without pointing to a very possible colossal (on our scale) wrong direction I took in ’96. The one thing that got us committed to DCOM was our inability to achieve satisfactory response times over dial-up connections. PC Anywhere was rejected by a customer because of the requirement of the extra PC for each connection.<br>
<br>
Now you acquaint me with this product Citrix that seems to take care of all of that, and would run just fine for our 20 to 30 user systems without multi-tier at all!<br>
<br>
I'll now have to reexamine the cost/benefit picture of dealing with DCOM. Win2000 Certification from Microsoft requires it and that may be important to us. Of course, larger networks where load sharing is needed will require it.<br>
<br>
Again, thanks for sharing your experience. I’ll take a good look and keep you posted.<br>
<br>
Warm regards, John<br>

 
Hmm,<br>
<br>
That was pretty much Microsoft's reaction when WF started to get popular - they weren't best pleased.<br>
<br>
Seems to me that the benefits you got from having to go with classes are not to do with performance over a WAN at all.<br>
<br>
We're starting to put commonly used functions into DLL's now - even on the WF servers - so that each app runs from a common set of utilities. Not quite DCOM I'll grant you but the analogy's plain I hope. Time spent organizing an application's architecture is rarely wasted.<br>
<br>
Load Sharing -- Hmm. Take a look at Citrix Metaframe. Designed to share users out to the least busy server in a server farm - that's what we do.<br>
<br>
They should put me on the payroll - I'm going to shut up now before I get red-flagged.<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Hello All,<br>
<br>
Can somebody explain to me in a non-textbook way, what you mean by fat client (vs. thin client).<br>
<br>
Thanks
 
VB400,<br>
<br>
I'll take a non-textbook crack at your question.<br>
<br>
Many of us think of the client as the machine that the individual user's keyboard, mouse & monitor are hooked to. The client machine is connected to a server machine, on a LAN, WAN, dial-up direct connect, over the internet, etc.<br>
<br>
The fat/thin terminology describes how much processing is done on the client and how much on the server. In the mini computer with dumb terminal systems, almost all is done on the server. In early client/server systems all processing except data base interaction was done on the client. I consider this as the &quot;fattest&quot; client.<br>
<br>
Now, with newer software technology like DCOM, the designer has options of moving much more of the application logic off of the client to the server, hence the term &quot;thin&quot; client.<br>
<br>
This is my manager's concept of the subject. My more technical friends may well post corrections to this, and I would welcome such.<br>
<br>
JohnK
 
ok....<br>
<br>
slightly more technical.<br>
<br>
Citrix developed a communications protocol called Independent Console Architecture (ICA) that describes what is on a windows screen, what the mouse is doing and what the keyboard is doing. You run a small program on your PC (your thin client - could be a 286, that small) that passes key strokes and mouse events up to a server (a WinFrame server) and accepts a stream from the server describing what the screen should look like.<br>
<br>
This is a &quot;thin client&quot; (in this context anyway). The application itself runs on one machine (the server) and the display, keyboard, mouse etc run on another machine (the client).<br>
<br>
If that makes your head go 'round -- just ignore it.<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Thanks John and Mike,<br>
<br>
Based on my understanding of this I would guess that applications running on the Web basically use thin clients (in a fashion similar to Winframe) in the sense that the users worldwide do not install anything on their machines other than a generic browser but they all can use any application on the web.<br>
<br>
In John's case, your application has a VB UI tier that you normally install on each user's machine. Now you want to have any user anywhere (generally speaking of course) to use the application on the web in which case you do not want to install any software on users' machines. Is this the original problem?<br>
<br>
Tarek
 
Hi guys,<br>
<br>
I relation to thin/fat client technology, I think the crux of the matter is where the processing sits. In the fat architecture all processing including dlls get sent to the client and with the thin version the dll etc are resident on your web server, all the client does is process javascript and outputs HTML.<br>
<br>
C
 
Tarek, As to my specific situation, I do have lots of application code with the UI tier written in VB. It runs fairly fast when the UI machine is connected to the server with dial up telephone connections. My original post in this thread was looking for a way to substitute the internet for the long distance telephone call.<br>
<br>
I would still need to install my UI code on each client machine. Mike Lacey suggested using another software package which would allow me to run even my UI code on the server machine and communicate with the client machine in a way somewhat similar to how a server communicates with a browser. This package, from Citrix, would require a program to be installed on the client machine, but that program could then work with any of my client programs running on the server machine.<br>
<br>
Calahans, I agree with your thinking, but aren't there a number of particular &quot;thin&quot; client technologies? The one you site is certainly one of 'em.<br>
<br>
JohnK
 
Hello,<br>
<br>
I like the idea of having the application running on a central machine as it makes updates and upgrades a snap. We have one client that uses metaframe and it works very well for them.<br>
<br>
Based on Mike's explanation of how WinFrame works, the client sends information to the server indicating mouse events, keyboard clicks, etc. Winframe sends information across the wire instructing the &quot;client&quot; of what to display on the screen. It seems to me that if we have a slow Wan to begin with then sending every key stroke across the wire would be very slow! Also, receiving data and screen layout across the wire would seem much slower than receiving just a lonely variable (say a serialized string)!<br>
<br>
I know I'm wrong about these assumptions otherwise Mike wouldn't be using this approach; however, it really doesn't make sense to me that sending data along with entire screen instructions (images) across a slow Wan connection is faster than sending one piece of data (a string).<br>
<br>
Am I crazy for thinking that?<br>
<br>
Tarek
 
Tarek,<br>
<br>
Citrix compress everything they can - and compress more if they detect a slow link. For the screen, only changes are sent and not the whole screen. As I said in my original post - I saw this demo'd over a mobile phone (9600) and it was still usable with a *very* poor mobile phone signal.<br>
<br>
So no - you're not crazy - but it is faster...<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
I've heard that there are printing problems Winframe and terminal server - also I heard that microsoft are going to ship Terminal Free with NT, in MS's time-honoured way of dealing with competition.<br>
<br>
Is this true?
 
We don't have any printing problems ourselves.<br>
<br>
Difficult to guess which way MS will jump in a given situation. They already bought the Winframe source from Citrix - TS is essentially WF but without the WAN protocol (ICA) which is still Citrix's in an add-on product to TS called MetaFrame.<br>
<br>
People seem to say all kinds of things about WF &lt;smile&gt; the problem with the product is that it's very good and threatens some vested interests - IMHO. Anyway - here is not the place to discuss Citrix/MS politics - there is a Citrix forum on Tek-Tips.<br>
<br>
-ml<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top