Responsibilities

Implementation details

  • Strongly coupled to the WCF service logic (queries message map state)
  • Single role deployment (can't be scaled out)
  • May have multiple worker threads
  • Knows about processor node - entity mapping
  • Implements event handling protocol

Components

Message Map

Event processing is handled by a specific protocol. The current processing state may be deducted from actual responsible node, but this knowledge is also maintained directly by event dispatcher node.

Message map is a table, keyed with correlation id, which stores all the messages to the given processing (input message, result message from processor node, result message from dispatcher node), and the current status (what do we think, which node should work on this right now). Message processing is terminated when message becomes obsolete, or a client polled for status, and got 'completed' result.

Message map should be kept in memory for the lifetime of the message processing, and be persisted during service restarts. For this end, a snapshot-enabled transactional table mechanism is used (see Message Map Repository)

Protocols

TODO: Should implement a fail-safe logic for the following scenarios:

1. Processor is not available

  1. Message is succesfully posted to the WCF facade
  2. Message is routed to a processing node, which is currently unavailable
  3. Processing node does not responds in a given time

Should be handled by a retry mechanism. On processing / persister nodes, we must filter out duplicated messages

2. Service restart

  1. Message is succesfully posted to the WCF facade
  2. Message is routed to a processing node
  3. Dispatcher service is restarted
  4. WCF facade queries for message status

Message map should be kept persistent

Last edited Apr 3, 2012 at 3:28 PM by delzubu, version 6

Comments

No comments yet.