Microsoft ties high-level code to Web development with Volta

The long effort to make it technically feasible for already skilled developers to produce Web applications using high-level languages like C++, may at last be paying off.

It's no secret that Microsoft has been looking for ways to tie higher-level application programming to Web-based deployment, so that more traditional developers using the principal .NET Framework languages -- including C++, C#, and Visual Basic -- can make multi-tier applications that run in clients' browsers, without having to learn a different language like JavaScript or Python. It's the clearest indication of any still remaining that Bill Gates is still in charge of Microsoft.

On Wednesday, the company unveiled its next step in that effort: a Web development toolkit called Volta whose objective is to deploy applications written using conventional single-tier, monolithic architecture in multi-tier environments, simply by tying in a few libraries and throwing a couple of switches.

"When Visual Basic 1.0 first came out, Windows programs were hard," admitted Volta group product manager Alex Daley in an interview with BetaNews. "Now the same is true for Web development. You have to know about XML, CSS...We're trying to take away all that complexity, in order to make sure that normal developers can write Web applications."

The basic idea behind Volta is that an application is incubated in a client-only environment. You compile and test it on a stand-alone system to make sure it functions properly. For a Web application, the difference may primarily be simply uncoupling the front end controls from the back end logic, then distributing the front end over the network. The code for that runs on the client, while the back end continues to run on what's now the server, just as it did before.

Plotting the fork in the road

There isn't a basic determining factor yet -- a "white dotted line," if you will -- for what parts stay on the server and what gets distributed to the client. Microsoft may be hoping that this little part of the picture gets addressed along the way.

Microsoft offers a complete description of the basic concept of the Volta development process in VS 2008, which involves creating a stand-alone application first, splitting it into tiers later, and then testing the profile to make certain the client tier is deployable. You do begin your project by declaring it a "Volta application" -- you don't just convert stand-alone C++ or C# programs you've already developed.

In typical Microsoft fashion, the process would have you build the user interface first (step 2), then build the business logic behind it (step 3) before wiring them together (step 4). In practice, many programmers prefer to build the back end logic first prior to the front end, and there's probably no reason why steps 2 and 3 can't be swapped for one another for Volta.

The "wiring them together" part involves invoking the Document Object Model, and it's here where Microsoft assumes you're writing a modern .NET application rather than something that invokes the old MFC class library. Obviously, "traditional" applications in that sense aren't compatible with Volta; and it's because Microsoft has shifted its focus to DOM-oriented front ends that splitting that part into a distributed client tier, run through the client's browser, becomes feasible.

Only after the stand-alone application is fully functional do you begin the process of refactoring for multiple tiers, to use Volta's term for it. With Volta available as a VS 2008 plug-in, you have the choice of which modules run at the origin (what will become the server once the app is deployed), literally from a dialog box. Making that choice plugs custom properties into your code for you.

At that point, Volta's principal architect Erik Meijer told BetaNews, you use Volta's and VS 2008's profiling tools to detect where the dividing line between server and client belongs.

"When you have one code base that covers client/server and all the plumbing in-between," Meijer said, "you can see how it performs and decide which tier to run your code in." That performance data comes from the default trace viewer in VS 2008.

After you make that split, this is where a tricky part begins: You do make some changes to your code, specifically for asynchronous invocation. Your application was running like clockwork on your stand-alone system before, but now clockwork is the very thing that'll work against you, because the front end will eventually be remote -- it's on another system, and independent of the framework set up for your back end logic. So you have to adapt your code for splitting off that thread; it's not too much difficulty, but it's the only part of Volta programming that currently resembles surgery.

In a blog post by ZDNet's Mary Jo Foley on Friday, Meijer demonstrated -- in a rather roundabout way -- one of what he considers Volta's principal benefits, especially when compared to the Google Web Toolkit: Besides the distinction that GWT is a "beta" while Volta is an "experiment," as Meijer put it, Volta is not bound to one language. It leverages the power of .NET's intermediate language compiler MSIL, while "GWT takes source code written in Java only and directly compiles it into JavaScript," he explained.

Finding the proper pidgeonhole for Volta's marketing push

Microsoft is marketing Volta similarly to the way Adobe is marketing its AIR toolkit, with the message that now you can use familiar tools you already know to deploy high-grade network applications. And that's a sign that Adobe's message may be catching on. But Microsoft's underlying methodology is almost completely different, not using JavaScript or AJAX or Flash or Flex -- not subscribing to Adobe's premise that you "already know" those tools. Instead, it uses libraries that are plugged into Visual Studio 2008.

But because the marketing is so similar, Web developers are begging the question: Will Volta be tied in with Silverlight, Microsoft's networkable graphics platform? Strangely, you get two different answers to that question depending on whom you ask. While Microsoft's Alex Daley advised us that Volta and Silverlight were two separate tracks, essentially two separate developer groups, careful readers of Volta's own documentation have already noticed where it mentions Volta can be used in conjunction with Silverlight, presumably on the client side.

Since Silverlight can be used to develop a stand-alone application with a rich, graphical front end just about as easily as a distributed application, it would seem Silverlight is perfectly compatible with the development model Meijer has outlined.

The marketing division of Microsoft is still looking for a flashier, more attention-grabbing "wrapper" for Volta, besides Meijer's message of being able to use the tools already available to you -- "what's already in the room," to use his phrase -- to make distributed applications. It's already tried to adapt the "cloud computing" concept to the project, so far without much luck; there's nothing the least bit "cloudy" about Meijer's multi-tier application model.

And while Daley explains Volta as "extending .NET to fulfill the promise of the software-plus-services application," Meijer makes the technically more accurate point that Volta doesn't extend .NET at all. In fact, it actually puts .NET to use in the way it was originally intended, making .NET into an unquestionable contender against Java in a way that developers can no longer ignore.