In-Depth

Comparing servlets and EJBs

• By Max Dolgicer, Gerhard Bayer, Michael Bardash
• August 30, 2002

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 objective parameters.

APPLICATION TOPOLOGY
Servlets
Web-centric model (client connects via Web server only)

EJBs
* Web-centric model (via presentation gateway, e.g., HTML servlet)
* 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 fashion)

Comments
EJB permits for much more flexible deployment topographies. Web server is not a prerequisite.

CLIENT ACCESS
Servlets
HTTP only

EJBs
HTTP
* RMI and/or CORBA
* IIOP HTTP tunneling
* Value-added proprietary protocols such as t3

Comments
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 precluded.

TRANSACTIONAL SUPPORT
Servlets
* Transactions must be coordinated manually through integration with JTS.
* A client cannot easily pass transaction context to a servlet.
* Attempt to allow a single transaction to spawn multiple servlet invocations is at least non-trivial.

EJBs
* 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 management.
* Transaction rules are declarative in nature and can be changed at deployment time.

Comments
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.

SECURITY
Servlets
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).

EJBs
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.

Comments
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.

PERSISTENCE
Servlets
No specific 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.

EJBs
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 ASSOCIATION
Servlets
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.

EJBs
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 context identification.

Comments
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.

ENVIRONMENT ACCESS
Servlets
Servlets have no access to the runtime environment other than regular Java mechanisms.

EJBs
The EJB container manages environment properties on behalf of individual EJBs. These can be defined at deployment time, allowing for greater deployment flexibility.

Comments
EJB provides better ergonomics of the runtime environment management, an essential part of system administration.

NAMING AND DIRECTORY SERVICES
Servlets
No integration with JNDI except when manually coded. No client-side access to directory services.

EJBs
JNDI is fully integrated into the server and the namespace is managed transparently. EJB provides naming context and automates object registration.

Comments
The servlet client's inability to discriminate its server object is a limiting factor for component-based architectures.

LIFE-CYCLE MANAGEMENT
Servlets
Servlets 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.

EJBs
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.

STATE MANAGEMENT
Servlets
Servlets do not have any prescribed state management policies.

EJBs
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.

Comments
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.

RESOURCE BINDING
Servlets
The association of a servlet with back-end resources must be hard-coded.

EJBs
Back-end resource access is encapsulated in entity beans that act like resource proxies to the session-level objects.

Comments
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 management.

RESOURCE SHARING
Servlets
Resource locking must be manually implemented and coordinated across servlet instances. It is easy to break resource sharing, as there is no centralized enforcement authority.

EJBs
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.

Comments
An EJB resource-sharing mechanism creates an essential foundation for resource load balancing.

RELATIONSHIP MULTIPLICITY
Servlets
The relationship between the client and the servlet is one-to-one only, for the duration of single request.

EJBs
The multiplicity of relationships between client and server-side objects is not defined. The client may reference many entity and/or session beans simultaneously.

Comments
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 obvious.

DATABASE INTEGRATION
Servlets
Servlets rely on JDBC facilities to pool database connections. This pooling is managed explicitly. SQL statements have to be prepared manually.

EJBs
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.

INVOCATION ARGUMENTS
Servlets
Servlets 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.

EJBs
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.

Comments
Direct HTML rendering provided by servlets is a strong advantage for a browser-based client.

THREADING MODEL
Servlets
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.

EJBs
Bean invocations run in dedicated threads. The container manages thread synchronization. Thread pooling is available for performance optimization.

METAPHOR
Servlets
Servlets essentially 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
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.

CHAINING
Servlets
Servlets can be chained to each other to process client requests in a sequential manner.

EJBs
An EJB that receives the client request can fan out consequent service invocations.

Please see the related story 'The right Java tool for the right job.'