For a ful list - EJB's 101 Damnations
http://www.softwarereality.com/programming/ejb/

Sing it brother!
Sing it from the mountain tops! Sing it in the Valley! Sing it from the tops of the crappy office parks in Palo Alto!

What java needs is a decent, light-weight O/R layer. Not a crazed, all encompassing development methodology. Take a lesson from Unix: combine simple tools that do small things well rather than try to create one tool which ends up doing everything poorly.

(Session Beans may be the baby not to be thrown out with the bathwater of entity beans, *if* you have a need for remoting, which 95% of web apps do not.)

Unfortunately, most of the alternatives mentioned in the blog are pretty ugly as well. JDO is developing into an EJB-like behemoth. The proprietary O/R tools out there are all very heavy weight and adapt to model change poorly. Stored procs are very inflexible (especially in selects). JDBC just plain sucks to deal with if you are doing anything dynamic.

Anyway,
Carson

An American proverb??
Hmmm,

http://www.utas.edu.au/docs/flonta/DP,1,1,95/BABY.html

Cheers,
Paul

NOT An American proverb (Was: An American proverb??)
OK, I stand corrected--thanks for the catch. :-)

While I hate to dissent...
this article is fundamentally flawed in terms of the presentation of its argument and the facts used to support it.

The presentation hinges on a misunderstanding of what an enterprise "application" is. As a hint, your company's website is not an enterprise application. Enterprise applications typically only have a GUI as a front-end for minimal functionality - all the real work occurs on the back end. Take the example of a bank - you may have online access to your account, but the systems to initiate payments, stop payments, track payments, schedule payments, view check images, etc. require a thorough, stable, and scalable back end. The author, whom I have great respect for (his books are always a pleasure), honestly sounds like he has never worked in a true enterprise environment.

Now to the facts:
Persistence/OR Mapping - EJBs were not created to solve this problem. This functionality is a feature which can be used or ignored (although I think the acronym CMP defeats many of the arguments I saw).
Remoting - Yes, some work is required. But if you find this level of work onerous, then you should find a better tool or consider what an acceptable degree of work is.
Synchronization - These settings can be changed (I believe there are four options).
Connection Pooling - Again, the author assumes that a simple web-app is an enterprise system, or even EJB worthy, which is simply not true.

A final note on patterns. People who claim that patterns simply create extra work are just spouting nonsense. Anyone who has properly deployed a pattern can attest to the flexibility created as well as the ease in communication. Most of the senior developers I know will not hire anyone above a junior level without a basic understanding of patterns and a grasp of the GoF defined patterns.

EJB Alternatives are already available
EJB is quite a heavy weight portable enterprise framework, that can be used to build enterprise systems. This usually means building a internet or intranet system that connects to various existing enterprise systems (order fulfilment for example).

EJB is one of the aspects of J2EE, and it's gotten a lot of attention. However, most web-sites don't need a system as complex as EJB.

When using EJB's, usually the system created separates the application in several layers:
1. User interface
2. Business functions
3. Business object model
4. Proprietary systems layer

J2EE uses JSP's, session beans, entity beans and JCA (J2EE Connector Architecture) for these layers respectively. When some of these layers are abscent, the project's architect(s) should consider J2EE alternatives, as they are much quicker and lighter weight to use. I've encountered projects where this is the case, and used tools like Enhydra (open source, light weight java appserver) and ATG Dynamo (supports both J2EE and a proprietary much faster and flexible model).

ATG Dynamo for instance, uses either jthml (pre-decessor of JSP) or jsp's to access the lower layers. The layer of interest in ATG is the O/R layer. That layer maps the java objects into database tables. This mapping is expressed by developers in an XML file. Objects becomes available in the form of hash maps (key value pairs). This is a powerful and convinient way to avoid entity beans that explicitely contain the attributes of the database tables.

In short: EJB isn't the holy grail, and there are alternatives available that are much more powerful if you don't develop a heavy weight enterprise application. EJB is useful but is complex and is not the silver bullet that fits every web application...

Ok...
...this is just plain stupid...

ever heard of stateless session beans ??

Damn .. EJB (with or without CMP beans) solves _a lot_ of problems in every day development. Please don't spoil the whole EJB concept just because of a bad O/R mapping thing. EJB is so much more than CMP/BMP EJB:s!!!!!

While I hate to dissent...
I won't dissent to the dissent, but I do want to state that:
1) I tried to keep the article short--this could easily be a full book in of itself.
2) EJB *was* created to solve this problem, otherwise how do we justify the amount of time and energy spent on EBs? CMP is just O-R mapping, and many of the EJB vendors require additional proprietary extensions to make it work well--which defeats portability.
3) Please describe how I can control synch on a method (session bean or entity bean). Please describe how I can control transactions on an entity bean so I'm not running every EB under full distributed transaction control.
4) Remoting isn't something we can bury under the hood and pretend it's not there anymore. A little work is perfectly acceptable--just so long it isn't more than necessary. Bear in mind, though, that one of EJB's goals was to remove the idea that this remoting was taking place entirely from the view of the developer.
5) Webapps are typically the entry point to an enterprise system, and the fact is that this is where most people are taking J2EE--they want to 'web-enable' the enterprise.
6) I *LOVE* patterns--if there was any hint that I was denigrating them, then I need to rewrite the article. :-)

Well...

Ted,

I agree with you when you say that EJB is complicated. I don't like the programming model that much either, especially when I compare it to other solutions, such as Jini.

Programming EJBs is a lot of work which is why I finally jumped on the code generation bandwagon. To me, this seems to be the only reasonable way to handle it. However, I don't think EJBs are a damnable thing altogether.

Writing enterprise systems has never been a simple thing, and IMHO will never be. Some people simply got the wrong impression when the read the marketing blurb about EJB.

For the list of technical shorcomings that you're article offered: yes, there is a price to pay for standardized solutions. The technical solution might not be the perfect one but a good-enough one. And who really needs the last bit of optimization?

What you gain, to mention only one aspect, is a large community of developers who know the technology. Companies like that because they don't have to invest so much money in training for specific products any more. Sure, you can go to a BEA training to learn the nits and bits of Weblogic, but what I'm saying is that I can do without if somebody asks me to develop an enterprise application.

IMHO, it all comes down to understanding the implications of complex enterprise applications--why would you want to use EJB for a two-tier Web application w/o distributed transaction requirements as you describe it?--and using the right tools. As an architect you know that the application requirements should drive technology decisions. Use EJBs if they are appropriate.

Believe me, I'd go with other technologies if customers would let me, but the world stills buys into relational databases when object databases are more mature for a lot of applications that I did recently. Why do people go with static languages such as Java when there are dynamic ones around with which you can solve problems with mush less effort?

EJB is here to stay because the industry bought into it, whether that's a good or a bad thing is upon others to decide. Cobol seemed to be a good thing at the early days, too.

tom

Comment: Death of EJB
I agree that Entity beans are something that any one would not like to use..But there are other things about it that make ur application much easy to develop and maintain. With my experience in working on a realtime j2ee application, I can say that it is really fascinating. You can move the DataAccess and Business logic part to JSPs/Servlets....but that doesn't mean what u can ...u should. It makes a lot of difference to the Software quality if not to performance or anything else. And what if you don't want to have a browser based application ??

"Portable" EJBs
Using EJBs could have some of the same positive aspects as using other patterns.

Even though it would be hard to port a complex application using EJBs to a different container, we still have the same concepts and mostly the same interfaces. This should ease communication in the project, and hopefully decrease the time necessary to move on to a different container in a later project / job.

Comment: Death of EJB
Who said HTTP was intimately tied up with browser-based applications? If nothing else, the Web Services sensation should be teaching us that HTTP is good for far more than just shipping HTML back to the browser.

Software quality is a measure of the developer, not the technology, and performance takes a huge jump if you cut out unnecessary round trips. So build your Swing-based front-end (delivered via JNLP so as to maintain Zero Deployment costs), and use HTTP to ship the data back and forth to the database; whether the data is in XML or binary serialization format is up to you.

"Portable" EJBs
You're correct in that using EJB as a conceptual layer helps port the application to other systems; that's a far cry from using EJB as a "vendor-neutral" application technology, though. Frankly, I look at a given EJB container, and look to take advantage of every vendor value-added feature they offer, since I know that porting the app from one container to another entails about as much work as porting an enterprise app from one database to another. (Forget the code/schema migration--just look at the amount of work required to port the data!)

Well...
Who really needs that last bit of optimization? A lot of systems do, particularly since it's not just "that last bit", but just optimization in general--one round trip per property in an EB? Ouch. Having to choose up front between local and remote access to beans? Ouch.

I totally line up with you on the statement "Use EJBs if they are appropriate", which is a loose adaptation of the patterns approach: choose the pattern whose problem and forces best matches yours, and whose consequences best match your desired end result.

I have yet to see a project where EJBs were more appropriate than other approaches.

For a ful list - EJB's 101 Damnations
This is a great list, by the way.

Bollocks
What a load of bollocks. For one this guy is talking about EJBs as if
they are all entity beans. Entity beans have always been considered the weakest
point of the EJB spec, since they were introducing 5 (?) years ago. And secondly he produced
this list of so-called arguments to use EJBs ...

> One such alternative is to look at what EJB provides, and see if those same features are provided elsewhere:
> Persistence and O-R mappings. Can you say, "JDO", or "SQLJ", or "stored procedures", even "raw JDBC", anybody? Fact is, SQL was, is, and shall always be a more powerful and better- supported
> language than EJBQL. Why surrender the expressive power of SQL, particularly when developers have been mastering it for decades and database vendors have been optimizing it for longer, in
> exchange for a language that's barely two years old, has varied support from vendors, and doesn't provide half the functionality of SQL?
Since when does the EJB spec enforce EJBQL ? AFAIK you can happily code DB vendor specific SQL in your entity beans

> Remoting. The EJB specification "takes care" of all the underlying remoting details--which is to say, it exports your RMI servant objects (the beans) for use from client VMs. That's it.
> Everything else-- defining the remote interface, writing the business implementation, ensuring the interface inherits from java.rmi.Remote--all of that is the same level of detail required by
> doing raw RMI programming yourself.
What about object pooling ? Object failover / recovery . Thread management ...

> Synchronization. Along the lines of remoting, EJB also provides synchronization policies for your remote objects--by choosing the worst possible synchronization scheme. When a remote call
> comes in from a client, the entire bean is locked until that client call completes--any other call from any other client is blocked until that call returns. This is like locking the freeway when
> a car hits the onramp--great for that one car, but certainly less than optimal for others waiting on the onramps. If you take control of your RMI servants directly, you can replicate this
> behavior if desired, or adopt a finer-grained synchronization policy to boost scalability.
Simply not true. EJBs do run single threaded , but this is for good reasons ! And by having pooled objects, you aren't locking the freeway, you're locking the car . Which seems only fair. Writing multi-threaded objects isn't an easy task!

> Connection pooling. This is probably the most cited reason developers use to persuade managers to adopt EJB.... and probably the least meritous, from a technical perspective. The fact is, a >
> servlet- based application will connection-pool naturally, because all presentation elements are coming through the servlet container anyway. Drop a connection-pooled JDBC driver into the
> webapp's WEB- INF/lib directory, and voila! You're connection pooling with the best of them. In fact, many servlet containers are even providing JNDI contexts from which to discover JDBC >
> DataSources, rather than forcing you to do the Class.forName()/DriverManager thing directly.
Since when are people using EJBs just to get DB connection pooling ? This is part of the JDBC spec, so if you only want connection pooling , just use a JDBC driver that supports this...

I'm not a big fan of EJBs, but there's more to it than vendor neutral DB access! This idiot
is just writing this crap to get his name out and sell his stupid books.

too many no-knows, too little time...

cheers,
Edwin.

Bollocks
I love it when somebody expects a complete dissertation in a one-page article. :-) If I had the complete time and space required to dissect EJB entirely, I'd do it. Unfortunately, I don't. Not here, anyway.

"Entity beans have always been considered the weakest point of the EJB spec, since they were introducing 5 (?) years ago."

Session beans were introduced at precisely the same time--in fact, the ONLY new bean type to be introduced since 1998 is the message-driven bean. That said, so what? Age makes them weaker? I thought the EJB 1.1, 2.0 and forthcoming 2.1 specs were supposed to fix what's wrong; if they haven't, then what's up?

"Since when does the EJB spec enforce EJBQL ? AFAIK you can happily code DB vendor specific SQL in your entity beans."

Only if you do vendor-specific extensions in your container; the standard format for doing a finder on a Home is to use EJBQL, expressed in your deployment descriptor. Now, if you're willing to surrender vendor-neutrality entirely, which a majority of EJB developers are claiming you don't want to do, then by all means, take every value-added feature the vendor offers. (I'm with you on that one.)

"What about object pooling ? Object failover / recovery . Thread management ... "

Object pooling has never been proven to really achieve anything--connection pooling is another story. Object failover/recovery, I'm not entirely certain what's meant here, and thread management is pretty much nonexistent in the Java platform entirely--I suppose you could always go back to ThreadGroups, but that's pretty much a "don't go there" issue.

"Since when are people using EJBs just to get DB connection pooling ? This is part of the JDBC spec, so if you only want connection pooling , just use a JDBC driver that supports this..."

Dude, I hate to say this, but a LOT of people are going to EJB for precisely this reason. I agree with you, believe it or not--just use the JDBC driver and call it a day.

"Simply not true. EJBs do run single threaded , but this is for good reasons ! And by having pooled objects, you aren't locking the freeway, you're locking the car . Which seems only fair. Writing multi-threaded objects isn't an easy task!"

Bullshit. It requires the developer to think a bit, perhaps, but writing a thread-safe object isn't nearly as hard as people want to make it out to be. Worse yet, choosing the most coarse synchronization policy possible simply makes the system perform poorly when it doesn't need to. I think you sell a huge number of Java programmers short when you implicitly say they're too stupid to "get it", so the container needs to do it for you. After all, servlets are multithreaded, and Sun has tried the "let's forget about threading" approach (SingleThreadModel), and backed away from it.

"I'm not a big fan of EJBs, but there's more to it than vendor neutral DB access!"

You're right, there's more to it than just vendor-neutral DB access--which is why I want people to take a serious look at this thing and ask themselves precisely what it is that EJB gives them. Answer: nil. So why use it?

"This idiot is just writing this crap to get his name out and sell his stupid books."

Well, you're certainly entitled to your opinions.

Bollocks
> "What about object pooling ? Object failover / recovery . Thread management ... "
>
> Object pooling has never been proven to really achieve anything--connection pooling is another story. Object failover/recovery, I'm not entirely certain what's meant here, and thread management is pretty much nonexistent in the Java platform entirely--I suppose you could always go back to ThreadGroups, but that's pretty much a "don't go there" issue.
* Object pooling in Java in general achieves less frequent garbage collection. This is essential if you want to run a production system that isn't going to grind to a halt evey couple of hours.
* Object pooling wrt EJBs achieves concurrent access to single threaded EJBs.
* Object failover/recovery achieves object & state recovery in case of process failure. Completely transparent to the client of the failing object.
* Thread management non existent ? Thread mgmt in EJBs is hidden from the developer, thread mgmt in Java non existent ? What are you on ?
>
> "Since when are people using EJBs just to get DB connection pooling ? This is part of the JDBC spec, so if you only want connection pooling , just use a JDBC driver that supports this..."
>
> Dude, I hate to say this, but a LOT of people are going to EJB for precisely this reason. I agree with you, believe it or not--just use the JDBC driver and call it a day.
Well, I'm shocked, seriously. Just goes to show the amount of knownledge that's outthere ...
>
> "Simply not true. EJBs do run single threaded , but this is for good reasons ! And by having pooled objects, you aren't locking the freeway, you're locking the car . Which seems only fair. Writing multi-threaded objects isn't an easy task!"
>
> Bullshit. It requires the developer to think a bit, perhaps, but writing a thread-safe object isn't nearly as hard as people want to make it out to be. Worse yet, choosing the most coarse synchronization policy possible simply makes the system perform poorly when it doesn't need to. I think you sell a huge number of Java programmers short when you implicitly say they're
Quantifying the complexity is not really possible w/out a real scenario, but I'd much rather have juniors code single threaded & pooled objects, than having them write multithreaded objects. It's just less error prone. And debugging multi-threaded stuff, or even just reproducing concurrency issues, is a pain in the ass.

How many actually port? I can only answer that for a limited subset...
>A number of EJB developers code their enterprise
>apps strictly to the specification, citing
>adherence to the standard as a holy mission, and
>criticizing those who do not with holy zeal. In
>all honesty, however, how many EJB applications
>actually migrate between server products?

In my limited experience _100%_. Between myself (working in healthcare software) and a friend who is working at a .com, every single thing we've done has gone from the original J2EE server it was written for to another one.

So far:

We've had to port stuff written for BEA WebLogic to JBoss because we were concerned we were going to have to put it on a bunch of servers and we didn't think we could afford the licenses.

We've seen a single application go from Orion to WebLogic (lack of support from Orion) to WebSphere (IBM was a customer and didn't want a product on WebLogic). There was also a brief stopover in JBoss for that one as well but it didn't stay...

The stuff we are working on now at my job is migrating from WebLogic to WebSphere because IBM will give us developer licenses for free and BEA won't (I don't make this stuff up folks, this is how real world decisions get made).

Don't even get me started about how many of those are also not running on the hardware platform they were originally written for either. :)

WORA not just a myth
I think you're unfair to Java when you say "just as any but the most trivial Java programs are nonportable". I think jakarta.apache.org provides plenty of examples of programs that I at least would consider non-trivial. They seem to run fine on different platforms for me. The app I work on professionally runs on WebLogic and WebSphere, against DB2 or Oracle, on Sun or Windows. Ok, it's not all roses but I don't see C++ or .Net making this possible. Perhaps Python/Ruby or Scheme would work but there isn't the enterprise community around those tools. Just because it isn't a floor wax and a desert topping...

WORA not just a myth
Like Java, C++ was portable so long as you constrained your application to a bound set of usage models, e.g., no pointer arithmetic/manipulation, no calls to library functions outside of the ANSI standard libraries, and so on.

.NET and portability still remains an open issue; by submitting the CLI to ECMA, the opportunity is there for people to write "portable" .NET code--portability between Mono and the CLR, for example--but Microsoft has also explicitly stated that they're not interested in WORA, so WinForms remain a Win32-only API, for example. So, again, non-trivial programs will likely not run "as is" on multiple platforms.

The big problem with "portable code" is that we choose each platform for its value-add; the platforms have evolved the way they did for particular reasons. Case in point: Where did God intend the menubar of an application to be? At the top of the screen, or the top of the main window of the application? Should a system have one root directory, or many? Where are user settings stored? And so on.

WORA not just a myth
I don't understand the pointer arithmetic/manipulation statement. That's a feature of C++ that you shouldn't use, you say, for cross platform portability. What's a similar feature for java, i.e. a core part of the language that is not portable, or to ease the restriction, a part of any of the jdk packages that is not portable? Sure, if you use JNI and call platform specific code you lose cross platform portability but in the same way if I point a gun at my foot and pull the trigger I'm likely to blow my foot off.

I think we can agree that .NET is not portable. Nor will it ever be portable.

But under java it doesn't matter where the menubar of the application is. As a java programmer you don't get to control that. Same with the root directory question, just call java.io.File.listRoots() and you're told what they are. Some systems will return one entry, some more than one. Provided you don't, yourself, of your own free will, restrict yourself to the assumption that there is only one root your code will work cross platform.

The user settings question was "solved" in 1.4 by the java.util.prefs stuff. I know that wasn't present in earlier versions but I don't think we can expect complete success even in the first few revisions.

I agree that you may need to go native to get absolute look and feel match with a platform. However, for what I do, enterprise computing, there's seldom a GUI anyway, or if there is it's HTML. Even if it's a client server app Java now looks close enough to the native platform that it's not worth rewriting in another language for that last 1% of appearance.

WORA is unfairly bashed. To believe it's not there after seeing it work for myself for so many years I need real examples where it's not present and it's reasonable to expect it might be.

WORA not just a myth
> I think we can agree that .NET is not portable. Nor will it ever be portable.

Nope, can't agree. Fact is, I can take an assembly compiled under the CLR, and run it, in binary form, unchanged, on a FreeBSD system using Rotor, or on Linux using Mono. That's portability, by the same definition as Java uses. Worse fact is, there are currently about as many implementations of the CLI as there are of the JVM (CLR, Compact Framework, Mono, Rotor, Portable.NET vs Sun Win32 JDK, Sun Solaris JDK, Sun Linux JDK, IBM Win32 JDK, IBM AS/400 JDK, and....?).

> WORA is unfairly bashed. To believe it's not there after seeing it work for myself for so many years I need real examples where it's not present and it's reasonable to expect it might be.

How about massive threading policies? Can you say, with certainty, what the threading policy will be in a portable fashion for a given Java thread priority? (Alan Holub makes a very deep argument on this score in his APress book--I forget the title off the top of my head.)

> Provided you don't, yourself, of your own free will, restrict yourself to the assumption that there is only one root your code will work cross platform.

But, see, there's the rub: as long as you don't make any sort of assumptions, your code is portable. As long as C++ code didn't try to do anything beyond the ANSI libraries, or do any pointer arithmetic, or want to use threads, it, too, was portable. ANYthing is portable under that definition.

I'll grant, Java has slowly been expanding its "reach" of what's covered by the Java libraries--for example, JavaComm, Java2D, Java3D, JMF have all started to cover the obvious places where Java libraries didn't reach in 1.3--but that still doesn't change the reality that if Java doesn't cover it (and even some places where it does), you can't have any solid guarantees as to behavior.

The key area, for enterprise systems, is to look at "portable" SQL and how well that's worked amongst the database vendors. Even after three revisions of "standard" ANSI SQL, no one database vendor can claim to be 100% compliant, even 11 years after the first revision. Database guys frequently talk about the pain involved in porting an app from one to another database, both at the schema level, and the data level. You may argue that RDBMSs are a multi-vendor environment, where Sun is the sole proprietor of Java, but doesn't that effectively mean that we can't assume Java will run correctly under anything but a Sun JDK? Where, for example, is the delegating hierarchy of ClassLoaders documented in the "official" Java specifications? It's not in the Java Lang Spec, nor the JVM Spec, so what, precisely, defines a "compliant" VM for Java?

> Even if it's a client server app Java now looks close enough to the native platform that it's not worth rewriting in another language for that last 1% of appearance.

Unfortunately, in many cross-platform application projects I've been involved with, it's that last 1% that really stands out. Part of the reason Swing has such horrendous performance is because they needed to draw everything in Java in order to get a consistent user interface across platforms--AWT, and its delegating Peer model wasn't doing it. And even there, Sun is now caught up in a constant code-maintenance nightmare, where they will have to constantly revise the Windows L&F to keep up with Microsoft's L&F changes, or else the Windows L&F "just won't look right".

To be honest, WORA is a red herring; I'm not looking for more portability, in many ways, I'm looking for less. I don't want to have to find ways to write code that can run anywhere, I want to have ways to exploit the particular advantages of the hardware I'm running for an enterprise application. Java's making it more and more difficult to do that.

Bollocks
> * Object pooling in Java in general achieves less frequent garbage collection. This is essential if you want to run a production system that isn't going to grind to a halt evey couple of hours.

All depends on your garbage collection heuristic. Under simple mark-and-sweep, most definitely true.... but simple mark-and-sweep is the most primitive of all the GC algorithms, and Sun has most definitely moved away from that. Generational collectors, arena-based collectors, lots of different approaches are available that can make GC a lot friendlier for long-lived apps. Pooling objects here can in fact be counterproductive under those scenarios.

* Object pooling wrt EJBs achieves concurrent access to single threaded EJBs.

How so? The EJB spec explicitly disallows more than one thread on any given EJB bean, period.

* Object failover/recovery achieves object & state recovery in case of process failure. Completely transparent to the client of the failing object.

Only for Entity Beans--the EJB spec explicitly states that in the event of process failure, stateful session bean state is lost and must be reestablished. Stateless session beans hold no state across calls anyway, and entity bean state is preserved in the database under transactional semantics anyway. Precisely what are we gaining here?

* Thread management non existent ? Thread mgmt in EJBs is hidden from the developer, thread mgmt in Java non existent ? What are you on ?

Precisely part of the problem--how would I do an async operation in an EJB? Or how do I set up an "active thread" within an EJB environment, to perhaps act as the controller in a workflow app scenario? EJB's threading model is entirely passive--a bean must be called somehow, and therefore must borrow a logical thread of control from the client. MDBs go some towards solving this, but still don't resolve all issues on this score.

I must be odd, stupid or gullable...
I love using EJBs and in perticular CMP2

I can...
- easily map domain objects to beans
- easily map relations between my entity beans
- have the container manage all my transactions
- have the container manage my entity cache
- have the container manage my bean pool
- have each of my use cases represented by a session bean, giving me a visual link between business requirement and code
- have the container manage all my inserts, updates and deletes (less code), even creates during development
- find an "order" object then do this order.getCustomer().getAddress().getPostCode(), just by setting the relations up
- decoratively manage my bean deployment, eg. one bean can be deployed several times for different situations

I've only been using EJBs for a little over 6 months but I'm already finding that I'm writing way less code (via xdoclet) then before. I'm sure I'm only scratching the surface.

Why, when someone else has figured out the code for cache, pool and transaction management (amongst other things) - would I not try to use it and concentrate my time on the business and functional logic?

It's not perfect but it seems to give me most of what I need.

WORA not just a myth
We have to see WORA in a different way - not just as works/doesn't-work. The issue is how easy is it to port a working application from one platform to another. There are situations where adjustment should be done and even new code written or rewritten, but in my experience in Java you can do it in a fraction of the time it would take you to do it other languages.

I must be odd, stupid or gullable...
Out of curiosity, have you deployed the EJB app yet, and if so, to a user base of how many users, and how many concurrently?

Two seperate issues
You have mixed two seperate issues in this article:
1. The complexity of developing EJB applications.
2. The portability issue.

Indeed EJB is not a suitable for all enterprise applications - for some it is a definite overkill.
For a nice discussion of this issue take a look at the article "To EJB, or not to EJB?" by Humphrey Sheil (http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html)

Once you have decided that you'll use EJBs in your project the issue of portability is quite important :
* You have a wide variety of application server to choose from depending on your budget and features (raging from free Open Source applications servers to very expensive ones).
* Most of the standard EJB code migrates smoothly from one application server to another. Most of the problems with the migration are on tuning and extra-features.
The issue of WORA is not a binary working/not-working value. WORA works because it lowers the overhead of portability to a manageable short time.

I must be odd, stupid or gullable...
yes I have, but they are all small intranet or extranet systems with 10's of users rather than 100's let alone thousands

But, is scalability also an issue? Are there not many reference sites that the likes if IBM, BEA, jBoss can point to? (admittedly a lot of marketing hype, but there must be some truth)

What we tend to do a lot, although the user base is always small, is build intranet systems which would have traditionally been done with a VB or Access front end - so I would argue that some of the complexity in giving them this kind of functionaly is equal (in a different direction) to building something that caters for '000s of users. Also the database(s) that they need to talk to are varied and often in terms of Gbyte's in size.

Bollocks
>> * Object pooling in Java in general achieves less frequent garbage collection. This is essential if you want to run a production system that isn't going to grind to a halt evey couple of hours.
>
>All depends on your garbage collection heuristic. Under simple mark-and-sweep, most definitely true.... but simple mark-and-sweep is the most primitive of all the GC algorithms, and Sun has most definitely moved away from that. Generational collectors, arena-based collectors, lots of different approaches are available that can make GC a lot friendlier for long-lived apps. Pooling objects here can in fact be counterproductive under those scenarios.

No kidding, ... are there GC approaches available than /can/ help long lived apps, which /can/ make pooling counterproductive ? Sure , you can setup a completely stupid GC alg. that clashes w/ object pooling, but you'd really have to know what you're doing. More likely though, object reuse ( by pooling ), will increase the availability of the JVM, not decrease it.

>
>* Object pooling wrt EJBs achieves concurrent access to single threaded EJBs.
>
>How so? The EJB spec explicitly disallows more than one thread on any given EJB bean, period.

By creating multiple instances of the same EJB off course, re: object pooling . ( maybe you should stop snipping relevant pieces of thread )

>
>* Object failover/recovery achieves object & state recovery in case of process failure. Completely transparent to the client of the failing object.
>
>Only for Entity Beans--the EJB spec explicitly states that in the event of process failure, stateful session bean state is lost and must be reestablished. Stateless session beans hold no state across calls anyway, and entity bean state is preserved in the database under transactional semantics anyway. Precisely what are we gaining here?

We gain automatic object recovery, and a framework for state recovery. Try that w/ raw RMI...
FYI , Stateless beans do hold state, the state isn't related ( or cannot be ) to the client, but they still hold state...

>
>* Thread management non existent ? Thread mgmt in EJBs is hidden from the developer, thread mgmt in Java non existent ? What are you on ?
>
>Precisely part of the problem--how would I do an async operation in an EJB? Or how do I set up an "active thread" within an EJB environment, to perhaps act as the controller in a workflow app scenario? EJB's threading model is entirely passive--a bean must be called somehow, and therefore must borrow a logical thread of control from the client. MDBs go some towards solving this, but still don't resolve all issues on this score.

What problem? We were discussing the (dis)advantanges of using EJBS vs raw RMI coding here , how is the threadmgmt in EJBs 'part of the problem' ? As for the asynch operations. That's what MDBs are for. As for scheduled/controllor-threads, EJBs or J2EE won't help you there, even worse, you'll have to find workarounds to get it to work, which I agree, sucks.

Hardly
I'm working for one of the worlds largest investment banks (can't say which) and we have a very large scale application (60000 users+) running off a couple of weblogic 6.1 application server instances and an oracle database. It uses both entity and session ejb which is modified, written and enhanced by a small team of six people including one manager. So far this has proved not only simple to architect and scale but simple to develop on and with. We have a mixture of skills and abilities in the team which allows us to break up the application into different responsibility groups. Senior developers, core session bean development etc, which juniour developers focused more on the presentation JSP javascription, and simpler session beans.

If my experience has been anything to go on I'd say that EJB is a welcome simplification that has enabled us to develop and deploy quickly.

EJB criticisim
Well this is the worst article I read against EJB. Fact is EJB has beans fact is for a large application you need components, you need session bean components and you don't want to grab that from internet not write yourself. You need components that talk to database that delivers the messages, that handles the transactions, that maintains the state for you that does the load balancing for you, that takes care of the failover. There is nothing ready made elsewhere for enterprise application. EJB is the best java could offer till now, no matter how much you love coding every single time the same logic, you should not forget all that is ready made available.

WORA is stinking Red Herring...
WORA is absolutely a red herring. It is like watch manufacturers who advertize that their watches are waterproof down to 150 and 200 feet under water. Which of the two are you going to buy, the 150 foot deep watch or the 200 foot deep watch? You are going to buy the one that is good down to 200 feet because it is obviously better. When are you ever going to take your watch down 200 feet under water? Another example is the useless "feature" on many vacuum-cleaners, the 2-speed switch -- Off, Medium, and High. You will never use the medium setting. But when you go to buy a vacuum cleaner and you are faced with buying the one that has 1-speed or 2-speeds, you will buy the 2-speed because it has more features. Marketing takes advantage of the gullible. 2-speeds, 200 foot waterproofing, and WORA are MARKETING ploys to get you to buy something. They are features you will never use. You don't need WORA.

EJB's are COMPONENT BASED BUSINESS LOGIC ARCHITECTURE
.. unfortunately the author never mentioned it and this makes difference as much as structured programming from OOP.

CLOADSUN

EJB alternative - JDSM
Please take a look at http://www-106.ibm.com/developerworks/java/library/j-jdsm/
for a simpler, smaller alternative to EJB that may be of interest to some folks.
Noam
noam@telemessage.com

Bollocks
I couldnt agree more Bullocks, I have read many articles on the death of the Entity bean and had many heated discussions around using them. In the end they provide a useful consistent model for data modeling.

The one point you missed in remoting is the ability to cluster which is best performed with application server capable of managing remote object pools.

Thanks for your reply to this garbage.
Not Bob

WORA is stinking Red Herring...
Strange... cause I use WORA constantly. I develope on PC's, deploy on Solaris and even do some testing on Linux. Almost every day!!!!

Florian Hehlen

Bollocks
*****************************************
What problem? We were discussing the (dis)advantanges of using EJBS vs raw RMI coding here , how is the threadmgmt in EJBs 'part of the problem' ? *******************************************
Think about SOAP/ Web services for remote access. Now that you have web services, you do not need EJB for solving RMI threading issue.

EJB Article
Thought provoking!!!!