Home/ Questions/Q 635055
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T20:21:46+00:00

I’m building a .NET web service that will be consumed by a vendor’s application,

  • 0

I’m building a .NET web service that will be consumed by a vendor’s application, and I’m not sure how to accomplish the following:

  • The vendor will call my webserivce with some information, but wants an acknowledgement returned quickly, just stating that I received their info. They don’t care what I do with it, and don’t want acknowledgement that I’ve finished processing.
  • The info that I was passed needs to do something behind the scenes and act on the information in a time-sensitive manner – i.e., take some actions within a few minutes. I’ll be contacting a number of other web services, as well as doing some database work. Obviously, this will be after I’ve responded “Success” to the calling application.

I don’t have control over the way the vendor accesses my service, and the method they’re using to call it is synchronous, so I need to respond quickly to let the calling app continue its work. As I see it, there are two choices, though I’m open to others:

  1. Since the calling app is essentially submitting to a queue so that the process I’ve written can process it, I can have the web service just submit the item to the database (or an MSMQ or another queue) and then return success. The queue process will pick up processing from there.
  2. Ideally, I pictured that my service could return “Success” and then just continue processing on its own, but I’m not sure if this is possible. Since my processing is time-sensitive, kicking off the back-end processing of the new request is ideal, so wait time is minimal.

Are there any other ideas, or does one of these sound preferable?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think 1st is the only possible solution. 2nd is very bad design. Assume you process each request for 1 second, and there are 2 requests coming in 1 second in average. You will quickly run out of resources (because more and more threads will be used)

    1st one is good because you have all control on how you will store and process requests. Good design is to have web service as frontend that will just answer “Success” and enqueue requests. As a persistent storage i recommend MSMQ or database. Then create a service app that will have pool of threads and will pick from queue(db).

    • 0