broken links in AG intoroduction

deployment scenarios

diff --git a/org.glite.lb.doc/src/LBAG-Introduction.tex b/org.glite.lb.doc/src/LBAG-Introduction.tex
index 604d2c3..bbdfacd 100644 (file)
--- a/org.glite.lb.doc/src/LBAG-Introduction.tex
+++ b/org.glite.lb.doc/src/LBAG-Introduction.tex
@@ -39,9 +39,43 @@ and delivering the events to \LB servers where users can query for them
 
 \subsubsection{Standalone \LB server}
 
+This is the recommended standard production deployment.
+
+\LB server is installed on a~dedicated machine,
+where no other grid services (gLite WMS in particular) run.
+Hence user queries and notification processing are offloaded 
+from the WMS, not affecting its performance directly.
+
+In this setup the full reported performance is achieved,
+currently up to several hundreds thousands jobs per day, with the goal
+of one million, see~\cite{lbtp}).
+
+Further performance can be gained with clustering $M$ WMS's and $N$ \LB's
+while configuring all WMS's to distribute jobs to the \LB's uniformly.
+In this setup bottlenecks emerging from \LB proxy to \LB server serialized
+communication are likely to be eliminated.
+The optimal $M:N$ ratio strongly depends on the rate of user queries
+and number of evaluated notifications,
+and it must be determined empirically for each specific installation.
+
 \subsubsection{Hybrid \LB server-proxy}
 
-Jen 2.0
+\LB server runs on the WMS node, in combined server-proxy mode,
+serving both user queries and supporting WMS.
+Total processing requirements for a~single jobs are lower
+(unlike with separated proxy and server, job state is computed and stored only once).
+
+On the other hand, processing user queries is done on the WMS node,
+limiting its performance then.
+This setup is suitable for smaller installations with a~single (unclustered)
+WMS, expected load of upto 30--50 kjobs/day, and not very heavy user-generated
+load.
+
+The functionality is available for \LBnew only.
+
 
 \subsubsection{\LB server on WMS node}
-Highly obsolete and inefficient \dots
+
+% dedictvi pre-proxy , chybny deployment
+
+% Highly obsolete and inefficient \dots

diff --git a/org.glite.lb.doc/src/LBUG-Tools.tex b/org.glite.lb.doc/src/LBUG-Tools.tex
index 0f06391..17798b1 100644 (file)
--- a/org.glite.lb.doc/src/LBUG-Tools.tex
+++ b/org.glite.lb.doc/src/LBUG-Tools.tex
@@ -57,6 +57,7 @@ where verbosity level can be from 0 to 3.
 
 
 \subsection{HTML and plain text interface}
+\label{simple}
 Since the gLite jobId has the form of a unique URL, it is possible to cut and paste it directly
 to the web browser to view the information about the job (esp. its status), e.g.
 \begin{verbatim}

diff --git a/org.glite.lb.doc/src/components.tex b/org.glite.lb.doc/src/components.tex
index 15609d1..3f6fa07 100644 (file)
--- a/org.glite.lb.doc/src/components.tex
+++ b/org.glite.lb.doc/src/components.tex
@@ -6,6 +6,7 @@ is available in ANSI~C binding, most of the querying capabilities also in C++.
 These APIs are provided as sets of C/C++ header files and shared libraries.
 The library implements communication protocol with other \LB components
 (logger and server), including encryption, authentication etc.
+\LBnew provides an experimental Java binding of the logging API.
 
 We do not describe the API here in detail; it is documented in~\LB Developer's
 Guide\cite{lbdg},
@@ -17,6 +18,17 @@ intended for usage in scripts.
 The query interface is also available as a~web-service provided by the
 \LB server (Sect.~\ref{server}).
 
+Finally, certain frequent queries (all user's jobs, single job status, \dots)
+are available as HTML pages (by pointing ordinary web browser to the \LB server
+endpoint), or as simple text queries (\LBnew only) intended for scripts.
+See~%
+\ifx\insideUG\undefined
+\cite{lbug}
+\else
+\ref{simple}
+\fi
+for details.
+
 \subsubsection{Logger}
 \label{comp:logger}
 The task of the \emph{logger} component is taking over the events from
@@ -57,10 +69,18 @@ owner can store events belonging to a~particular job), and stored into the
 database.
 In addition, the current state of the job is retrieved from the database,
 the event is fed
-into the state machine (Sect.~\ref{evprocess}), and the job state updated
+into the state machine 
+\ifx\insideUG\undefined\relax\else
+(Sect.~\ref{evprocess}),
+\fi
+and the job state updated
 accordingly.
 
-On the other hand, the server exposes querying interface (Fig.~\ref{f:comp-query}, Sect.~\ref{retrieve}).
+On the other hand, the server exposes querying interface (Fig.~\ref{f:comp-query}%
+\ifx\insideUG\undefined\relax\else
+, Sect.~\ref{retrieve}
+\fi
+).
 The incoming user queries are transformed into SQL queries on the underlying
 database engine.
 The query result is filtered, authorization rules applied, and the result
@@ -77,8 +97,11 @@ The set of indices is configurable, and it may involve both \LB system
 attributes (\eg job owner, computing element,
 timestamps of entering particular state,~\dots) and user defined ones.
 
-The server also maintains the active notification handles
-(Sect.~\ref{retrieve}), providing the subscription interface to the user.
+The server also maintains the active notification handles%
+\ifx\insideUG\undefined\relax\else
+(Sect.~\ref{retrieve})
+\fi
+, providing the subscription interface to the user.
 Whenever an event arrives and the updated job state is computed,
 it is matched against the active handles%
 \footnote{The current implementation enforces specifying an~actual jobid
@@ -100,7 +123,7 @@ pending events belonging to this handle accordingly.
 
 \subsubsection{Proxy}
 
-\emph{\LB proxy} is the implementation of the local view concept (see
+\emph{\LB proxy} is the implementation of the concept of local view on job state (see
 \ifx\insideUG\undefined{\cite{lbug}}\else{Sect.~\ref{local}}\fi). Since
 \LBnew, \LB proxy is intergrated into \LB server executable.  When deployed (on
 the WMS node in the current gLite middleware) it takes over the role of the