EJB Design Flaw

These days it seems like Enterprise Java Beans are a well accepted, yet controversial technology.

There have been some issues associated with it for some time. However, the recent benchmark by a once well reputed ejb development firm called many of the popular myths into doubt. The results of this benchmark sent people scrambling for explainations. Some very good explanations around code quality have been identified. However, the debate did not end there. People began to speak up about their misgivings. I hope to spend a little time over the next week exposing some of my own beliefs around this.

My first exposure to ejb was in 1998 at the java business expo. I don’t recall if it was announced there or if I learned of it in one of the side conversations I was having with the folks at Sun. All the same, it was an exciting new technology. I tell you this to talk a little about the roots of ejb. When it came out there was nothing, nothing, that even touched it. It was replacing Corba as a solution for enterprise apps. Corba was a great technology, but it was starting to show it’s age. For the types of enterprise applications that Sun was targeting, it was too complicated. I tell you this because it is critical to one of the most important issues in the J2EE suite. Entity beans (which I will talk more about in another entry) were largely inspired by Corba distributed objects. This is the reason why initially entity beans were accessed remotely. The idea was to share objects accross multiple machines. Of course, this later evolved to sharing services. At the time though, this was the influence that may have created the most glaring legacy issue in ejb.

With all that said, entity beans are not the most important issue that is aging ejb technology. Instead the issue is the development model that Sun tried to impose. For those that remember the original application development guide, Sun introduced the concept that enterprise software should be developed by component builders, component assemblers, and deployers. To a degree the idea was both ahead of its time and unrealistic. It was ahead of its time in that we are starting to see a bit of realization of the component builder / component assembler in the web services arena. However, the third part was never realistic. The idea that the folks that were in charge of deploying the ejbs would be knowledgable enough to modify deployment descriptors and rebuild the project was a reach at best. The result of this has been over engineered metadata that in many cases requires duplication of content. This is why JDO generated so much initial hype (and Hibernate is getting some now). They evolved after people realized that the developer was the one that should be modifying these descriptors. The propostion that I should have to edit 6 files to persist one object tears at the metacarpal tendons that have to key them in. As a community, we have come up with some tools to aid with this. However, to fix it code generation tools are not enough. We have to acknowledge that the fundamental concepts underlying the metadata approach are flawed. The only things for which a case can be made for the meta data are the datasources and schema information. All of the other stuff, is bogus. Frankly, I am not sure that this is a good candidate for externalized metadata either, but that is another conversation.

With that said I want to acknowledge that ejb is a technology that has transformed the industry. I am going to be spending some time talking about the flaws in the future entries, but first I want to recognize and thank the visionaries that created it for a truely remarkable revolution in enterprise IT technology.