A Comparative Study of Web Application Design

Models Using the Java Technologies 1st edition

by Budi Kurniawan, Jingling Xue ISBN 3540213710
978-3540213710 install download
https://ebookball.com/product/a-comparative-study-of-web-
application-design-models-using-the-java-technologies-1st-
edition-by-budi-kurniawan-jingling-xue-
isbn-3540213710-978-3540213710-12688/

Explore and download more ebooks or textbooks

at ebookball.com
 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Java for the Web with Servlets JSP and EJB 1st edition by Kurniawan
Budi ISBN 073571195X 9780735711952

https://ebookball.com/product/java-for-the-web-with-servlets-jsp-
and-ejb-1st-edition-by-kurniawan-budi-
isbn-073571195x-9780735711952-12630/

An Efficient Multidimensional Data Model for Web Usage Mining 1st

edition by Edmond Wu, Michael Ng, Joshua Huang ISBN 3540213710
9783540213710

https://ebookball.com/product/an-efficient-multidimensional-data-
model-for-web-usage-mining-1st-edition-by-edmond-wu-michael-ng-
joshua-huang-isbn-3540213710-9783540213710-10862/

Full Stack AngularJS for Java Developers Build a Full Featured Web
Application from Scratch Using AngularJS with Spring RESTful 1st
Edition by Ravi Kant Soni ISBN 1484231988 9781484231982

https://ebookball.com/product/full-stack-angularjs-for-java-
developers-build-a-full-featured-web-application-from-scratch-
using-angularjs-with-spring-restful-1st-edition-by-ravi-kant-
soni-isbn-1484231988-9781484231982-16168/

Java Web Services Using Java in Service Oriented Architectures 1st

Edition by David A Chappell, Tyler Jewell ISBN 0596002696
9780596002695

https://ebookball.com/product/java-web-services-using-java-in-
service-oriented-architectures-1st-edition-by-david-a-chappell-
tyler-jewell-isbn-0596002696-9780596002695-11376/
Business Web Strategy Design Alignment and Application 1st Edition by
Latif Al Hakim, Massimo Memmola 1605660248 978-1605660240

https://ebookball.com/product/business-web-strategy-design-
alignment-and-application-1st-edition-by-latif-al-hakim-massimo-
memmola-1605660248-978-1605660240-14160/

Web Application Security, a Beginner's Guide 1st edition by Bryan

Sullivan, Vincent Liu ISBN 0071776168 978-0071776165

https://ebookball.com/product/web-application-security-a-
beginner-s-guide-1st-edition-by-bryan-sullivan-vincent-liu-
isbn-0071776168-978-0071776165-16468/

Data Structures Abstraction and Design Using Java 1st edition by

Elliot Koffman, Paul Wolfgang ISBN 0470128704 978-0470128701

https://ebookball.com/product/data-structures-abstraction-and-
design-using-java-1st-edition-by-elliot-koffman-paul-wolfgang-
isbn-0470128704-978-0470128701-16346/

Web Animation using JavaScript Develop and Design 1st Edition by

Julian Shapiro ISBN 0134096703 9780134096704

https://ebookball.com/product/web-animation-using-javascript-
develop-and-design-1st-edition-by-julian-shapiro-
isbn-0134096703-9780134096704-16170/

Global Networks and Local Values A Comparative Look at Germany and the
United States 1st Edition by Committee to Study Global Netoworks ISBN
9780309171298

https://ebookball.com/product/global-networks-and-local-values-a-
comparative-look-at-germany-and-the-united-states-1st-edition-by-
committee-to-study-global-netoworks-isbn-9780309171298-11726/
A Comparative Study of Web Application Design Models
Using the Java Technologies

Budi Kurniawan and Jingling Xue

School of Computer Science and Engineering

University of New South Wales
Sydney, NSW 2052, Australia

Abstract. The Servlet technology has been the most widely used technology for
building scalable Web applications. In the events, there are four design models
for developing Web applications using the Java technologies: Model 1, Model
2, Struts, and JavaServer Faces (JSF). Model 1 employs a series of JSP pages;
Model 2 adopts the Model-View-Controller pattern; Struts is a framework
employing the Model 2 design model; and JSF is a new technology that
supports ready-to-use components for rapid Web application development.
Model 1 is not recommended for medium-sized and large applications as it
introduces maintenance nightmare. This paper compares and evaluates the ease
of application development and the performance of the three design models
(Model 2, Struts, and JSF) by building three versions of an online store
application using each of the three design models, respectively.

1 Introduction

Today, Web applications are the most common applications for presenting dynamic
contents. There are a number of technologies for building Web applications, the most
popular of which is the Servlet technology [5]. This technology gains its popularity
from its superiority over other technologies such as CGI and PHP [2], [3], [13].
Servlets are cumbersome to develop, however, because sending HTML tags
requires the programmer to compose them into a String object and send this object to
the browser. Also, a minor change to the output requires the servlet to be recompiled.
To address this issue, Sun Microsystems invented JavaServer Pages (JSP) [4]. JSP
allows HTML tags to be intertwined with Java code and each page is translated into a
servlet. A JSP page is a servlet. However, compilation occurs automatically when the
page is first requested. As a result, changing the output does not need recompilation.
In addition, JSP enables the separation of presentation from the business logic through
the use of JavaBeans and custom tag libraries. The norm now in developing Java-
based Web applications is to use servlets along with JavaServer Pages.
In the later development, there are a number of design models for building
servlet/JSP applications: Model 1, Model 2, Struts [12], and JSF [6]. Model 1 and
Model 2 were first mentioned in the early specifications of JSP. Model 1 strictly uses
JSP pages, with no servlets, and Model 2 uses the combination of both servlets and
JSP pages. The terms of Model 1 and Model 2 have been used ever since. Model 1 is

J.X. Yu, X. Lin, H. Lu, and Y. Zhang (Eds.): APWeb 2004, LNCS 3007, pp. 711–721, 2004.
© Springer-Verlag Berlin Heidelberg 2004
712 B. Kurniawan and J. Xue

suitable for prototypes and very small applications, and Model 2 is the recommended
design model for medium sized and large applications.
As Model 2 gained more acceptances in the industry, an open source initiative to
build the Struts Framework was initiated. Struts perfects Model 2 by providing the
controller part of the Model-View-Controller of Model 2. In addition, Struts provides
better page navigation management and several custom tag libraries for more rapid
development. Despite its steep learning curve and the fact that it was never defined in
any specification, Struts has been gaining popularity as the alternative to Model 2.
JavaServer Faces [6] is built under the Java Community Process under JSR-127.
Sun Microsystems proposed this technology in the hope that JSF will be the ultimate
model for building Java Web applications. The most important feature of JSF is the
availability of ready-to-use components such as extensible UI components, easy page
navigation, input validators, data converters and JavaBeans management.
The problem facing servlet/JSP programmers are to choose the most appropriate
design model. Clearly, JSF provides a better solution in regard to development time.
However, some people are not sanguine to adopt this technology for fear of
performance penalty due to the overhead of the JSF implementation.
We build three versions of an online store application named BuyDirect using
Model 2, Struts and JSF. The parameters compared are the number of lines of code,
the number of classes, and the performance measurement results. We investigate
which of the design models allows the most rapid development process. We evaluate
the performances of the applications built upon these models. We provide some
suggestions to perfect the existing design models to make development more rapid.
The rest of the paper is organised as follows. Section 2 discusses the issues in Web
development. Section 3 explains how the three design models address these
development issues. Section 4 provides the details of the hardware and software used
in these experiments. Section 5 presents the experiment results and analysis. Section 6
reviews the related work. Section 7 concludes by offering some suggestions to
improve the existing design models.

2 Java Web Development Issues

All Java Web development uses the Servlet technology as the underlying technology.
As such, all Java Web applications have certain issues that need to be addressed:
− User Interface. The user interface is what the client browser renders as HTML
tags. Any server-side component used in the application must be encoded into the
corresponding HTML elements. Besides for displaying the content and data, the
user interface is also responsible in receiving input from the user.
− Input Validation. User input needs to be validated. There are two types of input
validation, server-side and client-side. As the name implies, the server-side input
validation is performed on the server after the input reaches the server. Client-side
input validation is done on the browser, usually by using JavaScript or other
scripting languages. The advantages of using client-side input validation are
prompt response and reducing the server workload. The server-side input
validation should always be performed regardless the presence of client-side
validation because there is no guarantee the user browser's scripting feature is
being on and malicious users can easily work around client-side validation.
 A Comparative Study of Web Application Design Models 713

− Model Objects. Model objects in Java-based Web applications are in the forms
of JavaBeans. Model objects make up the Model part of the MVC based design
model. A model object can be used to bind a component value to be used at a later
stage. In addition, it can encapsulate business logic required for processing.
− Page Navigation. Almost all Web applications have multiple pages that the user
can navigate from one to another. All MVC-based design models use a servlet as
the Controller part. This servlet also acts as the sole entry point to the application.
Which page to be displayed after the current request is determined by the value of
a specified request parameter. Managing page navigation is critically important.

3 Web Application Design Models

The Model 2 design model is based on the Model-View-Controller (MVC) design

pattern. As explained by Burbeck [1], there are three main modules in MVC, the
Controller, the View, and the Model. The Controller acts as the central entry point to
the application. All user interactions go through this controller. The View contains the
presentation part of the application, and the Model stores data or encapsulates
business logic of the application. In the later development, the Struts Framework
provides a common framework to easily build Model 2 applications. Then, the last
initiative is the JavaServer Faces, which also employs the MVC design pattern.
In the following sections, we discuss these three design models and explain how
each design model addresses the development issues specified in the previous section.

3.1 Model 2

A Java Web application that is based on the Model 2 design model has one servlet
(called the Controller servlet) that serves as the Controller part. All requests are first
handled by this servlet, which immediately dispatches the requests to the appropriate
views using RequestDispatcher objects. Views in the Model 2 design model are
represented by JSP pages. To store data, a Model 2 application uses JavaBeans, which
are the Model part of the application. In addition to storing data, the JavaBeans also
encapsulate business logic. Each HTTP request carries an action parameter that
indicates which view to dispatch this request to. The programmer must code the
HTML tags for user interface in all JSP pages in the application and write input
validation code. In addition, the model objects are managed by individual JSP pages.

3.2 Struts

The Struts Framework is an improvement of the Model 2 design model. It provides a

default Controller servlet so that the user does not have to write and compile one.
Struts alleviates the task of page navigation by allowing navigation rules to be present
in its application configuration file (an XML document). Changes to the navigation
rules do not require recompilation of a Java servlet class. In addition to easier page
navigation, Struts provides custom tag libraries that define tags representing HTML
elements. One of these tags is used for error handling and Struts is therefore capable
714 B. Kurniawan and J. Xue

of displaying localized error messages in support for internationalization. Struts

applications use JavaBeans as their models, just like the Model 2 design model. In
addition, Struts programmers have to write their own input validation code.

3.3 JSF

JSF also employs a controller servlet that is called FacesServlet. This servlet is the
only entry point to a JSF application. JSF also uses JSP pages as its views and
JavaBeans as its model objects. Unlike Model 2 and Struts, however, JSF provides
ready-to-use user interface components that can be written on JSP pages. Upon an
invocation of a page of a JSF application, the FacesServlet constructs a component
tree that represents the JSP page being requested. Some of the components can also
trigger events, making JSF event-driven. For page navigation, JSF uses an approach
similar to Struts, i.e., by allowing navigation rules to be defined in an application
configuration file (again, an XML document).
What distinguishes a JSF application from non-JSF servlet/JSP application is that
JSF applications are event-driven. The user interface of a JSF application is one or
many JSP pages that host Web components such as forms and input boxes. These
components are represented by JSF custom tags and can hold data. A component can
be nested inside another, and it is possible to draw a tree of components. Just as in
normal servlet/JSP applications, you use JavaBeans to store the data the user entered.

4 Experimental Setup

The software and hardware details for our experiments are described below.

4.1 The Online Store Application

The online store application in this research comes in three versions: Model 2, Struts,
and JSF. All of them are named BuyDirect, an online store that sells electronics
goods. The application has the following features:
- Search for certain products based on product names or descriptions.
- Browse the list of products by category.
- View a product's details
- Put a product into the shopping cart.
- View the shopping cart
- Check out and place an order.

This application represents the most common Web application that provides the
following functionality:
- searching for certain information in the database
- browsing the data in the database,
- performing database transactions.
Data is stored in a MySQL database. The tables used and the relationship among
them are depicted in Figure 1.
 A Comparative Study of Web Application Design Models 715

Fig. 1. The tables and relationships among them

4.2 The Servlet Container

A Java Web application runs in a servlet container, which is the engine that processes
the incoming HTTP requests for the resources in the application. For this research
project, we use Tomcat, an open source servlet container from the Apache Software
Foundation. The version we use is 5.02 [11].
Basically, a servlet container processes a servlet by performing the following tasks:
- Creating the HttpRequest Object
- Creating the HttpResponse Object
- Calling the service method of the Servlet interface, passing the HttpRequest and
HttpResponse objects.

4.3 Testing Clients

For performance testing, we emulate multiple users using JMeter 1.9 [9], also from
the Apache Software Foundation. JMeter allows the user to choose the number of
threads to perform testing. Each thread emulates a different user. JMeter also lets us
choose how many times a test will be done. To test a Web application using JMeter,
you direct requests to certain IP address, context path, and port number. You can also
specify request parameters to be included in each HTTP request. As the output,
JMeter notifies the response time of the server in milliseconds for a test. From the
response time, we derive the number of hits/seconds the server is capable of serving.

4.4 Hardware

We use different computers for running the applications and for testing, so as to
obtain maximum performance measurement accuracy. The computer running the
application is a Linux machine having the following hardware specifications: Intel
Pentium III 750MHz CPU with 256MB RAM. The computer running the testing
clients is a Windows 2000 machine running JMeter. The computer has the following
specifications: Intel Pentium III 850MHz CPU with 256MB RAM.
716 B. Kurniawan and J. Xue

5 Experimental Results

We obtain experimental results in two categories: the ease of development and

performance. The ease of development category compares the number of classes and
the number of lines of code. These numbers indicate how easy it is to develop an
application by following a certain design model. An application with the fewer
number of classes or the number of lines of code indicates that the application is
relatively easier to build. The application with the more number of classes indicates
that the application takes more time to develop.
The performance measurement results are obtained by comparing three operations
in each version of the online store application: Search, Browse, and Shopping. The
Search operation is the most common operation in such an application. The Browse
operation displays products by category, and the Shopping operation is the most
complex operation of all. It includes filling in the Order form and inserting products
in the shopping cart to the database. The database is locked during the product
insertion, so either all shopping items are stored in the database or none of them is.

5.1 Ease of Application Development

As Table 1 shows, it takes the most effort to implement the Model 2 design model.
Using Struts alleviates the problem a bit, and the best saving in the development
comes if one uses JSF.

Table 1. The number of classes and the number of lines for the applications under study

Model 2 Struts JSF

Servlet #Classes 1 0 0
#Lines 74 0 0
Bean #Classes 9 9 9
#Lines 348 348 348
JSP #Classes 9 9 9
#Lines 809 733 534
Others #Classes 12 10 3
#Lines 590 430 271
Total #Classes 31 28 21
#Lines 1821 1511 1153

The Model 2 design model is characterised by the presence of a Controller servlet

and a number of JavaBeans classes (as the Model) and JSP pages (as the Views). The
Controller servlet is responsible for page navigation rules that employ a series of if
statements. Model 2 application programmers must also code for the input validation
that in this research is implemented inside a number of custom tag libraries. The other
classes in the Model 2 design model are custom tag library and the tag library
descriptors responsible for input validation and data display. In fact, input validation
takes 590 lines of code, or almost 30% of the total amount of code.
In the Struts application, the Controller servlet is provided by the framework,
therefore a Struts programmer saves time for not having to write one. However,
he/she still needs to write page navigation rules in the Application Configuration file,
which is easier than writing a servlet because the Application Configuration file can
 A Comparative Study of Web Application Design Models 717

be edited using a text editor and no compilation is necessary. Input validation must
still be done manually, even though the Struts Framework provides an error handling
mechanism. The number of classes and the number of lines of code for input
validation are almost similar to the Model 2 application. In Struts, the other classes
are Action classes to which the default Controller servlet dispatches requests.
In JSF input validation comes free through the availability of validator component.
As a result, a JSF application developer can skip this task. In addition, page
navigation takes the same course as Struts, i.e. by utilising an Application
Configuration file. The other classes in JSF are a ContextListener, an ActionListener,
and a Database utility class.

5.2 Performance Measurement

For each operation, we measure the server response time (in milliseconds) for 1 to 10
concurrent users. The number of users is specified by setting the number of threads in
Jmeter. Each test is conducted 10 times and the average is taken. Each operation is
discussed further is the following sub-sections.

5.2.1 Search Operation

The Search operation retrieves all products whose name or description matches the
keyword. There is one SQL SELECT statement performed. Figure 2 compares the
three versions of applications for the Search operation.

Search Operation

1000
Model 2
900
Struts
800 JSF
Server Response Time (ms)

700

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9 10
Number of Concurrent Users

Fig. 2. The performance comparison for the Search operation

For the Model 2 application, the average server response time for one user is 173
ms and for 10 users is 919 ms. For the Struts application, these numbers are 189 ms
and 900 ms, respectively. For the application built using JSF, the average server
response time is 210 ms for one user and 932ms for 10 users. The increase of the
response time is proportional to the increase of the number of concurrent users, which
means that the server is still able to cope with the load.
The Model 2 application has the least overhead, therefore the average performance
should be better than the Struts and JSF applications. However, the Struts application
performs as well as the Model 2 application. This is because the server has enough
memory to load all Struts libraries required to run Struts. Also, note that page
navigation rules in Struts are loaded and stored in an object called ActionMapping.
718 B. Kurniawan and J. Xue

Therefore, given an action request parameter, the next page of navigation is obtained
through a look-up. On the other hand, the Model 2 application uses a series of if
statements to find the next page of navigation, given the action request parameter.
The JSF application performs slightly worse than the other applications in almost
all numbers of concurrent users. This could be due to the time taken by the JSF
implementation to construct a component tree for each page requested. However, the
difference in server response time between JSF and other applications is not that
significant.

5.2.2 Browse Operation

The Browse operation retrieves all products belonging to the specified category for
the three versions of applications. Like the Search operation, there is one SQL
SELECT statement performed. Figure 3 gives the test results for this operation.

Browse Operation

1200
Model 2
Server Response Time (ms)

1000 Struts
JSF
800

600

400

200

0
1 2 3 4 5 6 7 8 9 10
Number of Concurrent Users

Fig. 3. The performance comparison for the Browse operation

On average, the Model 2 application performs the best because it has the least
overhead. The average server response time is 111 ms for one user and 899 ms for 10
users. The Struts application has comparable performance, with one user average
server response time of 180 ms and 10 user response time of 920 ms. The JSF lacks a
bit behind the two applications with these numbers being 190 and 1009 ms
respectively.
The increase of the server response time is proportional to the increase of the
number of concurrent users, which means the server is able to serve those users well.
The average performance measurement results of the Browse operation are very
similar to the ones for the Search operation because the database operations of both
operations are also similar.

5.2.3 Shopping Operation

This operation includes a database transaction with an insert into the Orders table and
multiple inserts into the OrderDetails table. The transaction either succeeds or fails as
a whole. Figure 4 shows the test results for this operation.
The Model 2 application results in an average server response time of 230 ms for
one user and 2088 ms for 10 users. The Struts application scores similar results with
238 ms and 2033 ms for both one user and 10 concurrent users. The JSF application
takes an average of 240 ms to server one user and 2227 ms for 10 concurrent users.
 A Comparative Study of Web Application Design Models 719

Shopping Operation

2500
Model 2

Server Response Time (ms)

Struts
2000
JSF

1500

1000

500

0
1 2 3 4 5 6 7 8 9 10
Number of Concurrent Users

Fig. 4. The performance comparison for the Shopping operation

Figure 4 shows that in all applications, a linear increase in the number of concurrent
users causes an almost exponential increase in the average server response time. This
is due to the lock in the database during the database transaction that causes
subsequent requests to be queued until the database lock is released.
Performance comparison for the Model 2, Struts, and JSF applications for the
Shopping operation is almost the same as the Search and Browse operations. Model 2
and Struts perform similarly, while the JSF application is worse. However, the
difference between the JSF application and the other two is not significant.

6 Related Work

Wu et al [13] compare the performance of database-based Web applications using

Java servlets, PHP version 3, and Common Gateway Interface (CGI). After a series of
benchmark tests that performs data retrieval from a MySQL database, they find that
the solution of Java servlets with persistent database connection has the best
performance. PHP3 using persistent database connections performs fairly well when
compared to the CGI solution. They also mention the advantages of using Java
servlets. According to these authors. Java servlets are an excellent choice to meet the
requirement of e-commerce (such as online shopping) applications and are able to
handle client requests in a highly interactive mode. However, Wu et al. do not provide
analysis of the architectures of the system they are testing. Nor do they study the ease
of development and ease of maintenance aspects of those technologies.
Cecchet et al [2] conduct similar research, this time comparing PHP 4, Java
servlets, and Enterprise JavaBeans. They measure the performance of these three
architectures using two applications: an online bookstore and an auction site. The
online bookstore stresses the server back-end, whereas the auction site represents an
application with most workload on the server front end. Their study reveals that PHP4
is more efficient than Java servlets, and the EJBs perform even worse than servlets.
However, they note that servlets, being part of the Java solution, provides the
flexibility of being able to be ported to another system with a different operating
system. This research too does not compare design models of the same technology, as
we do. Neither does it offer an insight into the underlying code of the technologies.
720 B. Kurniawan and J. Xue

In a similar study, Cecchet et al [3] evaluate the performance and scalability of

EJB applications using two different open source J2EE containers, JBoss 2.4 [7] and
JOnAS 2.4.4 [9], as well as the performance of the EJB applications with servlet-
based solutions. They find that the servlets-only application they build performs the
best due to the fewer number of layer communications in the server. They find that
JOnAS 2.4.4 outperforms JBoss 2.4 because of the more efficient design of the J2EE
application server. This study is different from ours because it compares the
efficiency of the infrastructure software (the J2EE containers) as opposed to the
design models of the applications.
Also worth mention is the white paper from Sun Microsystems [10] that presents
the functionality comparison of Java servlets, PHP, and CGI.

7 Conclusion

We find that it is most rapid to build Web applications using JSF. Model 2
applications are the least rapid but give the best performance. Struts applications sit in
the middle of the other two design models in both comparisons.
We make some suggestions that could improve the Servlets technology in general
and enhance the performance of applications based on both design models.
− Struts. Struts is not based on any specification and there is no documentation that
discusses its internal working. Therefore, it is hard to know what have been
implemented and what could be improved.
− The Servlets Technology. The Servlet 2.3 Specification does not define any
caching mechanism. There is no mention of caching in the upcoming Servlet 2.4
Specification either. Despite the dynamic nature of the content of a Web
application, some contents do not change very often. For example, the categories
of products that a user can browse in an online store application probably only
change once in a month. If those semi-static contents must be generated from the
database every time they are requested, a lot of programming resources will be
wasted. Servlet programmers get around the absence of caching by writing an
object that caches certain content. However, since there is no standard for caching,
many programmers write the same piece of code again and again.
− Model 2.The main drawback is that the page navigation rules are hard-coded in the
Controller servlet. This means any minor change to the program flow will require
the Controller servlet to be re-compiled. The solution to this problem is to provide
a mapper that reads the page navigation rules when the application starts. The code
could be conveniently written in the init method of the Controller servlet. This
method is only executed once, i.e. the first time the servlet is loaded into memory.
If the properties file needs to be re-read every time it changes, the programmer can
check the timestamp of the properties file for each request, and compares it with
the previous read of this file. If the timestamp is more current than the previous
read, the mapper can be re-constructed. This feature can be enabled and disabled
by using an initial parameter in the Context object. At the development phase, this
feature should be enabled. At deployment, this feature should be off. The use of the
properties file to store the page navigation rules also makes it possible to avoid a
series of if statements in the Controller Servlet, which can be time-consuming for
 A Comparative Study of Web Application Design Models 721

every request. Instead, a HashMap can be used, with action request parameters as
keys and the next JSP pages as values. The other disadvantage of this design model
is the absence of standard components for input validation and user interface.
However, this has been solved in JSF.
− JSF. JSF provides solutions to common problems in Web development, such as
page navigation management, UI components and input validators. However,
because this technology is still very young, there are not too many UI components
available, forcing programmers to combine JSF with non-JSF servlets/JSP pages.
JSF is event-driven. JSF programmers determine the behavior of a JSF application
by writing event listeners, just like those listeners in a Swing application. In JSF
version 1.0, there are currently two types of events that can be triggered:
ActionEvent and ValueChangedEvent. However, this is good enough to provide
sufficient level of interactivity between the application and its users. Adding more
types of events will definitely make JSF more appealing.

References

1. Burbeck, S., Applications Programming in Smalltalk-80: How to use Model-View-

Controller (MVC), http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html, 1987.
2. Cecchet, E., Chanda A., Elnikety S., Marguerite J., Zwaenepoel W.: Performance
Comparison of Middleware Architectures for Generating Dynamic Web Content.
th
Proceeding of the 4 International Middelware Conference, 2003.
3. Cecchet, E., Marguerite, J., and Zwaenepoel, W.: Performance and Scalability of EJB
Applications. Proceedings of OOPSLA’02, 2002.
4. Java Servlet 2.3 and JavaServer Pages 1.2 Specification (JSR-053),
http://jcp.org/aboutJava/communityprocess/final/jsr053/.
5. Java Servlet 2.4 Specification (Proposed Final Draft 3),
http://jcp.org/aboutJava/communityprocess/first/jsr154/index3.html.
6. JavaServer Faces Technology, http://java.sun.com/j2ee/javaserverfaces/.
7. JBoss EJB server, http://jboss.org.
8. JMeter, http://jakarta.apache.org/jmeter/.
9. JOnAS: Java Open Application Server, http://www.objectweb.org/jonas.
10. Sun Microsystems, Comparing Methods for Server-Side Dynamic Content,
http://java.sun.com/products/jsp/jspservlet.html, 2000.
11. The Apache Software Foundation, http://www.apache.org.
12. The Struts Framework, http://jakarta.apche.org/struts/.
13. Wu, A., Wang, H., and Wilkins, D.: Performance Comparison of Alternative Solutions for
Web-To-Database Applications. Proceedings of the Southern Conference on Computing,
the University of Southern Mississippi, 2000.
Other documents randomly have
different content
 Sheet steel wing covering
Automatic pilot: 3 airdriven gyros: height & range setting controls
Pneumatic servo mechanism operating rudder & elevators

The German-developed V-1 was an automatically controlled pilotless

aircraft for use against Allied cities during World War II.

The missile was launched from ground ramps. Once in the air,
automatic controls on board the craft took over. The V-1 climbed to a
predetermined altitude, followed a compass course, and dove to the
ground after a preset distance had been covered.

This mid-wing monoplane was powered by a unique pulsejet engine

above the rear portion of the fuselage.

The relatively low speed of the missile made it easy prey for
antiaircraft guns or fighters.

The V-1 on exhibit is from the U.S. Air Force, Park Ridge Depot.

50
 German Antiaircraft Missiles

64. Rheintochter R-I (Rhine Maiden).

Rheintochter I
The Rheintochter I (Rhine Maiden) was intended for use against
Allied bomber formations late in World War II. The German ground-
to-air rocket was fin-stabilized, and controlled by radio. The flight of
the two-stage vehicle was controlled by the four movable vanes on
the nose of the craft.
The first stage carried the missile away from the launching rail, while
the second stage brought the missile up to full speed and propelled it
to the target.

Both the booster and sustainer engines used solid fuel. After a six-
tenths of a second burn, the booster dropped off and the sustainer
motor ignited. The missile warhead was housed at the rear of the
sustainer stage. Exhaust gases were expelled through six nozzles
located between the main fins.

The program was abandoned in December 1944, after 82

Rheintochter I rockets had been test fired. By then it had become
apparent that the missile could not reach the operational altitude of
modern bomber aircraft.

Hs-298

65. Hs-298.
The Hs-298 was designed to combat the Allied bomber threat to
wartime Germany. This air-to-air missile could be launched from
either fighter or bomber aircraft and was in quantity production early
in 1945.

It carried 45.4 kilograms (100 pounds) of high explosives that were

detonated by proximity fuse when the missile was within 9.1 meters
(30 feet) of an enemy airplane.

X-4

66. X-4.

The fin-stabilized X-4 air-to-air missile was guided to its target by

means of electrical impulses which passed through two wires
connecting the rocket to the launch aircraft until detonation. Once
the missile was on its way to the target bomber, the fighter pilot
directed its course with a separate small control stick in his cockpit.
Because the control wires streamed out ahead of the launching
aircraft, the pilot was prevented from evasive maneuvering.

Launched from German fighter aircraft, usually a FW-190, the X-4

was powered by either a solid-propellant engine or a bi-propellant
liquid-rocket engine. It carried a 20-kilogram (44-pound) warhead.

51
 Jupiter-C

67. Jupiter-C launches the first American satellite, January 31, 1958.

Jupiter-C carried the first successful American artificial earth satellite,

Explorer 1, into orbit on January 31, 1958. Jupiter-C launched
additional Explorer satellites on March 26 and July 26, 1958.

Jupiter-C, or Juno 1, is a modified version of the Redstone Ballistic

Missile and a direct descendant of the V-2 (A-4) rocket developed in
Germany during the second World War.

The vehicle’s main stage is powered by a rocket engine burning liquid

oxygen and a hydrazine mixture. The second and third stages are
contained in the “tub” on the nose of the rocket. Both use scaled-
down Sergeant solid-propellant rockets: eleven in the second stage
and three in the third. A final Sergeant motor is attached to the base
of the satellite to provide the velocity necessary to place the vehicle
in orbit. An electric motor spun the entire “tub” prior to launch and
during the climb into space in order to stabilize the satellite.

The Jupiter-C was built by the U.S. Army Ballistic Missile Agency.

52
Vanguard
 68. Three-stage Vanguard launch vehicle boosts the second
American satellite into Earth-orbit, March 17, 1958.

Standing 21.6 meters (70.8 feet) high and weighing more than
10,000 kilograms (20,000 pounds), the Vanguard launch vehicle
successfully orbited three satellites. The first was Vanguard 1,
launched on March 17, 1958.

The rocket has three stages. The first-stage motor, burning kerosene
and liquid oxygen, operated for 2 minutes and 20 seconds. The
second stage carried the vehicle to an altitude of 210 kilometers (130
miles), propelled by white-fuming nitric acid and unsymmetrical
dimethylhydrazine (UDMH). With propellants exhausted, the upper
stages then coasted to 480 kilometers (300 miles) above the surface
of the Earth where the solid-propellant third-stage motor fired to
place the satellite into orbit.

The Vanguard was designed and built by the Martin Company for the
U.S. Naval Research Laboratory.

53
 Scout

69. Four-stage Scout vehicle launches satellite from the Western Test
Range, California.
 70. Scout in vertical position prior to the launch of an Explorer
science satellite, April 29, 1965.

On February 16, 1961, Scout became the first solid-propellant vehicle

to orbit a satellite (Explorer 9). It is a four-stage launch vehicle that
can perform a variety of space and reentry research tasks. Its
relatively low cost has made it a popular choice for many satellite
programs, including Transit navigation satellites, the Small Astronomy
and Small Scientific Satellites, the Beacon Explorer, Hawkeye,
Micrometeoroid, Meteoroid Technology, and Solrad satellites. The
rocket has also been used extensively to launch foreign satellites.
ANS-A (Netherlands), GRP-A (Germany), UK-5 (England), Eole
(France), San Marco 5 (Italy), and the ESRO satellites for the
European Space Research Organization (now European Space
Agency) have all gone aloft aboard Scout launch vehicles.

The satellite in the nose of the Scout on exhibit is an INJUN/Air

Density Explorer identical to that launched from Wallops Island,
Virginia, on August 8, 1968.

Scout was built by the LTV Aerospace Corporation for the National
Aeronautics and Space Administration and the Department of
Defense.

The Scout is from the National Aeronautics and Space Administration

and LTV Aerospace Corporation.

54
Minuteman III
 71. Minuteman III launch from Vandenberg AFB, California.

The Minuteman III is the standard U.S. land-based intercontinental

ballistic missile. This three-stage solid-propellant missile is launched
from underground silos that are 24.4 meters (80 feet) deep and 3.7
meters (12 feet) in diameter. These missiles can be launched either
from underground control centers or by an airborne launch control
center installed in KC-135 aircraft.

Minuteman III was first test-fired on August 16, 1968, and has since
replaced earlier Minuteman series ICBMs in the operational system.
This missile was designed by Boeing for the Air Force Strategic Air
Command.

This missile is from the US. Air Force and Boeing Aerospace
Corporation.

55
 Poseidon C-3

72. Launch of Poseidon from nuclear-powered submarine.

This two-stage solid-propellant Fleet Ballistic Missile is launched

underwater from nuclear-powered submarines. The Poseidon is
launched by compressed air, with first-stage ignition just after the
missile is clear of the hull. Poseidon carried the Mk-3 Multiple
Independently targeted Reentry Vehicles (MIRV)—thermonuclear
weapons which enable a single missile to cover a number of targets.

The first successful test flight of Poseidon was from Cape Canaveral
on August 16, 1968, and the first submarine launch was from the
U.S.S. James Madison on August 3, 1970.

The Poseidon C-3 is from the U.S. Navy and Lockheed Aircraft
Corporation.

56
 Skylab

73. Closeup view of Skylab space-station cluster photographed

against a black-sky background from the Skylab 3 Command Module
during the “fly around” inspection prior to docking.

Launched into earth orbit on May 14, 1973, Skylab was a research
center that housed three-man crews on three different visits to the
space station. The longest mission lasted nearly three months.

Equipment and experiments on board the orbiting station were

designed to accommodate four areas of research: earth observation
to further knowledge of natural resources and the earth’s
environment; solar observation to increase understanding of solar
processes and influences on earth’s environment; study of the effects
of long duration weightlessness on man, basic biological processes
and adaptability to space flight conditions; and experiments in
processing of materials under the unique conditions of weightlessness
and vacuum environment of space. All missions were highly
successful in obtaining data and photographs.

Skylab consisted of four major components: the Orbital Work Shop

(OWS), Airlock Module (AM). Multiple Docking Adapter (MDA), and
the Apollo Telescope Mount (ATM).

The cylindrical Orbital Work Shop is 15 meters (48 feet) in length and
6.5 meters (22 feet) in diameter. The workshop is divided into two
major areas by an open-grid partition. By wearing special shoes, the
astronauts can use this grid to anchor themselves in the 57
weightlessness of space. The lower portion contains the crew
quarters, food preparation and dining areas, washroom, and waste
processing and disposal facilities.
 74. Orbital Workshop crew-quarters installations.

I
M131 chair control
Sleep compartment 70 sq ft
II
Head 30 sq ft
Wardroom 97 sq ft
III
M507 gravity substitute work bench
Experiment compartment 181 sq ft
M171 gas analyzer
M171 helmet stowage
ESS
IV
M092 LBNPD
Electric power control console
M131 rotating chair
The upper portion contains a large work-activity area, water-storage
tanks, food freezers, film vaults, and experiment equipment.

The Airlock Module enabled spacesuited crew members to make

excursions outside the Skylab to replace or adjust equipment, change
film, or carry out other extra-vehicular activities. This capability was
vital to emergency repairs by the astronauts on the first mission. The
Airlock Module was attached to the OWS and passage to the module
was accomplished through a hatch which connected the module to
the interior of the workshop. When an astronaut entered the module,
he would vent the atmosphere of the module into space. When the
pressure in the airlock reached zero, the crew member could open
the outer hatch and float out into space.

75. Airlock Module.

The Multiple Docking Adapter (MDA) was used by crews arriving or

departing from the Skylab workshop. The Apollo command/service
modules delivered crews to the MDA from which the astronauts could
enter Skylab through the hatch in the docking port. In an emergency,
two command/service modules could dock at the MDA. The MDA also
held equipment for earth resources multispectral photography,
materials processing, and astronomy. The Apollo Telescope Mount
(ATM) was on top of and controlled by the MDA. It contained six
astronomical instruments to obtain information about the Sun.

76. Multiple Docking Adapter.

Solar energy is the prime source of electric power on Skylab. Two

systems of solar electric-cell arrays—one wing on the OWS and four
panels on the ATM—deployed after the Skylab reached orbit. Principal
contractors: OWS—McDonnell Douglas Astronautics Company; AM—
McDonnell Douglas Astronautics Company; MDA—Martin Marietta
Aerospace.

The Skylab components on display were presented to the museum by

the National Aeronautics and Space Administration.

58
 Apollo-Soyuz Test Project

77. Artist conception of the Apollo-Soyuz Test Project rendezvous.

On May 24, 1972, President Richard Nixon and Aleksey Kosygin,

Chairman of the USSR Council of Ministers, signed an agreement
“concerning cooperation in the exploration and use of outer space for
peaceful purposes.” The signing represented a formal endorsement of
negotiations that had been held between the two nations over
several years. The agreement established the Apollo-Soyuz Test
Project (ASTP) to develop and fly a standardized docking system “to
enhance the safety of manned flight in space and to provide the
opportunity for conducting joint scientific missions in the future.”

On July 15, 1975, the afternoon countdown for the Soviet launch was
completed and Soyuz lifted off from the Baykonur complex near
Tyuratum in Central Asia, some 3200 kilometers (2000 miles)
southeast of Moscow. Soyuz carried cosmonauts Alexey Leonov and
Valeriy Kubasov.

Taking advantage of Apollo’s larger fuel supply for maneuvering,

Apollo followed Soyuz into orbit 7½ hours later. Apollo was launched
atop a Saturn 1B from Kennedy Space Center, Florida.

After careful maneuvering, the two craft linked up around noon on

July 18. Some 225 kilometers (140 miles) above Earth, the astronauts
and cosmonauts visited each other’s craft, performed joint
experiments, and made further tests of the new docking system.

Following the undocking Saturday, Apollo fired its engines briefly and
moved away from Soyuz. Soyuz descended from orbit and landed in
the south-central USSR early Monday morning, July 21.

Astronauts Stafford, Slayton, and Brand remained in orbit conducting

research and making science demonstrations. Splashdown into the
Pacific Ocean occurred in late afternoon on Thursday, July 24.

The historic ASTP mission was accomplished by using existing

systems and a new docking module. The Apollo spacecraft was made
available when the lunar-landing program was curtailed. Since the
command module was built with a docking system designed to work
only with U.S. spacecraft, a method of incorporating the new docking
system had to be devised.

A second important problem was the difference between the

spacecraft atmospheres. The Apollo used a pure oxygen atmosphere
at about one-third of the atmospheric pressure on earth’s surface;
Soyuz used a nitrogen-oxygen mixture at normal atmospheric
pressure. To permit crews to pass from Soyuz to Apollo without 59
suffering from the “bends” (a painful condition experienced
when nitrogen gas bubbles form in the body fluids), engineers had to
design an airlock to equalize the pressure.

78. The Soviet Soyuz atop a three-stage launch vehicle lifts off July
15, 1975, to begin the joint US-USSR space mission.
79. Overhead view of Soyuz in orbit, photographed from the Apollo
spacecraft during the joint mission. The three major components of
the Soyuz are the spherical Orbital Module, the bell-shaped Descent
Vehicle, and the cylindrical Instrument-Assembly Module from which
two solar panels protrude.
80. View of Apollo spacecraft as seen in Earth-orbit from Soyuz. The
Command/Service Module and Docking Module are contrasted
against a black-sky background and the horizon of the Earth is below.

The docking module, 3 meters long and 1.5 meters in diameter (10
feet long and 5 feet in diameter), also solved the problem of
incompatible docking mechanisms by carrying the new docking
system on one end and a system compatible with Apollo on the other.

Prime contractor for Apollo Command Module, Service Module, and

Docking Module was Rockwell International.

The Apollo hardware is from the National Aeronautics and Space

Administration, and the Soyuz spacecraft is on loan from the USSR
Academy of Sciences.
 Apollo
Command module
Base diameter 3.90 m. (12.8 ft.)
Length 3.66 m. (12 ft.)
Weight 5896 kg. (13,000 lb.)
Service module
Diameter 3.9 m. (12.8 ft.)
Length 6.71 m. (22 ft.)
Weight at launch 24,947 kg. (55,000 lb.)
Docking module
Diameter 1.52 m. (5 ft.)
Length 3.05 m. (10 ft.)
Weight 1882 kg. (4155 lb.)
Soyuz
Orbital module
Diameter 2.29 m. (7.5 ft.)
Length 2.65 m. (8.7 ft.)
Weight 1224 kg. (2700 lb.)
Descent module
Diameter 2.29 m. (7.5 ft.)
Length 2.20 m. (7.2 ft.)
Weight 2802 kg. (6200 lb.)
Instrument module
Diameter 2.77 m. (9.75 ft.)
Length 2.29 m. (7.5 ft.)
Weight 2654 kg. (5850 lb.)
60
 M2-F3 Lifting Body

81. Three chase planes salute the M2-F3 wingless lifting body
following one of its rocket-powered flights. The blunt-nosed M2-F3
achieves its aerodynamic lift from the shape of its body.

This wingless craft is called a lifting body, because it derives its lift
from the fuselage rather than from wings. Removing the wings
reduces the weight of the craft, but adds significant control problems.
The lifting body concept was developed early in the last decade to
explore the problems of aerodynamic heating and vehicle control
during reentry from earth orbit. These are the problems that will be
especially critical in the space shuttle of the 1980s.

The M2-F3 tested flight behavior of wingless craft over a wide range
of speeds.

The M2-F3’s forerunner, the M2-F2, made 16 flights—all unpowered—

between July 1966 and May 1967. On May 10, it crashed on landing,
partly due to control instability. The craft was rebuilt, and the center
fin was added. This modification effectively solved the control
problem, and the new craft, designated M2-F3, logged 27 more
flights by December 1972. Some of the M2-F3’s flights were powered
by a 3630-kilogram (8000-pound) thrust rocket which boosted the
craft to a higher altitude.

The M2-F3 was launched from a B-52 bomber at a height of about

13,300 meters (45,000 feet) and a usual speed of 730 kilometers
(450 miles) per hour. The maximum altitude achieved was 21,800
meters (71,500 feet). The M2-F3’s record speed was 1718 kilometers
(1066 miles) per hour. The M2-F3 was built by Northrop.

The craft on exhibit is from the National Aeronautics and Space

Administration.

Length 6.8 m. (22 ft., 2 in.)

Span 2.9 m. (9 ft., 7 in.)
Height 2.5 m. (8 ft., 10 in.)
Weight 2720 kg. (6000 lb.) empty; 4540 kg. (10,000 lb.)
fueled
Speed 1718 km. per hr. (1066 m. per hr.) max. achieved
Altitude 21,800 m. (71,500 ft.) max. achieved
Mach 1.5 max. achieved
number
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookball.com