locked
Designing a queue job to interact between two application RRS feed

  • Question

  • User-2021793694 posted

    Hi,

    Currently i have a web application and a wins form application in my server. Basically, the web application will receive request from user and this request will be send to the wins form application to proceed (wins form need about 1 minute to complete a request).

    Let say 2 users send a request at the same time via web application, I need to develop a queue job to maintain the request in sequence.

    1) User A make a request > request will be store into a queue job

    2) User B make a request > request will be store into a queue job

    3) The queue job will send the first request to the wins form. Once first request is complete, then will follow by the second request

    So my question is, this queue job should be develop inside the web application? Or it should be develop in a stand alone wins form?

    Any example code for create a queue job?

    Or anyone can suggest a better solution?

    Tuesday, October 8, 2013 8:42 PM

All replies

  • User538021195 posted

    I would suggest to look into using WCF for implementation of Queues as it provides the ground work like fault isolation and loosely coupled design. A good starting point would be:

    http://msdn.microsoft.com/en-us/library/ms731089.aspx

    If for some reason, you don't go in this direction, I would suggest at the minimum to implement a Queue in the database - this would handle case of concurrency, reliability and synchronization at the minimum.

    Tuesday, October 8, 2013 11:52 PM
  • User-488622176 posted

    Actually, I'd ditch the desing you made :-)

    Alternative solution:

    • Create a (secured) WCF service that manges the queue : store items in queue, fetch items
    • The asp.net/web app puts data in the que by calling the wcf service => allows concurrency
    • Create a Winforms app that periodically checks the queue for items and processes the items
      • If no user interaction is needed for processing => use a windows service instead

    Communication between a web app & a win app is almost impossible, and very very rarely required.

    Wednesday, October 9, 2013 10:02 AM
  • User538021195 posted

    Actually, I'd ditch the desing you made :-)

    I recommended looking into WCF service for managing queues as the first option.

    Thursday, October 10, 2013 12:28 AM
  • User-545631939 posted

    Actually, I'd ditch the desing you made :-)

    Alternative solution:

    • Create a (secured) WCF service that manges the queue : store items in queue, fetch items
    • The asp.net/web app puts data in the que by calling the wcf service => allows concurrency
    • Create a Winforms app that periodically checks the queue for items and processes the items
      • If no user interaction is needed for processing => use a windows service instead

    Guru,

    What are the pros and cons between implementing WCF queueing and queueing in the database? I had posted a similar question about it in the WCF forum, here at:

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/6145b9b5-a8e8-4a18-aca3-66462d91680d/is-it-better-to-have-a-queue-at-the-wcf-layer-or-in-the-database?forum=wcf

    The Gurus there suggest doing it in the database, as opposed to WCF. Is there an advantage too it, or is it that for my scenario, database is the better option?

    Novice Kid

    Friday, October 11, 2013 4:16 AM
  • User-488622176 posted

    Please do not misunderstand my answer : the queuing of data/messages is done in dbase. The logic (access, store, query, ...) in my sample is done through a service. This service hides all underlying functionality of the queing, and is wrapped with WCF. This enables you to call it from any application without implications. If you separate the WCF from other apps, you can not only separate concerns (functionally), you also can scale more. If this is not a requirement (low traffic, few messages, few data) you could wrap the service in a class assembly and share the code/implementation as such.

    Friday, October 11, 2013 4:54 AM
  • User-545631939 posted

    Please do not misunderstand my answer : the queuing of data/messages is done in dbase. The logic (access, store, query, ...) in my sample is done through a service. This service hides all underlying functionality of the queing, and is wrapped with WCF. This enables you to call it from any application without implications. If you separate the WCF from other apps, you can not only separate concerns (functionally), you also can scale more. If this is not a requirement (low traffic, few messages, few data) you could wrap the service in a class assembly and share the code/implementation as such.

    Ok, thanks Guru. By the way, if I could ask an academic question (or maybe it is not purely academic at all!), could queueing be done purely in the WCF layer, without the help of a database? Using WCF Queueing, that is? Since it use MSMQ for queueing, the question of reliability is taken care of. Are there any inherent drawbacks to the approach that does it without a database?

    Seeking wisdom from you Guru!

    Novice Kid

    Friday, October 11, 2013 6:29 AM
  • User-488622176 posted

    Queueing can be done in the WCF layer. This falls under the reliable messaging features. There is no answer on wether it is good or not (besides the fact it uses MSMQ and has some drawbacks). This depends on the requirements/situation.

    If you can stick to the messaging part, it will provide reliable messaging. However if you need to assure reliability end-to-end this will be insufficient. The service can threat the message and do something with it. What if processing fails inside the service? What if the service invokes external systems, how to assure reliability in this case? WCF RS handles part of the reliability of the system, but not all of it. 

    By using database queues (in sense of storing data in dbase), you can go further. You do not loos your message unless you delete it. You can mark as processed at the end (case service invokes other service calls), you can redo, ...  

    However: what to use depends on the overall/underlying drivers for your application/system. 

    Friday, October 11, 2013 8:17 AM