1. EJB
Enterprise Java Bean

2. Introduction Java's most important features is platform independence.
Java has been depicted as "write once, run anywhere"
Enterprise JavaBeans (EJBs) is both platform independent but also implementation independent.
EJBs can run in any application server that implements the EJB specifications

3. Enterprise Distributed Object Computing (EDOC)
Distributed computing allows business logic and data to be located on separate computers
Reached from remote locations at any time from anywhere by any one.
Recent development in distributed computing is distributed object computing.
The technologies such as Java RMI, CORBA and Microsoft's DCOM help to accomplish distributed object computing.
Allows objects running on one computer to be accessed for servicing the clients in other computers.

4. Object-oriented (OO) programming languages viz., Java, C++, Smalltalk
Features
Flexibility, Extensibility and Reusability
Methodology
Encapsulation, Polymorphism and Inheritance
In business systems,
To improve development of GUIs
To simplify access to data
To encapsulate the business logic into business objects
To support above mentioned features and Methodology.

5. Reaching EJB from earlier computing paradigms
Multi-Tier
Scalability, Performance, Reliability…
Client does not directly interact with the server.
Client contacts the middleware, it instantiates the server application and manages the server objects, and it returns to the client.
Middleware
Concentrate only on business logic
Supports
Thread Handling
Security
Transaction Management
Resource Management

6. Transaction Processing (TP) Monitors
High-speed server platforms
For mission-critical applications
TP monitors are for applications are written in languages like COBOL
TP monitors automatically manage the entire environment that a business system runs in:
Transactions
Resource management
Fault tolerance
With these feature it is eligible to be called operating systems
The business logic in TP monitors is made up of procedural applications that are often accessed through network messaging or remote procedural calls (RPC).
RPC is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally.

7. The downside for TP monitors is as follows:
TP monitors are not object oriented
Work with procedural code that can perform complex and mission-critical tasks but no sense of identity.
Accessing a TP monitors through RPC is like executing static methods.
The business logic, which is procedural, is not as flexible, extensible, or reusable.

8. Object Request Brokers (ORBs)
Distributed objects allow unique objects that have state and identity.
Distributed object computing technologies like CORBA and Java RMI, invoking method is on an object instance, not an application procedure.
Distributed objects are usually deployed on some kind of ORB - responsible for helping client applications find distributed objects in a transparent manner.

9. The down side for an ORB is as follows:
ORBs do not define an operating system for distributed objects.
All the responsibility for concurrency, transactions, resource management and fault tolerance rests on the application developers.
These services may be available from the ORB vendors or can be purchased from third party vendors and can be implemented in an ORB.
The developer has to write the glue code to incorporate them into the business objects.

10. The resource management strategies such as
Instance swapping
Resource pooling
Pre-cached Instances
Mainly responsible for distributed object systems to scale:
improve performance and throughput and reducing latency.
Without automatic support OS features.
In addition ORBs fail to address the complexities of mission-critical environment, an area where TP monitors have always excelled.

11. Component Transaction Monitor (CTM)
Having realized that combining these two revolutionary technologies will do wonders for enterprises
IBM and BEA started to design a hybrid of ORBs and TP monitor systems, which is referred to as component transaction monitors (CTMs) or application servers.
These types of application servers combine the flexibility and accessibility of distributed object systems based on ORBs with the robust operating system of a TP monitor.
CTMs provide a comprehensive environment for server-side components by
Transaction managing
Concurrency
Transactions
Object Distribution
Load Balancing
Security
Resource Management automatically.

12. CTMs have started to come out of several different industries
Relational Database industry
Application Server industry
Web Server Industry
CORBA ORB industry
TP monitor industry.
Each vendor offers products that reflect their particular area of expertise.
But a CTM that supports the Enterprise JavaBeans standard server-side component model from Sun Microsystems seems to be a more elegant and productive choice.
Reasons for success:
Sun Microsystems has framed a number of excellent standard server-side specifications for several technologies.
The Java Database Connectivity API (JDBC) was one of the shining examples.

13. Why EJB?
Sun Microsystems in the beginning put forward Java Remote Method Invocation (RMI) API as a distributed object computing technology.
RMI specifies how to write objects so that they can talk to each other no matter where on the network they are found.
RMI says nothing about other characteristics normally required of an enterprise-class distributed environment.
For example, it does not say anything about how a client might perform a search for RMI objects matching some criteria.
It also does not specify how those distributed objects work together to construct a single transaction.
Thus there is a realization for a need of a distributed component model.

14. A component model is a standard that defines how components are written so that systems can be built from components by different developers with little or no customization.
There is already a component model called as JavaBeans in Java.
It is a component model that defines how we write user interface components so that they may be plugged into third-party applications.
The magic thing about JavaBeans is that there is very little API behind the specification; we neither implement nor extend any special classes and we need not call any special methods.
While there are API elements behind Enterprise JavaBeans, it is more than an API.
It is a standard way of writing distributed components so that the written components can be used with the components we write in someone else's system

15. RMI does not support this ability for several reasons listed below:
Security
Searching
Transactions
Persistence

16. What is EJB? (From EJB Spec.)
“The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications.“
“Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure.“
“These applications may be written once, then deployed on any server platform that supports the Enterprise JavaBeans specification."

17. What is EJB Technology? Cornerstone of J2EE
A server-side component technology
Easy development and deployment of Java technology-based application that are:
Transactional, distributed, multi-tier,portable, scalable, secure, …

18. EJB Design Principles EJB applications are loosely coupled
EJB behavior is specified by interfaces
EJB applications do not manage resources
The container supports the application developer
EJB applications are tiered
The session tier is the API to the application
The entity tier is the API to the data sources

19. EJB Applications are Loosely Coupled
Support the integration of components from different vendors
EJBs refer to other components and services to which they have access by arbitrary names
EJB can be authored without a detailed knowledge of the environment
Applications can be assembled from separate components

20. EJB behavior is specified by Java interfaces
An EJB’s interaction with its clients is specified entirely in terms of Java interfaces
Interfaces expose the methods that clients can call, and thereby set out a ‘contract’ between the client and the EJB
Implementation is hidden from the client
Supports portability and modularity

21. EJB applications do not manage resources
EJBs get access to external resources (databases, legacy systems) through their container
Programmer does not have to worry about resource allocation and de-allocation
It is the container’s job to manage these resources, and make the access as efficient as possible
Container is configured by system admin not through programming APIs

22. Container supports application developer
Container provides system services
Persistence
Security
Transaction
Connection pooling
Component lifecycle management
Threading
Application developer and deployer specifies his/her requirements in declarative fashion (in deployment descriptor)

23. EJB in a Big Picture of J2EE

24. Where is EJB?
J2EE
Web Tier
EJB Tier DB

25. EJB Architecture
Any distributed component technology should have the following requirements:
1. There should be a mechanism to create the client-side and server-side proxy objects.
A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object.
On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object
2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy.
3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client.

26. These interfaces specify the bean contract to the clients.
In order to meet these requirements, the EJB architecture specifies two kinds of interfaces for each bean.
These interfaces specify the bean contract to the clients.
Interfaces are:
Home interface
The home interface will contain methods to be used for creating remote objects
Extends the javax.ejb.EJBHome
Remote interface
The remote interface should include business methods that a bean is able to serve to clients
Extends the javax.ejb.EJBObject

27. EJB is a layered Architecture consisting of:
EJB Server, which contains the EJB container
Responsible for network connectivity to the container.
EJB Container, which contains enterprise beans.
Uses the Home Interface and Remote Interface
All basic operation of OS
Enterprise bean, which contains methods that implements architecture (Business Logic)

28. EJB Architecture

29. Types of Beans Session Beans Entity Beans Message Driven Beans
Stateful session beans
Stateless session beans
Entity Beans
Bean Managed Persistence (BMP)
Container Managed Persistence (CMP)
Message Driven Beans
JMS
JAXM

30. A bean developer has to specify the home and remote interfaces and also he has to implement one of these bean interfaces depending upon the type of the bean.
For instance, for session beans, he has to implement the javax.ejb.SessionBean interface.
The EJB architecture expects him to implement the methods specified in the bean interface and the methods specified in the home and remote interfaces.
During the deployment time, he should specify the home and remote interfaces and bean implementation class to define a bean.
The EJB container relies on specific method names and uses delegation for invoking methods on bean instance

31. How to invoke a bean instances
EJB container for each bean implement a proxy object to the home interface and publishes in the JNDI implementation of the J2EE platform.
One can use JNDI to look for this and obtain a reference.
As this object implements the home interface only, he can use one of the creation methods of the home object to get a proxy to the remote interface of the bean.
When one invokes a creation method on the home proxy object, the container makes sure that a bean instance is created on the EJB container runtime and its proxy is returned to the client.
Once the client gets hold of the proxy for the remote interface, it can directly access the services of the bean.
Finally, once the client decides to stop accessing the services of the bean, it can inform the EJB container by calling a remote method on the bean.
This signals the EJB container to disassociate the bean instance from the proxy and that bean instance is ready to service any other clients.

32. Session Beans Does work on behalf of a single client
Does not use any persistent storage mechanism.
Is not persistent and hence relatively short lived
Is removed when the EJB server crashes
Does not represent data in data store, although can access/update such data
Bean class implements javax.ejb.SessionBean interface

33. When to Use Session Beans?
Use Session beans to model process or control objects specific to a particular client.
To model workflow, processes or tasks, manage activities (make reservation, purchase...).
To Coordinate processes between entity beans, control interactions of beans
To Move business application logic from Client to the Server Side

34. Stateless: execute a request and return a
2 Types of Session Beans
Stateless: execute a request and return a
result without saving any client specific state information
Transient
Single Method Call
temporary piece of business logic needed by a specific client for a limited time span
Stateful: maintains client specific state
Mutiple Method Call
State Instance Data

35. Examples of Session Beans
Stateless session beans
Catalog
No client specific state needs to be preserved
Interest calculator
Business logic with no need for database access
Stateful session beans
Shopping cart
Items choosen by the client needs to be stored
Method which calculates the price will use.
For displaying the list of books purchased.

36. Stateless Session Bean
Life Cycle of Stateless Session Bean
Does Not Exist
newInstance()
setSessionContext()
ejbCreate()
ejbRemove()
Method -Ready

37. Stateful Session Bean Life Cycle of Stateful Session Bean
Does Not Exist
create()
newInstance()
setSessionContext()
ejbCreate()
remove()
ejbRemove()
ejbPassivate()
Ready
Passive
ejbActivate()

38. Example of Stateless Session Bean
The enterprise bean Consists of the following classes and interfaces:
Remote interface
Import javax.ejb.EJBObject and java.rmi.RemoteException interface.
Access modifier is public
Remote interface name should not be a keyword.
Must Extend from EJBObject interface.
Throws an RemoteException-network failure

39. Home interface EJB class Import Extend EJBHome
java.io.Serializable
Java.rmi.RemoteException
Javax.ejb.CreateException
Javax.ejb.EJBHome
Extend EJBHome
Create() method
With RemoteEXception and CreateException
EJB class
Java.rmi.RemoteEXception
Javax.ejb.SessionBean
Javax.ejb.SessionContext
Implement SessionBean and Remote Interface
Write the following methods
ejbCreate()
ejbRemove()
ejbActivate()
ejbPassive()
setSessionContext()

40. Deployment Descriptor
To mange enterprise bean at run time we use Deployment Descriptor.
Deployment descriptor is an .xml file and contains information about deployment of enterprise bean.
It contains the following information
Then Access Control list (ACL) of the entities authorized to invoke classes or methods.
The name of the EJB class
The name of the EJB home interface
The name of the EJB remote interface
A list of container- managed files if the enterprise bean is an entity bean.
A value specifying whether the enterprise bean is stateful or stateless, in case of a session bean.

41. Example of Stateful Session Bean
Shopping cart, Credit card validator..
You can choose to implement Stateful session bean if:
The bean instance need to be initialized when it is created.
The client application is an interactive one.
The client is likely to invoke multiple method-calls.
The bean needs to store client-specific information across method calls.

42. Entity Beans Provides object view of data in data store
Its lifetime not related to the duration of interaction with clients
Lives as long as data exists in database i.e.Long lived
In most cases, synchronized with relational databases
Shared access among multiple clients
Bean class implements javax.ejb.EntityBean interface.
Used in EJB application where data about business entities such as customers, accounts and products have to stored in database.
Models Persistent data

43. Key Features Persistence Shared Access Primary Key
By storing the state of the bean in the bean
It is done by mapping itself with a row in a table.
Shared Access
Multiple clients can access an entity bean at a particular instant.
Manipulation can be done simultaneously. (transaction management)
Primary Key
Used to identify the bean in the data store by the client. e.g.: product bean-product code.

44. Entity Beans Clients normally look up (find) an existing entity EJB
Creation means adding a row to a database table
Finding means finding a row in a existing database table
Removing means removing a row from a database table

45. 2 Types of Entity Beans CMP (Container Managed Persistence)
Persistence is managed by Container
Persistence requirements are specified in deployment descriptor
Bean developer does not have to worry about providing persistence logic in his code
BMP (Bean Managed Persistence)
Persistence logic code is provided by Bean developer

46. Terminologies to be known
Table Relationship
One to One
One entity related to one occurrence
One to Many
One entity related to many occurrence
Many to Many
Every entity related to many occurrence
Transaction
Single Atomic Operation in series of steps.
Successful only when all steps within it will execute
Commit or rollback
ACID
Persistent
Declarative and programmatic transaction
Authorization
Ensure that clients are authorized to perform operation
Declarative and programmatic authorization
isCallerInRole() & getCallerIdentity()
Security Exception
System and Application Exception
Database connectivity & Logical Error Respectively

47. Examples of Entity Beans
Customer
Customer data has to persist, thus is maintained in the database
Customer data has to survive server crash
Customer data is shared by many clients
Each customer has unique identification such as customer number

48. When to Use CMP vs. BMP? CMP BMP entity beans Database independence
Higher performance
Easy to develop and deploy
BMP entity beans
More programmatic control is desired

49. Life cycle of Entity Bean
Does Not Exist
newInstance()
setEntityContext()
unsetEntityContext()
Pooled
Create()
ejbCreate()
ejbPostCreate()
remove()
ejbRemove()
ejbActivate()
ejbPassivate()
Ready

50. Session Beans and Entity Beans

52. Message-Driven Beans (MDB)
Acts as a consumer of asynchronous messages
Cannot be called directly by clients
Activated upon message arrival
No home or remote interface
Clients interact with MDB by sending messages to the queues or topics to which they are listening
Stateless