Microsoft Azure Service Fabric: There are several reasons to switch to this brand new platform for building distributed systems. For one, Service Fabric can host itself literally anywhere: on your laptop, in your data center, in some else’s data center, on Windows, on Linux… If you are still hugging Cloud Services (that thing with web roles and worker roles), you better mend your acts early, it is getting phased out and will become obsolete soon. If you have worked with cloud services, you must be aware of the fact that there are differences in the behaviors of the development emulator and Azure and the issues that arise from those differences are not pretty. Service Fabric ensures delivery consistency by providing you with exactly the same environment on your laptop and in your data center. There is no reason for you to not use Service Fabric in your production applications given that it is now GA on Azure and Windows Server.

Since my last post on Microsoft Azure Service Fabric, I have received quite a few questions from the readers of this blog about applying their own communication protocols, such as the various WCF bindings, RPC etc. on their Service Fabric applications. I can see that the MSDN documentation doesn’t really do justice to this area, so today we will try to understand how you can apply your protocols on Service Fabric Reliable Services by building a basic sample.

What are Service Fabric Reliable Services?

We have already discussed about Service Fabric in an earlier post. I encourage you to read that post first in order for this one to make any sense.

Before we discuss about service communication any further, note that there are two kinds of communication that are involved in a Service Fabric application.

1. Client-Application : The communication channel used by the clients to connect and interact with your Service Fabric Application.
2. Inter-Replica : The communication channel used by the various replicas of your Microservice to talk to each other to replicate state data. This replication ensures that consistency of state data is maintained, so that when the primary replica goes down, one of the secondary replicas can resume processing without losing state.

Generally, we would want to control the behavior of the  Client-Application communication channel only. I will show you how you can configure both the communication channels in your Reliable Services.

Implementing a Communication Stack

Your Service Fabric application can accept requests and respond to clients using various communication protocols. Service Fabric provides a couple of inbuilt communication stacks that you can use, such as the default stack built on RPC proxy, WCF, REST (WebAPI) and HTTP (ASP.net). However, rolling out your own communication stack is quite simple, for which you just need to implement the following in your Microservice:

1. Implement ICommunicationListener and handle how your communication channel will open, close and abort.
2. Override the method CreateServiceInstanceListeners for stateless service (base class StatelessService) and CreateServiceReplicaListeners for stateful service (base class StatefulService) and return a collection of listeners to the Service Fabric runtime (including your custom listener).
3. Add the desired communication ports to the ServiceManifest.xml file of your Microservice.

Once the service is ready, we need to enable the communication on the clients of this Microservice. The clients of this Microservice would first need to resolve the endpoint address of the partition or an instance of the service and then send requests to it. This process involves the following.

1. Use ServicePartitionResolver to resolve the address of the replica to which the client wants to connect to. The overrides of the constructor of this class allow the client to connect to multiple clusters.
2. Retrieve the FabricClient client object to communicate with the cluster.
3. Handle the headache in lieu of fine-grained control: Your client will need to detect whether the connection attempt failed because of a transient error and can be retried (e.g., the service moved or is temporarily unavailable), or a permanent error (e.g., service was deleted or the requested resource no longer exists). Service instances or replicas can move around from node to node at any time for multiple reasons. The service address that was resolved through ServicePartitionResolver may be stale by the time your client code attempts to connect. In that case again the client will need to re-resolve the address.

#azure service #byop #bring your own protocol #azure service fabric applications