NServiceBus design help (Initializing a service instance with messages)

I'm looking for an alternative design or maybe a workaround this issue I've encountered with MSMQ messaging. Right now I'm using NServiceBus (not the problem) for my service architecture. It works really well and I like it a lot. However, I'm having some trouble with services that I want to initialized at start up before processing the normal workload messages. Let me explain my situation.

Let's say I have 2 services, Data Access (DA), and a Processing Engine (PE).

The PE performs 2 tasks:

1. Load some configuration information from the DA.
2. Process incoming client requests.

The problem is that because of the configuration. I cannot guarantee after the service starts up that the first messages it receives are the configuration messages. I know that you ca开发者_开发百科n purge all the messages from the queue at start up but I don't want to do this because I need to process all the messages. Secondly, even if I purge all the messages in the queue there is still no guarantee that the configuration will load first, in fact due to the high volume of messages this service is processing it's highly unlikely to be the first message received.

My question to you guys is what have you done in the past to get around these types of issues with the message based architectures. I've created the cardinal sin here and assumed that the messages will arrive in some kind of order, which couldn't be further from the truth.

You can use two different queues. One for the workload. And the second for the configuration (or metadata). Other option is using priorities. You can set higher priority on configuration messages so they will be read first.

That said, I don't understand your architecture at all. How will the DA service know that the PE has restarted. It needs to know that in order to send configuration messages.

You should really consider loading the configuration in each service that requires it. As for workarounds, you could send a request message to the other endpoint for the configuration and then keep calling Bus.HandleCurrentMessageLater() until you get the correlated reply back. This would not be optimal as the non-configuration messages would build up in the queue until the configuration occurred.

each and every service should be responsible for his own data. so your processing engine should know the exact configuration options it needs to know to work properly. it seems that you are mixing up some things and have a service that uses 2 windows services where one service is dependent on another service.

usually your processing engine would have a direct database access for something that it operates on. if there are configuration settings that are configured from within another service your processing engine would store that configuration options and would offer interfaces to update that configuration options. so if your processing engine is online your client requests can be handled regardless if your database access process works or not. if the database access process comes online and detects configuration changes it would inform all dependent processes of the configuration changes.

i would recommend to reconsider your architecture.

Have you looked at the distributor? Also look at ICustomConfigurationSource you can use it to retrieve endpoint config when windows service starts (before it starts processing messages)