In generale una buona soluzione ORM dovrebbe essere facile da usare e capire. Dovrebbe promuovere l'uso di buoni modelli di progettazione (DAO, DTO, caricamento lento, servizi, limiti delle transazioni, facilità di configurazione, ecc.). Dovrebbe essere non invasivo, cioè non dovrebbe costringerti ad estendere classi speciali o implementare interfacce speciali.
Le specifiche dell'EJB si sono ridotte molto nei primi giorni, portando la migrazione di massa a persone come Spring e Hibernate. EJB1 non è riuscito a definire adeguatamente i campi CMP sul bean, il tipo EJB2 implicava che dovevano essere accessors astratti piuttosto che campi effettivi, il che era semplicemente strano, e non è stato fino a EJB3 che qualcosa di simile a quello che tutti volevano effettivamente fosse creato. A quel punto era troppo tardi, tutti credevano che EJB avesse risucchiato e che il JPA e JTA JCR avessero risolto le cose.
EJB1 e 2 in genere costrinsero lo sviluppatore a mettere tutta la loro configurazione di persistenza in un gruppo di file XML ben lontano dal codice reale che lo stava usando. Questo ha portato a un sacco di confusione e codice buggy. Altri framework ORM hanno imparato da questo e hanno deciso di utilizzare invece le annotazioni. Grande vittoria per loro.
EJB1 e 2 avevano un supporto molto limitato per diversi tipi di relazioni e come potevano essere implementati nel database relazionale sottostante. Tutti i tipi di interfacce speciali dovevano essere rispettati e il codice risultante era difficile da capire.
In ogni caso, tutto ciò che è nel passato e possiamo aspettarci un futuro brillante con persone come Hibernate che implementano JPA e JTA. Tutto molto armonioso.