When to not use EJB

[paul wheaton]

Developing a simple method as an EJB turns out to be a fairly complicated matter. Many files to define the bean. Many lines of code to get the home, get the remote and then make the method call.
There are times when the security gets in your way, or you decide that you want to do security a different way.
The CMT can be cool, but it doesn't take a lot of code to do it manually for those times that you need it.
I'm not a big fan of CMP - preferring my own persistance stuff.
I suppose that when using EJB, I can gain the failover and distributed system stuff that comes with J2EE and EJB, but there can be other ways to handle that sort of thing that aren't too complicated.
There have been several EJB projects I have worked on in the past where when the project was done, the developers held the opinion "We could have finished 20% faster if we didn't use EJB and if we used other stuff for where the EJB parts were."
I guess I would really like to see a discussion on when not to use EJB. And maybe even a discussion of projects where all of the complexity of EJB is well worth it.
Anybody have any experiences they want to share? Opinions?

[Chris Mathews]

Ok, I'm game! I think it is about time for another EJB bloodbath.
These days, it is becoming more and more rare for me to find cases where I think EJB is appropriate. However, that says as much or more about my personal changes in thinking and development practices as it does about EJB. Regardless, let's review the reasons that are most often cited for using EJBs.
Remotability:
This one is fairly easy to understand. However nowadays many people, myself included, try to stay away from large distributed systems unless it is absolutely necessary. The reason is that they don't usually pay off. The perceived decoupling advantage never really pulls it weight and these systems always seem to perform like dogs. Martin Fowler had a nice article (requires registration) describing the evils of unnecessarily distributed systems in SD last year (from content in his PEAA book). Therefore, it is questionable how useful the distributed nature of EJBs are.
Security:
I don't know about you but I have never really considered J2EE Security a proper solution. There are huge gaps missing from the specification for things such as user management and SSO. This adds up to the fact that it is hard to use J2EE Security for real-world solutions without pervasive use of vendor extensions. For this reason, most projects that I have ever worked on have relied third-party solutions such as SiteMinder for security.
Persistence:
Does anybody actually like working with CMP? They are hard to develop (almost bearable if you are using XDoclet), hard to test (in-Container testing is the only option here), and not very flexible. There are many other persistence layers that are more than a match for CMP. My favorite persistence tool right now is Hibernate. This tool just rocks! It supports everything that was good about CMP and has none of those things that make it a pain. Sure you still have config files, but only one and it is easily managed. The best thing about Hibernate (and JDO for that matter) is that it works off of POJOs which make development and testing very easy.
Caching:
I think this one is really a red herring. None of the big EJB Containers support a truly distributed cache out-of-the-box, so in a clustered environment (which is most of the time for large EJB projects) a third-party solution is still required for good caching. Any good ORM tool supports caching as well, so EJBs still don't bring anything additional to the table. For example, Hibernate supports multiple caching products including Tangosol Coherence, EHCache, and Jakarta JCS. Whenever the JCache Specification is finally finished (hurry up Cameron!) then I am sure that Gavin and crew will add support for that as well.
So far things aren't looking very good for our old friend EJB... but we now come to the light at the end of the tunnel: Messaging and Transactioning.
Messaging:
One of the good things that EJB 2.0 brought to the table was the addition of Message Driven Beans. MDBs are quite simply fantastic. This is one area of the specification that they really nailed. They are easy to use, develop, and test (in this case they are easy to mock out). I don't think I ever want to work on a large-scale messaging project without the use of MDBs.
Transactioning:
Plain and simple - demarcating transactions in EJB is dead-easy. Using Two-Phase Commit in EJB is dead-easy. Those two things hold a lot a weight for systems that have large-scale transactional requirements. In this case using EJB makes a whole lot of sense, especially if you have to deal with 2PC and multiple transactional resources. I know that I am not about to try to reinvent the Transaction Manager wheel on my projects, it is just too risky. However, it is important to note that lightweight Frameworks such as Spring and even
JBoss's new AOP stuff are now showing up with transactional support similar to EJB that can be demarcated on POJOs. In these cases all you need is a JTA implementation and you are good to go. I don't think that this type of solution is quite ready for prime time in a high transactional volume system but I have no doubt that at some point in the future they will be. At that point, EJBs will lose their number one advantage in my mind.
So to recap... unless your project is making heavy use of transactions, messaging, or both then I think choosing EJB is a mistake. There are too many good alternatives out there to ignore. Even if EJB is chosen, I recommend keeping its use to a very limited capacity. I feel that all business logic should be placed in POJOs and the persistence layer should be strictly decoupled from EJB (no CMP for me). All of the above benefits of EJBs (with the exception of persistence and caching) can be easily achieved by using EJBs as a thin Decorator-layer on top of POJOs. This type of architecture is easy to develop and test and takes full advantage of the services provided by EJB Containers.
It looks to me that EJB are on their way out (except in a legacy capacity), though I would love to hear alternate opinions.
[ January 20, 2004: Message edited by: Chris Mathews ]

[Lasse Koskela]

Chris pretty much nailed it, in my opinion. One more aspect to add into the soup, though... EJB is a standard and has an edge over, for example, Spring and Hibernate in that sense. Whether that edge has any relevance in the long run, I don't know. Anyway, I wouldn't throw away my EJB books just yet with 3.0 coming and all...

[Tonny Tssagovic]

Well, that's the question I always ask and never get a reply!
I think that Rod Johnson has a good discussion in his book Expert One-on-One: J2EE Design and Development, in the free sample chapter available at Wrox.
It is worthwhile to note that Rod has a new book called �J2EE Development without EJB, Expert One-on-One�.
In my humble opinion, using EJBs is a better idea then having your own framework, even if it is lighter and better for a simple reason;
you can easily hire EJB programmers to work further/maintain your system, and it is not a good idea to learn a new framework, whenever one changes the company.
(Well I don�t know of any �standard� frameworks that give you the power of EJBs, and until then I will stick to EJBs.)
I would suggest that one should give an alternative to EJBs for each of the features EJB has to offer.
For example, when discussing scalability, one could have a load balancer, distributing the load across a farm of web containers (tomcat) and POJOs or simple beans for the Business logic runing inside the servlet container.
I can not think of any situation where EJBs beat simple servlets+ POJOs in perfomrance, IF any of you have seen an EJB app beat a servlet one in performance PLEASE LET ME know that was the question I posted in the performance forum but never got a reply!
I am actually making an application where there is no need for EJBs. Yet I will use them; worst of all, I will have to write a paper explaining why EJBs is the right solution. Kewl hein?(well at least you get scalability for free, by just changing some xml files, and adding up PCs)
I hope to see some arguments in this thread
Rod's new book
Expert sample chapter

[paul wheaton]

Wow, excellent feedback!
I'm putting a lot of time into trying to decide when to use EJB and when to not use EJB. And I think I may have come across a case. LEt me know if you think I'm on the right track ....
A team might work on a "component" of an architecture. Let us suppose that the team has been tasked to provide a service to another team. A computationally expensive component, combined with some persistance. The final product will probably have a thousand classes. They will provide an interface of 20 remote functions to five other teams.
Now, there are ten teams total. Eight teams are working on server "services" items. One team is working on GUI interfaces for outside clients and one team is working on GUI services for inside clients.
On deployment, the default plan is that each team will have one or more servers to handle their load. Some teams might be able to share a box. Some teams might have stuff that is so computationally intensive that they might need several large boxes.
With EJB, the idea is "what if everybody used EJB?". Then rather than having each box be specific to one or two tasks, you could have five boxes be set up to handle five to fifteen tasks. As one task attempts to use the resources of another task, it may or may not be on the same box. As the needs change, what is on each box could be changed.
This is the dream that EJB has always promised. Yet, I have heard from many engineers over time (and experienced it myself) that the implementations of EJB often fall short here.
Would this be a case where modern EJB (stateless session beans) would shine?

[Rufus BugleWeed]

Fowler and Mathews are in favor of the webserver and the EJB container in the same JVM. IBM preaches that the webserver belongs in the DMZ. Anyone care to make the case against the webserver in the DMZ? Obviously the performance is better when co-located.
Websphere is using an Apache dirivative, which is C based. Jboss is using Jetty which could be collacated. The word I hear is JBoss is slow. Anyone one dispute that?
How does BEA implement their solution?

[Chris Mathews]

Originally posted by Rufus BugleWeed:
Fowler and Mathews are in favor of the webserver and the EJB container in the same JVM. IBM preaches that the webserver belongs in the DMZ. Anyone care to make the case against the webserver in the DMZ? Obviously the performance is better when co-located.
Websphere is using an Apache dirivative, which is C based. Jboss is using Jetty which could be collacated. The word I hear is JBoss is slow. Anyone one dispute that?
How does BEA implement their solution?

Let's make the distinction between a Web Container (aka JSP/Servlet Container) and a Web Server (aka HTTP Server). I believe that the Web Container and the EJB Container (if used) should be co-located. I also believe that the Web Server should be in a public-facing DMZ (in big organizations there are usually multiple levels of DMZs). I believe this is completely in accordance with both IBM and Fowler.

[Rufus BugleWeed]

Am I correct that Jetty is an embedded webserver of sorts?

[Lasse Koskela]

Originally posted by Rufus BugleWeed:
Am I correct that Jetty is an embedded webserver of sorts?

Yep. It's 100% Java so you can do something like new HttpServer(), server.start(), register some handlers for incoming HTTP requests, and you're on your way...

[Tonny Tssagovic]

Originally posted by Chris Mathews:

I believe that the Web Container and the EJB Container (if used) should be co-located.

Could anyone of you guys think of a situation where the web-container and app-container should be separated? For example they use different resources, and compete for some resources in such a way that when you put web+app in the same machine you can handle 500 transactions / minute. But when you separate them, the web-container machine can handle 2000 and the app can also handle 2000 TPM. So in the first place, if you had a web server distributing the load to your 2 web+app container bundle, you would end up with 2*500 = 1000 TPM, but if they are separated, you will handle 2000 TPM.

 
 Web server (apache)---- Web container (tomcat)--- app server (Jboss)
 might be better than:

 Web server (apache) ----- Web+app container (Jetty/tomcat+Jboss bundle)
                       |
                       |---Web+app container (Jetty/tomcat+Jboss bundle)

PS: the example is just for simplification, of course in this case you would not have fail-over, and would have a single point of failure. (at the web-container machine, and at the EJB machine).. But you migh as well have a cluster of web containers and a cluster of app servers. (the DB is ignored in here)

[Rufus BugleWeed]

I'm getting up on my IBM soapbox again. Of course this is a proprietary
solution, at least in < 2.0 spec.
IBM supports a seesion affinity to EJB. Websphere 5.0 supports an architecture that is composed of coarse grained entities ( local interfaces ) and IBM's support for horizontal clusters of app servers.
So this satisfies Fowlers recommendation for clustering. Assuming most of the persistent beans a client needs are likely to get loaded into the same JVM his objection to RMI is overcome.
Now if said system is in production it has advantages to a POJO ( Hibernate ) system. Horizontal machines increase availablity. If one fails the load balancer sends all request to the other. Hardware servers can be taken off line for upgades, so in this sense maintainability is better.
Maintainability is more complicated in that multiple servers must be configured.
Now would a high availability package give a persitance layer like Hibernate an equal place in availability?

[Richard Monson-Haefel]

The truth is that EJB is complex and difficult to develop without really good tools like XDoc or similar tools. That's simply a manifestation of the problem space in which EJB resides � transaction processing. The stuff you can do with spring and Hibernate are pretty cool and much easier than EJB, but they are not standard technologies and you are fully dependent on a single implementation when using them. EJB vendors can differentiate themselves based on performance, ease of use, and other things.
<p>
EJB needs to be simplified. No doubt about it, but don't buy into the EJB FUD without carefully considering the alternatives of no standard at all. If you can use Xdoclet or vendor tools to reduce the complexity of your development efforts than by all means do so. In addition, EJB offers configurable transaction and security at the component level � this is something other persistence frameworks don't offer � ASFAIK.
<p>
The EJB 2.0 (JSR 220) expert group has as one of its main goals to simply the programming model offered by EJB. Because of non-disclosure agreements I cannot go into any detail, but suffice to say we are all working hard to make EJB as simple to use as its CMP alternatives like JDO and Hibernate � actually it's my goal to make EJB even simpler.
<p>
In addition, EJB is not just CMP. CMP is only one facet of EJB. The Message-driven bean component, for example, is reason enough to go with EJB for many problems � it�s a very powerful programming model.

[Johannes de Jong]

The Message-driven bean component, for example, is reason enough to go with EJB for many problems � it�s a very powerful programming model.
Amen to that.

[paul wheaton]

I'm now reading "Bitter EJB" which is providing a lot of clarity on this sort of stuff. Also, a lot of folks here are big fans of XDoclet and the more I learn about it, the more it sounds like (when combined with ant) it takes most of the sting (complexity) out of EJB. Although I don't care much for introducing a declarative language to mix in with OO ... Perhaps a new generation of java will come out some day that is a bit more do for enterprise stuff and persistance what Java did for OO.

[Binildas Christudas]

To add to Chris's validations, a few points more (Trying not to point out "with or without any favour to any specific technology", but if it seems to favour any specific technology, it is just coincidence!):
1. Assembling of component transactions is a blessing, when it comes to any technology. This requirement might not be evident in small projects, but I have experienced it a lot in many of my past projects. As we go alongwith our design we will find that in some cases we can call services which were already implemented (using jargon, we call it composite services). To do so, if we dont think of transactions, then we are ignoring a major aspect. OK - what is we consider transaction? Then, the next question is whether the technology supports component level transactions. I know that EJB supports component level transaction in the finest level (surely, there are a lot more things to be done, including support for Nested transactions and all, which I suppose will be addressed by the forthcomming specifications, perhaps EJB4.0 or EJB5.0, if not EJB3.0). Similar stuff can be attained in .NET components, with the help of COM+ services. But now, when we dont use any of these technologies, I haven't found yet a neat solution to this in OOP.
When it comes to deployment (speaking in the context of B2B applications), it would be appropriate for anyone to consider how easy one can send messages accross firewalls, and this is where the use of XML over HTTP comes to our help. But again, when it comes to Composite Services, technology is yet to give a solution to cotrol transactional nature, which I hope will be addressed soon.
2. I am not a pro-CMP evangelist. I say like this not only because the EJB spec is not offering 100% what we need, but also because, even the best commercially available App. Servers implement them in their own ways, and the moment when the number of CMP beans increases in the project, we will be faced with the related issues. Having said this, it would not be nice if I dont highlight the benefits of CMP too - Firstly, CMR. I could say that, CMR could increase developer productivity. Moreover, look at the CMP-CMR code - It shows how object oriented and cleaner we can do stuff with objects. I never say that we cannot do them with JDO, POJO, etc., but my point is:
IT WOULD BE NICE, IF WE HAVE A MORE FEATURE RICH, PROBLEM LESS EJB PARADIGM.
Binildas C. A.
Sr. Technical Architect
US Software (http://www.usswi.com)

[Lasse Koskela]

Binildas, may I ask you to drop by at My Profile and add a second part to your display name (our naming policy requires both a first name and a last name).
Thanks.
[ January 22, 2004: Message edited by: Lasse Koskela ]

[Bill Dudney]

This is a great discussion! I should be writing but instead I'm reading... Ah well...
I was on a fairly large project that had just the situation that Tonny describes below. We had much better throughput by putting the web tier on one set of machines and the ejb tier on another.
We used local cmp entities behind session facades. Although we had great success with this approach, reflecting on the project now I think we might have been better off with session's over something like hibernate. Has anyone built something like this. To borrow Tonny's diagram and slightly change it...
webserver -- web container -- ejb sessions -- hibernate
\
\-- hibernate for read only access
My thoughts are that the read only access stuff that is typically done with JDBC in the web container would be much better done with hibernate (or the like). Also, instead of ejb cmp behind the session facades read/write access done through hibernate. You get all the easy transaction demarcation, distributability etc that you get from ejb (because of your sessions) without having to pay the overhead of entities. I have not had a chance to build a real commercial system of this kind so I'd love to hear any thoughts or experiences.
BTW: I've used xdoclet on other projects and love it, even for hibernate. Some of the example code I've posted on my blog does xdoclet to generate the hibernate xml files.

Originally posted by Tonny Tssagovic:

 
 Web server (apache)---- Web container (tomcat)--- app server (Jboss)
 might be better than:

 Web server (apache) ----- Web+app container (Jetty/tomcat+Jboss bundle)
                       |
                       |---Web+app container (Jetty/tomcat+Jboss bundle)

PS: the example is just for simplification, of course in this case you would not have fail-over, and would have a single point of failure. (at the web-container machine, and at the EJB machine).. But you migh as well have a cluster of web containers and a cluster of app servers. (the DB is ignored in here)

[Pradeep bhatt]

I have read somewhere that EJB 3.0 will make use of POJO?

[Fokko Degenaar]

Security:
I can't agree on that one. The nice thing about having a standard here is to be able to interface to all sorts of proprietary security repositories. We did so and it worked from day #1.
With regard to the deployment descriptors we found security to be much easier to deploy with EJB's than with servlets:
We handled the necessary entries in a simple Excel sheet. One table for use cases and their roles, the other one for EJB methodes and use cases. The XML is generated by a 60-line Excel macro. Copy and paste into ejb-jar.xml, voila. Plus the XML is still human-readable due to being use case oriented.
The only thing we did miss though, was to be able to peek into web.xml and disable a menu entry, if the user is not allowed to invoke the target URL.

[Karthik Guru]

Originally posted by Fokko Degenaar:
Security:
I can't agree on that one. The nice thing about having a standard here is

But I found that J2EE security does'nt integrate with JAAS either.
and it looks that they are promoting JAAS as a standard.

[Fokko Degenaar]

Originally posted by karthik Guru:
But I found that J2EE security doesn't integrate with JAAS either.

At the time we started to develop our application, JAAS wasn't mandatory for app servers, so we used a proprietary interface. AFAIK, all major vendors of J2E servers had one interface or another to connect to a custom security repository.
Anyway, J2EE security and JAAS seem to go together rather well:
JAAS LoginModule in the J2EE Application

[Jonathan Esterhazy]

I read this article in the journal, and had to post a reply. There's a lot of good points and sound thinking in the article, but I think it's a little unfair to EJBs in a couple of areas.
Remotability and Scalability
I thing the intention of these features was to allow you to cope with unexpected load increases, or progressive load increases on production systems, without rearchitecting or reprogramming your application(s). J2EE also lets you scale your web tier and your ejb tier separately. Given these goals, RMI is as good a way as any to hook up a web container and an EJB container that might live on different boxes. And the JNDI lookup stuff is a pretty reasonable way for the web tier to find one of the n servers in the EJB cluster. Of course, the whole Local interface thing ruins this completely. You can avoid this by sticking with remote interfaces and deploying your app to a container smart enough to call locally when possible.
Is this how real organizations manage capacity growth? In a perfect world, no. But if you think about internal corporate applications instead of web sites, it is at least plausible, for a whole bunch of reasons.
- Web sites are light on business logic, high on web tier stuff. In this case, external caches, web switches, load balancing with some sort of session sharing are more efficient, probably simpler solutions.
- Corporate apps that are light on web tier (small number of users), but very demanding on the business end. Think "View account history calls EJB calls CICS transaction that gets the optical library robot to load an offline disk, waits 'til it spins up, then queries a DB/2 data base, then queries an oracle database, then applies a bunch of weird rules before returning a large result set with complicated structure." If your app looks like this, it's nice to be able to scale the business tier separately.
- Also, think about outsourced development. If your developers are in house, it's probably better to carefully analyze the load pattern and resize your application intelligently - upgrade or add hardware related to specific bottlenecks, repartition it, or even make code changes to improve efficiency. But if your app was developed by a contractor, you'd have to rehire them to do this. It's probably a lot cheaper and quicker to throw hardware at your EJB cluster or web tier until the problem goes away, because you can do this without rehiring the contractor.
Security
J2EE security isn't about providing advanced user management or funky authentication features. It's about making it easy for a programmer to define and enforce access restrictions. Programmer make the roles and rules. The container enforces rules. It's the deployer's job to binds these roles to data in the authentication authority. This makes a lot of sense if you are developing a web application that must fit into an existing set of corporate apps -- you don't have to develop account management tools, your administrators can continue using the account tools they are used to, and your users don't need to remember another account. All of this *without* creating some new single sign on system.
If you are creating a totally new app that doesn't need to integrate this way, then this probably seems like a lot of extra steps. Especially when most developers how to store user attributes with JDBC much better than they do JNDI.
Persistence
Yeah, some really good points here.
I did try XDoclet, and it worked, but I don't think this simplified things much. You end up with ejb source files that were written in three or four "languages" (java, javadoc, ejb-ql, and several xml dialects). To change anything (and keep consistent naming etc. across all the parts), you still need to make just as many changes, they just all happen to be in the same file.
I haven't tried Hibernate yet (soon!). It's got lots of good buzz, so maybe it's the real deal. But it's configuration files don't exactly read like "see spot run" either.
Caching
This is a little bit disingenuous for a couple of reasons. First, providing caching features is the job of the container implementor. The EJB spec identifies a number of places where a container (or a programmer) may implement caching, but the spec does not guarantee or mandate any caching anywhere. So if most containers only implement simple, in-container result set caching, blame the implementors, not the spec. And, if there are good third party caching tools available, why would a container implementor create their own?
Second, it's true that a lot of persistence tools now offer caching. But EJB containers with result set caching were available earlier, so, back in the day, they *did* bring something new to the table, or at least make it more widely available.
Conclusion: Chris' article was a good read, and made some really good points, but EJB isn't a useless, obsolete technology, and it has more to offer than the article suggests.

[Karthik Guru]

Originally posted by Fokko Degenaar:

Anyway, J2EE security and JAAS seem to go together rather well:
JAAS LoginModule in the J2EE Application

I read this tutorial. I was wondering as to how would i do this on Weblogic 6.1 which is what i'm using at the moment. What s'd the html form 'action' of login.jsp point to. With form based authentication we specify j_security_check.? The servlet (in case of weblgic) that handles the security part will use one of the realms that has been configured. If I use a JAAS Login Module am not sure how to fit it into this model.
Looks like pramati allows me to specify it through console. To me this seems to be an app server specific solution than a standard.
Not sure how to get it to work with weblogic.
These were my findings:
Unless I know the weblogic specfic class that stores the user and role information for a session I dont think I w'd be able to use JAAS with J2EE declarative security. I mean to achieve this I have to code a login module that accesses weblogic specific classes and programmatically store the user and role information in it. Weblogic can then propogate this information to the web container and then subsequently to the EJB container.
To me this definitely does not look like a *standard* way of integrating JAAS with J2ee declarative security. But this is my opinion and might be wrong.
I think j2ee declarative security is good for method level permissions which probably serves most of the applications. But in the enterprise, authorization is applied at the data level too. So performance is extremely important here. It cannot be an api level security feature. Will companies like SAP, Oracle use J2ee declarative security for their enterprise applications?, I doubt.I think they usually end up designing their own security solutions.
But then I do realize that it's probably unfair to expect j2ee authorization experts to come up with such a generic authorization framework.

[David Armour]

Hi

We have built a service framework that will be deployed to a J2EE application server. One of the first entry points requested is SOAP/JMS. Ok so I want to use MDBs for the JMS work, but I want to deploy the rest of the service framework as POJOs. So how do I get the SOAP message out of the container?

This is one area I also don't like EJBs. It seems like such a one-way choice. It is hard to put together applications which have components that you want to deploy in a composite fashion. If you wanted to take advantage of some of the advanced features of EJBs for remoteability it is clearly difficult to take the rest of the app and deploy it out of the container.

The 3.X spec I believe will be different, highly influenced by POJOs and Hibernate.

Any help on my above issue would be great.

Thank you.

David

[Edward Kenworthy]

No-one seems to have mentioned testing.

Testing, especially unit testing, an application in an app server is a real chore. It's an order of magnitude slower to perform your unit tests when you have to first package then deploy your app before testing and because EJBs are so intrusive you can't choose to mock-up and test your classes outside the app server: they won't run there.

I've used EJBs since 1.1 and I didn't think much of them then (CMP stank and without CMP there didn't seem much point to EJB) and it's gone down hill since, especially in comparison with the competition.

[Mark Lybarger]

nothing like keeping the old thread alive.

anyway. testing with ejb's is getting much much better. cactus was nice, but is afuly slow and a pita to setup and get running. my recent preference is to use in container with openejb. it's F-A-S-T. and if you can use an embedded axion database, you're off and running. then the cactus tests merely need to verify the target environment is ok, not validate the busniess logic (call a simple select method on a bean to ensure the ejbCreate works ok and the bean can get all it's needed references to other beans/db).

0.02$ on a friday morning.

[Ashik Uzzaman]

A similar topic you'll find in the following blog entry.

http://jpgroup.blog-city.com/read/888490.htm

[Charles Sexton]

12 years later has the opinion of EJB changed since the release of version 3.*?

[Anton Golovin]

paul wheaton wrote:Developing a simple method as an EJB turns out to be a fairly complicated matter.  Many files to define the bean.   Many lines of code to get the home, get the remote and then make the method call.  
There are times when the security gets in your way, or you decide that you want to do security a different way.  
The CMT can be cool, but it doesn't take a lot of code to do it manually for those times that you need it.  
I'm not a big fan of CMP - preferring my own persistance stuff.  
I suppose that when using EJB, I can gain the failover and distributed system stuff that comes with J2EE and EJB, but there can be other ways to handle that sort of thing that aren't too complicated.
There have been several EJB projects I have worked on in the past where when the project was done, the developers held the opinion "We could have finished 20% faster if we didn't use EJB and if we used other stuff for where the EJB parts were."
I guess I would really like to see a discussion on when not to use EJB.   And maybe even a discussion of projects where all of the complexity of EJB is well worth it.  
Anybody have any experiences they want to share?  Opinions?

I think when using CMP, you have to still look at what is being generated.

JPA is good, but it must be used correctly. For example, multi-table entity mapping is a must where appropriate to account for joins in the database.

Hibernate provides a fine tool for custom types where you need to write the query by hand. JPA does not - yet. Hopefully, it will be fixed in a future release.

Hibernate will let you use stored procedures, provided they follow certain rules.

So there are some positives and some drawbacks. You can use BMP where appropriate and use the technology of your choice with that.

Sometimes CallableStatement is the best choice. Whatever the technology - use design patterns to ensure refactoring is not difficult in the future.

Hope it was helpful.

With best regards,

Anton.