The developers of Lynx clearly recognize EJB as a powerful technology for distributed transaction processing. For business scenarios where a transaction must span multiple applications in real time, coordinating heterogeneous transaction media such as RDBMS and MOM resources, EJB can be an appropriate choice.

These scenarios, however, are extremely rare …

A spring 2002 Gartner Group report found that although many companies during their sample period released server side Java applications what were deployed on enterprise class servers, only 12% actually leveraged EJB. Gartner’s findings cited a number of reasons, ranging from the steep learning curve of EJB compared to JDBC and conventional Java, to the lack of tool support, complexity of debugging, and complex deployment issues.

Our past experience has shown that EJB carries with it a level of complexity that is unnecessary for most common application development tasks. Additionally, while some who are new to enterprise technologies have followed the path to EJB as one that promises higher performance, this goal is rarely realized. True application performance has always been more a matter of application design, than programming or deployment model. Contrary to early vendor propaganda, EJB is also not the holy grail of scalability and fault tolerance. Using basic Java application server and hardware technologies, application clustering, load balancing and fail-over can all be easily accomplished without the use of EJB.

The Lynx position with regard to EJB is that most applications simply do not require it. If the need for a truly distributed and/or heterogeneous transaction should arise in an application, however, Lynx advocates intervening when the situation arises by wrapping conventional code modules with Stateless Session Beans (SSB). The transaction management components in Lynx have been crafted with this very contingency in mind.