Introduction

FADA is a decentralized peer-to-peer network of nodes that provide leased storage. That means that things that are registered (stored) in a FADA node are not kept forever: the party that registers must periodically renew a lease in order for the stored data to remain in the node. If the lease is not renewed before it expires, the associated data is deleted. This is a characteristic borrowed from Jini™, on which FADA is based.

The main purpose of the leased registry is to provide a registry that purges itself of stale data. In its actual implementation, the only type of data that can be registered in a FADA node is Java classes, often referred to as service proxies, because they usually provide a programmatic front-end to existing serivices. In this case, it is useful for the registry to delete proxies that were registered but their lease is not renewed, because that means the party that registered the proxy (and is providing the service) is not active anymore (due to failure or any other reason), so the proxy is not useful anymore.

In a future release of FADA it will be possible to register (store) any type of data, from any programming language (now limited to only Java clients).

Items (service proxies) are registered in any node of the FADA cloud, and they can be searched for starting from any node in the FADA cloud. The FADA nodes create a free graph (the topology is not enforced and not even known). Searching is performed through a flooding algorithm. As the limitations of a flooding algorithm with respect to scale are known, future versions will provide alternative ways to perform the search.

Items registered in nodes are described by three types of data: the Java interface the proxies implement, the id associated to the proxy when it is registered, and a set of strings we call entries. Original Jini entries were Java classes that could provide behaviour, like the proxies, but we decided long ago to simplify them: if you want behaviour, you can always embed it in the proxy itself.