In the past, I’ve written about server-based computing versus .NET. I viewed the two as competitive technologies. I felt that Terminal Services was a great "stop gap" solution but that ultimately true ".NET" applications would prevail and Terminal Services would die a slow but inevitable death.
I’ve recently changed my opinion, and I now think that Microsoft can use Terminal Services to quickly help customers experience the true value of a .NET world. I also think that Terminal Services will be around for a long, long time (albeit in a slightly different form that it is today).
To understand why, let’s look at some of the technologies in Longhorn and how I think they’ll tie into Terminal Services. I've already discussed in previous articles how future versions of Terminal Services will pass “Avalon primitives” to the client devices instead of / in addition to screen buffer- and pixel-based screen scrapes.
Longhorn is adding quite a few other new elements to the Microsoft computing experience, so we’ll focus on these and how they’ll integrate with Terminal Services.
One of the cool new features of Longhorn is something called “Longhorn Notifications.” In a nutshell, a Longhorn system will have a single, unified, and extensible interface for alerts and notifications. This will include everything that “pops up” to tell the user something, such as low disk space warning, print job completion or errors, new emails, MSN Messenger contacts coming online, upcoming appointments, viruses found, search complete, etc.
In the current Windows environment, it’s up to each application vendor to provide notifications to the user in their own way. Most things use the system tray (those little icons next to the clock in the lower-right corner of the taskbar), although some applications pop up messages on the screen.
In a Longhorn environment, these notifications will be XML-based messages that will be consumed by the local Longhorn client. It will be up to the user (or administrator) to determine what happens when notifications come in, under what conditions they’re ignored or repressed, etc. (As a side note, this should be able to tie into the MSN Alerts service in a cool way.)
In a Longhorn Terminal Server environment, we’ll probably see something like a “notifications” virtual channel or some other mechanism to get the raw notification XML data to the RDP client device where it can be consumed locally instead of remotely on the Terminal Server.
In plain English, this means that notifications generated by applications running on remote Terminal Servers can be acted upon, consumed, and dealt-with locally instead of in the remote application windows. A single Longhorn client interface will allow you to seamlessly manage alerts from all applications running on all remote Terminal Servers.
One of the big changes in Longhorn is a new file-system service called WinFS. Running on top of NTFS, WinFS will provide a relational database interface to the file system. (This will allow one file to exist in multiple folders, enable faster searching, etc.)
Longhorn will introduce “contacts” as a type of data that is stored natively in the file system. With today’s version of Windows, each application manages contacts on their own. Outlook, MSN Messenger, and Local User accounts all contain “contact” information for various users. In Longhorn, all contacts will me managed centrally by the system. In fact, a new tool called “Contact Explorer” will do for contacts what “Windows Explorer” does for files.
With Terminal Services on Longhorn, you’ll probably see a “contacts” virtual channel that allows local and remote applications to seamlessly interact with local and remote contact lists.
Another new UI element of Longhorn is called the “Sidebar.” The sidebar is like a modified taskbar that’s used to display dynamic information about applications that are currently running. Just like today’s seamless windows sessions on remote servers properly use the taskbar and the local ALT + TAB interface, future Longhorn-era applications will be able to share a “local” sidebar that aggregates dynamic data from local and remote applications.
Another one of Longhorn’s modular subsystems will be the chat interface. All applications that use a chat window will be able to share a single interface, and local and remote chat applications should be able to share the same window running locally on the client device, with server-based application chat data being transmitted as raw chat data down to the client device.
What does this all mean?
By this point you’re probably starting to notice a trend here. Most likely, all of these individual subsystems will have “native” integration between server-based and locally running applications. Conceptually, this is similar to the way that the driverless printing solutions from triCerat and ThinPrint work today. (Instead of rendering print jobs on the server and sending down to the client, these products send the raw data directly down to the client device.)
So what does all this have to do with .NET? By transferring Avalon Primitives and raw XML component data via RDP, local client devices will essentially become “presentation aggregators” for applications. This goes beyond .NET web services. True, rich data from multiple applications on multiple servers can be aggregated, consumed, processed, and used by local devices. Microsoft can use Terminal Services as a conduit for getting true .NET applications onto users’ desktops.
In this sense, Terminal Servers will become more like generic application servers, almost like traditional client-server architectures. However, this time around, the performance of the application will not be limited by connection speed or local client resources. Furthermore, the push towards utility computing will build more resilient data centers that are dynamic and flexible.
At the same time, fluid computing technology will allow users to disconnect and reconnect from applications anywhere. (We’re already starting to see this in Citrix’s new SmoothRoam technology.) Applications will be able to dynamically resize themselves and turn on and off different bits of the interface depending on the type of device that you’re connecting from.
I think Microsoft will ultimately change the name of Terminal Services. Most likely we’ll see Terminal Server become something like “Remote Application Server.” (I think Citrix’s “Presentation Server” is a really good name.) Maybe RDP will become RAP (Remote Application Protocol) or RCP (Remote Computing Protocol)?
Throughout all of this, however, there will always be a place for “screen scrape” technology. Ultimately, these protocols and systems will be smart enough to figure out what’s needed where. There’s a good chance that true “thin client” devices will exist for a long time. (Even a truly “dumb” client device will still be able to realize these advantages. The Longhorn Terminal Server will act as their application aggregator, and dumb client devices will be able to scrape a smarter screen.
So where does this leave Citrix, Tarantella, and the other server-based computing software vendors? Stay tuned!