Do We Really Need EJB?

Transcription

1 Do We Really Need EJB? Alexander Krastev and John Galletly Abstract: This paper, which is a compilation of the experiences of a number of software developers, is an attempt to guard the software community against the pitfalls of the EJB technology. It presents an anthology of experience that might help application developers realize when they are over-engineering their solution when the signs point to a different approach, probably to a different technology. We will start by juxtaposing the commonly agreed on advantages and disadvantages of the EJB architecture. Then we will see how some of the alleged advantages might turn out to possess a certain downside, in the sense that they might lead to solutions that, for reasons implicit in the EJB ideology, are far from efficient. On the basis of all that, we will try to distil rules of thumb about the situations for which the EJB paradigm is suitable and the ones in which it is to be avoided. We will complete the paper with our personal opinion about the viability of the EJB technology in the software arena as well as the prospects for this technology to find place in the applications of the near future. Key words: EJB, Session Bean, Entity Bean, Security, Transaction, Pooling, Portability, Remote Invocation, Caching, JSP, JDBC, Servlets INTRODUCTION Ever since its introduction in 1998 [4], the Enterprise JavaBean (EJB) technology has generated much controversy in the software arena, with developers and managers struggling to decide if the new component architecture should be used in their projects. The EJB architecture was promoted as the server-side component model of the Java platform and, as such, it was designed to enable enterprises build secure, scalable, multiplatform, business-critical applications as server-side components [1]. The main purpose of EJB was to allow enterprise developers to focus on writing the business logic and free them from the need to write transaction, security, caching, pooling and threading primitives by delegating that task to the server vendor. While EJB is a very elegant technology, many software developers fail to realize that it is not a one-size-fit-all solution [4]. For instance, EJB might not be needed for nondistributed applications such as batch processes in which speed might be more important than security and transactions. Unfortunately, at the moment, EJB is the default choice of the industry, probably because it gets so much attention from the media, not because it is technically the best fit for a project [6]. Deciding whether the EJB architecture is appropriate to the project at hand is therefore an important issue that must be given considerable thought. Being familiar with a given technology might be important. Knowing when to apply it, however, is even more significant. This paper, which is a compilation of the published experiences of a number of software developers, is an attempt to draw attention to some of the pitfalls of the EJB technology. It is an endeavour to make developers realize when they are over-engineering their solution when the signs point to a different approach, perhaps even a different technology. At the same time it does not try to discredit the EJB technology. Rather, it presents an anthology of experience, possible alternatives and tips that may lead to a better solution. ADVANTAGES AND DISADVANTAGES OF EJB In order to decide whether the EJB technology can fit a project, it is necessary first to understand its major advantages and disadvantages.

2 1. Advantages i) The EJB Specification [9] is a thorough description of the whole EJB architecture. It defines the EJB types, lifecycles, restrictions, developers roles, etc. Vendors write the application s servers conforming to the EJB Specification and the enterprise developers write the business logic according to a well-defined API. Following the same rules makes it easy to migrate from one application server to another [8]. ii) Ever since Sun released EJB [4], the number of complementary technologies that integrate with the J2EE platform has been steadily growing, and this constantly increases the attractiveness of the EJB technology. Presently the J2EE collection includes technologies such as servlets, JMS (Java Message Service), JSP (JavaServer Pages), the JCA (Java Connector Architecture), JDBC (Java Database Connectivity), security, and transaction management [8]. iii) Security, transaction, pooling and caching issues are delegated to the application server. Because of that we can transparently scale our application by scaling the serverside resources to meet fluctuations in demand [8]. iv) Presently, 25 of the major IT players, with the exception of Microsoft, support J2EE, and EJB as part of it. [8] Thus, customers devising a J2EE solution have a large pool of servers, tools, environments as well as a variety of popular books and Internet articles on EJB best practices and design patterns to choose from [8]. v) Since the specification does not specify any remote object protocol, it allows for a variety of clients. This means that a server can support multiple protocols like RMI, IIOP (CORBA), and DCOM. This implies that a client of an EJB server does not have to be written in the Java language [1]. Furthermore, we can reuse the same component layer for a thick client as well as a Servlet/ JSP client [2]. vi) The system is usually built in a faster and more reliable way: Developers only have to focus on writing the business logic. There are command-line tools that generate the files you need, there are IDEs that help you build EJB components, and there are UML editors that help you generate EJB components from UML diagrams [2]. Also, features that have to be ordinarily hand coded can be turned on by simple declarative properties of the Enterprise JavaBean. Thus, certain behaviors, such as security and transactions, are set not in code, but as flags on the Bean itself [1]. There are situations, however, when a glitch in the application server can significantly prolong the testing and debugging phase. A closed system like an EJB container can be a extremely hard to debug if it behaves in an unexpected way. [6] vii) The presentation logic (Servlets and JSPs) is separated from the business logic (EJB components). This allows for various types of presentation logic, such as WAP enabled phones or web-based clients tapping an XML data stream from a business service provider [2]. The same separation, however, can be equally well achieved without resorting to the EJB architecture. 2. Disadvantages i) The specification is too large and complicated. The truth is that every widely adopted distributed technology, such as Microsoft.Net or OMG CORBA, suffers from this weak point. Still, there are ways in which the specification can be simplified. For instance, in practice only two roles can be discerned as opposed to the six roles described in the specification: container providers and application providers. The latter administrate the server, build the application, assemble it and finally deploy it. This is how teams are organized in the real world [8]. ii) Added complexity compared to straight Java classes. Every session bean consists of at least three Java classes, while every entity bean comprises at least four. We also need standard and possibly vendor-specific deployment descriptors. It is true that some tools for

3 auto generation can considerably reduce the coding time. However, these tools introduce their own restrictions because usually they tie you to one vendor [8]. iii) The EJB technology has the potential to produce a more complex and costly solution than necessary. This disadvantage is a direct corollary of the complex specification. The specification is so complicated that some developers do not take full advantage of it, simply because they fail to understand it. A common pitfall is to misuse some parts and reinvent others, creating a solution that is hard to maintain and one that does not focus on the merits of EJB [8]. iv) EJB has a poor Object/Relational mapping. EJBQL is also notorious for its limitations. There exists no standardized portable way to retrieve the first N records either the whole collection is loaded or each bean is loaded one at a time. The primary key generation mechanism is usually rather awkward as well [6]. v) The EJB paradigm is also tarnished by its inefficient synchronization scheme for the remote objects. When a client makes a remote call, the bean is locked and available only to that client. All other clients are blocked, waiting to be scheduled for execution when the client holding the lock releases it. If we take control of our RMI servants directly, we can adopt a more efficient synchronization policy [7]. QUESTIONING THE MERITS OF THE EJB ARCHITECTURE i) Does code portability really exist? The truth is EJBs are portable only if you write them to be. Session beans and BMP (bean managed persistence) entity beans usually port quite easily. In contrast, CMP (container managed persistence) entity beans need plenty of work. The reason is that vendors often introduce proprietary features, which do not comply with the specification, in order to optimize performance. The work might not be in rewriting code, but in reconfiguring deployment descriptors and container/server configurations [8]. In addition, administration and configuration tools and mechanisms are vendor-specific, as are things like startup and shutdown scripts and sometimes build scripts. ii) Is portability really necessary? Before we start coding our applications with a strict adherence to the specification and start criticizing those who do not, we must ask ourselves the question: How many applications actually migrate between server products?. Most developers are unwilling to perform such a migration because it turns out to be not a trivial task. If we define EJB portability as the ability to migrate seamlessly between server products [7], it is easy to see that, for any but the most trivial beans, this is obviously a false hope, for in 99% of the cases developers are bound up in vendorspecific features without even realizing it. So, what do we gain from selecting best of breed product if we forgo taking advantage of their proprietary features for fear of losing portability? Absolutely nothing! iii) Is vendor neutrality efficient? The emphasis on vendor-neutrality within the EJB specification leads to a number of inefficient ways of building enterprise applications. To mitigate against these inefficiencies, developers need to follow design patterns, which create a lot of additional work. A developer can be better off if he abandons the whole EJB idea altogether and starts from a core architecture of just servlet/jsp and JDBC [7]. A way to avoid design patterns is to use some of the applications server vendor proprietary extensions. Adopting these extensions, however, precludes the portability of the application to another application server and violates the basic idea of the EJB architecture. iv) Is security really free with EJB? There seems to exist some misunderstanding about the issue of security. It is true that the EJB specification provides a fully-fledged security model. But it is just a model - you need to set up your users and roles yourself, and potentially tie in to an existing authentication source, such as a database or LDAP server [8].

4 v) Is caching of Entity Beans that important? No doubt caching is an attractive feature but it is usually not as important as you are led to believe. The truth is that only a few vendors support clustering and caching. Another problem is that caching does not work with legacy systems, such as PL/SQL applications running on the same dataset [6]. vi) Are container-managed transactions a feature of EJB only? There appears to be a common misconception that there can be no transactions outside the realm of EJBs. The truth is that the whole transaction work is actually done behind the scene by the proprietary application server s JTS (Java Transactional Services). We can achieve basically the same functionality without resorting to a session bean at all. All we have to do is use the JTA API. [6] vii) Can we do without a session bean in a three-tier architecture? A common misunderstanding is that session beans cannot be done without in three-tier architectures. This is not true because Servlet/JSP > EJB > Database [6] is only one of the possible approaches. Servlet/JSP > Bean > Database [6] usually turns out to be another valid solution. viii) Do we really need to incur the overhead of remote invocation? In 95% of the applications, the EJB container and the client (the servlet container) run on the same VM. There is no need to incur the overhead of the remote method invocation when direct method calls would be much faster and easier to program [6]. ix) Is connection pooling a merit of the EJB architecture only? The truth is, connection pooling can be easily achieved by installing a connection pooled JDBC driver in the servlet container. What is more, many servlet containers are even providing JNDI contexts from which to discover JDBC DataSources, rather than forcing us to instantiate database connections on the fly. [7] RULES OF THUMB 1. Rules for choosing EJB i) Choose EJB if you need a comprehensive security model [8]. EJB technology offers an advanced declarative approach to restricting access to objects or methods by a particular user. ii) Consider EJB if you need to have more than one client-type access shared data [3]. Common data and business logic may be encapsulated in a single set of EJB components that are accessed by different client types (such as servlet/html and application). iii) Consider using the EJB architecture if you need concurrent read and update access to shared data [3]. The EJB components control the access to the back-end data and manage the current transactions and database locking internally. This reduces the effort spent in writing database control logic, while ensuring the consistency and validity of the data. iv) Consider using EJB if you need to access multiple, disparate data sources with transactional capabilities [3]. Many applications require the ability to access multiple data sources. In order to maintain data integrity, we must ensure that the transactional changes of all data sources are undone if any of the transactional phases fails for some reason. For online catalogues or read-only systems with low user numbers, EJB is probably not needed. For financial systems or any system where you must preserve the ACID (Atomicity, Consistency, Isolation, and Durability) properties, EJBs are imperative [8]. v) Consider using EJB if your application will need to scale beyond initial low levels of usage and you need multiple servers to handle the throughput or availability needs of the system and ensure constant operation of the system. [3]

5 2. Rules for not choosing EJB i) Do not use EJB when there is no need for scalability, transaction management, or security and low numbers of read-only users are anticipated [8]. ii) Do not consider EJB if you do not need platform independence and do not mind being locked into one particular vendor [8]. iii) Do not choose EJB if you have existing skill sets or investments in a working technology. If your developers are proficient in CORBA, for example, then why not stick with it? [2]. iv) Do not use EJB just because your company got a free set of licenses from a vendor [8]. v) Do not use EJB if your application is a big GUI to a database. If yous is such an application - heavy on data logic but no business logic - you could bypass the EJB business logic layer and connect directly to the database via JDBC. [2] vi) Do not use EJB if your application is simple. If you are prototyping, building a simple system, or developing a one-off application that will not evolve over time, EJB may be overkill [2]. vii) Do not use EJB if you cannot deal with the limitations of EJB. There are situations when we do need to use threading, static variables and native code, and simply cannot deal with the EJB paradigm of load balancing across single-threaded instances [2]. CONCLUSION Presently, the demand for distributed architectures is extremely scarce because a distributed architecture usually implies a broad, almost enterprise-wide application in order to amortize the higher development costs as much as possible. Usually most IT management does not think beyond a six-month development cycle, never mind the longterm consideration that a distributed, enterprise-wide architecture implies. Now, with the likelihood of austere years ahead, the development of distributed applications will be even less unlikely [5]. In the meantime, as clients are interested in applications with no apparent need for distributed features, the possibilities for developing EJB applications in the near future are very slim [5]. Even though those applications are almost certainly to be developed in Java, we must be aware that Microsoft will be garnering an ever-increasing share of the enterprise market with their innovative.net platform. EJB is not the sum total of J2EE - in fact, it is probably the one bad apple in the barrel [7]. Servlets, JSP, JMS, RMI, and JDBC - all of these are excellent specifications that serve their stated goals quite well. Abandoning EJB does not necessarily imply you need to abandon all these wonderful APIs. Instead, embrace them even more fully, and utilize them to the utmost. REFERENCES [1] An Introduction to Enterprise JavaBeans TM Technology. Available from [2] Roman, E. Deciding whether EJB is appropriate. [3] Brown, K, L. Cook. What's it going to take to get you to go with EJB components? [4] Hemranjani, A. Do you really need Enterprise JavaBeans? [5] Sefchik, G. EJB not always necessary. [6] Lightbody, P, M. Cannon-Brookes. Is EJB Always Necessary?

6 [7] Neward, T. The Death of EJB As We Know It? [8] Sheil, H. To EJB, or not to EJB? [9] The EJB Specification Available from ABOUT THE AUTHORS 1. Alexander Krastev, Department of Computer Science, American University in Bulgaria, Е-mail: 2. Prof. John Galletly, PhD, Department of Computer Science, American University in Bulgaria, Phone: , Е-mail: