Enterprise Java Beans 2

2. WHAT IS EJB??
 Enterprise JavaBeans (EJB) is a managed,
server-side component architecture for modular
construction of enterprise applications.
 EJB is a server-side model that encapsulates the
business logic of an application.
 The EJB specification was originally developed
in 1997 by IBM and later adopted by Sun
Microsystems (EJB 1.0 and 1.1) in 1999.

3.  The EJB architecture.
 An EJB component is a reusable
WORA.
 The EJB architecture makes
enterprise application (transaction
management, security management,
multithreading management)
 The EJB architecture also supports
WORA and portable solution.
 manages the EJB component

5.  enterprise bean is a distributed
 lives in an EJB container
 accessed by remote clients
 enterprise beans on the same
server
 a remotely executable component
 deployed on its server and it is
self-descriptive

6.  Remote interface
 Home interface
 Client class
 Server class
 Deployment descriptor
 JNDI(java naming and directory
interface)

7.  The bean developer is responsible for declaring the
bean class' persistent fields as either Java primitive
or serializable types.
public class Address implements Serializable{
public String street;
public String city;
public String state;
public String zip;
}
 Bean developer responsible for declaring the persistent fields in the
bean class.
 On an RDBMS primitive types(String, integer etc) map easily to
their corresponding types
 Tell the container through the deployment descriptor (DD). The
<cmp-field> tags identify such fields.
 Generally container tools allow you to map.

9.  There is no standard way of mapping serializable objects
to a relational database. Although the Address class has its
own set of fields, the XML deployment descriptor doesn't
provide a mechanism for mapping those fields to the
database. In most cases it was expected that serializable
objects such as Address would be persisted as a binary type,
which is sometimes called a blob type, to a database table.
 That problem is make worse as the entity bean's data
schema grows in complexity.
 For entity beans with a large schema problem grows. As an
entity bean may have many dependent objects which in turn
have dependent objects forming complex graphs.
 Entity bean to Entity bean relationship support not adequate.
Since it always uses the other EB’s primary key as a link.
Relationships are not always based on the primary key.

10.  New in EJB 2
1. Container managed Persistence
2. EJB Query Language
3. Message-Driven Beans
4. Local client view
5. Improved interoperability

11. i. The most important changes in the specification are those
made to container-managed persistence (CMP) and the
introduction of a completely new bean type, the
MessageDrivenBean.
ii. When the bean is deployed, you will use persistent
manager tools to generate a concrete implementation of the
abstract bean class and its dependent object classes based
on the XML deployment descriptor and the bean class. The
concrete implementations will include the data access code
that will actually read and write the bean's state to the
database at runtime. At runtime, the container uses the
subclasses generated by the persistence manager tools
instead of the abstract classes defined by the bean
provider.

12. Container Managed
Persistence

13. • Allows you to define complex bean-to bean, bean to
dependent object and dependent to dependent object
relationships.
• Done with the help of new “PERSISTENCE MGR”
• Contract between container and Persistence Mgr.
• Contract known as Abstract Schema has two parts
 Additional XML tags in DD
 Code idioms (Rules for coding the bean )
• The bean class is declared abstract and all persistent and
relationship fields are accessed using abstract accessor
and mutator methods whose signatures map to special
elements in the DD

14. public abstract EmployeeBean implements
javax.ejb.EntityBean {
// instance fields
EntityContext ejbContext;
// container-managed persistent fields
public abstract void setIdentity(int identity);
public abstract int getIdentity();
public abstract void setFirstName(String
firstName);
public abstract String getFirstName();
public abstract void setLastName(String lastName);
public abstract String getLastName();
// container-managed relationship fields
public abstract void setContactInfo(ContactInfo
info);
public abstract ContactInfo getContactInfo();
... }

15. • They form relationships with entity beans
• live and die along with the entity bean
• only visible to the bean class and not the client
• Bean class must have additional methods to expose
dependent objects to the client since they are not suitable
remote arguments.

16.  A dependent object ( class)………..
public abstract class ContactInfo {
// home address info
public abstract void setStreet(String street);
public abstract String getStreet();
public abstract void setState(String state);
public abstract String getState();
public abstract void setZip(String zip);
public abstract String getZip();
public abstract void setHomePhone(String phone);
public abstract String getHomePhone();
// work address info
public abstract void setWorkPhone(String phone);
public abstract String getWorkPhone();
public abstract void setEMail(String email);
public abstract String getEMail();
...
}

17.  Formerly developer provided a description of what
the finder methods should do . Deployer provided
the actual query according to the target Application
Server. Advantages of EJB QL
◦ Query need be developed and tested only once (
not at each new environment)
◦ Developer can do it .More suited for the purpose.

18.  Integration of EJB with Java Message Service (JMS). Container on
arrival of a JMS message invokes a “message-driven bean”. Need
not create a separate front-end for messages.
 The Message Driven Bean is used among others to provide a high
level ease-of-use abstraction for the lower level JMS (Java Message
Service) specification
 Message Driven Beans can support other messaging protocols.Such
protocols may be asynchronous but can also be synchronous.
 Examples
 Sending a configuration update to multiple nodes might be done by
sending a JMS message to a 'message topic' and could be handled
by a Message Driven Bean
 Submitting a job to a work cluster might be done by sending a JMS
message to a 'message queue' and could also be handled by a
Message Driven Bean,
 the Quartz scheduler can be handled by a Message Driven Bean;
when a Quartz trigger fires, the MDB is automatically invoked.

19.  An MDB component works in the following way:
1. The container registers this MDB component with
JMS.
2. The JMS registers all JMS destinations (Topic for
broadcasting or Queue for PTP) with Java Naming
and Directory Interface(JNDI).
3. The EJB container instantiates this MDB component.
4. The client looks up the destination with the MDB.
5. The client sends a message to the destination.
6. The EJB container selects the corresponding MDB to
consume the message.

20. WORKING:

21.  Unlike the remote client view, the local client view of a bean is
location dependent.
 Local client view access to an enterprise bean requires both
the local client and the enterprise bean that provides the local
client view to be in the same JVM.
 Local interfaces and local home interfaces provide support for
lightweight access from enterprise beans that are local
clients. Session and entity beans can be tightly coupled with
their clients, allowing access without the overhead typically
associated with remote method calls. The local client view
consists of two interfaces:
 Local interface: The local interface is a lightweight version of
the remote interface, but for local clients. It includes business
logic methods that can be called by a local client.
 Local home interface: The local home interface specifies the
methods used by local clients for locating, creating, and
removing instances of enterprise bean classes.

22.  protocol based on RMI/IIOP and
CORBA to allow J2EE applications on
different app servers to interact
without bean developer intervention

23.  The standard component architecture for building distributed
object-oriented business applications in Java.
 Make it possible to build distributed applications by combining
components developed using tools from different vendors.
 Make it easy to write (enterprise) applications: Application
developers will not have to understand low-level transaction
and state management details, multi-threading, connection
pooling, and other complex low-level APIs.
 Will follow the "Write Once, Run Anywhere" philosophy of
Java.
 Address the development, deployment, and runtime aspects
of an enterprise application’s life cycle.
 Define the contracts that enable tools from multiple vendors
to develop and deploy components that can interoperate at
runtime.
 Compatible with existing server platforms
 Compatible with other Java APIs.
 Compatible with the CORBA protocols (RMI-IIOP).

24.  Complex schemas involving relationships among entity beans
and dependent objects can be depicted with the help of
persistence manager.Closer to intuition and better database
design and use.
 Business methods in the home interface provide option for
better design by isolating business logic completely within
the entity.
 Entity beans can communicate using JMS at the business
logic level itself --one more for better design .
 New EJB QL makes standardized query possible and relives
deployer.Helps in correct creation of finder method queries.
 Tightened some unresolved issues of 1.1

25.  Implement a lot of artifacts such as home interfaces ,
callback methods, remote interfaces
 Use only one business interface per EJB bean
 Follow a lot of conventions when building enterprise
beans such as using RMI conventions, using specific
base interfaces
 Abide to a different scheme when developing EJBs
compared to developing regular Java classes and
interfaces
 Configure beans and applications with giant XML
based deployment descriptors
 Introduce dependencies to the environment
 Deal with the complexities of persistence
 Manually introduce tracing, logging and other
homegrown
 methods to test components
 Manually locate and use beans as clients

26.  Use Meta-Data
 Use Dependency Injection
 Reducing the number of artifacts
developersmust provide
 Configuration by exception
 Reducing environmental dependencies
 Simplification of EJB types
 Getting rid of many interfaces
 Simplification of persistence
 Improved testing outside of the container

27.  Using POJOs (Plain Old Java Object) and POJIs (Plain Old Java
Interface)
 Business Interface as Java interface
 No more home interface
 Using metadata annotations for configuration of EJB Type, Local/Remote,
Transactions, Security
 Minimize the bean-specific configuration requirements
 The deployment descriptor can also be used to specify a bean as
message-driven.

28.  The bean class now serves as the main programming artifact
 Home interfaces have disappeared
@Stateful public class ShoppingCartBean
implements ShoppingCart
{
public int add(long item){…}
public void remove(int id){…}
}
public interface ShoppingCart {
public int add(long item);
public void remove(int id);
}
 Bean class methods may throw application exceptions
 They should not throw java.rmi.RemoteException

29. • Implement plain Java business interfaces
 Do not provide a homeinterface
• Comprise an implementation class annotated with@Stateless
• Callbacks defined @PostConstruct, @PreDestroy andexecuted in unspecified
security, transaction context
• Interceptors might be applied
• Dependency Injection before first business method execution

31.  Empowers developers due to more possibilities
 Increases productivity by reducing required
artifacts, configuration by
 exception, dependency injection, annotations
 Much easier to handle through POJOs and POJIs
 Developers might use deployment descriptor or
annotations or both
 Extensibility of container using callback concept

32.  EJB 1.0 provides the basic functionality of Enterprise beans but has
some flaws to cover up those flaws EJB 2 was introduced
 Enterprise Java Bean 2.0 embodies some fantastic changes from
the previous specification. The new CMP model is far more flexible
than the previous model, allowing entities to model complex object
graphs while providing for more portability across containers and
the new MessageDrivenBean
 EJB 2 had many dependences like home interface must implement
EJBHome in order to provide services in order to reduce
dependency EJB 3 was introduced.