Handout – Java and the J2EE Platform - Gatineau Gliding Club

cabbagewheatInternet and Web Development

Nov 13, 2013 (4 years and 11 months ago)

117 views


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

Handout


Java and the J2EE Platform




Java and the J2EE Platform




The evolution of Java from a means of developing applets for running in browsers, to a
programming model capable of driving today’s enterprise application has been remarkable. Java
ha
s acted as a catalyst in making certain technology domains take more robust and secure shapes.
Java’s enterprise computing platform, a.k.a., the
Java 2 Platform, Enterprise Edition (J2EE)

is
one such domain. J2EE is one of the most successful attempts by

Sun and its associates at
making Java credible as a
platform

for enterprise computing.




The shift to an information economy is forcing many businesses to rethink even their most
basic business practices. In order to maintain a competitive edge, the a
doption of new
technologies has become a key factor in a company’s ability to succeed. As well, adapting these
new technologies to work in tandem with the existing, legacy systems has become one of the
foremost requirements of the enterprise.


The fund
ing and the time allocated to application development has been shrinking, while
demands for complexity have increased. As a result, today’s developer face several challenges:





Responsiveness,
adapting to new directions and information



Programming Product
ivity,
the ability to develop and deploy applications as effectively
and quickly as possible



Reliability and Availability,
your business transactions must be processed completely and
accurately, and your web site must not go down



Security,

as technology h
as become more advanced, and applications more sophisticated,
and enterprises more complex, the ability to implement effective security has become
increasingly difficult



Scalability,

the ability for an application to grow to meet new demand both in its op
eration
and in the number of users it services



Integration,
much of the information exists as data in old and outdated systems. New
applications must be able to integrate with existing information systems, not necessarily an
easy task




Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

There have always
been several technologies available to address one or more of the above
demands, but what has been missing is a comprehensive platform, with a rich infrastructure, and
numerous architectural possibilities that also promotes a rapid development environment.






System Architecture



When discussing enterprise application development, it is appropriate to introduce the concept of
n
-
tier architecture
. Typical client/server systems are based on the 2
-
tier system, whereby there
is a clear separation between th
e data and the presentation/business logic. These are generally
data driven, with the application existing entirely on the client machine, while the database
server is deployed somewhere else in the organization. Although it allows us to share data
acros
s the enterprise, it has many drawbacks.




2
-

Tier Architecture




In this situation, the processing load is given to the client PC while the server simply acts as a
traffic controller between the application and the data. As a result, application perfo
rmance
suffers not only because of the limited resources of the PC, but the network traffic tends to
increase as well. Another problem is that of maintenance. Even the smallest change to the
application might involve a complete rollout to the entire user

base. Even if you can automate
the process, you still have to do it to everyone. And, people being people, some will readily
make the change, while others will delay it.












Application


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE















3
-

Tier Architecture



In a 3
-

tier architecture, th
e application is broken up into three separate logical layers, each
with a well defined set of interfaces:




The first tier is referred to as the
presentation layer,
and typically consists of a graphical
user interface of some kind.



The middle tier, or
busi
ness layer,
consists of the application or business logic



The third tier, or
data layer,
contains the data that is needed for the application



The middle tier is basically the code that the user calls upon (through the presentation layer), to
retrieve the

desired data. The presentation layer then receives the data and formats it for display.
This separation of application logic from the user interface adds enormous flexibility for design.
Multiple user interfaces can be built and deployed, without ever
changing the design of the
application logic, as long as it presents a clearly defined interface to the presentation layer.


In other words, all the business layer does is receive a message from the GUI, and retrieve
data. Once the presentation layer re
ceives this data back, it is capable of massaging it into any
format necessary, for example web browser vs desktop application. As long as each different
presentation layer is expecting the data to come in the same way, there need be no change in how
the
business layer sends the data, even when a brand new interface is designed.


The third tier contains all the data necessary for the application, and this can be in any format
imaginable, which is why the term database has become replaced with the phrase da
ta store.




DB

User Interface


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

















N
-

Tier Architecture


There is no hard and fast way to define the application layers for an n
-
tier system. Just that there
can be many of them. In an n
-
tier architecture, the application logic is divided by func
tion,
rather than physically.


For example:




A
user interface
that handles the user’s interaction with the application. This could be a
web browser running through a firewall, a heavier desktop application or even a wireless
device



Presentation logic
that

defines what the user interface displays and how a user’s request are
handled. Depending on what user interfaces are supported, you may need to have slightly
different versions of the presentation logic to handle the client appropriately



Business logic
t
hat models the application’s business rules, often through the interaction with
the application’s data



Infrastructure services
that provide additional functionality required by the application
components, such as messaging, transactional support, etc.



The
data layer
where the enterprise’s data resides.



Applications based on this architecture are employing the
Model
-
View
-
Controller (MVC)

pattern. What this means is that the data ( the model ) is separated from how the information is
presented (the view ).

In between this is the application/business logic (the controller ) that
Application Logic

XML

Document
s

XML

Document
s

XML

Document
s

DB

DB


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

controls the flow of the information. An application is designed based on these three functional
components ( model


view


controller ) interacting with each other.


Picture page

11

















However, the above discussion has focused on a single application.
Enterprise architecture,
while still an n
-
tier system, requires a different focus. What we do is extend the middle tier by
allowing for multiple
application objects
ra
ther than just a single application. These application
objects must each have an interface that allows it to work with the others.



An interface can be thought of as a contract. Each object states through its interface that it will
accept certain parame
ters, and return a specific set of results. Application objects communicate
with each other through their interfaces.



It is a good idea to make the interface as generic as possible, to avoid changes later on. Since
other objects communicate with the in
terface, and not the object itself, changes to the object, and
not the interface, are relatively simple and quick.




Picture page 12





Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE























The J2EE Platform



J2EE is one of the best solutions we have so far for meeting the demands of
today’s enterprise.
It specifies both the infrastructure for managing you application and the service APIs for
building them


The J2EE platform is essentially a distributed application server environment which provides the
following:




A runtime infrastruc
ture for hosting applications



A set of Java extension APIs to build applications.


The applications that you can develop with the above may be programs to drive web pages, or
components to implement complex database transactions, or even Java applets


all

distributed
across the network.



The J2EE Runtime


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



J2EE bundles together APIs that have been existence in one form or another for some time, but
its significant achievement is its abstraction of the
runtime infrastructure
. The J2EE specifies
roles and

interfaces for applications, and the runtime onto which applications could be deployed.
This results in a clear demarcation between applications and the runtime infrastructure services
that enterprise developers have traditionally attempted to build on t
heir own. This is
accomplished through the use of containers. As a result, the programmer can focus on the
application logic and related services.


As mentioned above, the J2EE does not specify the nature and structure of the runtime. Instead
it introduc
es what is called a
container
, and via the J2EE APIs, specifies a contract between
container and applications.



The J2EE APIs



Distributed applications require access to a set of enterprise services. Typical services include
transaction processing, dat
abase access, messaging, etc. The J2EE architecture unifies access to
such services in its enterprise service APIs. However, instead of accessing these services
through proprietary or non
-
standard interfaces, in J2EE, application programs can access thes
e
APIs via the container.


A typical commercial J2EE application includes one or more containers, and access to the
enterprise APIs is specified by the J2EE.





The specification of the J2EE platform defines a set of Java standard extensions that each J2E
E
platform must support:




Java Database Connectivity (JDBC) 2.0 Extension,
this API improves the standard JDBC
2.0 API by adding better means of obtaining connections, connection pooling, distributed
transactions, etc.


JDBC is the Java Enterprise API for
working with relational database systems. JDBC allows
a Java program to send SQL query and update statements to a database server and to retrieve
and iterate through query results returned by the server. JDBC also allows you to get meta
-
information about

the database and its tables from the database server.



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

The JDBC API is independent of vendor
-
specific APIs defined by particular database
systems. The JDBC architecture relies upon a
Driver
class that hides the details of
communicating with a database se
rver. Each database server product requires a custom
Driver implementation to allow Java programs to communicate with it. Major database
vendors have made JDBC drivers available for their products. In addition, a “bridge” driver
exists to enable Java pr
ograms to communicate with databases through existing ODBC
drivers.


The JDBC API is found in the
java.sql

package, which was introduced in Java 1.1 . Java 1.2
also includes additional features, found in the
javax.sql bpackage,
which include classes for
t
reating database query results as JavaBeans, for pooling database connections, and for
obtaining database connection information from a name service. The extension package also
supports scrollable record sets, batch updates, and the storage of Java object
s in databases.





Remote Method Invocation over the Internet Inter
-
ORB Protocol (RMI
-
IIOP) 1.0 :
provides an implementation of the usual Java RMI API over IIOP. This bridges the gap
between RMI and CORBA applications


RMI is a programming model that provid
es a high
-
level generic approach to distributed
programming. It allows a client to communicate with a server by invoking methods on
remote objects that reside on the server. You invoke remote methods using the same syntax
you would use to invoke methods
of a normal local object.


This model for distributed computing can be implemented in a number of ways. One of
these ways is the Java Remote Object Method Invokation( RMI) API. It is implemented in
the
java.rmi
package and its subpackages, which were int
roduced in Java 1.1 and enhanced
in Java 1.2 .


It is full featured, yet easy to use. It gains simplicity by requiring that both the client and
server be implemented in Java. This ensures that both client and server share a common set
of data types and h
ave access to the object serialization and deserialization features of the
java.io
package, for example. On the other hand, this means that RMI cannot be used with
distributed objects written in languages other than Java. It also means that servers writt
en
using RMI can only be used by clients written in Java. Fortunately, there are many situations
where both client and server are Java programs.


CORBA ( Common Object Request Broker Architecture) is a widely used standard defined
by the Object Management

Group ( OMG ). This standard is implemented as a core part of
the Java 2 platform in the
org.omg.CORBA
package and its subclasses. The implementation

Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

includes an Object Request Broker ( ORB) that a Java application can use to communicate,
as both a clie
nt and a server, with other ORBs , and thus with other CORBA objects.




Enterprise Java Beans ( EJB ) 1.1:
specifies a component framework for multi
-
tier
distributed applications. This provides a standard means of defining server
-
side components,
and spec
ifies a rich runtime infrastructure for hosting components on the server side


Enterprise JavaBeans is a component model for units of business logic and business data.
Thin client programming models that take business logic out of the client and put it on

a
server, or in a middle tier, have many advantages in enterprise application. However, the
task of writing this middleware has always been complicated by the fact that business logic
must be mixed in with code for handling transactions, security, networ
king, and so on.


The EJB model separates high
-
level business logic from low
-
level housekeeping chores. A
bean in the EJB model is an RMI remote object that implements business logic or represents
business data. The difference between an enterprise bean
and a run
-
of
-
the
-
mill RMI object is
that EJB components run within an EJB container, which in turn runs within an EJB server.
The container and server may provide features such as transaction management, resource
pooling, lifecycle management, security, n
ame services, and so on. With all these services
provided by the container and server, enterprise beans( and enterprise bean programmers) are
free to focus purely on business logic. The particular set of services provided by an EJB
server is implementati
on
-
dependent.


The EJB specification is a document that specifies the contracts to be maintained and
conventions to be followed by EJB servers, containers and beans. Writing EJB components
is easy, you simply write code to implement your business logic, t
aking care to follow the
rules and conventions imposed by the EJB model.


Unlike the other Java Enterprise APIs, EJB is not really an API; it is a framework for
component
-
based enterprise computing. The key to understanding them lies in the
interactions a
mong beans, containers and the EJB server. There is, of course, an API
associated with the EJB application framework, in the form of the
javax.ejb
and the
javax.ejb.deployment
packages.




Java Servlets 2.2:
The Java Servlet API provides object
-
oriented abs
tractions for building
dynamic web applications



A servlet is a piece of Java code that runs within a server to provide a service to a client. The
name servlet is a takeoff on applet, with a servlet is a server
-
side applet. The Java Servlet

Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

API provides

a generic mechanism for extending the functionality of any kind of server that
uses a protocol based on requests and responses.


Right now, servlets are used primarily by web servers. They are a growing replacement for
CGI scripts. They can also replace

technologies such as Active Server Pages, by Microsoft.
The advantage of servlets over these other technologies is that servlets are portable among
operating systems and among servers. Servlets are persistent between invocations, which
gives them major
performance benefits over CGI programs. Servlets also have full access to
the rest of the Java platform, so features such as database access are automatically supported.


With the advent of the Internet, and the WWW, many enterprises are interested in tak
ing
advantage of web browsers


a universally available thin
-
client that can run on any desktop.
Under this model, the web server becomes enterprise middleware and is responsible for
running applications for clients. Servlets are a perfect fit here. The
user makes a request to
the web server, the web server invokes the appropriate servlet, and the servlet uses JNDI,
JDBC and other Java Enterprise APIs to fulfill the request, returning the result to the user,
usually in the form of HTML
-
formatted text.


Th
e Servlet API is a standard extension for the Java 2 platform, implemented in the
javax.servlet
and
javax.servlet.http
packages. The javax.servlet package defines classes
that represent generic client requests and server responses, while the javax.serlet.
http package
provides specific support for the HTTP protocol.





JavaServer Pages ( JSP ) 1.1:
this extension further enhances J2EE web applications by
providing for template
-
driven web application development





Java Message Service ( JMS ) 1.0:
JMS provide
s a Java API for message queuing, and
public and subscribe types of message
-
oriented middleware services


This is used for working with networked messaging services and for writing message
-
oriented middleward (MOM). The word “message” in the context of th
e JMS is a chunk of
data that is sent from one system to another. The data serves as a kind of event notification
and is almost always intended to be read by a computer program, not a human. In a
nondistributed system, an
Event
object notifies the progra
m that some important event (such
as the user clicking a mouse button) has occurred. In a distributed system, a message serves
a similar purpose: it notifies some part of the system that an interesting event has occurred.
You can think of a networked mes
sage service as a distributed event notification system.



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

Like JNDI and JDBC, JMS is an API layered on top of existing, vendor
-
specific messaging
services. In order to use JMS in your application, you need to obtain a JMS provider
implementation that supp
orts your particular message server.





Java Naming and Directory Interface (JNDI) 1.2:
The JNDI API standardizes access to
different types of naming and directory services available today. This API is designed to be
independent of any specific naming o
r directory service implementation. J2EE also specifies
a JNDI service provider interface (SPI) for naming and directory service providers to
implement


This is the API for working with networked naming and directory services. It allows Java
programs to u
se name servers and directory servers to look up objects or data by name and
search for objects or data according to a set of specified attribute values. JNDI is
implemented in the
javax.naming
package and its subpackages.


To support a particular protoco
l, you plug a service provider for that protocol into a JNDI
installation. Service providers have been implemented for the most common protocols, such
as NIS, LDAP and Novell’s NDS. Service providers have also been written to interact with
the RMI and CO
RBA object registries.





Java Transaction API 1.0:

This API is for implementing distributed transactional
applications





JavaMail 1.1:

This API provides a platform
-
independent and protocol
-
independent
framework to build Java based mail applications



All

of the above APIs are specifications, independent of implementation. That is, one should be
able to access the services provided by these APIs in a standard way, irrespective of how they are
implemented.










Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



J2EE Architecture


Containers



What is

a container? A J2EE container is a runtime to manage application components, and to
provide access to the J2EE APIs. The following figure shows the architecture of J2EE:







Figure page 17



















There are four types of containers in J2EE,
two of which are shown above:




An applet container to run applets



An application client container for running standard Java application clients



A web container for hosting Java servlets and JSP pages



An EJB container for hosting Enterprise JavaBeans



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

Apart

from access to the infrastructure
-
level APIs ( RMI and JDBC, for example), each container
also implements the respective container specific API ( Java Servlet API for the web container,
and the EJB API for the EJB container).


The stack of rectangle (serv
lets, JSP pages, and EJBs) in the figure are the programs that you
develop and host in these containers. These are called
application components
.



Web clients
normally run in web browser. For these clients, the user interface is generated on
the servers
ide as HTML or XML and is downloaded and then rendered by the browser. These
clients use HTTP to communicate with the web server. Application components in web
containers include Java servlets and JSP pages, which implement the functionality required for

web clients. Web containers are responsible for accepting requests from web clients, and
generating responses with the help of the application components.


EJB clients
are applications that access EJB components in EJB containers. An
application
client
is an example of an EJB client. They could be stand
-
alone applications accessing the EJB
components using the RMI
-
IIOP protocol, or they could be components of the web container.
That is, Java servlets and JSP pages can also access the EJB components via

the RMI
-
IIOP
protocol in the same way as a stand
-
alone application.



Container Architecture



In this architecture, you are required to provide the following:




Application components

which may include servlets, JSPs, EJBs, etc. These can be
packaged in
to archive files



Deployment descriptors,
which is an XML file that describes the activation components. It
also includes additional information required by containers for effectively managing
application components.






Figure page 18




Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE













The a
rchitecture of a container can be divided into four parts:




Component contract

which is a set of APIs specified by the container that your application
components are required to extend or implement



Container service APIs

which are additional services prov
ided by the container, commonly
required for all applications in the container



Declarative services,
which are services that the container interposes on your application,
based on the deployment description provided for each application component



Other con
tainer services

related to component lifecycle, resource pooling, garbage
collection, etc.



Component Contract


The purpose of a container in the J2EE architecture is to provide a runtime for application
components. Thus, instances of the application com
ponents are created and invoked within the
JVM of the container. This makes the container responsible for managing the lifecycle of
application components. However, for these application components to be manageable within
the container runtime, they are
required to abide by certain
contracts
specified by the container.


Consider a Java applet. Typically, a Java applet is downloaded by the browser, and instantiated
and initialized in the JVM of the browser. That is, the applet lives in the runtime provide
d by the
JVM of the browser.


In order for the container to be able to create, initialize, and invoke methods on application
components, the application components are required to implement or extend certain Java
interfaces or classes. Considering an appl
et again, a Java applet is required to extend the

Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

java.applet.Applet
class specified by the JDK. The JVM of the browser expects your applet to
extend this class.


This allows the browser’s JVM to call init( ), start( ), stop( ) and destroy( ) methods on

your
browser. These methods control the lifecycle of an applet, and without your applet extending the
java.applet.Applet class, the browser JVM has no means on calling these methods to control the
lifecycle of your applet.




In J2EE, all application compo
nents are instantiated and initialized in the JVM of the
container



Since J2EE application components are always remote to the client, clients cannot directly
call methods on these components



Since the container process is the only entry point into the appl
ication component, all
application components are required to follow the contract specified by the container



In J2EE, the contract is in the form of interfaces and classes that your classes implement or
extend


In the case of web containers, web applicatio
n components are required to follow the Java
Servlet and JSP APIs. In this model:




All Java servlets are required to extend the
javax.serlet.http.HttpServlet
class and then
implement certain methods of this class, like
doGet( ), doPost( )

etc.



When compil
ed, classes corresponding to JSP pages extend the
javax.servlet.jsp.HttpJspPage
class



In the case of EJB containers:




All enterprise beans are required to have
javax.ejb.EJBHome
and
javax.ejb.EJBObject
interfaces specified, while implementing either a
ja
vax.ejb.SessionBean
or
javax.ejb.EntityBean
interface




Container Service APIs


The J2EE platform defines a set of Java standard extensions that each J2EE platform must
support. J2EE containers provide a service
-
level abstraction of the APIs. As a resul
t, you can
access the service APIs such as JDBC, JTS, JNDI, JMS etc, within the container, as though the
underlying container were implementing them.


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE


In J2EE, application components can access the APIs via appropriate objects created and
published in a JN
DI service or implementation. For example, when you want to use JMS within
your application components, you configure your J2EE platform to create JMS connection
factories, message queues and topics and publish these objects in the JNDI service. Your
app
lication can then look in the JNDI, obtain references to these objects, and invoke methods. In
this process, it does not matter if your J2EE platform has a JMS implementation built
-
in or it is
using a third
-
party messaging middleware solution.



Declarati
ve Services


One of the most important features of the J2EE architecture is its ability to dynamically interpose
services for application components. This is based on declarations specified outside your
application components. The J2EE architecture provi
des a simple means of specifying such
declarations. These are called
deployment descriptors
.


A deployment descriptor defines the contract between the container and component. You are
required to specify a deployment descriptor for each group of applicat
ion components. For
example, a set of EJB components can be described together in a single deployment descriptor
file. In the case of web containers, each web appliation is required to have a deployment
specified.


Depending on the type of the component,

certain types of services (such as transactions, security,
etc) can be specified in the deployment descriptor. The purpose of this approach is to minimize
the application programming required in order to make use of such services.


The standard way of in
voking J2EE services is via
explicit invocation
. For example, to
implement transactions for database access, you can programmatically start a transaction before
accessing the database, and commit or rollback the transaction once the business methods are
c
ompleted. In the case of
declarative invocation
, your application components need not
explicitly start and stop transactions. Instead, you can specify in the deployment descriptor that
your business methods should be invoked within a new transaction. Ba
sed on this information,
the container can automatically start a transaction whenever the business methods in your
applications are invoked.


In simple terms, a declarative service is a service or action that is provided by the container on
your behalf.



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

Because the container receives the request first, then passes it along to the appropriate
application component, the container has a chance to
interpose

a new service before passing
along the method, such as starting a transaction.



Other Container Servi
ces


These include:




Lifecycle management of application components
, which involves creating new instances
of application components, and pooling or destroying them when the instances are no longer
required




Resource pooling
: containers can optionally imp
lement resource pooling such as object
pooling and connection pooling




Population of the JNDI name space based on the deployment names associated with
EJB components
: this information is typically supplied at deployment time




Population of the JNDI name sp
ace with objects necessary for utilizing container
service APIs,
which include data source objects for database access, etc.




Clustering:
In J2EE, containers can be distributable. A distributable container consists of a
number of JVMs running on one or m
ore host machines. In this setup, application
components can be deployed on a number of JVMs, in order to help distribute the load, for
example.




J2EE Technologies


There are three separate technologies that provide the mechanics we need to build larg
e,
distributed enterprise applications:




Component Technologies
, these are used to hold the most important part of the application


the business logic. There are three types of components, JSP, servlets and Enterprise
JavaBeans



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



Service Technologies
, whi
ch provide the application’s components with supported services
to function efficiently




Communication Technologies
, which are mostly transparent to the application programmer,
provide the mechanisms for communication among different parts of the applicati
on, whether
they are local or remote



1. Component Technologies



The most important part of any application is modeling the necessary business logic through
the use of components


application level reusable units. These components will be dependent
on their container for many services, such as life
-
cycle management, threading, security, etc.
This allows you to concentrate on providing the required business functionality without getting
into details of low
-
level container
-
level semantics. There are
three technologies for developing
components:




Servlets





JavaServer Pages


They provide a way to embed components in a page, and to have them do their work to
generate the page that is eventually sent to the client. A JavaServer Page can contain HTML
cod
e, Java code, and JavaBean components. JavaServer Pages are an extension of the servlet
programming language; when a user requests a JSP page, the web server compiles the JSP
page into a servlet. The web server then invokes the servlet and returns the re
sulting content
to the web browser. Once the servlet has been compiled from the JSP page, the web server
can simply return the servlet without having to recompile each time.


Compared to servlets, which are pure Java code, JavaServer Pages are merely text
-
based
documents until the web server compiles them into the corresponding servlets


this allows a
clearer separation of application logic from presentation logic; this allows application
developers to concentrate on business matters and web designers to
concentrate on
presentation.






Enterprise JavaBean Components


The EJB architecture is a distributed component model for developing secure, scalable,
transactional, and multi
-
user components. Simply put, they are reusable software units
containing busin
ess logic. Just as JSPs allow the separation of application and presentation

Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

logic, EJBs allow separation of application logic from system
-
level services thus allowing
the developer to concentrate on the business domain issues and not system programming.

These enterprise bean business objects take two basic forms: session beans and entity beans




Session Beans


A
stateful session bean
is a transient object used to represent a client’s interaction with
the system


it performs the client’s requests in the a
pplication, acccessing a database,
etc. and when the client’s operations are complete, it is destroyed; for example, an online
shopping cart. A
stateless session bean
maintains no state between client requests.
Generally, this type of session bean is use
d to implement a specific service that does not
require client state, for instance, a simple database update




Entity Beans


An entity bean is a persistent object that models the data held within the data store, that
is, it is an object wrapper for the data
. Compared to session beans that can be used by
any client, entity beans can be accessed concurrently by many clients but must maintain a
unique identity through a primary key. Under the J2EE container architecture you can
elect whether to have the persi
stent state of the entity bean managed for you by the
container or whether to implement this yourself in the bean itself


2. Service Technologies




JDBC



JNDI



Java Transaction API and Service (JTA)


The JTA is a Java Enterprise API for managing distributed

transactions. Distributed
transactions are one of the things that make distributed systems more complicated than
nondistributed programs. First, a look at a simple, nondistributed transaction:


A
transaction
is a group of several operations that must be
have atomically


as if they
constituted a single, indivisible operation. Consider a banking application that allows a user
to transfer money from a checking account to a savings account. If the two account balances
are stored in a database, the applicat
ion must perform two database updates to handle a
transfer: it must subtract money from the checking account and add money to the savings
account. These two operations must behave atomically. For example, what happens if the
database server crashed afte
r money had been subtracted from the checking account but
before it had been added to the savings account!


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE


To make multiple operations atomic, we use transactions. In our banking example, we first
begin a transaction, then perform the two database update
s. While these updates are in
progress, no other threads can see the updated account balances. If both updates complete
successfully, we end the transaction by
committing
it. On the other hand, if either of the
database updates fails, we
roll back
the t
ransaction, reverting the accounts to their original
balances. The JDBC API supports transactions on databases. The database server is required
to do some complex work to support transactions, but for the application programmer, the
API is easy; simply b
egin a transaction, perform the desired operations, and then either
commit or rollback the transaction.


Distributed transactions are quite a bit more complex than the simple transactions just
described. Image a program that transfers money from an accoun
t stored in one database to
another stored in a different database running on a different server. In this case, there are two
different servers involved in the transaction, so the process of committing or rolling back the
transaction must be externally co
ordinated. Distributed transactions are performed using a
complex procedure known as the
two
-
phase commit protocol
. In practice, distributed
transactions are coordinated by a specialized, distributed transaction service.


This brings us to the JTA. It d
efines a Java binding for the standard XA API for distributed
transactions (XA is a standard defined by the Open Group). Using the JTA, we can write a
program that communicates with a distributed transaction service and uses that service to
coordinate a d
istributed transaction that involves a transfer of money between database
records in two different databases. JTA tends to be complex and error prone right now, and
so JTA is not used much.


3. Communication Technologies


The final technology grouping is

those technologies that provide the means for the various
components and services within a J2EE application to communicate with each other


a
distributed application would be pretty inefficient if these technologies didn’t provide the “glue”
to hold it a
ll together


Internet Protocols




HTTP (Hypertext Transfer Protocol)

is a generic, stateless, application
-
level protocol. It
works on a request/response basis


a client sends a request to the server in the form of a
request method, URI (Uniform Resource
Identifier) and protocol version, followed by a
MIME
-
like message containing request modifiers, client information, and possible body
content over a connection with the server. The server in turn responds with a status line

Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

followed by a MIME
-
like message
containing server information, entity meta
-
information,
and possible entity
-
body content




TCP (Transmission Control Protocol) over IP (Internet Protocol)
are actually two
separate protocols but are typically combined into a single entity. IP is the protoc
ol that
takes care of making sure that data is received by both endpoints in communication over the
Internet. TCP is the protocol that keeps track of all of these packets and makes sure they are
assembled in the same order they were dispatched, and are er
ror free.




Secure Socket Layer (SSL)
uses cryptography to encrypt the flow of information between
the client and server. This also provides a means for both parties to authenticate each other.
Secure HTTP (HTTPS) is usually distinguished from regular encr
ypted HTTP by being
served on a different port number, 443, by default



Remote Object Protocols




RMI
allows you to use interfaces to define remote objects. You can then call methods on
these remote objects as if they were local




RMI
-
IIOP
is an extension
of RMI but over IIOP (Inter
-
Orb Protocol), which allows you to
define a remote interface to any remote object that can be implemented in any language that
supports OMG mapping and ORB.




JavaIDL


The interfaces to remote CORBA objects are described in a p
latform
-

and language
-
independent way with the Interface Description Language (IDL). Sun provides an IDL
compiler than translates an IDL description of a remote interface into the Java stub classes
needed for implementing the IDL interface in Java of for
connecting to a remove
implementation of the interface from your Java code

Through the use of JavaIDL, a Java client can invoke method calls on CORBA objects.
These CORBA objects need not be written in Java but merely implement an IDL
-
defined
interface.




JMS




JavaMail



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



XML
Although the XML parsing APIs such as JAXP are not currently included by the J2EE
specification, future versions will include them. XML is widely used internally in J2EE, and
is becoming a key technology in today’s enterprises.


XML(
Extensible Markup Language) influences how we view, process, transport and
manage data. The data description mechanisms in XML mean it is a great way to share
information because:




It is open, XML can be used to exchange data with other users andprograms
in a platform
independent manner



It is self
-
describing; this makes it an effective choice for business
-
to
-
business and
extranet solutions



You can share data between programs without prior coordination



XML plays a significant role in the construction of J
2EE applications:




The J2EE architecture provides the means for a container to provide services at runtime
through a declarative mechanism defined in a deployment descriptor. This deployment
descriptor file is an XML document



XML can be used to integrate
you J2EE application with legacy systems



You can return XML instead of HTML to display application data to the client



XML is more than just a description mechanism:




Transforming XML;
transformations allow a programmer to map an XML document in
one form
into another form based on a set of rules. XML transformations are used to
translate between similar XML vocabularies as well as translating XML documents into
other text
-
based file formats like comma
-
delimited values



XML and Databases;

Although XML is h
ierarchical, and databases are relational, XML
can still provide a mechanism of integrating existing data into new systems



Server
-
to
-
Server Communications
; XML can provide a layer of abstraction in order to
integrate dissimilar systems


XML can be obtaine
d from one server, manipulated, and
then passed to another server in a way it understands the request


Developing J2EE Applications


The J2EE specification specifies the following steps in the application development and
deployment process:


Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE




Application co
mponent development

In this step you model the business rules in the form of application components




Composition of application components into modules

In this step, the application components are packaged into modules. This phase also involves
providing d
eployment descriptors for each module




Composition of modules into applications

This step integrates multiple modules into J2EE applications. This requires assembling one
or more modules into a J2EE application, and supplying it with the descriptor files




Application deployment

In the final step, the packaged application is actually deployed and installed on the J2EE
platform application server( s ).




J2EE Application Development and Deployment Roles


Let’s look at who should do what:




J2EE Product Provi
der

provides the base J2EE platform upon which you develop your
applications




Application Component Provider
is essentially the application developer who creates the
application functionality, although it is possible to subdivide into web developer, EJB
d
eveloper, etc.




Application Assembler
is responsible for taking the application components and packages
them together through a series of modules and descriptor files so they can be deployed to the
production servers




Deployer
is the person who installs th
e packaged application, and configures it for the
particular operating environment on which the application will be running




System Administrator
is responsible for maintaining and administering the application once
it has been deployed



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



Tool Provider

prov
ides toos that are of use in the devlopment and deployment of application
components.

Application Component Development


In J2EE, the development process starts with designing and developing application components.


Composition of Application Components In
to Modules



A module is used to package one or more related application components of the same type.
Apart from the application components, each module also includes a deployment descriptor
describing the structure of the module. There are three types o
f modules in J2EE:




Web module
is a deployable unit consisting of Java Servlets, JSP Pages, JSP tag libraries,
library JAR files, HTML/XML douments, and other public resources such as images, applet
class files, etc. A web module is packaged into a
Web Ar
chive file,
also called a
WAR file
.
A WAR file is similar to a JAR file except that a WAR file contains a WEB
-
INF directory
with a deployment description contained in a web.xml file




EJB module
is a deployable unit consisting of EJBs, and associated libr
ary JAR files, and
resources, etc. EJB modules are packaged into JAR files, with a deployment descriptor(
ejb
-
jar.xml

) in the META
-
INF directory of the JAR file




Java module
is a group of Java client classes packaged into JAR files. The deployment
descr
iptor for a Java module is an
application
-
client.xml

file



Composition of Modules Into Applications



The highest level of packaging is in the form of applications. A J2EE application consists of one
or more modules composed into an
Enterprise Archive (E
AR) file.
An EAR file is similar to a
JAR file, except that it contains an
application.xml
file (located in the META
-
INF directory)
describing the application.


The purpose of multiple descriptor files is that fine
-
grained application components can be
cu
stomized while integrating them into modules. We also need a means of specifying which
modules make up the application, which is where the application.xml file comes in.



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE

The advantage of this structure is that it allows reuse at different levels. Applic
ation components
can be reused across multiple web modules. For example, web components related to user login
can be packaged to different web modules responsible for online order, customer service, etc.








Figure page 31

















Application

Deployment


Finally, application deployment is the process of installing and customizing packaged modules
onto a J2EE platform. This process involves two steps:




To prepare the application for installing on to a J2EE application server. This involves
co
pying the EAR files onto the application server, generating additional implementation
classes with the help of the container, and finally installing the application onto the server



Enterprise Java

Lesson x


Lesson Title


COPYRIGHT ©2002. WILLIS COLLEGE



To configure the application with application server specific information.

An example is
creating data sources and connection factories, as the actual creating of these object is
application server specific