Dcom vs terminal services.

Why bother with Terminal Services or DCOM when you could make a web application? I know not all apps are suited to be web applications, but I'm sure a large percentage of 'em would work just fine as a web application.

Terminal Services have their place and can be very useful as long as they are kept in perspective. About 6 years ago, I worked for the Dept. of Defense and they made the BAD decision to move away from Desktop PCs in favor of the "NEW CALS" system.Leave it to the government to consider dumb terminals as "NEW". The idea was to centralize everything... Word processing, database apps, spreadsheets, graphics apps, everything ran on the server. It doesn't take a genius to see that single point of failure. As long as people don't get into the mode that it has to be all Terminal services, all DCOM, all Desktop, or all Web Apps then they probably have a good shot at success. Depending on the type of application or service being provided a thorough analysis should help determine the best environment to host the app (whether it be stand alone, DCOM, Terminal, or Web)

There are a lot of "hidden" costs in using Terminal Server which if anyone doing some research on will come across before deploying. First off only between 40 to 60 users can be supported per TS at best. Memory needs and CPU load is the reason. For a good TS you need at least 4 GIGs of RAM, 4 CPUs. Then you need to ensure high bandwidth for those 40 people so you are talking 100 Base T connections which means your switches have to be that speed for the 2 TSs you will need -- and dual homed to avoid single switch failure You then need a good TS admin who can configure apps and user profiles for the TS.

Forget any heavy graphic applications. You do not want apps that write to the local drive so everything has to be mapped to a network file server drive for users to write at logon. That means profiles and that means AD for best use and that adds a layer of complexity and political fighting.

Add in the CALs for all apps (You need a license server, you should know what programs are running anyway but having a TS just ensures that you know it).

Start adding all that up and you are about to hit a quarter million dollars in hardware / software up front costs for a 120 to 200 person sized company to put in a TS farm correctly (you can always do it cheaper but then the background support costs and user frustration set in).

You will need an RnD zone too to test apps in and I have factored that in also in the above plus spares for all hardware and cost to expand.

For $50,000 you can purchase 200 copies of MS Office suite. For $240,000 you can purchase every person a 1.6 Gig (or better given discounts) brand new PC complete -- a PC is still needed to access the TS -- and can work online or offline as needed plus can have special apps that will not work on a TS. You do have the support staff to manage the PCs but you would have them ANYWAY even on a TS system.

Tom Philo
www.taphilo.com

We use DCOM extensively. Although Terminal Server is useful, we find it unsuitable for custom distributed applications because:

1..DISTRIBUTED PROCESSING. TS is not really 'distributed'. A well developed DCOM application can be installed on many servers, each sharing a portion of the processing. The terminal server needs to run the entire app itself, AND still serve up the application, process the TS client requests etc. etc.

2..BANDWIDTH. TS is comparitively heavy on bandwidth. A DCOM app has to stream small, intermittent packets of data (obviusly dependant on the type of aplication). TS needs to constantly stream keyboard and screen updates.

3..EXTENSIBILITY. DCOM was designed with expansion in mind. As your application grows, it's relatively easy to add new components to your system, through DCOM. You will probably argue that you can do the same with TS, but aren't you at the very least using COM (more than likely DCOM or COM+) to do it?

4..LICENSING. If you use TS, it's one more product to license, and yet another cost to add to your project's budget.

Don't get me wrong, I'm not against TS. It's a good product, and has it's place, but it's by no means a total replacement for DCOM. A well designed DCOM system will always run faster and be more expandable than running it on TS. I'm referring specifically to the larger enterprise level applications when I make that comment.

I would see TS better served by sharing Office type applications, possible small accounting packages and that sort of thing.

Anyway, just my 2 cents worth...

Most of my app's are "real-time" apps that gather data from a manufacturing process. On top of the vast amount of data that needs to be "quickly" processed, there is also the problem of proprietary hardware that must be used on the client machine.
For me, DCOM works great for some of the DLL's I create, usually for fairly complex process requirements where nothing else will work.

For my line of work, I don't think Terminal Services could replace DCOM, nor do I think that the network groups would appreciate the massive amount of data that would be going over the network...they're usually not even happy with the amount of data I pass when all the work has been done.

Although server based application architecture has its place, a "mix of fat and thin" is needed to support the remote user base which connects infrequently. It is not a question of DCOM vs. TS for that group, but a basic issue of "just in time technology" based on the user's task. A remote user requirement may drive the need for detachted (sometimes robust) functionality, potentially with server database synchronization at various intervals. Couple this with the fact that wireless solutions (CDPD, CDMA, etc...) simply are not there yet, the useage or thick design (or hybrid) has a solid place in the mainstream of application development across user bases for quite some time. Don't throw away your VB book!

My organization (VA New England) has made a major investment in thin clients and CITRIX, for all the reasons quoted elsewhere related to total cost of operation and support / maintenance. However, the downsides are major network bandwidth requirements -- costly and difficult to achieve -- as well as an increasing requirement for multimedia. We continue to push forward, but it hasn't been as cost effective as we would like. For the record, our major clinical application is client-server, but ismigrating to .Net / web services.