I have a Windows service that listens on a queue; when there is a new message, it parses it, and stores it in its own storage.
It's "uni-directional" in the sense that it just listens on a queue, but doesn't expose any endpoint and it doesn't interact with other services.
Is this considered a micro-service?
As the name implies any service which is not monolithic, which can be independently built and deployable can be a microservice.
There is 12 factor approach to be called a true micro service, https://www.nginx.com/blog/microservices-reference-architecture-nginx-twelve-factor-app/
Microsoft have a article about that.
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
Services communicate with each other by using well-defined APIs.
Internal implementation details of each service are hidden from other
services.
Related
While trying to create a web application for shared drawing I got stuck on a problem regarding Kubernetes and scaling. The application uses an ASP.NET Core backend with SignalR for sharing the drawing data across its users. For scaling out the application I am using a deployment for each microservice of the system. For the SignalR part though, additional configuration is required.
After some research I have found out about the possibility to sync all instances of the SignalR backend either through the use of Azures SignalR Service or the use of a Redis backplane. The latter of which I have gotten to work on my local minikube environment. I am not really happy with this solution because of the following reasons:
My main concern is that like this I have created a hard bottleneck in
the system. Unlike in a chat application where data is sent only once
in a while, messages are sent for every few points drawn in the
shared drawing experience by any client. Simply put, a lot of traffic
can occur and all of it has to pass through the single Redis backplane.
Additionally to me it seems unneccessary to make all instances of the SignalR backend talk to each
other. In this application shared drawing does only occur in small groups of up to 10 clients lets
say. Groups of this size can easily be hosted on a single instance.
So without syncing all instances of the SignalR backend I would have to route the clients connection based on the SignalR group name to the right instance of the SignalR backend when the client is trying to join a group.
I have found out about StatefulSets which allow me to have a persistent address for each backend pod in the cluster. I then could somehow associate the SignalR group IDs with the pod addresses they are running on in lets say another look up microservice. The problem with this is that the client needs to be able to access the right pod from outside of the cluster where that cluster internal address does not really help.
Also I am wondering if there isnt a whole better approach to the problem since I am very new to the world of kubernetes. I would be very greatful for your thoughts on this issue and any hint towards a (better) solution.
I am working on an ASP.NET MVC 5 application (based on nopCommerce). I want to use MassTransit to communicate with another application that is used for inventory management, billing, etc. It would be easier if I could add receive endpoints directly into the web application and not have to create a Windows service for that. But the MassTransit documentation says it is not recommended and there is no explanation as to why that is.
MassTransit in a web application
Configuring a bus in a web site is typically done to publish events,
send commands, as well as engage in request/response conversations.
Hosting receive endpoints and persistent consumers is not recommended
(use a service as shown above).
Does anyone know the reasoning behind it? Is it not safe to add receive endpoints in a web application? Will they not work properly?
Hosting endpoints in a web application is not recommended because web applications often restart for various reasons. These reasons are typically outside the control of the application itself.
While using a standalone Windows service is highly recommended, as long as the bus is properly started and stopped using the Application_Start and Application_End methods, it can be okay if you have no other options available.
I want to use Azure service bus in my iOS app to communicate with server i have went through the below link. its pointing to C#.Need suggestions to work on iOS.
http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/#next_steps
You may want to consider using WebHttpRelayBinding for your service so you can hit the Azure endpoint using HTTP / HTTPS.
WCF supports both RESTfull and classic SOAP style messaging but using lightweight json requests in a RESTfull service would be better from a mobile app.
read the following article for details. but you don't need to write custom autostarter if you are using IIS 7.5 or greater with appfabric, since it has autostart functionality in built.
http://msdn.microsoft.com/en-us/library/hh966775.aspx
if you don't need request-response messaging pattern then you can also consider service bus queues for persistence, and your on-premise process can pull and process the messages at its own pace.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
I have 6 WCF web services in my web application.
On visiting any page on my MVC3 site I may call up to 4 or so of these WCF services.
In my live environment (as in all my environments) I have all my web services hosted on the same machine (each front end server has these services).
My issue is that the site I'm working on runs very slowly and as part of the performance improvements to the site I wanted to reduce the overhead of all these http requests to these various WCF services.
My question is, is it possible to call these web services in a 'non-http-overheady' way since they are living on the same machine anyway?
Thumb rules in choosing endpoint' binding of WCF
If you require your service to be consumed by clients compatible with
SOAP 1.1, use basicHttpBinding for interoperability
If you require your service to be consumed within the corporate
network, use netTCPBinding for performance
If you require your service to be consumed over the internet and the
client is a WCF compatible, use wsHttpBinding to reap full benefits
of WS* specifications
If you require your service to be accessible only in the same machine, use netNamedPipeBinding
If you require your service to be queue messages, use netMsmqBinding
If you require your service to act as server as well as client in a
peer to peer environment, utilise netPeerTcpBinding setting