--- /dev/null
+%-----------------------------------------------------------------------------------------------------------------------------
+% The XtremWeb-CH environment
+%-----------------------------------------------------------------------------------------------------------------------------
+XtremWeb-CH (XWCH) is a volunteer computing inspired, large-scale computing platform for distributed applications. It consist of three
+components: one coordinator, a set of workers and at least one warehouse. Client programs utilise these components.
+
+The coordinator is the main component of the XWCH platform. It controls user access and schedules jobs to workers. It provides a web
+interface for managing jobs and users, and a set of web services. These are user service and worker/warehouse services implemented using
+WSDL \cite{WebServ2002}.
+
+A worker is a Java daemon that runs on the user machine. Assumed to be volatile, the workers reports periodically
+themselves to the coordinator, accept jobs, retrieve input, compute jobs, and store the results of the computation on warehouses. If the
+coordinator does not receive a signal from a worker, it will simply remove it from the scheduling list, and if a job had been assigned to that
+worker, it will be re-assigned to another one. A schema of the architecture is shown in Figure 4.
+
+\begin{figure}[hb]
+ \begin{centering}
+ \includegraphics [scale=0.2]{figures/xwcharchitecture.pdf}
+ \caption{The XWCH Architecture}
+ % \label{Figure 4: The XWCH Architecture}
+ \end{centering}
+\end{figure}
+
+A warehouse is a file server that acts as a data storage system for workers and client programs.
+Workers may not necessarily be able to communicate directly with each other, due to firewalls and NAT subnetworks.
+For these reasons, warehouses are used as intermediaries to exchange, store and retrieve data.
+
+Job submission is done by a client program which is written using a flexible API, available for Java and C/C++ programs. The client program
+runs on a “client node” and calls the user services to submit jobs (Figure 1, (1)). The main flexibility provided by the use of this
+architecture is to control and generate dynamically jobs especially when their number can not be known in advance. Communications between
+the coordinator and the workers are always initiated by the workers following a pull model (Figure 1, (2)):
+\begin{itemize}
+ \item Workers receive jobs (Figure 1, (3)) only if they send a “work request” signal.
+ \item When a worker finishes its job, it stores its output file on warehouse and sends a “work result” signal to the coordinator.
+ \item During its execution, a worker (respectively warehouse) periodically sends “work alive” to the worker service (respectively warehouse service)
+to report itself to the coordinator.
+\end{itemize}
+As a whole, XWCH is easy to install, maintain ans use. Its components are programmed mainly using Java, and their process memory sizes in a typical 32-bit Linux computer are shown below.
+\begin{itemize}
+ \item Coordinator 190 MB including the Glassfish Java container
+ \item Worker 40 MB
+ \item Warehouse 80 MB
+\end{itemize}
+
+Experiments, presented in \cite{ccgridpaper}, shows that the performance of XWCH is comparable with Condor \cite{Condor1988}, another
+non-intrusive computing system that has similar functionality but is somewhat more difficult to install .
+
+The main characteristics of the new version of XWCH, compared to its previous versions, are: dynamic job generation, flexible data
+sharing (data replication) and persistent jobs. These features are presented in \cite{VEZGrid} and will not be detailed in this paper.
+
+
+
+
