In preparation for the EDCON conference, we present a series of articles to introduce the technology behind the Blockchain-based Distributed Cloud. The previous article gave an overview of This article introduces the technology we use: XtremWeb-HEP, a middleware that allows us to use many machines on the Internet to execute distributed applications.


XtremWeb-HEP (XWHEP), developed by CNRS-IN2P3, is based on XtremWeb by INRIA. It is a middleware permitting to deploy a distributed data processing infrastructure (computing grid). XWHEP belongs to the so called “Cycle Stealing” family that uses idle resources. Like some other grid middleware stacks, XWHEP uses remote resources (PCs, workstations, PDA, servers) connected to Internet, or a pool of resources inside a LAN. Thus this middleware is the cornerstone technology of the distributed Cloud because it allows the participant to share their computing resources, such as processor, application and/or data.

XWHEP is written in Java language permitting to run on different architectures. It’s a Free Software under Gnu Public License that easily enables applications of Global Computing and Peer to Peer distributed systems. XWHEP allows to setup and run Distributed Systems. Such project infrastructure may be based on a community of participants. For example, XWHEP allows high schools, universities and companies to setup and run a Global Computing or Peer to Peer distributed system for either a specific application or a range of applications.

XWHEP has been developed and used in the context of international IT projects funded by the European Union: EDGeS, EDGI, DEGISCO, and is part of the International Desktop Grid Federation.


XWHEP features include:

  • P2P communications
  • Fault tolerance
  • security: authentication (X509, OpenId, OAuth, login/password); authorization; confinement; blacklisting
  • user management
  • access rights
  • data management
  • data driven scheduling
  • application management
  • bag of tasks
  • replication
  • volunteer sharing
  • deployment policy
  • bridges
  • virtual machine management


Server — as shown in figure “ : a secured 3 tiers architecture” :

  • one ormore Services are maintained by system administrators to host services such as the ‘Scheduler’, the ‘Result Collector’ and the ‘Bridge’ between the infrastructure and the Ethereum Blockchain.
  • Clients are installed by users on their PCs to interact with the infrastructure. The client permits users to manage the Services and use the distributed resources (register applications, submit tasks, retrieve results…).
  • Workers are deployed on computing resources. Thanks to the worker, a machine deployed on the Internet will be able to join the network and execute client’s tasks.


The workflow described below does not intentionally take security into consideration to ease the understanding. Security will be the subject of an upcoming article.

In short, works as follow:

  • The XWHEP services permit to manage registered applications, data, users etc.
  • Client registers applications, data and any item that are needed to successfully compute jobs. These item may be stored in the infrastructure itself or in any repository as soon as they can be described by an URI and are accessible through the network. There is no limit on item size, but exceeding a few hundred of mega-bytes may be very long to transfer.
  • A Client prepares jobs (units of work) containing the reference of a registered application, optional parameters, optional references to additional files as well as any item.
  • Finally, the Client submits the prepared jobs to the scheduler.
  • Independently, workers contact the scheduler to get jobs suitable for their architecture.
  • In response, the scheduler sends a suitable job description to a worker.
  • For each item referenced by the job which is not present in the local cache of the worker, the worker fetches it from Data Repository or an external data repository.
  • As soon as a job has finished on worker side, the worker contacts the Result Collector to send the results.
  • The result can either be retrieved by the Client, or fetch back to the smart contract.
  • The client may want to develop a front-end for his Dapp application using a framework such as Embark or Truffle. Still, his application will be able to communicate with the network through the smart contracts.


The comes with a public dashboard aiming to present a view of the platform. Please note that this public dashboard does not propose any interaction.

It is available at

Next figures show some examples:

Dashboard for the network, presenting the hosts, tasks and applications registered on the scheduler. It can be viewed online at


This article introduced the architecture. The upcoming article will detail security. It will present the communication secured layer; it will also introduce authentication, authorization, access rights, confinement and more.


You are kindly invited to:


Next Article

Next article describes the security: available here.