Enterprise JavaBeans
What is EJB?
EJB is a server-side component framework that simplifies the process of building the enterprise-class distributed component applications in java.
By using EJB, you can write scalable, reliable, and secure applications without complex distributed component framework.
EJB is a component.
EJB is a standard for developing & deploying server-side distributed components in java.
EJB involves a standardized agreement that enables a component to run within any application server (increasing code reuse).
The agreement is accomplished by implementing a set of Java interfaces from the EJB API.
EJBs are not GUI components.
Advantages
Many vendor application servers conform to the J2EE specification allowing one to select a best-of-breed solution.
To handle fluctuations in resource demand server-side resources can easily be scaled by adding or removing servers.
Application servers provide access to complex services, namely transaction and security management, resource pooling, JNDI, component lifecycle management, etc.
Disadvantages
EJB has a large and complicated specification.
EJBs take longer to develop.
Also, when things go wrong they can be more difficult to debug.
Occasionally the bug may not be in your code but in the application server itself.
No sooner have you deployed your EJB application than you see a new specification coming down the pipe with newer features, rendering your application obsolete.
- when there is no need for scalability, transaction management, or security.
if you anticipate low numbers of read-only users.
if your team lacks EJB experience or cannot quickly obtain that experience.
The EJB learning curve is steep and overcoming it can easily derail an otherwise viable project.
For an EJB deployment up and running, needs more than an application server and components.
There are six more parties that are involved:
- The Bean provider
The Application Assembler
The EJB Deployer
The System Administrator
The Container and Server providers
The Tool Vendors (IDEs)
Session Beans
- Session EJBs are function-oriented components
They represent a set of behaviors that reside on a server and can be invoked by clients.
Represent business processes to be performed
They implement business logic, business rules, algorithms, and work flows
Their lifetime is equivalent to a client session
Session Beans can’t survive when application server crashes or machine crashes
A session bean can perform database operations, but session beans themselves are not persistent.
There are two sub-types of Session EJBs,
Stateless Session EJBs and Stateful Session EJBs.
Stateless Session Beans
Represents a set of related behaviors (methods) that do not retain client-specific states between invocations.
Stateless session beans can possess instance variables, but those variables must be shared among multiple potential clients (e.g., they should be
read-only).
The EJB specification allows some flexibility in the design of an EJB Server such that each method call to a single EJB client stub for a Stateless Session EJB
may be directed to a different instance of a Stateless Session EJB
Possibly each residing on a different physical machine.
This allows the EJB server to be flexible in its approach to workload management, providing safety and scalability.
These can serve business requests that span only a single method invocation
Stateful Session Beans
Each Stateful session EJB is "owned" by a single client stub and is uniquely connected to that stub.
Stateful session EJBs may retain client state across method invocations by the same client.
That is to say, a client may call a method that sets a variable value in one method and then be assured that another, later, method invocation to retrieve that value will retrieve the same value.
Stateful session beans are usually developed to act as agents for the client, managing the interaction of other beans and performing work on behalf of the client application
Like ATM Transactions-balance, fund transfer, or making a withdrawal
Entity Beans
Entity Beans model data entities and provide shared distributed transactional access to persistent data.
Entity Beans provide concurrent shared access to multiple users.
An individual Entity EJB represents a single persistent entity -- for instance a row in a relational database (RDB).
In contrast, Session EJBs model businesses processes and provide exclusive access to a single client either for a length of a method (in the stateless case)
or for the life of the bean (in the Stateful case).
There are two basic subtypes of Entity EJBs:
Container-Managed Persistence (CMP)
Entity EJBs
Bean-Managed Persistence (BMP) Entity EJBs.
CMP
CMP entities are those whose persistence (for example, the storing and retrieving of their data from a backing store like an RDB) is managed by the EJB container.
This means that the container would, for instance, manage both generating and executing SQL code to read and write to the RDB.
CMP allows multiple entity beans to have container-managed relationships among themselves
You can designate instance variables to be container-managed persistence fields (cmp fields) or container-managed relationship fields (cmr fields).
You define these cmp and cmr fields in the deployment descriptor or throug getter/setter methods defined in bean
BMP
- Bean-managed persistence is more complicated than container-managed persistence because you must explicitly write the persistence logic into the bean class.
Bean-Managed Persistence (BMP) EJBs leave the management of such details as what SQL is executed to the developer of the EJB.
Bean-managed persistence gives you more flexibility in how state is managed between the bean instance and the database eg. complex joins, a combination of different databases, or other resources such as legacy systems will benefit from bean-managed persistence.
Each BMP EJB is responsible for storing and retrieving its own state from a backing store in response to specific "hook" messages (like ejbLoad() and ejbStore()) that are sent to it at appropriate times during its lifecycle.
Message Driven Beans
Message-Driven Beans are enterprise beans that allow applications to process messages asynchronously.
Act as a JMS message listener, which is similar to an event listener, except that it receives messages instead of events.
The most visible difference between message-driven beans and session or entity beans is that clients do not access message-driven beans through interfaces.
A message-driven bean's instances retain no data or conversational state for a specific client .
A single message-driven bean can process messages from multiple clients
All bean classes must implement javax.ejb.EnterpriseBean, or one of its subinterfaces, at some level.
javax.ejb.EnterpriseBean extends java.io.Serializable.
Session beans implement javax.ejb.SessionBean.
javax.ejb.SessionBean extends javax.ejb.EnterpriseBean.
It defines methods: ejbActivate, ejbPassivate, ejbRemove, and setSessionContext.
Entity Beans implement javax.ejb.EntityBean.
javax.ejb.EntityBean extends javax.ejb.EnterpriseBean.
It defines methods: ejbActivate, ejbPassivate, ejbRemove, setEntityContext, ejbLoad, ejbStore, and unsetEntityContext.
Message Driven Beans implement javax.ejb.MessageDrivenBean.
javax.ejb.MessageDrivenBean extends javax.ejb.EnterpriseBean.
It defines methods: ejbRemove and setMessageDrivenContext.
EJB Components
- EJB Object
Remote Interface
Home Object
Home Interface
Local Interfaces
Deployment Descriptors
EJB-JAR file
No comments:
Post a Comment