I'd like to make an informed choice towards a simple publish/subscribe architecture.
So I'm wondering: what does the Service Bus add that MSMQ can't do?
What are the drawbacks of the Service Bus?
Thx for enlightening me!
The main functional difference is Service Bus provides out of the box support for message exchange semantics such as topic based routing via publish-subscribe.
MSMQ on the other hand is a lightweight store-and-forward queuing system, which supports point-to-point one way messaging.
Service Bus:
depends on SQL Server, and
is a broker. This may be considered a drawback.
If you are looking at pub-sub frameworks then a popular one at the moment (free in single threaded mode) is NServiceBus, which sits on top of MSMQ, though has swap-able transport.
Pros
Service Bus allows you to publish over tcp and http which is cool, and gives you greater
decoupling.
Service Bus is a sql database so your Disaster Recovery is WAY simpler and a lot cheaper to implement.
Cons
Service Bus is centralised, and MSMQ is federated, so potentially more scalable. Although you can scale out with more nodes in WSB.
You need a live connection to the central bus before you can publish. So MSMQ being federated (on each machine) makes it more available to clients.
However people are using MSMQ as a local store with Service Bus, so publish locally, then push it over to the bus when a connection is available.
We are having a good experience with Service Bus instead of MSMQ at the moment.
Related
I have an ASP.NET MVC application hosted in Azure.
This application is complemented with a desktop application that also has WCF services for communicating with III party interfaces. WCF are hosted locally.
There are thousands of clients using the desktop application at different geographical locations.
Till now, every desktop application used to talk to web app using api with the help of WCF.
This was limited to on demand from the desktop application.
Whenever desktop application feels the need to talk to web app, it used the way of web api from WCF.
Now, what I want is:-
To access the different desktop applications(typically called sites), from azure depending upon the need.
This is required on account of an online ordering system that is through web app/mobile app.
I do not want to keep polling from desktop application to know about if any new order is there for this site.
I feel it would be better if I can play from other side.
Also, keeping in mind that IP of sites will not be fixed. There may be issue with firewall. NAT may translate resource identifier differently.
Can service bus in azure may be of any help, but what confuses me is that every desktop application is having its own WCF service and order should reach the respective site only.
Any type of ideas on this would be appreciated.
According to your description, Service Bus messaging is a perfect way to achieve this.
More information about Service Bus Messaging, we can refer to: Service Bus queues, topics, and subscriptions
In addition, We can also use RabbitMQ or ZeroMQ which is similar with Service Bus Messaging because both of them are free. You can choose an best way to realize your requirements.
About differences between ZeroMQ and RabbitMQ:
ZeroMQ has better performance, but it is built in the case of allowing message data loss to apply to high throughput / low latency applications. Unlike ZeroMQ, RabbitMQ fully implements the AMQP protocol, which is similar to mailbox services, supporting message persistence, transaction, congestion control, load balancing and so on, making RabbitMQ have a more extensive application scenario.
Function RabbitMQ ZeroMQ
Message persistence Support Not Support
Transaction Support Not Support
performance Low High
stability High Low
Support for AMQP protocol Support Not Support
Application scenario Data loss is not allowed High throughput
More information about RabbitMQ and ZeroMQ, we can refer to:
RabbitMQ
ZeroMQ
If you are able to modify the desktop applications, implementing a websockets connection with SignalR might be worth a look. The desktop applications sign up with a SignalR hub you provide.
You can then push data to the clients from, for example an ASP.NET MVC app. It works very reliable and handles lots of connections well. It is typically used for realtime web communication but might be useful in your case, too.
The downside is probably, that the desktop app needs to initially sign up to a hub to receive push messages.
We currently have a solution, using web services (implement via WCF) where client software periodically call a service to retrieve a list of new items waiting for them, then for each item, calls a separate service to do the actual download. This is the typical message polling scenario, and is relatively simple in implementation and trouble free. It does not give a near real time messaging solution however. For real time messaging you'd want more of a push notification architecture.
Because of security concerns we do not want clients to expose interfaces that our system can call because then each client needs to secure that exposed interface among other concerns.
Id like to explore the option of the client still initiating the connection to the server as we do today, but instead of polling, we maintain the connection and once the client has completed the connection, the server is now able to push messages to the client.
Our clients base may be implementing their solution on a variety of platforms, from Linux to Windows, .Net to PHP, etc. Additionally, clients vendors have a varying degree of technical capabilities so complexity of the solution is a factor here. Can SOAP or REST services be used in this type of architecture? Are there other technologies I should be looking at? Our server side part of the solution would need to be a .net one.
I have a client server setup where i am sending the messages to the server over http(I am using WCF service hosted as windows service.)In my current setup as I have seen some messages are lost when the connection is down between client and server ,for the sake of reliability i have decided to use MSMQ.So the client sends the messages to the queue and the server continuously polls the queue I need some design decision to be taken before i will developing.
Which one would be the best bet windows service or wcf service(hosted as windows service) ?
Are there any advantages apart from windows service which WCF has if i have to develop such a service where all it has to do is continuusly read messages from the queue and does some processing.I would be using a private queue which is transnactional .
I would suggest avoiding writing code that directly integrates with MSMQ and instead using an existing service bus to do that for you (like NServiceBus or MassTransit). Rolling-your-own messaging layer may work for the simplest of systems but as requirements change over time you will need a fuller featured service bus. The service buses that I mentioned do the following things in a developer friendly way:
Messaging patterns (fire-and-forget, request-response, publish subscribe)
Message serialization
Message routing
Failure/Retry logic (i.e. a message handler is supposed to update a database, but the database is down how do you handle this?)
Long running processes (also called sagas)
These are just a few of the things you will be writing before long if you go the roll-your-own route.
I need to build a system that is similar to a pub/sub system. It is composed of multiple sub-systems or services running in separate executables or as a Windows Services.
The sub-systems are:
The pub/sub service
A pub/sub service managing communications between the internal sub-systems and the users.
A user can have multiple channels open (A web page connected to a SignalR service, a mobile device connected to a duplex WCF service, etc.).
The service should manage all the channels of an user and be able to send information to them on demand based on topics or specific users.
The service must support multiple transports like SignalR, WCF, or others ...
Worker services
A worker that runs as a Windows Service and sends information to the users using the pub/sub service.
The SignalR and WCF host
The SignalR service and WCF service will be hosted on IIS
My questions are
As the sub-systems run in separate processes, how do I communicate between the pub/sub service and the other sub-systems like (the workers and IIS). The communication must be really fast. Do I use named-pipes, is it fast enough ?
An example; The worker tells the pub/sub system to send a message to a user, the pub/sub systems checks the channels opened for the user (let's say a SignalR channel), then in turn it must notify the SignalR service running in IIS to send the message to the user's browser.
Do you know of implementations of similar systems ?
Observations
I cannot use third-party service-bus services (Azure ..). And even with that .. I can't see a solutions to the problems above.
The service must be very scalable and high-demand proof.
If the question is how to bridge SignalR with other transports there are several solutions.
On a single server you could just connect them up with the Reactive framework's own pubsub mechanism which is neatly encapsulated in the Subject class.
If you need to scale out to multiple servers you'll want to use an existing service bus or perhaps roll your own simple one using SQL server and a SqlDependency.
You could also use SignalR as a client on one server communicating with the other servers to copy messages between them.
I recommend you look into some of the existing Service Bus technologies for .NET.
There is an article which clearly explains the possible mechanism of how to incorporate a pub/sub design pattern in your .NET application. The answer lies in using a .NET In-Memory distributed cache and use its clustering capabilities as a publish subscribe medium. Since it's clustered therefore you won't have to worry about down-times as well.
Basically you'll be using the Application Initiated Custom Events
Register your events
public void OnApplicationEvent(object notifId, object data)
{
...
}
_cache.CustomEvent += new CustomEventCallback(this.OnApplicationEvent);
And fire those events whenever you need to
_cache.RaiseCustomEvent("NotificationID", DateTime.Now);
Pub/Sub design pattern in a .NET distributed cache
Full disclosure: I work for Alachisoft
I haven't been able to find a clear answer to this problem. Is there a good way to subscribe to a MSMQ through the internet? Ideally I need security both in authentication and encryption for this connection. But I would like the subscriber to act just like any other client that would be subscribed on the local network. I believe I have a couple of options here
Expose the MSMQ ports publicly
Put the MSMQ behind some type of WCF service (not sure if that works for a subscriber)
What other options do I have? We're sitting in a .NET environment and the main problem domain that is trying to be solved is to change the remote connections from a pulling system to an event based system to reduce the load on the main server.
One way is to use a queue ON the Internet.
I work at Microsoft and my team owns MSMQ and we also own the Windows Azure Service Bus service. For the scenario you describe you may want to take a look at using a Service Bus Queue, which has not only the advantage of being reachable for Internet senders but also eliminates the need to create inbound firewall rules on the receive side.
More here: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-queues/
The most natural option will be to use MSMQ over http, which is a feature of MSMQ:
http://msdn.microsoft.com/en-us/magazine/cc164041.aspx
The alternative would be to create an http WCF service possibly with duplex polling and use WS-Routing to an MSMQ WCF service.
Checkout the Gateway feature of NServiceBus.