SUB CODE:IT0407 

SUB NAME:INTEGRATIVE PROGRAMMING & TECHNOLOGIES

SEM : VII 

112/26/2012

N.J.Subashini

Assistant Professor,(Sr. G)

SRM University, Kattankulathur

212/26/2012

UNIT ‐ III

312/26/2012

UNIT 3 ENTERPRISE JAVA BEANS 9Introduction to J2EE : Need for J2EE, Overview on the J2EE , Architecture, J2EE Key Standards - Introduction to EJB3 : The EJB Model, Key Services of the Application Server - Developing Session Beans: Stateless Session Beans, Stateful Session Beans, Packaging, Writing Clients- Messaging & Message Driven Beans : JMS Overview, JMS Message Driven Beans, Custom Messaging Types- Using Transactions : Distributed Transactions, Bean Managed Transactions, Container Managed Transactions. Creating Interceptors : AOP Overview, Interceptor Classes, Lifecycle Interceptors.

412/26/2012

Introduction to J2EE

512/26/2012

Java Enterprise Edition 6 (EE 6) is the latest Java platform for developing enterprise applications.

The enterprise applications connect various business units of the enterprise by using various kinds of user interfaces.

enterprise applications are software applications that help an enterprise to manage its various business activities.

Enterprise applications can be accessed by the end users or partners of an enterprise through the Internet or private networks (such as LAN or WAN).

the need to simplify and restructure the implementation of business practices let to the development of Java EE.

Java EE is an integrated software package that supports a distributed computing architecture, and provides definitions to package and deploy distributable components.

612/26/2012

Introduction to Java:Starting with java

Java refers to a combination of following four aspects:Java Programming LanguageJava Runtime Environment (JRE)Java Virtual Machine (JVM)Java Platform

The Java PlatformJava platform has evolved into three major editions, each addressing a distinct set of

programming needs. These editions are:

Java SEJava EEJava ME

712/26/2012

The Java Platform, Standard Edition (Java SE) -The Java SE Edition of Java is the most commonly used among the three. It is used for developing desktop and console-based applications. It consists of the following: 1. A runtime environment2. Set of Application Programming Interfaces (APIs) to build a wide variety of applications comprising standalone applications that can run on various platforms

The Java Platform, Enterprise Edition (Java EE) -Java EE is a platform primarily used for building server -side applications, by using its convenient component-based approach.

The Java Platform, Micro Edition (Java ME) -Java ME enables us to build Java applications for micro--devices, which include handheld devices such as mobile phones, PDAs, and other similar devices with limited display and memory support.

812/26/2012

Enterprise ArchitectureEnterprise architecture helps in understanding the structure of an enterprise

application and can be broken down into three fundamental concerns or logical layers, which are:1. The User Interface -Displays data elements to the users and collecting data from

the users. Often called the `presentation layer', it includes the part of the software that creates and controls the user interface and validates the user's actions.

2. Processing-Helps an application to work and handle processing of business logic. This logical layer is also called the business layer.

3. Data Storage and Access -Helps business applications to read and store data. This layer is also called the Data Access layer

912/26/2012

Whenever user design any enterprise application, it is important to introduce the concept of n-tier architecture.

client/server system that is based on the 2-tier architecture, where there's a clear separation between the Data and Business logic.Enterprise Architecture Types

enterprise architecture can be designed in many ways, but the common types of enterprise architectures:

Single-tier architecture2-tier architecture 3-tier architecture n-tier architecture

1012/26/2012

Single- Tier Architectureit consists of the presentation, the business rules, and the data access layers-in a

single computing layer. Figure shows the single-tier architecture:

Applications created on this architecture are relatively easy to manage and implement data consistency; since data is stored at a single location.

The only problem is that such applications cannot be scaled up to handle multiple users, and they do not provide an easy means of sharing data across an enterprise.

1112/26/2012

2- Tier ArchitectureThis architecture separates the data and business logic, it is generally data driven; with the application existing entirely on the local machine and the database deployed at a specific and secure location in the organization. This type of architecture is the traditional method of enterprise development. In a 2-tier application, the processing load is entrusted with the client, while the server simply controls the traffic between the application and data, as shown in FigureThe rational for this approach is to centralize the data to allow multiple users to simultaneously work with a common database, and to provide the ability for a central database server to share some of the load associated with the execution of application.

1212/26/2012

1312/26/2012

This architecture is usually referred to as client/server, where a client communicates with a server, as shown in Figure

1412/26/2012

3-Tier ArchitectureIn the 3-tier architecture, an application is virtually split into three separate logical

layers. Each of these layers has well defined interfaces, as shown in Figure

1512/26/2012

The layers in the 3-tier architecture are:1. First Tier - Referred to as the `presentation layer'. The first tier consists of a GUI

to interact with the user.2. Middle Tier-Known as the `business layer'. The middle tier consists of the

application or the business logic. The middle tier represents the code that the user calls upon through the presentation layer to retrieve the data from the data layer.

3. Third tier -Called the data layer. The third tier contains the data access logic needed for the application.

This separation of application logic from the user interface adds enormous flexibility, as compared to the 2-tier system, to the design of an application.

1612/26/2012

By using this architecture, multiple user interfaces can be built and deployed without changing the application logic provided it defines a clear interface to the presentation layer. Figure shows the 3-tier architecture:

1712/26/2012

The n-Tier ArchitectureAs the name suggests, there can be numerous layers in this kind of architecture.

Figure shows an example of n-tier architecture, which is the combination of 3-tier and 2-tier model

In this model, the business logic is retrieved from the application running on the desktop.

The application on the desktop is responsible for presenting the user interface to the end user and for communicating to the business logic tier. It is no longer responsible for enforcing business rules or accessing databases.

1812/26/2012

the n-tier architecture can support a number of different configurations, this can be virtually distributed into the following segments:1. The user interface can be used to interact with the database and the user. This

means, it provides an interface between the user and the database, which can be a Web browser running through a firewall, a heavy desktop application, or even a wireless device.

2. The presentation logic that defines what will be displayed on the user interface and how the users' requests would be handled.

3. The business logic models the applications' business logic or rules, often through the interaction with the application data.

1912/26/2012

4. Infrastructure services provide additional functionality required by the application components, such as messaging and transactional support.

5. The data layer is one that stores the data of the enterprises.

2012/26/2012

Advantages of n-tier architecture are as follows:Improved maintainability Interoperability FlexibilityScalability

Java EE 6 architecture is based on the n-tier architecture, which makes it very easy to build enterprise applications based on two, three, or more application layers.

Goals of Enterprise Applications• Ensure robustness • Ensure scalability and performance • Implement object-oriented design principles • Avoid complexity • Ensure maintainability and extensibility• Ensure ease of testing• Promote Reuse of applications

2112/26/2012

Introducing the Java EE Platform:Java EE 7 is the latest version of the Java platform, used to develop robust,

scalable, distributive, and secure enterprise level applications.Earlier versions of Java were termed as Java 2 Platform, Enterprise Edition (J2EE),

followed by specific versions such as J2EE 1.5. The term J2EE has been replaced by Java EE in version 5. Therefore, the new

version of this platform has been termed as Java EE 5 (formally J2EE 1.6). The previous versions of Java are still referred as J2EE 1.4 and J2EE 1.5

2212/26/2012

Java EE, which can also be defined as the extension to J2EE 1.5, is capable of meeting all requirements of enterprise services for different users of an organization, such as customers, suppliers, and employees.

For example, Java EE focuses on making development of enterprise applications easier by supporting annotations and Plain Old Java Objects (POJOs), reducing the need of Deployment Descriptors, enhancing Web services, and supporting rich technologies such as Asynchronous JavaScript and XML (AJAX).

2312/26/2012

Features of Java EE 6:Platform independenceManaged objectsReusabilityModularitySimplified EJBEnhanced Web ServicesSupport for Web 2.0

Exploring the Java EE 6 PlatformThe Java EE 6 platform is an environment that uses a distributed multi-tiered

application model for the development of enterprise applications. It comprises of the following:

Runtime infrastructureA set of Java APIs

2412/26/2012

A runtime infrastructure for managing and hosting applications. All runtime applications are located in this server.

A set of Java APIs to build applications. These Java APIs describe the programming model for Java EE applications.The Runtime Infrastructure

The runtime infrastructure component includes numerous services to manage enterprise applications.

The Java EE architecture provides the uniform means of accessing platform-level services via its runtime environment.

These services include messaging, security, and distributed transactions.The applications that we develop from the programs drive the Web pages or

components to implement the complex database transactions, or even Java applets across the network.

2512/26/2012

Java EE5 APIs

2612/26/2012

In the enterprise services, the distributed applications require server access for running.

These enterprise services include transaction processing, managing, multithreading, and database access.

The Java EE architecture unifies access to such services in its enterprise service APIs.

The application program in Java EE can access these APIs through the containers such as Web and EJB, as shown in Figure

The Java Platform, Standard Edition (Java SE) SDK provides core APIs for writing Java EE components, core development tools, and the Java Virtual Machine (JVM).

The Java SE SDK is also required to run the Java EE SDKJava EE APIs has been developed on J2SE 1.5; therefore, we can use J2SE 1.5 or

the latest one, i.e. Java SE 6, to provide a run time environment.

2712/26/2012

EJB 3.0Java Servlet TechnologyJavaServer Pages (JSP) TechnologyJava Server Pages Standard Tag Library (JSTL)Java Server Faces (JSF)Java Message Service (JMS) APIJava Transaction API (JTA)Java Mail API JavaBeans Activation Framework (JAF) Java API for XML Processing (JAXP) Java API for XML Web Services (JAX-WS) Java Architecture for XML Binding (JAXB)Java API for XML Registries (JAXR)SOAP with Attachments API for Java (SAAJ)Java EE Connector ArchitectureJDBC APIJava Persistence API (JPA)Java Naming and Directory Interface (JNDI)Java Authentication and Authorization Service (JAAS)

2812/26/2012

Architecture of Java EE The architecture of the Java EE platform uses the multi-tier distributed application

model. The application logic is divided into different application components as per the

required functionality. These components that make up a Java EE application are installed on different

machines, depending on the number of tiers of the Java EE environment.A Java EE application can be 3-tier or 4-tier, as shown in Figure, but generally they

are considered to be 3--tier as they are located over three different locations, that is,client machine, Java EE server, and Database server.

This means that the application logic is distributed over different locations-client machines, Java EE server machine, and the database or legacy machines at the backend.

2912/26/2012

Fig shows Java EE application model, this application model is both distributed and multi-tiered.

This 3-tier architecture and applications extend the standard 2-tier client/server model by placing a multithreaded Application Server between the client application and the back-end storage.

in the Figure the middle tier, which is represented by Java EE Server, has also been divided into two tiers -Web tier and Business tier.

3012/26/2012

3112/26/2012

Describing Java EE Containers:The Java EE applications are comparatively easy to write due to the component-

based platform-independent Java EE architecture as Business logic is organized into reusable components.

The Java EE server provides various services in the form of a container for every component type.

As a matter of fact, user do not have to develop these services, they are free to concentrate on solving the business problem at hand.

Containers are a central theme in the Java EE architecture.Containers are like the rooms in the house. People and things exist in the rooms, and

interface with the infrastructure through well-defined interfaces

3212/26/2012

In an Application server, web and business components exist inside the containers and interface with the Java EE infrastructure through well-defined interfaces.

A Java EE container acts as a runtime interface between the application components and the low-level platform- specific functionality.

Java EE containers provide deployment, management, and execution support for application components.

One of the features of the Java EE platform is its support for a declarative programming style.

Many component low-level details, such as persistence, security, and multithreading issues, can be declaratively specified in a Deployment Descriptor.

3312/26/2012

Java EE containers provide an execution environment for the component fulfilling the requirements declared in the Deployment Descriptor.

Different application components are installed in respective containers during deployment; the containers act as interfaces between the components and the low-level platform-specific functionality that supports the components.

The container also manages non-configurable services such as life cycles of Servlets and EJBs, database connection Resource pooling, data persistence, and access to the Java EE platform APIs.

3412/26/2012

Container TypesDuring the deployment process, installation of Java EE application components takes

place in the Java EE containers on the Java EE server. Java EE Server is used as runtime portion for the execution of application, which

contains the EJB and Web containers. Java EE containers can be categorized as:

EJB Container-used for the execution of all enterprise beans for a Java EE application. Enterprise beans and their container run on the Java EE server.Web Container -used for the execution of all JSP pages and Servlet components for a Java EE application. Web components and their container run on the Java EE server.

3512/26/2012

Application Client Container-used for the execution of all application client components for a Java EE application. Application clients and their container run on the client machine. Applet Container-used for applet execution. It is a combination of the Web browser and Java Plug-in running together on the client machine.

You can see all the containers in the Figure 1.12.

3612/26/2012

3712/26/2012

Java EE 6 Container Architecturecontainer is an interface between component and low-level platform functionality that

supports the component. the architecture of a Java EE container is shown in Figure 1.13This architecture includes different components such as JSP, Servlets, and EJBs. An archive file is used for packaging these components. It also includes different Deployment Descriptors. The container itself is divided into four parts, which are:

1. Container Contract2. Container Service APIs3. Declarative Services4. Other Container Services

3812/26/2012

3912/26/2012

Component ContractComponent contracts are rules, stored in the form of some APIs, which the

application components must extend or implement. A Java EE container acts as a runtime environment to manage the application

components. At runtime, the instances of the application components are invoked within the JVM of

the container. The container manages the life cycle of the application components, so components

have to abide by certain contracts specified by the container. The container manages the location, instantiation, pooling, initialization, service

invocation, and removal of application components by using the component contracts.

4012/26/2012

For example, an applet is downloaded by the browser and instantiated and initialized in the JVM of the browser. That is, the applet exists in the runtime environment provided by the JVM of the browser.

Since the container has to create, initialize, and invoke the methods on application components, the application components have to implement or extend certain Java interfaces or classes.

Let's suppose a Java applet is required to extend the java.applet package.Applet class specified by the JDK. The init (), start (), stop (), and destroy () methods

control the life-cycle of the applet and are present only in the java.applet.Applet class. If the applet does not extend this class, the JVM cannot call these methods.

4112/26/2012

Container Services APIsThe container provides APIs and protocols that all application components need to

use by extending or implementing them. This is how user can use service APIs, such as JDBC, JTS, JNDI, and JMS in the

container. All these APIs specified in the Java EE platform are provided as a view by the

container. Java EE applications require the services of a Java EE container, which implements a

long list of Java EE APIs, including EJB, JTA, JNDI, JMS, JCA, and JMX.

4212/26/2012

Declarative ServicesThe Java EE architecture has the feature of providing services to application

components, which is based on declarations outside the application components. These declarations are provided by means of a Deployment Descriptor. Java EE platform services simplify the application programming and allow

components and applications to be customized at packaging and deployment time to use resources available in the deployment environment.

Deployment Descriptors contain many elements related to customizing Java EE platform services, such as transactions and security.

4312/26/2012

This approach gives the container the ability to interpose a new service before transferring a request to the application component.

The advantage of this approach is that we can interpose new services without changing the application component.

The extensive use of annotations and defaults in Java EE has reduced the number of Deployment Descriptors and the configuration provided in a Deployment Descriptors.

4412/26/2012

Other Container ServicesOther container services include component life-cycle, resource pooling, garbage

collection, clustering and so on. The following are some of the runtime services that a container provides:The container manages the complete life-cycle of application components, which includes creation and pooling or destroying of application components when they are of no use.Resource pooling is the responsibility of the container. Pooling can be implemented either by object pooling, which manages short lived objects or by connection pooling, which is a technique used for sharing server resources among the clients.The container populates the JNDI namespace based on the deployment names associated with EJB components. This information is typically supplied at deployment time.

4512/26/2012

The container populates the JNDI namespace with objects necessary for utilizing container service APIs. Some of the objects include data source objects for database access, queue and topic connection factories for obtaining connections to the JMS, and user transaction objects for programmatically controlling transactions.Clustering increases scalability and availability applications. In a distributed java EE container multiple JVM run on one or more host machines. In this setup, application component can be deployed on multiple JVMs. The container can distributed the load of incoming requests on one of these JVMs, depending on the type of load-balancing strategy and the type of component.

4612/26/2012

Difference between EJB and Java beans

4712/26/2012

Java Beans: Enterprise Java Beans:

• Java beans are reusable components that can be used for customized user objects. 

• Java beans adhere to two methods known as setter and getter methods and one public constructor. 

• For example an Employee object can be used to set (setter method) and get (getter method) employee detailswhich are a customized object. AWT and Swing components are based on java beans. 

 

• EJB are reusable components that are developed to comply with enterprise specification 

• adhering to setter and getter methods and one public constructor. 

• These beans run in an EJB container of J2EE architecture.

• An EJB is a nonvisual, remote object. • EJB's are remotely executable 

components or business objects that can be deployed only on the server. 

4812/26/2012

Java Beans: Enterprise Java Beans:

• JavaBeans may be visible or nonvisible at runtime. 

• JavaBeans are intended to be local to a single process and are primarily intended to run on the client side. Although one can develop server‐side JavaBeans, it is far easier to develop them using the EJB specification instead. 

• JavaBeans is a component technology to create generic Java components that can be composed together into applets and applications.

• Even though EJB is a component technology, it neither builds upon nor extends the original JavaBean specification. 

• EJBs have a deployment descriptor that describes its functionality to an external builder tool or IDE 

• EJB's have no concept of BeanInfoclasses, property editors or customizers and provide no additional information other than that described in the deployment descriptor. 

4912/26/2012

Java Beans: Enterprise Java Beans:

• JavaBeans have an external interface called the properties interface, which allows a builder tool to interpret the functionality of the bean. 

• JavaBeans may have BeanInfoclasses, property editors or Customizers 

• JavaBeans have no types. • No explicit support exists for 

transactions in JavaBeans.• Component bridges are available 

for JavaBeans

• EJBs are of two types ‐ session beans , message driven bean and entity beans. 

• EJB's may be transactional and the EJB servers provide transactional support.

• An EJB cannot be deployed as an ActiveX control because ActiveX controls are intended to run at the desktop and EJB's are server side components. 

• However CORBA‐IIOP compatibility via the EJB‐to‐CORBA mapping is defined by the OMG

5012/26/2012

Introduction to EJB3

5112/26/2012

An enterprise level application developed on Java Platform, Enterprise Edition (Java EE) should be distributive, transactional, secure, and portable.

To ensure that the application supports all these features, developers have to provide extra code and logic for the implementation of various low level interactions, which can distract the developers from the actual business logic implementation.

To overcome this problem, user use a user-defined component, which is used by the container to ensure security, manage transaction, implement automatic object persistence, and enhance portability.

5212/26/2012

New technology called server-side component architecture was introduced for Java EE, more commonly known as Enterprise JavaBeans (EJB).

The use of EJB component helps in easy and fast development of distributed, transactional, secure, and portable Java applications.

EJB components and EJB containers used in application servers reduce the efforts of the developers, as they do not need to understand low level transaction and state management details, connection pooling, multithreading, and other similar complex processes related to application development, which are now provided by the container.

5312/26/2012

EJB 3.0 FundamentalsIt is a component-based architecture for developing, deploying, and managing reliable enterprise applications in production environments. An enterprise bean is a server-side piece of code with fields and methods to implement the modules of the business logic.An enterprise bean can be considered as a building block that can be used alone or with other enterprise beans to execute the business logic on the Java EE server adhering to the EJB architecture. Java EE provides all infrastructure services to EJB, such as Java Database connectivity (JDBC), Java Naming Directory interface (JNDI), Java Message Service (JMS), and Java Transaction APIs JTA. EJB 3.0 has been introduced with Java EE. EJB 3.0 makes programming of EJB components simpler and better as compared to its previous version, EJB 2.1, which was supported by J2EE 1.4.

5412/26/2012

Enterprise JavaBeans is a standard architecture used for enterprise level distributed applications that are object -oriented, transaction-oriented, as well as distributed.

Implementing the Enterprise JavaBeans architecture means creating enterprise bean components that are managed by EJB container in the application server.

The enterprise bean implements the business logic, which can operate on enterprise data and is normally defined through some enterprise bean methods.

These enterprise bean methods can be accessed and invoked by remote clientsThe behavior of these enterprise beans can be customized at the time of their

deployment by changing the entries in the deployment descriptor.

5512/26/2012

The enterprise bean instance is created and managed by the EJB container where it is deployed.

In addition to business logic, user can also provide service information by using annotations in the enterprise bean itself or declaratively in the deployment descriptor.

The enterprise beans can use the container for all the services defined in the specification.

We need to create a client view of the enterprise bean. The client view refers to creating another enterprise component or other Java

program, such as applet and Servlet, to access enterprise bean and its business methods

The client view of the enterprise bean is independent of the type of container and server in which the enterprise bean is deployed.

5612/26/2012

EJB architecture is flexible and helps in implementing the enterprise bean in various scenarios as mentioned here:

The enterprise bean can be used to provide all stateless services.The enterprise bean can be used as a Web service endpoint that provides stateless service.The enterprise bean can be used to provide stateless service asynchronously with the arrival of some message.The enterprise bean can be used to provide stateful services, where the conversational state of a client is maintained.The enterprise bean can be used as an entity that represents a persistent object that is managed automatically for its persistence and relation with other entities.

5712/26/2012

Why EJB 3. 0?The previous version of EJB, EJB 2.1, was powerful enough to support all the needs

of a distributed enterprise application, but it was very complex to develop because a developer has to create a number of interfaces and classes for implementing single enterprise bean.

In addition to this, all interfaces and classes developed were required to implement interfaces and extend classes from javax.ejb package.

The client, therefore, had to use JNDI (Java Naming and Directory Interface) look up to access enterprise bean and invoke its business methods.

The EJB 3.0 introduced with Java EE 6 specification has made Enterprise JavaBeans technology simpler and easier to be implemented in the application.

5812/26/2012

EJB 3.0 needs fewer interfaces and classes as it supports metadata annotation to support dependency injection.

The use of default behavior and configuration through annotations has further removed the need of deployment descriptors, and the entity persistence and Object/ Relational mapping has also been simplified.

In EJB 3.0, since the container has to work more for doing all the processing, it gives developer enough time to concentrate on the implementation of business logic, thereby increasing the productivity of the developer.

The EJB 3.0 enhances business logic implementation and speeds up the enterprise bean development.

5912/26/2012

Some facts about EJB 3.0 are as follows:EJB 3.0 leverages Java language metadata, which helps simplify all bean types, and resource accesses. It reduces the need of deployment descriptors but preserves the ability to use XML file as an alternative mechanism and overriding annotations.The enterprise beans now resemble Plain Old Java Objects (POJO) and do not need to implement EJB component interfaces.All Business interfaces are also Plain Old Java Interfaces (POJI).The Home interfaces are not required any more in EJB.In EJB 3.0, all callback methods are defined by using annotations, because javax.ejb.EnterpriseBean interfaces are not used in it.The persistence model is simplified.EJB 3.0 specification always ensures that the EJB 2.1 API is available and supports the reuse of existing components in the new application. EJB 3.0 specification helps in migrating from previous EJB 2.1 application to new EJB 3.0 applications.

6012/26/2012

EJB 3. 0 -Architecture and ConceptsThe EJB 3.0 architecture comprises the EJB server, EJB container, and EJB client. The first model is to process an EJB file to generate deployment artifacts (required

interfaces and deployment descriptors) closer to the EJB 2.1 deployment model and then deploy the EJB component in the same way as EJB 2.1 deploys it.

The deployment descriptors and files generated can be non-standard, but they might resemble the deployment descriptors in EJB 2.1.

This approach reduces rework for container providers and also reduces the burden of supporting both EJB 2.1 and EJB 3.0-style EJB components.

6112/26/2012

Another EJB 3.0 processing model is a JSP-like (JavaServer Pages) drag-and-drop deployment model.

Now you can drop an EJB file into a pre-designated, implementation-defined directory. The container picks it up, processes it, deploys it, and makes it available for use.

6212/26/2012

EJB ServerAn EJB server provides a runtime environment to execute server applications that use

enterprise beans. It is used to create an infrastructure to deploy server applications also called

components. It provides a JNDI-accessible naming service, manages and co-ordinates the

allocation of resources to client applications, provides access to system resources, and provides a transaction service.

In the EJB architecture, servers are basically the resource managers. Every server manages the allocation of resources to the containers it controls. It is the

resource manager that determines which and how many of the containers may run within the server.

6312/26/2012

Following points show what a server does in the EJB architecture:At the client-level, the server manages all incoming client requests. This also includes providing connections to clients, dispatching client requests to containers, and routing responses back to clients.At the container-level, the server manages the processing of the resources that are available to the container. This type of management includes allocating available working processes and threads to the running containers.At the service-level, the server verifies that the container has access to shared services, such as a centralized security manager, a pool of JDBC drivers, a transaction service implementation, a global cache manager, and an asynchronous messaging service.

6412/26/2012

user can run an EJB application on more than one server. So, in addition to allocating resources to the containers managed by the servers, the

servers must cooperate as a group to allocate resources efficiently across all the servers in a cluster.

This cooperation among the servers involves publishing the load information to a load balancing process, and then assigning the client requests to the least-loaded server to provide the requested services.

It also includes system management infrastructure, such as demons, that automatically starts server processes, alerts to a management console when the server load exceeds a certain level, and management interfaces for controlling the resource allocation policies of the server.

6512/26/2012

EJB ContainerThe EJB container provides an environment in which one or more enterprise beans

can run. This environment is basically a combination of available interfaces and classes that

the container uses to support enterprise beans throughout their life-cycle.The EJB container performs the following tasks:The EJB container transparently provides services by intercepting all method calls to the EJB components.The EJB container provides following control and management services:

Life-cycle management -Creates and removes enterprise bean instances, handles instance pooling with their activation and passivation.

6612/26/2012

Naming services -Provides JNDI registration of EJB when the enterprise bean is loaded.Security checks-Performs authentication and access control and implements declarative and programmatic security.Persistence management -Helps in storing the enterprise beans.Transaction coordination -It is the declarative transaction managementResource pooling-It is an indirect access to the bean instance

The EJB container simplifies the complex aspects of a distributed application, such as security, transaction coordination, and data persistence.

6712/26/2012

The EJB infrastructure is implemented by EJB container and service providers.This infrastructure deals with the distribution aspects, transaction management, and

security aspects of an application. The Java APIs for the infrastructure is defined by EJB specification.Now the developers focus on their area of expertise -- the Business logic -- and leave

the infrastructure to the platform specialists. Figure 13.2 shows various services provided by EJB container.

6812/26/2012

6912/26/2012

The responsibilities of an EJB container for each enterprise bean are as follows:It registers the object.It provides a Remote interface for the object.It creates and destroys object instances.It checks security for the object.It manages the active state for the object (activation/passivation).It co-ordinates distributed transactions.It persists CMP entity beans, and saves stateful Session beans attributes when passivated.

Whenever a client wants to call business methods of an enterprise bean, it actually connects to the container first. -

7012/26/2012

The container then verifies that the call conforms to the semantics specified in the deployment descriptor before dispatching the call to the EJB itself.

This mechanism allows the container to control all aspects of the execution -of an EJB, including the following:

Life-cycle-The life-cycle methods of the enterprise bean are invoked as per the specification. While managing the life-cycle of an enterprise bean, the container itself enforces security, transaction, and persistence requirements.Security -When a client attempts to call a method of an EJB, the container looks for the user's permission in an Access Control List (ACL) to verify whether the client has the right to invoke that method. The deployment descriptor object contains declarations about the access control for an EJB's methods.

7112/26/2012

Transactions -These are the declarations about the transaction restrictions on an EJB's methods included in the deployment descriptor object. When a client attempts to call the method of an EJB, the container is responsible for verifying whether the call obeys the transaction restrictions on that method. The restrictions for execution of a transaction are as follows:

It must not execute within a transaction context.It may execute within a transaction context.It must execute within a transaction context, and it must execute within a new transaction context.

7212/26/2012

Persistence- We can use two different types of persistence-one that is managed by bean itself and the other that is managed by the container. In case of the persistence managed by beans itself, the bean needs to implement its own data access code, while in the persistence managed by the container, the enterprise bean delegates data access to the container, thus making the container responsible to implement appropriate data access functioning.

7312/26/2012

EJB ClientThe client code is the code written to execute business logic embedded in

enterprise bean and its methods. EJB client can be a simple Java program or a Web client.The end-user runs these clients to get results from the enterprise bean method

invocation. An EJB client can use resource injection or JNDI service to access an enterprise

bean. The client code can be a simple Java class, Applet, Servlet, or JSP. An enterprise bean is looked up using resource injection or lookup() method,

irrespective of the different EJB clients.

7412/26/2012

Features of EJB 3.0:EJB 3.0 specification addresses all the complexities that it has in its previous versions

and solves them by implementing new strategies. The new features added in the EJB 3.0 have changed the way the enterprise beans

are developed, configured, and deployed. The extensive use of metadata annotations has reduced the use of different interfaces and classes and deployment descriptors.

The interfaces required in an application and deployment descriptor generation are now taken care of by the container.

This has relaxed developers from developing unnecessary local or remote home and component interfaces.

7512/26/2012

The callback methods can easily be marked in the enterprise bean now. The enterprise bean has been simplified to a POJO model and all resources to be

used by the components are injected using dependency injectionThe features of EJB 3.0 have been summarized here:

AnnotationsElimination of Home InterfaceElimination of Component InterfaceCallback MethodsSimple POJO ModelJava Persistence APITimer ServiceInterceptors

7612/26/2012

AnnotationsA new program annotation facility has been introduced in the Java Platform, Standard

Edition, 5 (Java SE 5). These metadata annotations (or simply the annotations) are inspected at compile time

or runtime by the different tools to generate additional constructs, such as deployment descriptors, and to customize the component's runtime behaviour.

class fields, methods, and classes can be annotated with different annotations, such as @Remote, @Stateful, and @Stateless.

EJB 3.0 proposed a set of annotations that has made development of enterprise beans easy.

The annotations indicate that the associated element maintains some application-specific or domain-specific semantics

7712/26/2012

Annotation should only be provided when defaults cannot be used.For example, for an enterprise bean CustomerBean, we do not need to extend javax.ejb.EnterpriseBean type of class; instead, we can use @Stateless annotation to declare it stateless session bean, as shown here:

import javax.ejb.stateless; @statelesspublic class CustomerBean{

public string sayHello(){return "Hello from CustomerBean.";}

}

7812/26/2012

Elimination of Home InterfaceIn EJB 3.0, all enterprise beans are created homeless, it means that we do not need

to create home interface for the enterprise bean. In EJB 2.1, we need to create a home interface by extending javax.ejb.EJBHome

interface or javax.ejb.EJBLocalHome interface and declare life-cycle methods, such as create() and remove().

In EJB 3.0, we do not need to create locale or remote home interfaces for the enterprise bean.

The EJB 2.1 APIs are still supported in EJB 3.0 specification and the home interfaces can still be used, which supports reverse compatibility with previous versions.

7912/26/2012

Elimination of Component InterfaceThe earlier versions of EJB require the local or remote component interfaces to be

created for the given enterprise bean. The local and remote component interfaces need to extend javax.ejb.EJBObject and

javax.ejb.EJBLocalObject respectively.The component interfaces were used to declare the business method that a client

could invoke. In EJB 3.0, its not required to create component interfaces as they have been

replaced by business interfaces that declare all business methods to be provided to the client.

The business interface can be local or remote, but it is a simple POJI (Plain Old Java Interface).

8012/26/2012

Callback MethodsIn EJB 3.0, not need to define all the unnecessary life-cycle callback methods, such

as ejbPassivate() and ejbActivate(), in the enterprise bean class. In the earlier versions, we have to define these callback methods but in EJB 3.0, they

have become optional. However, we can define any of these methods in our bean class to which the

container can invoke. In EJB 3.0, we can mark an arbitrary method as the callback method, which can listen

EJB life-cycle events. user can use different metadata annotations, such as @PreDestroy, -@PostConstruct,

@PrePassivate, @PostActivate, and @Remove to mark a method as callback method.

8112/26/2012

A enterprise bean method marked with @PreDestroy is shown here:@statefulpublic class SomeSessionBean{

@PreDestroypublic void someMethod() {

/*Some Logic to be executed before the destroy() method*/

}}

8212/26/2012

Simple POJO ModelEJB 3.0 supports a simple Plain Old Java Object (POJO) model. A simple Java class which does not implement any interface or extends any class can

be treated as an enterprise bean. A simple POJO object can be made a powerful component handling concurrency,

transactions, and security issues. All these are provided by the container to the simple POJO objects.The POJO model also helps in creating enterprise bean classes that do not depend

on other APIs. The POJO objects help in implementing the unit testing by using frameworks, such as

JUnit, without deploying them on a server.

8312/26/2012

The implementation of POJO model has totally simplified the development of enterprise beans.

Now we just need to create simple business interfaces that are the Plain Old Java Interfaces (POJIs), and implement business methods in enterprise bean class which is a Plain Old Java Object (POJO).

All the resources are made accessible in the component by resource injection using metadata annotations, and all callback methods can be marked with metadata annotations.

8412/26/2012

Java Persistence APIEJB 3.0 provides a new Java Persistence API, which further simplifies the

programming model for entity persistence. The Object/Relational mapping and all persistence logic is now handled by the

container and we just need to provide proper annotations, such as @Id, @Table, @OneToOne, and @OneToMany.

These annotations are used to map entities and their relationships to application's database.

The long term storage of this large amount of information has been simplified by Java Persistence API.

The first release of Java EE 5 introduced entity bean as a solution to Java Persistence.

The introduction of the entity bean has prevented the developers to directly deal with the persistence.

8512/26/2012

But the first release of the technology lacked many features, such as annotations, and provoked many problems to the developers.

Some of the major problems were: relationships of the entities which had to be managed by the applications, foreign key fields were required to be stored and managed on the bean class.

The EJB2.1 specification solved many of the problems by introducing the idea of container-managed entity beans.

In the container managed entity bean, the server was responsible for generating subclasses to manage the persistent data.

The EJB2.1 specification also introduced the Enterprise Java Bean Query Language (EJBQL)-a query language designed to create queries for CMP entity beans.

8612/26/2012

This language is similar to SQL but searches for persistent attributes of the enterprise Java bean.

EJB 2.1 specification, despite of improved features than its earlier versions, was still overloaded with the major problems and complexities.

The EJB 3.0 provides new Java Persistence API, which simplifies the programming model for entity persistence.

Now Object Relational Mapping or Persistence approach uses POJO model instead of abstract persistence schema model.

The Object Relational mapping maps entities and their relationships to application's database.

8712/26/2012

EJB 3.0 entity depicts persistent-information stored in database by using Container Managed Persistence (CMP) but EJB 2.1 entity bean only represents persistent information stored in the database

The optimistic locking technique that was supported only by TopLink persistence framework is also encapsulated in EJB 3.0 specification.

It also enhances R/W access ratios. The optimistic locking technique allows you to use objects in a disconnected model

implying that you can change data and their relationships offline and merge data operations into one transaction.

We can also create deep and wide entity inheritance hierarchies.

8812/26/2012

Other changes made in the Java Persistence API, which were not there in EJB2.1, are as follows:

It requires less number of classes and interfaces.New EntityManager API, similar to Hibernate, is introduced to perform operations, such as creation, removal, and searching on entity beans.The lengthy deployment descriptors have been eliminated through annotations.It provides cleaner, easier, and standardized object-relational mapping.The need for lookup code has also been eliminated.It adds support for inheritance, polymorphism, and polymorphic queries.It adds support for named (static) and dynamic queries.We can now perform many database related operations, instead of performing only one operation generating primary key.It provides a Java Persistence query language -an enhanced EJB QL.It makes testing the entities without the EJB container easier. Earlier, the developers need to be aware of deployment platform to test EJBs.

8912/26/2012

Dependency InjectionThe client, to use the constructed bean in an application, needs to know how to locate

and invoke that enterprise bean (constructed bean).The client for an EJB 2.1 session bean gets the reference of the session bean with

JNDI. In order to use an enterprise bean, say Calculator bean, the EJB 2.1 client needs to

add the following code to locate and invoke an enterprise bean method:context ic = new Initialcontext();object obj = ic.lookup ("calculatorJNDI");CalculatorHome home = (CalculatorHOme) POrtableRemoteobject.narrow(obj, calculatorHOme.class); Calculator calc = home.create();

9012/26/2012

In the preceding code, the JNDI name of the Calculator bean is "CalculatorJNDI". The local/remote instance is obtained with create() method. But in EJB3.0, the JNDI

lookup and create() method invocation is not required. In EJB3.0, a reference to a resource is obtained with dependency injection using

annotation. EJB, by implementing dependency injection, conveys to the container that a particular

resource is dependent on some resource. A dependency annotation comprises the type of resource, the resource properties,

and a name to access the resource. The use of annotations in EJB 3.0 has simplified the task of both the developers and

the EJB client.

9112/26/2012

Some examples of dependency annotations are as follows:@EJB(name="sessionBeanName",beanlnterface=sessionBeanlnterface.class) @Resource(name="Database",type="javax.sql.Datasource.class")

The @EJB annotation used here injects stubs of session bean having name "sessionBeanName".

The @Resource annotation is used to inject service object having JNDI name "Database".

This name may be present in either global or local JNDI tree.Dependency annotations may be associated to bean class, its member variables or methods.

The information to be specified in dependency annotation depends upon the context and the amount of data to be fetched from that context

9212/26/2012

Timer ServiceIn enterprise applications, sometimes we need to implement time-dependent services.For example we may need to invoke a particular business method provided by enterprise bean after a given span of time or by invoking them repeatedly after a fix time interval. Before EJB 2.1, developers had to write code manually for building and deploying time-based workflows. However, with EJB 3.0, the task of creating such application has been considerably simplified. Equipped with annotations and dependency injections, developers can use EJB 3.0 to build and deploy scheduled applications easily.

9312/26/2012

InterceptorsThe interceptors intercept the invocation of business methods of enterprise bean to

provide some additional functionality. The interceptors are used with session beans and Message-driven beans. Interceptor

methods to be invoked before a business method can be defined in a separate class known as Interceptor class.

For example, we always want to validate all passed values to the business methods before the actual logic is executed.

We can invoke more than one interceptor on an EJB.We use @Interceptors annotation to import a chain of interceptors associated with the

bean.

9412/26/2012

We can define interceptor methods using @AroundInvoke annotation.Following code is used to add interceptor methods to a bean:

@Stateful@Interceptors({MethodProfiler.class}) public class someServiceBean {

………….

}