2

I have a fairly straightforward scatter-gather pattern implemented using an IIS-hosted web service (WCF) as both the request handler (broadcast) and aggregator.

Everything runs pretty smoothly using the standard NetMsmqBinding, one-way message contracts, and WAS. But now we want to introduce a business rule, whereby the aggregator will only wait a certain amount of time (probably a few days) for the final responses; if some or all of them are not received, it should close out the batch and publish whatever information it has. Normally it would only initiate a publish when all endpoints have reported.

I know that I can set message expirations on the broadcast messages so that the endpoints don't waste time doing unnecessary work, but what about triggering the early publish?

NServiceBus treats sagas as a first-class citizen, handling timeouts gracefully, and I know that BizTalk actually implements the entire scatter-gather as a single orchestration. But I don't want to have to deploy any new tools or services just for this one requirement.

Is there a way to implement a long-running batch timeout action using just WCF and MSMQ?

(Again - the aggregator is hosted in IIS, so I can't just set a timer; the app pool could be recycled or shut down at any time.)

Aaronaught
  • 120,909
  • 25
  • 266
  • 342

1 Answers1

0

You could implement your own, but you need to find a way to manage the timeouts for each instance of your requests, manage the state of each instance while it is waiting for the responses of each of the vendors, correlate the responses, and also introduce a pub/sub architecture to decouple the aggregator from the vendors in order so you can handle the events published by them.

In my opinion, this sounds like an awful lot of work and is exactly the type of thing that NServiceBus provides out of the box (and so much more). I would take another look at it. Businesses are always changing and saga's more common that we realise. It might be one requirement now, but that could change again soon.

SteveC
  • 15,808
  • 23
  • 102
  • 173
stephenl
  • 3,119
  • 4
  • 22
  • 22
  • This is... all already done. This is exactly how the scatter-gather works. There's no coupling between the aggregator and the vendors. All I need is the timeout. It doesn't need to be a per-request or per-instance timeout, just one for the whole batch. I assure you that I've taken a look at NServiceBus and use it wherever possible, but I can't retrofit an entire system with it in a couple of days. – Aaronaught Jul 28 '11 at 02:13
  • Fair enough. So I assume that the aggregator needs to know when the batch was sent in order to invoke the time out and publish returned results. Could you not send the aggregator a message with batch details and configure your time out mechanism and then have it publish when the period has elapsed? That way you could set different time out periods for each batch. The question is what do you use for a timeout mechanism? – stephenl Jul 28 '11 at 05:29
  • All of the request information is already tracked. The hard part is making sure that the aggregator (or some other web service - as long as it lives in the same IIS app it's fine) actually gets activated when the timeout has expired. That's why I mentioned a few times that I'm using IIS and WAS. It's easy to set a timeout, but that doesn't accomplish much if the app pool is recycled or shut down. – Aaronaught Jul 28 '11 at 14:15