Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

6.1 OC4J Components

OC4J consists of three components:

A servlet container

An EJB container

A
JSP translator

The servlet and EJB containers have access to a standard set of
services provided by the J2EE architecture that are managed by the
server.

The following sections describe these components and the
relationships among them.

6.1.1 Servlet Container

A servlet is a server-side Java program that
extends the functionality of the application server in which it
resides. A servlet
container
is the server-managed environment
for executing a Java servlet.

J2EE defines both a generic servlet and an extension called an
HTTP servlet. An HTTP servlet has all the
generic servlet capabilities plus functionality specific to dealing
with the HTTP protocol. HTTP servlets are the most common type of
servlet used in a servlet container because HTTP is the most common
application-level protocol used on the Internet today. When someone
requests dynamic content from a Java application server such as OC4J
using HTTP, the request is most likely serviced by an HTTP servlet.

A servlet container manages the
life cycle of a servlet as follows:

It loads any necessary class files from the host file system.

After class files have been loaded, it initializes the servlet. At
any subsequent time that a request requiring the servlet is received,
the already loaded and initialized servlet is executed.

When the application server shuts down, the servlet instance is
destroyed, and the memory it used is garbage-collected.

A servlet is very performant because the same loaded and initialized
servlet, already in memory, is used for each request.

A servlet container also provides a set of standard services to a
servlet. A common example is access to data sources, which provide
servlets with access to databases. Services are discussed in more
depth later in this chapter.

The Hypertext Markup
Language (HTML) produced
by servlets to provide content for a web browser is sent to the browser by
calling an HTTP servlet method that streams output back to the
browser. This mechanism implies that a programmer writes Java code to
produce web content. Creating web content in this Java-centric
fashion may be well suited to programmers, but not web designers. To
enable web designers to create dynamic content, an alternate method
of designing servlets was created that is HTML-, not Java-centric.
This alternative is called JavaServer Pages, described in the next
section.

6.1.2 JavaServer Pages Translator

A
JavaServer Pages translator parses a
JSP file, typically composed of HTML and Java code snippets and/or
tags, and creates a corresponding
servlet. This servlet is then executed
in the servlet container like any other servlet. The difference here
is that the source code in a JSP file consists of
HTML with embedded
Java code instead of Java
code with embedded HTML.

JSP also offers a means of using other markup languages such as
Wireless Markup Language (WML) for mobile devices or, better yet,
XML. If XML is used, an XML technology called the eXtensible
Stylesheet Language for Transformations (XSLT) translates the markup
into a suitable format for the device on which it's
used: HTML for a web browser or WML for a wireless device. See Chapter 10 for a discussion of XML and Chapter 14 for information about OracleAS Wireless.

6.1.3 Enterprise JavaBeans Container

An EJB container is a server-managed
environment for executing EJBs. An EJB is a Java program that can be
executed as a component in a distributed fashion. A client program, a
servlet, or another EJB can remotely execute the methods in an EJB.
An EJB can also be executed locally if it exists in the same
application server as the calling servlet or EJB. The EJB container
provides transaction, security, and persistence management, as well
as access to other server services such as Data Sources.

In the J2EE architecture, an EJB can isolate business logic,
represent a persistent entity, or process asynchronous information
feeds. Appropriately, there are three types of
EJBs:


session, entity, and message-driven.

Session bean

A session bean, or EJB, is used for business logic. A session bean can be
stateful, or stateless. A stateful
EJB
remembers its internal values between invocations, while a
stateless EJB doesn't. A stateful EJB is
typically used to model complex business processes that require
several steps to complete, whereas a stateless EJB is used for
simple, one-method invocation processes and computations.

Entity bean

An entity bean, or EJB, is used to model a
business entity. It typically
retrieves its internal values from, and saves its values to, a
relational database. Behavior that is intrinsic to the entity is
modeled using its own methods. (For some, which methods belong in the
entity bean and which belong in a session bean that uses the entity
bean can be a source of confusion.) An entity bean can use container-
or bean-managed persistence. With container-managed
persistence
(CMP), the EJB container is
responsible for creating and executing
SQL to retrieve and save
values from and to a database. With bean-managed
persistence
(BMP), it's the
programmer's responsibility to write the required
persistence code using JDBC, Java Data Objects (JDO), or a
value-added object-relational mapping tool such as
TopLink.

Message-driven bean (MDB)

A message-driven bean, or EJB, processes a stream of asynchronous
messages from a queue. The asynchronous nature of messaging systems
allows a client to post messages to a queue without waiting for a
response. In turn, it allows a message consumer, such as an MDB, to
process messages from a queue independent of a conversation with a
client program. MDBs process messages delivered via the Java Message
Service (JMS) API. JMS provides an implementation-independent API for
accessing messaging systems. One of the strengths of MDBs is that
they can process messages concurrently, providing a scalable means of
handling asynchronous information.

Transactions can be
container- or
bean-managed:

Container-managed transactions

In such transactions, the EJB container coordinates commits or
rollbacks in a distributed fashion.

Bean (or component)-managed transactions

In such transactions, the component is responsible for its own
transaction coordination.

In a similar fashion,
security and persistence (as
mentioned earlier) can be managed by the container or by the
component. When the container is responsible for these services, the
programmer declaratively specifies the appropriate parameters in a
file called a deployment
descriptor
.

Whether exposing its configuration using a deployment descriptor, or
being self-managed, an EJB exists as an independent software
component that can conceivably be mixed and matched with other
components to build an application.

6.1.4 OC4J Component Relationships

Figure 6-1 demonstrates the relationship between
these three components and the services to which they have access:

A request is sent to the application server's Oracle
HTTP Server. The request is identified as a servlet or a JSP by its
URI and is appropriately forwarded to OC4J.

The servlet, possibly generated by translating a JSP, may access an
EJB or other OC4J container services, such as a data source, to
produce dynamic content.

The servlet, in turn, streams any generated content back through the
Oracle HTTP Server to the browser.

Figure 6-1. OC4J component relationships

OC4J provides access to the J2EE architecture's APIs
and to Oracle's own value-added APIs by what it
refers to as OC4J Services. These services are described in the next
section.