Runtime
24 February 2002
<< Deployment
Once you have developed your Enterprise Beans and web apps, packaged them into their respective Jars, Wars and Ears, deployed them to your favourite gronky EJB server, fought with the deployment tools...
... edited the auto-generated deployment descriptors to make them work, and then actually seen your JSP page display some data, and rejoiced that the Gods of EJB have allowed you this small victory… then you might think that you are home dry.
Unfortunately, there are still the Runtime issues to be grappled with.
| 77. |
The real bottleneck is data access and transactions, of which the average database can only handle about 50-100 a second. EJB needs to take on board replication server duties in order to really speed things up. |
| 78. |
There is very little scope for run-time optimisation. The EJB specification contains no standard flags or extensions for improving performance. For example, WebLogic has used a 'dirty' flag to help determine if the object should be written down to the database. Despite being a well-known extension with well-understood semantics, this didn't make it into the latest specification. |
| 79. |
EJB performance is very slow, and uses lots of resources. It's costly to scale. The "fetch my primary key" query model suggests that the designers did not understand how relational databases work:
The EJB queries return a list of primary keys. Each of these primary keys are then used to perform another query to the database. This operates in a way contrary to the way relational databases are optimised, i.e. on sets of rows. The whole philosophy behind EJB object pools is to re-use objects, and not cache them. This relates to Damnation #3 - that EJB is designed to preserve memory, when memory is not a scarce resource - in fact it's a dime-a-bucket at the moment.
|
| 80. |
EJB cannot scale. Because your entity beans need to be synchronised across all the servers that they are deployed on, the amount of network traffic multiplies. |
| 81. |
The Reference Implementation (RI) is fragile, easy to break. 1.2.2 simply broke on perfectly valid code. It also isn't backward compatible - an ear that worked on an earlier release simply doesn't run on a later release.
The specification was not specific enough to guarantee certain behaviour.
|
| 82. |
EJB servers which have their own Servlet/JSP engine often get it wrong, e.g. WebLogic 5.1 needs to get to SP7 at least to be even mildly reasonable. Servers like Orion and HP-AS still have issues with basic functionality. So even if the EJB side is fine, your web apps will malfunction. |
| 83. |
Black box. When your deployed system goes slow you can't work out why unless you have the container source. |
| 84. |
An EJB server is harder to build than a servlet engine. Hence they tend to be far more fragile and mad, which is hardly a good base for an enterprise application. |
| 85. |
Sun said that to be 2.0 compliant an EJB app-server would also have to support 1.2 compliant EJBs. But their own reference implementation does not support 1.2 compliant beans, because the Sun specific 2.0 XML interpretation throws errors with 1.2 compliant XML. |
| 86. |
Sun's J2EE compliance tests seem to let some pretty obvious omissions through. For example HP-AS doesn't handle nested archives (i.e. referencing one jar from another through a declaration in the Manifest file), which is part of the J2EE spec. A server can be officially branded J2EE, even if half its J2EE features are broken. The promise that they'll be made to work in the next service release doesn't quite cut it, and often ends up not happening. |
| 87. |
Can Sun PLEASE focus on the RI, working around the clock, until it is 100% in line with the specification? Will we ever get to the state where the RI is in line with its goals, or will the spec always be aspirational?
Why don't Sun take an established open-source EJB server such as JBoss, and work on making that their reference implementation (or alternatively, open the RI out to Open Source, in the same way they did with Tomcat for servlets/JSP)?
|
>> Next Category: Knock-On Effects
Message Forum
<< Back to EJB Central
<< Back to Software Reality
|
Programming
