- Components are deployable units that provide a business service to their clients.
-
It is reusable piece of code and free from the surroundings., Component services can be used as a part of business logic of other components.
-
Components are operation independent of
-
Hardware
-
The underlying operating system
-
Their Application Server
-
The network protocol they use
Each component provides an interface in the form of operations, properties and events
-
Components can be developed in any language such as JAVA, C++, VB
-
Components are frequently organized into application frameworks for vertical domains.
-
If multiple clients are using a component simultaneously, the component will provide the same quality of service to all the clients. [ So, Components are Shareable. ]
-
Components should provide services to clients running locally or remotely.

SelfContained Components
-
Components should only contain the code necessary to implement their services,
-
Infrastructure services should be injected by the execution environment
Standard infrastructure services include
-
Directory Services
-
Distributed transaction management
-
Security management
-
Concurrent access management
-
Persistence management
-
Resource pooling (e.g. DB connections)
-
Administration interface
-
Load Balancing
-
Fault tolerance
Note :- An application server provides the infrastructure and services to run components/applications.
-
The server-side components deployed on the application servers can be implemented using various technologies, such as EJB and Microsoft’s COM/DCOM.
-
Enterprise JavaBeans are different from JavaBeans,
-
OR we can say Sun Microsystems component based technology.
-
EJB is a standard for developing and deploying server side distributed component in java.
-
It defines an agreement between component and application servers that enables any component to run in any compliant Application Server.
Three Main value proposition of EJB
-
It is a ubiquitous industry standard
-
Portability is possible
-
Rapid application development
Examples of real-life applications where you can use the EJB component architecture are:
-
Online share trading application
-
Online reservation application
-
Online Banking application
-
Online library application
Enterprise JavaBeans were quickly adopted by large companies.
EJB used when
-
Remoting is Required
-
Distributed Transaction is Required (2PC Commit)
-
Component Security is Required
-
Persistence is Required
-
Integration with Legacy application is Required
-
Scalability is Required.
-
the application will have a variety of clients
-
EJB Survives in EJB Container like fish survives only in Water.
-
EJBs are deployed in an EJB container within the application server.
-
The J2EE server consists of containers to provide the runtime environment for different J2EE components.
-
The EJB container stores the enterprise beans that implement the business logic of enterprise-level applications.
EJB container provides various services:
-
Persistence: EJB container manages the persistence of data for enterprise beans that are declared as Container Managed Persistence (CMP).
-
Transaction management: EJB container manages the transactions for different enterprise beans of an EJB application. A transaction is a set of operations that is executed as a single unit.
-
Security: EJB container provides security by allowing only authorized clients to access enterprise beans.
-
Life cycle management: EJB container manages the life cycle of an enterprise bean and is responsible for changing the state of an enterprise bean as per client requests.
-
Database connection pooling: EJB container creates a pool of database connections and allocates these connections to the enterprise bean as and when required.
-
Remote client connectivity: EJB container allows clients at remote locations to access methods of an enterprise bean stored in the J2EE Server.
-
EJB 1.0 (1998-03-24)
-
EJB 2.0, final release (2001-08-22)
-
EJB 2.1, final release (2003-11-24)
-
EJB 3.0, final release (2006-05-11)
-
EJB 3.1, final release (2009-12-10) : The purpose of the Enterprise JavaBeans 3.1 specification is to further simplify the EJB architecture by reducing its complexity from the developer’s point of view.

Note :- EJB 3.0 made it much easier to write EJBs, using ‘annotations’ rather than the complex ‘deployment descriptors’ used in version 2.x. The use of home and remote interfaces and the ejb-jar.xml file were also no longer required in this release, having been replaced with a business interface and a bean that implements the interface.
Note:- Legacy (deprecated) beans:Previous versions of EJB also used a type of bean known as an Entity Bean. These were distributed objects having persistent state. Beans in which their container managed the persistent state were said to be using Container-Managed Persistence (CMP), whereas beans that managed their own state were said to be using Bean-Managed Persistence (BMP). Entity Beans were replaced by the Java Persistence API in EJB 3.0, though even in EJB 3.1, CMP 2.x style Entity beans are still available for backward compatibility.
There are three types of Enterprise Java Beans namely:
-
Session Beans
-
Entity Beans
-
Message driven beans

-
EJB home interfaces extends javax.ejb.EJBHome
-
EJB home interfaces provide operations for clients to
-
create EJBs
-
remove EJBs
-
find handles to EJB remote interface objects
-
have its stub placed into JNDI at startup

-
EJB remote interfaces extends javax.ejb.EJBObject
-
EJB remote interfaces
-
provide business-specific functionality of an EJB
-
are similar to RMI Remote interface

-
EJB implementation
-
Class in which EJB developer codes the business methods defined in the bean’s component interface(s) to provide any application specific
-
business method invocation
creation
-
removal
-
finding
-
activation
-
passivation, database storage
-
database loading logic

EJB clients
-
utilizes the Java Naming and Directory Interface (JNDI) to look up for the references to home interfaces
-
use home and remote EJB interfaces to utilize all EJB-based functionality
-
The PortableRemoteObject.narrow( ) method was first introduced in EJB 1.1 and continues to be used on remote clients in EJB 3.0. It is needed to support the requirements of RMI over IIOP(Internet Inter-Orb Protocol which delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java 2 platform).
-
Because CORBA supports many different languages, casting is not native to CORBA (some languages don’t have casting). Therefore, to get a remote reference to myLoarRemote, we must explicitly narrow the object returned from lookup( ).




Architecture in Details


This post will help the internet visitors for building up new blog or even a weblog from start to end.