James Strachan writes (BTW, James you got my name wrong):

The biggest problem with EJB isn't the technical solution to remoting, to stateful/stateless session beans. Its that its all so visible and intrusive and damned complicated to use. Also the irony is barely 10% of uses ever even need the EJB solution. Most folks are developing web applications or web services that really don't need EJB at all. This stuff should be hidden and only actually used if stuff really is deployed remotely. .Net doesn't do this perfectly either; .Net remoting requires you to derive from MarshalByRefObject (rather like RMI in Java) whereas the SOAP stuff does not but requires extra class metadata. So again your business logic code must choose its architecture.

So I think we need a new simple business logic Container API and then we can deploy our business logic in lots of different configurations using different technologies. Right now the closest thing I've seen to this is EOB with JBeans a close second both of which I think are close to what we need.

Are we seeing some kind of convergence here?  Graham Glass is talking about some other alternative to EJB.  The Avalon folks are pursuing a new Enterprise Object Model.  JBeans and ACE are producing code generators to target n-tier deployments.  Rickard Oberg is building his Dynamic AOP.  Ara talks about XRAI and a metadata bus. Aslak talks about integrating UML2EJB, MiddleGen and XDoclet.  

What I see common in all the above endeavors is the need to keep the core logic separate from the implementation.  Although, this principle seems entirely obvious, EJB in its current incarnation goes completely against it.  The conflicting motiviations for EJB (Transaction Monitor ideas, compliance with CORBA standards, Business Objects or Beans programming model) have created a Frankenstein.  A Technology where a business' core object model is hopelessly lost inside a jungle of design patterns.

Post-EJB is an attempt to separate the core model from the implementation.  The core model needs to be preserved at all times.  This leads to better traceability and a more agile implementation.  Imagine building your core object model without the complexities associated with EJB, test and execute it just like a plain java object.  Build and deploy inside a Enterprise class container that gives you all the quality of service (QOS) features.  That's what the Enterprise world needs and that's what we're not getting using EJB