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