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
Related
Lets say that I have multiple internal ASP.NET web api applications. i.e.
http://service1.something.com/bob/bill
http://service2.something.com/pete
http://service3.something.com/dancing/dragon
I would like to expose these different services under a common host name
http://something.com/service1/bob/bill
http://something.com/service2/pete
http://something.com/service3/dancing/dragon
The reason I'm thinking of this setup is to allow each service to run a different set of middleware, but give the client a uniform URL structure to use. Each service can then be upgraded indepently of the others.
Ideally this should be using the latest version of ASP.NET and potentially hosted on Service Fabric. It doesn't have to run on the new core stack, the full .NET framework is acceptable.
I've read that the WebListener supports port sharing, so that is something I'm considering.
Suggestions?
Yes, you can do this with ASP.NET applications in Service Fabric:
service 1: http://something.com/service1/bob/bill
service 2: http://something.com/service2/pete
service 3: http://something.com/service3/dancing/dragon
As long as you use a web stack that supports port sharing. On windows, that means using a web stack that uses the http.sys kernel driver. Here are the web hosting options currently available for ASP.NET on Service Fabric:
The WebListener host in ASP.NET Core 1 is based on HttpListener which uses http.sys, so that will work.
Kestrel in ASP.NET Core 1 is not based on http.sys and to my knowledge does not support port sharing, so that won't work.
Katana uses HttpListener so that will also work.
Even in Azure Fabric every service should have different port - port sharing is available for service replicas (statefull) or multiple instances of the same service (stateless).
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-service-manifest-resources/
Common way to have uniform URL structure is to create Api Gateway, which will call other services.
http://microservices.io/patterns/apigateway.html
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!
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.
I have a web application and on that application i update a sql database ...what i want is that when i update the database from the web application a notification will be sent to any one openening my application or a pop up appears to them on their desktop informing them that the database is updated to check all this will be in an intranet.
I'm using ASP.Net and I'm the admin for all the PCs in the network and the server.
Does anyone knows how i can do this ?
Build a desktop application that polls the database regularly or better write a HTTP/REST service where desktop application poll frequently.
What you need is a WCF duplex service your website and your windows clients connect to. With such a service you can use callback methods to inform your windows clients through the service. But be aware that this is normally an intranet and not an internet scenario because such an wcf binding has problems with internet infrastructure (Proxies, Firewalls, ...)
I have a situation very similar to the one in this question:
Selective Cache clearing across load balanced servers (ASP.Net)
The difference is that due to our hosting configuration, I am unable to address individual servers by IP address. Assuming I cannot access specific servers via web requests, is it possible to access the HttpContext of a web application running on the same machine? I'm thinking I could accomplish this with a windows service that I could address by machine name, or alternately a console application, I just don't know if I can gain access to the web application cache either way.
You can expose content of the WebCache of an app through some Remoting/WCF code built into the web app. I hope you can use localhost to access it from an app on the same box.