Featured discussion: Why are developers still using DCOM?

One Builder.com member wants to know why more people aren't using Terminal Services to deploy applications instead of sticking with DCOM.

Builder.com member neo raised an interesting question recently in our discussion forum. He really wants to know why more people aren't leveraging Terminal Services instead of developing distributed applications with Distributed COM (DCOM), given that terminal services seem to more fully achieve the ideal of a zero-client-maintenance application.

Neo thinks DCOM clients aren’t thin enough because part of the installation is required at the client, which is a problem for the programmer because:
  • The programmer is likely to support the client machine even if it has nothing to do with the installed application. Neo writes: “I have heard customers saying, ’Your program has ruined my Word application.’”
  • The programmer must update all client machines when customers want to change the program interface.

Neo notes, “With Terminal Services, you just install the program at the server machine and every client machine will use the program as if the user is at the server machine. In this way, the program is truly at the server machine and the client is truly thin (if not nonexistent, because you don’t install any part of the program there). With Terminal Services, there are no mappings, and the users will refer to their system administrator for most network problems."

A new twist on dumb terminals
Terminal Services is a set of components built into Windows 2000 Server. It allows a server to deliver what is essentially a virtual desktop to any connected client machine, even one (gasp!) that doesn't run Windows itself. The Terminal Services client machine essentially becomes a dumb terminal, transmitting keyboard and mouse input directly to the server for processing. While this may seem like a throwback to the olden days of computing to some, the approach offers advantages over other distributed architectures. In addition to removing client-side application maintenance from the equation, as neo points out, developers gain benefits in better version control, while administrators only have to worry about one box instead of many.

Single points of failure and simple economics
Perhaps the reason more people aren't delivering applications through Terminal Services is simple inertia. Existing DCOM projects represent a significant investment to the organizations that have implemented them. Ripping out that functionality and replacing it with a single central application delivered by Terminal Services would seem like madness to many bean counters.

In my mind, there's another reason, and it’s been called the primary advantage that "fat client" computing has over the thin or dumb client computing—the single point of failure. A DCOM application, properly designed, at least has the potential to provide some basic functionality to the user should the server connection be lost. In contrast, if a Terminal Services client can't connect to its server, the user is simply out of luck.

Terminal Services: Next wave or old news
What do you think of deploying distributed applications through Terminal Services? Could it replace DCOM as a distributed computing platform? Do you use it as such already? Head over to the discussion and tell neo what you think.


Editor's Picks