I have been going through the NServiceBus samples, one point which is not clear to me is the cardinality of NserviceBus Host to Endpoint. Is the relationship 1 NServiceBusHost to 1 Endpoint? What does this look like in production? 1 Windows Service per 1 Endpoint?
Thanks In Advance
We have 3 main actors the NServiceBus.Host that is the physical host that allows an Endpoint, more to come, to be hosted as a Windows Service on a Windows machine. So there is a 1:1 relation between a NServiceBus.Host and a Windows Service.
One host can, starting with V5, host multiple endpoints instances (we can have more than one bus per service listening to different Qs) where an endpoint instance is the physical deployment of an endpoint that is a logical definition that owns a set of message types.
So in production we can 1 service, that monitors 1 queue that hosts 1 endpoint. But you can also have multiple endpoints in the same service even if by default the on-premises NSB.host does not support that out-of-the-box. On the other hand we support it out-of-the-box on Azure where we have a dynamic host that allows more than 1 instance per host while keeping the instances isolated in different processes.
cross answered: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/particularsoftware/7zOHHOOqDi4/I4p2TbvFGc0J
Related
I am looking in for the best way to implement the RabbitMQ consumer by using .Net Client which should be run as windows service.
I referred the RabbitMQ documentation and found the way to consume messages by using .Net client (https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html).
My current scenario is like, RabbitMQ is installed in AWS VM machine. I have to install dotnet client consumer service resides in On-premise network which should consume messages.
Which one is the best way, to always listen the Queue (AMQP protocol) or HTTP API which should get messages on demand (https://pulse.mozilla.org/api/).
Please advise.
Thanks,
Vinoth
I believe the answer is "neither." You should have your message queue as a back-end service behind the firewall, and expose your application functionality through a set of carefully-specified web services. The web services, which are exposed through the firewall but can communicate to services behind the firewall, would produce messages that would be transmitted to the server. Any services needing to produce or consume messages would need to do so via the web services, which would perform safety/security checking prior to forwarding the request on to the AMQP server.
If you need to expose AMQP directly to clients (i.e. that is the purpose of your app), then the recommendation is to do so via STOMP. I think a valid use case for exposing AMQP directly over the internet would be a rare thing to come across. The security implications of doing so would be immense.
Currently we have 2 load balanced web servers. We are just starting to expose some functionality over NSB. If I create two "app" servers would I create a cluster between all 4 servers? Or should I create 2 clusters?
i.e.
Cluster1: Web Server A, App Server A
Cluster2: Web Server B, App Server B
Seems like if it is one cluster, how do I keep a published message from being handled by the same logical subscriber more than once if that subscriber is deployed to both app server A and B?
Is the only reason I would put RabbitMQ on the web servers for message durability (assuming I didn't have any of the app services running on the web server as well)? In that case my assumption is that I am then using the cluster mirroring to get the message to the app server. Is this correct?
Endpoints vs Servers
NServiceBus uses the concept of endpoints. An endpoint is related to a queue on which it receives messages. If this endpoint is scaled out for either high availability or performance then you still have one queue (with RabbitMQ). So if you would have an instance running on server A and B they both (with RabbitMQ) get their messages from the same queue.
I wouldn't think in app servers but think in endpoints and their non functional requirements in regards to deployment, availability and performance.
Availability vs Performance vs Deployment
It is not required to host all endpoints on server A and B. You can also run service X and Y on server A and services U and V on server B. You then scale out for performance but not for availability but availability is already less of an issue because of the async nature of messaging. This can make deployment easier.
Pubsub vs Request Response
If the same logical endpoint has multiple instances deployed then it should not matter which instance processes an event. If it is then it probably isn't pub sub but async request / response. This is handled by NServiceBus by creating a queue for each instance (with RabbitMQ) on where the response can be received if that response requires affinity to requesting instance.
Topology
You have:
Load balanced web farm cluster
Load balanced RabbitMQ cluster
NServiceBus Endpoints
High available multiple instances on different machines
Spreading endpoints on various machines ( could even be a machine per endpoint)
A combination of both
Infrastructure
You could choose to run the RabbitMQ cluster on the same infrastructure as your web farm or do it separate. It depends on your requirements and available resources. If the web farm and rabbit cluster are separate then you can more easily scale out independently.
My management is evaluating non-Azure Microsoft Windows Service Bus (Azure is out of consideration for security reasons). It will be used to setup topic/subscription model with a number of WCF services with netMessagingBinding that we building, so I just have a few basic questions about that.
Are there any specific hardware requirements like dedicated server, dedicated database etc. for WSB to run in production environment?
It's easy to configure WCF service to listen on a specific topic subscription. Is there any way for WCF service to listen to multiple subscriptions?
Appreciate the answers.
You can install the service components and the databases all on one server (that is the default). However, for a number of reasons, we installed the services on a dedicated app server and then created the Service bus databases on an existing database server. The install package allows you to specify a different db server. Check this article for the minimum server requirements
Yes you can get one WCF service to listen to multiple subscriptions. You would need to create two (or more) System.ServiceModel.ServiceHost instances and then run them inside one process. For example we had one windows service running two ServiceHost's. Each host listened at a different queue and therefore implemented a different contract. This meant where queues were logically grouped we didn't need a new windows service per queue. You could do the same with subscriptions.
For question one, you will have to go through the exercise of hardware sizing. the good news is that WCF services can scale vertically, so you can add up servers if there were issues in handling client load.
To do hardware sizing you will have to make an estimate the expected load and then do performance/scalablity testing to figure the load bearing capacity of your serviceBus/services .
you could find a lot of resources for load testing like this one http://seroter.wordpress.com/2011/10/27/testing-out-the-new-appfabric-service-bus-relay-load-balancing/
once you do load testing and come up with the numbers, you can then do sizing using references like this one http://msdn.microsoft.com/en-us/library/bb310550.aspx
i can't find any good architecture explanation of how can WCF SHOULD be part of a main-server with multiple clients.
in my solution, i want to have a central WCF service (hosted in windows-service on windows server machine).
The central service is the only one that's connected to the DB.
all the clients, are connecting to this main service, login, and get having a duplex communication.
via that main service, one client can connect another one. or when one client using the main service to change the DB, the main service updates all other clients.
for doing that, i added in the main service the InstanceContextMode.Single attribute, and in the windows-service, i init ServiceHost with the WCF-service singleton.
it works. so so..
i can continue and search where the problems are, and how to fix them, but it looks like something here is not right, like i'm not supposed to do it this way.
i could really use an advice on how WCF service should be used as a main service with multiple clients, that require common memory.
it's basically for ~20 clients with not too intensive operations, but i still want the option to let them all communicate simultaneously with the main service, and not only one by one.
In my application I need to push notifications of real time events from server to clients. The amount of data to pass is very small, mostly and Id. The number of clients listening simultaneously can be around 100 and I may have to publish one notification every 2 - 3 seconds. Both the server and client are built using .Net and WCF.
Given these requirements I have built a set of WCF services which will be run on a load balanced server cluster. The Instance context mode is Per Call and there is no need for sessions etc.
I am currently using BasicHttpBinding. Will TCP binding be better? Does it run on IIS 5 or 6? If not why?
What configuration for serialization can work best?
What are the things I need to do to make sure I get maximum performance?
Edit - Adding more information based on some of the responses -
I host a small WCF service in the client process using manual hosting. The server just calls this service on each client to push the data to all of them.
Firstly have you considered using messaging for what you are trying to achieve?
In answer to will TCP binding work better than BasicHttpBinding- almost certainly yes. If you want to use TCP, you can't use IIS- look into WAS with Windows Server 2008. If you're stuck with Windows Server 2003, then you'll have to host in a windows service instead.
You've made a good choice by choosing per call- this is the preferred instance management mode for creating scalable WCF services.
Edit:
Now you've update your question, I recommend you take a look at IDesign's Pub/Sub framework if you want to stick with WCF. I'd also look at Pub/Sub with MSMQ in WCF and also with "Vanilla" products such as Tibco RV.
If you need pushing data from service to clients you need sessions and you need duplex binding - NetTcpBinding or WSDualHttpBinding. It will not work with BasicHttpBinding because it allows only pulling data (client pools the service for changes). Push data means tha service sends data to clients when needed.
NetTcpBinding always crete session. It can't be hosted in IIS 6 or older. NetTcpBinding is allowed only in Windows Activation Service (WAS) which is extension of IIS 7.x. For older systems you need self hosting = windows service.
Edit:
Based on your description you need Publish-Subscribe message exchange pattern.