The SOA Model Service Fabric vs WCF

I’ve started my trek into analyzing all of the information that has been published by Microsoft on Azure Service Fabric. One of the very first things I noticed is strikingly similar it is WCF. This may be a surprise to some but is not at all surprising to me. WCF has been a much maligned technology, largely for being widely misunderstood.

Let me start with where I feel people were so put off by WCF.

1. XML configuration. WCF is one of the most (if not the most) interopable and configurable frameworks in the world. This is a double edged sword when coupled with XML. WCF was created in the hayday of XML configuration being the “new hotness” everything needed XML and so it was thrust upon WCF. WCF has never meant to be configured via XML it was built fully strong typed and in fact can be used without a single line of XML configuration entirely. Ask yourself, did you know you could use WCF with strongly typed configuration? That standard configuration exists out of the box in predefined strong types?
2. WS-* and the web. WCF is at its heart WINDOWS Communication Foundation. It was never built with any concern given to the web. The fact that WCF is immensely interopable it was decided WCF needs to become the replacement for ASMX web services, because it could. This was the early days of SOA and the WS-* standards were created with the belief if they created a wide set of standards that SOA apps would emerge with guaranteed connectivity with each other. Unfortunately the standards that were created were horrific. WCF then took the blame for the standards as it was one of the few systems that was so extensible it could actually even implement the standards for how bad they are.

Now that we’ve talked about is commonly attributed as what’s wrong with WCF let’s talk about WCF and Azure Service Fabric. Working with the examples from Microsoft the following is an illustration of an Actor

public interface ICalculatorActor : IActor {

Task<double> AddAsync(double x, double y);
Task<double> SubtractAsync(double x, double y);

public class CalculatorActor
     : Actor, ICalculatorActor { ....

If this was done in WCF you would have

[ServiceContract]
public interface ICalculatorActor {

[OperationContract]
double Add(double x, double y);
[OperationContract]
double Subtract(double x, double y);

public class CalculatorActor
     : ICalculatorActor { ....

So the only difference here is whether you have an decoration model or a marker model. Just to clarify with WCF the async keyword doesn’t need to exist. Whether a service call in WCF will be asynchronous depends on your hosting model, but it absolutely can be asynchronous.

On to the usage model

ActorId actorId = ActorId.NewId();
var applicationName = "fabric:/CalculatorActorApp";

ICalculatorActor calculatorActor
 = ActorProxy.Create<ICalculatorActor>
   (actorId, applicationName);

var result = calculatorActor.AddAsync(2, 3).Result;

With WCF

var actorId = new BasicHttpBinding();
var applicationName = "http://localhost/Service";

ICalculatorActor calculatorActor
 = new ChannelFactory<ICalculatorActor>
    (actorId, applicationName).CreateChannel();
 
double result = calculatorActor.Add(2, 3);

There is no difference here at all. The only minor difference is the transport binding in the Actor Api is fixed whereas it is configurable in WCF.

What about hosting?

using (FabricRuntime fabric
  = FabricRuntime.Create()) {

fabric.RegisterActor(typeof(CalculatorActor));
Thread.Sleep(Timeout.Infinite);

And WCF

ServiceHost fabric
 = new ServiceHost(typeof(CalculatorActor)); 
      
host.AddServiceEndpoint(typeof(ICalculatorActor),
     actorId, applicationName);
host.Open();
Thread.Sleep(Timeout.Infinite);

Once again they are virtually identical. The minute difference again is declaring the binding for the end point since WCF supports any binding whereas Service Fabric supports itself only.

Something else that is directly shared between WCF and Service Fabric is the DataContract serialization model.

I’m immensely excited about Azure Service Fabric. I do not wish to be in the plumbing business nor the hosting business. While this is likely premature to state definitively, but it is likely I would never choose to build an application without the Azure Service Fabric. The only question left is when could I go to production and that I have no answer to.