Download - EJB 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.
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
lifecycle.
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
Remote interface
Home interface
Client class
Server class
Deployment descriptor
JNDI(java naming and directory
interface)
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.
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.
New in EJB 2
1. Container managed Persistence
2. EJB Query Language
3. Message-Driven Beans
4. Local client view
5. Improved interoperability
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.
• 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
public abstract EmployeeBean implements javax.ejb.EntityBean { // instance fields
EntityContext ejbContext;
// container-managed persistent fieldspublic 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 fieldspublic abstract void setContactInfo(ContactInfoinfo); public abstract ContactInfo getContactInfo(); ... }
• 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.
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(); ... }
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.
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.Suchprotocols 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.
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.
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.
protocol based on RMI/IIOP and
CORBA to allow J2EE applications on
different app servers to interact
without bean developer intervention
The standard component architecture for building distributedobject-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).
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
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
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
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.
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
• 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
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
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.