Design - Fixity Service

User Stories/Features

1. Ensure that all resources are checked every n months
2. Run continual fixity checks
3. Only alert me there failures
4. Call an arbitrary HTTP endpoint on success and/or failure
5. Send a (jms,stomp) message to a endpoint on success and/or failure
6. Perform fixity check on HEAD version of resource only
7. Perform fixity check on all versions of resource
8. Generate list of resources checked since X date  
9. Generate list of resources not checked X date
10. Generate a fixity audit report by resource
11. Generate a csv of fixity audit results showing resource id, date checked, checksum, and the result
12. Set  rate limits (max bits/second) for checks
13. Allow checks to be scaled horizontally
14. Store fixity results in external datastore
    1. triplestore
    2. sql database
    3. no-sql db 
15. Deliver fixity requests in batches

Prior Art

Components

Fixity Checker 

performs the fixity check on a resource and communicates the results to the configured Fixity Result Handler

Fixity Check Manager

• Is responsible for monitoring and providing status of  all fixity check tasks
• coordinates parallel processing of fixity checks
• coordinates auto-scaling requests

Fixity Result Handler

responsible for storing the results.  I can imagine difference implementations that talk to different types of data storage backends

Fixity Result Reporter 

a service that generates reports