First off, I’m really new to all this messaging stuff, so please excuse what might be a dumb question!
We have a WPF application, used by people all over the world, and data is accessed via WCF services. We want to allow the server to inform the client when data has changed (eg, user Jim modifies a customer, we want everyone else to know about the change).
I was looking at the publish/subscribe demo, as that looks to be what we want. In our case, when a WCF service call was made, the server could publish a message, and the WPF apps that subscribed to it would pick it up.
We would be interested in doing this using NServiceBus on top of MSMQ.
My main question is, does this require MSMQ to be installed on the client machine? Installing it on the server is no problem, but I can’t imagine how we’re going to get it installed on all the client machines.
If it does have to be installed, is there any other way of having the clients pick up the messages?
Thanks for reaching out. First of all I don’t believe there are dumb questions. It is great that you reach out when you have questions and we are here to help.
So if you are using MSMQ then MSMQ has to be installed on the client machines as well as on the server machines and it has to be possible to access MSMQ ports. This is mostly OK if the clients and the servers are running in the same network. It can be a problem when clients need to run in a different network. Even if you are running the clients in a DMZ then the MSMQ resources and ports need to be reachable between the DMZ and the intranet. Can you elaborate a bit more your client / server deployment scenario so that we can help you go into the right directions?
I’m also happy to hop on a call to better understand what sort of problem domain we are talking about. Feel free to reach out to me at daniel dot marbach at particular dot net
First I must warn you that I’m no expert in networking and so on. I’m a software developer, but tend to leave the nitty gritty network stuff to the experts!
We have a WPF desktop application, and that has references to the WCF services. The app can be installed on any Internet-conected PC, and does not require any specific network connection. It gets its data by making WCF service calls, and sends updated data back via WCF service calls.
We aren’t doing any messaging at all at the moment. I mentioned MSMQ as it looked like it might be the answer to our needs, especially when used with NServiceBus, as that looks like it takes a lot of the pain away.
Does that make it any clearer? Thanks again for the help.
If the WPF application is hosted on any internet-connected computer the MSQM is not an option. You can really establish a trusted connection with MSMQ in that scenario. MSMQ might be an option to implement the various backend system communications behind the scenes on your servers though depending on your needs
The WCF services that your WPF application is using are they publicly exposed or does the WPF application authorize to those services in any sort?
I do think this discussion would be better suited to take place in a call and then summarize it here. Please send me an email to daniel dot marbach at particular dot net and we’ll find a good spot in our calendars to talk this through.
For this kind of situation, I’d recommend cloud-based messaging infrastructure like Azure Service Bus or Amazon SQS - both of which are supported with NServiceBus.
Thanks for the suggestion. It looks like Azure Service Bus would fit the bill exactly. Our WCF services are housed in Azure already, so we are halfway there.
I just had a play with their sample, and had something up and running very quickly. I’m interested to see what NServiceBus adds on top!
Like Udi mentioned usually a cloud hosted transport is the best choice. If you are in Azure then either Azure Service Bus or Azure Storage Queues might be feasible. More more background information we have guidance that helps you select a transport Selecting a transport • NServiceBus • Particular Docs
Given that the WPF applications will need connection information to reach the transport of your choice you want to make sure you use at least SAS tokens for the services you use
Another option if you are in Azure is to use Azure SignalR services to create a channel between the backend and the WPF applications and then use NServiceBus for the backend parts to introduce reliability and temporarily decouple the API parts from the background processing logic. Within the handler code you can then access the signalr connection hub and push out notifications to the clients over the SignalR service.
Then you would keep the transport choice internal to your backend and WPF clients would only use SignalR websocket connection (which eases the transition to web clients in the future should you wish to migrate your WPF clients). For example SignalChat: WPF & SignalR Chat Application - CodeProject shows how to integrate SignalR with WPF