%
% r.tex
%
% 2000/06
%
%
% Revisions:
%
% 2000/09/04
% Authors and headers as in the Tea Intro paper, as suggested by
% lcampos. (jpsl)
%

\documentclass[11pt,twoside]{article}

\usepackage{lastpage}
\usepackage{verbatim}

\usepackage{graphicx}
%\usepackage{pstricks}

%
% Images
% (change this from pdf to eps as required)
%
%\newcommand{\iteareq}{\includegraphics[width=.5\textwidth]{iteareq.eps}}
%\newcommand{\itealib}{\includegraphics[width=.5\textwidth]{itealib.eps}}
%\newcommand{\itearep}{\includegraphics[width=.5\textwidth]{itearep.eps}}
\newcommand{\iteareq}{\includegraphics{iteareq.eps}}
\newcommand{\itealib}{\includegraphics{itealib.eps}}
\newcommand{\itearep}{\includegraphics{itearep.eps}}

%
% Product name words
%
\newcommand{\tea}{{\bf Tea} }
\newcommand{\itea}{{\bf I*Tea} }
\newcommand{\java}{{\bf Java} }
\newcommand{\cgi}{{\bf CGI} }
\newcommand{\cgiitea}{{\em cgi2itea}}
\newcommand{\client}{{\em Web Client} }
\newcommand{\webserver}{{\em Web Server} }
\newcommand{\iteaserver}{{\em I*Tea Server} }
\newcommand{\clientdata}{{\em Client Data} }
\newcommand{\teacontext}{{\em Tea Interpreter Context} }


\begin{document}

\title{The I*Tea$^{\hbox{\small TM}}$ Application Server: An Overview}

\author{{\em Jo\~ao Lu\'{\i}s}
\and {\em Jorge Nunes}
\and {\em Lu\'{\i}s Miguel Campos}\\
\\
Dev.Web\\
Rua de Borges Carneiro, 61-A\\
1200 Lisboa\\
{\tt jpsl@devweb.pt}, {\tt jfn@devweb.pt}, {\tt lcampos@devweb.pt}
}


\date{June 2000}

\maketitle

\begin{abstract}
\noindent
\itea is a Web application server entirely written in Java,
scalable, and small in size.
It supports the \tea scripting language, allowing fast prototyping
and development of web applications which can evolve up to
large, scalable and robust applications.
It supplies a few pre-built client context and session management
policies giving the application programmer the choice to choose between
client-server programming models, or explicit client context management.
\itea can generate any kind of output the programmer desires (HTML, WML,
XML, etc...) and comes with object-oriented libraries for HTML rendering
and form processing.  Applications
typically range from small scripts embedded within HTML pages
to large business management applications on Enterprise
JavaBeans\footnotemark
technology.
\end{abstract}

\footnotetext[1]{Java 2 Plataform Enterprise
Edition,  Java Servlet API, Java Server
Pages, and Enterprise JavaBeans are registered trademark of Sun
Microsystems inc.}

\section{Introduction}

\cgi applications usually require the programmer to explicitly
manage application state storing outsite of the mechanisms
provided by the programming language chosen.
Web clients are simpling following links (HTTP GET URL requests)
or submitting forms (HTTP GET or POST requests). The programmer has to
identify each one of them client and explicitly manage the
data structures which store the application state, save them
on hidden form fields, or, serialized/de-serialize them into/from
from disk files, etc... A {\bf web application server} simplifies most
of this job.

There are several {\bf web application} programming frameworks and
commercial products which can help the programmer on this.
\itea is one of them, for which we will try to briefly
describe its features and characteristics.





\section{Software Architecture}

In this paper we will describe the \itea version which interfaces
with browsers through \cgi technology.\footnote{
Integration into a web server as a {\bf servlet} is under study, but
meanwhile, the \cgi version is compatible with most web servers,
and very well tested in large full production environments.
}

An operating \itea application site usually involves the following
software:
\begin{itemize}

\item
\client -
A {\em Client} is usually a user's browser which performs HTTP GET
or POST requests.

\item
\webserver -
A server process which receives HTTP requests and takes appropriate
action.

\item
\cgiitea -
A small executable \cgi program wich interfaces the \iteaserver
process with the \webserver.

\item
\iteaserver -
A standalone process, which receives requests from the \cgiitea,
executes them, and passes the response back to \cgiitea.

\end{itemize}

\itea is entirely written in \java, inheriting all the advantages
of such a technological choice. Its runtime environment occupies
a surprisingly low disk space (approx. 1MB, including the \tea
runtime environment).

The \iteaserver is a multi-threaded \java process which can be modelled
as a set of software components (data and threads)
which communicate between them:
\begin{itemize}

\item
\clientdata -
A simple data storage hastable, private to each \client. It can only be
accessed through a {\em set/get key value} hashtable like API.
The values store in this hashtable can be simple \tea data objects
(integers, strings, etc...)

More complex data structures have to be serialized/de-serialized
if to be stored in such a way. For those situations
we suggest using a separate \teacontext for each \client.

\item
\teacontext -
Object binding context for executing \tea code
(ie. the bindings between variables/values for \tea scripts executed
under the \iteaserver).

Recall that the \tea language supports integers, floats, strings,
symbols, lists, vectors, hashtables, global variable bindings,
nested code blocks (code with local variable bindings), functions as first
class objects ({\tt lambdas}), programming modules (files defining
public and private functions and variable bindings), and object oriented
programming (class based with single inheritance). It has a simple syntax
and powerful semantics that allow a programmer to extend the language
based on the language itself.
As such, a program written in the \tea language can have very
complicated object structures.
(See documentation on the \tea language for more information).


\item
{\em Main Server Thread} -
The {\em Main Server Thread} accepts connections from the \cgiitea
and places them in the request queue. (The number of pending requests is
configurable by the programmer.)

\item
{\em Thread Pool} -
The {\em Thread Pool} contains a configurable number
of idle {\em threads}
waiting for requests to be placed in the {\em Request Queue}.
When an idle {\em thread} acquires a pending request, it:
\begin{enumerate}

\item
Identifies the \client by the HTTP cookie provided. If the \client has
no cookie, then it is a new \client and a new {\em Client Context} 
is created. A configurable operating mode parameter specifies if
the {\em Client Context} is given a new {\em Tea Interpreter Context},
or to reuse one. (Configurable parameters limit the number of
{\em Client Contexts} allowed and their idle lifetime.)

\item
Parses a document specified by the URL and configuration
parameters. This document can
be a single \tea script (wich is executed), or a textual document
(HTML for example) with embedded \tea script blocks.
Each \tea script block runs under the appropriate
{\em Tea Interpreter Context}
and has access to the {\em Client Data}
(private for this \client) through the \itea API.

\item
Flushes the data outputed during document parsing back to the
calling \cgiitea.

\end{enumerate}

\end{itemize}
The \iteaserver is dynamically linked with the \tea interpreter
code (also written entirely in \java) and with other \java
class libraries which give it access to whatever the
application programmer might need (JDBC for relational database
access, TCP/IP APIs, etc...)


A typical interaction with a \client goes like described in
figure ~\ref{fig-iteareq}.

\begin{figure}
\hfil
\iteareq
\hfil
\caption{HTTP request interaction}
\label{fig-iteareq}
\end{figure}


\begin{enumerate}
\item
The \client issues an HTTP request to the \webserver (by following
a link or submitting a form).

\item
The \webserver receives the HTTP request, and, if the URL requested
corresponds to a \cgiitea invocation, spawns the process and passes
it the information of the request (as defined by the \cgi specification).

\item
The \cgiitea spawned by the web server reads the HTTP request
information supplied by the \webserver, opens a TCP/IP connection
to the \iteaserver and passes it this information.

\item
The  {\em Main Server Thread} from the \iteaserver accepts the connection from
\cgiitea, reads the request parameters and places them in a request
queue.

\item
An idle {\em thread} picks up the request, selects the appropriate
\clientdata and \teacontext for this \client, and
parses the document specified by the URL, executing the whole document
as \tea script, or expanding text embeded \tea script blocks.

The \tea script blocks can access the request parameters,
access the {\em Web Client}'s private \clientdata and manipulate
its own variables in its \teacontext and dynamically import and
use \tea or \java libraries.
Requests are serialized for each \client, so there is usually
no need to worry about concurrency when manipulating these resources.

At any time, the script can output data through \itea API function
calls and libraries to be sent back to the \client.

\item
The \cgiitea reads the output from the \iteaserver, and
passes it back to the \webserver, closes its connections and
dies.

\item
The \webserver passes the \cgiitea output back to the browser
(which should render it on the user's browser window),
closes its HTTP connection, and it is ready for another request.

\end{enumerate}





\section{Client Session Management}

One of the key strengths of \itea lies in its pre-defined
automated policies of \client context management.

\itea automatically identifies every browser with an HTTP cookie
key (setting it only once at the beginning of the client's session),
and from there on it manages its internal context data pools
for each HTTP request automatically. The programmer has no need
to worry about identifying separate client sessions.

\itea provides a simple {\em get/set key value} API for
storing simple \clientdata state information.
In some cases, this is enough to easily store client dependent
application state.
In such cases, the programmer can configure the \iteaserver to
have a limited pool of \teacontext, which can be used to cache
data and code common to all users.

In the cases where the effort for serializing individual
\client application state is considered high, it is recommended that the
programmer configures the \iteaserver to allocate a private
\teacontext for each \client session. In this case, the
programmer sees a full client-server programming model, where,
each \client appears to have a single server process just to
itself.

As a simple example of \itea code for a simple HTML counter.
Tme implementation is exptrmely simple. Just a library
file {\tt counter.tea}
\begin{verbatim}
   define counter 0
   # Like C's "static int counter = 0;"

   global incrementAndPrint () {
      set! counter [+ $counter 1]
      doc-print $counter
   }
   # Like C's "void incrementAndPrint() {
   #    counter = counter + 1;
   #    printf("%d", counter);
   # }"
\end{verbatim}
and the server side parsed HTML file {\tt counter.html}
\begin{verbatim}
    <HTML><BODY>
    Counter value is: <!--@
        import "counter.tea"
        incrementAndPrint
    --></BODY></HTML>
\end{verbatim}
Each \client sees its own counter, and every time they attempt to read
{\tt counter.html} \itea identifies the \client and chooses apropriate
context for the variable {\tt counter}.

In this latest case, as \tea and \java libraries are dynamically
imported for each \client session, for large software projects
the time spent on importing vast library definitions can become
high. \tea supports a library {\em import-on-demand} feature to
ease such problem, but, besides that, \itea supports an operating
mode where each \teacontext can be reused for another \client
when the previous client has releases the session (though logout
or timeout). Such a new session already has all the libraries
from the previous \client imported.







\section{Software Libraries}

\itea is supplied with object oriented libraries written in \tea
which allow representation of HTML documents (including form elements)
and processing of HTTP requests as event trigger functions or
object method callbacks.

\begin{figure}
\hfil
\itealib
\hfil
\caption{I*Tea Software Libraries}
\label{fig-itealib}
\end{figure}

These libraries can be extended (for example,
using inheritance and delegation programming patterns) allowing
the programmer to easily build problem specific object oriented
models, adding problem specific logic.
Several object-oriented programming patterns have already been
developed to help editing, validating and displaying form data.
Also, HTTP file upload, {\em on-the-fly} generation of graphic
images and seamless integration with {\bf Java Applets} and client side
{\bf Java Script} has been done with full success.

On the backend side of the application, the full power of the
\java language (existing libraries and standard APIs)
is available through the \tea language. (Writing of mapping APIs
onto the \tea language might be required).






\section{Fast Development and Maintenance}

\tea is an interpreted scripting language recommended for
fast prototyping, and supports many programming
paradigms which allow it to scale well for larger
software projects.
An \iteaserver parses documents dynamically, so there is no need 
to recompile anything after changing \tea source code.

\itea has a policy of caching parsed documents, only
re-interpreting them if the modification date has changed.
Careful use of this feature allows expert site
administrators (which also know the software
architecture of the application and how \tea caches
libraries) to change code/patch on line applications without
any visible disturbance for on-line clients.




\section{Performance and Scalability}

Running over JDK 1.2.1 on Solaris 2.6
on a SPARC CPU at 300Mhz, an \iteaserver version 1.4 takes
aprox. 40 miliseconds to process an HTTP request, rendering
simple HTML pages through its HTML library. This value
can be taken as a reference value of \itea overhead
for each request.
For a more complex page, the time will increase with the number
of HTML objects rendered and backend processing required.

A single \iteaserver based on a CPU at 400Mhz
has been used in call-center helpdesk
situations with more than 40 simultaneous
clients, with an average of 3 HTTP requests per second (typical 
request frequency ranges from 1 to 5 requests per second).

It performs acceptably well, and it  can scale as well if needed.
Besides brute-force CPU power increase, \itea applications
can achieve scalability through:
\begin{itemize}
\item
Vertical Scalability -
If the {\bf Java Virtual Machine} and native operating system support
multi-processing through \java threads, then the performance of the
\iteaserver scales through symmetric multi-processing processing power
increase.

\item
Horizontal Scalability -
Replication of an \iteaserver running identical copies of the same
application accessing the same backend (a relational database)
has been successfully tested over a network of cheap PCs.
The load balancing intelligence has been coded in the \cgiitea.
\end{itemize}

\begin{figure}
\hfil
\itearep
\hfil
\caption{I*Tea Horizontal Scaleable Architecture}
\label{fig-itearep}
\end{figure}




\section{The Future into J2EE\protect\footnotemark[1]}

\itea was conceived in early 1997 to replace \cgi
programming and other resource consuming application server
alternatives available at the time.

Today, the standardization of the Java Servlet API and Java Server
Pages into the Java 2 Platform Enterprise Edition by
Sun Microsystems point the way to go for large multi-tiered
applications, with middle tiers on Enterprise Java Beans. Nevertheless
we feel clearly the need for a
fast proototyping scripting language like \tea, specially for
developping Web front-ends.

For this reason, \tea is being extended for writing
Enterprise Java Beans client applications, and running existing
\itea application code under a Servlet/Java Server Pages environment is
under study (already demonstrated experimentally).







\section{Summary}

\itea is a low resource consumption (disk space)
application server for fast development of Web Applications
using the simple but powerful \tea scripting language.

The power of the built-in web session management policies
of \itea, combined with the power of the \tea language and
being entirely based on the \java platform, allows quick web
prototypes evolve as commercial quality production applications.
It has been successfully tested in large projects (more
then one 300000 lines of code in a single project) such as:
\begin{itemize}

\item Web HomeBanking

\item Internet Service Provider Management
(including both customer self-care, call-center,
and enterprise management interfaces)

\item On-Line Brokerage

\item Portal management

\item Custom Enterprise Management Applications
(Customer/service database interface, billing, call-center
web support, etc...)

\end{itemize}

\end{document}

