I am currently in the process of reviewing the design strategy and direction for EJB adoption for a very large, techno-savvy, risk-averse financial client. As part of the review, I looked across the implementations that my company, Infosys, has done for other clients. In the enterprise solutions world, it is fairly obvious that the solutions are stepping away from Entity Beans, Stateless Beans are viewed as "Give me a good reason why they were even invented," and Stateless Session Beans are used primarily as pass-through classes. A large part of the reasoning behind the latter is that folks don't want to put all their eggs inside the bean. MDBs make sense if you are trying to get to Session Beans. If the session beans are used purely as a remoting technology, then the usfulness of MDBs is also very limited. Business Delegate is used to the point of overkill in most situations. Given these types of scenarios, it is questionable why companies should invest in EJB technology. Agreed that the vendor-added features give you a lot of "free" features, but then you are not developing "pure-J2EE." In a previous life I have deployed enterprise products which used both Entity Beans as well as Session Beans successfully. But that was also because we invested in the technology and adopted it without worrying about avenues for alternative means of client access. This was not a requirement. Fortunately, this was a product built from scratch. But when clients want to be able to walk away from the EJB model, they want to make sure that the business logic is completely outside the session, the business logic components are accessible by other means (besides Session bean based remoting), and Session Beans are a pure facade - no aggregation logic or business logic.