I'll take Wes words that he did think about distributed systems when he modeled Volta - but if you read EriK Meijer Volta paper (http://research.microsoft.com/~emeijer/Papers/DemocratizingTheCloudOOPSLA2007.pdf) as well as the Volta documentation on the site - you do not find the spirit in Wes comment at all... what you do get is a message that you can slap [run at] attributes and "refactor" your application easily - which is exactly what you mentioned in your comment - which is exactly the wrong assumption that would get you in trouble if you try to develop a distributed system this way

The problem is that Volta gives the illusion to intelligent, but not experienced in distributed systems, developers that it is THAT easy - and it is really not. When you move the tier around you also need to change the messages that are passed, you need to take into account the differences in latency, throughput , security etc. Not just in the boilerplate code, but also in the way the interactions are modeled.

Arnon

Hi Jesse,
I wrote this article, and while I agree that that article is a little bit of hand waiving (which is why I wrote another piece to explain it better: http://www.rgoarchitects.com/nblog/2007/12/11/WhyArbitraryTiersplittingIsBad.aspx )
The point of the article was not that volta is remote objects but rather that just like remote objects it tries to abstract away the network and make it seem as if you can just move the boundary between local and remote code around
The problem is exactly with the thinking that you can just add/move/remove [runat] attributes and everything would be fine. Components that are not designed to run remotely will hardy be moveable.
If Volta's premise was that you can take you distributed app and test it locally - something you can use Volta (or rather future versions of it since the first one is limited) now that would be something viable.

Arnon