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 more than made up for that.

My benchmarks show that WCF can easily sustain hundreds of calls per second per class, making it adequate for the vast majority of business applications. While of course there is a performance hit for doing so, the productivity gains more than compensate, and historically, it is evident that this is a trade-off you should make. WCF does have detrimental overhead, but it’s to do with ownership, not performance (which is adequate). Imagine a decent-sized application with a few hundred classes, each of which you wish to treat as a service. What would the Main() method of such an application look like, with hundreds of service host instances to be instantiated, opened, and closed? Such a Main() method would be unmaintainable. Similarly, would a config file with many hundreds of service and client endpoint declarations be workable?

The truth is that in practical terms, WCF cannot support (out of the box) such large-scale granular use. It is designed to be used between applications and across layers in the same application, not in every class. Just as COM had to use C++ and Windows, WCF is bolted on top of .NET. The language used (C# or Visual Basic) is merely component-oriented, not service-oriented, and the platform (.NET) is component-oriented, not service-oriented. What is required is a service-oriented platform, where the basic constructs are not classes but services. The syntax may still define a class, but it will be a service, just as every class in .NET is a binary component, very different from a C++ class. The service-oriented platform will support a config-less metadata repository, much like .NET generalized the type library and IDL concepts of COM. In this regard, WCF is merely a stopgap, a bridging technology between the world of components and the world of service (much like ATL once bridged the world of objects and C++ with the world of components, until .NET stepped in to provide native support for components at the class and primitive level).

public static class InProcFactory
{
   public static I CreateInstance<S,I>() where I : class
                                         where S : I;
   public static void CloseProxy<I>(I instance) where I : class;
   //More members
}

[ServiceContract]
interface IMyContract
{
   [OperationContract]
   string MyMethod();
}

class MyService : IMyContract
{...}

IMyContract proxy = InProcFactory.CreateInstance<MyService,IMyContract>();
proxy.MyMethod();
InProcFactory.CloseProxy(proxy);

IMyContract proxy = InProcFactory.CreateInstance<MyService,IMyContract>();

IMyContract proxy = new MyService();