JackBe became known for distributing a full, browser-based IDE for JavaScript applications before the AJAX buzzword was coined. Their engineers understood AJAX before most of us. Now, their system has grown dramatically to mesh with a new server-side data mechanism for mashing together HTML, RSS feeds, WSDL calls, and SQL calls into one data feed for clients. This big, bold brand, known as Presto, has eaten the old JavaScript development plug-ins for Eclipse, now known as Presto Studio.

Nexaweb, on the other hand, began as a Java-based framework for building client-server applications that connected a set of XML-defined widgets to a set of data sources through a J2EE server. It offered the kind of client-server framework that Presto now offers -- but it sent this information to a Java-based tool on the client. Now, the company has built an AJAX version for deploying the client, giving developers another pathway for your application.

Both show how far the world of AJAX -based clients have come while illustrating just how lost they can be without adequate server support. JavaScript is a good language for building robust user interfaces. But the Web is a dangerous place, and these applications need a good back end. Both JackBe Presto and Nexaweb Enterprise Web 2.0 Suite give this support.

The Presto approach
The Presto back end is a robust octopus of an application designed to live on the server, collect data from all possible sources, and repackage it for the JavaScript client. It is the kind of application that a JavaScript developer starts dreaming of writing after discovering that XMLHttpRequest can call only the original domain that delivered the JavaScript. This cross-domain scripting limitation means that the server must do all of the proxying for the client.

The Presto developers point out that there are a number of advantages to this approach, and they've built many of them into their code. This server, called the Presto Edge, can cache the data, translate the information into a common format, and even mash it up with some basic transformations. It also can straddle the security line and act as a firewall between the JavaScript clients in the wild and the pampered servers inside.

Presto Edge can suck data from WSDL, REST (Representational State Transfer), Atom, RSS, SQL, KML (Keyhole Markup Language), WMS (Web Map Service), and POJO (plain old Java objects) calls before translating this data into JSON (JavaScript Object Notation) or XML for the clients. The information can be mixed together by creating views that, in turn, can be joined together, sorted, filtered, or annotated. This federated approach also contains all of the logic for dealing with the security of distant data sources such as an LDAP directory. It offers an additional layer that lets you give users access to certain mashups of data without giving them complete access to the data source. Given that many of the most egregious security holes come from giving the browser too much power to craft pure SQL, this is a good design practice.

I tested the mechanism by building a few mashups that pulled data from RSS feeds and a database. The tool is a pretty nice Swiss Army Knife for mixing together different data sources. The JackBe folks argue that putting so much security control into the server is a logical approach for cautious developers. Presto Edge can poll servers behind the firewall and clean up the data before sending it out to the client. Without it running interference, the only solution would be bolstering the security of each and every service you wanted to expose to the outside world.

Nexaweb's way
The Nexaweb application began as a pure Java-based tool, but now it's expanded to offer a JavaScript version for the client. The applications are still built in a collection of Eclipse plug-ins, but now you can choose whether you want the XML that describes the locations of the widgets to be interpreted by a JVM or by a browser. The XML itself remains the same, making it possible to switch freely between the two options.

The freedom starts to fade as you add enough of your own logic for gluing together the widgets, validating the inputs, or doing any other housekeeping. The JVM wants to speak Java and the AJAX layer wants JavaScript. There's no automatic way to push a button and make your application move from the Java client to the browser or back again, but the APIs are very similar. If you're writing code, the design patterns and structures are pretty equivalent. It makes me wonder if Nexaweb could incorporate a Java-to-JavaScript translator like the one used in Google Web Toolkit.

There are subtler differences that can be important. The Java version can offer a pure push option to the server because the Java code on the client can open a continuous connection. The AJAX code can only poll the server every so often. This may be an important distinction in some applications demanding heavy connectivity, such as apps for trading desks and other fast-paced realms. JackBe's JavaScript, by the way, can come close to approximating this by tricking the HTTP connection by sending down a bit of data every so often. It's not the same thing, but it can be just as effective.

A Java client is also useful in other ways. The Java APIs are rich with code for doing simple things such as loading local files and arcane things such as parsing image files. The Nexaweb Java client leaves these options open to you -- if you have client computers that are happy to open themselves up to the software. You can just link them into your code.

I tested the Nexaweb toolkit (Nexaweb Platform 4.5 and Nexaweb Studio 3.5) by building another tool that would mash up RSS feeds and display them in a browser. Nexaweb's back end offers many of the same features as Presto in different packaging. You can grab information from Web services, Web sites, and databases and then send them back over the "Internet Messaging Bus" to the client. The server can poll most of the same basic sources as Presto, but it can't manipulate the information as readily. Nexaweb's server doesn't have the same support for quick manipulation. You could certainly whip up most of this on your own, but it isn't as simple.

Drag and drop, you say
One of my pet peeves is that the marketing forces for both of these packages tend to suggest that building an application with Nexaweb or Presto Studio can be done without requiring any code to be written. Ha. Just because both applications include neat drag-and-drop tools that construct XML to describe the widget layout doesn't mean that you don't need to think abstractly and try to guess what the API wants to do. In both cases, I admit I was charmed by the quick ways to drag an RSS data source onto a table to produce a nice feed reader; I was also driven to tears by nasty little glitches that were the visual equivalents of sign errors. These are sophisticated systems that make life far easier, but you still have to think like a programmer.

The biggest competitor for both of these applications may be services like Yahoo Pipes, Google Gadgets, Metaplace, and any of the other mashup tools for the worlds of Facebook or Salesforce.com. These tools can similarly pull data from a number of sources, mix it up, and then deliver it to Web pages. They're simple and often free, or close to free.

Most IT professionals may be scared of such freedom, and with good reason. If the Nexaweb or Presto server does the mashing, it can decide on the rules for sharing information with the world. Control remains behind the firewall, not with some distant server farm owned by someone else. The downside of this tightfisted approach is that your customers will never surprise you with cool new applications or mashups, something that can be exciting until the so-called customers discover a way to embarrass or rob you. The obvious solution is to open up as many databases as practical but use tools such as JackBe Presto or Nexaweb to do the heavy lifting for more proprietary things.

The biggest customers for these products will be IT professionals with a deadline and a need to integrate a number of internal data sources. If the boss says that the customers need a single place to pull data and reports that tap disparate systems from different parts of the organization, then these are both good tools for creating a rich and usable application that hides some of the confusion going on in the background. They are even more valuable if the hidden sources can't be changed because the developer is long gone, too busy, or uncooperative. Scraping information from the other sources and integrating it all into one front end is quite useful. Both Nexaweb and JackBe Presto are ideal tools for the folks responsible for moving an enterprise's Web presence into Web 2.0 and beyond.

As I've written before, RIAs comprise a spectrum of application types and technologies. Silverlight is Microsoft's entry in the middle of the "weight" spectrum. It joins the Microsoft AJAX Library, which falls at the lightweight end, and Microsoft .Net Smart Client applications, which occupy the heavyweight end. Microsoft Silverlight 1.0 incorporates a subset of the .Net Framework and supports JavaScript. Microsoft Silverlight 1.1, currently in alpha tests, incorporates a larger subset of the .Net Framework and supports JIT-compiled C#, Visual Basic .Net, IronPython, and (eventually) IronRuby as well.

Unlike many of Microsoft's other offerings, Silverlight was designed from the ground up to be a cross-platform, cross-browser plug-in. It currently supports Windows and Mac OS using the Internet Explorer, Firefox, and Safari browsers. In the future, it will also support Linux and the Opera browser.

As you might expect from Microsoft, Silverlight is supported by excellent development tools. You don't absolutely need those tools: Silverlight 1.0 is largely straightforward enough that you could develop applications using free HTML and JavaScript editors if you wished, supplemented by a free XAML (Extensible Application Markup Language) editor, such as XAMLPad from the Windows SDK or Charles Petzold's XAML Cruncher. On the other hand, the time savings from using Visual Studio for development and Expression Studio for graphics design and video preparation should more than offset their cost.

The Silverlight 1.0 SDK can install a Silverlight JavaScript Application project template into Visual Studio 2005. For the best development experience, Microsoft recommends using Visual Studio 2008, which includes Silverlight 1.1 C# and VB project templates and is currently in beta test, and a preview version of Expression Blend 2. Setting up the Silverlight 1.0 JavaScript Application project template in Visual Studio 2008 takes some effort, which I discuss in this blog entry.

Silverlight is a browser plug-in and, as such, needs to be launched from an HTML page via JavaScript. The Silverlight runtime can parse and render XAML to the browser, animate XAML elements, and respond to user input and other events. It can also download and display media, and handle "ink" input from a pen, a touchscreen, or a mouse.

The Silverlight 1.0 plug-in provides mechanisms for setting and changing the XAML content to be executed by the runtime; for retrieving objects from the runtime; for manipulation of objects through JavaScript; and for downloading image, text, glyph, audio, and video content incrementally.

I found Silverlight development easy to learn, but I had a head start: I was already familiar with XAML, JavaScript, HTML, and Visual Studio. Expression Blend was new to me, but was similar enough to other graphical design tools that I didn't have to climb much of a learning curve. That said, I'm no graphical designer: I appreciate the division of labor between programmers and designers that is facilitated by having XAML and code-behind files.

The online Silverlight QuickStarts should give most developers enough of a feel for the product to get started with simple projects. Additional reference information on MSDN and in the SDKs helps a bit, but a number of Microsoft Technical Evangelists and bloggers have created videos to make the process even clearer. Some of the videos go further afield, covering useful topics you never expected to hear about from Microsoft, such as integrating Silverlight with PHP and Java, and using SVG (Scalable Vector Graphics) assets in Expression Design.

Silverlight 1.0 performance is adequate as long as you don't do too much work in JavaScript; it's certainly more than adequate for streaming videos (which is done by the runtime) and simple XAML animations. I found Silverlight 1.0 sites to be about as responsive as AJAX, Flash, and Flex sites, but less responsive than Curl sites.

The use of JavaScript in Silverlight 1.0 helps make Silverlight compatible with multiple browsers and operating systems, but it also limits Silverlight's performance. There are two relevant issues. First, JavaScript is an interpreted language that is inherently much slower than native code. Second, when JavaScript is running, the Silverlight plug-in stops drawing. Silverlight 1.0 can be used for simple user interfaces that don't spend much time processing events, but it's not appropriate for creating highly interactive applications, such as games. For that, consider Silverlight 1.1.

Now that Silverlight 1.0 has been released, the Silverlight team is devoting most of its energy to Silverlight 1.1, now in alpha, which has a number of additional features over 1.0. Foremost among these is support for development in C# and Visual Basic .Net, offering a speed boost over JavaScript of roughly 200X, judging by the Bubblemark animation test. The Silverlight Chess demo, however, reveals the computational speedup is close to a factor of 1,000. I wouldn't be surprised if the final computational speed of Silverlight 1.1 applications was comparable to that of Curl applications, and Curl is fast enough to do ray-tracing.

Silverlight 1.1 supports a larger subset of the .Net Framework than Silverlight 1.0, enabling the development of some fairly serious applications, not to mention some fairly cool games. In Silverlight 1.1 you can do networking and communication, process XML, use isolated local storage, upload files, and use compiled dynamic languages such as IronPython.

But Silverlight 1.1 is still a work in progress. In the meantime, should you jump for Silverlight 1.0? If I had a site that could benefit from streaming media and simple animations, and was intended for viewing on Windows and Mac computers, I wouldn't hesitate to use Silverlight 1.0, especially if I had a development staff familiar with Visual Studio and XAML. On the other hand, I wouldn't spend the time and money needed to convert an existing Flash or Flex site to Silverlight 1.0. If performance were an issue, I'd revisit the question when Flex 3 and Silverlight 1.1 are released.

If I had a site that displayed embedded videos from YouTube, I'd have to decide if the additional interactive features I could get from Silverlight made up for the additional bandwidth cost. If my videos fit within the free 4GB hosting restriction of Silverlight Streaming by Windows Live, bandwidth wouldn't be an issue, and I'd strongly consider moving my content.

In those tests, Sun brought its massive Sun Blade 8000 system, which is a 12U, 10-slot chassis that runs four-socket blades. The other participants brought their biggest units, but those used two-socket blades. Sun's performance in that test wasn't stellar, due largely to a software issue and not hardware.

Now, however, Sun has introduced a scaled-down version of the Sun Blade 8000, dubbed the Sun Blade 6000. It's a 10-slot, 10RU chassis with two sets of redundant power supplies, and it offers the same expansion options found in the 8000 series. There are two network module slots in the rear of the chassis, slots that can hold two 10-port gigabit modules dubbed Network Express Modules. These are not network interfaces themselves, just media pass-through adapters, so the cost is very low: about $500 (list price).

In addition to these slots, each blade has two Express Module slots at the top of the chassis that can handle a variety of standard PCI-SIG cards, from dual-gigabit Ethernet to Fibre Channel and so forth. Thus, it's possible to dress up any blade with as many as six Gigabit Ethernet ports, four GigE ports and Fibre Channel connectivity, or any mix. It's a very nice feature and adds significantly to the expansion possibilities of the 6000 series.

Blade power
As far as blades go, the Sun Blade 6000 offers the greatest range of any blade chassis, essentially because you can mix and match dual-socket Intel, AMD, and single-socket Sparc-based blades in the same chassis.

The X6250 Intel blades are available in dual- or quad-core versions of the Intel 5000-series CPUs, with up to 64GB of 667MHz PC2-5300 FB-DIMM (fully buffered DIMM) RAM. Inside, there are two x8 PCI Express buses and one x8 PCIe bus to each PCI interface module; two x4 PCI Express buses and one x8 PCIe bus to each Network Express Module; four 3Gb SAS interfaces standard; and eight available using the RAID expansion module. The RAID expansion modules supports SAS drives and offers RAID 0,1,5,10 support.

The X6220 Opteron-based blades share many of the same features as the Intel blades, but they're slightly older and don't offer the RAID expansion option. They can handle dual-core Opteron 2200-series CPUs and have one x8 PCI Express bus per PCI Express Module and Network Express Module. The X6220 blades offer both SAS and SATA SFF (small form factor) drive support, however.

The T6300 blades are Sparc-based and offer a single-socket multicore UltraSparc T1 CPU. It's limited to 32GB of RAM per blade, though it uses all four memory controllers in the processor. Those processors are available in a few configurations: six- or eight-core running at 1.0GHz, an eight-core 1.2GHz version, and finally an eight-core 1.4GHz UltraSparc T1 CPU. It shares the SAS/SATA SFF disk support of the X6220 but lacks RAID.

The Intel and AMD blades also offer an internal CompactFlash slot, which is a nice touch, considering that there are no internal USB headers within the blade itself. This will come in handy for a variety of applications, predominately for the upcoming Flash-based VMware V3i product. Use of the CompactFlash interface in this fashion will preclude the need for hard drives in the blades, which will reduce heat generation and power consumption while essentially removing the problem of disk failure.

In the lab, I had a Sun Blade 6000 chassis with six blades (two each of the X6250, X6220, and T6300 models), two Network Express Modules, and four dual-gigabit Express Modules. This equates to four blades with four gigabit NICs each, and two blades with two gigabit NICs. I worked with a variety of operating systems, from Red Hat Enterprise Linux 4.5, CentOS 5, VMware ESX Server 3.0.1 and 3.0.2, to Solaris 10, Windows Server 2003 Standard and R2. I used 32- and 64-bit versions of each. I didn't run into any problems with driver incompatibilities that couldn't be rectified with a few updated drivers, and most of the newer releases found all the hardware without issue, including VMware ESX 3.0.1 on the Intel and AMD blades.

Embedded management
One of the features I found very useful on the Sun Blade 8000 chassis was the Chassis Management Module's Web interface. In the 8000 series, you can pull up this module in a Web browser and use it as a clearinghouse of sorts, jumping to any one blade, or several, and getting a graphical overview of the entire chassis. This Web interface isn't available on the 6000 series, however, and is strictly command-line. It's unfortunate to lose that capability.

Each blade has an ILO management card embedded in it, however, that drives like any of the Sun Galaxy server management cards, offering a Web interface with out-of-band power controls and console redirection. The console redirection available in the AMD-based blades, dubbed JavaRConsole, is simply stellar, offering a fully graphical console based on a Java applet that works flawlessly. It offers virtual CD and floppy support and accurate mouse tracking.

I've run it on Mac OS X, Linux, and Windows clients. Unfortunately, the Intel-based blades diverged from JavaRConsole to the Java Remote KVM applet. I had problems getting it to work under anything but Windows and a specific version of Java for Linux, with the applet either failing to load or showing nothing but a blank screen.

With the systems that I did get it to run on, the mouse tracking seemed less stable, multiple sessions in a single applet apparently weren't supported, and the overall experience was not as good as that of the older version found on the Opteron blades. It's curious to me why Sun would "fix" something that wasn't broken, but it seems that it has. Perhaps a firmware update in the future will rectify some of these problems.

Solid performance
I I did wind up with a bad X6220 Opteron blade in the initial shipment, but the replacement Sun shipped worked fine. Some of the benchmarks I ran were real-world FPGA simulations, and my rough calculations showed that the Opteron 2220-based blade outclassed an identically configured Opteron 285 system by about 6 percent, which isn’t bad, but also isn’t a huge margin. However, the performance gains shown by the quad-core Intel blades using those tools was significant, at roughly 20 percent across identical test runs. I did note that when running Red Hat Enterprise Linux 4 U5 on the Opteron blades, the kacpid process had a tendency to become a runaway, consistently consuming 40-50 percent of one core and not responding to a kill command. I have yet to find a permanent fix for that problem.

Overall, however, testing across the three blade architectures showed solid performance at every level, and the quad-core Intel blades are obviously perfect for virtualization.

It would be nice to see a refresh of these blades with AMD’s Barcelona, and Intel’s Harpertown-based Stoakley platform, but as far as what’s available today, the price/performance mix delivered by the Sun Blade 6000 is outstanding. My quibbles with the lack of a Web-based CMM and the relatively annoying Intel ILO are minor, and hopefully will be addressed in the near future, but the overall package is very impressive.

This story contains updated information in the “Solid performance” section that did not appear in the earlier version previously posted.

Click for larger view.

In practice, click ‘n’ run is a nightmare to implement. Setting aside the licensing issues (and they are legion), the fact remains that delivering traditional fat client applications over the Internet is a technological hurdle on the scale of enabling pigs to fly. First, you have to package the code in a way that allows it to run without actually installing anything. That’s where virtualization comes in. Then you need to find a way to deliver the bits to the end-user without choking their network connection or leaving them helpless when they no longer have access to the distribution point. Here streaming and caching are the keys.

Previous attempts at Web-based application distribution have focused mostly on kiosk-style computing, using a virtual machine or terminal session running on a back-end server to deliver a “screen-scraped” UI to the remote user. However, with the emergence of application virtualization solutions from Softricity (now part of Microsoft), Altiris (now part of Symantec), and Thinstall, the industry is poised for an explosion of new and potentially revolutionary delivery models.

These three solutions virtualize the interaction between Windows programs and the Windows OS resources they depend on, including the file system and system registry, allowing them to run in isolation from the underlying desktop. (For the differences in how they go about it, see my writeup on application and desktop virtualization in "Virtualization: Under the hood.") Combine the virtualization capabilities with streaming servers, as two of the vendors have done, and click 'n' run, on-demand application deployment is just a step or two away. 

What makes application virtualization so compelling is its immunity to the very issues that torpedoed the kiosk solutions. For starters, virtualized applications are modular. Though streamed by default, virtualized applications can be configured for offline use, either through caching or by simply copying the application image to the client. And though isolated from the local system (because the application’s registry access and private file set are virtualized), they can still interact with local resources, seamlessly accessing the PC’s storage and print devices, for instance.

But despite having the right general plumbing, none of these first-generation solutions is designed specifically with a subscription-based computing model in mind. Microsoft SoftGrid and Thinstall Virtualization Suite are still aimed at internal enterprise deployment, whereas Symantec SVS Pro -- by virtue of its integration with a streaming server component from partner AppStream -- is closer to the goal of a true click ‘n’ run format. All Symantec needs to do is work out the optimization kinks.

It’s worth noting that, although the focus of SoftGrid is still internal, the 800-pound gorilla in Redmond has everything it needs to deliver a future Office suite via the Web. The future of software distribution is subscription-based click ‘n’ run; the question is no longer if, but when. The three platforms reviewed here are helping pioneer the transition.

A simple test of speedy delivery
To better understand the behavior of each application virtualization solution, I constructed a rudimentary test bed featuring Microsoft Office 2003. Using the packaging tools from each solution, I created a virtualized Office image and then used each solution’s distribution mechanism to deploy the image to a Windows XP-based client session.

Click for larger view.

During deployment, I monitored the client session to measure peak network traffic, recording the total bytes sent and received per second in Windows Performance Monitor. I also timed the initial launch of multiple Office applications (Word, Excel, PowerPoint, and Access) in an effort to gauge the efficiency of the three delivery methods.

Note: All testing was conducted under Microsoft Virtual Server 2005 R2 (SP1). In the case of SoftGrid, a Windows Server 2003-based Active Directory environment was created to support the SoftGrid server components. For Symantec SVS Pro, I used a non-Active Directory Windows Server 2003 instance. Thinstall didn’t require any server components; however, I did use the SoftGrid server to host a cached share point containing Thinstall-packaged executables.

Microsoft SoftGrid 4.2
When I first reviewed SoftGrid in July 2006 ("SoftGrid opens a stream toward application manageability") I found a product with tremendous promise saddled with an overly complex sequencing process and myriad runtime limitations. It’s now a year later and virtually nothing has changed. Version 4.2 is still plagued by UI quirks and omissions, the failure to automatically share the Content folder during the server installation process being the most glaring (unforgivable, really). There has been no real improvement in application compatibility; for example, SoftGrid still can’t handle applications that employ headless services (such as systems management agents). In fact, other than support for Windows Vista as a client OS, SoftGrid is effectively unchanged from its previous incarnation.

All of which makes the logic behind Microsoft’s decision to acquire SoftGrid from its original developer, Softricity, all the more apparent. The Redmond giant has a history of obtaining half-baked products for the purpose of gaining access to a particular core technology -- in this case, the SoftGrid virtualization client and streaming engine. Microsoft needs these code nuggets in order to flesh out its grand scheme for a subscription-based computing model (see my blog post, "Microsoft's Virtualization Endgame," for details). And barely 12 months since the acquisition, the gutting has begun.

For example, Microsoft recently announced a new packaging tool for SoftGrid, one that allows customers to redistribute SoftGrid-encoded applications using Microsoft’s Windows Installer service. This makes it easier for customers to decouple the virtualization client layer from the streaming server layer, effectively making the SoftGrid OSD package format a viable stand-alone delivery platform, much as the company’s VHD (Virtual Hard Disk) format functions for virtual servers. It also helps SoftGrid applications play better with existing configuration management environments because the OSD is wrapped within the widely supported Windows Installer (MSI) package format.

MSI compatibility is only the first step. Microsoft will likely do an even more thorough strip job as time goes on, dumping much of the existing management UI, which is awkward at best, in favor of an even more seamless integration with MSCCM (Microsoft System Center Configuration Manager). The company doesn’t think much of SoftGrid as a separate product, as evidenced by its decision to release what was essentially the entire Softricity product catalog as a set of free tools (the Microsoft Desktop Optimization Pack for Software Assurance) for customers in the Microsoft Software Assurance program. Clearly, this is a product acquisition in which the sum of the parts is considered greater than the whole.

I tested SoftGrid 4.2 running under Microsoft Virtual Server 2005 R2 (SP1). As with previous versions, the SoftGrid server components require a Microsoft Active Directory environment in order to function. There are a variety of additional requirements, including Microsoft Internet Information Services and Microsoft Management Console 3.0, the latter of which must be downloaded separately. The SoftGrid installer does a good job of flagging any missing pieces, but does not offer to install them from within the setup wizard -- an un-Microsoft behavior that will likely be fixed when the company further integrates SoftGrid with MSCCM.

During benchmark testing, SoftGrid streamed a virtualized Office 2003 package to the desktop with initial startup times of 13, 10, 9, and 12 seconds for Word, Excel, PowerPoint, and Access respectively, all while consuming from 92Mbps to 110Mbps of network bandwidth. Subsequent streaming operations to support accessing additional functionality outside of the initial startup blocks triggered another 50Mbps to 80Mbps of network traffic. Caching the entire Office suite for offline use took just under two minutes while pushing peak bandwidth utilization to 124Mbps.

Overall, SoftGrid remains a solution with tremendous potential, but is marred by unresolved usability and compatibility issues. No doubt the compatibility issues will become moot as Microsoft narrows the product’s focus to its own delivery needs while the usability problems will be addressed when SoftGrid is eventually vivisected on the System Center chopping block.

Symantec SVS Pro 2.1
Symantec’s SVS (Software Virtualization Solution), acquired when the company purchased Altiris in late 2006, has long provided one of the easiest to use and most flexible application virtualization platforms (see my March 2006 review, "Altiris shakes up Windows configuration management"). Its effortless handling of headless services and other complex application types have made SVS the darling of the IT skunkworks crowd, as evidenced by the popularity of the Juice online developer community. However, in direct comparisons to SoftGrid and even Thinstall, SVS always came up short in the area of application delivery. Complex SVS “layers,” such as our Office 2003 test bed, can be quite large (150MB to 300MB or more, depending on configuration), making them impractical to deliver over large, geographically dispersed enterprises.

To address this deficiency, and to bring SVS more on par with SoftGrid, Symantec has partnered with AppStream to add a streaming delivery mechanism for SVS-packaged applications. However, as is often the case with mixed vendor/OEM solutions, the integration of the participating components is less than perfect, leaving the user to navigate disparate UIs rife with redundancy.

For example, to deploy an SVS package via AppStream you begin within the confines of the SVS administration utility. After you’ve captured an application install you need to export the layer to a VSA file. Next, you copy the VSA file to a system running the AppStream packager where you open the VSA and convert it into an AppStream ZIP package. Once that’s done you need to upload the package to the AppStream server and then provision it for distribution. All told, you’re forced to navigate across four different UIs (SVS admin, AppStream packager, AppStream upload/import utility, AppStream Web console) spanning three different runtime platforms (Windows, Java, Web). By contrast, with SoftGrid you remain within a single UI and platform (Windows), and importing an application requires just a single step (copying the package to the Content folder).

Click for larger view.

This spotty integration also extends to the delivery process. When testing SVS Pro against the aforementioned Office 2003 test bed, I clocked AppStream at no less than 1 minute and 45 seconds from initial user request to the appearance of the virtualized application. During this time AppStream was downloading nearly 50MB of data into the local SVS cache and generating just under 80Mbps of network traffic.

Compare this to the 9 to 13 seconds for SoftGrid or the 2 to 5 seconds for Thinstall, and you can see that, at least during the initial program load to cache, SVS Pro is far from a speed demon. However, on the positive side this large initial blob includes the most common code blocks required for all of the packaged executables. So while it might take longer to launch the requested application for the first time, subsequent launch requests -- either to the first application used or any of the other applications in the SVS package layer (in this case Word, Excel, PowerPoint, and Access) -- are serviced almost instantaneously.

An analysis of subsequent streaming requests (i.e. grabbing additional code to support functions not downloaded in the initial 50MB or more blob) showed a much more granular access pattern. All of which seems to point to an architectural tradeoff when dealing with streaming SVS packages: You need to download more of the package blocks to get the first application started, but these additional blocks help to eliminate the need for subsequent roundtrips to get additional applications loaded. To put this in perspective, you have to add up the initial startup times for Word, Excel, PowerPoint, and Access under SoftGrid (44 seconds) before you’ve achieved the same degree of functionality that the initial SVS Pro download provides.

One area in which the SVS Pro solution outshines both SoftGrid and Thinstall is in its support for Web-based access to packaged applications. The AppStream Web portal makes it easy for users to surf up and access the desired applications in a kiosk-like, on-demand fashion. In this regard, SVS Pro provides a solution that is closer to the subscription-based delivery model that has been the holy grail of commercial developers for nearly a decade.

ThinstallVirtualization Suite 3.2
Every time I review a version of Thinstall I can’t help but remember a joke I heard about something being “a riddle wrapped in an enigma and surrounded by mystery.” Thinstall is the riddle. Or is it the enigma? One thing’s for sure: The platform’s underlying architecture continues to be a mystery to even savvy IT experts. Does it really work without a client agent and without loading anything into kernel mode? What about streaming? What does the company mean by “it delivers the benefits of streaming without the server?”

Click for larger view.

The answers to the first two questions are yes and yes, while the third is a solid “maybe.” It’s true that Thinstall requires no client agent or server-side components; everything a Windows PC needs to create the virtual runtime and enable the application loads dynamically from the packaged executable image. (See my February 2007 review, "Thinstall removes barriers to application virtualization.") Furthermore, the company claims that, since Thinstall controls the application’s loading sequence, by supplanting the usual program header logic with its own virtual environment bootstrap code, it can directly modulate which bits are passed over the wire to service a particular startup request.

For example, in the case of our Office 2003 test bed, Thinstall’s setup capture utility transformed our default installation into a single, large (more than 300MB), compressed file, with multiple shortcut-type redirector files taking the place of the normal Office executables. In practice, launching one of these pseudo-executable shortcuts prompted Thinstall to access the larger code image file and extract only those bits necessary to assemble the virtualized runtime image, a fact evidenced by our test results: When launching Word, Excel, PowerPoint, and Access, Thinstall generated peak network utilization on par with SoftGrid (92Mbps to 106Mbps). It also blew the doors off both SoftGrid and SVS Pro when it came to initial application load times. Whereas the two “streaming” solutions took at least 9 seconds (SoftGrid) and 105 seconds (SVS Pro) to load an application for the first time, Thinstall did it in 2 to 5 seconds, depending on which application was being requested.

Of course, no matter how efficient the download, you don’t want your users hammering on the server every time they decide to load a Word document. The lack of client-side caching of code images has been one of the persistent knocks against Thinstall. And though you can work around the issue externally -- for example, under Windows by enabling caching on the share point -- it’s still something Thinstall’s designers need to address directly.

Another issue they need to address is Thinstall’s reliance on SMB-based (Server Message Block) sharing as its only network distribution mechanism. Both SoftGrid and SVS Pro, though not yet fully optimized for Web-based delivery, are at least closer to that goal in that they provide a non-SMB delivery vehicle (streaming), one that should be more palatable to security-conscious administrators.

Thinstall executives claim to be working on a persistent caching mechanism for Thinstall and say they’ll address the SMB sharing limitation in the near future. In the meantime, the company has begun talking up its new License Manager product which will hopefully address another of the product’s shortcomings: the inability to enable, disable, and monitor access (including license compliance) to Thinstall packaged applications.

Thinstall License Manager will be released as open source, allowing IT shops to customize the PHP-based (PHP: Hypertext Preprocessor) server components to meet their specific requirements. Until then, potential Thinstall customers will need to weigh the advantages (raw speed plus no client agent or streaming servers required) against the disadvantages (reliance on SMB shares and the absence of an integrated caching mechanism) and hope that the company comes through on its promises to flesh out the Thinstall architecture.

Picking a winner

Neither Thinstall nor SVS Pro nor SoftGrid is fully baked. But while all of them have quirks and limitations, only one of them delivers an experience that’s within striking distance of our stated target of a true click ‘n' run solution: Symantec SVS Pro 2.1. Despite the awkward integration of the native virtualization component and the OEM delivery mechanism, Symantec’s choice of AppStream as its streaming partner yields additional dividends, such as the ability to stream both virtualized and non-virtualized applications from the same platform. SVS Pro is the most complete of the three platforms, and an initial one time delay of a minute or so -- which will disappear after the application is cached -- is a minor nit against an otherwise impressive solution.

SoftGrid, by contrast, is a product in transition. The old bits are getting stale, but that’s to be expected for a code base that is in the process of being strip mined. Expect to see pieces of SoftGrid technology popping up all over Microsoft’s product line with the end game of delivering an on-demand platform from which the company can distribute most of its wares. In the meantime, the product that was Softricity’s crown jewel is now available as a freebie for Microsoft’s most loyal customers. These shops will want to take advantage of the opportunity to kick SoftGrid’s tires and to prepare for what will doubtless be a major push by Microsoft to seed its version of application virtualization throughout the enterprise computing landscape.

The odd man out in the trio is Thinstall. Thinstall's integrated Virtual Operating System is still a technical marvel. Where else can you find so much muscle crammed into a 300K file header? However, the company’s lack of progress in building out the management and delivery mechanisms has left Thinstall looking more and more like a one-trick pony. Those lingering deployment issues -- no caching, SMB-only streaming -- need to be addressed immediately, while the more visionary elements of the Thinstall executive team must start painting a bigger picture before enterprise customers lose interest. Perhaps the best case would be if Thinstall were acquired by a larger player (IBM and HP come to mind) who can help them weave their innovative virtualization tool into a cohesive delivery and management framework to counter those of Microsoft and Symantec.

When InfoWorld last reviewed Vontu, Version 5 was at the midpoint of this cycle, offering full network coverage and the capability of discovering sensitive information in file systems, database, and e-mail archives. Vontu 6 included data-at-rest protection for these repositories. Now, with the introduction of Vontu Endpoint Monitor (which checks for sensitive data on removable media, USB devices, iPods, external drives, and data downloads), Vontu 7 is a near-total solution for guarding confidential customer and company information.

Other leak-prevention products block at the end point, such as prohibiting files from being copied to external devices. Version 8 will include this feature, according to Vontu. Otherwise, there's enough solidity in Vontu 7 to make it a prime choice for financial institutions, manufacturers, technology companies, and retailers.

Eye on the data prize
Vontu Enforce is the glue of Vontu 7. This server provides centralized policy management, unified reporting of incidents from the five monitoring and prevention modules, automated policy enforcement, and remediation workflow.

Click for larger view.

Key to preventing data loss is accurately detecting confidential data -- the first half of a policy. (The second half is response rules, which I'll discuss further on.) Vontu 7 ships with more than 60 policies; these certainly provide you with an excellent starting point and best practices for setting up your own policies. However, what makes Vontu Enforce so strong is its three types of underlying detection technology and how they can be customized and combined for near-perfect detection performance.

I started testing Vontu 7 at the Vontu Enforce Web console by fingerprinting a text file with 1 million rows of customer names and associated Social Security numbers -- a process called EDM (Exact Data Matching), the first of the three underlying detection technologies. Additionally, I registered content from several SQL Server databases.