Unit V

ENTERPRISE APPLICATIONS

5.1 Server-side component architecture

Enterprise JavaBeans (EJB) is a specification for developing large-scale, distributed business

applications on the Java platform. EJB 1.0 was released in 1998. EJB architecture
The EJB architecture consists of three main components: enterprise beans (EJBs), the EJB
container, and the Java application server. EJBs run inside an EJB container, and the EJB
container runs inside a Java application server.

Server side components need to run in a highly available (24/7), fault-tolerent transactional,
and multiuser secure environment. The application server provides this high-end server side
environment for the enterprise beans, and it provides the runtime containment necessary to
mange enterprise bean.

EJB Components as follows

Perform business logic. Example include computing the taxs on the shopping cart, ensuring that
the manger has authority to approve the purchase order, or sending an order confirmation
email using the java mail AP.

Access database : Example include submitting an order for books, transferring money between
two banks etc.

EJB Architecture
• EJB server:The server contains the EJB container
• An EJB client does not communicate directly with an EJB component Remote interface
• Define the business methods that can be called by client Home interface
• Method to create and destroy the proxies for the remote interface EJB container :the EJB
specification defines a container as the environment in which one or more component execute
it.
The EJB enumeration aims to provide a standard way to implement the server-side business
software typically found in enterprise applications. Such machine code addresses the same
types of problems, and solutions to these problems are often repeatedly re-implemented by
programmers. Enterprise Java Beans is assumed to manage such common concerns as
endurance, transactional probity and security in a standard way that leaves programmers free
to focus on the particular parts of the enterprise software at hand.
To run EJB application we need an application server (EJB Container) such as Jboss, Glassfish,
Weblogic, Websphere etc. It performs:
1. Life cycle management - Bean life cycle is managed by the spring container. When we run
the program then, first of all, the spring container gets started. After that, the container creates
the instance of a bean as per the request, and then dependencies are injected. And finally, the
bean is destroyed when the spring container is closed
2. Security - Authentication − This is the process ensuring that user accessing the system or
application is verified to be authentic.
Authorization − This is the process ensuring that authentic user has right level of authority to
access system resources.

3. Transaction management - EJBs support two types of transaction management: container

managed and bean managed. Container managed transactions provide a transactional context
for calls to bean methods, and are defined using Java annotations or the deployment descriptor
file ejb-jar. xml.
4. Object pooling - An object pool helps an application avoid creating new Java objects
repeatedly. Most objects can be created once, used and then reused. An object pool supports
the pooling of objects waiting to be reused.

5.2 Introduction to J2EE

J2EE is the standard platform for developing applications in the enterprise and is designed for
enterprise applications that run on servers. J2EE provides APIs application programming
interfaces that let developers create workflows and make use of resources such as databases or
web services. The Java EE provides a platform for developers with enterprise features such as
distributed computing and web services

Features of Java EE Enhancements include:

 Java Servlet 4.0 API with HTTP/2 support.

 Enhanced JSON support including a new JSON binding API.
 A new REST Reactive Client API.
 Asynchronous CDI Events.
 A new portable Security API.
 Server-Sent Events support (Client & Server-side)
J2EE architecture

J2EE architecture supports component-based development of multi-tier enterprise

applications. A J2EE application system typically includes the following tiers:

Client tier
In the client tier, Web components, such as Servlets and JavaServer Pages (JSPs), or
standalone Java applications provide a dynamic interface to the middle tier.
Middle tier
In the server tier, or middle tier, enterprise beans and Web Services encapsulate
reusable, distributable business logic for the application. These server-tier
components are contained on a J2EE Application Server, which provides the platform
for these components to perform actions and store data.
Enterprise data tier
In the data tier, the enterprise's data is stored and persisted, typically in a relational
database.

J2EE applications are comprised of components, containers, and services. Components are
application-level components. Web components, such as Servlets and JSPs, provide dynamic
responses to requests from a Web page. EJB components contain server-side business logic for
enterprise applications. Web and EJB component containers host services that support Web
and EJB modules.
Additional services and APIs upon which J2EE is based include:

 Java Naming and Directory Interface (JNDI)

Provides access to distributed resources via hierarchical name lookup
 Java Transaction API (JTA)
High-level access to distributed-transaction services
 Java Transaction Service (JTS)
Integration with CORBA distributed-transaction service
 Java Messaging Service (JMS)
Distributed publish/subscribe and point-point messaging
 Java Mail API
Ability to send/receive e-mail via standard protocols
 JavaBeans Activation Framework (JAF)
Mapping of JavaBeans to MIME types and file extensions

5.3 Types of Enterprise Java Beans

Written in the Java programming language, an enterprise bean is a server-side component that
encapsulates the business logic of an application. The business logic is the code that fulfills the
purpose of the application. In an inventory control application, for example, the enterprise
beans might implement the business logic in methods called checkInventoryLevel and
orderProduct. By invoking these methods, remote clients can access the inventory services
provided by the application.

1. Session Bean: A session bean represents a single client inside the Application Server. To
access an application that is deployed on the server, the client invokes the session bean’s
methods. The session bean performs work for its client, shielding the client from complexity by
executing business tasks inside the server. As its name suggests, a session bean is similar to an
interactive session. Session bean contains business logic that can be invoked by local, remote or
webservice client. There are two types of session beans:

(i)Stateful Session bean :

Stateful session bean performs business task with the help of a state. The state of an object
consists of the values of its instance variables. In a stateful session bean, the instance variables
represent the state of a unique client-bean session. Because the client interacts (“talks”) with
its bean, this state is often called the conversational state. The state is retained for the duration
of the client-bean session. If the client removes the bean or terminates, the session ends and
the state disappears. This transient nature of the state is not a problem, however, because
when the conversation between the client and the bean ends there is no need to retain the
state.

(ii) Stateless Session bean :

A stateless session bean does not maintain a conversational state for the client. When a client
invokes the method of a stateless bean, the bean’s instance variables may contain a state, but
only for the duration of the invocation. When the method is finished, the state is no longer
retained. Because stateless session beans can support multiple clients, they can offer better
scalability for applications that require large numbers of clients.

A stateless session bean can implement a web service, but other types of enterprise beans
cannot.

When to Use Session Beans

In general, you should use a session bean if the following circumstances hold:
• At any given time, only one client has access to the bean instance.
• The state of the bean is not persistent, existing only for a short period (perhaps
a few hours).
• The bean implements a web service.

Stateful session beans are appropriate if any of the following conditions are true:

• The bean’s state represents the interaction between the bean and a specific
client.
• The bean needs to hold information about the client across method invocations.
• The bean mediates between the client and the other components of the
application, presenting a simplified view to the client.

2. Message Driven Bean: Like Session Bean, it contains the business logic but it is invoked by
passing message.

3. Entity Bean: An entity bean represents a business object in a persistent storage mechanism.
Some examples of business objects are customers, orders, and products. In the Application
Server, the persistent storage mechanism is a relational database. Typically, each entity bean
has an underlying table in a relational database, and each instance of the bean corresponds to a
row in that table.
Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared
access, have primary keys, and can participate in relationships with other entity beans. It
summarizes the state that can be remained in the database. It is deprecated. Now, it is
replaced with JPA (Java Persistent API). There are two types of entity bean:

(i) Bean Managed Persistence :

Bean-managed and container managed. With bean-managed persistence, the entity

bean code that you write contains the calls that access the database. In a bean
managed persistence type of entity bean, the programmer has to write the code for
database calls. It persists across multiple sessions and multiple clients.

(ii) Container Managed Persistence :

The term container-managed persistence means that the EJB container handles all
database access required by the entity bean. The bean’s code contains no database
access (SQL) calls. As a result, the bean’s code is not tied to a specific persistent
storage mechanism (database). Because of this flexibility, even if you redeploy the
same entity bean on different J2EE servers that use different databases, you won’t
need to modify or recompile the bean’s code.

5.5 transaction
To emulate a business transaction, a program may need to perform several steps.
A transaction can end in two ways: with a commit or with a rollback. When a transaction
commits, the data modifications made by its statements are saved. If a statement within a
transaction fails, the transaction rolls back, undoing the effects of all statements in the
transaction. In the pseudocode, for example, if a disk drive were to crash during the credit step,
the transaction would roll back and undo the data modifications made by the debit statement.
Although the transaction fails, data integrity would be intact because the accounts still balance.

A transaction is a single unit of work items, which follows the ACID properties. ACID stands for
Atomic, Consistent, Isolated, and Durable.

 Atomic − If any of the work item fails, the whole unit will be considered failed. Success
meant, all items execute successfully.
 Consistent − A transaction must keep the system in consistent state.
 Isolated − Each transaction executes independent of any other transaction.
 Durable − Transaction should survive system failure if it has been executed or
committed.
Container-Managed Transactions

In an enterprise bean with container-managed transaction demarcation, the EJB container sets
the boundaries of the transactions.

Enterprise beans that use container-managed transaction demarcation must not use any
transaction-management methods that interfere with the container’s transaction demarcation
boundaries. Examples of such methods are the commit, setAutoCommit, and rollback methods
of java.sql.Connection or the commit and rollback methods of javax.jms.Session

Container Managed Transactions

EJB 3.0 has specified following attributes of transactions, which EJB containers implement −

 REQUIRED − Indicates that business method has to be executed within transaction,

otherwise a new transaction will be started for that method.
 REQUIRES_NEW − Indicates that a new transaction, is to be started for the business
method.
 SUPPORTS − Indicates that business method will execute as part of transaction.
 NOT_SUPPORTED − Indicates that business method should not be executed as part of
transaction.
 MANDATORY − Indicates that business method will execute as part of transaction,
otherwise exception will be thrown.
 NEVER − Indicates if business method executes as part of transaction, then an exception
will be thrown.