CODEWITHSUNDEEP
asp.net-web-apiazure-service-fabric
Sajan
Sajan

Reputation: 155

Communicate to stateless web Api service from a different application in Azure Service Fabric

I have two different service fabric applications. Both are stateless web api models. I do have a situation that from service 1 inside application 1, I need to invoke service 2 which is part of application 2. I am deploying both applications in the same cluster. Can someone advise the best practice here. What could be best way to communicate. Please provide some sample as well.

Upvotes: 0

Views: 492

Answers (2)

yoape
yoape

Reputation: 3335

Fabric Transport (aka Service Remoting) is the sdk built-in communication model. Compared to communication over HTTP or WCF it does a little more, especially on the client side of the communication.

When it comes to communicating with Service Fabric services (or really, any distributed systems service) your communication should take into account that the connection could be fail to established on an initial try, or be interrupted mid communication and that you really shouldn't build your solution to expect it to always work flawlessly. The reason for this is in the nature of how Service Fabric at any time can decide to move primaries from a node to another node, the nodes themselves can go down and the services can crash. Nothing strange about he great thing with Service Fabric is that it does a lot of the heavy lifting for you when it comes to maintaining your services and nodes over time.

So, in terms of communication this means that a client needs to be able to do three things (for it to truly work in a distributed environment);

  • resolve the address to the service (figure out which node it is on, which port it is listening on, which partition id and replica to target and so on)
  • connect to the service, package and send requests and then recieve and unpack responses
  • retry the resolve and connect if the communication fails

Fabric Transport does all this when you are using the Service Remoting clients (like ServiceProxy) and service side listeners.

Thats the good part with Fabric Transport, you get all that out of the box and most of the time you don't have to change the default setup either. The bad part is that it only works for communication inside the cluster, i.e. you cannot communicate from the outside to a service running in the cluster using Fabric Transport. For that you need HTTP or WCF.

HTTP(s) and WCF (over HTTP(s)) communication allow you to build your own clients and handle the communication yourself. There are a number of samples on how you can do the resolve, connect and retry for HTTP clients, this one for instance

Upvotes: 1

Wouter B
Wouter B

Reputation: 731

According to Microsoft there are three built-in communication options. It's up to you to decide which one works best for you. I'm personally using service remoting which is easy to quickly set up. It also allows you to exception handling in your client service.

Upvotes: 0

Related Questions