Comparing servlets and EJBs
- By Max Dolgicer, Gerhard Bayer, Michael Bardash
This table compares and contrasts the servlets and EJBs, and provides a more
detailed insight into how they stack up against each other using a set of
model (client connects via Web server only)
* Web-centric model (via presentation gateway, e.g., HTML
* LAN-based model (clients access services over LAN or WAN via
remote method invocations without any intermediary)
* Local (several tiers of
services collocated within a single host, either in intra- or inter-process
EJB permits for much more flexible deployment
topographies. Web server is not a prerequisite.
* RMI and/or CORBA
* IIOP HTTP tunneling
Value-added proprietary protocols such as t3
HTTP is a stateless protocol optimized for request-reply
style text transfer. An attempt to engage it for generic use, such as may be
required by common cooperation metaphors like stateful session, involves
significant overhead and is not trivial to implement. On the other hand,
technologies like RMI and CORBA are specifically optimized for distributed
computing and easily account for a variety of cooperation metaphors. HTTP
tunneling allows circumventing a firewall in cases when direct client access is
Transactions must be coordinated manually through integration with JTS.
client cannot easily pass transaction context to a servlet.
* Attempt to
allow a single transaction to spawn multiple servlet invocations is at least
* All transaction functions are performed by the container
implicitly on behalf of an EJB, including context propagation and transaction
demarcation. However, the bean is not precluded from taking full control over
* Transaction rules are declarative in nature and can
be changed at deployment time.
Though a servlet can ultimately be made as transactional
as an EJB, this attempt will involve significant effort, both at design and
development times. EJB strongly relieves these concerns.
There is no security
mechanism readily available to servlets. Rudimentary access security is managed
by the servlet engine in a superficial manner (in most cases, limited to
differentiating between trusted and untrusted modes).
Comprehensive security mechanism is managed by the server.
EJBs are instantiated into security context and service invocations are
authorized against access control lists. Security definition is declarative and
defined at deployment time.
In a Web-centric environment, both standards benefit
from technologies like SSL and digital certificates. But implementation of these
features is not mandated by either standard and is left to the discretion of
specific products. Most app servers and servlet engines (especially those
embedded in app servers) support an end-to-end Web security model.
mechanism exists to provide for servlet persistence, though of course nothing
prevents a servlet from implementing persistence on its own by explicitly
integrating with JDBC.
EJB allows persisting objects automatically. Support for
this comes from two angles. Introspecting the bean can automatically generate
database schemas. Container-provided life-cycle management automatically
passivates and activates objects as needed and provides for synchronization of
EJB state with the database.
OBJECT IDENTIFICATION AND CONTEXT
To identify a Servlet into context
(such as in the case of a session context, for example) requires explicit
cooperation between the client and the engine. Client-side cookies are needed,
and additional coding is required on the server side for session tracking.
Integration with a naming service is not possible at the client side, and has to
be manually coded at the server side.
EJB differentiates between stateless and stateful objects.
While the former are created on demand and do not outlive single invocation, the
latter are uniquely identified by a primary key, which permits unambiguous
EJB benefits from its implicit integration with
persistence and naming services. Moreover, while servlets leave the topic to the
user's discretion, EJB supplies ground rules and a comprehensive framework for
identification of EJBs.
no access to the runtime environment other than regular Java mechanisms.
The EJB container manages environment properties on behalf
of individual EJBs. These can be defined at deployment time, allowing for
greater deployment flexibility.
EJB provides better ergonomics of the runtime
environment management, an essential part of system administration.
NAMING AND DIRECTORY SERVICES
integration with JNDI except when manually coded. No client-side access to
JNDI is fully integrated into the server and the namespace
is managed transparently. EJB provides naming context and automates object
The servlet client's inability to discriminate its
server object is a limiting factor for component-based architectures.
are bound into the end-user context only for the duration of a single request.
Servlet instances are managed by the server only to assure that the configured
number of instances of a certain kind has been pooled.
EJB instance life span can vary from per-request
instantiation to the duration of a session, to the persistence over many user
sessions. The persistence mechanism allows bean-based implementations to survive
catastrophic session failures and container shutdowns.
Servlets do not
have any prescribed state management policies.
The container cooperates with the EJB to maintain the state.
In contrast to servlets, stateful EJBs are required to implement
activation/passivation methods to enable the container to invoke them
automatically to persist the EJB's state at well-defined points.
EJBs must comply with the state management contract,
which in some scenarios may be perceived as an unnecessary burden. However, a
well-articulated and standardized state persistence policy is a definite
advantage to application designers.
of a servlet with back-end resources must be hard-coded.
Back-end resource access is encapsulated in entity beans
that act like resource proxies to the session-level objects.
To achieve the same level of indirection and
encapsulation as available with EJB, servlets have to manually provide for
resource management. This may be prohibitively complex, especially when resource
management needs to be integrated with transactional and security
locking must be manually implemented and coordinated across servlet instances.
It is easy to break resource sharing, as there is no centralized enforcement
Resource sharing is managed at the level of entity beans.
The container manages access to the entity beans and synchronizes access to them
according to the defined sharing policy.
An EJB resource-sharing mechanism creates an essential
foundation for resource load balancing.
relationship between the client and the servlet is one-to-one only, for the
duration of single request.
The multiplicity of relationships between client and
server-side objects is not defined. The client may reference many entity and/or
session beans simultaneously.
The relationship between client and servlet is
inherently damaged by the limitations of the HTTP protocol. However, a number of
work-around techniques may be suggested, like having a single servlet to
multiplex all types of client requests. The drawbacks of such a scheme are
rely on JDBC facilities to pool database connections. This pooling is managed
explicitly. SQL statements have to be prepared manually.
The database connection pool is managed by the server,
according to the deployment time policy. The container manages object
persistence. SQL statements can be generated automatically.
require manual marshalling of call arguments from their HTML representation.
Analogously, return values have to be embedded in HTML. The Servlet API defines
a number of programmatic facilities that assist in this task.
EJB invocations do not have fixed signatures, and arguments
can be represented as a structure of arbitrary complexity, including, but not
limited to HTML strings.
Direct HTML rendering provided by servlets is a strong
advantage for a browser-based client.
Servlets do not
have any inherent threading or synchronization model. Threading safety is left
to the discretion of the developer. A single threading model is devised
specifically to ensure that all calls are single-threaded.
Bean invocations run in dedicated threads. The container
manages thread synchronization. Thread pooling is available for performance
support a single metaphor: request-reply. It is possible to identify requests
into a client session, but this requires additional design and, because of API
limitations, is not a comprehensive solution.
EJBs support a wide spectrum of metaphors, including
request/reply in both stateless and stateful manner, asynchronous communication
through message-driven beans, as well as session and persistent session.
Servlets can be chained
to each other to process client requests in a sequential manner.
An EJB that receives the client request can fan out
consequent service invocations.
Please see the related story 'The right Java tool for the