In "Where are the components", Joseph Ottinger makes some interesting points
about the absence of reusable components in the Java land.  In
many ways, I share his concerns and I said so in a
previous entry. 
However, there are a few inaccuracies in his editorial that I’d like to address.

Joseph says:

EJBs were the answer to distributed computing,
with a promise of massive scalability.

That’s not at all what EJB’s were supposed to be, nor what they promised. 
Initially, the EJB specification defined a component model, and nothing more. 
Granted, it was ambitious, as it tried to address several "fringe" issues as
well, such as security, remotability and persistence.  The specification
made a few initial errors in its first revisions, which are now addressed for
the most part.

I do agree with Joseph about Stateful Session beans, which qualify as a
failed experiment in my book as they are bested by servlet sessions, but the
following statement needs some precisions:

Sure, you can get some of their promise out of
session beans, and message-driven beans are easily my favorite aspect of the EJB
spec, but getting good performance out of stateful beans or entities can be a
fine art in and of itself.

It’s true that writing Entity beans that scale requires some expertise, but
then again, scalability is a complex problem.  No technology will give you
this feature for free.  Blaming the EJB specification for this is unfair.

Let me turn to a quick example to illustrate my point.

Those of you who are aware of FreeRoller already know about this. 
FreeRoller still has massive scalability problems and the hardware and the
bandwidth can no longer be the culprit.  This leaves two possibilities:

  • Hibernate and/or Roller need to be optimized.
  • Hibernate and/or Roller have a fundamental design flaw that prevents them
    from scaling.

A few very good developers (including Gavin) have been investigating this
issue but so far, the results were inconclusive and FreeRoller is still showing
dire scalability problems.

Now don’t get me wrong:  I love Hibernate and I think it’s a piece of
software
that will pave the way for future persistence frameworks, but right now, it is
showing that scaling and relational persistence are two goals that are extremely
hard to achieve together.

I contend that EJB’s enable this goal, as many WebLogic customers can testify.

But don’t let this distract you from Joseph’s article, which makes good
points about the absence of real Java components.  This problem is not new
and I read about it for the first time in 1994 in Oliver Sims’ seminal book "Business
objects".  CORBA took a shot at it back then, but didn’t go very far.

Now here is a thought:  what if the components were already here, but
we’re not seeing them because they adopted a shape we are not expecting?

Think about it.

When a corporation buys Microsoft Word, they do it for the end user
application in the first place.  The fact that they suddenly have all these
powerful COM components at their disposal is just a by-product of this choice. 
It’s not advertised, nor does it represent the main use of the software, but it
gets used nevertheless.

Let’s turn to J2EE application servers now.  Aren’t they the epitome of
component reuse?  When you write a J2EE application, you are reusing a
staggering amount of components that have been written and packaged for you by
experts:  web, database, remote access, transaction, security…

These are components right there.  Not the kind that Oliver Sims
envisioned, but components nevertheless.

Components are happening.  Slowly, but surely and pervasively. 
J2EE application servers provide us the equivalent of integrated circuits for
the electronic world:  well-defined blocks of functionalities that
developers can build upon to raise the level of abstraction that they provide. 
We have the plumbing and we are now progressively building the house around it.

And J2EE is the main enabler for this amazing phenomenon.  I can’t wait
to see what the business world will look like in ten years from now…