Discussions

News: J2EE Container Shootout Summary

  1. J2EE Container Shootout Summary (57 messages)

    David Johnson last week posted a summary of interesting questions/responses made by top representatives from JBoss, Oracle, BEA and IBM at a recent North Carolina Java Users Group meeting. Questions covered the need for EJB, the .NET threat, JDO, and future of J2EE.

    Read J2EE Container Shootout Summary.

    Threaded Messages (57)

  2. J2EE Container Shootout Summary[ Go to top ]


    For a while ago I asked this forum is EJB actually improves performance.

    Juergen Hoeller wrote in answer:
    "IMHO: No, in your case Stateless Session Beans won't improve performance, compared to business logic in plain Java classes. Instance pooling of Session Beans doesn't give you any benefits if you just use them locally and don't keep resource references as instance variables in them. On the contrary, Session Beans have the overhead of method call interception that you don't benefit from if you don't use declarative transactions and/or declarative security. The rest is all plain Java logic execution, in both cases."

    Jurgen really knew what he was speaking about, and nobody protested so I though the matter was closed.

    But now says Marc (JBOSS):
    "EJB caches data for web applications very well and can be ten times faster than ordinary database access"

    As I really want to know this and as I understand there is 100.000 members of this forum, many senior consultants, can anybody tell me if EJB (stateless or not) actually improves performance? Or is Marc talking marketing fluff?

    I really appreciate an answer

    Regards
    Rolf Tollerud
     
  3. J2EE Container Shootout Summary[ Go to top ]

    Marc is referring to "Entity" EJBs here, which is a different discussion from Session Beans vs. just plain local Java classes.

    Simple answer: any kind of caching that reduces the number of calls to the database will improve performance. EJB entity beans offer a "standard" way of doing this, albeit at some significant learning curve, and occasionally proprietary vendor extensions to achieve this.

    Depending on your environment, you may find that garden variety caching (ala Tangersol Coherence or java.util.HashMap) meets your needs just fine.
  4. J2EE Container Shootout Summary[ Go to top ]

    David: "Depending on your environment, you may find that garden variety caching (ala Tangersol Coherence or java.util.HashMap) meets your needs just fine."

    p.s. that's Tangosol Coherence ;-)
  5. J2EE Container Shootout Summary[ Go to top ]


    But certainly products like Tangosol Coherence can be used without EJB. Or?

  6. J2EE Container Shootout Summary[ Go to top ]

    What about JONAS ? (www.objectweb.org) The J2EE implementation seems to be excellent and it is a breeze to install and configure. And guess what ? The documentation is free !
    They have just released version 2.6 which adds a lot of cool features. Anyone using this J2EE app server ? What do you think ?
  7. J2EE Container Shootout Summary[ Go to top ]

    Mark Fluery is very articulate and he has some really good points when he speaks. I think Jonas deserves as much visibility as JBoss has if not more. Some time ago, there was a EJB Architecture performance paper published by some university. That was even posted on TSS. I don't have links handy. After reading half way through that report my impression is Jonas-Jeremie combo kicks ass and JBoss container as severe performance penalties due to its use of reflection and dynamic proxies and such. So with Jonas supporting J2EE 1.3 with a proven performance and scalability, I think it deserves a serious look. I am not affliated with Jonas thought it should get its fair share of attention given the overwhelming popularity of JBOSS?
    Anybody has positives or negatives about Jonas? What are your experience with it.
  8. J2EE Container Shootout Summary[ Go to top ]

    Here is the link to the document
    http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf
  9. J2EE Container Shootout Summary[ Go to top ]


    Raj,

    It was extremely interesting to read "Performance and Scalability of EJB Applications" (perf_scalability_ejb.pdf ). I also found this discussion: http://www.theserverside.com/home/thread.jsp?thread_id=14941 entertaining. I don't understand how I could miss that one! And the Java community is fighting MS .NET with EJB entity beans.. Rather funny, the only historical comparison I can think of is the Tulip craze in the 17th century.

    Our project is progressing rather well based upon Tomcat/Velocity with DBCP as connection pool. We plan to add Tyrex later and are looking into Richard Öbergs AOP work.


    Regards
    Rolf Tollerud
  10. J2EE Container Shootout Summary[ Go to top ]

    <snip>
    JBoss container has severe performance penalties due to its use of reflection and dynamic proxies and such.
    </snip>

    Don't know if I would characterize is as severe, but, yes, under Java 1.3, using reflection is slower. However, using Java 1.4, there is no performance hit for reflection. So, as Java 1.4 become the standard, this criticism of JBoss no longer applies.
  11. J2EE Container Shootout Summary[ Go to top ]

    I would like to make it clear. It is not a: JONAS vs JBOSS contest. I think that it is important to have more than 1 option in the open source community in term of J2EE container, it will give more leverage to businesses when it is time to decide on one app server.
  12. J2EE Container Shootout Summary[ Go to top ]

    I think, JOnAS is as great as JBoss. I'm using JOnAS since the beginning
    of my project OpenUSS (around 3 years by now). I must say, for beginners
    in EJB, JOnAS is very easy to use. The documentation of JOnAS is just
    the best, I've ever seen.

    I still remember as I began my project and wanted to choose between
    JBoss and JOnAS (I have to use Open-Source products ;-))).
    Both products were already available. I've choosen JOnAS
    because of its great and easy to understand documentation.
    Luckily you have some good commercial documentations of
    JBoss nowadays. At my time there was no good documentation
    for JBoss.

    You can use JOnAS on a "small" PC or laptop and you can use
    it for "big" servers, no problem at all.

    I like the possibility within JOnAS that you don't have
    to package those EJBs in jar files. Just let them as
    class files in your class directory and start your EJB
    server. This makes the development of EJBs in JOnAS very
    handy and fast.

    You can also integrate JOnAS in your application easily,
    so you can make your J2EE application "ready to run"
    directly without having to install the application server
    separately.


    Regards,
    LoDe.

    OpenUSS (GPL- and J2EE-based E-Learning platform)
    SourceForge: http://sourceforge.net/projects/openuss
    Reference Installation: http://www.openuss.org
  13. J2EE Container Shootout Summary[ Go to top ]

    I don't know which kind of projects you have been working on, but here's a real life example:
    Highly normalized database with information about a special entity, it's attributes etc.. (a bit odbms-like) spread in five to ten tables.
    Constructing the value object takes tens of queries from different tables -> Entity beans *do* improve performance in these situations.
  14. <quote>
    But now says Marc (JBOSS):
    "EJB caches data for web applications very well and can be ten times faster than ordinary database access"
    </quote>

    <quote>
    Marc is referring to "Entity" EJBs here, which is a different discussion from Session Beans vs. just plain local Java classes.

    Simple answer: any kind of caching that reduces the number of calls to the database will improve performance. EJB entity beans offer a "standard" way of doing this, albeit at some significant learning curve, and occasionally proprietary vendor extensions to achieve this.
    </quote>

    Yep, this is the Entity Bean discussion, not the Session Bean one ;-)

    True: Only caching can improve performance compared to direct JDBC. Either do it yourself, or use an O/R toolkit with caching support, like Castor, Hibernate, Jakarta OJB, or some JDO 1.0 compliant toolkit. With such a solution, you are able to reach and surpass the performance benefits of Entity Beans easily.

    Entity Beans are "just another" O/R solution. The drawbacks are method call interception even when using local interfaces, and dependency on the container. The benefits are remote accessibility, declarative transactions, and declarative security. IMHO neither is necessary for entities.

    All of those managed issues should be addressed at the service facade level, for example via Stateless Session Beans, if needed at all. Alternatively, wisely designed plain Java service classes with programmatic transactions would to the job too.

    So, in any case, I don't see a need for container-managed Entity Beans. Plain Java classes persisted by a simple O/R toolkit are not slowed down by method call interception, portable across containers, easier to handle, and especially easier to deploy.

    Unfortunately, most J2EE public promoters, be it from BEA or from JBoss Group, will tell you to use EJB in any case. The guy from Oracle was a notable exception. EJB is so incredibly driven by marketing, even by open source marketing that tells you that now you can use it everywhere without license costs.

    EJB is not the one-size-fits-all magical silver bullet but just one of the tools you can use, if you need some of its particular features. BTW the same applies to JMS, for example, but there noone seems to object. And to WSDL/SOAP-based Web Services, the next "use it everywhere" hype.

    So I suggest to stick to the basics of J2EE: Java, JNDI resources, JTA transactions, Servlets/JSPs, and handy toolkits. Choose EJB Session Beans only if you need distributed remote services, declarative transactions, or declarative security. And forget about Entity Beans, you will probably be better of with a decent O/R toolkit.

    I am really interested if anyone that has actually used both current O/R toolkits and EJB 2.0 Entity Beans favors the latter. Besides "it's included in my container", are there any unique real-life benefits of Entity Beans?

    Regards,
    Juergen
  15. J2EE Container Shootout Summary[ Go to top ]

    To add to the above, I think benefits of caching alone is not compelling to use EJB. Marc should have done better in that answer. If you want to use CMP you don't have to go with EJBs. Look at Resin Enterprise servlet container. They seem to have CMP implementation for servlets. I think they fill a gap here. I haven't used it myself, but may be others who have used can comment on its merits/demerits.
    Even if you want to distribute your remote services, I don't think EJB's are the only solution. With clustering available at the Http Session layer I think EJB solution will be good only for 10% apps that demands the heavy use of its features. For other apps its just adds more overhead than the benefits it provides.

    Also, does any body know whether EJB architecture has HttpSession like kinda functionality. I know about Stateful EJBs but it can't be used from Stateless EJBs, you have to pass some kind of handle to Stateful EJB into the method parameter but that still has some issues like what if the container passivates the stateful when I invoke a stateless ejb by passing to a handle to a stateless ejb.

    I think EJB has a long to way to go and it is already bloated and hard to use in the current version. Look at the concept of "Remote" and "Local" interfaces what a joke. The whole point when CORBA started 10 years ago was to provide location transparency of distributed objects. I guess Sun could not think of a clever idea to overcom the drawbacks of Entity beans and didn't know what do with the ill-conceived entity beans.
      
  16. My thought about EJB.[ Go to top ]

    1)
    >>Resin Enterprise servlet container
    When you talk about the Resin, I think the problem is that your entity bean can be port to different app server(ideally).
    but Resin CMP implementation...
    2)
    I remember the first EJB book told me that EJB is the TMP + COBRA.(sorry, it is not the origin word). As in the old days not every people use CICS/TUXEDO, the traditional TMP, now we don't need to rush to the EJB world. Pain Cobra or C routine can work without any TMP, why pain java object can't live independently.

    3)
    I think declarative security, declarative transaction concept also derive from traditional TMP. Now EJB just standarize it.

    4)
    As Remote interface, it does give us the convenient way to implement distribution programming. The question is that, is everyone need distribution programing?
    ****Hence we get to Fowler's First Rule of Distributed Object Design: don't distribute your objects! *****




  17. J2EE Container Shootout Summary[ Go to top ]

    One additional note regarding caching: It gets very, very, *very* hard to do once you go to a clustered environment. Once you are clustered, you have a few choices:

    1) You end up having to localize your cache on one machine, in which case you pay a network hit to access the cache which will likely be as bad or worse than the hit of going to the database

    2) You end up writing some *very* hairy syncronization code across your clustered servers. I'm not convinced this can be done in a fool-proof way.

    3) Yuo can use a 3rd party clustered cache and hope that the 3rd party has done a good job with the issues above.

    And after you've dealt with all that, you *still* have the perpetual worry with caches of any kind: some damned fool has "gone behind" you, and your cache is out of sync. It's one think to have a cache on a chip, where there is little risk of the cache getting out of wack. In a j2ee app with a relational db backing it, there are likely multiple entry points that you have no control over that can make your cache worthless and cause concurency issues.

    Sorry to sound so pessimistic, but that's my take.

    Cheers,
    Carson
  18. J2EE Container Shootout Summary[ Go to top ]

    Carson,

    1) You end up having to localize your cache on one machine, in which case you pay a network hit to access the cache which will likely be as bad or worse than the hit of going to the database

    A cache does not have to be located on one machine. There are replicated caches, and there are distributed caches. (There are a lot of products, including our Coherence product, and GemStone and Persistence and TimesTen and ....)

    Database latency is measured in tens of milliseconds or even hundreds of milliseconds. I can't speak for our competitors, but our cache latency is measured in microseconds.

    2) You end up writing some *very* hairy syncronization code across your clustered servers. I'm not convinced this can be done in a fool-proof way.

    Build a system that even a fool could use, and only a fool would want to use it ;-)

    It is difficult code to design, to write and (mostly) to test, but a good design at least makes it possible.

    3) Yuo can use a 3rd party clustered cache and hope that the 3rd party has done a good job with the issues above.

    See sig.

    You trust someone every time you use software. The OS vendor. The DB vendor. And for distributed caching, most of the players are DB vendors (the old OODBMS C++/Smalltalk/OMG/ODMG etc. vendors).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  19. J2EE Container Shootout Summary[ Go to top ]

    Cameron,

    *If* I were going to rely on a distributed cache, I'd probably rely on yours. If only because you seem to be the least arrogant vendor on this board. Course, I would rather just get a nice big *nix server with plenty of processors and plenty of ram and a cryogenically frozen engineer to fix it if it ever goes down. No network calls, no distributed computing, just a lot of memory. IBM offers stuff like that, right? :-)

    You didn't discuss the "slip behind" problem with j2ee caches and databases. As long as a DBA has a SQL interface to your database, you are in danger. And you can forget about non-java batch processing, unless it comunicates with your cache somehow. Ugly ugly.

    Suffice it to say, I think there are problems with caching in j2ee apps and that, in my experience, often the complexity (even if it isn't immediately apparant) you add outweighs the performance gain. This is especially true in the intranet space, where systems have lots of players. Maybe not as true for internet sites, where the system is more controlled. But I would bet that there are problems there too.

    Anyway, I'm sure Tangosol is great, and is done as well as a distributed j2ee cache can be done.

    Cheers,
    Carson
  20. J2EE Container Shootout Summary[ Go to top ]

    "are there any unique real-life benefits of Entity Beans?
    "

    This whole thread misses the two MAIN EJB benefits:

    1. STANDARDIZATION (i.e. if similar things are done in different places do them the SAME way. For the dense of skull examples might be railroad track guage, Pipe sizes, battery sizes, electrical outlets etc. )

    2. NORMALIZATION (i.e. If the same thing is done in many places eliminate redundancy by replacing many, possibly standard, implementations with ONE or a FEW that are shared. examples include Power plants vs. Home Power generation, Networks, Mass Trainsit, etc.)
  21. J2EE Container Shootout Summary[ Go to top ]

    Too bad there aren't any decent O/R tools.

    JDO is a disaster.
    Entity Beans are a disaster.
    OJB shows some promise, but isn't (or at least a month ago wasn't) there yet.
    Cocobase was a nightmare.
    Toplink... Well, I dunno, I haven't used it, but I'm a cynic.

    JDBC sucks, but the alternatives suck worse. Roll your own dynamic sql generator and get on with it...
  22. J2EE Container Shootout Summary[ Go to top ]

    You'd never use Entity beans for performance I'm afraid. Stateless Session Beans outperform Entity beans on all products we've evaluated. Caching helps, but Commit option A (data and object caching) has severe limitations (can't cluster, must have exclusive db access etc) - but never gets as fast as SLSBs (even for mostly RO operations).

    However, scalability is another aspect. Using Entity beans with commit option A does reduce the load on the db machine and therefore possibly allows for a higher throughput with fixed db resources cf SLSB approach.

    Some vendors have clever approaches to caching - e.g. one allows cache synch across containers, another has a sort of "optimisitic concurrency" caching approach (basically use the cached data and throw an exception at commit time if it wasn't valid).

    Having said that however, if you want good Entity bean performance you can get it - just pick the right product. We found that the performance of the product with the best Entity bean performance was better than SLSB performance of 3 other products. Check out:

    www.cmis.csiro.au/sact

    Regards,
    Paul Brebner
    CSIRO
  23. J2EE Container Shootout Summary[ Go to top ]

    Paul: "You'd never use Entity beans for performance I'm afraid. Stateless Session Beans outperform Entity beans on all products we've evaluated. Caching helps, but Commit option A (data and object caching) has severe limitations (can't cluster, must have exclusive db access etc) - but never gets as fast as SLSBs (even for mostly RO operations)."

    That used to be true ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  24. J2EE Container Shootout Summary[ Go to top ]

    Oh cripes... not the EJB FUD crowd again. I have 2 things I want to say:

    1) There are no J2EE systems anywhere in the world that have been around for more than 3 years!!!! EJB or rather "componentizing" your software is a hedge against future entropy and much of the return on investment will not be realized until further into your effort's lifecycle.

    It is true that many systems will not see a benefit from EJB - and this is a point worth making, however notice the word "ENTERPRISE" ... this is something likely long lived and critical, where adding a few more hours to properly make a deployment descriptor etc. or the overhead of administering an EJB app server is trivial. In return there is a single source of truth available in your enterprise for concept X. I don't know about you - but I have worked at many places where knowledge how everything works together (from an IT system's perspective) is pretty sketchy. I don't think that the "Employee EJB" will ever lose its identity, do you?

    If you are implementing a system which will continue to be expanded, and be long lived... you should seriously consider EJB in "that light", and not only whether or not they are absolutely required at the moment.

    If you are not developing such a system and you don't see an advantage to using EJB - that's fine but it hardly makes EJB pointless or worthless.



    2) RE: entity beans. First off - anyone posting general remarks about stateless session vs entity beans is doing novice readers in this forum a great disservice. The two are different in very fundamental ways. Regardless - I think most of these statements are meant to refer to using EJBs for O/R mapping with simple CRUD type operations. Again - even in this more specific scenario there are too many parameters left undefined to make a blanket performance statement... but: 1) with entity beans, you have a convenient hook into the lifecycle of your domain objects (ie the ejbCRUD methods)... this can be used to easily add all kinds of functionality to your domain... datawarehousing, versioning, logging, sanity check like stringent time sync policies etc, JMX???....) 2) Entity EJBs with optimistic concurrency combined with container caching means HUGE HUGE HUGE performance and scalability advantages over stateless session CRUD in situations where you care about isolating concurrent transactions (common scenarios) and you want your services layer not to worry about what order to call domain objects in, but rather concentrate on solving their problem. I really think the aforementioned is one of the most common scenarios. 3) Read-only entity bean option for work with relaxed transactional integrity requirements (generating a contact list with phone #s for example... who cares if one phone numbers changed during the course of the list generation). 4) the container managed relationships between the entities are a pleasure to use when writing services for your domain.

    One final note to novices comparing session vs entity performance because this point is often missed. Make sure you wrap your entity bean calls in a transaction... otherwise each 'get' / 'set' will initiate a load/store call to the db.

    cheers,
    Markus
  25. J2EE Container Shootout Summary[ Go to top ]

    Nobody is saying that the idea of components are bad. When people about EJB they usually mean the way it is implemented. Components are good but EJB technology makes people think is it really worth it. There is plenty of room for all sorts of component technology as long as they speak a common wire protocol and EJB is not the holy grail.
  26. <quote>
    Oh cripes... not the EJB FUD crowd again.
    </quote>

    *sigh* I'm trying to be as constructive as possible here, and all I'm earning is the FUD label...

    <quote>
    RE: entity beans. First off - anyone posting general remarks about stateless session vs entity beans is doing novice readers in this forum a great disservice. The two are different in very fundamental ways. (...)
    </quote>

    In a nutshell, the issues are (local) Session Beans vs. plain Java service classes with programmatic JTA, and (local) Entity Beans vs. an O/R toolkit. Both a very valid points IMHO. Every good O/R toolkit gives you all the persistence benefits of Entity Beans including caching, without the overhead of managed components.

    EJB is designed for declarative management, at the price of method call interception: especially declarative transactions and declarative security. That's a fair tradeoff, but avoiding that overhead and sticking to programmatic transactions is just as valid.

    The real disservice is promoting EJB as the one-size-fits-all solution for every system. This is the reason why novice readers tend to get the impression that J2EE is necessarily complex, even for rather simple systems.

    J2EE can be as simple as PHP for dynamic websites, as comfortable as .NET for rich web applications, and as powerful and complex as full-blown transaction processing systems for heavy load enterprise systems. It can be tailored to all that levels and more, but it does not need to be as complex as the latter in every case.

    EJB stems from the TP world, and it is definitely well suited for modern TP-centric enterprise systems. But what about web-centric applications with simple transactional requirements? IMHO it's better to avoid the TP complexity and stick to handier solutions here. A basic engineering principle: Choose the appropriate tool for the task at hand.

    <quote>
    This whole thread misses the two MAIN EJB benefits:
    1. STANDARDIZATION (...)
    2. NORMALIZATION (...)
    </quote>

    Good points, but IMHO tying "standard" persistence, "standard" remote accessibility, and declarative transaction management into one single component model is not ideal. The latter two result in Session Beans which is fine - as a choice for those who need the particular benefits. But combining all three into Entity Beans when most applications just need plain persistence is overkill. I consider an O/R toolkit that is much more flexible when it comes to persistence options the better choice in these cases.

    Let me repeat my main point concerning Entity Beans: Besides "it's included in my container", are there any unique real-life benefits of Entity Beans - compared to a much handier persistence toolkits like Castor, Hibernate, or Jakarta OJB?

    Juergen
  27. J2EE Container Shootout Summary[ Go to top ]

    "Good points, but IMHO tying "standard" persistence, "standard" remote accessibility, and declarative transaction management into one single component model is not ideal."

    You can argue the idealness all day long of:
    Outlet voltage: 120v/60hz vs. 12v DC
    video format: VHS vs. Betamax
    Fuels: gasoline vs. electric cars
    etc.

    However, the power of the standard(defacto or otherwise) overcomes the technical benefits of any alternative.

    Matt

  28. J2EE Container Shootout Summary[ Go to top ]

    Cameron,

    I would like this to be true :-)
    Do you have any figures to support this, and are you comparing SLSBs with "normal" CMP Entity beans, or something
    stranger (and proprietary?)

    Regards,

    Paul
    CSIRO
  29. J2EE Container Shootout Summary[ Go to top ]

    Paul: "I would like this to be true :-) Do you have any figures to support this, and are you comparing SLSBs with "normal" CMP Entity beans, or something stranger (and proprietary?)"

    I'm talking about transactional caching of standard CMP entity beans in a cluster. (As you know, it's the standard that makes them easy to cache. It defines both when and how the data gets loaded and stored, and what the data is that is getting loaded and stored, and how the transactions are to be managed.)

    You can get some of the benefit already with inter-transactional optimistic caching in BEA WL 7.0 ... an interesting approach (which assumes a read-mostly pattern, since otherwise the cost of rollback & repeat would be extraordinary). But I'm talking about caching that actually keeps the data in the entire cluster in sync (using transactions) with the database, so that ejbFindByPK, ejbLoad, and even ejbStore (with write-behind caching) can be managed in the cache in the app tier.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  30. J2EE Container Shootout Summary[ Go to top ]

    Cameron,

    Hi again. Sorry to keep pressing on this, but we havn't observed this type of improvement with caching.

    Let's just talk about non-clustered configuration for a moment, and comparing SLSB + JDBC vs SLSB wrapper around CMP Entity beans patterns with option A caching, with mostly RO transactions (80% in fact).

    We have not yet observed a product that has faster CMP + caching performance than SLSB performance. However, some products do have faster CMP than other products SLSB performance :-)

    I agree this is somewhat counterintuitive, however we suspect that data caching doesn't exceed SLSB perf in products we've evaluated possibly because:

    1 Caching has overheads
    2 Depends on how the data is accessed and hit-ratios etc
    3 There is a cost of the call from SLSB to Entity bean in EJB 1.1 (In 2.0 you can just use a local interface however)
    4 In SLSB + JDBC case the database is caching everything anyway.

    I'd be happy to take this discussion offline and work out ways to modify our tests and or test your products directly to determine what's really happening.

    Email me Paul dot Brebner at csiro dot au

    Cheers,

    Paul.




  31. J2EE Container Shootout Summary[ Go to top ]

    Hi Paul -

    You are correct that blind caching isn't always the solution. If the overhead outweighs the work then it can cause problems. However, in my experience on enterprise clusters, the DB is the bottleneck. When trying to get a successful cluster you want to minimize the areas of contention so you can scale. Adding boxes doesn't help at all if you are just causing more and more work to be done by the DB which can't handle it.

    We are seeing this first hand with clustering with TSS. We have just plugged in Coherence and it has been a god send. It is perfectly suited to us, as we are very heavy on reads. This means that we rarely have to even touch the database. The speed of the replicated caching is fantastic, so getting access to our value objects feels like it is just a local method on a HashMap.

    Again, this is helping us, as it allows us to scale our app server tier, and our poor db doesn't get overwhelmed. If our application was writing 99.9% of the time then we wouldn't see as many benefits.

    Caching can be a lifesaver, as long as you are smart about it!

    Dion
  32. J2EE Container Shootout Summary[ Go to top ]

    As I really want to know this and as I understand there is

    > 100.000 members of this forum, many senior consultants, can
    > anybody tell me if EJB (stateless or not) actually improves
    > performance?

    That largely depends on what you mean by performance: Just off the top of my head I can think of four ways of answering the question...

    Single box performance
    Whole system performance (aka Scalability)
    Code performance
    DB performance

    So if you would like to refine your question somewhat, I'm sure that we'd be glad to answer it.


    BTW: In my option the quick answers to the above would be

    Single box: Probabably not. EJBs are about scalability which generally is an overhead on a single box.

    Scalability: Resounding Yes. That is what they're there for, after all.

    Code: No.

    DB: Possibly, in the sense that Entity Beans are a DB cache. Real-world useage patterns would dictate the answer to that one.


    Hope that helps

    /david
  33. J2EE Container Shootout Summary[ Go to top ]


    Thank you Dave,

    Our application (a rich intranet web application) would almost always reside on a single box and with database on another box of course.

    Your remarks confirm my more or less unconscious belief (not having any real life experience of EJB) the EJB is only for the very, very large loads. But I had no idea that this was such heated subject, almost like a Java - .NET discussion!

    Regards
    Rolf Tollerud
     
  34. J2EE Container Shootout Summary[ Go to top ]

    Your remarks confirm my more or less unconscious belief

    >(not having any real life experience of EJB) the EJB is only
    > for the very, very large loads.

    Of course the other performance aspects that I forgot in my initial run through are concurrency (simultaneous clients) and availablity (response time).

    These are areas where EJBs (when used correctly - hence the much discussed Patterns) can definitely improve performance and do apply to one box.

    Oh, yes, and there is throughput as a performance angle, and I have no idea how EJBs use affects that.


    To me, to reduce the discussion about EJBs to merely performance misses several key points:

      Scalability. It is not a no-brainer, but scalability (as in just-add hardware) is made a lot easier.

      Knowledge reuse. You can take the same coding knowledge (and occasionally even code!) from JBoss running on your lap-top and use it on the million dollar plus IBM/BEA servers. (And I'm not saying JBoss is only for the laptop - in case anyone wants to start on ;-)

      Simplification (believe it or not!). They allow you to forget about the complexities of distributed systems, concurrent systems and (within the EJB rules) concentrate on the application logic and data modelling.
      
    Hope this helps
    /david
  35. J2EE Container Shootout Summary[ Go to top ]

    " (And I'm not saying JBoss is only for the laptop - in case anyone wants to start on ;-)
    "

    You should be careful here. Given the very poor performance characteristics of JBOSS in certain subsystems (like CMP) you could be lead to believe that it is not viable.

    I believe this situation has led many to believe that entity beans in general and CMP in particular perform an order of magnitude slower than SB+SQL. When in fact, on leading commercial app servers the difference is more like 20%-30% without even turning on caching or field grouping optimizations.

    (this data is based on independent testing)
    Matt
  36. J2EE Container Shootout Summary[ Go to top ]

    "
    I believe this situation has led many to believe that entity beans in general and CMP in particular perform an order of magnitude slower than SB+SQL. When in fact, on leading commercial app servers the difference is more like 20%-30% without even turning on caching or field grouping optimizations.

    "

    Sure. It's only 20-30% slower. You get a severely hamstrung version of SQL to work with. You are *not* able to do any sort of dynamic SQL(1), even with the proprietary extenstions that weblogic has introduced to deal with EJBQL. You don't have any good tools for maintaining the coherence between your data model and your object model. Gee, why *wouldn't* I use entity beans?

    grumble, grumble,
    Carson

    (1) By dynamic sql, I mean the following: a sql statement that changes *form*, not *content* depending on inputs. This is especially useful when you are doing a select. Consider a multi-select list in a UI that contains "A", "B", "C" and "ALL"

    If the user selects "A" then your sql looks like:

    SELECT * FROM some_table WHERE some_column in ("A")

    If the user selects "A" and "B" you get:

    SELECT * FROM some_table WHERE some_column in ("A", "B")

    If the user selects all, you get:

    SELECT * FROM some_table

    Try doing *that* with entity beans...
  37. J2EE Container Shootout Summary[ Go to top ]

    Dynamic sql has its own set of performance and maintenance problems, at least on SQL Server. You don't get a stored query plan when you use dynamic sql so the database can't re-use the execution plan.
    Also, have you tried to debug a moderately complex dynamic sql? It is a maintenance headache.
  38. J2EE Container Shootout Summary[ Go to top ]

    "
    Dynamic sql has its own set of performance and maintenance problems, at least on SQL Server. You don't get a stored query plan when you use dynamic sql so the database can't re-use the execution plan.
    Also, have you tried to debug a moderately complex dynamic sql? It is a maintenance headache.

    "

    Agreed, but the functionality boon is often well worth the tradeoff. Especially if you are essentiall writing a query generator for a back-end data store.

    And yes, I've tried to debug moderately complex dynamic sql. And yes, it can be a bit of a pain. But I tend to construct a StringBuffer with a prepared statement-style query, then print the query to std_out so I can see exactly what's being run. As long as I can see the query, I can usually see what is going wrong. Hell of a lot easier to debug than the obscure EJB exceptions that app servers chuck when things get messy, in my opinion.

    Hmmm. For my first real thread here, I'm not making any friends...

    Cheers,
    Carson
  39. J2EE Container Shootout Summary[ Go to top ]

    I'm just trying to point out some of the difficulties I've encountered with dynamic sql. It's flexibility comes at price. Developers love it - DBA's hate it. Some sites don't allow dynamic sql because it opens them up to possible sql injection attacks.

    I guess it depends on the application you are writing. If you're writing a query generator for a database, I'm not sure if EJB is the tool. It's not intended to solve every problem under the sun - no pun intended.

  40. J2EE Container Shootout Summary[ Go to top ]

    Hi PPl posted this on the discussion page earlier... I think it raises some interesting issues. Comments welcome...

    I've been looking through alot of EJB material but I have a couple of questions:

    Why would anyone want to use EJBs?

    Ive read all the "blurb" that says only use EJBs when you need them etc (Gartner, etc..) But I can't figure out a REAL reason to use them. Aren't all the "services" that the EJB contianer provides available in any good Servlet container and a decent web application framework?

    For example:

    1. Transactions: can be done using JNDI lookups for the UserTransaction in the Servlet. Which can used across different/multiple transactional resources/managers (hope my terminology is correct :~]) Agreed, the Servlet contaner doesn't allow for declarative transactions so I guess thats one advantage of EJBs. But apart from that I see no other benefit when it cones to using transactions. Please give any other examples if there are any...?

    2. Security can be handled by the Servlet container in a "portable" way using JAAS and the deployment descriptor. So why use EJB authentication?

    3. Scalability: People on this forum and others argue that EJB apps are implicitly (by their nature) more scaleable than Servlet and JSP (only) applications. Why is this the case? I know that EJBs are pooled, etc but if the EJBs are accessed via servlets, (as is the case in most situations), and the sevlet container is "not" considered to be scaleabe isn't this always going to be a bottleneck? So What difference would it make?

    4. Asynchronous messaging: On server startup a Servlet can be configured to be run its init() method via the deployment descriptor. In this method it can set up any helper classes (That implement the MessageListener interface) and subscribe to any Queues/Topics. So a servlet CAN act as an asynchronous message listener. Why is it better (or is it better) to use MDBs instead? What advantages do MDBs provide over this Servlet approach?

    5. Preserving state: The HttpSession can be used to preserve state. Why would anyone want to use a SSB instead?

    6. CMP: Admittedly the servlet container doesn't provide CMP. but is CMP actually viable for large scale systems? (I don't know thats why Im asking... :-]). And with all the complaints I've heared about Entity beans (heavy weight on the server etc) why would anyone want to go down that route? We could just use JDO instead (it not mature etc... but it works! :~]). Also for batch data access... a DAO, some sort of factory, DTO collection and JDBC could be used!

    7. Cacheing: a relatively difficult problem anyway... i.e. data consistency between multiple nodes/JVMs etc .And until the JSR that "specifies" multiple node caching is finished (if it ever is...!) I dont know if Entity bean cacheing solves this problem? Does it?

    I agree that using EJBs gives you the advantages of remoting (although this is now discouraged and LocalInterfaces are prefered for performance reasons), ability so serve multiple kinds of clients (fat and web), declarative transactions. BUT if any of these things are not required ... WHY USE EJBs? Are there any other compelling reasons to use them?

    Thanks in advance for your replies... :~]

    Smythe
  41. J2EE Container Shootout Summary[ Go to top ]

    Smythe,

    you have stated very valid points. I have discussed these issues a lot at TSS, for example in an earlier post in this thread, with the following conclusion:

    <quote>
    So I suggest to stick to the basics of J2EE: Java, JNDI resources, JTA transactions, Servlets/JSPs, and handy toolkits. Choose EJB Session Beans only if you need distributed remote services, declarative transactions, or declarative security. And forget about Entity Beans, you will probably be better of with a decent O/R toolkit.
    </quote>

    ad 1. Transactions: You are right, the only advantage of EJB over direct JTA usage is declarative transaction demarcation.

    ad 2. Security: Same here, declarative security at the component level. IMHO this only makes sense for remotely accessible backend components with own security needs that get accessed by multiple applications with different user bases.

    ad 3. Scalability: EJB is considered more scaleable sometimes because of Session Bean instance pooling. Note that Stateless Session Beans instances can hold non-session-specific state like resource connections. But if you write plain Java service classes and only access connections and transactions in your method imlementations without keeping them in instances, you will get just as much scalability as with Stateless Session Beans because pooling doesn't provide any benefits in this case. BTW holding resource factories like DataSources in such singletons is no problem at all.
    One advantage of Session Beans are that they can be distributed: A JNDI lookup returns one of the load-balanced backend beans. Still, most mid-size servers are clustered at the web server level (with HttpSession replication) and not at the remote object server level.

    ad 4. Asynchronous messaging: The only advantage of Message-Driven Beans that I can see is being managed by the container. They are initialized at container startup in a standardized way. And they get pooled but with the same limited benefits as Stateless Session Beans.

    ad 5. Preserving state: You can access the SFSB from both HttpSessions and rich clients (the latter directly access the SFSB stub). Nevertheless, I prefer to write business logic in reusable plain Java service classes that are used in either web control logic or rich client control logic (indirectly in both cases). This approach also allows for other RPC toolkits than RMI, e.g. SOAP-based or other HTTP-based ones (like Caucho's Hessian and Burlap).

    ad 6. CMP: As I have elaborated at numerous times at TSS, I prefer the pure persistence approach, i.e. a toolkit that concentrates on lightweight persistence and separates it from remote accessibility and declarative transactions. If you need the latter two, you can access your entity classes and your O/R toolkit from a Session Bean facade. JDO is flawed IMHO because of certain quirks, but there are some decent toolkits around, like Castor, Hibernate, and Jakarta OJB.

    ad 7. Caching: AFAIK distributed caching of Entity Beans is very hard to achieve, and hardly any container provides it in a reliable way. Anyway, you don't need EJB for distributed caching: There are toolkits that concentrate on this core competence and provide a very simple Map-like API, e.g. Tangosol's Coherence.

    So all things considered, if your business logic components don't need direct remote accessibility, declarative transactions, or declarative security, then you don't need EJB.

    Juergen
  42. J2EE Container Shootout Summary[ Go to top ]

    <Smythe>
    Why would anyone want to use EJBs?
    </Smythe>

    Granted, there is a crafty, nostalgia-like quality to using servlets for everything. I am sure many grandmas still don't believe a microwave has anything over a regular oven.

    As an example, I ran into a shop recently who had designed their whole application as one SB method call to some fairly complex processing(>100 SQL statements).

    Their issue was that they had performance problems with the application and couldn't figure out how to diagnose the problems and tune them out. Even after instrumenting some of their code and running a profiler, they still didn't have a very good sense for the hotspots of their app.

    If they had been using EJBs, they could easily do the following:
    1. Quicly test each bean/method independently.
    2. Quickly determine which EJBs are used repeatedly for a transaction (using App server admin console).
    3. Turn caching on (without recoding a thing) for their many read-only entities. (as well as several other DD tuning options -esp CMP ones.)
    4. Vertically partition the application so that the Entity beans run on one box(perhaps with the DB) and the SB's run on another. (this in itself would probably have been very insightful and helpful.)
    5. If certain SB method calls were taking a long time and affecting response time, they could quickly be converted to a Message-Driven Bean and done asynchronously.
    6. After making all of these changes, the transaction and security behavior can easily be verified.

    Servlets were never meant to support this level of flexibility. Sure there *may be* a performance cost to get this flexibility but it is obviously better than being at the mercy of murphy with some odd-ball architecture.

    Matt
  43. J2EE Container Shootout Summary[ Go to top ]

    Juergen thanks for your comments. You answered all of my questions. :-]

    Matt, thanks for your post. But I'm not too convinced about some of your points. The application on the site you described seemed to be badly designed (IMHO). Applications (client or server side, EJB or not) should be modularised so that different parts can be tested and optimised independently. Using one method call to drive 100's of SQL statements IMHO may be bad design. (comments people?). To comment on some of your other points:

    <matt-quote>
    1. Quicly test each bean/method independently.
    </matt-quote>

    As I mentioned above all applications should be modularised so unit testing (and optimisation) on each module or class method should be possible whether plain java classes or EJB are used. So this is not a compelling reason to use EJB. Or am i missing something?

    <matt-quote>
    2. Quickly determine which EJBs are used repeatedly for a transaction (using App server admin console).
    3. Turn caching on (without recoding a thing) for their many read-only entities. (as well as several other DD tuning options -esp CMP ones.)
    </matt-quote>

    I do agree with these points... But (refering to point 3) as Juergen said cacheing can be done without EJB. Also through careful coding (i.e. using a DAO to wrap the data access code) cacheing can be turned off and on via a deployment descriptor property (i.e. specifying the DAO class to use) using just servlets. More (initial, coding) work is required using this approach i suggested though. Comments?

    <matt-quote>
    4. Vertically partition the application so that the Entity beans run on one box(perhaps with the DB) and the SB's run on another. (this in itself would probably have been very insightful and helpful.)
    </matt-quote>

    Remoting might not necessarily speed up application performance. ( Can you tell I'm a fan of big boxes.... drool...! :-] )

    <matt-quote>
    5. If certain SB method calls were taking a long time and affecting response time, they could quickly be converted to a Message-Driven Bean and done asynchronously.
    </matt-quote>

    Can't this also be done using the servlet approach i suggested in my earlier post?:

    <smythe-quote>
    On server startup a Servlet can be configured to run its init() method via the deployment descriptor. In this method it can set up any helper classes (That implement the MessageListener interface) and subscribe to any Queues/Topics. So a servlet CAN act as an asynchronous message listener...
    </smythe-quote>

    Business methods would be called behind a facade so its implementation can be changed to be either synchronous or asynchronous with minimal "client" changes. Whats the difference with this approach and your point 5? Please explain...


    <matt-quote>
    6. After making all of these changes, the transaction and security behavior can easily be verified
    </matt-quote>

    Please can you expand on this point.

    Very informative thread! Look forward to your replies. Keep 'em coming guys. :-]. More people who "swear by EJBs" should also post comments so we can have a balanced discussion.

    Cheers

    Smythe

  44. J2EE Container Shootout Summary[ Go to top ]


    <matt>
    Granted, there is a crafty, nostalgia-like quality to using servlets for everything. I am sure many grandmas still don't believe a microwave has anything over a regular oven.
    </matt>

    No way. You are setting up a straw man here matt. NO ONE is advocating writing all your SQL logic in servlets. They are advocating creating normal java business logic and model classes and acessing them from Servlets or JSP's in a manner nearly identical with local EJB's (sans the hackish JNDI lookup procedure).

    <matt>
    As an example, I ran into a shop recently who had designed their whole application as one SB method call to some fairly complex processing(>100 SQL statements).
    </matt>

    It is silly to have ONE object do all your business processing. This is orthogonal to the EJB-or-not-to-EJB question. It would be silly to have one local business logic class do all your processing as well. No dice.

    <matt>
    Their issue was that they had performance problems with the application and couldn't figure out how to diagnose the problems and tune them out. Even after instrumenting some of their code and running a profiler, they still didn't have a very good sense for the hotspots of their app.
    </matt>

    <laugh/> Likely because the problems were SQL related. Which is, once again, orthoganal to the EJB question...

    <matt>
    If they had been using EJBs, they could easily do the following:
    1. Quicly test each bean/method independently.
    </matt>

    Uhhh, hows that? By writing a killer test suite? You could do the same thing with local business clases. Plus you could hook into the debugger much more easily than trying to use a server side debugger...

    <matt>
    2. Quickly determine which EJBs are used repeatedly for a transaction (using App server admin console).
    </matt>

    Nothing a profiler on local biz classes couldn't do. And without the overhead of EJB calls.

    <matt>
    3. Turn caching on (without recoding a thing) for their many read-only entities. (as well as several other DD tuning options -esp CMP ones.)
    </matt>

    Hmmmmm. This would speed things up, if the database layer caching wasn't keeping things speedy enough. But if you using Entity beans, you are already taking massive performance hits over JDBC...

    <matt>
    4. Vertically partition the application so that the Entity beans run on one box(perhaps with the DB) and the SB's run on another. (this in itself would probably have been very insightful and helpful.)
    </matt>

    Oh, now that would definitely speed things up. Put a *network* call between the business logic and the data layer logic. C'mon man, no way. Neither insiteful, nor helpful.

    An running an app server on your database server? I dunno about you, but the dba's I work with would rather have hot pokers stuck under thier fingernails...

    <matt>
    5. If certain SB method calls were taking a long time and affecting response time, they could quickly be converted to a Message-Driven Bean and done asynchronously.
    </matt>

    Hmmm. JMS anyone? You have to change the client code anyway...

    <matt>
    6. After making all of these changes, the transaction and security behavior can easily be verified.
    </matt>

    *If* your JDBC drivers are all well written, and *if* you have set up your app server perfectly, and *if* you have written test cases to verify the transaction and security behavior is correct. We just had a nightmare getting distributed transactions to occur between an AS400 and a SQLServer database using weblogic...

    <matt>
    Servlets were never meant to support this level of flexibility. Sure there *may be* a performance cost to get this flexibility but it is obviously better than being at the mercy of murphy with some odd-ball architecture.
    </matt>

    Which is why you *don't* put your biz logic in servlets, and instead put them in normal biz logic java classes that are then accessed from your servlets/jsps.

    I agree with the earlier statement that EJB's are good when you need remote access to your biz logic (which you *don't* with web apps), or when there is a big value add to declarative transactions/security. In my experience, neither of those two conditions come up on most web apps.

    My team is building a Swing-based app that needs to remotely access a weblogic server right now, thus we chose to use Stateless Session Beans. EJB's aren't *always* the wrong way to go, but it seems, to me at least, that they are *often* the wrong way to go.

    But then, what the hell do I know?

    Cheers,
    Carson

  45. J2EE Container Shootout Summary[ Go to top ]

    "It is silly to have ONE object do all your business processing. This is orthogonal to the EJB-or-not-to-EJB question."

    The question I am addressing is the standard-or-not-standard-architecture approach.


    "<laugh/> Likely because the problems were SQL related. Which is, once again, orthoganal to the EJB question...
    "

    Whatever the problems, the portability and partitionability will definitely help zero-in on the problem -and is decidedly NOT orthogonal to the ejb question. (you can't do this with plain old java objects.)

    "Uhhh, hows that? By writing a killer test suite? You could do the same thing with local business clases. "

    Not necessarily. However, in this case one of the challenges to testing was the large amount of data coming from the DB. The resulting large network latency distorted the runtime performance of several classes during development. EJB allows component testing "in place".

    "Nothing a profiler on local biz classes couldn't do. And without the overhead of EJB calls. "

    True. Just a lot more work and, again, possibly irrelevant if done on the desktop.

    "But if you using Entity beans, you are already taking massive performance hits over JDBC"

    20-30% Max. Less if using EJB optimizations (caching, field grouping, etc.) Also, more flexible.


    "An running an app server on your database server? I dunno about you, but the dba's I work with would rather have hot pokers stuck under thier fingernails... "

    Since I have been a DBA I sympathize. However, for reporting/analysis Apps that access a lot of rows, this approach has technical advantages. Plus, with JMS/MDBs It allows your client apps to provide faster response times and a more consistent quality of service.


    "We just had a nightmare getting distributed transactions to occur between an AS400 and a SQLServer database using weblogic... "

    But at least it is possible -and with AS400 too! Thats the magic of STANDARDS.

    Matt
  46. J2EE Container Shootout Summary[ Go to top ]

    "The question I am addressing is the standard-or-not-standard-architecture approach."

    Hmmmmm. So we should use EJB's because... expensive hardware and software vendors say it is a "standard"? Hmmmm....

    "Whatever the problems, the portability and partitionability will definitely help zero-in on the problem -and is decidedly NOT orthogonal to the ejb question. (you can't do this with plain old java objects.)"

    Sure you can. You can have your biz logic in a totally separate project. You can create vanilla factory objects as needed. They are as "portable" as any other java objects, and I would argue more so since you aren't relying on app-server specific deployment-descriptors...

    "Not necessarily. However, in this case one of the challenges to testing was the large amount of data coming from the DB. The resulting large network latency distorted the runtime performance of several classes during development. EJB allows component testing "in place"."

    <laugh/> "In place"?

    You touch on a general problem with test cases in a j2ee app, which is that the test cases are often based on a persisten stores state, which is difficult to control from a test case environment.

    Aside from that, EJB's can be a pain to troubleshoot because there is such a long deploy-undeploy cycle associated with them (at least with weblogic). If you just you plain old vanilla biz objects, you can just recompile and *presto* you are off and running.

    "True. Just a lot more work and, again, possibly irrelevant if done on the desktop."

    Actually, less work than with EJBs. See previous paragraph.

    "20-30% Max. Less if using EJB optimizations (caching, field grouping, etc.) Also, more flexible."

    Actually, *less* flexible. Try doing an order by with Entity beans. And try doing anything remotely like dynamic SQL with them.

    "Since I have been a DBA I sympathize. However, for reporting/analysis Apps that access a lot of rows, this approach has technical advantages. Plus, with JMS/MDBs It allows your client apps to provide faster response times and a more consistent quality of service."

    JMS (and, hell, multithreading) let you do the same thing. MDBs are neat, but not earth shattering...

    "But at least it is possible -and with AS400 too! Thats the magic of STANDARDS."

    Now *that* I agree with. But EJBs still suck. For the most part... ;-)

    Cheers,
    Carson
  47. J2EE Container Shootout Summary[ Go to top ]

    Hi Carson,

    "Now *that* I agree with."

    this is a good first step ;-)


    "Actually, *less* flexible. Try doing an order by with Entity beans. And try doing anything remotely like dynamic SQL with them. "

    Order by, dynamic queries, select hints, its all supported. You probably need to take a look at this...
    http://e-docs.bea.com/wls/docs70/ejb/cmp.html#1083208

    " MDBs are neat, but not earth shattering"
    Standards are *in a subtle way* earthshattering.



    As for Rolf who "says 20-30% max it is more than inaccurate, it have to be a down right lie.. "

    for a "create", my experience shows(for 50 users):
    355 txns/sec for CMP
    381 txns/sec for SSB+sql
    (6% hit)

    for an "inquiry", my experience shows(for 50 users):
    1597 txns/sec for CMP (caching turned on)
    1181 txns/sec for SSB+sql
    (35% benefit)

    for a "select then update", my experience shows(for 50 users):
    153 txns/sec for CMP (caching turned on)
    191 txns/sec for SSB+sql
    (20% hit)

    Productivity, manageability, scalability, standardness of CMP is definitely a bigger advantage in many cases.
    Matt
  48. J2EE Container Shootout Summary[ Go to top ]

    Yosef,

    Agreed that dba's hate it. But then, dba's hate everything... :-)

    Regarding the "SQL injection" attack, this is why, if you are constructing dynamic sql, you should *only* use PreparedStatements. This is more difficult, because you have to construct the sql string with ?'s in all the variables and then go through it *after* is has been constructed and set all those variables (likely from a list you have been building up as you construct the SQL). Kinda ugly, but you are now "safe" since your driver is doing all the argument preparation.

    Just constructing a string sql statement is dangerous and non-portable.

    Agreed, it absolutely depends on the app you are building. I would even go further and say it depends on what *part* of an app you are building. EJB's are nice for the CU and D part of CRUD, but suck at the R part. Tragically, the R part is often the most important part of online apps.

    I should mention, again, that I do mostly intranet development, so people working on internet sites might have a better experience with EJBs. Especially those "architects" out there that never have to actually write any code... :-)

    Cheers,
    Carson
  49. J2EE Container Shootout Summary[ Go to top ]

    You might also want to read
    Rickard Öberg's response to the J2EE Container Shootout summary.
  50. J2EE Container Shootout Summary[ Go to top ]


    Rickard Öberg:

    "J2EE will be just fine in 5-10 years from now. Servlets are cool. JTA works just fine. Etc. EJB is a dead end though. Using AOP and a XDoclet-ish approach is the way ahead."

    and earlier, Juergen Hoeller:

    "Stateless Session Beans won't improve performance"

    I think I put my money with Rickard and Juergen.
    Thank you David, for the link

    Regards
    Rolf Tollerud
     
  51. J2EE Container Shootout Summary[ Go to top ]

    This is my favorite part of the article:

    <quote>
    JBOSS: Marc [Fleury] proclaims that he is a "closet Microsoft lover" and that he takes Microsoft very seriously. But, he contends that Java has nothing to fear from Microsoft. Java is portable and the runtime is free. The difference between JBoss and Microsoft is philosophy. Microsoft wants to commoditize the $20/hour developer and JBoss wants to commoditize the runtime and the application server.
    [...]
    </quote>
  52. J2EE Container Shootout Summary[ Go to top ]


    Without ever having done any EJB I have been investigating this now for a couple of weeks. All test I have seen and all persons I talked to in person testify that it is between 3-6 times performance degrading using EJB vs ordinary Java classes done correctly. And there are many other issues too wrong with EJB. So when somebody says 20-30% max it is more than inaccurate, it have to be a down right lie..

    What I can not understand is why this subject is so religious and inflammable? After all Microsoft is not involved here. Why stick to a faulty and flawed spec? Is it Sun who wants to sell monster servers?

    It is not shameful not to get it right the first time, - throw away the prestige.

    Regards
    Rolf Tollerud
     
  53. J2EE Container Shootout Summary[ Go to top ]

    Rolf -
    <quote>
    All test I have seen and all persons I talked to in person testify that it is between 3-6 times performance degrading using EJB vs ordinary Java classes done correctly. And there are many other issues too wrong with EJB. So when somebody says 20-30% max it is more than inaccurate, it have to be a down right lie..
    </quote>

    What application servers have you looked at and what type of applications do you write? What kinds of applications are people that you talk to writing? What versions of EJB are they using? What are they using EJBs for? What tuning to they do with EJBs? With the types of apps we write (EAI/warehousing) we see at least as fast a performance level as with our older CORBA apps, they are easier to maintain, build, deploy, and employ fewer system resources. Is the spec perfect? Nope. Is it getting better? Yep. Are EJBs perfect for all apps? Absolutely not. Are they good for some things? Yes. You shouldn't call someone's experiences lies either unless you know all the circumstances and can back it up with facts. You can't - therefore you shouldn't. EJBs obviously aren't the right thing for you to use. Don't use them. Simple, no?

    Ray
      
  54. J2EE Container Shootout Summary[ Go to top ]

    <quote>
    Is the spec perfect? Nope. Is it getting better? Yep. Are EJBs perfect for all apps? Absolutely not. Are they good for some things? Yes. You shouldn't call someone's experiences lies either unless you know all the circumstances and can back it up with facts. You can't - therefore you shouldn't. EJBs obviously aren't the right thing for you to use. Don't use them. Simple, no?
    </quote>

    The problem is that vendors have sold EJBs to management as *the* answer to all thier enterprise problems. Understandable, because, if you don't need EJBs, why not just go with Tomcat?

    Part of the problem is that, in my experience, every manager considers his project a large scale enterprise app which, therefore, *requires* ejbs. I'll agree that there are cases where EJBs make sense. (Although I'm falling victim to the mistake of not differentiating between Session and Entity beans. Entity beans are absolute crap. Sun needs a good O/R Mapping tool. And JDO ain't it.) But the space where they make sense is very, very small.

    Cheers,
    Carson

    P.S. No fair bringing up CORBA apps. Of *course* EJBs are more maintainable than some insane CORBA app. That's like saying Death Valley is really not so hot, when compared with Hell. Sure, but Death Valley is still really friggen hot.
  55. J2EE Container Shootout Summary[ Go to top ]

    Agreed that EJBs are oversold - many people got caught up in the hype, and like all hype - it turns people off.

    By the way though, we use entity beans all the time. Love 'em.

    Cheers
    Ray
  56. J2EE Container Shootout Summary[ Go to top ]

    <laugh/>
    <quote>
    By the way though, we use entity beans all the time. Love 'em.
    </quote>

    Is that because your data objects don't use inheritance?

    http://www.onjava.com/pub/a/onjava/2002/09/25/ejbinherit2.html
    http://www.onjava.com/pub/a/onjava/2002/09/04/ejbinherit.html

    Or is that because you never need order-by your results?

    Or is that because you like editing an obscure xml file every time your database schema changes?

    Or is that because your finder methods *fix* the structure of your SQL statement, causing a combinitorial headache when you are creating a general search interface?

    Or is that because you enjoy a 1 minute redeploy time?

    <laugh/> Just my experience. Hate 'em.

    Cheers,
    Carson

  57. J2EE Container Shootout Summary[ Go to top ]

    Hey Carson -
    <quote>
    Or is that because you never need order-by your results?
    </quote>
    I actually don't need to. We aren't doing much data presentation - more processing of data from different sources, really.

    <quote>
    Or is that because you like editing an obscure xml file every time your database schema changes?
    </quote>

    <laugh>C'mon - it's not that hard!</laugh>
    Plus our schema rarely changes.

    <quote>
    Or is that because your finder methods *fix* the structure of your SQL statement, causing a combinitorial headache when you are creating a general search interface
    </quote>
    Not sure what app servers you have used - but I haven't had that problem.


    <quote>
    Or is that because you enjoy a 1 minute redeploy time?
    </quote>
    <laugh> I love 1 minute deploy times - gets me away from my desk </laugh>

    Cheers
    Ray
  58. J2EE Container Shootout Summary[ Go to top ]

    Ray,

    <quote>
    I actually don't need to. We aren't doing much data presentation - more processing of data from different sources, really.
    </quote>

    I'm jealous.

    <quote>
    <laugh>C'mon - it's not that hard!</laugh>
    </quote>

    No. More annoying than hard. I suppose I'm more annoyed that there isn't a decent O/R tool for java than anything.

    <quote>
    Plus our schema rarely changes.
    </quote>

    Now I'm really jealous.

    <quote>
    Not sure what app servers you have used - but I haven't had that problem.
    </quote>

    Weblogic 5.x, 6.x, 7.x. The dynamic select/find sql problem is a structural problem with the EJB spec, regardless of app server. If you aren't doing much work with user interfaces, it won't annoy you. If you are, and I am, it will.

    <quote>
    <laugh> I love 1 minute deploy times - gets me away from my desk </laugh>
    </quote>

    Point conceded. And how else would I find time to post the the serverside? ;-)

    Cheers,
    Carson