In-Depth
The Right Java Tool for the Right Job
- By Max Dolgicer, Gerhard Bayer, Michael Bardash
- September 1, 2002
Earlier this summer in these columns, we took a high-level view of the Java
side in the e-business middleware clash between Microsoft's .NET and Java 2
Extended Edition from Sun Microsystems Inc. and its partners. This month, we
look more closely at the relationship between Java servlets and Enterprise
JavaBeans (EJBs), and at how the two technologies can be best used separately in
some cases and as complements in others.
In the earlier ''Servlets and EJBs: Friends or
foes?'' article, we offered some thoughts on the evolution of the middleware platform so
far. We also concluded that the phrase ''less is more'' is certainly applicable
when it comes to the development of new, component-based e-business applications
now that there are just two middleware platforms to choose from -- J2EE and
.NET.
In that article, we noted in passing a question that we have been asked
repeatedly during the past few years: Should Java servlets or EJBs be used as a
foundation for e-business applications?
This is an important question, since the servlet model offers more simplicity
than EJBs. The servlet model is also easier for IT developers and managers to
comprehend as they get started with the technology. Our opinion is clear. If an
application is presentation-centric and does not require support for high-end
middleware services -- distributed transactions, persistence,
application-level load balancing, state management and asynchronous messaging,
among others -- then opting for heavy EJB usage is overkill. However, if an
application requires at least a partial list of such high-end middleware
services, then EJBs become the only game in town, assuming of course that the
customer has selected or is about to select a J2EE-based application server.
Scalability
Both servlets and EJBs scale well. A number
of features -- such as server clustering, DB connection pooling and
location transparency -- can facilitate scalability.
Each technology -- or rather the products that implement the
technologies -- has been built to support each of these concepts. However,
servlet scalability is based mostly on proprietary, vendor-created
implementations of servlet pools and load-balancing mechanisms, which are not
stipulated by the servlet API. On the other hand, the EJB architecture was
designed from the beginning with a vision of addressing scalability.
The essential point of distinction here is that while servlets can scale at
the server level, EJBs can scale at the architecture level. Server-level
scalability depends on specific product features (which, no doubt, are almost
universally supported nowadays by best-of-breed products, and are thus
sufficiently mature and comprehensive). Reliance on product characteristics
rather than on a robust, scalable architecture is a gamble because, in some
cases, loads can quickly outgrow product capacity and require emergency
re-architecting, which is a very expensive necessity.
Load balancing
Both EJB servers and servlet engines can
provide mechanisms for load balancing that include resource pooling, default
dispatch mechanisms and entity clustering. While benchmarking results of servlet
engines vs. EJB application servers show more or less compatible performance
curves under heavy loads, a load-balanced EJB-based application has a better
guarantee of operational integrity.
There is no enforcement on an individual servlet design to mandate its
guaranteed incorporation into the distributed environment. As a result, load
balancing has to be accounted for at design time and thus becomes a condition to
proper architecture design and mature vision.
If load balancing is not taken into account, later attempts to introduce new
resources create the potential for resource sharing conflicts, breach of
transactional guarantees, or for sub-optimal performance caused by custom
dispatch decisions or resource locking. On the other hand, EJBs can supply an
infrastructure with rich component management capabilities that allow for the
plug-and-play-style introduction of new resources.
Business logic hosting
Because servlets have no
impositions on their internal structure and therefore have to manage all aspects
of their existence explicitly, they attain only a mediocre level of separation
between business functionality and cooperation management (such as database
connection management calls, for example).
Business logic becomes intermingled with service calls to databases, name
servers or other infrastructure services. EJBs, by design, attain a good level
of business separation. Another limitation imposed on servlets' capability to
host business logic is their responsiveness obligations. Because they operate
within an HTTP session, a lengthy calculation -- which may be necessitated
by the business functionality -- could time out the user session.
Business agility
EJBs and servlets do not preclude
design-level atomization of business services, so application components can be
replaced with other components transparently to the overall architecture.
However, because of its more flexible cooperation model, an EJB provides a
better vehicle to handle paradigm shifts.
For example, if a browser client must be replaced for some reason with a
programmatic agent (such as in the case of business process automation),
servlets would not be able to handle the change, while an EJB-based solution
would require only modest and well-confined modifications.
Integrity
An EJB application is homomorphic throughout:
The same component model is utilized for the component hierarchy, and all
components are guaranteed to function under the single umbrella of transactional
and security services.
In contrast, a servlet-based application is free to agglomerate any
technology without restrictions, with the unavoidable risk of creating points of
tension, and the consequent need to account for technology blending at the
analysis and architecture stages.
High availability
Both EJB application server and
servlet engine products are designed to provide high availability of services on
the front end. This is achieved through clustering and failover mechanisms that,
though differing between implementations, still pursue the same goal with more
or less compatible effectiveness.
However, on the back end -- at the level of business logic
implementation -- EJBs use advanced component distribution techniques, such
as object factories and smart proxies, that are not available to servlets.
Failover
In the case of EJB, a failover mechanism is a
prescribed key functionality and is readily available without any additional
analysis or design effort. EJB failover is facilitated by automatic persistence
guarantees and by automatic failure detection. Servlets have no equivalent
mechanisms unless they are coded explicitly.
Deployment
Deployment is not a priority issue for
servlets, but in the EJB worldview, deployment is considered to be one of the
key elements of application delivery.
For this purpose, EJBs define a whole methodology for defining deployment
characteristics that is supported by extensive APIs dealing with environment,
deployment descriptors and object properties. As a rule, deployment description
is declarative in nature, and the container is capable of adjusting runtime
characteristics (such as transaction guarantees) automatically.
Portability
Both servlets and EJBs are published
standards that are backed up by reference implementations and product compliance
certification programs.
Despite that, vendors choose to introduce non-standard elements that, in
their opinion, enhance product functionality. Because of the huge difference in
the breadth of coverage and depth of penetration between servlets and EJBs, EJBs
more easily fall victim to such enhancements; so, applications developed over
different EJB products carry a greater risk of not being completely portable.
Management and administration
Runtime management and
administration is a high priority for both EJBs and servlets, and most products
supply facilities for component start and stop, configuring operational
parameters, event logging and health monitoring.
EJBs supply a runtime environment that enables easier component monitoring
and management. Integrating a component into a management infrastructure is a
seamless activity with EJBs, whereas with servlets, if it is feasible at all, it
requires the use of product-specific APIs.
Development ergonomics
Servlets is a relatively simple
standard that requires basic knowledge of Java and HTML, at the most. EJBs, on
the other hand, are complex and multifaceted, and require an understanding of
the J2EE platform, as well as proficiency with essential computer science
fundamentals (such as threading, transacting, object technologies and so on).
It is probably clear at this point to the development world that Enterprise
JavaBeans are better suited for enterprise application platforms than pure
servlets are. We say ''pure'' servlets to underscore the fact that a complete
(though, as explained, not necessarily adequate for certain uses) architecture
can be built exclusively upon servlets supplemented with a mix of other Java
technologies. In reality, however, there are shades of gray between pure EJB and
pure servlet solutions.
First, many servlet engines are embedded into app servers and share a common
implementation architecture with EJB servers. This allows vendors to merge the
servlet execution environment with the EJB server and thus bring servlet
execution under the same failover and load balance guarantees as EJBs.
Second, EJBs by definition declare compatibility with the other J2EE
standards, including Java Server Pages (JSP), a technology that aims for the
same goals as servlets (though admittedly in a different way). Moreover, JSP
uses servlets as an implementation vehicle, as JSPs are compiled and cached as
servlets.
If we return to our initial assertion -- that servlets are a narrowly
specialized technology that is excellent for delivering dynamic HTML content,
and that EJBs are a wide, generalized specification designed to componentize
business functionality -- it becomes apparent that the class of
enterprise-strength applications dealing with browser-based clients can benefit
from both servlet and EJB technologies simultaneously and without inherent
conflict.
The browser client initiates an HTTP request that is served by a servlet.
Rather than implementing complex business logic, the servlet simply redirects
the call, along with parameters and perhaps some identification information, to
a session bean. The session bean implements the top-level process flow
associated with the call, but delegates specific activities to the specialized
entity beans. These serve later as proxies to various resources both inside and
outside the application server. Developers should notice that all of the
business logic is under EJB container management and that it benefits fully from
the rich infrastructure services and container-side management.
It should be noted that this architecture has the inherent flexibility to
support not only browser-based clients, but also richer clients (in an intranet
scenario). In addition, it can be easily extended to make business functionality
available through new interface mechanisms -- for example, Web services or
whatever the next great idea might be.
In conclusion, it is easy to see that because servlets are good at exposing
Java interfaces to the Web, and EJB is the tool to enable good Java interfaces,
there seems to be a perfect match in using a lightweight servlet as a
Web-exposing front end to EJB-encapsulated business functionality.
See the related article 'Comparing servlets and
EJBs.'