1

We want to use NSB (NServiceBus) for our app development. We have a bunch (~6) of services that will get hooked into the NSB and where publish/subscribe pattern makes perfect sense. However, there is a configuration service also, where we need a simple request/reply (full duplex) pattern to get configuration data (settings, permissions, etc) from either a local DB a central remote DB server.

So the client would request the config data and immediately get a result back, which is illegal (according to the manual) when using the NSB with a pub/sub setup.

Is there a way to do this using NSB anyway,without losing the cool features such as SLR and fault tolerance, error queues, etc.? Or would I just have to circumvent the NSB altogether and create a simple WCF service instead?

Thank you.

John
  • 3,591
  • 8
  • 44
  • 72
  • "illegal (according to the manual)"? Care to share a link to that information? I'm very surprised because we run a setup where I work which combines point-to-point (one way + request/reply) and pub/sub and I've not had any problems with it. – Damien_The_Unbeliever Oct 14 '14 at 13:08
  • @Damien_The_Unbeliever if you say you are using both on the same bus I believe you. I can't find that specific paragraph in the doc right now. So you're saying when I use one bus, I can use it however I please -- Pub/Sub & Send/Replay, whatever? – John Oct 14 '14 at 13:16
  • As a general rule you should avoid queries across a service bus. Although it is possible it is probably going to hurt :) --- since a service bus is focused on being asynchronous your system should be happy to wait for responses and not have any expectation that they will arrive any time soon. If you *do* need synchronous response then go with something more direct (as Udi has mentioned). – Eben Roux Oct 15 '14 at 03:45

1 Answers1

3

Yes, you can use both publish/subscribe and full-duplex request/response messaging together in a given solution - that's fine.

All that being said, for the specific example that you gave, I'd model it differently.

I'd consider using a configuration component (rather than "service") which can be called in-process. This DLL would make the call to the database and really the only thing dealing with remote calls is whether the connection string points to the local machine or a remote one.

Udi Dahan
  • 11,932
  • 1
  • 27
  • 35
  • Thanks Udi! I'm not quite sure I follow that "component" model. I was hoping that with NSB there is no such thing as a remote connection string. Data would always flow from the caller (client machine) through the service bus and handled on the other side (=the remote machine, or maybe the local achine depending on the setup) where the database is local anyway. Or how would the configuration component otherwise benefit from the service bus? – John Oct 14 '14 at 15:26
  • The configuration component wouldn't use NServiceBus - just regular ADO.NET to access the database. Not everything is supposed to use NServiceBus :) – Udi Dahan Oct 14 '14 at 21:52