I agree that the article was riddled with semantic errors. While these can
be confusing to the reader, I think an articulate response is needed for the
more damaging, technical fallacies raised by Roger's article. Rickard
touched upon a few, and I hope that Anne Thomas will be able to do the
rebuttal justice.
Most of Roger's technical (if you can call it that) massacre of EJB centers
around the fact the an EntityBean must perform a database read whenever it
is referenced. Rickard pointed out that this read only takes place when the
reference has a method invoked upon it. He also stated that the power of EJB
containers is fully realized when the container is allowed to cache this
data, thus preventing subsequent database reads. Assuming this is the
norm,Rickard was able to dismiss several of Roger's claims regarding an
EntityBean's performance. I'm not sure that Rickard can summarily dismiss
this fact.
The greatest performance increases in EJB come from exclusive access to the
database, and Roger thoroughly misses this point in his ongoing article.
Rickard, on the other hand, relies on this fact to shoot down Roger's
assessment. The truth lies somewhere in between, and the authors of the EJB
spec were astute enough to pick up on this fact. Here is the section of the
EJB1.1 spec that applies:
===========================
9.1.10 Commit options
The Entity Bean protocol is designed to give the Container the flexibility
to select the disposition of the instance state at transaction commit time.
This flexibility allows the Container to optimally manage the caching of
entity object's state and the association of an entity object identity with
the enterprise bean instances.
The Container can select from the following commit-time options:
Option A: The Container caches a "ready" instance between transactions. The
Container ensures that the instance has exclusive access to the state of the
object in the persistent storage. Therefore, the Container does not have to
synchronize the instance's state from the persistent storage at the
beginning of the next transaction.
Option B: The Container caches a "ready" instance between transactions. In
contrast to Option A, in this option the Container does not ensure that the
instance has exclusive access to the state of the object in the persistent
storage. Therefore, the Container must synchronize the instance's state from
the persistent storage at the beginning of the next transaction.
Option C: The Container does not cache a "ready" instance between
transactions. The Container returns the instance to the pool of available
instances after a transaction has completed.
===========================
Exclusive access to the database is a difficult thing to guarantee for
large, scalable enterprise applications. For most EJB servers on the market,
this concept falls apart the moment you activate more than one container to
host the same EntityBean. There are some containers that support persistent,
shared cache mechanisms, but most do not. Regardless, many applications that
I have developed, would not be able to support exclusive access to the
database.
The beauty of the EJB spec comes from its flexibility. The power to decide
many issues regarding transaction control, persistence, security, and naming
become deployment decisions and not programming obstacles. If I can
guarantee exclusive database access, use it. If not, then flip a switch in
the deployment descriptor and database reads will occur. It's all about
choice, not to mention some, never before seen, platform independence. If
you choose to implement your entire server-side component model as stateless
session beans (as the COM+ spec does) so be it. If you don't want to write
any database code, use CMP EntityBeans. If you have to, go Bean-Managed
Persistence. Never before has a dozen or so interfaces given me so much
capability.
The media hype and programming effort is definitely squarely focused on EJB
right now. The biggest challenge is articulating the real-world benefits of
EJB to the average Java developer. The door is open, and we can only blame
ourselves if we don't see some *substantial* (quality not quantity) content
in JDJ, Java Report, Java Pro, JavaWorld, etc...pick one. The average
developer needs a development quality (freely available) EJB server to
play/test/learn with. This doesn't exist now.
<slightly off-topic>
If BEA/WebLogic would lift the 30-day trial on their server, I believe that
this momentum will continue. I don't want to bankrupt BEA, but I don't
believe that this will hurt BEA's (or anyone elses) bottom line, especially
if connectivity limits were still in place. Remove the 30-day "trial"
license to encourage more people (including students) to use your product
and more people *will* use your product. I think the reason RMI took off so
well was the availability of a reference implementation from Sun. I have
heard rumors of a reference implementation of EJB from Sun, but I don't
think we'll see it any time soon.
This soapbox topic isn't restricted to BEA, by any means. It just seems to
me that they are more in tune with what the developer wants/needs.
Persistence, Gemstone, Inprise, Oracle all seem to have very capable
servers, but a very limited amount of developer material (or none at all,
until purchase) available on their website. Developers don't usually want to
have to talk to a salesman, just to play/explore a new product. BEA and
Valto seem to be the exceptions to this rule, and BEA has had good docs and
tutorials on EJB for a couple years now.
</slightly off-topic>
I don't expect Roger Sessions to open his mind a crack and see the benefits
of EJB. Roger is defintely a tool of Microsoft. I personally think Microsoft
is a great marketing organization with great productivity software, good
development tools and a fairly good operating system. Above all, they have
great documentation, tutorials, and examples for the developer. Java has
also had some success in this area as well, but EJB is not a simple topic
that can be covered in a single article or a series of articles. Teaching
the fundamentals of EJB is a snap. It's the concept of application design
and how it relates to the EJB framework that is more difficult.
If Roger's readers blindly accept his propoganda, then we (as Java
developers/EJB supporters) have done a poor job at getting our message out.
This message must not stoop to the same snobbish assertions applied by Roger
Sessions, but rather, be factual, understandable, and indisputable.
jim
PS. Maybe I should of used <soapbox></soapbox> around the whole thing!?
Sorry, I got carried away!
===========================================================================
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".
