Krishnan Subramanian wrote: > > 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. >
Let me start off by giving an analogy from this "users perspective". In the mid-80's the world discovered Object Oriented programming mostly in the form of C++. There was an immediate explosion in the usage of the language. That explosion has only been recently surpassed by java. By the early 90's many C developer's and developers of other languages were either already programming in C++ or were promoting the conversion at their company. Basically C++ took over the world. And that push certainly helped java. Java made a huge impact in a mere 4 years. In the middle of the 80's the first Object Oriented Databases appeared. They were immediately promoted as the coming future. All major database vendors immediately started projects to add capabilities to support this to their products. There were a number of start ups pushing their new databases over the big guys. Many C++ programmers pushed the newer OODB vendors as being the next best thing and everyone better get on board or they were going to get left behind. And I could be mistaken but I believe Borland at the time jumped on the OODB band wagon and Paradox might have been one of the first "major" databases out the door with support for that. Where does OODB stand in the database market now? They have barely made a dent in the market - and maybe not even a dent. And the support technology in the major databases is seldom if ever used. OODBs are a failure. There is a small niche where they might be the best fit. In the vast majority of projects relational databases are better. EJBs could own the world in 2-4 years. If it does then it will have proven the technology. If it doesn't then I would say it is a failure. And just in case you missed it, let me be explicit in my bias... When I started using C++ the advantages were immediately apparent. As I used it more I came to appreciate the advantages even more. When I started using OODBs the advantages were not immediately apparent, and they became less apparent the more familar I became with them. That certainly seems to be my impression of EJBs. Note that I have seen the advantages in other aspects of J2EE technology. And that does not seem to be diminishing with time. (Note that I will be using EJBs on the project I am on now. This was a marketing decision and not a technology decision.) > > 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? > True. Those are great buzz words. The reality is that companies, the vast majority of companies, do not implement long term solutions in a planned manner. Many seldom implement solutions even in the short term in a planned manner. There are even some that can't manage it even in day to day operations. An editorial in a recent magazine (Software Developement?) commented on a poll by a process control organization which has about 500 companies. And of those companies 58% (if I remember the number correctly) were at CMM (Capability Maturity Model) level 1 or above. The percentage of companies increasing their level was significanlty up from the year before. The organization also had less companies than the year before. One can presume that the companies that belong to the organization are really interested in process control. Contrast 500 companies with the following... There are over 10,000 banks (banks, savings, credit) in the US. Not counting branches of course. The vast majority (if not all) have some sort of software developement going on. In the bank I worked in, there were at least three seperate divisions all doing software developement and with absolutely no coordinated planning between any of those divisions. As a specific example of a planning failure, in a 3 day period the bank lost 30k-90k because of an automated process failed to run for that time period. I had implemented a report more than 3 months before that which would have reported the discrepency. The report had not gotten through QA because of more pressing business. This despite repeated requests for more QA personnel. When I left months after that the report still had not made it through QA. Telecom, in my experience, pushes process control the best. And yet in working with 3 regional providers and a number of smaller ones I never saw a single one which could even have made it to CMM level 1. Most of the developers in the company approach process control and indeed many trivial planning activities as a waste of time. This is not to say that I wouldn't like to see more companies, many more, manage to follow some consistent policies in terms of software developement. But the fact is they do not. So it is ridiculous to promote solely based on feel good promises which no (statistically speaking) company promotes anyways. (For additional examples look to some of the surveys in the ACM/IEEE journals done which focus on the policies that companies can put in place to foster software reuse. And look at the numbers whose policies fail to promote it and the far vaster number who do not actively promote it at all.) (And for a more specific example of a planning failure I can when an executive at Borland promised that the bug database for Borland products would be made available online, as other companies were doing at the time . And presumably something that many of us take for granted now. It took Borland at least 4 years if not longer to do that. Again, if I remember correctly, I was told personally that there was a solution in place after about 18 months but that there were some internal politics going on which prevented if from actually being posted.) > 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. > Yes. And in a system the factors that can have the greatest impact are requirements and design. And that has nothing to do with what it is implemented on. > 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. > Presumably you are referring only to projects where that methodology is appropriate. I don't want my DVD driver to use CMP or BMP. It shouldn't be using EJBs at all. I would prefer to say that "we might have traded...". After all if the container, written in java, can provide modularity and extensibility then I can certainly implement something that does the same. It will of course take me longer. > 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 > Hmmm...do you know how the FAA software works? It is definitly brittle. It is definitely complex. It is definitely not short lived. > 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. > As I am sure any sales brochure would say. > 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. > Again that depends on how it is implemented. Again it would take longer to implement that solution than using a EJB container. > 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. I really question that. Saying the code is brittle is a subjective observation unless you can provide the data to back it up. Feel free to provide that data. > > 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. > Nice feature but then you are saying that is okay to create "brittle" code? > 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. > Again a nice feature. So if I try to use your product and find something that I could do using JDBC and your server doesn't to are you going to immediately roll out a new version that does it? That of course is one of the advantages of using JDBC, it will do what I want. > 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. > That is a really incredible rate. Unfortunately it doesn't appear those results are available online (or perhaps they are if I am willing to pay $1100 for them?) I couldn't seem to even find anything that really detailed the testing environment or the requirements of the system at least in regards to BMP vs CMP. > 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) > Yep. Just as it is folly to claim that any significantly complicated system that is implemented using one type of technology/methodology would have been faster or better if it had been implemented using a different technology/methodology. The complexity of the system itself and humans that put the systems together have a far greater impact than any technology/methodology that might be involved. =========================================================================== 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".
