The Enterprise Java Beans Component and container

The Enterprise Java Beans Component and container

The Enterprise Java Beans Component

An Enterprise JavaBean is a component, just like a traditional JavaBean. Enterprise
JavaBeans execute within an EJB container, which in turn executes within an EJB server.
Any server that can host an EJB container and provide it with the necessary services can
be an EJB server. EJB is a Java class, written by an EJB developer, that implements
business logic. All the other classes in the EJB system either support client access to or
provide services (like persistence, and so on) to EJB component classes.

The Enterprise Java Beans Container

The EJB container acts as an interface between an Enterprise bean and clients. The client
communicates with the Enterprise bean through the remote and home interfaces provided
by the customer. The EJB container is where the EJB component "lives." Since the EJB
container handles all these functions, the EJB component developer can concentrate on
business rules, and leave database manipulation and other such fine details to the
container. The EJB container provides services such as security, transaction and resource
management, versioning, scalability, mobility, persistence, and security to the EJB
components it contains.

EJB Server

The EJB server provides some low level services like network connectivity to the
container. In addition to this, it also provides the following services:

• Instance Passivation
• Instance pooling
• Database Connection Pooling
• Preached Instances

The EJB Object and the Remote Interface


Client programs execute methods on remote EJBs by way of an EJB object. The EJB
object implements the “remote interface” of the EJB component on the server. The remote
interface represents the “business” methods of the EJB component. The remote interface
does the actual, useful work of an EJB object, such as creating an order form or referring
a patient to a specialist.

EJB objects and EJB components are separate classes, though from the outside (i.e., by
looking at their interfaces), they look identical. This is because, they both implement the
same interface (the EJB component's remote interface), but they do very different things.
An EJB component runs on the server in an EJB container and implements the business
logic. The EJB object runs on the client and remotely executes the EJB component's
methods.

3) The EJB component architecture is the backbone of the J2EE platform. The EJB
architecture provides the following benefits to the application developer

• Simplicity: It is easier to develop an enterprise application with EJB
architecture than without it. Since, EJB architecture helps the application
developer access and use enterprise services with minimal effort and time,
writing an enterprise bean is almost as simple as writing a Java class.
• Application Portability: An EJB application can be deployed on any J2EEcompliant
server. Application developer can choose the "best-of-breed"
application server that meets their requirements.
• Component Reusability: An EJB application consists of enterprise bean
components and each of the enterprise Bean is a reusable building block.
Business logic of enterprise beans can be reused through Java sub classing of
the enterprise bean class.
• Ability to Build Complex Applications: EJB architecture simplifies building
complex enterprise applications. The component-based EJB architecture is well
suited to the development and maintenance of complex enterprise applications.
• Separation of Business Logic from Presentation Logic: An enterprise bean
typically encapsulates a business process or a business entity (an object
representing enterprise business data), making it independent of the
presentation logic.
• Easy development of Web Services: The Web services features of the EJB
architecture provide an easy way for Java developers to develop and access
Web services. The tools provided by the container manage the mapping to the
Web services standards

• Deployment in many Operating Environments: The EJB architecture allows
the bean developer to separate common application business logic from the
customisation logic performed at deployment to me. The EJB architecture
allows an entity bean to be bound to different database schemas. The EJB
architecture facilitates the deployment of an application by establishing
deployment standards, such as those for data source lookup, other application
dependencies, security configuration, and so forth.
• Distributed Deployment: The EJB architecture makes it possible for
applications to be deployed in a distributed manner across multiple servers on a
network.
• Application Interoperability: The EJB architecture makes it easier to integrate
applications from different vendors. The enterprise bean's client-view interface
serves as a well-defined integration point between applications.
• Integration with non-Java systems: The related J2EE APIs, such as the J2EE
Connector specification and the Java Message Service (JMS) specification, and
J2EE Web services technologies, such as the Java API for XML-based RPC
(JAX-RPC), make it possible to integrate enterprise bean applications with
various non-Java applications, such as ERP systems or mainframe applications,
in a standard way.
• Educational Resources and Development Tools: Because EJB architecture is
an industry wide standard, the EJB application developer benefits from a
growing body of educational resources on how to build EJB applications

Benefits to Customers

A customer’s perspective on EJB architecture is different from that of the
application developer. The EJB architecture provides the following benefits to the
customer

• Choice of Server: Because the EJB architecture is an industry wide standard
and is part of the J2EE platform, customer organisations have a wide choice of
J2EE-compliant servers. Customers can select a product that meets their needs
in terms of scalability, integration capabilities with other systems, security
protocols, price, and so forth.
• Facilitation of Application Management: Sophisticated application
management tools provided with the EJB container allow the customer's IT
department to perform such functions as starting and stopping the application,
allocating system resources to the application, and monitoring security
violations, among others.
• Integration with a Customer's Existing Applications and Data: EJB
architecture and the other related J2EE APIs simplify and standardize the
integration of EJB applications with any non-Java applications and systems at
the customer operational environment.
• Integration with Enterprise Applications of Customers, Partners, and
Suppliers: The interoperability and Web services features of the EJB
architecture allow EJB-based applications to be exposed as Web services to
other enterprises.
• Application Security: EJB architecture shifts most of the responsibility for an
application's security from the application developer to the server vendor,
system administrator, and the deployer

4) EJB container offers various kinds of services. Transaction Management is the most
important functionality served by the container. The container provides the support
according to the transaction specified and we can specify following types of
transaction support for the bean:

• The bean manages its own transaction
• The bean doesn’t support any transaction.
• When the client invokes the bean’s method and if, the client has a transaction in
progress, then the bean runs within the client’s transaction. Otherwise, the
container starts a new transaction for the bean
• The bean must always start a new transaction, even if a transaction is open.
• The bean requires the client to have a transaction open before the client invokes
the bean’s method.

Persistence is another important function, which is supported by the EJB container.
Persistence is the permanent storage of state of an object in a non-volatile media.
This allows an object to be accessed at any time, without having to recreate the
object every time it is required. The container if desired can also maintain persistent
data of the application

.5) Enterprise Java Beans have several restrictions, which they must adhere to:

1. They cannot create or manage threads.
2. They cannot access threads using the java.io package.
3. They cannot operate directly with sockets.
4. They cannot load native libraries.
5. They cannot use the AWT to interact with the user.
6. They can only pass objects and values, which are compatible with RMI/IIOP.
7. They must supply a public no argument constructor.
8. Methods cannot be static or final.
9. There are more minor restrictions

 6) Session Beans and Entity beans differ in respect to object sharing, object state,
transactions and container failure and object recovery. 

Object Sharing: A session object can be used by only one client whereas, an entity
object can be shared by multiple clients. A client may pass an object reference to
another client.

Object State: Object state of stateful session bean is maintained by the container
in the main memory across transactions and swapped to secondary storage when
deactivated whereas, the object state of an entity bean is maintained in the database
or other resource manager and typically cached in the memory in a transaction.

Failure Recovery: A session object is not guaranteed to survive failure and restart
of its container. The references to session objects held by a client become invalid
after the failure whereas, an entity object survives the failure and the restart of its
container. A client can continue using the references to the entity objects after the
container restarts

 7) There could be various guidelines, which can assist application developer choose
between a session bean and entity bean, which are described below:

• A bean developer may typically implement a business entity as an entity bean.
• A bean developer may typically implement a conversational business process as
a stateful session bean. For example, developers implement the logic of most
Web application sessions as session beans.
• A bean developer typically implements as an entity bean a collaborative
business process: a business process with multiple actors.
• If, it is necessary for any reason to save the intermediate state of a business
process in a database, a bean developer implements the business process as an
entity bean. Often, the saved state itself can be considered a business entity.