My team is in the middle of deciding the architecture of our backend system:
Webserver A is an ASP.NET MVC application with ASP.NET Web API component, hosted in Azure Website.
Windows Service B is a self-hosted OWIN server that will periodically push notifications to clients who subscribes to the notification, hosted in Azure VM.
Windows Service C is a client that subscribes to notification from B, hosted in Azure VM.
Since we are more-or-less entrenched in .NET stack, we implemented B as SignalR server with C being the SignalR client. This part seems to work well.
Now comes a point where we also want A to subscribe to B, but I realize that it means an ASP.NET Web Server is going to act as SignalR CLIENT, instead of the typical scenario where it acts as SignalR server.
I presume we can initialize the SignalR connection in Global.asax and make the process ever-running to avoid AppDomain recycle. However, I feel a bit iffy when a Web Server is made to do something other than serving web requests. This solution also make the web server not stateless since it needs to maintain the web socket connection alive.
Is there something fundamentally wrong with making an ASP.NET application a SignalR client? Is there any possible gotcha with this setup?
In Azure you cannot tell that your AppDomain will not recycle. Because of many reasons, it can restart itself to heal and then you will end up making a new connection to the SingleR server. Is that OK for you?
Also SingleR is mostly used in the Web Functionality improvement where polling and refresh on web clients is made simple. But as your requirement seems to be all a back end stuff, I would suggest you to go with any other event driven pattern. Check Azure Service Bus topic/subscription model to have different components listen to various events and act accordingly.
Related
I am hosting a handler inside of a IIS web application. Is this a good solution ? Or Should I Hosting a handler in windows service application ? Which solution is better? What is recommended and what is more performance ?
I use SqlTransport in my configuration.
There are many factors that can effect how you choose to host your endpoint(s). For example
How you want to scale your site / handlers
What permissions can be granted to your web site process
How an IIS reset can effect your handling code
But in general... Host the bus in both the Web Application and a Windows service.
The web application handles incoming http requests, translates those requests to messages and places them on the bus via a Send.
The Windows service takes message off the bus and does the actual handling/business processing.
Some useful links that may guide you to the best solution for you circumstance
Hosting documentation http://docs.particular.net/nservicebus/hosting/ which contains some information on hosting in a web application
Windows Service Hosting http://docs.particular.net/nservicebus/hosting/windows-service
A showcase sample that uses a similar design as i described above http://docs.particular.net/samples/show-case/on-premise/
Web related samples http://docs.particular.net/samples/web/
Implications of Publishing from Web Applications http://docs.particular.net/nservicebus/hosting/publishing-from-web-applications
If you need to send messages from your web application then the only solution is to host NServiceBus in IIS, With IIS you shouldn't be publishing events from IIS.
Take a look here for more details
HTH
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
Suppose I have 3 applications -
WebApp 1 - a NancyFX app that serves html pages. there's also a SignalR hub for messaging communications between the users of that app. (and sends messages to WebApp2 sometimes)
WebApp 2 - a NancyFX app that serves html pages. there's a SignalR hub to that receives messages from WebApp 1 and updates the users of WebApp 2.
WebApp3 - a self hosted WebAPI that doesn't have a SignalR hub, but sends messages to WebApp2 in order to update it's connected clients.
So my question - is keeping two hubs in WebApp2 and WebApp1 the way to go, or should I have a (scalable) dedicated SignalR server which hosts the hubs of WebApp2 and WebApp1 to facilitate communications?
Thanks..
Tough to say what's best for you, since we have no details about your load requirements or how authentication/authorization works in your application. However, I'll say this:
Your scenario could be viewed as similar to a more typical SignalR scale-out situation, where you have a single application deployed to a web farm behind a load-balancer. In this scenario, you use SignalR's scaleout ("backplane") feature for server-to-server communication so that outgoing messages reach clients no matter which server they happen to be connected to. Your situation is really no different, except you have three different applications in play. As long as all three of your applications are hosting the same hub class (via a shared hub assembly) and are connected to the same scaleout backplane, it ought to work fine.
I have a use case where we will have an ASP.NET MVC Server Application but it needs to talk over a persistent connection to a Windows service. It doesn't look like SignalR does this as it really wants talk Server to JavaScript browsers but I did notice .NET desktop libraries. Can it talk from a server to a Windows server? If not, is there a recommended way, TCP/IP or HTTP to have a persistent connection between the two? NetTcpBinding in WCF?
Yes, there is a SignalR client library for .NET that you can use in any old .NET app to talk to a SignalR server just like you can from JavaScript.
While there is a WebSockets binding for WCF, there is no binding that actually talks native SignalR which adds its own message framing on top of raw web sockets. So, while possible, it doesn't exist today and I wouldn't hold my breath for it ever being created.
Why not simply have a queue using RabbitMQ. And anytime the web need to talk to window service, it push a message into the queue while the window service listen to the queue
I'm sure that was a confusing enough title.
I have a long running Windows service dealing with things happening in the world. This service is my canonical source of truth for the rest of my system. Now I want to slap a web interface onto this so the clients can see what is actually going on. At first this would simply be a MVC5 application with some Web API stuff. Then I plan to use SignalR 2.0 and Ember.js to make this application more interactive and "realtime".
The client communicates with the Windows Service over named pipes using WCF. A client (such as a web app) could request an instance of for example IEventService, would be given a WCF proxy client, and could read about events through this interface. Simple enough.
However, a web application basically just exists in the sense that it responds to requests from the user. The way I understand it, this is not the optimal environment for a long lived WCF client proxy to raise events in, and thus I wonder how to host my SignalR stuff. Keep in mind that a user would log in to the MVC5 site, but through the magic of SignalR, they will keep interacting with the service without necessarily making further requests to the website.
The way I see it, there are two options:
1) Host SignalR stuff as part of the web app. Find a way to keep it "long-running" while it has active clients, so that it can react to events on the WCF client proxy by passing information out to the connected web users.
2) Host SignalR stuff as part of my Windows service. This is already long-running, but I know nada about OWIN and what this would mean for my project. Also the SignalR client will have to connect to a different port than where the web app was served from, I assume.
Any advice on which is the right direction to go in? Keep in mind that in extreme cases, a web user would log in when they get to work in the morning, and only have signalr traffic going back and forth (i.e. no web requests) for a full work day, before logging out. I need them to keep up with realtime events all that time.
Any takers? :)
The benefit of self-hosting as part of your Windows service is that you can integrate the calls to clients directly with your existing code and events. If you host the SignalR server separately, you'd have another layer of communication between your service and the SignalR server.
If you've already decided on using WCF named pipes for that, then it probably won't make a difference whether you self-host or host in IIS (as long as it's on the same machine). The SignalR server itself is always "long-running" in the sense that as long as a client is connected, it will receive updates. It doesn't require manual requests from the user.
In any case, you'll probably need a web server to serve the HTML, scripts and images.
Having clients connected for a day shouldn't be a problem either way, as far as I can see.