I love it when an article contains lots of complex ideas, some of which I've never heard of before, and presents it in a very clear and clean manner. A definitive victory of communication over jargon.

I do not agree at all with the first commentor; I thought this post was very poorly thought out, and that the author is too quick to bash Volta as the 2nd coming of distributed objects (it isn't). The author reprints an overview from the Volta page and intentionally highlights the passage which reads "Volta handles the complexities of tier-splitting for you" so that he can respond with, "The idea sounds very compelling - I kid you not." He then immediately contradicts himself by writing "Volta tries to do too much [...] What's more disturbing to me, is the automatic handling of the 'complexities of tier-splitting'." So he thinks the concept of a framework that automatically handles the complexities of tier-splitting "sounds very compelling", as long as it doesn't try "to do too much"...like automatically handling the complexities of tier splitting. WTF?

The rest of his post is equally bad:

"Wow, Agile development at its best, allowing us to postpone architectural decisions, that just sound too good to be true. Well, the problem is that it is too good to be true. Abstracting the network out, and providing location transparency without thinking about the implications of distribution is the reason 'distributed objects' failed."

First, Volta seeks to depart from the known failings of past distributed computing models. The author seems intent on ignoring this, which in my opinion is just a strawman so he can trot out some quotes from Harry Pierson and Martin Fowler about how awful distributed objects are. He is either misunderstanding or contradicting the stated purpose of Volta: to give you the ability modify the location your code runs simply and quickly, without redesigning the whole thing. You don't have to design explicitly distributed objects, and you don't have to redesigning the application just to test distribution changes. Unlike the traditional distributed objects the author seems to dislike, if someone makes bad decisions related to compute distribution on a Volta project, you have an opportunity to fix them by adding/moving/removing the [RunAt*] attributes, instead of automatically facing a redesign. THAT is compelling, indeed.

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

I came back to add another thought to my comment, when I saw your reply. I didn't mean to imply that you just add attributes and everything is fine, but instead that THAT is the part that volta is making easier--the plumbing. I took the time to read your other post about arbitrary tier splitting, and I read the comment by Wes Dyer at the bottom. Since I can't possibly say it better than someone who is actively working on the product, I'll just quote him here:

"I do want to clear up a few things about Volta that we apparently didn't make clear enough. [We do not believe that you can develop an application as if it will run on a single tier and then just sprinkle a few custom attributes here and there and be done with it.] More than anything else, programmers need brains. Volta does not claim that programmer brains can be checked at the door. When the programmer wants to divide the application across a particular boundary then things like network latency, new failure modes, concurrency, etc. need to be considered at that boundary. What Volta does is make expressing the transition between boundaries easier. It reduces the accidental complexity of writing all of the boilerplate code to express the programmer's intention. This allows the programmer to focus on the essential complexity of his problem domain -- figuring out how to write effective code for that particular tier boundary.

There are some schools of thought that believe [if something is potentially dangerous then make it hard to do so that the programmer will really have to think about it in order to get it done. Volta is not in this discipline] of thought. It makes it easier so that the programmer can use more mental power to solve the hard parts of distributed programming."

I added some brackets to draw your attention. Clearly, Volta isn't meant to let joe blow developer add attributes to an existing client-side app and call it "distributed". The same network issues you bemoan about distributed architectures still exist with Volta; however, it can possibly make the job of identifying these issues easier due to the dramatically simplified plumbing and other services they're adding in the future. That's promising vs. the doom-and-gloom I read in the post we're all commenting about. If I'm still not getting it, please let me know!

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

I get that you're worried that maybe they're overselling the dream of "distributed done easy", but I don't think anyone is going to sell a framework concept with 10 pages of disclaimers, esp. since it would be the standard "warning: software development is hard" kind of fare. After all, "not experienced in distributed systems" describes >99.99% of people writing code today, and making them play with (or more accurately: spend weeks-months architecting) plumbing doesn't help if their business logic is crap, IMHO.

After having written a small CORBA client for a distributed system at my previous job, I'm experienced enough to know when plumbing gets in the way of getting even a basic implementation off the ground. At my experience level, I'm excited about any framework that makes the plumbing easier--the faster I can fire up my half-baked systems, the more time my peers and I have to throw rocks at it and get it to scale.

And being that this is pretty much alpha code, I'm willing to cut Eric and Wes a lot of slack for not being on exactly the same page. Volta is so young the final version could end up being a Facebook client, for all we know.