What is EJB architecture(components)?

Enterprise beans
An enterprise bean is a non-visual component of a distributed, transaction-oriented
enterprise application. Enterprise beans are typically deployed in EJB containers and run
on EJB servers.

There are three types of enterprise beans: session beans, entity beans, and message-driven
beans.

Session beans: Session beans are non-persistent enterprise beans. They can be stateful or
stateless. A stateful session bean acts on behalf of a single client and maintains client-
specific session information (called conversational state) across multiple method calls
and transactions. It exists for the duration of a single client/server session. A stateless
session bean, by comparison, does not maintain any conversational state. Stateless
session beans are pooled by their container to handle multiple requests from multiple
clients.

Entity beans: Entity beans are enterprise beans that contain persistent data and that can
be saved in various persistent data stores. Each entity bean carries its own identity. Entity
beans that manage their own persistence are called bean-managed persistence (BMP)
entity beans. Entity beans that delegate their persistence to their EJB container are called
container-managed persistence (CMP) entity beans.

Message-driven beans: Message-driven beans are enterprise beans that receive and
process JMS messages. Unlike session or entity beans, message-driven beans have no
interfaces. They can be accessed only through messaging and they do not maintain any
conversational state. Message-driven beans allow asynchronous communication between
the queue and the listener, and provide separation between message processing and
business logic.

Remote client view

The remote client view specification is only available in EJB 2.0. The remote client view
of an enterprise bean is location independent. A client running in the same JVM as a bean
instance uses the same API to access the bean as a client running in a different JVM on
the same or different machine.
Remote interface: The remote interface specifies the remote business methods that a
client can call on an enterprise bean.
Remote home interface: The remote home interface specifies the methods used by
remote clients for locating, creating, and removing instances of enterprise bean classes.

Local client view

The local client view specification is only available in EJB 2.0. Unlike the remote client
view, the local client view of a bean is location dependent. Local client view access to an
enterprise bean requires both the local cleint and the enterprise bean that provides the
local client view to be in the same JVM. The local client view therefore does not provide
the location transparency provided by the remote client view. Local interfaces and local
home interfaces provide support for lightweight access from enterprise bean that are local
clients. Session and entity beans can be tightly couple with their clients, allowing access
without the overhead typically associated with remote method calls.

Local interface: The local interface is a lightweight version of the remote interface, but
for local clients. It includes business logic methods that can be called by a local client.
Local home interface: The local home interface specifies the methods used by local
clients for locating, creating, and removing instances of enterprise bean classes.

EJB client JAR file

An EJB client JAR file is an optional JAR file that can contain all the class files that a
client program needs to use the client view of the enterprise beans that are contained in
the EJB JAR file. If you decide not to create a client JAR file for an EJB module, all of
the client interface classes will be in the EJB JAR file.

EJB container
An EJB container is a run-time environment that manages one or more enterprise beans.
The EJB container manages the life cycles of enterprise bean objects, coordinates
distributed transactions, and implements object security. Generally, each EJB container is
provided by an EJB server and contains a set of enterprise beans that run on the server.

Deployment descriptor
A deployment descriptor is an XML file packaged with the enterprise beans in an EJB
JAR file or an EAR file. It contains metadata describing the contents and structure of the
enterprise beans, and runtime transaction and security information for the EJB container.

EJB server
An EJB server is a high-level process or application that provides a run-time environment
to support the execution of server applications that use enterprise beans. An EJB server
provides a JNDI-accessible naming service, manages and coordinates the allocation of
resources to client applications, provides access to system resources, and provides a
transaction service. An EJB server could be provided by, for example, a database or
application server.

How Java Web Servers Work

by Budi Kurniawan
04/23/2003

Editor's Note: this article is adapted from Budi's self-published book on Tomcat internals. You can
find more information on his web site.

A web server is also called a Hypertext Transfer Protocol (HTTP) server because it uses HTTP to
communicate with its clients, which are usually web browsers. A Java-based web server uses two
important classes, java.net.Socket andjava.net.ServerSocket, and communicates through
HTTP messages. Therefore, this article starts by discussing of HTTP and the two classes. Afterwards,
I'll explain the simple web server application that accompanies this article.

The Hypertext Transfer Protocol (HTTP)

HTTP is the protocol that allows web servers and browsers to send and receive data over the
Internet. It is a request and response protocol--the client makes a request and the server responds
to the request. HTTP uses reliable TCP connections, by default on TCP port 80. The first version of
HTTP was HTTP/0.9, which was then overridden by HTTP/1.0. The current version is HTTP/1.1,
which is defined by RFC 2616(.pdf).

This section covers HTTP 1.1 briefly; enough to make you understand the messages sent by the
web server application. If you are interested in more details, read RFC 2616.

In HTTP, the client always initiates a transaction by establishing a connection and sending an HTTP
request. The server is in no position to contact a client or to make a callback connection to the
client. Either the client or the server can prematurely terminate a connection. For example, when
using a web browser, you can click the Stop button on your browser to stop the download process
of a file, effectively closing the HTTP connection with the web server.

HTTP Requests

An HTTP request consists of three components:

• Method-URI-Protocol/Version
• Request headers
• Entity body

An example HTTP request is:

POST /servlet/default.jsp HTTP/1.1

Accept: text/plain; text/html
Accept-Language: en-gb
Connection: Keep-Alive
Host: localhost
Referer: http://localhost/ch8/SendDetails.htm
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Content-Length: 33
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate

LastName=Franks&FirstName=Michael

The method-URI-Protocol/Version appears as the first line of the request.

POST /servlet/default.jsp HTTP/1.1

where POST is the request method, /servlet/default.jsp represents the

URI andHTTP/1.1 the Protocol/Version section.

Each HTTP request can use one of the many request methods, as specified in the HTTP standards.
The HTTP 1.1 supports seven types of request: GET, POST, HEAD, OPTIONS,PUT, DELETE,
and TRACE. GET and POST are the most commonly used in Internet applications.
The URI specifies an Internet resource completely. A URI is usually interpreted as being relative to
the server's root directory. Thus, it should always begin with a forward slash (/). A URL is actually a
type of URI. The protocol version represents the version of the HTTP protocol being used.

The request header contains useful information about the client environment and the entity body of
the request. For example, it could contain the language for which the browser is set, the length of
the entity body, and so on. Each header is separated by a carriage return/linefeed (CRLF) sequence.

A very important blank line (CRLF sequence) comes between the headers and the entity body. This
line marks the beginning of the entity body. Some Internet programming books consider this CRLF
the fourth component of an HTTP request.

In the previous HTTP request, the entity body is simply the following line: