This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: This explains a lot
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Ted Neward points out some of the reasons why there are performance issues with many EJB applications - it has to do with developers following the rules laid out in the spec in all cases. Ted states that you hav eto know when to vary from the rules, and has this to say on the subject:
To truly criticize the EJB Specification without understanding why they made up those crazy, arcane rules is where the real crime comes in. The architect in Bob's story is committing an evil sin, to be sure, but so are you if you just take away the idea that you never want to use EJB. EJB solves one problem very very well--that of handling distributed transactional processing--in a fashion that's intended to be a very scalable model IF you play by their rules. And let's look at what those rules ultimately leave you with: a collection of objects that don't look like objects at all, but instead look more like a bunch of procedures collected together into lexical scopes (in the case of stateless session beans) or loosely-related objects (in the case of stateful session beans). MDBs fall into the lexical scope scenario, and entities were just a bad idea to begin with, so I'm not even going to consider them. (They should have been something hidden away within the implementation of the session or message bean, rather than something that could be seen outside of the container itself. Much like JDO accessed through a Connector, in fact.)
Basically, the problem comes in when you try to use EJB as distributed object technology. Funny that you might try that with an allegedly OO language :) This ties in with the comments by Anders Hejlsberg I stumbled across the other day - the ones where he states that OO and distribution are at odds with each other. Having looked at the way we do Opentalk in VisualWorks, I don't think that's true. What might well be the case is that OO and static languages attempting to do distributed objects are at odds with each other...
Previous Topic
