I am glad that you are writing about Volta and you are definitely right that abstractions can be leaky; however, I think that tier splitting was not adequately explained because it does not suffer from the problems that you indicate.

The abstraction that tier splitting provides does not attempt to hide the boundary between the tiers. It does hide the boilerplate code to serialize, maintain object references, communicate, provide profiling, etc. The point is that the developer should be free to focus on the hard part of tier splitting: deciding how to architect the boundary between tiers. With Volta, the developer does this by deciding where to place the annotations and what interface the exposed types present.

Some people believe that making something harder to do will make people think more deeply about it. This has some merit but overall it is a bad strategy. It is easy to see the fallacy of this claim in the extreme. It is not a good idea to build every application from the ground up in assembly language so that programmers know the true cost of what they are building. When tools make something easier while still making it explicit what is going on then the developer can focus on the problem and not on the mechanics.

In Volta's case, tier splitting requires explicit annotations in the code denoting where the boundaries are. It does not require explicit imperative code to accomplish the split but the developer still explicitly decides where to make the cut. This enables a more fluid development process where the programmer can refactor around the boundary more easily without having to change a lot of boilerplate code that obscures the fundamental problems in his code and makes him less nimble.

The idea of tier splitting in Volta is to explicitly acknowledge the boundary between tiers and then free the programmer to focus on the essential difficulty of managing the divide.

Thank you for taking the time to write about Volta and I hope this clears up the confusion.

Thanks for responding Wes. I think removing the need to get involved with the plumbing is no bad thing at all and I basically say this in the last paragraph of the post. However, the "annotate my class" approach without the ability for the compiler to catch potential problems can cause serious issues.

If you look at my original post on Volta (linked from this article) I was addressing the issue of people blindly annotatng a hugely inappropriate class. There is nothing to stop them and there is nothing to *advise* them that this is a bad idea. At least with the WCF model you can only put an [OperationContract] on a method. Something along those lines to exclude properties from the remoted interface would be better.

In the past my consulting has got me involved directly and indirectly with projects that have taken the "brown-field" approach to distribution. An existing monolithic application that people tried to remote parts of using the "short cut of the month" whether it be DCOM or .NET Remoting. Tiersplitting in its current form will produce more of these issues than DCOM and Remoting ever did because it is so easy but it does not provide any sanity checking.

The automation that you have provided will be "good enough" for many applications - there is another class of apps that really need to take control of the remoting infrastructure and tune it to their requirements. My fear is currently that Volta encourages you to shoot yourself in the foot because it doesn't tell you that you're about to do something really stupid. However, its early days yet and maybe this kind of checking/warning can make it into the technology.

I agree with your ideas but I think there is still some confusion. Building distributed applications is not easy and many people get it wrong, but I don't think that adding more buttons and knobs is the right way to help people write good applications.

It is not the compiler's job to catch performance problems introduced by an application. For example, most compilers that I know don't warn people when they write a bubble sort where a quicksort should be used. However, the languages and tools can actively work against writing good code by making the programmer grapple with more complexity than is necessary.

For example, while lower-level languages help a programmer understand what exact operations are being done, they do not help programmers see the larger picture. The architecture and algorithms are more critical to performance than the individual operations. In some cases, hacking at the lowest level is necessary but these cases are the exception rather than the rule.

In a similar way, Volta abstracts away the details of the operations necessary to split an application while still requiring the developer to declaratively specify where the split occurs and what interface is exposed. The developer can gain control at the lowest level by doing things like taking over serialization.

The right tool for warning developers about performance problems is a profiler. Volta includes the Rotunda profiler which does end-to-end cross-tier profiling. The developer can then make informed decisions about how to architect the boundary between the tiers.

The best way to help developers is to give them simple, powerful, easy-to-understand tools and then let the developers shine.

OK, so I should clarify - I really bean "build process" when i say "compiler". For example the validation infrastructure in WF is something that is not enforced by the compiler but rather a step in the build. Are you saying that that shouldn't exist because its just more knobs and buttons? And you are misrepresenting what I'm saying here - I'm not saying that abstracting the mechanics of splitting the application isn't a big win for some applications, what I'm saying is you should help people not shoot themselves in the foot in the process.

You say you want people to concentrate on the business functionality and the interfaces between tiers rather than the mechanics of how the split between tiers is achieved. I think this is a great objective. However (and you knew that was coming ;-) ) the current implementation precisely removes the need for someone to think about the interface between tiers. They can just attribute a class and it just works. And it will work on their local machine and across the LAN ... then they deploy it on to the internet and it suddenly doesn't work quite so well.

Obviously you cannot force someone to design a tier interface correctly, but there are some things that scream out of a design that say "wrong". Most obvious is the use of properties. What I'm arguing is that you need more than just the class level attribute - you need a member based one too that can only be put on methods. And if anyone calls a tier split object on something that isn't attributed you throw an exception. This makes the developer think about the functionality they are going to expose across the tier in a concrete way rather than just hoping they do the right thing.