The Future of Terminal Services: 2007 and Beyond

This is not another article about Bear Paw or how Microsoft is going to remove the world's need for Citrix by building their capabilities into Windows. Instead, this article is a glimpse ahead—way ahead—to how Terminal Services might look in the Windows “Longhorn” timeframe.

This is not another article about Bear Paw or how Microsoft is going to remove the world's need for Citrix by building their capabilities into Windows. Instead, this article is a glimpse ahead—way ahead—to how Terminal Services might look in the Windows “Longhorn” timeframe. This article is pure speculation on my part. I'm taking what I know about today's Terminal Server and tomorrow's Longhorn and making some projections about where Terminal Server will end up.

The only thing we know for sure is that today's Terminal Server and Citrix MetaFrame look absolutely nothing like the future. However, tomorrow's Terminal Server (codenamed “Bear Paw”) and tomorrow's MetaFrame (codenamed “ Hudson ”) also look nothing like the future.

What the Future is Not

All of today's products and technologies based on Terminal Server (including Citrix MetaFrame, New Moon Canaveral, and Terminal Server itself) operate on a “screen scrape” type of technology. The basic idea is that applications run on the server and render their output there, and the server composes the screen. Then, instead of being sent to the physical display adapter, the server routes the screen to the Terminal Services subsystem where it's broken apart, wrapped in RDP (or ICA ), compressed, encrypted, and sent to the client device. Today's Terminal Server is nothing more than a glorified KVM switch.

The next version of Terminal Server from Microsoft is codenamed “Bear Paw.” Regardless of what Citrix and Microsoft say publicly, we know Bear Paw is real. We know it's going to have many of today's MetaFrame features like seamless windows and application publishing. We know it's going to come out sometime before Longhorn. (My personal guess is mid 2005.)

However, Bear Paw is not the future of Terminal Services. All Bear Paw does is take today's “screen scrape”-based Terminal Server technology and wrap some slick management features around it, just like Citrix.

So what about Citrix? Their MetaFrame products are based on Terminal Server, and they makes use of the same “screen scrape” technology. Sure, Citrix's new “Hudson” version of MetaFrame Presentation Server (due out later this year) will make several important steps towards Microsoft's vision of seamless computing (as seen in features like dynamic “follow me” roaming). In fact, over the next 18 months, Citrix will most likely integrate the newly-acquired Expertcity GoToMyPC technology so that users can start an application on a local workstation and then have it “follow them” to other devices once they leave that workstation (with users accessing the application on that workstation via ICA and the standard Web Interface and Secure Gateway components). However, the point remains that underneath all the shiny new features, the “ Hudson ” edition of Citrix MetaFrame will still be based on ten year old Terminal Server technology.

Will Bear Paw “beat” Hudson ? Will people still need MetaFrame? By the end of 2007 it won't matter. Both Microsoft's Bear Paw version of Terminal Services and Citrix's “ Hudson ” version of MetaFrame will be completely irrelevant.

Terminal Server in a Longhorn World

In order to understand why this will be the case, you need to understand a bit about Longhorn itself. Due sometime in 2006, the Longhorn version of Windows Server will introduce some big, big changes. I've personally been following it closely and even playing with some alpha versions of the desktop edition. It's safe to say that almost everything is being rethought from the ground up. And that includes Terminal Services.

A key architectural component of Longhorn is its presentation layer that's codenamed “ Avalon .” Avalon is a unified presentation model that includes Windows apps, web apps, and all graphics. It manages objects, windows, animation, rendering, composition, and security, to name a few.

One of the major aspects of Avalon will be a new XML-based markup language called “XAML.” (rhymes with “camel”) XAML is the primary way to create a user interface in Longhorn. It provides a way to separate the user interface from the behind-the-scenes logic. The XAML code for a simple user interface might look something like this:

<button>Click Me!</cancel>

At its simplest level it seems like HTML, right? That's because HTML is a markup language too. In terms of interaction and efficiency, surfing the web with a local web browser usually provides for a better experience than surfing the web via a remote web browser on a Terminal Server. Why render a web page on a server and send it down to a client via screen scraping technology when a client device can render it locally? Local rendering provides a performance increase and consumes less bandwidth. (I'm not suggesting you shouldn't surf the web through MetaFrame connections. I'm just using this example to illustrate my point.)

Conceptually, this local rendering is how Terminal Services will work in Longhorn's Avalon presentation layer. A longhorn application (web, local, or whatever) will send XAML markup code to the Avalon system where it will be rendered to the screen. In traditional Terminal Server environments, the screen would be deconstructed and sent down to the client device as screen pixel data. However, why not just send the raw XAML code to the client device directly? After all, this solution is good enough for web surfing. The only reason we don't do this with today's Windows apps is because there is no XAML-like intermediary.

An added benefit of this model is that we will finally get “true” local and remote application interaction and integration—far beyond today's “cut and paste” integration. We'll also see “remote” applications that feel local, complete with the proper local colors and themes.

Will this be the end of our niche? Will Citrix's dominance of the thin client computing industry die as the industry fundamentally changes? Will I get everything I predicted horribly wrong? I can't wait to find out.

Regardless of what happens, every application will fundamentally have to execute somewhere, even in the future.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by Brian Madden on March 10, 2004
Now that Longhorn is pushed back to 2007, that means this Avalon stuff won't be picked up big time until 2010 or so. That gives us 6+ years of screen scrape technology remaining, and it gives Citrix, Terminal Server, and people (like me) who make their livings off this a bit more time.
This message was originally posted by an anonymous visitor on March 10, 2004
This is a very neat idea but for practical reasons is not a replacement of the current model. For instance, Avalon will require to applications to be build using the "Avalon" model instead of the GDI traditional model. This will take years. This model similar to Mozilla's XUL is fine for basic applications, but once you need to do complex graphics it falls short. You will still need to deal with primitive drawing calls.

Another big challenge is the client. With the current model is fairly easy to write clients in different platforms, with Avalon the story is far different. Also hardware requirements will increase.

Besides, the current model is bad with slow connections but over time this will not be an issue.

I guess we'll have to wait and see.
This message was originally posted by Cooledit on March 17, 2004
Had some nice sharing thoughts.
Now we have been in the IT industri for more than a decade, is there anytime were Microsoft have made a 100% fully functioning product that no one can beat ?. Haven´t seen it yet. For instant has Microsoft an additional tool for trouble shooting their own problem regarding Networking of clients ! Nope.
I wont sit here and just give away all my ideas but they lack something.
This message was originally posted by Cooledit on March 17, 2004
just stopped by, would like some (Network diagrams, or some programming diagrams to see what exactly happens in the new Avelon, too see the structure).
Some calculations on bandwith if availiable.
This message was originally posted by Gareth on April 9, 2004
An Avalon-style RDP protocol wouldn't transfer XAML per se. It'd transfer updates to the Scene Graph. In Avalon, applications update the screen by manipulating the Scene Graph, with GDI updates treated as a special case. XAML is just one way to put objects into the Scene Graph but not the only way (and it can also build things that aren't visual at all).

Since the Scene Graph can contain animations and the contents of all windows, Terminal Services clients that maintain their own Scene Graph won't have to communicate with the server for animations or swapping between windows. And since the Scene Graph is resolution independent, Terminal Services would be too.

Sending XAML itself feels more like 'smart client' to me, not Terminal Services.

I think there's an MSDN article that says much of this, though I can't seem to find it right now and could be wrong about that. I'm pretty sure about the Avalon fundamentals though.
This message was originally posted by Brian Madden on April 9, 2004
I've learned a lot about Avalon since I first wrote this article (only three months ago!). I totally agree with Gareth. The main point should be that Terminal Services in a Longhorn timeframe will be able to move beyond pure screen-scrape captures.
This message was originally posted by Brian Lilley on May 3, 2004
I don't see anything wrong with screen scraping! The idea of .net/longhorn is an honourable intention, and yes it will take the next ten years for this technology to filter through, by which time, bandwidth worries will be a thing of the past. The big drive for local intelligence, will be- exactly that, a platoform that executes at the bottom of the ocean, in a tunnel, wherever.
It is exciting to be in this part of the industry because of the dynamics. Besides which, these new fangled computer things will never catch on, you mark my word.
This message was originally posted by Ian on May 19, 2004
Screen scraping would go a long way if more end device capabilities were used for the "slow" operations. For example, JPG, MPEG and animation- since these today are highly compressed and efficient, should't the screen scraping just be able to pass these natively to the client, and only worry about the other stuff? HTML by itself is pretty verbose- hence the niche that companies like NetZreo, etc. are able to exploit with "browser" accelerators.
This message was originally posted by Runner Up on August 20, 2004
Hey. You are all forgetting something. Tarantella has been around for a while too, and they are already doing a great job of seemless application publishing in Microsoft's Terminal Services. I know - I was not a believer either - until I tried it. and It's cheap. Really cheap. It's amazing that Citrix has stayed alive this long with a comp like this. Citrix is running out of ideas and features to add. They'll be gone sooner than you think. Remember Novell?
This message was originally posted by John D. Hamrick on August 21, 2004
You comments from a technical perspective make sense. From a practicle viewpoint, things are working just fine on Terminal Services with this release of W2003. Users and companies don't care about all of the "code" behind their computing experiences, the time is now. 80% of the computer users of the world would do just fine with an XPe based thin client and a cable internet connection. Ask me how I know.

Nice Writing.
This message was originally posted by Bart Smith on November 2, 2004 offers xaml today. Also see
This message was originally posted by Nick Soefje on November 10, 2004
Don't forget about the security benefits of screen scraping.
You're right about smart screen scraping. Go check out the changes to speedscreen in mps 3.
Would XAML reduce the lag time that we experience when we type and click on things?

I use to access my work computer from home. It is very nice, and powerful, but sometimes the latency can be a little annoying... especially when typing.
I don't know that I understand what you're trying to convey here as there are several unrelated technologies discussed. But at a mimimum XAML is a technology that won't be mainstream until Longhorn. Even when the technology does appear in Longhorn it's not likely that all apps will adopt it.

How would you define screen scraping in the simplest of terms?
and what's its benefits?