Addressing the issues and decisions that go into adopting an EJB-based solution
Summary Since J2EE's (Java 2 Platform, Enterprise Edition) earliest days, Enterprise JavaBean (EJB) technology has caused much controversy, with developers and architects constantly struggling to make best use of EJB in their projects. Consequently, our industry has spawned folklore and rules of thumb to guide us how best to use EJB -- some true, some out of date, and some pure fabrication. In this article, Humphrey Sheil explains when and how to use EJB in your J2EE application, as well as how to know when EJBs are not the right solution for you.
EJB advantages and disadvantages Moving along, let's look at EJB's strong and weak points. In the disadvantages section, I also give solutions to commonly encountered EJB weaknesses.
EJB advantages First, let's examine the advantages that the EJB architecture and programming model provides:
1. The underpinning EJB specification: Funnily enough, EJB's main advantage -- its specification -- also represents its biggest disadvantage, as you'll see below. The specification stipulates everything for EJB, from the various types, lifecycles, and restrictions, right through to roles and responsibilities. Many vendors' application servers conform to the specification, allowing you to select a best-of-breed solution.
EJB's universal nature offers application developers well-defined roles (I'll write the container and server, you write the business logic according to my APIs). Moreover, developers enjoy the certainty the spec delivers. Indeed, by choosing an EJB solution, developers benefit from a large skills pool, along with established best practices and open standards. Finally, found a show-stopper bug in your current server? If you have paid attention to portability issues in your design and implementation, with EJB you can circumvent it by moving to another vendor with minimum effort.
2. Integration with the J2EE platform: Since Sun introduced EJB in 1997, a strong enterprise computing environment has grown up around it, including technologies such as servlets, JMS (Java Message Service), JSP (JavaServer Pages), the JCA (Java Connector Architecture), JDBC (Java Database Connectivity), security, and transaction management. Such integration enhances EJB's attractiveness as the J2EE platform includes so much other complementary technology.
For you, the application architect or developer, you can rest easy because no matter how complex your application, the integrated, fully featured J2EE platform can handle your requirements.
3. Almost transparent scalability: Because you delegate so much to the container, the vendor can scale server-side resources to meet fluctuations in demand. I say "almost transparent" because developers are somewhat affected. In the case of horizontal scaling and entity beans, for example, where application servers are clustered, you usually need to modify deployment descriptors to let individual server instances know they are not the only processes accessing and modifying a persistent store.
4. Free access and usage of complex resources: When you buy a specification-compliant EJB server, you receive important features for free, namely transaction and security management, resource pooling, JNDI (Java Naming and Directory Interface), component lifecycle management, and more -- representing heaps of systems-level code you would otherwise have to design, build, and maintain in-house.
5. A strong and vibrant industry and community: All the major IT players, with the exception of Microsoft, support EJB and J2EE, which means you are investing in a technology in which many other people have also invested. That investment commitment means the technology will be around for a long time. Additionally, enterprise Java technology continuously improves. For example, the EJB specification is currently at 2.0, having evolved from 1.0 and 1.1; a pattern likely to continue.
EJB disadvantages Surprise, surprise, despite all the marketing hype over the past three years, adopting an EJB solution does present some disadvantages. Even more surprising, despite what you may have read over the past six months about these disadvantages, they are almost all avoidable when you know how:
1. Large, complicated specification: In defense of Sun, no widely adopted distributed technology has avoided this pitfall; take a look at the CORBA specifications from the OMG (Object Management Group), or the architecture of Microsoft's .Net platform. Still, it would be good if there were a trail to follow in the specification for different roles. For example, EJB developers need only read Chapters 6 and 9 of the spec to understand session and entity beans. Additionally, in my experience two roles, not the six assumed in the spec, exist in practice: container/server providers and application providers, who build, assemble, deploy, and also administrate an EJB server. As such, the specification should reflect how EJBs are used in practice and how development teams are organized.
2. Increased development time: I mention EJB development time in comparison to straight Java class development, not to other distributed environments. EJBs do take longer to develop, and when things go wrong, they can prove more difficult to debug, particularly because the bug might not be in your code but in the application server/container itself. Again, a difficult pitfall to avoid since the container gives you so much, but a disadvantage nonetheless.
However, timely and targeted training can solve this problem. Knowing what the container/server should provide (by understanding the specification) and knowing how the container/server provides this (vendor documentation, sometimes augmented by training) will reduce EJB development time dramatically. On a technical note, an IDE that supports the Java Platform Debugger Architecture (JPDA) also proves invaluable in tracking down bugs.
3. Added complexity compared to straight Java classes: At a superficial level, you require three classes for every session bean, four for an entity bean, and you may additionally employ value objects to reduce network overhead, adding another class. And I haven't counted the deployment descriptors yet, one that stores standard EJB information, the other with vendor-specific information!
The solution: auto-generation. Tools like XDoclet reduce the amount of code you have to write, and it's free! Most IDEs feature auto-generation capabilities too, but they tie you to one vendor, and usually in a GUI-driven mode too, which means no automated builds or tests -- not a great solution.
4. Potential to produce a more complex and costly solution than is necessary: The potential complexity and cost is a corollary of disadvantage number one concerning the complexity of the spec. Simply put, "If you don't get it, it will get you." That is, if you don't understand EJB, you won't take full advantage of it. Moreover, you will misuse parts of it and reinvent others, making your solution less maintainable and one that fails to capitalize on the advantages that make EJB a good idea in the first place.
5. Continual specification revisions: No sooner have you deployed your shiny new EJB application than you see a new specification with newer features, rendering your application obsolete before it hits the streets. This situation, however, is unavoidable. As EJB technology matures, loose ends in earlier versions are tied up and new features added. Vendor release cycles contract in sympathy, and you need to move with them. Companies today upgrade application servers much more rapidly than they did databases three or four years ago, placing additional pressure on already tightened IT budgets.
References are solely from
Resources # See for yourself how I mutilated Shakespeare's original "To be, or not to be," speech from Hamlet in the sidebar. # Reader inquiries about my second JavaWorld article, "J2EE Project Dangers," (March 2001) prompted me to write the above article: http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html # You can download the Enterprise JavaBeans 2.0 Specification from: http://java.sun.com/products/ejb/docs.html # The Jakarta Project's free Ant build tool removes much of the pain in deploying EJBs to application servers, and, best of all, it's extensible: http://jakarta.apache.org/ant # Check out XDoclet for an elegant way to reduce hand-maintained code and increase efficiency through auto-generation: http://xdoclet.sourceforge.net # "Designing Enterprise Applications with the J2EE Platform" (Sun Microsystems, 2001) from the J2EE Blueprints series offers good information on design patterns for EJB/J2EE projects: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html # The OMG produces and maintains computer industry specifications for interoperable enterprise applications, most notably CORBA: http://www.omg.org # Jini.org offers in-depth information about Jini and JavaSpaces: http://www.jini.org # Sandstorm, an interesting technology out of the University of California, Berkeley, provides good information for scalable applications: http://www.cs.berkeley.edu/~mdw/papers/seda-sosp01.pdf # For more information on .Net, check out this site, specifically designed to appeal to developers and architects: http://gotdotnet.com/ # "Gartner: Don't Overspend on Application Server Tech," Scarlet Pruit (NetworkWorldFusion, August 2001) -- like all research notes, this one is refreshingly honest and wonderfully accurate: http://www.nwfusion.com/news/2001/0821gartnerapp.html # My first JavaWorld article, "Frameworks Save the Day" (September 2000), outlines the basic necessities of a J2EE framework and also an extension strategy. If you're not using a standard framework on your project, you are leaving yourself open to a whole raft of quality and maintenance issues: http://www.javaworld.com/javaworld/jw-09-2000/jw-0929-ejbframe.html # Born and bred from XP (extreme programming) and JUnit, continuous integration makes your development cycle a lot easier: http://www.martinfowler.com/articles/continuousIntegration.html # For more EJB stories, visit the Enterprise JavaBeans section of JavaWorld's Topical Index: http://www.javaworld.com/channel_content/jw-ejbs-index.shtml # Discuss EJB in our Enterprise Java discussion: http://forums.devworld.com/webx?50@@.ee6b80a # Sign up for JavaWorld's free Enterprise Java newsletter: http://www.javaworld.com/subscribe # You'll find a wealth of IT-related articles from our sister publications at IDG.net
Reading the article, I could not see a single place where the author mentions the types of problems that EJBs are supposed to solve. And, of course, there is no discussion on why EJBs are better for solving those problems compared to other available technologies.
Let us repeat the list of EJB advantages as stated by the author: 1. The underpinning EJB specification 2. Integration with the J2EE platform 3. Almost transparent scalability 4. Free access and usage of complex resources 5. A strong and vibrant industry and community
shows that only #3 has anything like a plausible reason to use EJBs.
The fact that EJB has a specification is not reason enough to consider it. CORBA has a specification too, I believe. The author's logic would then suggest that we should cosider that approach, too.
Integration with the J2EE platform is not in itself cause to use EJBs. I could use Spring Framework and Hibernate (for example) to solve my problem. Both are J2EE technologies. Why is EJB better?
As far as scalability is concerned, there are other approaches. Using Tomcat/JBoss/... and clustering if necessary, we could easily build scalable solutions that are less expensive to build. So what advantages do EJBs provide?
Re "free access and usage of complex resources", there are many open source frameworks that provide the same.
The same refutation holds for the last advantage mentioned by the author, "(a) strong and vibrant industry and community"
Looking at the advantages with a critical eye reveals that the author has failed to make a case for using EJBs.
i think the author have put up a very considerable topic of what are pro n corns of using ejb, and i fully agree wid the author that , any problem which is solved using ejbs can be done as simply as using jsp and servlets.
It is generally not appropriate to publish articles written by others and to claim it as your own. And to accept congratulations on an article that you have plagiarized is horrible.
I have clearly mentioned the links and resources at the end of the article.Dear friend its just a way of spreading the general awarness not any personal, and neither i have claimed any thing nor i would is that okiiiiii dear.
Sharad, Nowhere is there a link to the original article. All you've reproduced are the links mentioned in that article.
If you wanted to point us all to that article, you should merely have provided a link to that one right at the beginning of the article and expressed your views/comments on it.
When you accepted the "thanks for the article" messages, you implicitly claimed that you were the author.
Next time you post something, I will not believe that you wrote it. I'll think you "borrowed" it from somebody without attribution.
I'd have to agree with Ravi. All your comments and responses to posts imply that you are claiming credit for the article (of which has been brought to our attention to have been bootlegged off Java World).
If this is your first post on Artima, I must say thats not too great a start - you should probably think of salvaging your tarnished image as a plagerizer on Artima.
Previous Topic
