locked
Job scheduling in web applications RRS feed

  • Question

  • User-69623574 posted

    Hi all,

    I have an application which allows the user to submit a request for a ticket to be created. i send all the parameters selected by user to a third party tool through webservices (which is working fine) and a ticket is being created and the webservice brings the ticket number (only) back to the UI (this takes few minutes)

    Remember there is no database (owned by us) is asscoiated here. this is an immediate process (Tickets are created immediately and ticket details or shown on the UI) Now the thing is, there is  new request for me asking for a scheduled ticket creation i e User should be able to create a ticket per schedule  (let say 12.18.2009 5:00:00 PM ) either it is one time or recurssive. So iam supposed to call the webservice at the specified time. (I dont have an option of sending the details and storing them in their database and ticket created as per the specific time)

    I have 2 webservers (load balanced), 1 database a COM Box if required(an intermediate box to communicate with webservices and also database).

    i believe i cannot write a scheduler in the webserver since i have two (webservers). 

    My Plan

    i would like to wirte a windows service (console application) to create an exe file and place the file on the COM Box. when the user submits for an immediate ticket then i would call the webservice immediately other wise i would store all the info in my database and push a scheduled task to the COM box which has  scheduled time details.

    Exe file would query the db for ticket parameters and call the webservice.

    what do you think (Any issues that i might come across??)


    Any other suggestions in proceeding further would be greatly appreciated.

    Thursday, December 17, 2009 12:21 PM

All replies

  • User-952121411 posted

    Yes, it sounds like the 'immediate ticket' scenario is pretty well covered the way you have it designed currently. 

    As far as the 'post dated' ticket requests, I would do the following:

    1. Get the details / parameters about what time the ticket is to be created in the future (as you mentioned) and store them in a DataBase.
    2. Create a Windows Service, that polls the database periodically (on whatever time interval needed; every minute, 5 minutes, etc.) to see if any of the scheduled requests are ready to be processed (i.e. Scheduled Task Time <= Now).
    3. Call the webservice from the Windows Service and complete the ticket request.

    #2 above is what you will need the guidance with.  I have done this style of design with a Windows Service and have a link below that details how to complete this process.  The link's article below also has a link to straight forward, easy to understand code examples using a 'ThreadPool.RegisterWaitForSingleObject' for the Windows Service.

    Running a Periodic Process in .NET using a Windows Service:

    http://allen-conway-dotnet.blogspot.com/2009/12/running-periodic-process-in-net-using.html

    Post back if you need more information, and hope this helps! Smile

     

    Thursday, December 17, 2009 3:02 PM
  • User-389939489 posted

    IMO, the responsibility of dealing with the tickets database should all and only belong to the windows service.

    Conceptually, the client would just place a request by calling some method of the service, and then would check outcomes at the next reconnection, again by calling some other method of the service. The service itself would deal with creating/scheduling/processing tickets.

    At a later stage, you might need and think to restructure the whole thing and have tickects properly handled by some application/data layer. In any case, you wouldn't want to implement that functionality into the client.

    HTH,

    -LV

    Thursday, December 17, 2009 3:16 PM
  • User-952121411 posted

    Yes I agree with LudovicoVan; so to add on to my original post, all ticket requests (live or post dataed) could send their request to the database, and then the Windows Service would pick it up and make the request to have it created on the next poll of the database.  As long as the interval was set low enough on the poll from the Windows Service (like 30 seconds, etc.), you would have no problem implementing this.

    This was the responsibility of requesting the 'actual' ticket always comes from the Windows Service, and the client never has to make a direct request to the web service.  This more correctly clarifies the responsibilities of each piece.

    Thursday, December 17, 2009 3:21 PM
  • User-389939489 posted

     > Yes I agree with LudovicoVan; so to add on to my original post, all ticket requests (live or post dataed) could send their request to the database

    For the sake of clarity, I just wouldn't allocate that responsibility to the client: what I said is that the client would send a request to the service, and the service would create any tickets and have to do with any database, etc...

    -LV

     

    Thursday, December 17, 2009 3:47 PM
  • User-952121411 posted

    Are you stating that you want an ASP.NET client to call a Windows Service?  That is a bit difficult to do and doesn't expose itself in the way that a web service or other service type that is consumed does.  If you meant for the client to call the web service, then I understand your statements.

    Thursday, December 17, 2009 4:07 PM
  • User-389939489 posted

    Well, that was speaking "conceptually".

    In fact, what I'd do is have the client call the web service: the web service would deal with immediate requests as it is already doing; it would also create tickets upon request, (possibly) into some database table. The windows service on the other hand would poll the database at more or less short intervals to check that any ticket needs to be processed, and eventually do it and collect results; finally, the client would request for a processed ticket the web service, which would again query the database.

    Hope it makes sense,

    -LV

    Thursday, December 17, 2009 4:32 PM
  • User-952121411 posted

    Yep that is pretty much exactly what I said with the exception of adding a web service between the client and the database where the request would be stored, where I stated to do it directly.  However I agree a middle-man service to intercept the calls and actually add the data to the database is a good idea, this way multiple clients don't have to implement the raw code to insert the ticket information in the db, but rather could rely on the web service to handle all of the traffic.

    The Windows Service is still a separate piece that at a minimum handles the polling and calls to request the actual tickets.  The service if needed could call back to the web service mentioned above to create the actual ticket as well.

    So below describes the conversation thus far:

     

    ASP.NET Client -> Web Service -> DataBase           Windows Service (Windows Service can call the web service too to make the 'actual' tickets)

                                        ^                                                 |

                                        |                                                  |

                                       <-----------------------------------------

    (sorry for the terrible diagram; I am not good with character diagramming)

     

    Thursday, December 17, 2009 4:54 PM
  • User-69623574 posted

    atconway and Julio thanks for your response. I appreciate that.


    ASP.NET Client -> Web Service -> DataBase <- Windows Service (Windows Service can call the web service too to make the 'actual' tickets)

    here is my scenario.

    what i want to do is

    ASP.NET Client -> DataBase (our DB) <- Windows Service ->Web Service -> DataBase (Third party DB)

    what i have right now is

    ASP.NET Client -> Web Service -> DataBase (Third party DB)


    Please note that the webservice iam using is provided by the third party. so i have no control from that side.

    Create a Windows Service, that polls the database periodically (on whatever time interval needed; every minute, 5 minutes, etc.)

    I did n't get this part atconway. Could you explain me more, considering my present scenario (requirement)?


    Friday, December 18, 2009 10:13 AM
  • User-952121411 posted

    I did n't get this part atconway. Could you explain me more, considering my present scenario (requirement)?
     

    Yes no problem.  You need to read throughly the following link that I provided.  It gives a full detailed explanation for your scenario, and provides a link to code examples as well:

    Running a Periodic Process in .NET using a Windows Service:

    http://allen-conway-dotnet.blogspot.com/2009/12/running-periodic-process-in-net-using.html

    Friday, December 18, 2009 11:24 AM
  • User-389939489 posted

    > Please note that the webservice iam using is provided by the third party. so i have no control from that side.

    That's even better, as with atconway's suggestion you were at risk of circular dependencies...

      [Client]
      (Asp.Net)
          ^
          |
          v
    [ClientService] <--> [TicketsData] <--> [SysService]
     (WebService)         (Database)      (WindowsService)
          ^                                      ^
          +-----------> [ThirdyService] <--------+
                         (WebService)

    HTH,

    -LV

    Friday, December 18, 2009 12:58 PM
  • User-952121411 posted

     

    as with atconway's suggestion you were at risk of circular dependencies...

    I am either drawing this incorrectly or being misunderstood, because there would be no risk of circular dependencies.

    IMO, the Windows Service should not be calling the db directlly but use functionality exposed in the new web service you are creating (named ClientService) in the previous diamgram.  That web service should sit in front of the database and be the interface to the database and to the 3rd party web service.  That service would not make a raw call to the db, but rather call an exposed method on the new service that will centralize the logic of how to call the db.  Yes, the service polls on interval, but upon elapsing, the call is made to the web service which sits in front of the db and acts as a 'controller' of sorts on how the tickets are generated by the 3rd party service and how the database is called.

    You still need to read the article on setting up the Windows Service to poll the web service. 

    So here are the responsibilities:

    • The ASP.NET client only communicates with the new web service.
    • The Windows Service is a worker process to poll on interval the new web service which in turn will make calls to the database to see if tickets need generated.  If the response back from the database is 'True' then the new service could immdeatly generate the needed tickets.  The Windows Service only communicates with the new web service.  In a nutshell, all this service is responsible for is waking up periodically to call the web service to generate any outstanding tickets.
    • The new ASP.NET web serivce you create is responsible for all calls to the 3rd party web service and to the database.  It centralizes all logic for communicating with both the database and the 3rd part web service.  If the ASP.NET client app needs to generate a post dated ticket, it will call htis new service, and this service will communicate to the database thid information.  If the Windows Service elapses and polls, it will poll the web service to check and generate tickets as logic dictates.

    So in a nutshell, the new ASP.NET web service is the portal to both the database and the 3rd party web service.  The Windows Service is used as a worker to commit a perodic poll of the new web service.

    If there are still questions, or something is not clear, please let me know.

     

    Friday, December 18, 2009 1:40 PM
  • User-389939489 posted

    > Windows Service can call the web service too to make the 'actual' tickets

    In the context of your previous design, that would create a circular dependency.

    > IMO, the Windows Service should not be calling the db directlly but use functionality exposed in the new web service you are creating (named ClientService) in the previous diamgram.

    FWIW, I'd disagree: a web service should in general provide a facade, not embed logic. Not that hard to fix your design either, as I get it you only want one more middle-man, but IMO that just shouldn't be a web service.

    > You still need to read the article on setting up the Windows Service to poll the web service.

    I have no problems with that bit.

    > If there are still questions, or something is not clear, please let me know.

    Everything is crystal clear, thanks. If I can dare a suggestion, try and draw more...

    All the best,

    -LV

    Friday, December 18, 2009 3:41 PM
  • User-1067358373 posted

    Checkout if this helps in scheduling the tasks.

    http://kodethoughts.blogspot.com/2009/06/creating-windows-task-scheduler-service.html


    Thursday, December 24, 2009 12:27 PM