Accessing a stateful service - azure

I have been researching Azure's Service Fabric Reliable Services and looking at the samples too.
I am now building a simple proof-of-concept application with a recommended setup: A stateless Web API service with a stateful service behind (1 partition).
I've been going round in circles trying to find the easiest way for the API service to talk to the stateful service behind. It looks like the stateful service will have to exposed using Web API too (as shown in the example WordCount app).
Am I correct thinking that in order to consume a stateful service it needs to expose itself via HTTP/WCF etc. using something like OwinCommunicationListener : ICommunicationListener from the examples?

When the services lives inside the same app, you can access the service instance something like:
public static MyServices.Interfaces.IMyStatefulService GetMyStatefulService()
{
var proxyLocation = new ServiceUriBuilder("MyStatefulService");
var partition = new ServicePartitionKey(1); //provide the partitionKey for stateful services. for stateless services, you can just comment this out
return ServiceProxy.Create<MyServices.Interfaces.IMyStatefulService>(proxyLocation.ToUri(), partition);
}
ServiceProxy is from the Microsoft.ServiceFabric.Services.Remoting.Client namespace.
And you interface code will look something like:
public interface IMyStatefulService : IService
{
Task<MyResponseResult> DoSomething(MyRequest request);
}

If the Stateful and Stateless service are in the same cluster (In your case i assume that both services are in the same application type (same solution) ), You can call the Stateful service from Stateless service Using 'Service Proxy'
If you want to consume the stateful service from outside the cluster, you need to open an API communication listener.
ServiceProxy class is available from "Microsoft.ServiceFabric.Services".
Service Proxy only works within the same cluster.
usage
IServiceClass proxy = ServiceProxy.Create<IServiceClass >(new Uri(fabric:/your_service));
In order to proxy to works, the Methods in the stateful service needs to be exposed using an Interface.

Related

Micro service communication solution in the Azure service fabric

Recently I started working on an old Azure cloud based micro service project, which is running on Azure Service Fabric platform.
(I'm new to this platform, also I don't have team members for discussion. I can read the code and document to understand this project.)
I roughly understand how Service Fabric works. But one question confuses me a lot about inter service communications. I want to know which inter service communication solution my project is using.
Here are some useful information about this point:
Suppose the Azure Service Fabric cluster endpoint is as follows: myTestCluster.westus.cloudapp.azure.com:19000
The project use Consul for service discovery. In the codebase, before sending request to other services, first need to get the registered URL from consul. And the URL resolved from Consul is something as follows: myTestCluster.westus.cloudapp.azure.com:23333, which is another service deployed and run on the cluster. The code for sending request is something like:
using (var client = new HttpClient())
{
var response = await client.PostAsync(uri); // uri is resolved from Consul
return await response.Content.ReadAsStringAsync();
}
I read some article and know that the potential inter-service communication methods are:
Service Fabric's Naming service: based on the method I shown above, I think it's not this one.
Reverse proxy
DNS service
But I can't tell out method 2 or 3, which one is used. Or any other ones?

Azure Service Fabric usage

Service Fabric was just announced at the build conference. I was reading the scarce documentation about it and I have a question.
I'm evaluating Service Fabric for hosting CRUD like microservices that are at the moment built in ASP.NET WebApi.
Is Service Fabric geared towards hosting small pieces of functionality that receive data, process it and return the result, rather than hosting CRUD WebApi types of application?
Service Fabric enables the creation of both stateless and stateful microservices.
As the name suggests, any state maintained by an an instance of a stateless service will be lost if the node goes down. A new, fresh instance will simply be spun up elsewhere in the cluster.
Stateful services offer the ability to persist state without relying on an external store. Any data stored in a Reliable Collection will be automatically replicated across multiple nodes in the cluster, ensuring that the state is resilient to failures.
A common pattern is to use a stateless service as the client-facing gateway to the application and then have that service direct traffic to the app's partitioned stateful services. This hides the work of resolving partitions from clients, allowing them to to target one logical endpoint with all requests.
Take a look at the WordCount sample for an example of how this works. The WordCount.WebService stateless service acts as the front end to the application. It simply resolves the partition based on the incoming request and then sends it on. The WordCount.Service stateful service (partitioned based on the first letter of the word) immediately puts those incoming requests in a ReliableQueue and then processes them in the background, storing the results in a ReliableDictionary.
For more details, see the Reliable Services Overview.
Note: for now, the best way to expose WebAPI endpoints to clients is to self-host an OWIN server in the stateless service. ASP.NET 5 projects will soon be supported as well.
This video answers my own question: http://channel9.msdn.com/Events/Build/2015/2-704. In summary, we should use Stateless Services to host ASP.NET based sites or API's which persist data to external data stores.
If you don't have state (or have it externally), Stateless Service is the way to start.
Answer to the original question is "both". Basically, anything that have main() function (with couple of more extended contract methods to talk to Service Fabric) can be a service in Service Fabric world.

How to use a Service Locator in a WCF service

I'm using a service locator to hold concrete instances of classes, which is used in a WCF service. Rather than passing the ServiceLocator around I decided to make it static so I could access it from every class. The service locator is populated when the WCF service kicks off and depending on some parameters, it can get populated with different concrete implementations.
My problem is that if a call is made to the WCF service before another call has finished, then (I think) the ServiceLocator will be populated with the incorrect implementations.
Is there any way to make the service locator available to classes and not have it re-used by different threads or calls to the WCF service?
You provide few details about your Service Locator and the undelying implementation. From what I read I understand that it's your own.
My personnal advice is that you should not use a Service Locator in a case of WCF service because WCF exposes some interface that enable dependency injection.
You could read more about the anti pattern Service Locator here : http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
You should not implement your service locator because there are many OSS project around dependency injection you can use and that do the job the right way.
Here is the correct implementation of Dependency Injection using StructureMap with WCF services : http://lostechies.com/jimmybogard/2008/07/30/integrating-structuremap-with-wcf/.

How does WCF take care of multiple client calls to the server?

Want to get a clear understanding of how WCF works.
Lets say a WCF service has exposed a function A.
Now the client creates 5 threads, and in each one of them calls the function A with different parameters.
I assume this should happen - a new instance of function A would get created for every thread call to that function. Could some one confirm this.
I have written a POC which is not doing this, its giving inconsistent results.
This depends on your service configuration via the ServiceBehavior attribute on the class implementing your service contract:
[ServiceBehavior(
InstanceContextMode = InstanceContextMode.PerSession,
ConcurrencyMode = ConcurrencyMode.Multiple)]
With the parameter InstanceContextMode you tell WCF how you want to host your service:
Single: One instance of your service class will be created which receives all service calls
PerSession: For each connecting client a new instance will be created
PerCall (default): For each call of every client a new instance will be created
The next thing is synchronisation, when one host object receives parallel operation calls. You can control the behavior with the ConcurrencyMode parameter:
Single (Default): WCF serialises all operations, so your service instance is executing exactly one or no operation call at a time.
Reentrant: WCF delegates all operation calls to your service instance directly, but synchronises calls to another WCF service inside a service operation (rarely used i think).
Multiple: WCF delegates all operation calls to your service instances directly without synchronization. You have to worry about synchronisation yourself.
The default is for a new instance of your wcf service to be created per call, this is documented e.g. here
There is no such thing like a new instance of function. It'd be rather instance of class.
You can configure how your Service should behave by changing proper meta attribute.
You can make your service implementation instantiated per call. It can also work as singleton (one and only service instance for all calls).
Here you can find information on creating singleton WCF service
And here there is a lot more about WCF services

How to deploy a Azure application into production without Azure

I am developing an Azure application using queues, blob storage and SQL Azure. We anticipate that some clients will not be willing to have their data hosted in the cloud (for reasons of paranoia or legal limitations on the jurisdiction in which data can be stored) and will want to run the system on a server located within their own data centres, on a single server. Using SQL Server and building an alternative to blob storage should be easy, but Azure queues are a more complicated. I guess using the development fabric is undesirable because the MS documentation says it must run as administrator.
How should I go about this?
I would add a layer of abstraction over the AzureQueues.
Something like:
public interface IQueueService
{
// will create if not exists
IQueue GetQueue(string name);
IQueue GetQueueIfExists(string name);
}
public interface IQueue
{
string Name { get; set; }
void AddMessage(SimpleMessage message);
void DeleteMessage(SimpleMessage message);
SimpleMessage PeekMessage();
void Clear();
}
etc...
That should give you an idea. You can then provide two implementations, one that utilizes AzureQueues and another one that uses MS Queues (http://en.wikipedia.org/wiki/Microsoft_Message_Queuing)
You choose the implementation depending on whether you are running on Azure or not.
I have done something very similar in the past.
You don't need to run on the developer fabric to access azure resources. Blobs are very easy to access via the web, I'm fairly certain you can do it with tables and Queues as well as the "http://'accountname'.queue.core.windows.net/" URLs are publicly available.
For a neat solution you should look at Azure AppFabric service bus, it basically allows you to connect, or "project" an on premise app web service endpoints into the cloud, it's basically a relay service. (It sound like magic, but it's actually pretty simple). You can use the same Service Bus to give Azure Worker Role services public Url endpoints.
http://msdn.microsoft.com/en-us/library/ee732537.aspx
http://www.microsoft.com/windowsazure/appfabric/overview/default.aspx

Resources