Download Amazon Cloud Computing Class Tomcat Servers

Amazon Cloud Computing Class Tomcat Servers
References:
Tomcat API documentation: Tomcat 6/7 JavaDocs
Tomcat 6 Developer’s Guide. ISBN 978-1-847197-28-3 Published 12/2009.
Disclaimer: this document is not meant to be a Tomcat reference, it is designed to
give the reader enough background to develop and debug Tomcat Servlets and to be
able to scale to more complicated examples using different frameworks. particularly
Spring, the Amazon J2EE SDK libraries, and the Amazon Travellog example.
The Tomcat server is the most common server used to implement web services
implemented in Java. Tomcat is called a “Servlet Container” which means it supports
the Java Servlet and Java Servlet Specifications. This is in contrast to Application
Servers sold under the name of BEA Weblogic, Sun Glassfish, Apache Geronimo and
IBM Websphere. The commercial Application servers sell to Enterprise J2EE
developers with the premise their solution is better and worth the extra money for
extra features like EJBs Most of the J2EE deployments rely on free open source
libraries and Tomcat and the Application servers add additional features which
make the development of J2EE specificatons easier with completed components.
The problem is these frameworks are more difficult to customize . Sometimes it is
easier to build small applications from scratch starting with a Tomcat server and
developing your own libraries. There are 2 separate specifications, a Servlet
Container http://www.jcp.org/en/jsr/detail?id=315 and a J2EE specification
http://download.oracle.com/javaee/.
One Tomcat key design goal was to make things as simple as possible for the
developer developing dynamic web content. Before the existence of Ruby on Rails,
Tomcat follows a definition of convention so everybody would standardize on folder
names, file placement for content such as HTML pages, standardization on open
source components for logging, security, etc.. Most of the default settings in Tomcat
do not have to be changed for the developer to be up and running with a web server.
As a result of this design, Tomcat was the first Servlet/Server environment which
was highly integrated with an IDE, where you didn’t have to edit code in a text
editor and compile/deploy using command scripts.
To standardize the development of web services across corporate infrastructure
Sun started the JSR
process(http://jcp.org/en/jsr/platform?listBy=3&listByType=platform ) so vendors
could promote and develop their own implementations and have them interoperate
across vendors. One part of the JSR process is the J2EE specification. We are
currently on the J2EE 6.0 (http://jcp.org/en/jsr/detail?id=316 ) specification.
J2EE is an additional specification added on top of the Servlet and JSP specification.
These additional components include things necessary needed for a small web
application as it scales to a larger one. The following components below are what we
will focus on developing examples for in the class. These are the most common
components used to develop scalable web applications in the cloud.
 Java Database Connectivity (JDBC) API: The JDBC API provides a database-independent mechanism to
access a relational database server. Note that even application client components may access a database
directly via the JDBC API. However, the preferred mechanism in Java EE 5 is to use the Java Persistence
API whenever possible.
 Java Naming and Directory Interface (JNDI): A naming service allows applications to bind an object to a
logical name and to use that logical name at a later time to retrieve that object. Examples of a naming
service include the file system, where a file name maps to a file object, or the Domain Naming Service,
where a URL is used to lookup an IP address.
A Java EE container implements a naming service. A component within that container can access this
naming service to look up various system- or user-defined objects, such as a DataSource, an environment
variable, or an Enterprise JavaBean.
A directory service lets you manage a hierarchical tree of objects and their attributes. Examples of directory
services include Lightweight Directory Access Protocol (LDAP) directories that can be used to store user
information such as user names, passwords, and contact details.
 Java EE Connector Architecture (JCA): This API lets you access data that is contained in existing
corporate assets such as non-relational databases and mainframe applications, from within the Java EE
platform.
 Java API for XML Processing (JAXP): JAXP allows a Java EE application to process XML documents,
using DOM, SAX, or StAX APIs that are independent of the underlying XML processor implementation.
 Java Message Service (JMS) API: A messaging service allows distributed applications to communicate
using messages. This communication is usually asynchronous. The JMS API provides a generic API that
can be used to access enterprise messaging implementations from different vendors such as TIBCO or IBM
MQ Series.
 JavaMail API: This API provides an interface that an application can use to interact with different email
systems. It uses the JavaBeans Activation Framework (JAF) API to handle MIME data that are included in
email messages.
 Java Transaction (JTA) API: This is a generic API for transaction management that even supports the
complexity of transactions involving distributed databases. The Java Transaction Service (JTS) provides an
implementation of this API.
 Remote Method Invocation (RMI) over Internet Inter-ORB protocol (RMI/IIOP): This API allows
distributed EJB components to communicate with each other and with distributed CORBA services.
 Java Persistence API (JPA): This API provides an object/relational mapping facility for developers.
Applications should use this technology in preference to either CMP entity beans or JDBC access.
 Web Service APIs: The Java API for XML Web Services (JAX-WS) and Java API for XML-based RPC
(JAX-RPC) support the invocation of web services using the SOAP/HTTP protocol. The Java Architecture
for XML Binding (JAXB) defines the mapping between Java classes and XML. In addition, the Java API
for XML Registries (JAXR) provides client access to XML registry servers.
 Java IDL: It allows Java EE application components to invoke external CORBA objects.
 JavaServer Faces (JSF): This API provides a standard way to build component-oriented web applications
that run within a web container.
 JavaServer Pages Standard Tag Library (JSTL): This library defines tags that provide core functionality
required by web applications.
 Streaming API for XML (StAX): The StAX API provides for a simple pull parsing programming model
for XML. Rather than waiting for program callback, as with the push-parsing that is used by the Simple
API for XML (SAX) parser model, StAX lets the programmer retain control of the parsing operation.
 Java Management Extensions (JMX): This API supports the web-based management and monitoring of
applications and services.
The primary focus of the J2EE specification is to allow the layering of higher level
services which should abstract out the implementation details and also allow the
user to chose a particular open source components for many of the standard
services. For example persistence services or database services can be implemented
with many different types of database drivers from different vendors. One big
change with the introduction of the J2EE specification was the use of Transaction
services. J2EE allows the use of transactions to implement OO modeling vs.
relational models. Transactions require implementing 2 phase commit which is built
into the J2EE jars. We will cover the most common J2EE interfaces/implementations
along with Spring in building web services Some things are obsolete, for example
using CORBA to stub out web services have been replaced by SOAP or REST
services.
We are going to start writing Tomcat servlets. A lot of simple ones which do things
like process data, servlets which delegate to other servlets to do tasks, servlets
which monitor heartbeats of servlets, servlets which access datastores including
databases, file systems, no sql datbases and even servlets which display user
presentation UIs, although we should really delegate this to user side JS. To be able
to debug this mass of servlets we will have to develop how server containers work.
Concept of a Server Contaimer
The concept of a servlet container relies on the separation of the generation of a response
to a web request into 2 parts, a static part and a dynamic part. For example if we designed
a server which returned a hello world string for every time we went to the server url, then
this server is completely static. If we modified the server to output a string which was
generated at runtime, say it summed all the digits in the time of day the request came in
then the result of the sum is dynamic. This dynamic part of the webserver resides in the
server container and is implemented in a Java Class or Java Bean. A Java Bean is a Java
class without a main() method which distinguishes the ability to run this as a Java
Console application. The goal of the server container is to maintain when the new() and
delete() are called on the class to manage memory for the server runtime. The server
container defines an object lifecycle which is the equivalent of defining when the object
is created and when it is destroyed or garbage collected. The runtime methods in the
Servlet used to tell the container how to control the objects are init(), service() and
destroy().
Tomcat Runtime File Organization
Web Applications are compressed into a single file with a .war extension. This war
file is placed into the /webapps directory of a running Tomcat server. It magically
uncompresses to the same folder structure you developed in under Eclipse and the
url to access this project is defined as
http://localhost:8080/projectfolderhame/index.html . The name of the war file will
be the eclipse project name you choose when creating the Dynamic Web Project.
The war file is added into the Tomcat /webapps directory either by Eclipse copying
it over for you using the Export As.. Menu option or you having to manually doing
this by storing the war file to your desktop folder then the user can move the war to
the /webapps directory on the Amazon Instance. The servlet container will
decompress the file into a directory structure which you see in Eclipse.
1) All wars belong under the /webapps directory
2) The wars are unarchived. A minimum directory structure is a WEB-INF and
META-INF directory. All of our files which we work on will be placed under
WEB-INF. META-INF holds the Manifest file which is used to load shared
libraries which we will get to later.
3) WEB-INF structure. Web.xml under /WEB-INF is the deployment descriptor.
Every application needs one. This file tells the servlet container what the
names of your servlets are, where they are located on the URL after
http://localhost:8080 and what class to create to represent the servlets you
name in the web.xml file.
4) WEB-INF/classes is where the source code for your servlets and compiled
classes reside. You don’t have to do anything, Eclipse will handle this for you.
/WEB-INF/lib is where the jar files you need to satisfy your import
statements in the servlets you write should be placed. Eclipse will not do this
automatically for you. You have to make sure you select
Project>>Properties>>Deployment Assembly and you import the jars you are
using in the build path into the WEB-INF/lib. This is a very common
configuration error.
5) Realms; we will cover memory realms, JDBC realms and JNDI realms.
Tomcat Deployment Descriptors
This is the most basic web.xml which we need to deploy a servlet.
<servlet>
<servlet-name></servlet-name>
<servlet-class></servlet-class>
</servlet>
<servlet-mapping>
<servlet-class></servlet-class>
<url-pattern></url-pattern>
</servlet-mapping>
Other tags we will need later:
<filter></filter>
<context-param></context-param>
<listener></listener>
<session-config></session-config>