using Service Fabric CommunicationClient and servicePartitionClient from outside of fabric?

Question

I want to be able to call a stateful HTTP/WebApi service from a non-fabric app or service. I could just use the published urls for the stateful service but want to take advantage of failover to a different primary by resolving the partition endpoints.

I tried first to test in a desktop console app but it fails to execute the communications Lambda function inside of InvokeWithRetryAsync.

Is this a dead end (non fabric apps can't resolve stateful services) or is there another way to resolve the endpoint from non-fabric apps. Otherwise, I will likely wrap the requests in a "middleman" stateless service (like Wordcount Webservice).

        var result = await servicePartitionClient.InvokeWithRetryAsync(
            client =>
            {
                //never reaches here. 
                Uri serviceAddress = new Uri(client.BaseAddress, "SetConfiguration");

                HttpWebRequest request = WebRequest.CreateHttp(serviceAddress);
                request.Method = "POST";

                //Add the content into the body
                byte[] byteArray = Encoding.UTF8.GetBytes(_datapacket);
                request.ContentType = "application/json";
                request.ContentLength = byteArray.Length;
                Stream dataStream = request.GetRequestStream();
                dataStream.Write(byteArray, 0, byteArray.Length);
                dataStream.Close();


                request.Timeout = (int)client.OperationTimeout.TotalMilliseconds;
                request.ReadWriteTimeout = (int)client.ReadWriteTimeout.TotalMilliseconds;

                HttpWebResponse response = (HttpWebResponse)request.GetResponse();
                //for now, just return ok
                return Task.FromResult<string>("ok");

            });

Answer 1

It's been a while since I tried this, but the outcome should be the same: build a stateless service to act as a gateway to your stateful service.

The issues that I ran into were firstly around connecting to the cluster - if it's a secure cluster then you need to have client certificate loaded that will allow the secure connection to be established.

Once this is resolved, you will then likely bump into the problem that the naming service will resolve partitions to local addresses, not addresses that can be resolved from outside the cluster.

So the net result was that we built a stateless service which can be accessed as a typical REST API, with the benefit of moving the abstraction of partitioning into this layer within the cluster.

Answer 2

Yes, non-Service Fabric applications that run outside of a Service Fabric cluster can talk to a Service Fabric application, absolutely. Service Fabric itself doesn't impose any restrictions because it's your services themselves that are opening up communication endpoints (ultimately your services are just running in an EXE, and they can listen on an address and port just like any EXE you've written before). When you use the communication client APIs (like ServicePartitionClient), you're just asking the Naming Service to resolve the address and port of a service, which you can then connect to like you normally would.

There are two potential problems when you have a client outside of your Service Fabric cluster:

1. Does your client have access to the cluster so it can talk to the Naming Service? If your cluster is secured with a certificate, you'll need to use that cert in the client to connect to the Naming Service.
2. Are your service endpoints visible outside the cluster? Typically for stateful services, you get assigned a port from a port range. If your cluster is running in Azure, this port range is internal-only and not exposed through the Azure Load Balancer. If you're hosting your own cluster, you can set this up to let clients punch through your LB, but you should consider whether or not you actually want clients to be allowed to do that.

So the easiest solution, as mentioned by Darran, is typically to have a stateless service that acts as your ingress point for client requests. Once you're "inside" the cluster, you no longer have these problems.