Programming WCF Services, 2nd Edition

What's Next?

Since service-oriented frameworks provide off-the-shelf plumbing for connecting services together, the more granular those services are, the more use the application can make of this infrastructure, and the less plumbing the developers have to write. Taken to the ultimate conclusion, every class and primitive should be a service, to maximize the use of the ready-made plumbing and to avoid handcrafting plumbing. This, in theory, will enable effortlessly transactional integers, secure strings, and reliable classes. But in practice, is that viable? Can .NET support it? Will future platforms offer this option?

I believe that as time goes by and service-oriented technologies evolve, the industry will see the service boundary pushed further and further inward, making services more and more granular, until the most primitive building blocks will be services. This would be in line with the historical trend of trading performance for productivity via methodology and abstraction. As an industry, we have always traded performance for productivity. .NET, where every class is treated as a binary component, is slower than COM, but the productivity benefit justifies this. COM itself is orders of magnitude slower than C++, yet developers opted for COM to address the problems of object-orientation. C++ is likewise slower than C, but it did offer the crucial abstractions of objects over functions. C in turn is a lot slower than raw assembly language, but the productivity gains it offered ...