Citrix announced at iForum today that they are developing application streaming technologies to make centrally managed desktop applications available offline to client machines. From a marketing standpoint, this is exactly what Softricity does.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
To be fair, Softricity has nothing to worry about. I spent some time in the Tech Lab looking at Citrix’s application streaming project (codenamed “Tarpon”), and trust me, this ain’t Softricity. So while Citrix may targeting Softricity head on in this case, the two companies’ technologies are very different. (Just for the record, the Citrix lab guys never mentioned the word “Softricity,” and they sort of nervously laughed and looked at each other when I mentioned it.)
Citrix Application Streaming (Project Tarpon): What it is and isn’t
Project Tarpon is a set of technologies that are used to package and “stream” applications from a central server to individual client machines. The applications are then executed locally on the client. The cool thing is that the applications are not “technically” installed on the client; instead, their files, DLLs, and registry settings are packaged up and sent down to the client where they’re executed in a Citrix Application Isolation Environment (AIE). This is the same AIE technology that Citrix uses in Presentation Server 4. In fact, this whole Project Tarpon / application streaming thing is really nothing more than “AIE for desktops” with a few management bits written to glue everything together.
The key reason for creating Project Tarpon is that users with laptops can run Tarpon applications even when they’re offline. This has always been a weakness for traditional server-based computing solutions like Presentation Server, so now Citrix can offer a good story for both client/server and desktop Windows applications.
How does Project Tarpon work?
First of all, it’s important to say that at this point, Project Tarpon is just a very early prototype / proof of concept. It is not even beta code yet. I’m going to talk about where Tarpon is today, but it’s important to note that the challenges I outline here may not be representative of the final product. (By the way, with regards to the final product, Citrix has not yet chosen how Project Tarpon will be released. Stand alone? Presentation Server 5? Feature Release? Something completely different?)
Tarpon works by making applications available to users in the same way that current published applications or published content is available (via Program Neighborhood Agent, etc.). The first step is that an administrator must create a Citrix Tarpon application package. This is done by running a special packager utility on a standard computer. The utility watches an application’s installation procedure and makes a list of everything the installation process did (which files were installed, registry keys that were modified, etc.). Once the installation process is complete, the Tarpon packager gathers up all of the bits needed to install the application and creates a package file that sits out on a network share. The package file is then advertised to users or groups like any other Citrix published application.
The next step is for the user to run the application. Project Tarpon requires a client-side agent installation where it basically adds the application isolation environment capability to the client device. Presumably this capability will be incorporated into the standard ICA client when Tarpon is released.
Once the Tarpon application is published, the user clicks on the application icon in PN Agent (or the start menu or wherever). The client retrieves the application’s information from the server. The client sets up an isolation environment and copies the application’s main executable into it. Then the executable is launched.
There are some file system and registry filter drivers as part of the isolation environment that watch for resources the application calls for. If the app needs a specific DLL, the filter driver intercepts that call, copies the needed DLL down from the Tarpon share to the client and then makes that DLL available to the executable within the isolation environment. This process is repeated for every file that’s part of the application package.
What ultimately ends up happening is that the entire application gets cached on the client device within the isolation environment. The idea is that a laptop user could use their laptop without a network connection and the application could be executed from the cache—the user wouldn’t even know it wasn’t a “normally” installed application (except for the fact that it wouldn’t show up in the Add/Remove Programs list).
Other random tidbits about how Project Tarpon works:
- If you need to update a particular file or apply a hotfix to a Tarpon application, you can simply update an existing package. This update will increment an internal version counter in the package, and the new file(s) will be copied to the user’s client the next time they launch the application while connected to the network.
- The prototype that we saw at iForum only supported SMB (via UNC shares) as the method of copying packages from the server to the client. Hopefully Citrix will add HTTP/S support, although they may force you to buy an Access Gateway to do this.
- The transfer of package files from the UNC source to the client device is not compressed at this time, even though the files actually live on the server as part of a compressed CAB file.
- Even when executing out of the cache, the individual files that make up an application are checked against their source and replaced if they’ve been deleted or tampered with.
- Project Tarpon applications definitely start up and initially run more slowly than applications that are actually installed locally the old-fashioned way. How much of an impact this will be depends on (a) the size of the application, and (b) the network speed between the UNC share and the client workstation.
- Applications running within Isolation Environments can communicate with applications are that locally installed on a client device outside of the isolation environment. However, this is one-way and the reverse is not true. For example, Microsoft Word running in an AIE will be able to use the File | Send As Email function to open a new mail message in Outlook locally installed on a client device. However, Word installed locally on a client device would not be able to create a new message within Outlook running in a local AIE.
Why didn’t Citrix just buy Softricity?
Since this sounds a lot like what Softricity does, why didn’t Citrix just buy Softricity? Citrix did try to buy Softricity a few years ago, but a deal could never be completed. No one is really talking about what exactly happened (because these discussions never “really” happened <wink>), but the general consensus is that Citrix wanted to buy the Softricity sequencing and streaming environment right as Softricity was entering the desktop market, and the two companies couldn’t really agree on which components would be bought and for how much.
So instead, Citrix just decided to write their own Application Isolation Environment product for their servers (which was released last April in PS4). Citrix didn’t initially plan on taking this product to the desktop, although one developer tried to see if he could get AIE to work on Windows XP so he could isolate his crazy IE plug-ins, and in doing so a new product was born.
What does this mean for Softricity?
When I first heard the keynote speech that included a description of Project Tarpon, I thought Softricity was dead. However, now that I know more about how Tarpon works I think that Softricity doesn’t have anything to worry about. There are several reasons for this:
First of all (I want to be 100% clear on this), Citrix’s Application Isolation Environments (both in PS4 and Project Tarpon) are NOT application virtualization. Softricity has application virtualization capabilities. Citrix’s AIE are simply file system and registry redirection.
Second, Citrix’s “Application Streaming” is NOT “real” application streaming. Softricity offers streaming capabilities where individual function calls from individual files are cut apart and sent down to the client on an as-needed basis. Citrix’s Project Tarpon, on the other hand, simply copies complete files down to the client one-by-one as they are needed. So yeah, I can see how some could say this is “streamed,” but I think the de facto conventions of the word in this industry suggest that this is not an appropriate description for what Citrix is doing.
Third, Softricity is now on Version 3 of their product, and this Tarpon stuff will be Version 1, so Citrix definitely has some catching up to do.
What does Project Tarpon mean for Citrix?
In many ways, Citrix doesn’t necessarily have to compete directly with Softricity with Project Tarpon. Citrix is focusing on managing all applications—client/server, web, and desktop. If Citrix can integrate their application streaming with Presentation Server in a really cool way then they won’t have to worry about outside competition like Softricity.
For example, Citrix could make it so that you could publish two versions of an application—a traditional ICA-based Presentation Server version, and a desktop streaming Project Tarpon version. A user would be only be presented with a single icon for the application. When the user double-clicked the icon, the system would make a runtime determination as to whether that user should get the ICA version or the locally streamed version of the application. This could even be based on Citrix’s Smart Access technology that’s tied into their Access Gateways. Is the user connecting from a corporate laptop? Stream the app locally. Are they connecting from a personal computer at home? Give them access to the app via ICA.
How will Microsoft fit into all of this?
The dark horse in this whole application streaming race is Microsoft. Even though Citrix never mentioned Microsoft (or Softricity for that matter), it’s no surprise that Microsoft is looking at streaming technology and that this capability will play some role in some future version of Windows. Of course this will be a while from now, but it’s still worth thinking about. (Future Article: “Is Microsoft Windows Server 2010 a Citrix Streaming Killer?”) But of course that’s the dance that Citrix and Microsoft dance, and I don’t see it changing anytime soon.