Technologies the constitutes J2EE

tukwilagleefulInternet and Web Development

Oct 31, 2013 (3 years and 9 months ago)

102 views

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



Presenta
tion 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 segregat
ed 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.


Clie
nt 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:


Co
ntainer 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.



Applica
tion 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 e
nabled 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

Messa
ge
-
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 s
torage. 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 respons
ible 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 automatical
ly
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 previ
ous 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
e
ncapsulates 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 hand
le 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 a
pplication 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
Be
ans?


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 sess
ion 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.


* Al
l 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 messag
e
-
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 objec
t 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
-
driv
en 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 be
ans 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.rosei
ndia.net/jboss/index.shtml



Read J2EE Patterns at
http://java.sun.com/blueprints/corej2eepatterns/index.ht ml