Evaluate this design - IIS > MSMQ > WCF > DB RRS feed

  • Question

  • Current system is laid out like this:

    - ASPX page on ServerA recieves a http post, which is written to a DB table
    - Windows svc on Server B, on a schedule, polls the DB table for new records based on a specific flag
    - When the svc finds records, it processes the data, which ends up writing data to a different DB
    - The svc is doing A TON of very manual xml processing, using reflection to load/unload data into objects based on classes the conform to a given schema.  This works, but is rather hard to follow unless your familiar with the code.  It took me several days to to get familiar with it.

    Revamped solution idea:

    - HTTP handler on ServerA receives the data and writes the data to a private msmq queue
    - The queue is setup as a private, transactional queue and messages sent to the queue will be marked "recoverable=true")
    - The messages will be written to disk
    - If the message is read, but the process that uses the message data fails, the message goes back onto the queue
    - The data that gets sent is typically no more than 10-50 KB and is in xml format (a string)
    - WCF Windows svc also on ServerA, polls the queue for new messages on a schedule
    - When a message is read, the svc takes the data from the message and passes it into a Workflow
    - The workflow handles the business logic of processing the message data
    - Internally, the activities of the workflow use xpath to fetch the data out of the xml message before writing to the 2nd DB

    Comments or suggestions welcome

    Wednesday, May 8, 2013 1:07 PM

All replies

  • Seems reasonable.

    Nowadays I would be inclined to use WCF rather than a httphandler.


    You don't need to destroy messages as you read them out msmq.

    The various msmq peeks aren't destructive and can wait for a message for a specified time period.

    Makes your read a bit more flexible.

    You can then destroy a processed message by using receivelookup.

    This way if your service goes pear shaped part way through then your message will still be there.

    In the past I've used a sliding timscale on the service reading the q for processes where you tend to get a bunch of messages and then nothing for a while.  So it'll sleep like 5 minutes at a time until it finds something then much less until it finds nothing in the q.

    Thursday, May 9, 2013 2:41 PM