The Space vs. Time Dilemma
BMP entity beans have been the de facto means for using entity beans with application servers compliant with EJB v1.0 and EJB v1.1, but there are other reasons why such a model could be important until EJB v2.0 implementations become more widely supported. That is, although you can create EJBs that are J2EE-compliant and, therefore, deployable in any J2EE-compliant container that supports such an API, there are a few gotchas.
API portability does not translate into high-assurance execution portability. Vendor implementations of EJB tend to have a few bugs here and there, as well as fundamental lack of features that dictate whether an EJB application will scale well. For example, my colleagues at Assured Technologies and I have had to implement a means to provide server-side caching of entity data so that the database is not accessed every time a particular entity bean instance is referenced. Application servers might provide vendor-specific ways to keep a bean instance from accessing the database when the bean is read into memory. Of course, this is bad if the data is being affected externally by another tool and you want to have fairly up-to-date entity information (such as product stock status). The opposite extreme of inducing the EJB server to access the database every time the entity bean instance is accessed is also undesirable from a performance perspective. Use of transaction semantics can also degrade performance in such situations.
Although caching data can address such performance problems, too much caching of data can also lead to problems. Excessive amounts of EJB caching can make a server attempt to passivate bean data too often, which can bring a server to its knees. And my colleagues and I have even run into situations in which certain vendor implementations of EJB passivation actually killed the server. You also need to worry about excessive amounts of garbage collection (GC) from the JVM when caching too much data. Such "GC frenzies" can also cripple the performance of your application or perhaps kill your particular vendor's server. Needless to say, the developer must overcome such problems, or perhaps your EJB vendor has a solution for you.