CODEWITHSUNDEEP
c#.net
Calvin
Calvin

Reputation: 68

nServiceBus used with sockets

I am fixing a .net app written on top of nServiceBus and have a few questions:

  1. The app is configured AsA_Publisher and when it starts it waits for incoming connections on a socket, do you know why it might have been implemented like so? Why sockets? This socket is created during the Run method of a class which implements class IWantToRunAtStartup.

  2. Once a message arrives, the message is written to a queue (Q1). The message is then read from the queue(Q1). The format of the message is changed and then inserted into yet another queue (Q2). The message is then read from the queue (Q2) and sent to another application by calling a web service. The whole idea is to change the message format and send it off to the final destination. If nServiceBus is built on top of MSMQ, then why is the application creating more queues and managing them?

  3. I see absolutely nothing about Publish or Subscribe anywhere in the project. I guess it is relying on the socket to receive messages and if so then it is not really taking advantage of nServiceBus's queuing facility? Or am I lost...

If queues are needed and if I was to build this I will have one app writing to the queue (Q1), another app reading from the queue (Q1) and changing the format and inserting to another queue (Q2) and finally a third app reading from the (Q2) and sending it off to the web service. What do you think?

Thanks,

Upvotes: 1

Views: 234

Answers (1)

mookid8000
mookid8000

Reputation: 18628

I see nothing wrong with opening a socket in Run in an IWantToRunAtStartup. It must somehow be required that the service can be reached through some custom protocol implemented on top of sockets.

Processing the incoming socket messages by immediately bus.Sending a message is also the way to go - the greatest degree of reliability is achieved by immediately doing the safest thing possible: sending a durable message.

Performing the message translation in a handler and bus.Sending the result in another message is ALSO the way to go - especially if the translation is somehow expensive and it makes sense to be able to pick up processing at this point if e.g. the web service call fails.

Making a web service call in a message handler is also be the way to go - especially if the web service call is idempotent, so it doesn't break anything if the message ever gets retried.

In other words, it sounds like the service correctly bridges a socket-based interface to a web service-based interface.

It sounds weird, however, that the service employs multiple queues to achieve this. With NServiceBus it would be entirely sufficient with one single queue: the service's input queue.

Upvotes: 1

Related Questions