EJB limitations
Everyone likes to bash EJBs. They’re old, they’re unfashionable, EJB knowledge didn’t help you become a millionaire like everyone said it would. Go to any reasonably fashionable soapbox and you’ll be mocked for using EJBs and called a Sun bumlicker. Well, I use EJBs and happen to like them a lot. However, that is not to say they’re without their fair share of headaches. So I’m going to try and present real problems with the current EJB spec (2.0 and 2.1), vs the usual ‘they suck! they don’t scale! Nobody needs that much power! They don’t allow for obfuscated object models!’ arguments.
Limited EJBQL: I really don’t understand the logic behind this. An abstraction query layer over SQL makes sense, sure, however, why cripple it so horribly? Why not support that cutting edge datatype…Date? I mean, you’d have to look really hard to find any sort of object storage thingy which doesn’t understand dates in some form or another. Why not make it dynamic while you’re at it, and perhaps even allow a backdoor for those pesky legacy system which require obscure handcrafted 10 line long sql queries?
Idiotic object relation constraints: We actually have a good collection of these constraints, so I’ll try to give credit to the top ones. First, O/R has to be between local entities within the same module. Why? Is this yet another case of vendors saying ‘well any other way is too hard for us, lets just screw the users instead’? I understand the need for modules to be complete standalone units. However, it’s perfectly legal to declare that a module has references to another module, so why can’t this be extended to say that this module has relations with beans in this other module? While remote relations would be nice, I can sympathise somewhat with all the extra headache that would involve in the way of distributed transactions and suchlike, so I’m willing to stop being angry about it if they’ll just give me inter-module local relations.
Another fly in the ointment is the lack of primitive collection support in O/R collections (aka dependent objects in early drafts of the EJB 2.0 spec). Sometimes all one needs to make one’s boss happy is a collection of Strings. It’s not related to anything, it’s not normalised, it’s just a collection of strings in some far flung database join table. Why must I go through the heartache of defining a local entity with just two fields if all I want is a collection of strings, ints, or longs? This seems like such an obvious need to me I’m quite surprised that few vendors provide this even as an extension. My quality of life would increase considerably if I could use EJBQL to traverse my container handled primitive collections. I would be a happier person, a person far less likely to rant and rave all the damn time.
Inconsistent naming convention. One would think that the spec would demand that EJB’s adhere to bean property naming conventions. That the standard bean introspector rules apply. One would be rather wrong though. The spec authors, in their infinite wisdom, decided to mostly stick to that, but with a few twists here and there to ensure that vendors who assume the logical ‘bean’ characteristic of ‘enterprise java beans’ are caught with panties round ankles.
I’m a huge fan of EJBs (yes, entities too), but it would be really nice if these small niggles could be addressed by the powers that be. Then I can be truly gleeful about rubbing in EJBs in the faces of all those whiners with their wishy washy ‘ejbs suck’ articles. Assuming also of course that vendors stop released ‘ejb compliant’ products which gleefully implement a very ‘liberal’ interpretation of the spec, or even better, feel they’re too good for the spec altogether (yes JBoss kids, I’m pointing and laughing at you).
June 23rd, 2003 at 3:32 pm
my my thinking that JEB=j2ee spec..not!
Try to read the pspec this time and actually analze it..
EJB is but one small portion of J2ee..
June 23rd, 2003 at 3:43 pm
I dunno, I’ve pretty much given up on Entities unless I can create the data model from scratch and I know I won’t have to do any hand coded SQL.
I think there are significant issues with Session beans, mostly around deployment. Why the f*** do we have to make 5 classes all with the same interface just to make a remote, transactional call? Why make a home interface for stateless beans that JUST has create() in it? I should be able to write a class, give it to the server, and have the methods available as a Stateless Session Bean without any other XML crap or pseudo-not-implemented-but-implemented interfaces.
I’ll do all that other junk if I need something special, but 99% of the time, I just need a remote, transactional method.
June 23rd, 2003 at 4:15 pm
Hani, is that all you know about ejb limitation. i was expecting more from you. even Dave’s comment was more appealing. Dave, maybe you should write the BileBlog.
June 23rd, 2003 at 7:46 pm
To the FUD debunker:
my thinking that 2JEE mentioned at all … not!
Try to spell JEB this time and actually corrct…
Reading is but one small portion of understanding …
June 23rd, 2003 at 8:06 pm
Hey, Fred! I realize that nobody needs me to defend their comments, but the only person writing “J2EE” here seems to be, um, you. Hani seems to have only written “EJB” in all his references to specifications. Weird, huh?
June 24th, 2003 at 2:47 am
@Dave
I agree that writing all the interfaces and xml descriptors is stupid repetitive work. You want to just write one class and that’s it? Well that’s where XDoclet comes in. Since we started using XDoclet I haven’t written a single interface or deployment descriptor anymore.
So if you have to work with EJB’s have a look at XDoclet, it really makes your live a lot better
June 24th, 2003 at 8:46 am
Gosh, Fred, you are a bloody retard! Stop masturbating and spend *at least* two minutes proof-reading your comments. You are annoying.
June 24th, 2003 at 9:55 am
XDoclet: I really dislike it because you still have to write the stuff that goes in the descriptors; you just write it in the javadoc instead of a seperate file. Marginally easier, but why write it at all? The vast majority of what goes in the descriptor is the same (or based on the classname). I mean, you’re almost always gonna make the JNDI name the fully-qualified home interface name. You’re almost always gonna use no security on any methods and the default transaction configuration. Your XML ends up just stating the classnames. You only just need to know the fully-qualified name of the implementation, and sensible defaults can be determined from that.
Plus, with XDoclet, you have to learn a whole new set of magic-keys in addition to the those you need to know for the descriptor.
June 24th, 2003 at 10:53 am
Dave,
i agree with you on xdoclet thingy. it brings another layer of pain. if you are job is writing ejb any single day, then do the invesment and learn it. if you write ejb once a month don’t even bother, it is not worth it. people can come up with their own way of generating files/code as the way they like it; just like i did.
June 26th, 2003 at 10:11 am
Ironically, JBoss gets round many of the limitations of EJBQL you mentioned. You can use dates, do ‘order by’, even drop down to raw sql if it just gets too horrible.
And we do all that from inside XDoclet.
By the way, many serious systems have complicated requirements for EJBs – we often have to use non-default transactional settings, different remote and local interfaces (it’s called encapsulation), at which point generation tools like xdoclet become a godsend.
I agree about cross-module CMR though. At the very least, you should be able to have unidirectional relationships from module B pointing to a bean in module A where the writer of module A doesn’t need to know that B exists.
June 29th, 2003 at 3:00 am
I agree with most of your statements.
- The intermodule relation missing is very bad. A while ago i had to make session facades to supply his need. but it costs a lot more of sql execution.
I agree with chris about jboss-ql. It’s a lot powerful, and usable, because raw ejb is impossible to use alone in a serious project. But for the other side, it’s out of the spec.
Although it could be better. In some tests I did, jboss (and others EJB containers do worse) made too many sql’s for the job at hand, even using eg : when you are asking for 10 ejb’s MyEJB that are related to other 2 (for each MyEJB instance), jboss would generate 1 sql for getting the 10 MyEJB’s instances, and more 20 to get the relationships. I did once a feature request (a suggestion really) at jboss tracker (http://sourceforge.net/tracker/?func=detail&aid=626893&group_id=22866&atid=376685), 10/2002, but it’s still opened. I think this could reduce a lot of sql’s queries and be usable to make reports even.
At really, this last problem was one of the reasons why a company for which I worked for gave up to using EJB, but they just went to the other extreme : pl-sql, urghhhh :)of course, not for my indication :)
well. right now i’m more to the O/R tools (like hibernate or JDO) without all of that heavy-weight of EJB.
March 16th, 2004 at 2:53 am
I know I a bit late to this thread but I felt I did need to put something down so there is a record of where I stood.
I remember hand coding the required ejb interfaces when I used Weblogic 3.something in the last century. I remember writing up the descriptor and generating the myejb.ser file. I haven’t done that in a long time. Now I have pretty good skills in the various J2EE IDEs put out by the vendors. I have been using them ever since they got to the stage where they were usable. Anybody remember Visual Cafe here? Or Visual Age? Can anyone remember Sun’s first Java IDE?
Now I just point and click and have 99% of the work done for me using the ide. This has meant that I can work on much larger problems involving more entity beans than mere mortals can handle with notepad or vi.
One of the posters talked about remote transactions. He was close but just. Try distributed transactions across multiple databases. Try engineering a system where reads, writes and updates are all happening concurrently with hundreds of sessions. I was fortunate enough to have actually designed such a system using CORBA and C++ and to this day I am not sure how I pulled that one off. However, that is not an experience I would like to repeat again. Now a days I build systems like those as if they are a clam stroll in a park.
Despite the various annoyances in the spec and implementation, I am more relaxed now since I am empowered to build complex distributed transactional systems. The combination of good tools and reasonably un-ambigous specifications has meant that 99% of the architecture and design decisions have been taken out of my hands. Now I spend most of my clients money mapping the domain models and requirements to various types of ejbs. The design search space has become much smaller, resulting in a much smarter me.
I am glad ejbs exist, all three types. Now if only the gods that be could come up with a way to generate EJBs from use cases, I could seriously consider moving to a warm sunny place.