I would be grateful for some design suggestions concernig a windows service (c#) for publishing reports to a SOAP service.
It fetches a limited set of reports from a database (reports in Oracle AQ table), aggregates them into a message and forwards this message to a WCF SOAP service. Reports are marked as "sent" if they have been transmitted via SOAP successfully. Otherwise they are added again to the AQ table (via a db job).
So I came up with following designs. What would be the best way to go? Would the queue improve the design in terms of scalability, robustness, decoupling? Is it a good idea to use queuing in this case?
Proposed design A: Service with 1 to N threads. Each thread processes reports synchronously (fetching reports, aggregating, translating, sending via SOAP)
Proposed design B: Windows service with:
- 1 MSMQ message queue
- 1 to N Producer threads: (fetching reports, aggregating, enqueuing message via MSMQ)
- 1 to N Consumer threads: (dequeuing, translating, dipatching via SOAP)
Proposed design C:
- Windows service with producer threads (fetching reports, aggregating, enqueuing messages to a private MSMQ queue via WCF NetMsmqBinding Client)
- IIS/WAS hosted MSMQ-enabled service (listens to the MSMQ queue, dequeuing, translating, dipatching via SOAP)