-%-----------------------------------------------------------------------------------------------------------------------------
+%------------------------------------
% 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.
+%------------------------------------
+XtremWeb-CH (XWCH) is a volunteer computing inspired, large-scale
+computing platform for distributed applications. It consists of three
+components: one coordinator, a set of workers and at least one
+warehouse. Client programs use 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}.
+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 (Web Service Description Language) \cite{WebServ2002}, that simplifies
+client development for languages that support it (and most popular programming languages do).
-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.
+A worker is a Java daemon that runs on the user machine. Assumed to be
+volatile, the workers report 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 \ref{xwch}.
-\begin{figure}[hb]
+\begin{figure}[htp]
+\label{xwch}
\begin{centering}
\includegraphics [scale=0.2]{figures/xwcharchitecture.pdf}
- \caption{The XWCH Architecture}
- % \label{Figure 4: The XWCH Architecture}
+ \caption{The XtremWeb-CH 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.
+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 others, due to firewalls and NAT
+sub-networks. 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)):
+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 \ref{xwch}, (1)). The main flexibility provided by the use of this
+architecture is to control and generate dynamically jobs especially
+when their number cannot be known in advance. Communications between
+the coordinator and the workers are always initiated by the workers
+following a pull model (Figure \ref{xwch}, (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.
+\item Workers receive jobs (Figure \ref{xwch}, (3)) only if they send a “work
+ request” signal;
+\item When a worker finishes its job, it stores its output file on
+ a 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.
+
+As a whole, XWCH is easy to install, maintain and use. Its components
+are programmed mainly using Java, and their process memory sizes in a
+typical 32-bit GNU/Linux computer are:
\begin{itemize}
- \item Coordinator 190 MB including the Glassfish Java container
- \item Worker 40 MB
- \item Warehouse 80 MB
+ \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.
-
-
-
+Experiments presented in \cite{ccgridpaper} show 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
+previous ones, 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.
