# Friday, 06 June 2008

I've just got back from Software Architect 2008. Its a great conference to speak at and an interesting change from speaking at hard core developer conferences like DevWeek. Thanks to everyone who attended my sessions - the slides and demos are below

SOA with WCF and WF - SOA.zip (368.43 KB)

Volta - Volta.zip (506.21 KB)

The slides and demos from the pre conference workshop on .NET 3.5 for architects that Dave Wheeler and me presented will be posted early next week. We have realised we really need a guide to what all the projects are and how they relate - so we'll add this documentation and post them

.NET | Volta | WCF | WF
Friday, 06 June 2008 08:39:14 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Tuesday, 12 February 2008

Recently I wrote an article on Volta for the DevelopMentor newsletter DevelopMents. I concentrated on the core of what Volta is doing, IL rewriting, rather than highlight the IL to JavaScript functionality that has caught most attention. You can read the article here.

.NET | Volta
Tuesday, 12 February 2008 21:09:49 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Thursday, 13 December 2007

I've just been reading the latest team blog entry from the Volta team. This entry is meant to address the issue that I discussed here about the dangers of taking arbitrary objects and remoting them.

They say that they are abstracting away "unnecessary details" only leaving the necessary ones. Firstly, every abstraction leaks (just look at WCF for an example of that) so no matter how hard you try to abstract away the plumbing it will come through the abstraction in unexpected ways. Secondly the remote boundary is not an unnecessary detail. Its a fundemental part of the design of an application.

Unless Volta has heuristics inside it to generate a remote facade during execution, the interface into a remote object is of huge importance to how an application will perform and scale. Volta should at least give you a warning if you apply the [RunAtOrigin] attribute to a class with properties on it.

Does this mean that the whole idea is broken? Not at all - it just means that applications have to be designed with Volta in mind. Decisions have to be made in the design about which layers *may* get remoted and the interface into that layer should be designed accordingly. Then the exact decision about which layers to *actually* remote can be deferred and tuned according to profiling the application.

.NET | Volta
Thursday, 13 December 2007 10:15:49 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Tuesday, 11 December 2007

On 5th December, Microsoft Live Labs announced Volta. The idea of Volta is to be able to write your application in a .NET language of your choice and then the Volta infrastructure takes care of targetting the right platform (JavaScript or SilverLight, IE or FireFox). This side of things is pretty neat. The other thing it allows you to do is to write your application monolithically and then decide on distribution later on based on profiling, etc. This sounds quite neat but I have some reservations.

I went through the DCOM wave or "COM with a longer wire" as it was labelled at the time and learned some hard lessons. I then went through the .NET Remoting experience and learned  ... well ... the same hard lessons. The reality is unless you design something to be remote then when you remote it its going to suck.

Lets look at a Volta example. First some basics:

  1. Download and install the CTP
  2. Create a Volta application project

Now lets build our Volta application. You create the HTML page for the UI (heres the important snippet)

<body>
 
<p>Press the button to do chatty stuff</p>
 
<
p><button id="chat">Chat!</button></p>
 
<
div id="output" />
</
body>

You create the Volta code to wire up your code to the HTML

public partial class VoltaPage1 : Page
{
 
Button chat;
 
Div output;

 
public VoltaPage1()
 
{
   
InitializeComponent();
 
}

 
partial void InitializeComponent()
 
{
   
chat = Document.GetById<Button>("chat");
   
output = Document.GetById<Div>("output");
  }
}

Now create a class that has a chatty interface

class HoldStatement
{
 
public string The { get { return "The "; } }
 
public string Quick { get { return "Quick "; } }
 
public string Brown { get { return "Brown "; } }
 
public string Fox { get { return "Fox "; } }
 
public string Jumped { get { return "Jumped "; } }
 
public string Over { get { return "Over "; } }
 
public string Lazy { get { return "Lazy "; } }
 
public string Dog { get { return "Dog!"; } }
}

OK now lets wire up the event handler on the button to output a statement in the output div

partial void InitializeComponent()
{
 
chat = Document.GetById<Button>("chat");
 
output = Document.GetById<Div>("output");

 
HoldStatement hs = new HoldStatement();
 
chat.Click += delegate
 
{
   
output.InnerText = hs.The + hs.Quick + hs.Brown + hs.Fox + hs.Jumped +
                       hs.Over + hs.The + hs.Lazy + hs.Dog;
 
};
}

If we compile this in Release mode and press F5 we get a browser and a server appears in the system tray.

If you double click on this server icon you get a monitor window that allows you to trace interaction with the server. Bring that up and check the Log Requests checkbox.

Now click on the Chat! button in the browser. Notice you get a bunch of assembly loads in the log window. Clear the log and press the Chat! button again. Now you see there are no requests going across the wire as the entire application is running in the browser.

Now go to the project properties and select the Volta tab. Enable the <queue dramatic music> Tiersplitter. Go to the HoldStatement class, right click on it and select Refactor -> Tier Split to Run at Origin. Notice we now get a [RunAtOrigin] attribute on the class.

Rebuild and press F5 again. Bring up the Log window again and select to log messages. Now every time you press the Chat! button it makes a request to the server. We have distributed our application with just one attribute! - how cool is that?! But hold on ... how many requests are going to the server? Well one for each property access.

Latency is the death knell of many distributed applications. You have to design remote services to be chunky (lots of data in one round trip) otherwise the network roundtripping will kill your application performance. So saying you can defer architecting your solution in terms of distribution then simply annotate classes with an attribute is a dangerous route to go down. We have already learned the hard way that taking a component and just putting it on the other end of a wire does not make for a good distributed application - Volta appears to be pushing us in that direction again.

.NET | Volta
Tuesday, 11 December 2007 16:01:02 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   |