Experiment No.

Aim : Introduction to J2EE

Theory : J2EE is platform independent, java centric environment for developing enterprise
applications.
The J2EE is mostly used to develop web based applications, but also can be used
to develop non web based applications.
The J2EE Platform consists of set of services Application Programming Interface
(API) and protocol that provides functionality for development multithreading web based
applications.
Need :
 J2EE simplifies application development and decreases the need for programming.
 It decreases the need for programmer training by creating standardized reusable
modular components and by enabling the tier to handle many aspects of programming
automatically.
 J2EE used mostly for developing enterprise application because writing distributed
business application is not easy and they need high productivity solution that allows
them to flow only on writing their business logic and having full range of enterprise
class services to replay on like transactional distributed objects.

Components and parts of J2EE :

There are a number of different components that make up the J2EE suite
applications and creating enterprise solutions. Here are some of the most popular
technologies used to build J2EE.
JSP or Servelets:
J2ee technology uses JSP or Servelets to create applications either directly or
indirectly. Servelets are being used for a longer period of time and JSP was launched to
counter its competitor ASP from Microsoft.
EJB also known as Enterprise Java Beans is one of the popular and extensively
used J2EE technology. It offers all the solutions required for Enterprise applications.

Resource Adapter Module:

It contains ALL JAVA INTERFACES, CLASSES NATIVE LIBRARIES,
OTHER DOCUMENTS, A RESOURCE ADAPTER DEPLOYMENT
DESCRIPTOR.
Enterprise Java Beans Module:
It contains: JAVA CLASS FILES FOR ENTERPRISE BEANS, AN EJB DEPLOYMENT
DESCRIPTOR.
EJB modules are packed as jar files with jar extension.
Advantages:
 It is well documented and understood
 It has standardized and reliable s/w architecture. These can further decrease the cost
of the application.
 J2EE gives more flexibility . It can deploy applications with any server with small
changes.
 API’s used in J2EE are well documented and well commented.
  Low level services are already implemented.

Conclusion:
Thus we have studied J2EE

Experiment No.2

Aim :Explain Web-app folder structure in TOMCAT.

Theory:
A web application is defined as a hierarchy of directories and files in a standard layout. Such
a hierarchy can be accessed in its "unpacked" form, where each directory and file exists in the
filesystem separately, or in a "packed" form known as a Web Archive, or WAR file. The
former format is more useful during development, while the latter is used when you distribute
your application to be installed.
The top-level directory of your web application hierarchy is also the document root of your
application. Here, you will place the HTML files and JSP pages that comprise your
application's user interface. When the system administrator deploys your application into a
particular server, he or she assigns a context path to your application. Thus, if the system
administrator assigns your application to the context path/catalog, then a request URI referring
to /catalog/index.html will retrieve the index.html file from your document root.
The following item can exist in a web application:
 Servlets
 Java Server Pages
 Utility Classes
 Static document including XHTML ,images
 Client side Classes
 META information

Standard Directory Layout

To facilitate creation of a Web Application Archive file in the required format, it is
convenient to arrange the "executable" files of your web application (that is, the files that
Tomcat actually uses when executing your app) in the same organization as required by the
WAR format itself. To do this, you will end up with the following contents in your
application's "document root" directory:
 *.html, *.jsp, etc. - The HTML and JSP pages, along with other files that must be
visible to the client browser (such as JavaScript, stylesheet files, and images) for your
application. In larger applications you may choose to divide these files into a
subdirectory hierarchy, but for smaller apps, it is generally much simpler to maintain
only a single directory for these files.
 /WEB-INF/web.xml - The Web Application Deployment Descriptor for your
application. This is an XML file describing the servlets and other components that
make up your application, along with any initialization parameters and container-
managed security constraints that you want the server to enforce for you. This file is
discussed in more detail in the following subsection.
 /WEB-INF/classes/ - This directory contains any Java class files (and associated
resources) required for your application, including both servlet and non-servlet
classes, that are not combined into JAR files. If your classes are organized into Java
packages, you must reflect this in the directory hierarchy under /WEB-
INF/classes/. For example, a Java class named
com.mycompany.mypackage.MyServlet would need to be stored in a file
named /WEB-
INF/classes/com/mycompany/mypackage/MyServlet.class.
 /WEB-INF/lib/ - This directory contains JAR files that contain Java class files (and
associated resources) required for your application, such as third party class libraries
or JDBC drivers.
When you install an
application
into Tomcat (or
any other 2.2/2.3-
compatible
server), the classes
in the WEB-

INF/classes/ directory, as well as all classes in JAR files found in the WEB-INF/lib/
directory, are made visible to other classes within your particular web application. Thus,
if you include all of the required library classes in one of these places (be sure to check
licenses for redistribution rights for any third party libraries you utilize), you will simplify
the installation of your web application -- no adjustment to the system class path (or
installation of global library files in your server) will be necessary.
Deployment with Tomcat 4:
In order to be executed, a web application must be deployed on a servlet container. This is
true even during development. We will describe using Tomcat 4 to provide the execution
environment. A web application can be deployed in Tomcat by one of the following
approaches:
 Copy unpacked directory hierarchy into a subdirectory in directory
$USER/webapps/. Tomcat will assign a context path to your application based
on the subdirectory name you choose. We will use this technique in the
build.xml file that we construct, because it is the quickest and easiest
approach during development. Be sure to restart Tomcat after installing or
updating your application.
 Copy the web application archive file into directory $USER/webapps/. When
Tomcat is started, it will automatically expand the web application archive file
into its unpacked form, and execute the application that way. This approach
would typically be used to install an additional application, provided by a third
party vendor or by your internal development staff, into an existing Tomcat
installation. NOTE - If you use this approach, and wish to update your
application later, you must both replace the web application archive file AND
delete the expanded directory that Tomcat created, and then restart Tomcat, in
order to reflect your changes.
 Use the Tomcat 4 "Manager" web application to deploy and un-deploy web
applications. Tomcat 4 includes a web application, deployed by default on
 context path /manager, that allows you to deploy and un-deploy applications
on a running Tomcat server without restarting it. See the administrator
documentation for more information on using the Manager Web application.
 Add a <Context> entry in the $USER/conf/server.xml configuration
file. This approach is described briefly below, and allows you to position the
document root of your web application at some point other than the
$USER/webapps/ directory. You will need to restart Tomcat to have changes in
this configuration file take effect.

Conclusion:
Thus we have studied the web-app folder structure in TOMCAT server.