Is this possible? trying to look for examples that show a message being published by the server and having multiple clients subscribed to those messages
Technically, you could probably build a message transport over WCF with the NetTcpBinding, but you really don't want to. I wouldn't want to try.
It would be very difficult to replicate transactional message sending, store-and-forward, and the receive once and only once semantics that is baked right in to MSMQ.
Related
I am building a system using microservices architecture, using RabbitMQ as the messaging service.
I have a use cases of communication between 2 services and face the difficulties of using RabbitMQ to implement it.
Cart-Service needs to get data from Product-Service. In this case Cart-Service can send a message, Product-Service subscribes to that message. But I find no way for Product-Service to send back the data to Cart-Service.
May you let me know whether my approach of using RabbitMQ in this case is correct?
Any other approach I should apply in this use case?
Thank you in advance.
Use an event-driven naming convention for your rabbitMQ message routes. The format can be <service>.<entity>.<action>, e.g. "cart.item.added".
Cart service subscribes to product.*.* messages, Product service - to the cart.*.* ones.
The workflow might be the following:
cart: publishes "cart.item.added" message.
product: receives "cart.item.added" message, publishes "product.product.read" one
cart: receives "product.product.read" message with the product info.
If you're using Node.js for the microservices, you could read more on how to prototype RabbitMQ message exchange here:
https://medium.com/#krawa76/bootstrap-node-js-microservice-stack-4a348db38e51
I'm aware of that there are a couple of posts here on SO that discusses this issue, but I can't figure out a straight answer to my scenario.
Lets say i have:
One queue on Server-A with alot of messages coming in
One WCF service with NetMsmq binding on Server-B reading from Server-A's queue
The very same WCF Service deployed to another Server-C with the same binding reading from Server-A's queue
Am I guaranteed that the services on Server-B and Server-C will never process the same message?
Are there any other problems with this setup that needs to be taken care of?
The purpose of this setup with multiple wcf services reading from the same queue is to increase processing speed, and I do not want to use a hardware loadbalancer.
Thanks for your time!
You will need to make your queue transactional and then set the exactlyOnce property on the binding to true.
Reference:
http://msdn.microsoft.com/en-us/library/system.servicemodel.msmqbindingbase.exactlyonce(v=vs.110).aspx
This should take care of it. You can have multiple readers (WCF Services) reading from the same queue. That's basically a load-levelling concept and is the intent of queue-based messaging. Here is some background documentation on WCF and MSMQ.
http://msdn.microsoft.com/en-us/library/ms789048(v=vs.110).aspx
My team are looking for ways to separate the various components of our system to decoupled services. What we'd like to achieve is an event-driven pattern where services subscribe to receive information sent when events occur in other systems.
Since we're already using WCF for our request-reply messaging, we'd like to continue using it for this particular pattern. Ideally, the messages would be managed via MSMQ to enable us to use reliable messaging to give us fault tolerance in the event of a service failure.
We're not looking for anything complicated like transactional support across service boundaries. Really, we just need a simple subscription-based message dispatch system. Are there any simple frameworks or services which can help us work to this pattern?
Probably the easiest is NServiceBus (http://www.nservicebus.com/PubSub.aspx) but this does not use WCF.
However from a integration perspective sending and receiving messages is far simpler than the messaging semantics on web services, so you don't need WCF to abstract that away.
Edit: In order to enable this using NetMsmqBinding you will have to implement the subscription infrastructure yourself. It would also be fairly easy to do.
Your publisher would need to have a database to store the subscriptions. When your subscribers start up, the first thing they do is send a subscription message to the publisher, who logs the subscription in it's subscription db.
The subscription messages should contain:
The message types I am interested in
My queue address
Then when your publisher wants to publish a message it retrieves the subscriptions and evaluates each one to see if the message matches the subscription and to retrieve the address to send to. Then it just sends the messages.
This is a standard pattern for implementing pub sub.
Is there a way to intercept the raw data that's being sent over a TCP WCF endpoint? I have implemented IClientMessageInspector but I am not sure if that's what's actually being sent over the wire.
My goal is to measure the performance of different serializers. I know there is some information out there but I would like to take a closer look at how they behave in my app.
Enable Message Logging in your configuration. To see the raw messag you want to log at Transport level.
You probably want to look into the built-in tracing capabilities of WCF. I don't have a link handy, but search for WCF tracing.
I have a system that sends a object to another service via WCF using MSMQ. The service picks the message up fine and does what it have to with it. But the problem i have now is that i need to send a response to the calling system.
Example:
Create a Customer object
Populate the information
Send the message to the service using WCF over MSMQ
Pick the message up from the queue using a windows service
Call Customer.Insert() method on the windows service
I now need to send the new customer id back to the calling application here.
Any ideas?
As Emmanuel points out - MSMQ messages are by design one-way and have no response, really.
Your best solution would be to have a response queue where the "other service" can drop his response messages into. Your client would then have to monitor that queue, e.g. check it once in a while (every minute, every 30 minutes - whatever makes sense for you) for new messages, and handle those.
There's no duplex (two-way) MSMQ channels - but you can easily create a pair of separate queues for both directions.
Marc
you can use duplex communication with msmq but not natively, take a look to my article
MSMQ Operation needs to one way, the only way I can think of receiving back a message is for your calling application to also Host a service for responses since there's no duplex MSMQ binding.