Sierra
An OpenPrivacy
Reputation Management Framework
Communications
An RMF needs to support multiple topologies/protocols because a Sierra based
application may want to exchange or receive Reputation objects via
putReputation from any number of hosts.
Since the core of Sierra is based around an RCE, Sierra can provide support
for any new communications topology/protocol just by writing a new RCE which
acts as a bridge. A bridge RCE is similar to a normal RCE but does not
contain any calculation logic, it only contains network communications logic
and forwards all of its calculations onto a remote RCE.
Essentially this allows any RMF to support any current and future protocol
just by writing a small Component.
Future Directions:
- Support multiple communications protocols including SOAP/XMLRPC/RMI.
This will probably be integrated into Talon so that all components support
remoting.
- Support lookup mechanisms such as UDDI (which is somewhat centralized)
or metatracking
(which is somewhat distributed) so that we can find other RMF instances at
runtime.
Components:
CommunicationsRCE:
A CommunicationsRCE is a tag component which extends the RCE component.
It basically performs the same role that an RCE does except that it forwards
all operations (getReputation, putReputation, etc) to a remote RMF/Sierra
installation. This is done by wrapping an existing RCE with any logic
necessary to communicate with a remote machine.
This architecture means we can support any protocol, any topology and any
future protocols/topologies that do not exist yet. This is due to the fact
that a CommunciationsRCE has almost *no* requirements and offloads most of
its burden to the implementation class. This, in essence, will allow Sierra
to support almost infinite growth without rewriting any existing code that
uses it.
Example:
/ SOAP-RCE \ / SOAP-RCE \
| | ( IP ) | |
| [Local-RCE] | <--- Network ( Gnutella ) ---> | [Remote-RCE] |
| | ( Freenet ) | |
\ SOAP-RCE / \ SOAP-RCE /
Sierra has
additional documentation for this package.
|