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.

Advertisements

2 thoughts on “The SOA Model Service Fabric vs WCF

  1. Hi Chris, great comments. Great to see the interface-proxy usage/programming model, that’s apparently the way to go. Would be curious to know about the default and alternative bindings and supported wire protocols, apparently now under the hood.
    And I think that the worst offence of WCF was that you couldn’t make it work by trial and error, but had to know what’s going on. Apparently the new model is a lot simpler and productivity of all developers not just technology specialists seems to be a primary objective.

    • I understand the pain you’re referring to regarding the “trial and error”. Unfortunately that was inflicted upon us by Microsoft’s marketing of WCF and not WCF itself. WCF was intended to be purely strongly typed. WCF’s rise was in the hayday of XML configuration as the current cargo cult culture fad so they said MOAR XML.

      Every thing that has been traditionally showed as configured by XML in configs by WCF (even the crap generated by visual studio templates etc) all have strong types. Using the strong types would prevent in almost every case putting an unacceptable value into WCF. Whereas XML is quite happy to let you use any create/delete/misspell attributes and enter any text possible into those attributes.

      Also with what I know about WCF now, the only way I use WCF is an almost exact replica of Service Fabric. I don’t expose it to people, it uses private transport whether it’s named pipes, tcp/ip, azure service bus, msmq etc.

      However I’m thrilled about the ASF. I don’t want to be in the hosting business. I want to let the legions of Azure engineers be responsible for that while I’m responsible for delivering strategic business value (via software / SOA).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s