Given that RMI-IIOP does not support distributed garbage collection (unlike RMI-JRMP), do I need to do something explicitly to GC beans, or is it magically handled by the EJB framework?

(The lack of distributed GC was noted in the article "EJBs from a critical perspective".)

It is the Containers' responsibility to handle distributed garbage collection. This is how EJB's were designed.

Looking at Stateful Session Beans (SFSB) or Entity Beans. When you write a SFSB, you must implement ejbActivate() and ejbPassivate(). Implementing these methods, mean that the container can passivate your bean, hence take it out of memory and store its state on disk or in a datastore somewhere.

Whilst this article does take a hit at EJB, I believe that it is misleading in some sense and is outdated. Most of the pot shots that it takes about EJB products not supporting latest standards etc. are now obsolete as vendors such as Inprise, BEA, GemStone etc. have updated there products, it's a shame that he didn't get to review the beta products...

The article also mentions the importance of "Dynamic Glue" which is not using statically generated stubs and skeletons. This is in fact possible with RMI-IIOP using DII (Dynamic Invoacation Interface), but he fails mention how this technology is used in building systems and why it is important. He says that it is why CORBA has failed, which is wrong. EJB is a logical extension of and most Containers are built on top of CORBA.

He also mentions the overheads of intra-vm calls. This is something that most products provide optimizations for and something he clearly hasn't researched as this is a feature that CORBA ORB's have supported for quite a while.