/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsS. Gokul
What are EJBs?
Enterprise Javabeans are scalable, distributed server side Java components that
embody business logic rules and mechanisms in a J2EE platform based enterprise
application. EJB Specifications were released as a part of Java 2 for Enterprise
Edition (J2EE) specifications and standards.
EJBs are distributed — in the sense, they can reside on any application
server — either within the enterprise or even outside the enterprise. Thus, an
application built for J2EE standards can make use of EJBs that reside even
outside the home server — theoretically, across any compatible platforms,
anywhere in the world !
EJBs reside on what are called EJB containers. Applications that want to make
use of EJB services, can avail the same - only through EJB containers. In other
words, an EJB container acts as a broker in between EJBs and EJB Clients —
taking the inputs from the clients, processing them through the services
available in EJBs and sending the processed results back to clients. Apart from
security issues, this intercession of containers is to manage low level system
tasks like memory caching, pooling and ensuring availability of EJBs to the
clients. In fact, one of the core purposes behind the EJB specification is to
enable developers concentrate on developing business logic, instead of writing
complex codes for handling low level functions — in a distributed environment.
Currently, EJBs can be written only in Java language.
Ideas behind EJB specification
The core concept of introducing EJB specification in the enterprise applications
environment, is to enable developers and architects to evolve self contained
business logic rules of the enterprise as distributed components. Once a
business rule is satisfactorily wrapped up in an EJB, with its multiple facets,
then it can be reused again and again — in various applications. For example,
the enterprise as a whole can end up with a single login EJB — that will
authenticate the users with the Enterprise Information Systems tier. This is in
striking contrast to the current scenario in which literally every other
application in the enterprise will make use of its own logic for user
authentication.
Apart from cutting down the development costs several times by rigorous reuse
of components, this approach also ensures flexibility in adopting newer business
rules easily. For example, it is relatively easy to change the login rules in a
single EJB — rather than peeking into every enterprise application and doing
the necessary changes.
Another idea is to enable a business manager to buy business components off
the shelf — so that he can cut down the development costs several times. This
also helps him to have a wide variety of choices — instead of limiting himself
to the offerings of his development team. For example, a company that is
involved in the insurance business can buy EJBs from various vendors who offer
specialized EJBs that encapsulate core insurance functionality. Theoretically,
he can even purchase these enterprise beans from more than one vendor and still
ensure that the overall functionality of the system remains unaffected.
Such off-the-shelf EJB components can be constructed in such a way that they
can be adopted to different business environments. The core object oriented
methodologies — that lie at the foundation of server side Java development and
J2EE spec — take the credit of enabling such a magical flexibility.
To ensure consistency among the developers, vendors and purchasers of EJBs,
Sun Microsystems has introduced certain testing and certification methodologies
that can guarantee that the EJBs adhere to those specifications advocated by
J2EE.
EJB development process
Every EJB is supposed to perform certain well defined set of tasks. Thus, the
overall set of tasks that are to be performed by an application should be
clearly laid out before constructing the beans. Then, repetitive tasks should be
identified against specific tasks, which are specialized mechanisms for a given
applications. The idea is to construct EJBs for repetitive tasks separately —
so that they can be reused elsewhere within the application or by other
applications. An enterprise’s efforts should be driven with focus — with
several teams working in close association with each other to ensure cohesive
application development as well as to avoid concurrency issues.
An EJB can work with several other EJBs to perform a single business
assignment. In this case, an EJB itself becomes the client of another EJB !
While calling other EJBs, an EJB assumes nothing about its location or
container. Thus, theoretically, EJBs can communicate across server and
geographic boundaries. The fundamental RMI layer that is beneath the EJB
architecture allows applications to treat — even remote objects — as local
objects on the same server. Thus, EJBs should assume nothing about the type of
clients! It can be any remote call from any other server.
Application assembly
In an ideal scenario that is envisioned by the EJB architects, EJBs for specific
businesses will be sold by many vendors. Similarly, there will be many players
who provide the J2EE implementation platform (along with their own EJB
container) — in the form of Web Application Servers — wherein these EJBs can
reside. All the enterprises need to do is to purchase the relevant set of EJBs
for their business and deploy them on the J2EE Server platform.
EJBs will be purchased or developed, assembled and reused depending upon the
application(s) under development. This process will be called Application
assembling and specialized expertise would be required to perform this exercise.
Of course, the decision to purchase or develop the EJBs for a particular
application would be the discretion of the Project Manager.