Difference between revisions of "ACE (Audit Control Environment)"
Jump to navigation
Jump to search
(Added links to Function and/or Content Type) |
|||
| Line 4: | Line 4: | ||
|license=Apache License | |license=Apache License | ||
|platforms=Web-based and platform independent. Requires Java 1.6 or later; Tomcat 6.0 or later; MySQL 4.0 or later; and MySQL connector 5.0.7 or better | |platforms=Web-based and platform independent. Requires Java 1.6 or later; Tomcat 6.0 or later; MySQL 4.0 or later; and MySQL connector 5.0.7 or better | ||
| − | |function=Fixity | + | |function=Fixity |
}} | }} | ||
{{Infobox tool details}} | {{Infobox tool details}} | ||
Revision as of 19:40, 11 May 2021
Description
The Audit Control Environment is a mature set of software designed to help librarys and archives prove their holdings are intact and trustworthy. Recent developments of ACE include a new token store format to allow ACE tokens to be easily exported, transferred, and independently verified by third parties. To support the ACE tokens a python proof of concept has been developed to allow 3rd parties to write their own file validation routines using ACE tokens. Developed by University of Maryland. Written in Java.
User Experiences
- I deployed ACE-AM a few years ago, in it's servlet form, and it worked pretty well. The only problem was that for very large collections (millions of individual files) it would start to fall over due to running out of RAM. There is no technical need to keep the entire collection's checksum data in memory (as the system has a database available), so this could easily have been fixed by now. If this is a potential concern, I recommend monitoring memory usage as part of a large-scale test during evaluation. Andy Jackson (talk) 11:02, 11 September 2014 (UTC)
- Discussion of fixity tools, including ACE on the Digital Curation google groups