1. Client posts an event to the WCF facade
  2. Service facade posts the event to the Dispatcher input queue, and returns "Message successfully accepted" result to client
    • Posting to dispatcher queue is important to get a definite order of messages
    • Dispatcher may work multi-threaded, so queue processing may not conform to the order of messages
  3. Dispatcher retrieves message from queue, looks up processor node to the message type, and
  4. Processor retrieves message from queue, and processes it
    • Retrieves entity state from entity cache
    • Validates message against stored entity state
    • Updates stored entity state according to message data
    • Constructs result message, and posts it back to Dispatcher input queue
  5. Dispatcher receives result message, and handles it
  6. Persister receives message
    • Saves the payload to database (should check for out-of-order messages)
    • Constructs result message, and posts it back to Dispatcher input queue
  7. Dispatcher receives message
    • Updates message map (sets status to 'Persisted')
    • Saves message to repository
  1. Client polls for message completion
  2. Service facade queries dispatcher's message map, and returns current status
    • Based on correlation id
    • If status is 'Persisted', Dispatcher sets message map status to 'Completed'
    • After next snapshot, 'Completed' events are released from in-memory message map



MiniStock message processing preview.png
(Large size)

Last edited Apr 4, 2012 at 9:51 AM by delzubu, version 2

Comments

No comments yet.