Ladies & Gentlemen, This topic has been thrashed around quite a bit, but I thought I should do a bit to contribute given that I've been a strong proponent of entity beans. Hopefully, this writeup provides a "vendors perspective" of things as well.
The contents of this are based on a paper written by Jonathan Weedon. I'd also like to point readers to another paper that provides some useful insight into how an EJB Container handles entity beans internally. The paper also provides insights into optimizations that our Container provides. http://community.borland.com/article/0,1410,29074,00.html Performance is not the only yardstick by which enterprise applications are measured. Often just as important, or more important, are metrics such as: - Complexity: how hard is the system to build? - Modularity: how much of the system can be reused in future projects? - Extensibility: how easy is it to enhance the system? - Longevity: what is the usable lifetime of the system? In this writeup, we keep in mind that getting an application running fast is really only a small part of the overall challenge. As such, we avoid making suggestions that trade off performance improvements for an inferior implementation. A good example of the tradeoff between raw performance and a well-designed application is the use of Container Managed Persistence Entity Beans for accessing the database, verses using direct JDBC. Although admittedly it is possible to write a JDBC program that accesses the database directly, and for this application to be faster than a well-designed CMP Entity Bean based application, we have probably traded off modularity and extensibility for performance. Although at times the ultimate in performance can only achieved by building low-level systems, typically such optimization techniques lead to complex, brittle, and short-lived solutions The EJB specification has evolved over time towards the use of Entity Beans for data access instead of raw JDBC. This evolution can be seen in each revision of the specification: in EJB 1.0, Entity Beans were optional; in EJB 1.1, Entity Beans were mandatory; and the CMP model was enhanced; in EJB 2.0, the CMP model was substantially enhanced again. As the Entity Bean specification has evolved, so have various implementations of Container Managed Persistence. Today's best CMP engines support extremely high-performance data access, while providing a high degree of portability across J2EE compliant application servers, and a high degree of portability across various flavors of DBMS. Over time, there are a great number of optimizations that can be made on the CMP version of the application that cannot be made on the JDBC version of the application. This is due to the fact that the EJB Container has a great deal of control over how to execute the CMP code, but has almost no control over raw JDBC. So, for example, the CMP engine can reorder the data access to the database to trade off latency for throughput, and thereby scale the system further. Or, the Container can trade off time for space, by using algorithms that either use more memory, but less CPU time, or vice versa. And while these same optimizations are possible for the direct JDBC code, this requires code changes to your application. In the CMP case, it is the AppServer that is being configured and optimized, not your code. In the above discussions, we compare direct JDBC access with Container Managed Persistence. What about Bean Managed Persistence, which some would argue is the happy medium between the two? Unfortunately, BMP is not a happy medium, it is an abysmal compromise. Typically, BMP code is both complex and brittle when compared to CMP code, while not having the optimization possibilities afforded by CMP. As such, it is strongly recommended that Bean Managed Persistence be avoided, unless one is using an older application server that either does not support CMP, or has very limited support for CMP. Certainly, if a product supports EJB 2.0 (as does our AppServer 5.x), or has good support for the 1.1 version of CMP (as does our AppServer 4.x), then BMP is a poor alternative. There are a number of reasons frequently cited for using BMP instead of CMP. Most, if not all of these are invalid in the case of Borland's product. Below we list the commonly cited problems, along with our solution. Myth: BMP supports more complex queries than does CMP. Reality: In the Borland Enterprise Server, any query that can be defined in SQL can be used to implement an EJB 1.1 finder method. That is, the query language supported by Borland Enterprise Server is unconstrained. In fact, even DBMS-specific syntax can be used in our queries. Unfortunately, in EJB 2.0 the query language is much more constrained it is in our EJB 1.1 implementation. To handle this problem, we allow the user to implement a finder method (or select method) explicitly in bean code. So, if a particular query cannot be implemented using CMP, one can implement just that one method using BMP, and allow all other aspects of persistence be handed by the Container. Myth: BMP must be used to implement relationships and other complex mappings. Reality: Borland provides a much richer set of O/R mappings as part of CMP (both for version 1.1 and version 2.0) than do most other EJB products. In particular, we provide support for all types of Entity relationships in both EJB 1.1 and EJB 2.0, we support dependent objects in both models, and we support complex data types such as CLOBs and BLOBs in both models. In cases where data types beyond those natively supported by CMP are required (new SQL data types such as java.sql.Array, for example), the CMP engine can be augmented. That is, support for additional, arbitrary data types can be added by the user. Myth: BMP is faster than CMP. Reality: Our performance tests indicate that CMP can be significantly faster than equivalent BMP implementations. This is borne out in our testing with ECperf, which provides both BMP and CMP based code. In these tests, we saw throughput increases of over 100% using the CMP version of the benchmark. Lastly, I've said this before; and I'll say it again: It is an absolute folly to blame any technology (say Entity Beans) for the poor performance of a particular product or implementation. (Or, blame the technology for an improperly designed and implemented J2EE application) -krish =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
