Volta Specific Recipes

This section covers developer recipes. These represent some of the most common activities when we build Volta applications.

Tier Splitting

Objective

We have an application that runs in a monolithic environment, say the browser. We want parts of this application to run in other environments, such as servers. We don’t want to litter the application with plumbing code.

Rationale

The standard techniques for distributed applications infuse our code everywhere with information about what parts run where. This makes the code hard to change. Typically, once we make these decisions we can’t change them because it is too expensive. However, environments, requirements, and performance profiles change and we’re stuck with applications that can’t adapt to new realities. We need to separate the concerns about what the application does from the concerns about where parts of the application run.

Without Volta, we are forced to decide where code runs before we know everything it is going to do, in particular before we know the communication frequencies and delays. Development methodologies force us to make irreversible decisions too early in the application lifecycle. Volta gives us the means to delay decisions until we have adequate information to base them on.

Recipe

Volta tier splitting automates the creation of the communication plumbing code, serialization, and remoting. Simply mark classes or methods with a custom attribute that tells the Volta compiler where they should run. Unmarked classes and methods continue to run on the client.

We may base our decisions about tier assignment on any criteria we like, such as performance or location of critical assets and capabilities. Because Volta automates boilerplate code and processes for dispersing code, it is easy for us to experiment with and change assignments of classes and methods to tiers.

The following code fragment illustrates the use of the RunAtOrigin custom attribute to run the WeatherSvcProxy class on the server. This partitioning allows us to deal with the single origin policy that the browser-resident code is subject to.

namespace VEMashup.Weather

{

[RunAtOrigin]

public class WeatherSvcProxy

{

public string GetJsonWeatherInfoFor(double lat, double lng)

{

var baseUri = @"http://ws.geonames.org/weatherIcaoJSON";

var uri = baseUri + "?lat=" + lat.ToString() + "&lng=" + lng.ToString();

var xhr = new Microsoft.LiveLabs.Volta.Xml.XMLHttpRequest();

xhr.Open("GET", uri);

xhr.Send();

if (xhr.Status == 200)

return xhr.ResponseText;

else

return null;

}

Volta makes it possible to postpone these significant design decisions about the application’s structure until the last possible responsible moment.

Working with Resources

Objective

How do we bundle content other than code and HTML with Volta applications? For instance, our samples show how to include CSS style sheets and images. We can use the same mechanism to embed other formats, such as audio, video, XML, animations, and so on.

Rationale

Web developers demand that the web-client platform be as rich as the traditional desktop platform. If the desktop can do it, the browser had better be able to do it! Before Silverlight and Volta, CLR programs only ran on the desktop or the server. With Silverlight and Volta CLR programs can also run in the browser.

Recipe

In your source files mention the resources that you want bundled by name, as in the following:

[assembly: StartPage("Page.html")]

[assembly: VoltaFile("main.css")]

[assembly: VoltaFile("adv.css")]

Next, include those files in your VS project.

Finally use the Properties pane to set the Build Action to Embedded Resource. Note: Volta sets the Build Action property automatically for Page.html.

These attributes instruct the Volta compiler to package the embedded resources in the DLL. At deployment time these resources are automatically unfolded so that they are available to the web server.

Our code—in this case Page.html—refers to the embedded CSS files main.css and adv.css as they were in the same directory as Page.html. We would treat them in exactly the same way from C# code. Page.html is similar to the Main method: Volta inserts Volta-generated code at the appropriate places in Page.html.

Exception Handling

Objective

We’d like to use exceptions in Volta applications.

Rationale

.NET languages allow us to use exceptions in our programs. In addition, .NET libraries also use exceptions. We want to employ .NET exception handling in our programs.

Recipe

Volta preserves the semantics of the .NET code, handling exceptions just like the host language (e.g., C#). We can throw exceptions as well as handle them. We use the familiar .NET idioms and patterns when working with .NET libraries that throw managed exceptions. In addition, we use the same techniques when integrating with JavaScript code that throws JavaScript exceptions as Volta translates them into managed exceptions.

The following code sample shows how we handle exceptions in Volta code. This code obtains a couple of values from the DOM and invokes the Find method on the map object. The method throws a JavaScript exception, which we catch like any other managed exception.

void findButton_Click()

{

string what = Document.GetById<Input>("what").Value;

string where = Document.GetById<Input>("where").Value;

try

{

map.Find(what, where);

}

catch (System.Exception ex)

{

Window.Alert(ex.Message);

}

Detail Highlights

When crossing language boundaries (such as when running in Release mode) the exception’s call trace is unavailable.
In Debug mode Volta maps JavaScript exceptions into EvalError, RangeError, ReferenceError, SyntaxError, TypeError and UriError.

Deploying Volta Applications

Objective

Once we complete a Volta application, how do we deploy it?

Rationale

A Volta application comprises a client-side HTML and JavaScript code, and potentially one or more server-side services. We can’t use this application unless its client-side components are accessible to the browser and its services deployed on a server.

The Recipe

On the server side Volta applications require version 3.5 of the Microsoft .NET framework, Internet Information Services (IIS) version 6 or 7, and ASP.NET.

We deploy Volta applications from Visual Studio. Select the Publish action from Visual Studio’s context menu, and then point to the application server directly. Alternatively we can publish to a staging area and then xcopy to the application server. Regardless of whether we publish to the root of the server or an IIS application, the ASP.NET version should be configured to 2.0.50727 (rather than 1.1.4322 which is the default).

Consequences

Once deployed, the web server will deliver the client-side files to the browser on request, as well as execute the server-side files.