J2EE applications use too many EJBs. The correct1 number of EJBs is one per component. My reasoning is below, but first a quick review of the technical pros and cons of using EJBs.
Pros:
Cons:
Each of the advantages gained from EJBs, is gained, in full, with the first EJB you use. Additional EJBs don’t give additional advantage.
On the other hand, (most of) the disadvantages of using EJBs accrue with each and every EJB. Each additional EJB gives a bigger helping of disadvantages.
From here it’s a very small step to the conclusion that you should use as few EJBs as possible, preferably zero. However, if you find the advantages of using an EJB container compelling, then I recommend a maximum of one stateless session bean as the interface to each component.
1 If you know of an application that would benefit from more EJBs than this, please let me know. I’ve yet to encounter one.
2 Though I’ve never seen an EJB application gain any performance or reliabilty by distributing itself over multiple machines. IMHO, most applications don’t follow the rules strictly enough to allow transparent distribution.
3 Except that they are the only mechanism available to get hold of the SessionSynchronization interface, and thus the only way for EJB 1.1 objects in a container to “listen” for whether a transaction is successful or is rolled back.
Updated: This new entry extends and clarifies my argument.
Comments
Not convinced.
You seem to be ignoring local interfaces & xdoclet, which tends to remove many of your cons points. The last two don't seem to have anything to do with the number of EJB's at all.
You aoppears to be mixing in points as whether to use EJBs at all, which is a different question (and which tends to ignore MDB's too)
Though I'm a very big fan of the EJBs... Still I can not understad the very fact for the EJB came into existence and the way it is beeing used. 1) distributing component 2)distribution of work i.e. a) Bean provider b) Server provider c)Application assembler d) deployer. This is to make applications in less time.... in the above case apart from Server provider which is provided by a third party , the rest of the areas are being done by the application assembler himself. 3) Once the bean is jared then it should be able to deployed in any EJB server which is not the case now.
In our application we are using 3 layers of EJBs and it is usefull because it is giving a lot of scope for application enhancements.
Gwyn,
Yes I did ignore local interfaces and xdoclet. Locals may be faster, but they still carry around most of the same development time penalties as Remotes.
XDoclet addresses some of EJB's weaknesses, but fundamentally the problems remain: there is still a lot to configure. Each additional EJB gives you more to configure.
I'm not sure what point you are making about MDBs. From what I know of them (not much) they are equivalent to stateless session EJBs for the purposes of my argument.
Perhaps my latest post might help? http://www.cardboard.nu/archives/000096.html
Some additional cons:
- EJB finder have little sense in case of case sensitive databases, e.g. ORACLE, because even EJB 2.1 still doesn't support e.g. UPPER function
- there is no support for usual queries SELECT ... JOIN ...
So EJBs serve only limited part of real life applications: insert, update, delete operations.
xDoclet & local interfaced do compensate some of EJB Cons.
If you enjoy writing data access code over and over again, and if you enjoy writing caching code over and over again, and if you enjoy writing security code over and over again, and if you enjoy writing transaction control / cooperation code over and over again... then sure, I guess you shouldn't use EJBs.
a) CMP Entity EJB's are easy to write these days with a decent tool. We write CMP beans using WSAD (Websphere Studio Application Developer) with practically zero effort.
b) Stateleless session beans provide a perfect location-transparent interface to your business logic tier.
c) Stateful session beans are not useless - many business processes are STATEFUL. Most people have steered clear of stateful EJB's because of performance and scaleability problems, but today's containers have made vast improvements.
d) Using EJB's is easy with if you use simple patterns like Service Locator. My code never has to deal with PortableRemoteObject - that's all handled by a write-once class that provides home lookups and caching, remote or local lookups, etc.
All that being said, it is also true that you should not use EJB's when they are not appropriate. Entity EJB's are perfect for accessing data in an OLTP application. Stateless session EJB's are best for providing location-transparent and workload-managed access to distributed business logic. Stateful session beans are for managing stateful business processes, particularly when you are dealing with distributed clients (not just a web application that can use HTTP session on the front end for state).
I agree with Matt on that - this whole discussion is fruitless, if you want to write a mom and pop store kind of application, where you could write all that code, then certainly EJBs are not required.
Peace!
EJB's are useful if your component needs to participate in a distributed transaction. For example, your application must persist data into a proprietary EIS and a standard RDBMS in one automic unit of work (transaction). If you do not need to coordinate transactions, for example your application works with a single RDBMS, think hard about why you are using EJB. Also ask yourself the question, "Am I building an application, or a component?".
there are many good resons to identify various different ejbs.
1. you require stateless or stateful services. There's two to start with.
2. different availability. say you have one critical high-availabiltiy service, deploy it in its own ejb which can be replicated and deployed separately from your others, which might go down once a week for a rebuild.
3. different scaling. You might have one high-volume service like "isServerUp" which gets pinged all the time. Then you have other servies which might get called once a week. By identifying this up front, you can get flexibility to scale the component as required, without impacting other components.
4. different deployment timscale. Some components might change regularly, and you deploy a new version every day. Other components never change, and never need to be uneployed.
i love card board its so cool and i love to think about it
Good read