The membership service is responsible for providing programs with an updated list of the sites that belong to the federation, through a RESTful API.

Multiple implementations of this service are available. The simplest one, uses a fixed white-list that is retrieved from a configuration a file. More sophisticated implementations include a federated service that uses a gossiping protocol to dynamically update the list of active sites.

Federated networking

The federated networking service allows programs to create private networks that span multiple provider sites. This way, a program can instantiate Compute elements in different providers and connect them to the same virtual private network.


This is a local service that can be used to automatically outsource requests to a list of providers that belong to the federation. The policies that are used to decide to which site a request should be outsourced are customizable, and multiple policies may be configured. Depending on how the service is configured, clients may be able to chose different policies for different requests.

Barter of resources

This service provides a lightweight business model for the barter of resources (Compute, Volume, Network, etc.) among federated IaaS providers. Barter is performed with no need for sophisticated billing, auditing and customer relations services.

It implements the Network of Favors (NoF) incentive mechanism, proposed by Andrade et al. In the NoF, the allocation of a certain amount of resources for a given amount of time is called a favor. A federation member keeps a local record of the total amount of resources provided to and received from each other member with which it has interacted in the past, which is updated from time to time, depending on the accounting granularity autonomously defined by each provider. Based on these values, each member calculates a balance of the interactions as the difference between the amount of resources received from a member and the amount of resources provided to that member. In case of resource contention, a member will always prioritize the provision of resources to the members to whom it has the highest debt, ie. those with which it has the highest value in the balance of previously exchanged resources.

This business model was first designed and evaluated in the context of peer-to-peer desktop grids and implemented by the OurGrid middleware. For a complete description and assessment of this implementation, refer to OurGrid’s publications. In particular, have a look at "Automatic grid assembly by promoting collaboration in peer-to-peer grids". In addition to the scientific publications describing this prioritization mechanism, there are also others that describe improvements that have been proposed for the particular context of the federation of private IaaS clouds. Please refer to the Research section for further details.