As you can see, the application has a bunch of components that are just begging to be refactored to take part in distributed computing. Without the aid of Volta, this refactoring would then require your developers to bone up on WCF and/or Remoting and .NET-specific implementations of Web Services. You'd have to ask yourselves, "Do we use WSE?". Someone in the group would invariably come up with, "Shouldn't we be doing this with RESTy POX?". Then someone invariably has to ask, "How are we going to serialize all this crap - all these database objects have little dangly bits that are half-stuck to the database...". The architect in the room starts wagging his finger reminding people of the DRY principal and so your strategy for creating local copies of remote objects that are 99% dupes and 1% tightly coupled "dangly bits" goes down the toilet. Maybe someone even brings up COM+, MQ series, distributed MSMQ, middleware, Tibco, Enterprise Service Buses, and even more buzz words and jargon terms. Pretty soon, the whole thing turns into a battle royale. At some point, someone with seniority throws down the gavel and you pick one of the many thousands of ways to accomplish the distribution.

That's not the way it should work. You should be able to construct your application segmented the way you want it so that the functionality works. You start with nothing and you then rapidly build your application as a monolithic cylo containing a bunch of, what appears to be, tightly coupled services. Then you do your analysis and you figure out that you need some services in a secure zone, you need some on a high availability box, you need some others with really fast transaction requirements, and yet other services need to go elsewhere. With Volta, you can just decorate these services with the appropriate attributes and *poof* Volta takes care of all of the accidental complexity of network and distributed object plumbing. Volta will actually recompile your application with the distribution capabilities built into it and you are free to worry about testing, verifying, and validating your application.

Here's an example of what the same application shown above might look like after a Volta-style tier-split:

So the big myth floating around is that Volta is attempting to tell people that Volta creates a world that supports Tier Agnosticism. This couldn't be further from the truth. The tier, or execution context, in which your service runs is vitally important and must be explicitly defined for each environment in which your application exists. What Volta does is allow you to worry about the actual code for your service and your client consumer and you can not worry about the plumbing code. Refactoring functionality out of an application so that it runs in a distributed fashion is what Volta brings to the table. If you decide, after building your application and rigorously testing it, that a particular piece of server-side functionality really needs to be collapsed back into the client... How do you think that would go over without a tool like Volta?

Sure, a lot of us have gotten used to enterprise programming and so we have techniques, tools, and tricks to make refactoring distributed applications easier. The clever use of interfaces, shared libraries, serialization formats, web services discovery, etc will all get you pretty far. The problem is you're still spending an inordinate amount of time worrying about plumbing (which, in my opinion, should fall into the flotsam and jetsam category) when you should be worrying about the application logic and answering questions like "does this work?" and "Does this application meet the functional requirements?".

So, the moral of the story is this: Volta is all about making the ability to tier-shift services and refactor across tiers easy and less time consuming. It does not intend to tell you that you no longer need to worry about where your services lie. The location and execution context of your services is critically important. Volta makes changing and refactoring that location dead simple.