Learning J2EE
Introduction on Java based Enterprises Systems (Building Legacy/Enterprises
Systems).
Logical layers of software
1) Presentation manager
2) Presentation logic
3) Application logic
4) Business logic
5) Database logic and
6) Database manager
An autonomous process isolated due to its importance and intensive operation known
as tire.
1 tire
All 6 layers in single software
2 tire
6 Layers separated as client and server (divided into autonomous processes)
Below are the models that are available
“Presentation manager” or “Presentation manager and Presentation logic” or
“Presentation manager, Presentation logic and application logic” as client and
the other layers act as a server.
3 tire
Here we have one additional process identified that can be segregated to
improve the system. Its know as middleware and consists of “presentation logic,
application logic and business logic” or business logic alone.
Technologies the constitutes J2EE
Component (Servlets, JSP, EJB)
Service (JDBC, JMS, JTA, JavaMail, JAF, JAAS, JNDI)
Integration (JAXP, JCA, IDL)
Communication (RMI, IIOP)
15 elements constitute J2EE (Servlets, JSP, EJB, JDBC, JMS, JTA, JavaMail, JAF,
JAAS, JNDI, JAXP, JCA, IDL, RMI, IIOP)
The J2EE architecture (Different Containers)
An application client container for hosting standard Java client
applications.
An applet container for hosting Java applets.
A web container for hosting Servlets and JSP pages.
An EJB container for hosting Enterprise JavaBeans.
Normally 4 tire for J2EE Architecture.
Client tire
Web tire
Business logic tire
Enterprise information system tire
Container
A container is a runtime environment for application components
Container contains one or more application components.
The container itself is divided into four parts:
Container contract
Container services API
Declarative services
Other container services
J2EE (EJB) Application Development
Enterprise bean provider.
The role that develops EJB components.
The application assembler.
The role that combines EJB components with other softeware (e.g. web
components) in order to make a complete application.
Deployer.
The role that takes the application and install it on an application server,
resolving any references to existing resources in the target environment.
Application server /EJB container vendor.
The role that provides the application server on which the application is
deployed.
System administrator
The role that manages the application after it has been deployed in a target
environment.
Servlets are network enabled by default, but EJB are not. The EJB Containers will
serve EJB over network. All EJB’s will have home interface, remote interface and
bean class.
Servlets by themselves are http enabled.
EJB (Enterprise Java Beans)
Entity Beans
Session Beans
Message-Driven Bean (JMS)
Entity Beans
Entity Beans always have states. Each Entity Bean may however be shared by
multiple EJB Clients. Their states can be persisted and stored across multiple
invocations. Hence they can survive System Shutdowns.
EJB servers have a right to manage their working set. Passivation is the process by
which the state of a Bean is saved to persistent storage and then is swapped out.
Activation is the process by which the state of a Bean is restored by swapping it in
from persistent storage. Passivation and Activation apply to both Session and Entity
Beans.
Persistence in Entity Beans is of two types. They are:
Container-managed persistence:
Bean-managed persistence:
Container-managed persistence: Here, the EJB container is responsible for saving
the state of the Entity Bean. Since it is container-managed, the implementation is
independent of the data source. However, all container-managed fields need to be
specified in the Deployment Descriptor for the persistence to be automatically
handled by the container.
Bean-managed persistence: Here, the Entity Bean is directly responsible for
saving its own state and the container does not need to generate any database calls.
Consequently, this implementation is less adaptable than the previous one as the
persistence needs to be hard-coded into the Bean.
Every Entity Bean has the following characteristics:
Entity beans can share access from multiple users.
They can participate in transactions.
Entity beans represent data in a domain model.
They are persistent. They live as long as the data lives in the domain model.
Entity beans can survive EJB server crashes. Any EJB server crash is always
transparent to the client.
Entity beans have a persistent object reference. The object reference
encapsulates the Persistent key for this Bean.
Session Beans
There are two types of Session Beans. They are
Stateless Session Beans and
Stateful Session Beans
Stateless Session Beans:
These types of EJBs have no internal state. Since they do not have any states, they
need not be passivated. Because of the fact that they are stateless, they can be
pooled in to service multiple clients (remember MTS components?)
Stateful Session Beans:
These types of EJBs possess internal states. Hence they need to handle Activation
and Passivation. However, there can be only one Stateful Session Bean per EJB
Client. Since they can be persisted, they are also called Persistent Session Beans.
These types of EJBs can be saved and restored across client sessions. To save, a call
to the bean's getHandle() method returns a handle object. To restore, call the handle
object's getEJBObject() method.
ACID Properties - Atomicity Consistency Isolation Durability
All transactions subscribe to the following "ACID" properties:
WORA – Write once run anywhere/anytime
What Is a Message-Driven Bean?
A message-driven bean is an enterprise bean that allows J2EE applications to process
messages asynchronously (Not occurring or existing at the same time or having the
same period or phase). It acts as a JMS message listener, which is similar to an
event listener except that it receives messages instead of events. The messages may
be sent by any J2EE component--an application client, another enterprise bean, or a
Web component--or by a JMS application or system that does not use J2EE
technology.
Message-driven beans currently process only JMS messages, but in the future they
may be used to process other kinds of messages.
What Makes Message-Driven Beans Different from Session and Entity
Beans?
The most visible difference between message-driven beans and session and entity
beans is that clients do not access message-driven beans through interfaces.
Interfaces are described in the section Defining Client Access with Interfaces. Unlike
a session or entity bean, a message-driven bean has only a bean class.
In several respects, a message-driven bean resembles a stateless session bean.
* A message-driven bean's instances retain no data or conversational state for a
specific client.
* All instances of a message-driven bean are equivalent, allowing the EJB
container to assign a message to any message-driven bean instance. The container
can pool these instances to allow streams of messages to be processed concurrently.
* A single message-driven bean can process messages from multiple clients.
The instance variables of the message-driven bean instance can contain some state
across the handling of client messages--for example, a JMS API connection, an open
database connection, or an object reference to an enterprise bean object.
When a message arrives, the container calls the message-driven bean's onMessage
method to process the message. The onMessage method normally casts the message
to one of the five JMS message types and handles it in accordance with the
application's business logic. The onMessage method may call helper methods, or it
may invoke a session or entity bean to process the information in the message or to
store it in a database.
A message may be delivered to a message-driven bean within a transaction context,
so that all operations within the onMessage method are part of a single transaction.
If message processing is rolled back, the message will be redelivered.
When to Use Message-Driven Beans
Session beans and entity beans allow you to send JMS messages and to receive
them synchronously, but not asynchronously. To avoid tying up server resources,
you may prefer not to use blocking synchronous receives in a server-side
component. To receive messages asynchronously, use a message-driven bean.
Best free J2EE Application Server: Jboss (http://www.jboss.org) or Enhydra
(http://enhydra.enhydra.org)
EJB Example – Jboss Tutorial
http://www.roseindia.net/jboss/index.shtml
Read J2EE Patterns at http://java.sun.com/blueprints/corej2eepatterns/index.html