Picking An Ejb Server

There are lots of EnterpriseJavaBeansServers available. Where does one find useful, comparative information regarding these servers? I have found a study, but it costs US$2500 (or so).

What looks to be a fairly thorough study talking about conformance with the spec, interop and performance is available at http://nenya.ms.mff.cuni.cz/thegroup/EJBCOMP/index.html

This is no longer true, as the masters of that web have pulled the complete report, saying:

To avoid any potentially misleading extrapolation of the results relevant to the EJB 1.0 products (plus an apology to those who might have felt their new product would do much better), we decided to only make available for a download the part of the report which outlines and describes the methodology designed for the EJB server evaluation. ....

Frankly this seems misguided, and I'm disappointed. Does a newspaper pull its archives because the news has changed? Does a tech magazine pull its reviews because a new product has been launched? Do we erase the records of cricket matches because one team or another seems to have improved?

-- DinoChiesa

Choice of Tooling

When you are choosing an EnterpriseJavaBeans solution, you can't ignore the tools issue. There are tools (like VisualAge for Java when paired with WebSphere and JBuilder for InpriseAppServer) that make developing for a particular application server substantially easier than trying to do it with other tools. -- KyleBrown

VisualCafe integrates with WebLogic (eventually), but that's about the only good thing about it. -- KeithBraithwaite

All Smalltalkers will appreciate the luxuriousness of a tool like VisualAge for Java. Ease of development also comes from managing complexity in an application, and one area of complexity in EnterpriseJavaBeans applications is object/relational mapping (see Kyle's CrossingChasms). Due to its persistent object caching capability, GemStonej gives you options in this area. For example, you can get your application up and running using the persistent object cache, and deal with the separate concern of O/R mapping whenever you're ready. You still have to design for O/R mapping, of course, if you're going to be using it eventually... but you'd have had to do that anyway. <bias>The persistent object cache can also facilitate scalable performance at runtime, by alleviating the need to incur the response time contribution of O/R mapping in every transaction. Used this way, the role of the persistent object cache in software architecture is analogous to the role of a RAM cache in hardware architecture.</bias> -- RandyStafford

Agree entirely: The IDE is critical. VisualAge, as an example, generates a heck of a lot of stuff for you from nice step-through wizards; in fact, it has a whole different project-type view just for EJB projects. And it has great develop-and-test support right in the IDE. Inprise's new JBuilder IDE is a lot simpler (some might say easier, some might say cruder), but then so is their server product, particularly in the O/R mapping area. I haven't seen the Sun/Forte/Syner/J product so I can't help you there.

Generally speaking, you need the best tool support you can get when working with this stuff. That's not a bad thing at all (see Smalltalk), but it means you just can't pick a server on the server features alone. And I don't work for any of the vendors ;-)

-- RichardEmerson

Richard and Kyle, I moved the CMP discussion to ContainerIndependenceDiscussion. -- RandyStafford

So Kyle and Richard, are you saying that the tooling and runtime are tied together closely enough that you cannot make a decision on one without implicitly making a decision on the other? This certainly seems reasonable to me. But doesn't this put the lie to the "EJB as a standard platform" story? Certainly EnterpriseJavaBeans is still a standard, but the question is, what is the practical value or implication of the standard? If by selecting a server or container, I am also tying myself into a particular tool (and probably some other things like server extensions, e-commerce value-adds, connector technology...?), then the standard nature of EJB isn't resulting in an open solution - not at this level.

Of course I recognize the value EJB brings in standardizing the metaphor; this leads to the development and understanding of patterns, as one example. But it seems to me some of the vendors and analysts claim (imply?) more extensive benefits than can be realized given this state of affairs.

-- DinoChiesa

Upon reflection after working on several project inflicted with EJB, the tools/runtime tie-in is indeed a significant issue. In order to be productive with EJB, a level of automation and wizard to handle the fiddly details is essential. A realization has come, however, that it is not simply that the runtime that determines which tool you must use, it is the tool that limits the runtime(s) you can deploy to. Another way of looking at it is that WSAD (formerly VisualAge for Java) only does the wizardry for WebSphere. JBuilder only has the ability to build for Inprise. If either tool had support for the fiddly details of multiple application servers, then one could choose the tool independently of the EJB container. Of course, the tools vendors have a vested interest in tying your project to their platform, now and in the future.

Things are a bit better today than they were before. Previously, if you didn't use the vendor-supplied tool with your chosen EJB server, you were condemning your development to a lot of manual work, or to rolling your own automation. Because of projects like JakartaAnt there are now (somewhat) vendor-independent tools for automating the EJB tedium. The book JavaDevelopmentWithAnt, by EricHatcher? and SteveLoughran covers web application development with Ant as a special case, and cites tasks like jspc, ejbjar and XDoclet as the solution to a more vendor-neutral sane build. Although not at all a solved problem, it is now possible to choose to use Eclipse (the basis for WSAD, without so many plugins it topples over), or IntellijIdea combined with Ant. The development team can somewhat decouple the tools from the server, but it requires more knowledge of EJB than the ability to push buttons on a wizard. In practice, at least one project has a developer using vi and the command line with the Ant build tools. --StevenNewton