J2EE Complete Reference - Ch01

Color profile: Generic CMYK printer profile
Composite Default screen Complete Reference / J2EE: TCR / Keogh / 222472-x / Chapter 1
Chapter 1
Java 2 Enterprise
Edition Overview
P:\010Comp\CompRef8\472-x\ch01.vp
Thursday, August 15, 2002 2:00:01 PM
4 J2EE: The Complete Reference
hroughout the course of history there have been periods where disruptive
T technology revolutionized everyday life and forced the scientific, political,

and economic communities to rethink their practices. Electricity, the telegraph,
telephone, radio, television, automobile, airplanes, satellites, and cable television are
technologies that radically altered the status quo to become a demarcation between old
and new. Generations define themselves by these radical changes in technology.
The Internet is the most recent technology to change the way we interact with each
other and change the way we do business. Transactions and communication occur online
and are nearly instantaneous. Overnight mail has been replaced by email sent at almost
the speed of light. Junk mail has been replaced by spam. Most banking is handled at
home or at work. And buying a special gift is a few keystrokes away.
Disruptive technologies spawn supportive technologies that become its integral
component and make the disruptive technology operate more effectively. Java 2 Enterprise
Edition is a supportive technology that is closely associated with the Internet. This is
because Java 2 Enterprise Edition enables software engineers and programmers to create
an industrial-strength software infrastructure that makes web-based applications cost-
effective to build and reliable to use in any mission-critical system.
Although Java 2 Enterprise Edition seems to be rooted with the Internet, it is really
the next growth spurt in the evolution of programming languages. In this chapter, I’ll
take you on a brief tour of the genealogy of Java 2 Enterprise Edition, which will piece
together the puzzle of how forerunner programming languages became the foundation
for today’s Java 2 Enterprise Edition (J2EE).
The ABC of Programming Languages

Over the years there have been numerous attempts to make it easy for programmers to
write instructions that are processed by computers. And it seems that a single letter of
the alphabet identifies some of these early languages. One of the earliest programming
languages is assembly language. Assembly language requires a programmer to use rather
abstract symbols to represent machine instructions that direct a central processing unit
(CPU) to move and manipulate bytes of information inside the computer.
Programmers can write highly efficient programs using assembly language because
assembly language syntax gives a programmer direct low-level access to hardware. For
example, a programmer can specify a specific memory address or a specific register
within the CPU to store data, which is not possible in many other languages.
Although assembly language can produce efficient programs, assembly language is
difficult to learn, difficult to use effectively, and a nightmare to debug. These drawbacks
became the impetus for the creation of more programmer-friendly languages such as
FORTRAN, COBOL, and BASIC. Instead of using abstract symbols as found in assembly
language, these languages use English-like words and punctuation to create computer
instruction.
Chapter 1: Java 2 Enterprise Edition Overview 5
FORTRAN, COBOL, and BASIC had their strengths and weaknesses, too. FORTRAN
was designed to write efficient scientific applications, but lacked the power necessary
J2EE BASICS
to produce system code. COBOL was the choice for writing business applications.
However, it too couldn’t be used to generate system code. And both languages weren’t
as easy to learn as BASIC. BASIC was an all-purpose programming language that was
intuitive to learn, but lacked the efficiency necessary to build industrial-strength
applications.
And all three of these languages failed to follow structured principles for controlling
the flow of a program. This resulted in the creation of countless code segments that
were linked together by conditional branches and caused a typical program to jump
from code segment to code segment, creating an organization widely known as
spaghetti code.
The Pascal programming language is another early programming language that
was originally used to teach students how to program and later found an unsuccessful
trek into industry. The Pascal programming language successfully gave structure to
programming, something that was lacking in other languages. However, early Pascal
syntax lacked features that were key to the creation of system code and application
programs—and therefore the Pascal programming language wasn’t widely adopted
by programmers.
FORTRAN, COBOL, BASIC, and Pascal were programming languages developed prior
to the computer revolution of the early 1970s. Until then, system-level programming was
kept away from most programmers. But that was to change as technologists focused on
developing a computer language that was easy to learn, well structured, and could be used
to build both industrial-strength system code and application code.
The B and C of Programming Languages

Technologists from the Cambridge University computer lab joined with colleagues from
London University in the early 1960s to design a programming language that made it easy
for computers to be programmed. Their efforts resulted in the Cambridge Programming
Language (CPL). CPL (sometimes referred to as the Combined Programming Language)
was a complex language, which probably inhibited its wide adoption.
Towards the end of that decade, Martin Richards (who worked at Cambridge
University) simplified CPL. Richards called his version of CPL Basic CPL (BCPL),
which was designed to program the IBM 370 computer. In BCPL, the type of an object is
inferred from the context in which the object is used rather than defined by a data type
within the program. Listing 1-1 is a sample of BCPL. You can read more about BCPL in
BCPL: The Language and Its Compiler by Martin Richards and Colin Whitby-Strevens.
BCPL was used in Cambridge University until the late 1980s when the Cambridge
University computer lab moved to C.
Listing 1-1 LET START () BE $(

A sample of LET F(N) = N=0 -> 1, N*F(N-1)
BCPL. FOR I = 1 TO 10 DO WRITEF(""F(%N), = %N*N"", I, F(I))
FINISH
$)
A paper describing BCPL was published in the proceeding of the 1969 AFIPS spring
Joint Computer Conference. In the same year, Ken Thompson (with assistance from
Dennis Ritchie) set out to develop the UNIX operating system written in PDP-7
assembler. Thompson felt UNIX needed a high level language for UNIX to provide a
beneficial computing service. He looked towards FORTRAN as the solution.
Thompson used a language called TMG, developed by Doug Mcllroy, to create a
flavor of FORTRAN for UNIX. But that only lasted about a week. Instead of FORTRAN,
Thompson defined a new language that was greatly influenced by BCPL. He called
the language B. The B programming language was used to program the PDP-7 and
subsequently the PDP-11. Listing 1-2 illustrates a function written in the B programming
language. A major difference between BCPL and the B programming language is that
BCPL is a typeless programming language and the B programming language is a single-
type programming language where a word was only type.
Listing 1-2 infact (n)

A sample {
of the B auto f, i, j;
programming
language. extrn fact;
f = 1;
i = 0;
for (i=0; i <= n; ++i) {
fact[i] = f = #* j;
i =#+ 1;
}
return (f);
}
The B programming language sufficed for a couple of years, but it gradually became
inefficient. And an attempt to embellish the language with the creation of the NB
language (New B) fell short of its mark. However, Dennis Ritchie’s effort succeeded in
the early 1970s. He called the new language the C programming language.
Ritchie was able to create the C programming language without the drawbacks
found in previous programming languages. Many believe that Ritchie’s success was
strongly influenced by the fact that Ritchie was a practicing programmer and designed
the C programming language to conform to the way he and other programmers develop
J2EE BASICS
software. That is, programmers divide a program into its functionality and create code
segments called functions to define the functionality.
This approach was a radical departure from the traditional ways in which
programming languages were developed. Up to that time, committees of academics
designed programming languages, which typically lacked features professional
programmers needed to create effective and efficient programs.
The C programming language was designed by a programmer for professional
programmers and had the power and structure that is necessary to build industrial-
strength programs. It was these factors that caused programmers to rapidly embrace
the C programming language. The C programming language revolutionized the way
programs were designed and written.
The C programming language was distributed with UNIX and soon became the de
facto standard for writing UNIX programs. In 1990 the American National Standards
Institute (ANSI) formally adopted a standard for the C programming language.
Taking Programming Languages Up a Notch

The computer revolution of the 1970s increased the demand for sophisticated computer
software to take advantage of the ever-increasing capacity of computers to process data.
The C programming language became the linchpin that enabled programmers to build
software that was just as robust as the computer it ran on.
As the decade of the 1980s approached, programmers were witnessing another spurt
in the evolution of programming language. Computer technology advanced to a point
beyond the capabilities of the C programming language. The problem wasn’t new. It
occurred previously and caused the demise of generations of programming languages.
Simply stated, the problem was that programs were becoming too complicated to design,
write, and manage to keep up with the capabilities of computers.
The number of lines of code contained in the program measures a program’s
complexity. Early computers were programmed by toggling switches to encode
machine instructions with binary values. Only a couple of hundred instructions could
practically be programmed. Advances in computer technology drove demand for
increasingly complex programs. The programming community responded with the
creation of assembly language, which could handle hundreds of lines of code.
The need for more complex software continued. While assembly language and
subsequent programming language could technically process thousands of lines of
code, it was the human element that became a barrier from building more complex
software. That is, thousands of lines of code are difficult to comprehend and manage.
And this too affected the C programming language. A C program that consists of
50,000 lines of code is impractical to maintain. This meant that the C programming
language that once radically altered the way software was written was also developing
a weakness, which sent technologists looking for a better way to design and write
programs.
It was the early 1980s when a new design concept moved programming to the next
evolutionary step. This was the period when object-oriented programming (OOP) took
programmers by storm, and with it a new programming language called C++.
Object-oriented programming changed the way in which programmers designed
applications. The C programming language required programmers to divide an
application into data and functionality, called functions, that weren’t bound together by
program instructions. Object-oriented programming enabled programmers to divide
an application into objects that resembled real-life objects all too familiar to
programmers and users of the application.
The real world is built from objects, and objects are built from one or more other
objects. For example, a house is an object that is comprised of other objects such as
doors, windows, walls, ceilings, and floors.
Each object has data associated with it and functionality. For example, data associated
with a window consists of height, width, length, and style among other characteristics.
A window’s functionality includes opening and closing the window.
In an object-oriented program both data and functionality are directly bound to an
object without program instructions. This is a startling contrast to C programming,
where data and functionality are naturally disassociated from each other. This meant
that while the C programming language could be used to create objects, the language
lacked the features that would naturally bind data and functionality to an object.
In 1979, Bjarne Stroustrup of Bell Laboratories in New Jersey enhanced the C
programming language to include object-oriented features. He called the language
C++. (The ++ is the incremental operator in the C programming language.) C++ is
truly an enhancement of the C programming language, and began as a preprocessor
language that was translated into C syntax before the program was processed by
the compiler.
Stroustrup introduced the concept of a class from which instances of objects are
created. A class contains data members and member functions that define an object’s
data and functionality. He also introduced the concept of inheritance that enabled a
class to inherit some or all data members and member functions from one or more
other classes—all of which complements the concepts of object-oriented programming.
By 1998, ANSI officials standardized Stroustrup’s C++ specification.
The Beginning of Java

Just as C++ was becoming the language of choice for building industrial-strength
applications, another growth spurt in the evolution of programming language was
budding, fertilized by the latest disruptive technology—the World Wide Web.
The Internet had been a well-kept secret for decades before the National Science
Foundation (which oversaw the Internet) removed barriers that prevented the Internet’s
commercialization. Until 1991, when it was opened to commerce, the Internet was the
exclusive domain of government agencies, the academic community, and anyone else
J2EE BASICS
able to connect.
Once the commercialize barrier was lifted, the World Wide Web, one of the several
services offered on the Internet, became a virtual community center where visitors
could get free information about practically anything and browse through thousands
of virtual stores.
Browsers power the World Wide Web. A browser interprets ASCII text files written
in HTML into an interactive display that can be interpreted on any machine. The browser
must be compatible with the correct version of HTML and HTTP implementation. This
meant any computer could use the same file without the programmer having to modify
the file, which was something unheard of at the time. Programs written in C or C++
were machine dependent and could not run on a different machine unless the program
was recompiled.
There has always been a compatibility problem with the client machine, one that
(among other reasons) was caused by the use of binary protocols used to communicate
between client machines and servers. Binary protocols are inflexible and are operating
system specific. However, protocols used to exchange data between client and server are
ASCII text based. This means that Internet protocols are not operating system dependent.
It didn’t take long before information technology departments of corporations realized
that substantial cost savings could be gained by adopting Internet technology for internal
use in the form of an intranet. An intranet is basically a corporation’s exclusive Internet
that can be accessed over a corporation’s internal computer network.
There was always interest in developing a machine-independent programming
language that enabled corporations and software manufacturers to build one application
that could run without modification on every computer. However, attempts to develop
such a versatile language always fell short of reaching its objectives. The programming
language closest to reaching this goal was C and C++—where source code is written
once, then compiled into an executable that was machine dependent.
Both C and C++ use a preprocessor that enables a programmer to quickly distinguish
the target environment. This means that a programmer can use one version of source
code to create executables for different machines. This is possible because C and C++
use conditional preprocessor directives in the source code, which tells the preprocessor
to include specific statements in the source code before the source code is compiled.
Listing 1-3 illustrates a preprocessor conditional directive that includes a comment in
the source code if the target environment is WIN32. WIN32 is defined in the program
as the operating system environment. Of course, the comment is replaced with
environment-specific statements in the source code.
Listing 1-3 #ifdef _WIN32

Here is a //include WIN32 statements here
sample of a #endif
preprocessor
condition
directive.
The success of the Internet gave renewed focus to developing a machine-

independent programming language—the same year the Internet was commercialized,
five technologists at Sun Microsystems, Inc. set out to develop a machine-independent
programming language. James Gosling, Patrick Naughton, Chris Warth, Ed Frank, and
Mike Sheridan spent 18 months developing the programming language that they called
Oak, which was renamed Java when this new language made its debut in 1995.
Java had gone through numerous iterations between 1991 and 1995, during which
time many other technologists at Sun Microsystems, Inc. made substantial contributions.
These included Bill Joy, Arthur van Hoff, Jonathan Payne, Frank Yelin, and Tim Lindholm.
Although Java is closely associated with the Internet, Java was developed as a
language for programming software that could be embedded into electronic devices
regardless of the type of CPU used by the device, such as programs that run consumer
appliances.
The Java team from Sun Microsystems, Inc. succeeded in creating a portable
programming language, something that had eluded programmers since computers
were first programmed. Their success, however, was far beyond their original dreams.
The same concept used to make Java programs portable to electronic devices also could
be used to make Java programs run on computers running Microsoft Windows, UNIX,
and Macintosh.
Timing was perfect. The Internet/intranet had wetted corporate America’s appetite
for cost-effective portable programs that could replace mission-critical applications
within the corporation. And Java had proven itself as being a programming language
used to successfully develop machine-independent applications.
It was in the mid-1990s when the team from Sun Microsystems, Inc. realized that
Java could be easily adapted to develop software for the Internet/intranet. Towards
the turn of the century, many corporations embraced Java and began replacing legacy
applications—many of which were written in C and C++—with Java Internet/intranet-
enabled applications.
Java and C++

In keeping with the genealogical philosophy where only the dominant genes are passed
on to the next generation, the Java development team at Sun Microsystems, Inc.
incorporated the best of C++ into Java and left out features of C++ that were inefficient
and not programmer friendly. The Java team also created new features that gave Java
the dynamics necessary for Internet-based programming.
Many of the primitive constructs of the Java language are similar to, and at times
exactly the same as, constructs in C++. For example, Java is an object-oriented
programming language that uses classes to create instances of objects. Those classes
have data members and member methods similar to classes found in C++.
However, Java doesn’t have pointers, which is a cornerstone of the C++ (and C)
programming language. Pointers, while efficient when used properly, can be difficult
to master and can cause runtime errors when improperly used in a C++ program.
Java comes with automatic garbage collection, which is not found in C++ (and C).
Garbage collection is a routine that recovers spent memory without the programmer
J2EE BASICS
having to write code to free previously reserved memory. You’ll find a complete
discussion on the features of Java in Java 2: The Complete Reference. The Java development
team was wise to base Java on C++ because C++ programmers find transitioning to
Java a straightforward process, which is why corporations that have a staff of C++
programmers look favorably on Java.
The close relationship between Java and C++ has led more than a few programmers
to assume that the purpose of Java is to enhance the C++ programming language—and
eventually replace C++. This isn’t true. Both languages are designed to solve different
problems. Java is designed for applications that must coexist on different kinds of
machines—and frequently over an Internet-based infrastructure. In contrast, C++ is
designed to run on a specific machine, although a C++ program can be recompiled to
run on other machines.
Java Bytecode
Java programs are written similar to C++ programs in that the programmer writes
source code that contains instructions into an editor or in an integrated development
environment, and then the source code is compiled. However, that’s where Java and C++
part ways. The compiling and linking process of a C++ program results in an executable
that can be run on an appropriate machine. In contrast, the Java compiler converts Java
source code into bytecode that is executed by the Java Virtual Machine (JVM).
The JVM is an interpreter of Java bytecode, which is a throwback to days when
BASIC programs were converted to machine code at runtime rather than compile time.
Very few, if any, modern programming languages except for Java are interpreted at
runtime. Instead, programs are compiled and linked to the more efficient executable.
At first blush, one would expect a Java program to take a performance hit because
an additional processing step is necessary at runtime to convert each instruction into
machine code. However, performance degradation caused by runtime translation is
minimized through optimization of the Java source code into bytecode at compile time.
Furthermore, Java minimizes the number of instructions that must be translated by
shifting many instructions to the JVM and by dividing instructions into function
components.
Machine-specific instructions are not included in bytecode. Instead, they already
reside in the JVM, which is machine specific. This means that the bytecode might contain
fewer instructions that need to be translated than a comparable C++ program.
As you’ll learn in the next chapter and throughout this book, a Java 2 Enterprise
Edition program is typically designed around functional components, each of which
might be a separate bytecode file. Therefore, instead of including all functionality in the
program—which is the case with many C++ programs—a J2EE program could consist
of several bytecode files each called and translated as needed by the program.
Therefore, although the Java compiler generates bytecode that must be interpreted
by the JVM at runtime, the number of instructions that need translation is usually
minimal and have already been optimized by the Java compiler.
Sun Microsystems, Inc. is sensitive to concerns that bytecode must be interpreted
at runtime, and to alleviate these concerns they have included a Just In Time (JIT)
compiler with the JVM in the Java 2 release. The JIT compiler converts bytecode into
executable code at runtime, which in many cases boosts performance significantly.
JIT compiling occurs as needed by the JVM, rather than compiling the complete
Java program into an executable. This is because the JVM performs certain checks at
runtime that cannot be performed on the executable itself.
The Advantages of Java

The Java development team at Sun Microsystems, Inc. released Java at a perfect time,
just when the Internet community was moving from passive data to dynamic programs.
Internet users were wowed by the ability to click hyperlinks to display web pages that
were filled with text and pictures. However, that thrill quickly lost its magic. Internet
users wanted real-time interaction with web pages rather than receiving passive data
that they simply read.
They wanted more personalized responses from web pages—and so did corporations
that sought to bring electronic commerce to the Internet. Among other wishes,
corporations needed a way to build dynamic catalogs and online shopping, and a way
to make shopping at their virtual store an experience that kept customers coming back.
Static web pages couldn’t offer the dynamics demanded by Internet users and
corporations. Only an executable program could provide the power for customized
interactions. Unfortunately, executable programs were machine dependent, and the
Internet was machine independent. The door was opened for the new programming
language to enter and provide the means to transform the passive Internet into a dynamic
and alive cyberspace.
The Internet posed a programming challenge unlike previous challenges. This is
because of the way the Internet operates. Typically, a user tells the operating system
to run an executable. Both the request and the execution occur on the user’s computer,
commonly called a client. The executable is machine dependent. However, it works
differently on the Internet. The web server initiates the program that is executed by the
client, rather than the user, and therefore the executable must be portable and machine
independent.
For example, when a user selects a hyperlink on a web page, the browser requests
that the web server download to the client the web page associated with the selected
hyperlink. Embedded in the web page might be a reference to run a small Java program
called an applet. The browser reads the reference to the applet, then requests that the web
server download the applet. Once the applet is received, the browser requests that the
JVM execute the applet automatically without any additional interaction by the user.
Although applets are downloaded in the same way as images, applets contain the
intelligence to personalize the user experience by reading tiny amounts of information,
J2EE BASICS
called cookies, that are stored on the client and interact directly with users through
user input.
Applets
Java broke ground in a new direction by giving programmers a choice to create one of
two types of executables. These are an applet or an application. An applet is a small
program that can be efficiently downloaded over the Internet and is executed by a
Java-compatible browser. An application is a program that is executed directly by the
user. The Java programming language can be used to create both an applet and an
application.
The Internet is founded on two important principals. First, information should
be freely shared, and second, web pages and other files sent to clients are safe to
download and use. Unfortunately, not everyone lives up to the second principal.
Some programmers introduced malicious programs that can wreak havoc on a client’s
computer if downloaded from a server.
The Java team at Sun Microsystems, Inc. anticipated this potential security concern
and created a barrier, sometimes referred to as a firewall, between an applet and the
client’s operating system. All applets are restricted to the Java environment (JVM) and
are prohibited from interacting with the client’s operating system. For example, an
applet does not have disk drive access except to read and write cookies, and an applet
can only make a network connection to the server that downloaded the applet to
the browser.
Built for a Robust Environment

It has been said that the Sun Microsystems, Inc. Java development team created Java as
a programmer’s language much along the concepts developed by Ritchie and Stroustrup.
They then built upon this concept to make Java easy to learn, robust, and reliable, and
incorporated advanced concepts to meet the ever-growing demand for architecture-
neutral programs that work efficiently in a distributive environment.
The Java development team adopted many features found in C and C++, rather
than create an entirely new language. This subtle but important consideration made it
easy for existing programmers to assimilate Java. Furthermore, the team streamlined
Java to provide only a few ways of accomplishing a task. This is a critical factor when a
programmer must create industrial-strength programs that can continually deliver high
performance over networks with a global reach.
Mission-critical systems—and those not-so-mission-critical systems that help run
modern corporations are accessible from practically anywhere in the world. Information
that was once available only from the computer on an executive’s desktop is now
obtainable from an executive’s home office or hotel room, and soon from the executive’s
airline seat.
Corporations have built a robust network infrastructure that links together clients
and servers that directly or indirectly contain mission-critical information needed for
executives to make business decisions.
The network is the highway that transports information from clients to servers and
servers to clients. Networked programs make the transmission possible and provide the
intelligence for the executives to make sense of the information received from servers.
A key element of networked programs is that a program must be able to do multiple
tasks simultaneously so that many clients can interact with the program at the same
time. The Java development team designed Java to be a multithreaded programming
language where each thread is a process that can work independently from other
processes and permit multiple access to the same program simultaneously.
Multithreaded programming changes the way a programmer conceptualizes a
program. Rather than the programmer designing a program in functional subsystems,
the programmer focuses on behaviors—each of which can become a thread.
Furthermore, Java uses intra-address-space messaging to access remote objects
over the network. This is referred to as call to a remote method invocation, which is
discussed in Chapter 15.
Built-in Reliability
The Java development team at Sun Microsystems, Inc. have taken extraordinary steps
to beef up Java to prevent the most common reasons why programs fail at runtime.
Two of these are error handling and memory management.
Java has stringent rules for error handling within a program. Error-handling
routines must be located in the code near instructions that could cause errors. This
means a programmer will find it difficult to inadvertently overlook writing error-
handling routines.
Memory management is an aspect of programming that can lead to runtime errors.
In some programming languages, the programmer is directly responsible for managing
how the program uses memory. This means the programmer must write instructions to
allocate memory and then release that allocated memory once the program no longer
requires the memory. Once memory is freed, the program can reallocate memory for
another portion of the program.
In complex programs, it is easy for a programmer to mismanage memory by
releasing memory that is still being used by a portion of the program or by not freeing
previously allocated memory. This can lead to an out-of-memory condition during
runtime.
The Java development team made memory management automatic and removed
memory management from the programmer’s control. This process is called garbage
collection, where Java allocates memory and releases memory as necessary based upon
the needs of the program.
However, programmers still must test their programs for memory leaks, because in
some cases the Java garbage collector may not recognize complex relationships between
objects and memory management. Let’s say class A references class B and class B is
associated with a resource. When the Java garbage collector destroys class A, it will
J2EE BASICS
also destroy class B, but may not destroy the resource associated with class B. You can
learn more about Java garbage collection in Java 2: The Complete Reference.
Besides error trapping and memory management, the Java development team also
has Java double-check the code—once at compile time and another check at runtime by
the JVM. This means that once a program passes both checks, a programmer is assured
that the program will run predictably regardless of environmental conditions at either
the client or server.
For example, a common nightmare for programmers and users alike occurs when
changes are made to the operating system. There is always a lingering doubt of whether
or not existing programs on the system will work properly. However, programs written in
Java are secure because the JVM, and not the operating system, executes Java programs.
J2EE and J2SE

Java itself has undergone an evolution that has nearly taken on a life of its own.
Originally designed for programs that controlled electronic devices, Java made waves
in the Internet development community by providing a means to give intelligence to
passive web pages. However, the Java development team’s design has made Java the
programming language of choice for programming enterprise-wide, web-centric
applications.
Information technology departments had always sought ways to create cost-effective
computer applications. One approach is client/server architecture, which uses a two-
tier architecture where client-side software requests services from server-side software.
A traditional database application illustrates the two-tier architecture. Software
running on the client captures a request for information from a user, then formats the
request into a query that is sent over the network to the database server for processing.
The database server then transmits the requested data to the client, where software
presents data to the user.
Increasingly, backend systems and infrastructure grew as information technology
departments streamlined operations to deliver information and technology services
to the desktop. Client/server architecture exploded from a two-tier architecture to
a multi-tier architecture, where a client’s request to a server generates requests to other
servers that are connected together through a backbone network.
This is very similar to you asking a travel agent to arrange your vacation. The travel
agent contacts hotels, airlines, the car rental company, restaurants, and other vendors
that are necessary to fulfill your request.
Although a multi-tier architecture provides services efficiently, it also makes it
complex to design, create, debug, distribute, and maintain an application because
a programmer must be assured that all tiers work together. However, the Java
development team enhanced the capabilities of Java to dramatically reduce the
complexity of developing a multi-tier application.
The Java development team grouped together features of Java into three editions,
each having a software development kit (SDK). The original edition of Java is called the
Java 2 Standard Edition (J2SE) and consists of application programming interfaces
(APIs) needed to build a Java application or applet.
The Java 2 Mobile Edition (J2ME) contains the API used to create wireless Java
applications. And the Java 2 Enterprise Edition, an enhanced version of the J2SE, has
the API to build applications for a multi-tier architecture.
The Birth of J2EE

For the Internet to grow, web applications required a way to interact with backend
services such as a database and dynamically generate web pages. Common Gateway
Interface (CGI) technology was a solution that was adopted by many corporations.
CGI technology consisted of a program that was callable by a browser whenever the
appropriate hyperlink or submit action from a web form occurred.
In addition to calling a CGI program, the browser was also able to pass the CGI
program data that was either entered by the user into a form on the web page or hard-
coded in the hyperlink. The CGI program used this data to interact with components of
the corporation’s infrastructure, such as retrieving account information from a database.
This information was then incorporated into a web page that the CGI program
dynamically generated and sent to the browser for display.
CGI technology addressed the problem of interfacing web clients with the
corporate infrastructure. However, a new set of problems appears as corporations
increasingly move towards web-centric applications. CGI technology was resource
intensive and not scalable to meet the dramatic increase in the number of clients who
needed to access corporate resources through CGI programs.
The Java development team devised a solution to problems associated with
CGI technology. Their solution was scalable and required fewer resources than CGI
technology, and yet was capable of interfacing with the corporate infrastructure and
generating dynamic web pages. Their solution was a Java servlet.
A Java servlet consists of Java classes, data, and methods, which are callable by a
browser similar to how a browser calls a CGI program. You’ll learn all about Java
servlets in Chapter 10.
Although Java servlets improved upon the foundation laid by CGI technology, Java
servlets suffered from a serious drawback. A Java servlet requires programmers to be
knowledgeable about the Java programming language. Web programmers at that time
were proficient in HTML and scripting languages such as JavaScript, but not comfortable
with a full-featured programming language such as Java. Java was used for nearly all
coding in a Java servlet and HTML code was used only in output statements that were
sent to the browser.
This posed a problem for the Java development team. Java servlets had to be made
easier to program before they’d be widely accepted by web programmers. Their solution
was to create a new technology called JavaServer Pages (JSP). JSP programs could be
written with little if any knowledge of Java, because most of the coding in a JSP program
is written in HTML with snippets of Java code intermingled. A JSP program is then
J2EE BASICS
automatically translated into a Java servlet. You’ll learn how to create JSP programs in
Chapter 11.
Databases
Nearly every web-centric application requires access to a corporation’s database so that
clients can enter new information, recall existing information, and modify (if necessary)
information the corporation has on file.
There are many database management system (DBMS) products on the market that
are used to manage data. These include Oracle, DB2, Informix, Sybase, and others. Each
DBMS product uses proprietary algorithms and software to manage data. This posed
another dilemma for the Java development team, but one that was easily overcome by
the standardization that had taken place in database technology.
The Java development team needed an API that would interface between commercial
DBMS products and Java. It would have been a maintenance nightmare if programmers
needed a different API for each database product, which had been the case in the early
days of database programming.
By the time the Java development team turned their attention to a database API, the
database community had already agreed on two major standards for DBMS products.
These are a relational database structure and Structured Query Language (SQL).
A relational database structure applies normalization rules that, among other
things, reduce redundancy in data by organizing data into groups that later take form
as tables. A table consists of rows and columns, similar to a spreadsheet, and tables are
related together using a common value in the rows of each table. The concept of a
relational database is discussed in detail in Chapter 5.
SQL is similar to a programming language in that SQL consists of keywords and
statements. However, SQL differs from a programming language in that instead of
instructing the operating system or JVM to perform tasks, SQL instructs a DBMS to
perform data management tasks.
The adoption of a relational database structure and SQL by the database community
simplified the task of the Java development team. They could create one API that
connected to the DBMS, formulated a SQL statement, sent the SQL statement to the
DBMS, then received information from the DBMS, which consists of the requested data
or a message. They called this the Java Database Connectivity (JDBC) API, which you’ll
learn how to use in Chapter 6.
The Maturing of Java

As previously mentioned, Java is an evolving programming language that began with
the release of the Java Development Kit (JDK). During this evolutionary process, the Java
development team included more interfaces and libraries as programmers demanded
new APIs. These new features to the JDK were called extensions, APIs that were
add-ons to the JDK. Sun Microsystems, Inc. incorporated these extensions into a new
Java Development Kit called Java 2 Standard Edition.
Information technology departments of corporations look towards web-centric
applications as a way to economize while offering streamlined services to employees
and customers. An increased emphasis was placed on server-side programming and
on development of vendor-independent APIs to access server-side systems.
Sun Microsystems, Inc. responded by creating the Java Community Program (JCP)
that invited corporate users, vendors, and technologists to develop a standard for
enterprise Java APIs. The JCP effort resulted in the Java 2 Platform, Enterprise Edition
commonly referred to as Java 2 Enterprise Edition (J2EE).
Java Beans and Java Message Service

J2EE is a combination of several technologies that offers a cohesiveness to bond
together server-side systems and services and produce an industrial-strength scalable
environment within which web-centric applications can thrive.
A critical ingredient in the development of J2EE is the collaborative environment
fostered by Sun Microsystems, Inc. within which vendors and technologists come
together in the JCP to create and implement Java-based technologies.
Two of these promising technologies included in J2EE are Enterprise Java Beans
(EJB) and the Java Message Service (JMS). EJB consists of specifications and APIs for
developing reusable server-side business components designed to run on application
servers. As you’ll learn in Chapter 12, EJB facilitates the breadth of processing required
by a business, including distributed transaction processing that is used in many web-
centric applications. Manufacturers of application servers have joined the JCP to create
a standard specification to implement EJB with their application servers.
For example, EJB is used to encode and share business logic among clients by using
a session bean, entity bean, or message-driven bean. A stateful session bean retains data
accumulated during a session with a client. The data is lost once the client no longer
references the bean. A stateless session bean does not maintain any state between method
calls. A message-driven bean is called by the JMS container. The message-driven bean
deployment descriptor specifies the type of messages it wants to receive. An entity
bean is used to collect and retain rows of data from a database, and survives as long
as the data associated with the bean is viable.
JMS is a standard and an API used to provide vendor-independent communication
with Message-Oriented Middleware (MOM). This means Java programs and middleware
can transact using a common language. JMS is the first standard written for earlier
technology. Until the arrival of JMS, vendors provided their own API for messaging.
Why J2EE?
With the onset of web-centric applications that grew more dependent than ever on
server-side technologies such as middleware, information technology departments of
corporations needed a sustainable way to develop applications and related middleware

that were portable and scalable.
J2EE BASICS
These applications needed to be designed to handle thousands of users simultaneously
24 hours a day, seven days a week, without any downtime. One of the major challenges
to building such a complex application is to be able to design and test it. J2EE simplifies
the creation of an enterprise-wide application, because functionality is encapsulated in
components of J2EE. This enables designers and programmers to organize the
application into functionality that is distributed across the server-side components built
using J2EE.
Furthermore, the collaboration of industry leaders in the JCP results in J2EE as the
industry standard enterprise environment within which all competitive products must
operate. This means corporate clients are assured that server-side products they purchase
are supported by J2EE. This also means that a corporation is no longer locked into one
vendor. Instead, products from multiple vendors can be mixed and matched based on
their cost-effectiveness while being bonded together with J2EE technology.
J2EE is a versatile technology because application components built using J2EE are
able to communicate with each other behind the scenes using standard communications
methods such as HTTP, SSL, HTML, XML, RMI, and IIOP.
All J2EE programs are written in Java, enabling a corporation to use its existing staff
of Java programmers to create programs that work at each layer of the multi-tier
infrastructure. Corporations no longer need to find programmers to write programs to
interface with a vendor-specific component. This also shortens the development cycle
for complex programs that require multithreading and synchronization, because J2EE
contains all the interfaces and libraries that handle these complex issues.
Java Beans, Java Servlets and JavaServer Pages are core components of J2EE. In
addition, J2EE consists of seven standard services, all of which are discussed throughout
this book. These services are as follows.
CORBA Compliance
Sun Microsystems, Inc. built into J2EE two CORBA technologies that enable Java programs
to communicate with any enterprise system that is compliant with CORBA technology
and to interact with legacy systems. These technologies are JavaIDL and RMI-IIOP.
JavaIDL is used to interconnect Java programs with CORBA-based systems. RMI-IIOP
is a blend of Java Remote Method Invocation API (RMI) and the Internet Inter-ORB
Protocol (IIOP) used with CORBA to link together Java programs and legacy systems.
JavaMail API
The Java development team needed an efficient way for customers and e-commerce
sites to exchange information such as order confirmations. The solution is JavaMail
API, which enables Java programmers to communicate by sending email messages
to web users.
Java Message Service

The Java Message Service (JMS) API is used to build into Java programs a transmission
link between components. This link enables fault-tolerant messages to be transmitted
and received in asynchronous mode.
Java Naming and Directory Interface API

Objects can be located in various locations on servers linked to the infrastructure of a
corporation. The Java development team required a method to enable Java programs to
easily locate these objects. Their solution was to create standardized naming conventions
and directories, and the Java Naming and Directory Interface (JNDI) API, so programmers
can look up objects from within their Java programs.
Java Transaction API

One transaction can involve multiple components, and the Java development team
needed a way for components to manage their own transactions. The team created the
Java Transaction API (JTA) to enable Java programmers to build into components
routines to handle transactions.
JDBC API
Many Java programs and components must access information contained in a
database, as previously discussed in this chapter. The Java development team devised
the JDBC API that enables a program to connect to and interact with practically any
commercial DBMS.
XML Deployment Descriptors

Many corporations and some industries have adopted XML as a way to store, manipulate,
and exchange textual information that appears in documents. The Java development
team has included a set of descriptors in J2EE that enable programmers to create tools
and components that can interact with XML documents. XML deployment descriptors
define the environment and the functionality of components when they are deployed
into the J2EE container. The J2EE container learns how and where to deploy components
by reading the deployment descriptors. Components don’t interact with deployment
descriptors. Some of the more common activities of XML deployment descriptors are to
■ Manage transactions between the container and Enterprise Java Beans

■ Register a message-driven bean to a queue
■ Define JNDI lookup names
■ Manage stateful and stateless session beans
Looking Forward
The Java programming language is the foundation on which J2EE is built. This chapter
J2EE BASICS
provided you with a look back at the evolution of programming language that has
culminated into the Java programming language. This evolution continues with
introduction of J2EE by Sun Microsystems, Inc. J2EE is used to create a new breed
of applications that are based on web services components. J2EE programmers don’t
write code in the traditional sense. Instead J2EE programmers assemble a J2EE
application from web services components.
The remainder of this book introduces you to the concepts of web services, J2EE
architecture and strategies for designing and building J2EE components that collectively
form a J2EE application.
You’ll learn database design, development, and how to access data from within a
J2EE application using JDBC API and XML. You’ll learn professional techniques for
building your own web components using Java servlets, JavaServer Pages, and
Enterprise Java Beans. And then you’ll learn how to interconnect web components to
form an industrial-strength J2EE application.

J2EE Complete Reference - Ch01

Uploaded by

Copyright:

Available Formats

J2EE Complete Reference - Ch01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

J2EE Complete Reference - Ch01

Uploaded by

Copyright:

Available Formats

Color profile: Generic CMYK printer profile

4 J2EE: The Complete Reference

T technology revolutionized everyday life and forced the scientific, political,

The ABC of Programming Languages

Chapter 1: Java 2 Enterprise Edition Overview 5

The B and C of Programming Languages

6 J2EE: The Complete Reference

Listing 1-1 LET START () BE $(

Listing 1-2 infact (n)

Chapter 1: Java 2 Enterprise Edition Overview 7

Taking Programming Languages Up a Notch

8 J2EE: The Complete Reference

The Beginning of Java

Chapter 1: Java 2 Enterprise Edition Overview 9

Listing 1-3 #ifdef _WIN32

10 J2EE: The Complete Reference

The success of the Internet gave renewed focus to developing a machine-

Java and C++

Chapter 1: Java 2 Enterprise Edition Overview 11

12 J2EE: The Complete Reference

The Advantages of Java

Chapter 1: Java 2 Enterprise Edition Overview 13

Built for a Robust Environment

14 J2EE: The Complete Reference

Chapter 1: Java 2 Enterprise Edition Overview 15

J2EE and J2SE

16 J2EE: The Complete Reference

The Birth of J2EE

Chapter 1: Java 2 Enterprise Edition Overview 17

The Maturing of Java

18 J2EE: The Complete Reference

Java Beans and Java Message Service

Chapter 1: Java 2 Enterprise Edition Overview 19

corporations needed a sustainable way to develop applications and related middleware

20 J2EE: The Complete Reference

Java Message Service

Java Naming and Directory Interface API

Java Transaction API

XML Deployment Descriptors

■ Manage transactions between the container and Enterprise Java Beans

Chapter 1: Java 2 Enterprise Edition Overview 21

You might also like