I wonder is nservicebus pub/sub or other type of app can handle db client to msmq server.
For example I have a desktop client app. using db queue and i want to send message to server using msmq message queue.
Thanks
Take a look at this article about interop with SQL Server: http://andreasohlund.net/2010/09/03/event-based-interop-with-service-broker/. There exists an Oracle AQS transport as well if you are using Oracle.
The article describes how to setup a bridge between the DB queue and MSMQ.
Related
We are working towards an architecture like one below but we will have micro services on cloud and some on premises which will talk to each other using queue(s) and bus(es),
Now I am confused with where we should host MassTransit and RabbitMq, also should it be a ASP.NET Core project on its own ? if yes what I will be doing in it ? starting a bus ? creating queues ? I am not able to move forward with this
The simple MassTransit examples are just that, the absolute simplest examples of interacting with queues.
RabbitMQ is your message broker. It is hosted separately.
MassTransit is a development framework that makes it much easier to interact with RabbitMQ (or Azure Service Bus) by abstracting away the implementation-specific "plumbing."
You write any number of .NET services that either publish messages to a queue, or subscribe to queues.
We recently worked on something similar, the way we did it is:
RabbitMQ was hosted separately, and buses/queues creation and management were done from the services that use messaging.
For each service that receives messages you use Maastransit to create a queue because service will be receiving messages using this queue.
You will be using publish/subscribe way of messaging so as mentioned above, inside each service, create a queue with logical name and connect to RabbitMQ server address.
Services that represent senders will publish messages of a custom type you create, and services that represent receivers will subscribe to this type of messages by having a consumer for this type registered inside the bus created.
Hope it helps.
I went thought NServiceBus documentation including the durable messaging one. What I understand is that when the server is offline the messages continue to go into the server's input queue which get picked up when server comes back online.
But what if the server is completely down and the input queue is not accessible?
I'm using Bus.Send from the client.
It depends on what transport you're using.
In the case of a brokered message queue, like Azure Service Bus, as long as that service is available, the fact the machine that will eventually retrieve the messages is offline is irrelevant, as that machine is simply asking the external queuing service for messages. The same goes for a transport like SQL Server.
In the case of a transport like MSMQ, which is a store a forward style queue, the messages will remain in a local outgoing queue until the remote machine becomes available.
Can you double check that you are looking in the correct spot? If you aren't getting an error out of NServiceBus when you Send, then MSMQ is installed. If it can't be reached or the service is stopped you should get errors.
The Outbound queues are in a different place as illustrated here:
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-components-postattachments/00-09-06-31-16/outgoingempty.JPG
As RMD indicated, this is an advantage of the store and forward MSMQ transport.. the local outbound queue should just stack these up until the remote server is available.
Thx.
Joe
Hi Everyone,
I have just started working with SQL service broker. I was wondering if we can link two service broker queues to same service such that when a message is sent using that service, it will be delivered to both queues i.e both the queues will contain same copy of a message. Is there any way like this or there is some other way to do this?
Thanks in advance
Pankaj
No, in SQL 2008, service broker only supports DIALOG conversations, not MONOLOG, meaning there can be only one endpoint.
I have a lot of client programs and one service.
This Client programs communicate with the server with http channel with WCF.
The clients have dynamic IP.
They are online 24h/day.
I need the following:
The server should notify all the clients in 3 min interval. If the client is new (started in the moment), is should notify it immediately.
But because the clients have dynamic IP and they are working 24h/day and sometimes the connection is unstable, is it good idea to use wcf duplex?
What happens when the connection goes down? Will it automatically recover?
Is is good idea to use remote MSMQ for this type of notification ?
Regards,
WCF duplex is very resource hungry and per rule of thumb you should not use more than 10. There is a lot of overhead involved with duplex channels. Also there is not auto-recover.
If you know the interval of 3 minutes and you want the client to get information when it starts why not let the client poll the information from the server?
When the connection goes down the callback will throw an exception and the channel will close.
I am not sure MSMQ will work for you unless each client will create an MSMQ queue for you and you push messages to each one of them. Again with an unreliable connection it will not help. I don't think you can "push" the data if you loose the connection to a client, client goes off-line or changes an IP without notifying your system.
I have a scenario where I need a desktop console app to communicate with a Windows Azure Queue... the most important thing is that the message is received by the server eventually. Also, the desktop app may be disconnected from the Internet sometimes. In the traditional WCF+MSMQ approach you'd be able to send a message which would be cached in MSMQ until MSMQ could reach the Server's MSMQ and send the message. What's the equivalent when Windows Azure is the server-side?
Is it possible for the same approach to be used, where MSMQ just communicates with a Windows Azure Queue rather than an MSMQ on a Windows Server?
Maybe Windows Azure Queue is the wrong approach? I have heard about something called message buffer, but don't know what this is (yet!).
thanks for your help
Kris
You could write an MSMQ listener service that finishes moving the message to the Azure queue when the connection to the internet has been reestablished. I don't think this would be too difficult.
Update
Perhaps my answer wasnt clear. Based on the question the client is occasionally connected to the internet so you need a way to park the message until the intertubes get untangled. Using Windows the easiest way to do this is to put the message in an MSMQ local queue. YOu then have a service monitoring that queue. If there is a message and it can get to the service hosted in the cloud it sends the message. Once the message has been sent it can be deleted from the queue.
In order to queue a message to Azure Queue Storage you have to be connected to the Internet. If you want to handle disconnected scenarios, that is totally up to you. I would keep the solution very simple and use a local storage such as SQL Server Compact and then send the messages as soon as there's connectivity, maybe with the aid of a Windows Service (so that you don't need to run the desktop app).
You can do this with the Azure AppFabric Service Bus Message Buffers - there is no need to use a Queue. Check out the related sample downloads on the following site: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 - they should answer your questions much better than I can.
Regards