Seminar Report on

J2EE

ATNaresh i Technologies

Hyderabad

Under the guidance ofMr. L. N. Rao

CO-ORDINATOR

SUBMITTED BY

MANJIT SAHU Roll # 200710224

OF THE DEPARTMENT OFINFORMATION TECHNOLOGY

For the partial fulfillment ofBACHELOR OF TECHNOLOGY

NATIONAL INSTITUTE OF SCIENCE & TECHNOLOGYPALUR HILLS, BERHAMPUR, ORISSA – 761008

ACKNOWLEDGEMENT

I express my deep sense of gratitude to, Mr. L. N. Rao Advisor for his valuable

guidance and constant unfailing encouragement for completing the summer course.

I would like to thank Dr.Sudhir Panigrahy for their help and support for doing my summer training at Naresh i Technology, Hyderabad.

Finally, I would like to thank the Mr. Sangram Mudali for providing us proper environment or the completion of the report.

MANJIT SAHU

i

ABSTRACT

The Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing

multitier enterprise applications. The J2EE platform simplifies enterprise applications

by basing them on standardized, modular components, by providing a complete set of

services to those components, and by handling many details of application behavior

automatically, without complex programming. The J2EE platform takes advantage of

many features of the Java 2 Platform, Standard Edition (J2SE), such as "Write Once,

Run Anywhere" portability, JDBC API for database access, CORBA technology for

interaction with existing enterprise resources, and a security model that protects data

even in internet applications. Building on this base, the Java 2 Platform, Enterprise

Edition adds full support for Enterprise JavaBeans components, Java Servlets API,

Java Server Pages and XML technology. The J2EE standard includes complete

specifications and compliance tests to ensure portability of applications across the

wide range of existing enterprise systems capable of supporting the J2EE platform. In

addition, the J2EE specification now ensures Web services interoperability through

support for the WS-I Basic Profile.

ii

TABLE OF CONTENTS

ACKNOWLEDGEMENT..............................................................................................iAbstract..........................................................................................................................iiTable of contents...........................................................................................................iii1. Introduction................................................................................................................12. SALIENT features.....................................................................................................2

Figure 2.1 Enterprise Application Model..........................................................................33. NOMENCLATURE STANDARDS & SPECIFICATIONS.....................................64. INTRODUCTION TO JDBC....................................................................................7

4.1 JDBC API Overview............................................................................................74.2 Advantages of JDBC Technology........................................................................74.3 KEY FEATURES................................................................................................84.4. JDBC ARCHITECTURE....................................................................................8

Figure 4.1 JDBC Architecture1.........................................................................................8Figure 4.2 JDBC Architecture 2........................................................................................9

4.5 Two-tier and Three-tier Models.........................................................................104.6 JDBC Driver Type.............................................................................................11

5. JAVA SERVLET TECHNOLOGY.........................................................................13Figure 5.1 Client – servlet interaction..............................................................................14

5.1 The Benefits of Servlets.....................................................................................145.2 Servlet Application Architecture........................................................................16

Figure 5.2 the Servlet Application Architecture..............................................................165.3 Lifecycle of a servlet..........................................................................................17

Figure 5.3 Servlet Lifecycle............................................................................................175.4 Servlet sample code............................................................................................18

6. JAVA SERVER PAGES..........................................................................................196.1 About jsp............................................................................................................20

Figure 6.1 Generating Dynamic Content with JSP..........................................................216.2 The Problem with Servlets.................................................................................216.3 Advantages Of JSP.............................................................................................216.4 The Anatomy of a JSP Page...............................................................................22

7. ENTERPRISE JAVA BEAN...................................................................................237.1Benefits of Enterprise Beans...............................................................................237.2 Use of Enterprise Beans.....................................................................................23

8. AJAX........................................................................................................................248.1 INTRODUCTION..............................................................................................248.2 Traditional vs Ajax technology..........................................................................24

Figure 8.1 Traditional Web application communication flow.........................................24Figure 8.2 Ajax-style communication flow.....................................................................25

8.3 Overview of XHRs.............................................................................................259. XML.........................................................................................................................27

9.1 Introduction........................................................................................................2710. Struts......................................................................................................................28

10.1 Design goals and overview..............................................................................2811. CONCLUSION......................................................................................................30REFERENCES.............................................................................................................31

iii

iv

J2EE

1. INTRODUCTION

Today's enterprises gain competitive advantage by quickly developing and deploying

custom applications that provide unique business services. Whether they're internal

applications for employee productivity, or Internet applications for specialized

customer or vendor services, quick development and deployment are key to success.

Portability and scalability are also important for long term viability. Enterprise

applications must scale from small working prototypes and test cases to complete 24x

7, enterprise-wide services, accessible by tens, hundreds, or even thousands of clients

simultaneously.

However, multitier applications are hard to architect. They require bringing together a

variety of skill sets and resources, legacy data and legacy code. In today's

heterogeneous environment, enterprise applications have to integrate services from a

variety of vendors with a diverse set of application models and other standards.

Industry experience shows that integrating these resources can take up to 50% of

application development time.

As a single standard that can sit on top of a wide range of existing enterprise systems

-- database management systems, transaction monitors, naming and directory services,

and more -- the J2EE platform breaks the barriers inherent between current enterprise

systems. The unified J2EE standard wraps and embraces existing resources required

by multitier applications with a unified, component-based application model. This

enables the next generation of components, tools, systems, and applications for

solving the strategic requirements of the enterprise.

The J2EE specification also supports emerging Web Services technologies through

inclusion of the WS-I Basic Profile. WS-I Basic Profile compliance means that the

developers can build applications on the J2EE platform as Web services that

interoperate with Web services from non-J2EE compliant environments.

With simplicity, portability, scalability, and legacy integration, the J2EE platform is

the platform for enterprise solutions. 

0

J2EE

2. SALIENT FEATURES

2.1 Enterprise Application Model

The Enterprise Java BluePrints for the J2EE platform describe the J2EE application

model and best practices for using the J2EE platform. Building on the J2SE platform,

the J2EE application model provides a simplified approach to developing highly

scalable and highly available internet or intranet based applications. Thanks to the

J2EE application model, maybe the most interesting thing about J2EE applications is

what they don't do. That is, various complexities inherent in enterprise applications --

transaction management, life-cycle management, resource pooling -- are built into the

platform and provided automatically to the components it supports. Component and

application developers are free to focus on specifics such as business logic and user

interfaces.

Another advantage of the J2EE platform is that the application model encapsulates the

layers of functionality in specific types of components. Business logic is encapsulated

in Enterprise JavaBeans (EJB) components. Client interaction can be presented

through plain HTML web pages, through web pages powered by applets, Java

Servlets, or Java Server Pages technology, or through stand-alone Java applications.

Components communicate transparently using various standards: HTML, XML,

HTTP, SSL, RMI, IIOP, and others. Reusable J2EE components mean competitive

choices for enterprise developers and IT organizations. The J2EE platform enables

them to assemble applications from a combination of standard, commercially

available components and their own custom components. From general business

application components to vertical market solutions, a range of standardized J2EE

functionality is available off the shelf.

This means that an e-commerce site could be built using a combination of off-the-

shelf EJB components for shopping cart behaviors, modified EJB components for

specialized customer services, and completely customized layouts using Java Server

Pages technology that bring a unique look and feel to the site. This approach means

faster development time, better quality, maintainability and portability, and Web

1

J2EE

services interoperability across a range of enterprise platforms. The bottom line

benefits are increased programmer productivity, better strategic use of computing

resources, and greater return on an organization's technology investments.

Figure 2.1 Enterprise Application Model

2.2 Containers and Connectors: Hiding Complexity, Enhancing

Portability

The J2EE application model divides enterprise applications into three fundamental

parts: components, containers, and connectors. Components are the key focus of

application developers, while system vendors implement containers and connectors to

conceal complexity and promote portability. Containers intercede between clients and

components, providing services transparently to both, including transaction support

and resource pooling. Container mediation allows many component behaviors to be

specified at deployment time, rather than in program code.

Connectors sit beneath the J2EE platform, defining a portable service API that

communicates with existing enterprise vendor offerings. Connectors promote

flexibility by enabling a variety of implementations of specific services. In particular,

connectors implementing pluggable messaging contracts enable bidirectional

communication between J2EE components and enterprise systems.

2

J2EE

 

2.3 Flexible User Interaction

The J2EE platform provides choices for graphical user interfaces across a company's

intranet or on the World Wide Web. Clients can run on desktops, laptops, PDAs, cell

phones, and other devices. Pure client-side user interfaces can use standard HTML

and Java applets. Support for simple HTML means quicker prototypes, and support

for a broader range of clients. Additionally, the J2EE platform supports automatic

download of the Java Plug-in to add applet support where it's lacking. The J2EE

platform also supports stand-alone Java application clients.

For server-side generation of dynamic content, the J2EE platform supports two types

of web component technologies: Java Servlets and JavaServer Pages (JSP). Java

Servlets enable developers to easily implement server-side behaviors that take full

advantage of the power of the rich Java API. JavaServer Pages technology combines

the ubiquity of HTML with the power of server-side dynamic content generation. The

JSP 2.0 specification supports static templates, simplified access to Java objects, and

easy extensibility.

 

2.4 Enterprise JavaBeans Component Model

Enterprise JavaBeans (EJB) technology enables a simplified approach to multitier

application development, concealing application complexity and enabling the

component developer to focus on business logic.

EJB technology gives developers the ability to model the full range of objects useful

in the enterprise by defining several types of EJB components: session beans, entity

beans, message-driven beans. Session beans represent behaviors associated with client

sessions -- for example, a user purchase transaction on an e-commerce site. Session

beans can serve as Web service endpoints. Entity beans represent collections of data --

such as rows in a relational database -- and encapsulate operations on the data they

represent. Entity beans are intended to be persistent, surviving as long as the data

they're associated with remains viable. Message-driven beans allow J2EE applications

to process messages asynchronously. A message-driven bean normally acts as a JMS 3

J2EE

message listener, which is similar to an event listener except that it receives JMS

messages instead of events. The messages may be sent by any J2EE component--an

application client, another enterprise bean, or a Web component--or by a JMS

application or system that does not use J2EE technology.

 

2.5 Web Services Interoperability

The Java 2 Platform, Enterprise Edition version 1.4 is the most complete Web

services platform ever. The platform features Web services support through the new

JAX-RPC 1.1 API, which provides service endpoints based on servlets and enterprise

beans. JAX-RPC 1.1 provides interoperability with Web services based on the WSDL

and SOAP protocols. The J2EE 1.4 platform also supports the Web Services for J2EE

specification, which defines deployment requirements for Web services and utilizes

the JAX-RPC programming model. In addition to numerous Web services APIs, the

J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. This means

that in addition to platform independence and complete Web services support, the

J2EE 1.4 platform offers platform Web services interoperability.

 

2.6 Expediting Development and Deployment

Based on these flexible component configurations, the J2EE application model means

quicker development, easier customization and greater ability to deploy powerful

enterprise applications. And, because it's based on the Java programming language,

this model enables all J2EE applications to achieve all the benefits of Java

technology: scalability, portability, and programming ease.

4

J2EE

3. NOMENCLATURE STANDARDS &

SPECIFICATIONS

The platform was known as Java 2 Platform, Enterprise Edition or J2EE until the

name was changed to Java EE in version 5. The current version is called Java EE 6.

Java EE is defined by its specification. As with other Java Community process

specifications, providers must meet certain conformance requirements in order to

declare their products as Java EE compliant.

Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web

services, XML, etc., and defines how to coordinate them. Java EE also features some

specifications unique to Java EE for components. These include Enterprise

JavaBeans, Connectors, servlets, portlets (following the Java Portlet specification),

JavaServer Pages and several web service technologies. This allows developers to

create enterprise applications that are portable and scalable, and that integrate with

legacy technologies. A Java EE application server can handle transactions, security,

scalability, concurrency and management of the components that are deployed to it, in

order to enable developers to concentrate more on the business logic of the

components rather than on infrastructure and integration tasks.

5

J2EE

4. INTRODUCTION TO JDBC

The Java Database Connectivity (JDBC) API is the industry standard for database-

independent connectivity between the Java programming language and a wide range

of databases. SQL databases and other tabular data sources, such as spreadsheets or

flat files. The JDBC API provides a call-level API for SQL-based database access.

JDBC technology allows you to use the Java programming language to exploit "Write

Once, Run Anywhere" capabilities for applications that require access to enterprise

data. With a JDBC technology-enabled driver, you can connect all corporate data

even in a heterogeneous environment.

4.1 JDBC API Overview

The JDBC API makes it possible to do three things:

Establish a connection with a database or access any tabular data source

Send SQL statements

Process the results

4.2 Advantages of JDBC Technology

4.2.1 Leverage Existing Enterprise Data

With JDBC technology, businesses are not locked in any proprietary

architecture, and can continue to use their installed databases and access

information easily -- even if it is stored on different database management

systems.

4.2.2 Simplified Enterprise Development

The combination of the Java API and the JDBC API makes application

development easy and economical. JDBC hides the complexity of many data

access tasks, doing most of the "heavy lifting"for the programmer behind the

scenes. The JDBC API is simple to learn, easy to deploy, and inexpensive to

maintain.

6

J2EE

4.3 KEY FEATURES

Full Access to Metadata

The JDBC API provides metadata access that enables the development of

sophisticated applications that need to understand the underlying facilities and

capabilities of a specific database connection.

No Installation

A pure JDBC technology-based driver does not require special installation; it is

automatically downloaded as part of the applet that makes the JDBC calls.

Database Connection Identified by URL

JDBC technology exploits the advantages of Internet-standard URLs to identify

database connections. The JDBC API includes an even better way to identify and

connect to a data source, using a DataSource object, that makes code even more

portable and easier to maintain.

4.4. JDBC ARCHITECTURE

The JDBC API contains two major sets of interfaces: the first is the JDBC API for

application writers, and the second is the lower-level JDBC driver API for driver

writers. JDBC technology drivers fit into one of four categories. Applications and

applets can access databases via the JDBC API using pure Java JDBC technology-

based drivers, as shown in this figure:

Figure 4.1 JDBC Architecture1

7

J2EE

Left side, Type 4: Direct-to-Database Pure Java Driver This style of driver converts JDBC calls into the network protocol used directly by DBMSs, allowing a direct call from the client machine to the DBMS server and providing a practical solution for intranet access.

Right side, Type 3: Pure Java Driver for Database Middleware This style of driver translates JDBC calls into the middleware vendor's protocol, which is then translated to a DBMS protocol by a middleware server. The middleware provides connectivity to many different databases.

The graphic below illustrates JDBC connectivity using ODBC drivers and existing database client libraries.

Figure 4.2 JDBC Architecture 2

Left side, Type 1: JDBC-ODBC Bridge plus ODBC Driver This combination provides JDBC access via ODBC drivers. ODBC binary code -- and in many cases, database client code -- must be loaded on each client machine that uses a JDBC-ODBC Bridge. Sun provides a JDBC-ODBC Bridge driver, which is appropriate for experimental use and for situations in which no other driver is available.

Right side, Type 2: A native API partly Java technology-enabled driver This type of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.

8

J2EE

4.5 Two-tier and Three-tier Models

The JDBC API supports both two-tier and three-tier models for database access.

In the two-tier model, a Java applet or application talks directly to the database. This

requires a JDBC driver that can communicate with the particular database

management system being accessed. A user's SQL statements are delivered to the

database, and the results of those statements are sent back to the user. The database

may be located on another machine to which the user is connected via a network. This

is referred to as a client/server configuration, with the user's machine as the client,

and the machine housing the database as the server. The network can be an intranet,

which, for example, connects employees within a corporation, or it can be the

Internet.

In the three-tier model, commands are sent to a "middle tier" of services, which then

send SQL statements to the database. The database processes the SQL statements and

sends the results back to the middle tier, which then sends them to the user. MIS

directors find the three-tier model very attractive because the middle tier makes it

possible to maintain control over access and the kinds of updates that can be made to

corporate data. Another advantage is that when there is a middle tier, the user can

employ an easy-to-use higher-level API which is translated by the middle tier into the

appropriate low-level calls. Finally, in many cases the three-tier architecture can

provide performance advantages.

9

J2EE

Until now the middle tier has typically been written in languages such as C or C++,

which offer fast performance. However, with the introduction of optimizing compilers

that translate Java bytecode into efficient machine-specific code, it is becoming

practical to implement the middle tier in Java. This is a big plus, making it possible to

take advantage of Java's robustness, multithreading, and security features. JDBC is

important to allow database access from a Java middle tier.

4.6 JDBC Driver Type

The JDBC drivers that we are aware of at this time fit into one of four categories:

1. JDBC-ODBC bridge plus ODBC driver: The JavaSoft bridge product provides

JDBC access via ODBC drivers. Note that ODBC binary code, and in many

cases database client code, must be loaded on each client machine that uses

this driver. As a result, this kind of driver is most appropriate on a corporate

network where client installations are not a major problem, or for application

server code written in Java in a three-tier architecture.

2. Native-API partly-Java driver: This kind of driver converts JDBC calls into

calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS.

Note that, like the bridge driver, this style of driver requires that some binary

code be loaded on each client machine.

3. JDBC-Net pure Java driver: This driver translates JDBC calls into a DBMS-

independent net protocol which is then translated to a DBMS protocol by a

server. This net server middleware is able to connect its pure Java clients to

10

J2EE

many different databases. The specific protocol used depends on the vendor.

In general, this is the most flexible JDBC alternative. It is likely that all

vendors of this solution will provide products suitable for Intranet use. In

order for these products to also support Internet access, they must handle the

additional requirements for security, access through firewalls, and so on, that

the Web imposes. Several vendors are adding JDBC drivers to their existing

database middleware products.

4. Native-protocol pure Java driver: This kind of driver converts JDBC calls into

the network protocol used by DBMSs directly. This allows a direct call from

the client machine to the DBMS server and is a practical solution for Intranet

access. Since many of these protocols are proprietary, the database vendors

themselves will be the primary source, and several database vendors have

these in progress. Eventually, we expect that driver categories 3 and 4 will be

the preferred way to access databases from JDBC. Driver categories 1 and 2

are interim solutions where direct pure Java drivers are not yet available.

The following chart shows the four categories and their properties:

DRIVER CATEGORY ALL JAVA? NET PROTOCOL

1 - JDBC-OCBC Bridge No Direct

2 - Native API as basis No Direct

3 - JDBC-Net Yes Requires Connector

4 - Native protocol as basis Yes Direct

11

J2EE

5. JAVA SERVLET TECHNOLOGYJAVA SERVLET TECHNOLOGY PROVIDES A BASIC MECHANISM FOR GENERATING DYNAMIC WEB CONTENT. THINK OF THEM AS JAVA APPLETS FOR SERVERS. SERVLETS WERE DEVELOPED AS AN IMPROVEMENT OVER CGI SCRIPTS, WHICH ARE GENERALLY PLATFORM−SPECIFIC, AND ARE LIMITED IN THEIR ABILITY TO SUPPORT RICH INTERACTION. BECAUSE SERVLETS ARE BASED ON THE JAVA PROGRAMMING LANGUAGE, THEY OFFER SEVERAL BENEFITS OVER CGI, INCLUDING PORTABILITY, FLEXIBILITY, AND PROGRAMMING EASE. IN ADDITION, THEY PROVIDE BETTER PERFORMANCE BECAUSE THEY ARE PERSISTENT A SERVLET NEEDS TO BE LOADED INTO MEMORY AND INITIALIZED JUST ONCE. IT'S THEN AVAILABLE TO SERVE ANY USER REQUEST. LIKE ALL J2EE COMPONENTS, SERVLETS RUN IN A CONTAINER IMPLEMENTED BY THE J2EE PLATFORM PROVIDER. THE CONTAINER MANAGES A SERVLET'S INTERACTION WITH ITS CLIENT AND PROVIDES A RICH ENVIRONMENT FOR THE SERVLET TO USE TO ACCESS VARIOUS SERVICES BASED ON JAVA TECHNOLOGY. A SERVLET CONTAINER IMPLEMENTS ALL OF THE JAVA 2 PLATFORM, STANDARD EDITION APIS. THIS MAKES A VARIETY OF TECHNOLOGIES BASED ON THE JAVA PROGRAMMING LANGUAGE AVAILABLE TO SERVLETS, INCLUDING JDBC, JAVA NAMING AND DIRECTORY INTERFACE, RMI,

12

J2EE

JAVABEANS, AND OTHERS. THE CONTAINER CAN ALSO IMPLEMENT FEATURES THAT ALLOW SERVLETS TO SHARE INFORMATION ABOUT A PARTICULAR CLIENT AND SESSION, OVERCOMING THE OBSTACLES GENERALLY PRESENTED BY THE STATELESS HTTP PROTOCOL. THE FLEXIBILITY OF SERVLETS IS ENABLED THROUGH THE SERVLET API, WHICH IMPLEMENTS A MECHANISM FOR MORE COMPLEX INTERACTION WITH THE REQUESTING CLIENT THAN CAN CGI. VARIOUS SERVLET METHODS PROVIDE INFORMATION TO THE SERVLET AND ALLOW IT TO RESPOND. BECAUSE OF THE OBJECT−ORIENTED PROGRAMMING MODEL, ITEMS KEY TO SERVLET BEHAVIORS ARE PROVIDED AS OBJECTS WITH A WELL−DEFINED API.

FIGURE 5.1 CLIENT – SERVLET INTERACTION5.1 THE BENEFITS OF SERVLETSWHEN IT FIRST EMERGED, THIS GREAT THING WE CALL THE INTERNET CONSISTED OF ONLY STATIC CONTENTS WRITTEN USING HYPERTEXT MARKUP LANGUAGE (HTML). AT THAT TIME,

13

J2EE

ANYONE WHO COULD AUTHOR HTML PAGES WAS CONSIDERED AN INTERNET EXPERT. THIS DID NOT LAST LONG, HOWEVER. SOON DYNAMIC WEB CONTENTS WERE MADE POSSIBLE THROUGH THE COMMON GATEWAY INTERFACE (CGI) TECHNOLOGY. CGI ENABLES THE WEB SERVER TO CALL AN EXTERNAL PROGRAM AND PASS HTTP REQUEST INFORMATION TO THAT EXTERNAL PROGRAM TO PROCESS THE REQUEST. THE RESPONSE FROM THE EXTERNAL PROGRAM IS THEN PASSED BACK TO THE WEB SERVER, WHICH FORWARDS IT TO THE CLIENT BROWSER. CGI PROGRAMS CAN BE WRITTEN IN ANY LANGUAGE THAT CAN BE CALLED BY THE WEB SERVER. OVER THE COURSE OF TIME, PERL BECAME THE MOST POPULAR LANGUAGE TO WRITE CGI PROGRAMS.AS THE INTERNET BECAME MORE AND MORE POPULAR, HOWEVER, THE NUMBER OF USERS VISITING A POPULAR WEB SITE INCREASED EXPONENTIALLY, AND IT BECAME APPARENT THAT CGI HAD FAILED TO DELIVER SCALABLE INTERNET APPLICATIONS. THE FLAW IN CGI IS THAT EACH CLIENT REQUEST MAKES THE WEB SERVER SPAWN A NEW PROCESS OF THE REQUESTED CGI PROGRAM. AS WE ALL KNOW, PROCESS CREATION IS AN EXPENSIVE OPERATION THAT CONSUMES A LOT OF CPU CYCLES AND COMPUTER MEMORY. GRADUALLY, NEW AND BETTER TECHNOLOGIES WILL REPLACE CGI AS THE MAIN TECHNOLOGY FOR WEB APPLICATION DEVELOPMENT. THE WORLD

14

J2EE

HAS WITNESSED THE FOLLOWING TECHNOLOGIES TRYING TO DOMINATE WEB DEVELOPMENT:• COLDFUSION. ALLAIRE'S COLDFUSION PROVIDES HTML-LIKE CUSTOM TAGS THAT CAN BE USED TO PERFORM A NUMBER OF OPERATIONS, ESPECIALLY QUERYING A DATABASE. THIS TECHNOLOGY HAD ITS GLAMOROUS TIME IN THE HISTORY OF THE WORLD WIDE WEB AS THE MAIN TECHNOLOGY FOR WEB APPLICATION PROGRAMMING. ITS GLORIOUS TIME HAS SINCE GONE WITH THE INVENTION OF OTHER TECHNOLOGIES.• SERVER-SIDE JAVASCRIPT (SSJS). SSJS IS AN EXTENSION OF THE JAVASCRIPT LANGUAGE, THE SCRIPTING LANGUAGE THAT STILL RULES CLIENT-SIDE WEB PROGRAMMING. SSJS CAN ACCESS JAVA CLASSES DEPLOYED AT THE SERVER SIDE USING THE LIVEWIRE TECHNOLOGY FROM NETSCAPE.• PHP. PHP IS AN EXCITING OPEN-SOURCE TECHNOLOGY THAT HAS MATURED IN RECENT YEARS. THE TECHNOLOGY PROVIDES EASY WEB APPLICATION DEVELOPMENT WITH ITS SESSION MANAGEMENT AND INCLUDES SOME BUILT-IN FUNCTIONALITY, SUCH AS FILE UPLOAD. THE NUMBER OF PROGRAMMERS EMBRACING PHP AS THEIR TECHNOLOGY OF CHOICE HAS RISEN SHARPLY IN RECENT YEARS.• SERVLET. THE SERVLET TECHNOLOGY WAS INTRODUCED BY SUN MICROSYSTEMS IN 1996.• JAVA SERVER PAGES (JSP). JSP IS AN EXTENSION OF THE

15

J2EE

SERVLET TECHNOLOGY. THIS, TOO, IS THE CENTER OF ATTENTION IN THIS BOOK.IN THE PAST, ASP AND SERVLET/JSP HAVE BEEN THE MAIN TECHNOLOGIES USED IN WEB APPLICATION DEVELOPMENT. WITH THE RELEASE OF ASP.NET, IT IS NOT HARD TO PREDICT THAT THIS TECHNOLOGY WILL BECOME THE SERVLET/JSP'S MAIN COMPETITOR. ASP (AND ASP.NET) AND SERVLET/JSP EACH HAVE THEIR OWN FANS, AND IT IS NOT EASY TO PREDICT WHICH ONE WILL COME OUT THE WINNER. THE MOST LIKELY OUTCOME IS THAT NEITHER WILL BE AN ABSOLUTE WINNER THAT CORNERS THE MARKET; INSTEAD THE TECHNOLOGIES WILL PROBABLY RUN HEAD-TO-HEAD IN THE COMING YEARS. SERVLET (AND JSP) OFFERS THE FOLLOWING BENEFITS THAT ARE NOT NECESSARILY AVAILABLE IN OTHER TECHNOLOGIES:• PERFORMANCE. THE PERFORMANCE OF SERVLETS IS SUPERIOR TO CGI BECAUSE THERE IS NO PROCESS CREATION FOR EACH CLIENT REQUEST. INSTEAD, EACH REQUEST IS HANDLED BY THE SERVLET CONTAINER PROCESS. AFTER A SERVLET IS FINISHED PROCESSING A REQUEST, IT STAYS RESIDENT IN MEMORY, WAITING FOR ANOTHER REQUEST.• PORTABILITY. SIMILAR TO OTHER JAVA TECHNOLOGIES, SERVLET APPLICATIONS ARE PORTABLE. YOU CAN MOVE THEM TO OTHER OPERATING SYSTEMS WITHOUT SERIOUS HASSLES.• RAPID DEVELOPMENT

16

J2EE

CYCLE. AS A JAVA TECHNOLOGY, SERVLETS HAVE ACCESS TO THE RICH JAVA LIBRARY, WHICH HELPS SPEED UP THE DEVELOPMENT PROCESS.• ROBUSTNESS. SERVLETS ARE MANAGED BY THE JAVA VIRTUAL MACHINE. AS SUCH, YOU DON'T NEED TO WORRY ABOUT MEMORY LEAK OR GARBAGE COLLECTION, WHICH HELPS YOU WRITE ROBUST APPLICATIONS. • WIDESPREAD ACCEPTANCE. JAVA IS A WIDELY ACCEPTED TECHNOLOGY. THIS MEANS THAT NUMEROUS VENDORS WORK ON JAVA-BASED TECHNOLOGIES. ONE OF THE ADVANTAGES OF THIS WIDESPREAD ACCEPTANCE IS THAT YOU CAN EASILY FIND AND PURCHASE COMPONENTS THAT SUIT YOUR NEEDS, WHICH SAVES PRECIOUS DEVELOPMENT TIME.5.2 SERVLET APPLICATION ARCHITECTUREA SERVLET IS A JAVA CLASS THAT CAN BE LOADED DYNAMICALLY INTO AND RUN BY A SPECIAL WEB SERVER. THIS SERVLET-AWARE WEB SERVER IS CALLED A SERVLET CONTAINER, WHICH ALSO WAS CALLED A SERVLET ENGINE IN THE EARLY DAYS OF THE SERVLET TECHNOLOGY. SERVLETS INTERACT WITH CLIENTS VIA A REQUEST-RESPONSE MODEL BASED ON HTTP. BECAUSE SERVLET TECHNOLOGY WORKS ON TOP OF HTTP, A SERVLET CONTAINER MUST SUPPORT HTTP AS THE PROTOCOL FOR CLIENT REQUESTS AND SERVER RESPONSES. HOWEVER, A SERVLET CONTAINER ALSO CAN SUPPORT SIMILAR PROTOCOLS, SUCH AS HTTPS (HTTP OVER

17

J2EE

SSL) FOR SECURE TRANSACTIONS.

FIGURE 5.2 THE SERVLET APPLICATION ARCHITECTUREIN A JSP APPLICATION, THE SERVLET CONTAINER IS REPLACED BY A JSP CONTAINER. BOTH THE SERVLET CONTAINER AND THE JSP CONTAINER OFTEN ARE REFERRED TO AS THE WEB CONTAINER OR SERVLET/JSP CONTAINER, ESPECIALLY IF A WEB APPLICATION CONSISTS OF BOTH SERVLETS AND JSP PAGES.

18

J2EE

5.3 Lifecycle of a servletThe servlet lifecycle consists of the

following steps:The servlet class is loaded by the Web

container during start-up.

1. The Web container calls the init() method. This method initializes the servlet

and must be called before the servlet can service any requests. In the entire life

of a servlet, the init() method is called only once.

2. After initialization, the servlet can service client requests. Each request is

serviced in its own separate thread. The Web container calls the service()

method of the servlet for every request. The service() method determines the

kind of request being made and dispatches it to an appropriate method to

handle the request. The developer of the servlet must provide an

implementation for these methods. If a request for a method that is not

implemented by the servlet is made, the method of the parent class is called,

typically resulting in an error being returned to the requester. Finally, the Web

container calls the destroy() method that takes the servlet out of service. The

destroy() method, like init(), is called only once in the lifecycle of a servlet.

Figure 5.3 Servlet Lifecycle

19

J2EE

5.4 Servlet sample code

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.util.*;

public class TestingServlet extends HttpServlet {

public void doGet(HttpServletRequest request,HttpServletResponse response) throws

ServletException, IOException

{

PrintWriter out = response.getWriter();

out.println("<HTML>");

out.println("<HEAD>");

out.println("<TITLE>Servlet Testing</TITLE>");

out.println("</HEAD>");

out.println("<BODY>");

out.println("Welcome to the Servlet Testing Center");

out.println("</BODY>");

out.println("</HTML>");

}

The clientside browser will have the html page of code

<html>

<body bgcolor="white">

<h1>Good evening!</h1>

Welcome to our site, open 24 hours a day.

</body>

</html>

20

J2EE

6. JAVA SERVER PAGES

In late 1999, Sun Microsystems added a new element to the collection of Enterprise

Java tools: JavaServer Pages (JSP). JavaServer Pages are built on top of Java servlets

and are designed to increase the efficiency in which programmers, and even

nonprogrammers, can create web content. This book is primarily about JavaServer

Pages, covering the latest version of this technology, JSP 1.2, as well as the related

JSP Standard Tag Library (JSTL) Version 1.0. It also covers other J2EE technologies,

such as servlets and JDBC, with focus on how to combine them with JSP in the most

efficient way.

JavaServer Pages technology builds on Java Servlet technology to simplify the

development of dynamic Web content. JSP supports a page−based metaphor that

conveniently separates dynamic and static Web content; the JSP page defines a static

HTML template, with embedded calls to code written in the Java programming

language to fill in dynamic portions of the page. JSP pages contain four kinds of

elements, each with a specific role in the presentation of dynamic content. Text

elements are normally content formatted through standard HTML or XML. These

represent the static portion of the page.

1. Directives are instructions to the JSP processor. A JSP container processes

these directives when compiling the page into an efficient executable form.

2. Tags invoke JavaBeans to generate dynamic content or perform other

computations. Tag libraries are a powerful feature of JSPs used to encapsulate

specific functionality invoked via HTML tags. These allow the JSP

_language_ to be easily extended in a portable fashion. For example, tag

libraries can be implemented to support embedded database queries for an

application.

3. Scripting elements may be declarations, scriptlets, or expressions. Like tags,

scripting elements can be used to perform computations to generate dynamic

content. They are useful when standard tags are inappropriate or have not been

defined.

4. The combination of these four elements makes it easy to generate Web pages

for client browsers. Because JSP is based on servlets, users benefit from the

21

J2EE

application support and other features built into Web application containers.

These include portability, access to common services, the ability to maintain

state and client−access information via common APIs, and other servlet

benefits.

The advantage of the JSP model is that Web designers need not be familiar with the

Java programming language to create sophisticated JSP pages. JSP is designed to

enable Web authoring tools to automatically generate tags, scripting elements, and

other HTML, and to enable the incorporation of dynamic elements by means of

familiar drag−and−drop authoring techniques. Programmers can focus on providing

JavaBeans and custom tags for use by the Web designer; organizations can even

acquire custom behaviors from third−party developers. This supports one of the

higher goals of J2EE, separating the skill sets required to develop and assemble

complex applications into more logical roles. Using J2EE technology and tools,

Web−page designers and content providers can focus on presenting the best look and

feel possible, without programming, while application programmers can develop

complex behind−the−scenes behavior, without having to be user−interface experts.

6.1 About jsp

Dynamic content. Unlike a plain HTML page, which contains static content that

always remains the same, a JSP page can change its content based on any number of

variable items, including the identity of the user, the user's browser type, information

provided by the user, and selections made by the user. As you'll see later in the book,

this functionality is key to web applications such as online shopping and employee

directories, as well as for personalized and internationalized content. A JSP page

contains standard markup language elements, such as HTML tags, just like aregular

web page. However, a JSP page also contains special JSP elements that allow the

server to insert dynamic content in the page. JSP elements can be used for a variety of

purposes, such as retrieving information from a database or registering user

references. When a user asks for a JSP page, the server executes the JSP elements,

merges the results with the static parts of the page, and sends the dynamically

composed page back to the browser.

22

J2EE

Figure 6.1 Generating Dynamic Content with JSP

6.2 The Problem with Servlets

Thorough Java programming knowledge is needed to develop and maintain all

aspects of the application, since the processing code and the HTML elements

are lumped together.

Changing the look and feel of the application, or adding support for a new

type of client (such as a WML client), requires the servlet code to be updated

and recompiled.

It's hard to take advantage of web-page development tools when designing the

application interface. If such tools are used to develop the web page layout,

the generated HTML must then be manually embedded into the servlet code, a

process which is time consuming, error prone, and extremely boring.

6.3 Advantages Of JSP

1. The JSP technology is platform independent, in its dynamic web pages, its web

servers, and its underlying server components. That is, JSP pages perform perfectly

without any hassle on any platform, run on any web server, and web-enabled

application server. The JSP pages can be accessed from any web server.

2. The JSP technology emphasizes the use of reusable components. These

components can be combined or manipulated towards developing more purposeful

components and page design. This definitely reduces development time apart from the

At development time, JSPs are very different from Servlets, however, they are

precompiled into Servlets at run time and executed by a JSP engine which is installed

on a Web-enabled application server such as BEA WebLogic and IBM WebSphere.

6.4 The Anatomy of a JSP Page

A JSP page is simply a regular web page with JSP elements for generating the parts

that differ for each request

23

J2EE

Everything in the page that isn't a JSP element is called template text. Template text

can be any text: HTML, WML, XML, or even plain text. Since HTML is by far the

most common web-page language in use today, most of the descriptions and examples

in this book use HTML, but keep in mind that JSP has no dependency on HTML; it

can be used with any markup language. Template text is always passed straight

through to the browser.

When a JSP page request is processed, the template text and dynamic content

generated by the JSP elements are merged, and the result is sent as the response to the

browser

.

7. ENTERPRISE JAVA BEAN

Written in the Java™ programming language, an enterprise bean is a server-side

component that encapsulates the business logic of an application. The business logic

is the code that fulfills the purpose of the application. In an inventory control 24

J2EE

application, for example, the enterprise beans might implement the business logic in

methods called checkInventoryLevel and orderProduct. By invoking these methods,

remote clients can access the inventory services provided by the application.

7.1Benefits of Enterprise Beans

For several reasons, enterprise beans simplify the development of large, distributed

applications. First, because the EJB container provides system-level services to

enterprise beans, the bean developer can concentrate on solving business problems.

The EJB container not the bean developer is responsible for system-level services

such as transaction management and security authorization. Second, because the

beans and not the clients contain the application’s business logic, the client developer

can focus on the presentation of the client. The client developer does not have to code

the routines that implement business rules or access databases. As a result, the clients

are thinner, a benefit that is particularlyimportant for clients that run on small devices.

Third, because enterprise beans are portable components, the application assembler

can build new applications from existing beans. These applications can run on any

compliant J2EE server.

7.2 Use of Enterprise Beans

One should consider using enterprise beans if the application has any of these

requirements:

The application must be scalable. To accommodate a growing number of

users, you may need to distribute an application’s components across multiple

machines. Not only can the enterprise beans of an application run on different

machines, but their location will remain transparent to the clients.

Transactions are required to ensure data integrity. Enterprise beans support

transactions, the mechanisms that manage the concurrent access of shared

objects.

25

J2EE

8. AJAX

8.1 INTRODUCTION

Ajax (Asynchronous JavaScript and XML) encompasses much more than the

technologies that make up this catchy acronym. The general term Ajax describes the

usage of various Web technologies to transform the sluggish batch submission of

traditional Web applications into a highly responsive near desktop-software-like user

experience. However, such a dramatic improvement does come with the price of a

significant rise in programming complexity, increased network concerns, and new

user experience design challenges. For now, let’s avoid most of those details, as is

appropriate in an introduction, and begin with an overview of the concepts behind

Ajax illustrated by an example. Details of the example will then be presented hinting

at future complexity. The chapter then concludes with a brief discussion of the

historical rise and potential effects of Ajax upon Web development.

8.2 Traditional vs Ajax technology

Figure 8.1 Traditional Web application communication flow

26

J2EE

Figure 8.2 Ajax-style communication flow

8.3 Overview of XHRs

At the heart of Ajax is the XHR object. A bit misnamed, this object provides

generalized HTTP or HTTPS access for client-side scripting and is not limited to just

making requests or using XML, as its name would suggest. The facility was first

implemented in Internet Explorer 5 for Windows to support the development of

Microsoft Outlook Web Access for Exchange 2000, and this object has come to be

widely supported in all major desktop browsers. Native implementations can be found

in Safari 1.2+, Mozilla 1+, Netscape 7+, Opera 8+, and Internet Explorer 7+.

ActiveX-based implementations are found in Internet Explorer 5, 5.5, and 6. Browser

support for XHRs is summarized in

Property or Method Description

readyState Integer indicating the state of

the request, either:

0 (uninitialized)

1 (loading)

2 (response headers received)

3 (some response body

received)

4 (request complete)

27

J2EE

Onreadystatechange Function to call whenever the

readyState changes

Status HTTP status code returned by

the server

(e.g., “200, 404, etc.”)

statusText Full status HTTP status line

returned by the server (e.g.,

“OK, No Content, etc.”)

responseText Full response from the server

as a string

responseXML A Document object

representing the server’s

response

parsed as an XML document

abort() Cancels an

asynchronous HTTP

abort() Cancels an asynchronous HTTP

request

getAllResponseHeaders() Returns a string containing all

the HTTP headers the server

sent in its response. Each

header is a name/value pair

separated by a colon and

header lines are separated by

a

carriage return/linefeed pair

28

J2EE

9. XML

9.1 Introduction

XML stands for the eXtensible Markup Language. It is a new markup language,

developed by the W3C (World Wide Web Consortium), mainly to overcome

limitations in HTML. The W3C is the organization in charge of the development and

maintenance of most.

HTML is an immensely popular markup language. According to some studies there

are 800 million Web pages, all based on HTML. HTML is supported by thousands of

applications including browsers, editors, email software, databases, contact managers,

and more.

Originally, the Web was a solution to publish scientific documents. Today it has

grown into a full-fledged medium, equal to print and TV. More importantly, the Web

is an interactive medium because it supports applications such as online shops,

electronic banking, and trading and forums.

To accommodate this phenomenal popularity, HTML has been extended over the

years. Many new tags have been introduced. The first version of HTML had a dozen

tags; the latest version (HTML 4.0) is close to 100 tags .

Furthermore, a large set of supporting technologies also has been introduced:

JavaScript, Java, Flash, CGI, ASP, streaming media, MP3, and more. Some of these

technologies were developed by the W3C whereas others were introduced by vendors.

However, everything is not rosy with HTML. It has grown into a complex language.

At almost 100 tags, it is definitively not a small language. The combinations of tags

are almost endless and the result of a particular combination of tags might be different

from one browser to another.

Finally, despite all these tags already included in HTML, more are needed. Electronic

commerce applications need tags for product references, prices, name, addresses, and

more. Streaming needs tags to control the flow of images and sound. Search engines

need more precise tags for keywords and description. Security needs tags for signing.

The list of applications that need new HTML tags is almost endless.

29

J2EE

10. STRUTS

Web applications differ from conventional websites in that web applications can

create a dynamic response. Many websites deliver only static pages. A web

application can interact with databases and business logic engines to customize a

response.

Web applications based on JavaServer Pages sometimes commingle database code,

page design code, and control flow code. In practice, we find that unless these

concerns are separated, larger applications become difficult to maintain.

One way to separate concerns in a software application is to use a Model-View-

Controller (MVC) architecture. The Model represents the business or database code,

the View represents the page design code, and the Controller represents the

navigational code. The Struts framework is designed to help developers create web

applications that utilize a MVC architecture.

The framework provides three key components:

A "request" handler provided by the application developer that is mapped to a

standard URI.

A "response" handler that transfers control to another resource which

completes the response.

A tag library that helps developers create interactive form-based applications

with server pages.

The framework's architecture and tags are buzzword compliant. Struts works well

with conventional REST applications and with nouveau technologies like SOAP and

AJAX.

10.1 Design goals and overview

In a standard Java EE web application, the client will typically submit information to

the server via a web form. The information is then either handed over to a Java

Servlet that processes it, interacts with a database and produces an HTML-formatted

30

J2EE

response, or it is given to a JavaServer Pages (JSP) document that intermingles

HTML and Java code to achieve the same result. Both approaches are often

considered inadequate for large projects because they mix application logic with

presentation and make maintenance difficult.

The goal of Struts is to cleanly separate the model (application logic that interacts

with a database) from the view (HTML pages presented to the client) and the

controller (instance that passes information between view and model). Struts provides

the controller (a servlet known as ActionServlet) and facilitates the writing of

templates for the view or presentation layer (typically in JSP, but XML/XSLT and

Velocity are also supported). The web application programmer is responsible for

writing the model code, and for creating a central configuration file struts-

config.xml that binds together model, view and controller.

Requests from the client are sent to the controller in the form of "Actions" defined in

the configuration file; if the controller receives such a request it calls the

corresponding Action class that interacts with the application-specific model code.

The model code returns an "ActionForward", a string telling the controller what

output page to send to the client. Information is passed between model and view in the

form of special JavaBeans. A powerful custom tag library allows it to read and write

the content of these beans from the presentation layer without the need for any

embedded Java code.

Struts also supports internationalization by web forms, and includes a template

mechanism called "Tiles" that (for instance) allows the presentation layer to be

composed from independent header, footer, and content components.

31

J2EE

11. CONCLUSION

The pace of business is getting faster and faster, with a greater need to compete and

sustain a market. In this age of e−commerce, e−business, e−tailing, and other e's,

"traditional" system development just doesn't cut it anymore. Java Platform,

Enterprise Edition or Java EE is a widely used platform for server programming in

the Java programming language. TheJava platform (Enterprise Edition) differs from

the Java Standard Edition Platform (Java SE) in that it adds libraries which provide

functionality to deploy fault-tolerant, distributed, multi-tier Java software, based

largely on modular components running on an application server.

The Java platform comes in three flavours: Standard Edition, Enterprise Edition and

Macro Edition. The Enterprise Edition (J2EE) builds the Standard Edition & includes

number of technologies, such as Enterprise JavaBeans(EJB), Servlet and JavaServer

Pages, used for building enterprise server side- applications.

32

J2EE

REFERENCES

[1] Enterprise JavaBeans, Third Edition , Richard Monson-Haefel

[2] JavaServer Pages, Hans Bergsten

[3] www.java.sun.com

Research Paper helphttps://www.homeworkping.com/

33