DISTRIBUTED PROGRAMMING

(DIP417B)
2021
 JAVA ENTERPRISE EDITION

 Java EE technology is the platform that provides

services for developing enterprise applications using a
multi-layer architecture
 Java EE applications are deployed into the container
which implements Java EE specifications.
 Containers resides within the application server
 The container provides lifecycle management,
security, transaction management and object pooling
 JAVA ENTERPRISE EDITION

 In practice we do not need to distinguish between the

application server and the container, we will use these
terms interchangeably
 Java EE specification is supported by commercial
vendors such as Sun, IBM,Oracle,BEA Systems as
well as open-source container such as Jboss.
 JAVA ENTERPRISE EDITION

 Enterprise applications have their responsibilities

divided into number of layers.
 A common architecture is a 3-layer model consisting
of the presentation layer, business layer and the
database layer.
 Presentation layer is responsible for presenting a user
interface and handling interactions with the system
end user.
 JAVA ENTERPRISE EDITION

 Business layer is responsible for executing business

logic.
 Database layer is responsible for storing of business
data into the database.
 JAVA EE PRESENTATION LAYER

 Java EE presentation layer technologies includes the

following:
 Servlets
 JSP Pages
 JSF Components
 These are developed for business applications and
deployed into the web container
 A client would interact with the web container either
from the browser or an applet
 JAVA EE BUSINESS LAYER

 Java EE provides EJB3 technology for business

payer.
 In Java EE 5 the business layer was subdivided into 2-
layers which are business processing layer and the
persistence layer.
 In EJB3 the business processing artifacts are session
and message-driven beans
 JAVA EE BUSINESS LAYER

 Session and message-driven beans are developed for

business application and deployed and run in a
container
 The persistence layer artifact is an entity which gets
persisted into the database layer using persistence
provider or persistence engine
 The persistence provider implements JPA
specifications
 JAVA EE BUSINESS LAYER
 Some of the persistence providers are as follows:
 Hibernate : Most advanced and widely used.Supports JPA
2.1
 Toplink : Oracle’s free version of the JPA implementation
 EclipseLink : Based on Toplink. Supports JPA 2.1
 Apache OpenJPA : Open source implementation for JPA.
Supports JPA 2.0
 DataNucleus : Open source (Apache 2 license). Supports
JPA 2.1
 CMobileCom JPA : light-weight JPA 2.1 implementation for
both Java and Android
JAVA EE ARCHITECTURE
 JAVA EE ARCHITECTURE

 In the Java EE architecture diagram depicted above,

the commonly known 3-layer model has become 5-
layers.
 The distinction between client/web and business
logic/persistence layers is not always made
 Java EE architecture is simply referred to as n-layer or
multi-layer
 JAVA EE CONTAINER OFFEIRING

 Java EE containers offer many other services such as

:
 Web services
 Java Messaging Services (JMS)
 Resource adapters
 EJB3 ARCHITECTURE

 The EJB3 architecture offers a standard for developing

distributed, object-oriented, component-based
business applications
 The components developed in an EJB framework are
session and message-driven beans.
 A session bean must have an business interface,
which can be either remote or local
 If session bean and its client resides in the same JVM
instance, a local business interface will be used to
access the session bean.
 EJB3 ARCHITECTURE

 If session bean does not reside in the same JVM

instance as the client application, a remote business
interface will be used to access it.
 EJB3 ARCHITECTURE

 A remote client invokes the remote interface of a

session bean as shown in the diagram below
 EJB3 ARCHITECTURE

 The following diagram shows a web container client

invoking the session beans local interface
 EJB3 ARCHITECTURE

 A message-driven bean is an asynchronous recipient

of a JMS message.
 The client, which can be a Java application or Java EE
component such as a session bean, sends a JMS
message to the message queue or topic.
 The message queue or topic may be managed by a
Java EE container or alternatively by a dedicated JMS
server
 EJB3 ARCHITECTURE

 The following diagram shows a client sending a JMS

message which is received by a message-driven
bean:
 EJB CONTAINER OTHER SERVICES

 EJB containers support concurrency and all EJB

components are thread-safe
 EJB containers provide pooling for EJB component
instances
 Pooling contribute to the scalability of the EJB
architecture
 EJB containers also provides load balancing and
clustering which contribute to scalability
 EJB CONTAINER OTHER SERVICES

 EJB containers provide a naming service, the Java

Naming and Directory Interface (JNDI) for accessing
EJBs or any other container-managed resource such
as JMS queue or data source connections
 In EJB3 a simpler annotation-based dependency
injection facility is available which in many cases
provides an alternative to JNDI lookup.
 EJB CONTAINER OTHER SERVICES

 All EJB containers support Java RMI-IIOP(Remote

Method Invocation run over Internet Inter-Orb
Protocol), which enables a session to be remotely
accessed by a client.
 EJB Containers provide container-managed
transaction service
 EJB containers provides a basic scheduling capability:
Timer service
 EJB CONTAINER OTHER SERVICES

 EJB containers provides Interceptors to allow common

aspects of EJB components to be separated from any
business logic
 EJB allows developers to convert a stateless session
bean into a web service
 EJB provides standards for both authentication and
authorization aspects of security.
 EJB3 provides JPA persistence engine
 SESSIONS BEANS

 Session Beans are an EJB technology for

encapsulating business processes or workflow. Three
types of session beans are:
 Stateless session beans
 Stateful session beans
 Singleton session beans
 STATELESS SESSIONS BEANS

 Stateless session bean does not maintain a

conversational state with the client. It is used to
perform independent operations.
 A stateless session bean’s state spans a single
method call
 Steps for creating Stateless session beans:
 Create a remote/local interface exposing the business
methods
 This interface will be used by the EJB client application
 STATELESS SESSIONS BEANS

 Steps for creating Stateless session beans:

 Use @Local annotation, if EJB client is in the same
environment from where the session bean is to be
deployed
 Use @Remote annotation, if EJB client is in different
environment from where EJB session bean is to be
deployed
 Create a stateless session bean, implementing the above
interface
 Use @Stateless annotation to signify it is a stateless
session bean.
 STATELESS SESSIONS BEANS

Remote Interface example :

 STATELESS SESSIONS BEANS
Sateless session bean implementation example :
 STATELESS BEANS

 Any kind of dependency injection, apart from two

exceptions, is signaled with the @Resource
annotation.
 The two exceptions are @EJB,which is used for
injecting EJB references and @PersistenceContext,
which is used for injecting Entity Manager instances
STATELESS SESSION BEAN EXAMPLE
STATELESS SESSION BEAN’S LIFECYCLE
 STATELESS SESSION BEAN’S LIFECYCLE

 The initial state of a stateless bean is the does-not-

exist state : This would be the case before a container
starts up, for example
 The next state is the method-ready pool : When the
container starts up, it typically creates a number of
stateless session bean instances in the method-ready
pool
 STATELESS SESSION BEAN’S LIFECYCLE

 To create an instance in the method-ready pool, the

container performs the following steps:
 The bean is instantiated
 The container injects the bean’s SessionContext, if
applicable
 Container performs any other dependency injection
that is specified in the bean metadata.
 STATELESS SESSION BEAN’S LIFECYCLE

 To create an instance in the method-ready pool, the

container performs the following steps:
 The container invokes a PostContruct callback
method if one is present in the bean
 A PostConstruct method is called only once in the
life of an instance
 If the container decides to destroy the instance it
first invokes the PreDestroy callback method if one
is present in the bean
 STATELESS SESSION BEAN’S LIFECYCLE

 PreDestroy callback method would be used for tidying

up activities, such as closing connections that may
have been opened in the PostConstruct
 PreDestroy method is called once in the life of an
instance, when it is about to transition to the does-not-
exist state
 STATEFUL SESSION BEANS

 Stateful session bean maintain state for an individual

client over one or more method requests.
 Stateful session bean is not shared among clients, and
a client’s reference to a bean only ends when client
ends the session or the session times out.
 The state is not persisted into the database but held in
the containers cache and is lost when container
crashes
 STATEFUL SESSION BEANS

 The state is not persisted into the database but held in

the containers cache and is lost when container
crashes
 The example of a stateful session bean is the online
shopping cart. The user adds one or more items to
shopping cart, possibly over a long time period while
the user visits other web sites or is interrupted by a
phone call.
 See examples in the next slides
 STATEFUL SESSION BEANS

 Steps for creating stateful session bean:

 Create remote/local interface exposing the business
methods
 This interface will be used by the EJB client application
 Use @Local annotation if EJB client is in the same
environment as the session bean you intend to call
 Use @Local annotation if EJB client is not in the same
environment as the session bean you intend to call
 Create a stateful session bean, implementing the above
interface
 STATEFUL SESSION BEANS

 Steps for creating stateful session bean:

 Use @Stateful annotation to signify it a stateful bean. EJB
Container automatically creates the relevant configurations
or interfaces required by reading this annotation during
deployment.
 STATEFUL SESSION BEAN

Local Interface example:

 STATEFUL SESSION BEAN
Stateful session bean example:
STATEFUL SESSION BEAN
STATEFUL SESSION BEAN
 STATEFUL SESSION BEAN

 @Remove annotation is being used to indicate that

after the method has executed, the client no longer
needs the session.
 @Stateful annotation is being used to indicate this is a
stateful session bean.
STATEFUL SESSION BEAN
STATEFUL SESSION BEAN’S LIFECYCLE
 STATEFUL SESSION BEAN’S LIFECYCLE

 Stateful session bean transitions from a does-not-exist

to a method-ready state as soon as a client performs a
business interface lookup or a dependency injection of
a bean.
 Once a stateful session bean is in a method-ready
state, the container performs the same steps as with a
method-ready stateless session bean:
 STATEFUL SESSION BEAN’S LIFECYCLE

 The container performs the following steps:

 The bean is instantiated
 The container injects the bean’s SessionContext, if
applicable
 The container performs any other dependency
injection specified in the bean’s metadata
 The container invokes PostConstruct callback
method if one is present in the bean
 STATEFUL SESSION BEAN’S LIFECYCLE

 The bean can move from a method-ready state to a

does-not-exist state if @Remove annotated method is
invoked
 The bean can also move from method-ready to a
does-not-exist state if the container configured timeout
period has lapsed.
 In both cases a @PreDestroy annotated method is
invoked
 SINGLETON SESSION BEAN’S LIFECYCLE

 A singleton session bean maintains the state of the

bean for the complete lifecycle of the application.
 It is similar to stateless session beans but only one
instance of the singleton session bean is created in
the whole application.
 It does not terminates until the application shut down.
 The single instance of the bean is shared between
multiple clients and can be concurrently accessed.
 SINGLETON SESSION BEAN’S LIFECYCLE
Singleton session bean example:

@Singleton is used to mark a bean as singleton

session bean.
@Startup annotation informs the EJB container to
initialize the bean at the startup.
 SINGLETON SESSION BEAN’S LIFECYCLE

 Initialization of the singleton session bean at the

startup is called eager initialization.
 If @Startup is not used on the singleton session bean,
the EJB container determines when to initialize it.
 Multiple singleton session beans can be used to
initialize data and load beans in the specific order. To
achieve this we use @DependsOn annotation to
define our bean’s dependency on other session
beans.
 SINGLETON SESSION BEAN’S LIFECYCLE

@DependsOn usage on singleton session bean

 REFERENCES
 https://www.javatpoint.com/ejb-interview-questions
 https://www.tutorialspoint.com/ejb/index.htm
 https://www.baeldung.com/java-ee-singleton-session-bean
 https://docs.oracle.com/javaee/7/tutorial/
 EJB 3 Developer Guide by Michael Sikora