X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/gpc2011.git/blobdiff_plain/db3fd661ef153080f851664602a43ab45755cc34..386389681aed0efc9e9a396a4b09e2ab55a063f4:/xwch.tex

diff --git a/xwch.tex b/xwch.tex
index d38b719..f3230e3 100644
--- a/xwch.tex
+++ b/xwch.tex
@@ -1,53 +1,74 @@
-%-----------------------------------------------------------------------------------------------------------------------------
+%------------------------------------
 % 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.
