How Terminal Services will Help Microsoft Deliver the .NET Vision

In the past, I’ve written about server-based computing versus .NET. I viewed the two as competitive technologies.

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.

Longhorn Notifications

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.

Longhorn Contacts

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.

Longhorn Sidebar

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.

Longhorn Chat

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!

Join the conversation

4 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

This message was originally posted by brianos on May 11, 2004 well here's an insight into my thoughts on TS's place in distributed computing beyond longhorn... maybe by five years or more...certainly 8-10 years from now....how about this...

ok, well where is it that we are heading? ....not sure, but I think the wish dhoulf look something like this...

full fat interactive flashy graphic applications, sometimes running on our device..if we so choose, or for performance/connectivity/security reasons...some components running on a mainframe/remote peer device somewhere else...no problem.. we prob. still like the idea of local execution of applications, maybe 10 years time we find that 802.11, gprs, satlinks et al have been cooking our brains... or we just decided that we liked having stuff on our personal computing devices...anyway.. I digress

the future.....

"a combination of .net (Virtual Machine) technology mixed with a dose of TS (screen scraping) provides us with our wishlist?? we are almost there......

will we see the idea of web services/remoting taken a stage further and mixed with screen scraping to see not only individual objects instantiated remotely, but also individual components ran and screen scraped from remote machines.. a user won't have a whole session/desktop on a remote machine, just that tiny object+it's graphics rendering.....

this is not so far away.. the layers of abstraction are already beginning to take place in Longhorn..... the apps logic can run on a secure machine... the graphics rendering running on a super fast machine.. or them all running locally on one machine... "

This message was originally posted by Mark Dutton on June 4, 2004 One of Microsoft's first major .NET applications is CRM. I installed CRM 1.2 on our SBS and setup the client on my PC. So far so good... I then installed the CRM/Outlook integration client on the TS. Didn't work.. Went to the public Microsoft newsgroup on this and the official line is that CRM/Outlook integration won't work on TS. How pathetic. This blew me away. A brand new Microsoft product that won't run on TS. We can't use it now and we can't recommend it to anyone. Microsoft promptly removed my question and reply to their response from the newsgroup. I wonder how many times this question has been raised. Doesn't offer much hope for Microsoft's view of terminal server.

This message was originally posted by an anonymous visitor on July 5, 2004 Unfortunately it's not - lets say that all the XML gets sent - who sends it and who receives it and who parses it? Or is that all in terminal services now - with and easy configuration setting. As usual it looks great on paper, but will it work in a real world scenario? Probably not, otherwise it would be deployed.