 |
|||||||||
|
|||||||||
|
|
Volta is a new CTP that just came out from Microsoft Live Labs. Several months ago I saw a Channel 9 video with Erik Meijer explaining about what Volta's goal was and what it was going to do. I was intrigued but got busy doing other stuff because no code or CTP followed the video - so there was nothing I could do with it.
Now I've got my hands on a CTP of Volta and I am really, really intrigued. What I find really intriguing is that already the misinterpretations of what Volta is and what it is supposed to do have started bubbling up so I thought I would post (my opinion of) what Volta's tier splitting is all about.
Basically Volta's tier splitting feature is designed to make it so that you can build your application early and then figure out where the services need to go when you're done. This allows you to profile your entire application on a per-method-call basis all in a tight integrated system without having to deal with complicated distributed deployments. Once you've done your profiling you will be able to see what communications are chatty, which ones are chunky. Further, you can then decide whether you want Service A to be in the "secure" server type and whether you need Service B to be running on the "high availability" server type, etc.
Here's an example of what a service-oriented (you are embracing the whole software-as-a-service concept even when building your internal class hierarchies, aren't you??) application might look like when built as a pre-Volta monolith:
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.
