by
Brian Madden
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:
<canvas>
<button>Click Me!</cancel>
<text>Hello</text>
</canvas>
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.
(Note: You must be logged in to post a comment.)