% % 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} Counter value is: \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}