EJB's promote distinctly non OO programming practices:
1. Separation of data and business logic - the EJB model has Entity Beans which your hold your data and session beans which execute business logic. In every EJB system that I have seen the data objects are just dumb data objects. A true OO system would not have this separation. Let's take a simple example, credit card validation/charges. An OO approach would be to have a credit card object that could be asked are you valid, and charge this amount. The credit card object would know how to do it. The EJB approach is to have a session bean which does credit card authorization. The EJB gets passed in the credit card details and does the authorization, the credit card object is just a dumb data holder.
2. Little or no inheritance - it is very difficult to combine entity beans and inheritance, finder methods for example are not polymorphic.

see this [link|http://www.oreillynet.com/pub/wlg/1322|blog] for a similar opinion

"It looks to me that we are doing RPC calls from the client to the server (via the facade). Our entities are glorified structs, and sessions are functions that work on that data. So what do you think... is this the right way to be doing things? Is this OO? "