1. Enterprise Computing with Java (MCA-305) Unit 3: EJB Fundamentals
© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63, by Dr. Sunil Pratap Singh 1

2. What is EJB: Background
Component
A component is a piece of code that implements well-defined interfaces.
Typically, it lives in a runtime environment and takes advantage of the services offered by the environment.
For the component to live in a runtime environment, it must follow the rules of the runtime environment. This ensures the proper functioning of the runtime environment and the portability and scalability of the component.
A component is not a complete application.
An application consists of multiple components working together.

3. What is EJB: Background
The development of server-side objects is more difficult than writing client components because in addition to writing business application logic, the developers must also take care of system-level issues such as:
multithreading,
access to databases,
efficient management of resources,
transactions,
security,
access to legacy systems, etc.
A server component model or architecture provides support for server-side components. This simplifies the development of server-side components and allows developers to focus on developing business application logic.

4. What is EJB
An Enterprise JavaBean (EJB) is a server-side component that implements the business logic of an enterprise application and adheres to the rules of the Enterprise JavaBean architecture.
Enterprise beans live in an EJB Container - a runtime environment within a J2EE server.
The EJB container provides multiple services to support the enterprise beans.

5. Characteristics of EJBs
They contain business logic that operates on the enterprise’s data.
They depend on a container environment to supply life-cycle services for them. EJB instances are created and maintained by the container.
System-level services, such as transaction management and security, are described separately from the enterprise bean.
A client never accesses an enterprise bean directly; the container environment mediates access for the client. This provides component-location transparency.
The EJB is designed to be portable across EJB servers provided by different vendors.
They can be included in an assembled application without requiring source code changes or recompilation of them.
Beans are always single threaded; we never have to write thread-safe code. We design our EJBs as single-threaded components, and the EJB container handles multiple client requests by load balancing and instantiating multiple instances of the single-threaded components.

6. Remote Method Invocation (RMI): Background
RMI is an API that provides a mechanism to create Distributed Applications.
A distributed application is a software or application that runs on more than one computer and communicates through a network.
RMP provides an object running in one JVM to invoke an object and methods on an object running in another JVM.
RMI provides remote communication between programs written in the Java programming language.
The JVM application, in which an invoked method is running out, is called RMI Server, where as the invoking application running on the different JVM is called RMI Client.

7. General RMI Architecture
RMI provides remote communication between the applications or programs using two objects:
Stub
Skeleton

8. Work Flow of RMI-based Applications
1. The server creates a remote object and registers it at the registry.
2. The client can obtain references to objects stored in the registry.
3. When the client invokes a method on the remote object, the method is actually invoked on the Stub object, located in the same JVM as the client’s JVM.
4. The Stub object makes a message containing the name of the method together with its parameters (called marshalling) and sends this message to the associated Skeleton object residing in the server’s JVM.
5. The Skeleton object extracts the method name and parameters from the message (called unmarshaling), and invokes the appropriate method on the remote object with which it is associated.
6. The remote object executes the method and passes the return value back to the Skeleton.
7. The Skeleton in turn marshals the return value in a message and sends back to the Stub object.
8. The Stub unmarshals the return value from the message and returns this value to the client program.

9. Working Ex. of RMI-based Applications

10. RMI vs. EJB
RMI
In RMI, middleware services such as security, transaction management, object pooling etc. need to be done by the java programmer.
RMI is not a server-side component. It is not required to be deployed on the server.
EJB
In EJB, middleware services are provided by EJB Container automatically.
EJB is a server-side component, it is required to be deployed on the server.

11. JavaBeans vs. Enterprise JavaBeans
JavaBeans is an approach to develop reusable software components that can be used for building different types of Java applications (applets, stand-alone apps).
Java Bean is a plain java class with member variables and getter setter methods.
JavaBeans may be visible or nonvisible as it can be used as client component or server-side programming.
JavaBeans are intended to run on a client side. However a JavaBeans component can be used anywhere, either like an AWT/Swing component on the client (View Bean) or with a JSP page on the server (Data Bean)
Although one can develop server-side JavaBeans, it is far easier to develop them using the EJB specification instead.
JavaBeans are not part of the J2EE architecture.
JavaBeans are used in the J2EE applications as either a View Bean or as a Data Bean.

12. JavaBeans vs. Enterprise JavaBeans
Enterprise JavaBeans (EJBs)
An EJB is nonvisual component as it is remote object.
EJBs are remotely executable components or business objects that can be deployed only on the server.
EJBs are deployed on the EJB container and executes in the EJB container.
An EJB is a reusable server-side software component which facilitates the development of distributed Java applications.
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.
The only similarity between an EJB and a JavaBean is that both are components. 

13. EJB Architecture (J2EE Architecture)
The J2EE architecture is a consolidation of standards, specifications, frameworks, and guidelines to provide Java capability on the server side for the enterprise.
These standards and frameworks consist of classes and interfaces to be implemented by both service providers and developers.
The EJB API is at the heart of the J2EE architecture. The other APIs are used as services to the EJB API.
A J2EE implementation can be obtained from many vendors today.
The implementation of the J2EE specification is realized through a Java Application Server (EJB Container), a product that offers the infrastructure-base solutions to the enterprise needs.
The most common Application Servers are WebLogic, WebSphere, GlassFish, and Jboss.

14. Components of EJB Model/Architecture
EJB Server
EJB Container
EJB Client
Home Object (Home Interface)
EJB Object (Component Interface)
Enterprise Bean (Bean Class)
Common Services

15. EJB Server
The EJB Server (also known as the J2EE Application Server) is the outermost container of the various elements that make up an EJB environment.
The EJB server manages one or more EJB/or different containers and provides required support services
Common (Horizontal) Services:
The Common Horizontal Services are the services specified in the J2EE Architecture. They’re commonly known as J2EE APIs, and are provided by the EJB server to all the containers running on the server.
Java Naming and Directory Interface (JNDI)
Java Database Connectivity (JDBC)
Java Message Service (JMS)
JavaServer Pages (JSP)
Java Servlet

16. EJB Container
An EJB container is an abstract facility that manages instances of EJB components.
Common (Vertical) Services:
The common vertical services are inherent services that are provided by the EJB Container and are not specified explicitly by the J2EE architecture APIs.
Life Cycle Management
Security
Remote Method Invocation
Transaction Management
Persistence
Passivation / Activation
Resource Pooling

17. EJB Client The client can be either Local or Remote.
A local client means the client is running in the same JVM as the bean.
We use remote client when we want a bean to be used by the outside world.
How does an object in one JVM directly call a method on a reference to an object running in another JVM?
Java RMI (Remote Method Invocation) solves this problem by giving the client a proxy (called a stub) object that acts as the go-between for the Client and Remote object.

18. Characteristics of Local Clients
It must run in the same application as the enterprise bean it accesses.
It can be a web component or another enterprise bean.
To the local client, the location of the enterprise bean it accesses is not transparent.

19. Characteristics of Remote Clients
It can run on a different machine and a different JVM from the enterprise bean it accesses.
It can be a web component, an application client, or another enterprise bean.
The enterprise bean must implement a business interface, i.e., remote clients may not access an enterprise bean through a no-interface view.

20. Clients interacting with EJB Components

21. EJBHome (Home Interface)
The Home Interface lists the available methods for creating, removing, and finding EJBs in the container.
The Home Object is the implementation of the Home Interface that is generated by the container at deployment time.
The Home Object has one main job: to hand out references to a Bean’s Component Interface.
At runtime, the Home Object will be used by the Client in conjunction with a naming service to find the component and establish a connection to its Component Interface.
Each deployed bean has its own Home Object, and that Home Object is responsible for all Bean’s instances of that type.

22. EJBObject (Component Interface)
The Component Interface defines the Business Methods offered by a Bean Class.
The Bean Class does not directly implement the Component Interface but, rather, uses an EJBObject that mediates the Client’s calls to a Bean Object.
The Container provides the implementation of this interface, and the Client will use it.
The Component Interface can be either Remote or Local, depending on the location of the EJB Client with respect to the EJB.
In EJB, the EJBObject (Remote Object) is the Bean’s Bodyguard.
The Bean sits back, protected from all Client’s invocations while the EJBObject implements the Component Interface and takes the remote calls.

23. EJBObject (Component Interface)
Business logic lives here.

24. How EJB uses RMI

25. POJO POJO POJO stands for Plain Old Java Object.
POJO is an ordinary Java object, not bound by any special restriction other than those forced by the Java Language Specification.
POJOs are used for increasing the readability and re-usability of a program.
POJOs have gained most acceptance because they are easy to write and understand.
POJOs were introduced in EJB 3.0 by Sun Microsystems.

26. POJO A POJO should not extend pre-specified classes.
public class Test extends HttpServlet { … } is not a POJO class.
A POJO should not implement pre-specified interfaces.
public class Bar implements SessionBean { … } is not a POJO class.
A POJO should not contain pre-specified annotations.
@javax.persistence.Entity
public class Baz { … } is not a POJO class.

27. POJO
A POJO basically defines an Entity. If we want an Employee class then we can create a POJO as follows:
This example is a well-defined example of POJO class. As we can see, there is no restriction on access-modifier of fields. They can be private, default, protected or public. It is also not necessary to include any constructor in it.

28. JavaBeans vs POJO JavaBeans are special type of POJOs.
There are some restrictions on POJO to be a JavaBean.
All JavaBeans are POJOs but not all POJOs are JavaBeans.
Serializable, i.e., JavaBeans should implement Serializable interface.
Fields should be private. This is to provide the complete control on fields.
Fields should have getters or setters or both.
A no-argument constructor should be there in a JavaBean.
Fields are accessed only by constructor or getter/setters.

29. Steps to Define a Stateless Bean in EJB 2.x
EJB Component Interface
It is used by an EJB Client to gain access to the capabilities of the bean.
This is where the Business Methods are defined.
The component interface is called the EJB object.
There are two types of Component Interfaces:
Remote component interface (EJBObject):Used by a Remote Client to access the EJB through the RMI-IIOP protocol.
Local component interface (EJBLocalObject): Used by a Local Client (that runs inside the same JVM) to access the EJB.

30. Steps to Define a Stateless Bean in EJB 2.x
EJB Home Interface
It is used by an EJB Client to gain access to the bean.
It contains the bean Life Cycle Methods of create, find, or remove.
The EJBHome is an object which implements the Home Interface.
At startup time, the EJB Container instantiates the EJBHome objects of the deployed enterprise beans and registers the home in the naming service.
An EJB Client accesses the EJBHome objects using the Java Naming and Directory Interface (JNDI).
There are two types of Home Interfaces:
Remote Home Interface (EJBHome): Used by a Remote Client to access the EJB through the RMI-IIOP protocol.
Local Home Interface (EJBLocalHome): Used by a Local Client (that runs inside the same JVM) to access the EJB.

31. Steps to Define a Stateless Bean in EJB 2.x
EJB Bean Class
It contains all the actual bean business logic.
It is the class that provides the business logic implementation.
Methods in this bean class associate to methods in the component and home interfaces.

32. Example of Stateless Bean in EJB 3.x
To declare a Stateless Session Bean according to EJB 3.1 specification, simply define a POJO:
@Stateless
public class MySessionBean implements MyBusinessInterface {
// business methods according to MyBusinessInterface
..... }
To expose the same bean on the Remote Interface, use annotation:
@Remote

33. Example of Stateless Bean in EJB 2.x
public class AccountBean implements javax.ejb.SessionBean { SessionContext ctx; DataSource accountDb; public void setSessionContext(SessionContext ctx) { this.ctx = ctx; } public void ejbCreate() { accountDb = (DataSource)ctx.lookup("jdbc/accountDb"); public void ejbActivate() { } public void ejbPassivate() { } public void ejbRemove() { } public void setAccountDeposit(int empId, double deposit) { Connection conn = accountDd.getConnection(); ...

34. Example of Stateless Bean in EJB 3.x
public class AccountBean implements Account {
@Resource private DataSource accountDB;
public void setAccountDeposit(int custId, int amount)
...
Connection conn = accountDB.getConnection(); }

35. Interface: Need? Problems: Solution:
How does the client know which method to call?
How does the stub know which methods the Remote object has?
If the stub is pretending to be the Remote object, the stub must have the same methods as the Remote object.
Solution:
Interface
All methods in a distributed environment should be exposed to a client.

36. EJB Interfaces
Each Session or Entity Bean has two interfaces (Home and Component) and a Bean class.
A Message-Driven Bean has only a Bean class and defines no interfaces.

37. Types of Enterprise Beans
Session Bean contains business processing logic.
Message-Driven Bean allows clients to asynchronously invoke business logic.
Entity Bean contains data processing logic.

38. Why EJB / Benefits of EJB Technology
Simplicity
The EJB architecture simplifies the development of complex enterprise applications by providing built-in common services. This allows an EJB application developer to access and utilize these services, and results in a reduction of the overall development effort.
Application Portability
Portability can be accomplished by deploying an EJB application on any J2EE-compliant application server. Many Java Application Servers (EJB Containers) today implement all the services provided by J2EE-standard specifications.
Component Reusability
An EJB is a highly reusable building block. The application business logic of a certain EJB can be reused through Java sub-classing of the EJB class.

39. Why EJB / Benefits of EJB Technology
Application Partitioning
The separation of an application’s business logic from its presentation allows ease of development and helps business programmers to work independently from Web page designers. Again, the separation of the application’s business logic from its data helps manage each team independently. Any change of a component hosted in one tier does not affect the other tiers.
Distributed Applications
The EJB architecture helps create distributed applications, which can span multiple environments. Each subsystem can work independently of the others, but still can interact with one another to deliver enterprise services to the target users. A user transaction, for example, can be executed across multiple servers within a single context, and will be perceived by the user as a single unit of work.

40. Why EJB / Benefits of EJB Technology
Application Interoperability
The EJB architecture helps EJB components to access other components written in other component-based models, such as CORBA and .NET.
Application Integration
One of the main objectives of the EJB architecture is to allow the integration of new applications with existing applications, such as legacy systems. Enterprise Application Integration (EAI) is an important topic for the corporate world. The related J2EE APIs, such as the J2EE Connector Architecture (JCA) and the Java Message Service (JMS) specification, make it possible to integrate enterprise bean applications with various non-Java applications, such as ERP systems or mainframe applications, in a standard way.

41. Why EJB / Benefits of EJB Technology
Availability of Java Application Servers
An enterprise has many J2EE-compliant application servers to choose from. Each application server provides J2EE services at a minimum, with the addition of other value- added services. A J2EE-compliant server can be selected to meet the customer’s needs, which prevents vendor lock-in.
The most significant value provided by the EJB architecture is the separation of business logic programming from the challenge of integrating business logic with the complexities of enterprise-class server-side runtime environments.
If the containers in which EJB components are deployed assume responsibility for managing runtime services such as persistence, transactions, and concurrent database access, bean developers are free to focus on developing software components that encapsulate business logic.

42. Example: Using a Home Object & EJB Object
Suppose there is a bean named as AdviceBean:
1. The AdviceBean is deployed, and the Server instantiates the AdviceBean HomeObject and register it with JNDI.

43. Example: Using a Home Object & EJB Object
2. The Client does a JNDI lookup on the HomeObject, using the registered name “Advisor”.

44. Example: Using a Home Object & EJB Object
3. JNDI sends back a Stub to the Remote HomeObject.

45. Example: Using a Home Object & EJB Object
4. Client asks the HomeObject for a reference to the Component Interface, by calling create().
In other words, the Client wants to “create” a bean and get the Stub back to the bean’s EJBObject.

46. Example: Using a Home Object & EJB Object
5. Now, the “services” kick in, and the bean is created.

47. Abstract View of using a Home Object & EJB Object

48. Example: Using a Home Object & EJB Object
6. The EJBObject is made and its stub is returned to the Client.

49. Example: Using a Home Object & EJB Object
7. Now, the Client can (finally) do what he/she really wants to do – call a business method on the bean (which of course, has to go through Component Interface)

50. Example: Using a Home Object & EJB Object
8. The Client can get rid of his/her Home stub if he/she does not want to access to more beans of this type (AdviceBean), but he can still keep calling methods on the Component Interface.

51. Creating and using a Bean

52. Session Bean: Clients share the Home but never the Bean

53. Entity Bean: Clients share the Home and may share the Bean

54. Things to build a Bean
Code the Bean Class with all of the business methods
Code Component Interfaces for the bean.
Code Home Interfaces for the bean.
Create an XML Deployment Descriptor that tells the server what the ben is and how it should be managed. Its name should be ejb-jar.xml.
Put the bean, the interfaces, and the deployment descriptors into an ejb- jar file. (There might be more than one beans in the ejb-jar, but there will always be just one deployment descriptor.)
Deploy the bean into the server, using the tools provided by the server vendor.

55. 1. Code the Bean Class
In bean class, we implement our business methods defined in the component interface.
There are three bean types to choose from: session, entity, and message-driven.
Before making a bean, we must decide what type of we need because our bean class must implement one of three interfaces depending upon the types we choose.
Example Code:
import javax.ejb.*;
public class CalculatorBean implements SessionBean {
… … }

56. 2. Code Component Interfaces
This is where all the business methods are declared.
In other words, it is where we put the methods the client wants to call.
Code Example:
import javax.ejb.*;
public interface Calculator extends EJBObject {
public int addition(int a, int b); }

57. 3. Code Home Interfaces Home Interface Code Example:
The client uses the home interface to ask for a reference to the component interface.
The home interface can be considered as a kind of factory that makes and distributes bean references to clients.
Code Example:
import javax.ejb.*;
public interface CalculatorHome extends EJBHome {
public Calculator create() throws CreateException; }

58. EJB Object Model

59. Things to build a Client
Get a reference to JNDI InitialContext.
Use the InitialContext to do a lookup on the home interface of bean.
Cast the thing we get back from the lookup.
Call create on the home interface to get back a reference to the component interface.
Call addition(4,5) (the business method) on the component interface, and print the result.

60. Things to build a Client: Example
On a Servlet:
Context initialContext = new InitialContext();
Object obj = initialContext.lookup(“Calculator");
CalculatorHome calHome =(CalculatorHome) obj;
Calculator calc = calHome.create();
out.println(“Sum = “ + calc.addition(3,4));
InitialContext is initial point into the JNDI naming service, where we do the lookup.

61. JNDI (Java Naming & Directory Interface)

62. JNDI (Java Naming & Directory Interface)
Context ic = new InitialContext(); Object ob = ic.lookup(“Advisor”); AdvisceHome home = (AdviceHome) ob;

63. High Level View of EJB Architecture

64. Deployment Descriptor
A Deployment Descriptor is an Extensible Markup Language (XML) document (with an .xml extension) that describes a component’s deployment settings.
Because Deployment Descriptor information is declarative, it can be changed without modifying the Enterprise JavaBean source code.
You can create the Deployment Descriptors by hand or use vendor tools to generate them.
At deployment time, the J2EE server reads the Deployment Descriptor and acts on the component accordingly.
ejb-jar.xml file is the standard Deployment Descriptor as specified by Sun/Oracle.

65. Deployment Descriptor
The ejb-jar.xml describes the Enterprise JavaBean’s deployment properties, such as its bean type and structure.
The file also provides the EJB container with information about where it can find, and then load, the home interface, remote interface, and bean class.
Sample ejb-jar.xml file:
<?xml version="1.0"?>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>EmployeeDetail</ejb-name>
<home>EmployeeHome</home>
<remote>Employee</remote>
<ejb-class>EmployeeBean</ejb-class>
<session-type>Stateful</session-type>
</session>
</enterprise-beans>

66. Packaging and Deployment EJBs
The process of assembling components into modules, and modules into applications, is known as packaging.
The Java ARchive (JAR) file format enables to bundle multiple files into a single archive file.
Enterprise beans use the JAR file format for packaging Enterprise JavaBeans in a generic and portable way.
The ejb-jar file is the standard format for packaging Enterprise JavaBeans.
After EJBs are packaged, we need to install and configure them in an EJB container for loading and execution. This is known as deployment, which makes the new functionality available as a service.

67. Packaging and Deployment EJBs

68. EJB Ecosystem

69. EJB Ecosystem
To have an EJB deployment up and running, one needs more than an application server and components. There are six more parties that are involved:
Tool Vendors/Provider: There are various IDEs available to assist the developer in rapidly building and debugging components, for example Eclipse, NetBeans, and JBuilder.
Bean Provider: The bean provider supplies the business components to the enterprise applications. These business components are not complete applications but can be combined to form complete enterprise applications.
Application Assembler: The application assembler is responsible for integrating the components. This party writes applications to combine components so as to develop the target application that can be deployed under various environments.

70. EJB Ecosystem (contd…)
Container and Server Providers: The container provider supplies the EJB container (an application server). This is the runtime environment where the beans live. The container supplies the middleware services to the beans and manages them. Examples of containers are: BEA’s WebLogic, IBM’s WebSphere, Oracle’s Oracle 9i Application Server and Oracle 10g Application Server, and the JBoss Open Source Application Server, Glassfish.
EJB Deployer: After the application developer builds the application, the application must be deployed on the server. This involves configuring the security parameter settings, performance tuning, etc. An application assembler is not familiar with these issues. This is where the EJB Deployer comes into play.
System Administrator: The system administrator is responsible for the upkeep and monitoring of the deployed system and may make use of monitoring and management tools to closely observe the deployed system.

71. Bibliography https://docs.oracle.com http://www.studytonight.com
“Enterprise Java Computing: Applications and Architectures” by Govind Sesadari, Cambridge University Press
“Head First EJB” by Kathy Sierra and Bert Bates, O’Reilly Media Inc.
“Mastering Enterprise JavaBeans” by Ed Roman, John Wiley & Sons, Inc.