Sierra
An OpenPrivacy
Reputation Management Framework
Store
The Store package provides a simple Reputation persistence mechanism. RCEs must
save known reputations when they shutdown. If they didn't, calculated
Reputation and all Reputations obtained via putReputation would be lost and the
RCE would have an incomplete data set. In order to do this an RCE needs to be
connected to some type of structured storage mechanism (usually a database but
it could also be a filesystem). An RCE could provide a mechanism for its own
storage but this has problems. If you wanted to support a different storage
mechanism you would have to rewrite the RCE for every new storage format.
An RCE has a defined lifecycle that all RCEs should be aware of:
- RMF startup
- RCE startup
- An RCE gets a Reputation object via putReputation and starts building a
Graph.
- The RMF is shutdown (either because of a reboot, garbage collection,
etc) and a checkpoint is called and it saves itself to disk.
- Steps 1-3 are called on restart but this time we also add a step where
the RCE is instantiated with the Graph which it had before. This way
calculated Reputations are preserved.
The put method adds a new Reputation to the store. The get method takes a
reputation:// URI and pulls it out. The restore mechanism should restore all of
its internal Reputations into the given RCE by calling putReputation on the RCE
until all Reputations are added. This should provide a state restoration
mechanism for RCEs which is portable across algorithms.
When a developer deploys an RMF he must pick at least one Storage provider that
the RMF can use. Ideally an RMF would ship with multiple Storage providers. At
this time Sierra only ships with one implementation for MySQL.
Components:
StoreEngine:
A StoreEngine is responsible for saving Reputation objects to persistent
storage within an RCE. Although not a requirement, if an RCE chooses to use
a StoreEngine as its persistence mechanism, this can be changed without
rewriting an RCE. This means that if you write a Foo RCE and you develop it
for a MySQLStoreEngine you can change it to use a OracleStoreEngine without
having to rewrite the FooRCE.
This is a significant tool for RCE developers. This allows then to
concentrate on implementing the logic necessary for their RCE without having
to worry about the persistence of their Reputation object.
Get a reputation from this Store via its URI:
Example: reputation://[SERVER]/key/signature
+get (URI) : Reputation
-------------------------------------------------------------------------
Given a SignatureValue ( PublicKey and a signature) for an object,
return its representation from the underlying persistence mechanism.
+get (SignatureValue) : Reputation
-------------------------------------------------------------------------
Get a QueryManager which is optimized for finding QueryEngines which
support this StoreEngine.
+getQueryManager () : QueryManager
-------------------------------------------------------------------------
After an RCE starts up, populate it with Reputation objects so that its
internal graph reputation is formed. This allows an RCE to restore its
state due to server restarts or application faults/crashes.
+populate (RCE) : void
-------------------------------------------------------------------------
Put a Reputation into this StoreEngine.
+put (Reputation) : void
StoreManager:
Handles serving Stores to RCE components so that reputation storage is
separate from reputation calculation. The StoreManager allows for each RCE
to have a different store based on their requirements. When Sierra is
deployed the StoreManager will be configured to serve the correct Store to
the given RCE
Get a store which is appropriate for the given RCE.
+getStoreEngine (RCE) : StoreEngine
Sierra has
additional documentation for this package.
|