Hey
I recently posted an evaluation of Roger Sessions critique of EJB1.1
(http://www.objectwatch.com/issue20.htm). At the time part 5(of 5) was
not posted, but since then it has been which is why I am posting this
addendum to the evaluation for completeness.
The previous posting covering parts 1 through 4 can be found here:
http://archives.java.sun.com/cgi-bin/wa?A2=ind9908&L=ejb-interest&F=&S=&P=3526
Note: This post only covers part 5, but it is still quite long.
Part 5 of 5
First paragraph:
"You may think, after all this, that I hate Enterprise Java Beans. Not
so. My point here is not that EJB is bad, but that only that it offers
no important functionality (for
distributed commerce applications) over and above what has been offered
by MTS since 1996 and what COM+ offers today. Its bean model is no
better than the
COM+ stateless component model. Its overall functionality is no better
than COM+. In fact, COM+ has several things going for it that EJB
doesn't have."
As the first part of my evaluation clearly showed, and which has been
confirmed by other postings, the assessment that the other types of
beans are useless is based on false assumptions about how an EJB server
is typically implemented.
Next paragraph:
"First, COM+ exists. As of press time, COM+ has been in beta for a
while, and is on the verge of product release. EJB 1.1, the
specification I have been discussing
here, is, as of press time, still only a draft specification, and
probably at least a year away from being released as a full product."
Here he again contradicts himself by first saying that COM+ exists, and
then that it is in beta. A beta product cannot be seen as finished and
useful for production work IMnotsohumbleO. His assessment that EJB1.1 is
about a year away from release is completely unfounded. I mean EJB2.0 is
slated for Q1, 2000 (see http://java.sun.com/products/ejb/faq.html) so
how could EJB1.1 possibly be released after that? Finally, EJB is not a
"product". From the EJB-FAQ:
"How much does EJB sell for?
EJB technology is not a commercial product - It is a
specification created
and published by Sun and freely available on Sun's
web site.
"
And the next paragraph reads:
"Second, COM+ is mature. It is the second generation of COM/DCOM/MTS,
technology that has been with us since 1996 and has proven itself in
mission critical
commerce applications, two of which I have given case studies for in
this book. EJB is immature and unproven technology. "
Anyone who went to the "EJB Users panel" at JavaOne knows that the
statement that EJB is immature is false (see
http://industry.java.sun.com/javaone/99/event/0,1768,538,00.html for
reference). There are lots and lots of successful EJB apps running
today. And, as anyone who has observed the EJB server market for some
time will tell you, the rate of improvement among servers is amazing.
The glory of market competition at its prime :-)
Third paragraph:
"Third, COM+ offers capabilities not matched in EJB. COM+ has
asynchronous components, a better event model, fail over support, in
memory databases (not that
I think much of in memory databases), and excellent interoperability.
None of these are in the specifications yet. Any products that do
include these features do so in
proprietary manner"
Asynchronous components is something that is certainly lacking in
EJB1.1, but it is something that is scheduled for inclusion into EJB2.0.
When he says that EJB does not have fail-over support I suggest that he
takes a look at, for example, WebLogic 4.x clustering. No failover, eh?
Further he doesn't think of the IMDB that much. Well, EJB'ers doesn't
think of it at all. Working with CMP EntityBeans allows one to avoid the
fact that a database is doing the heavy work. It's all completely
transparent. "Excellent interoperability": has he ever tried to
interoperate several WebLogic servers? Great interoperability...
Fourth paragraph:
"Fourth, COM+ does not tie you to one language. You can write a COM+
component in any language: Visual Basic, C, C++, Java, COBOL, and
others. EJB
beans can be written in one and only one language: Java."
Strictly speaking this is incorrect. EJB ties you to the Java
*bytecode*. And not even if it was tied to the Java language is this
such a big problem. It is perfectly possible (*today*) to use other
languages for which there is an interpreter written in Java, such as
Python, Tcl or BRML (Business Rules Markup Language). It might even be a
good idea to do so since the maintenance costs of any given application
is minimized by using a language that maps the needed semantics of the
application. Java might be too powerful for some applications, or
doesn't let you effectively express what you want to happen.
And again:
"Fifth, COM+ is free, or at least, it comes with Windows 2000. If you
buy Windows 2000, you have COM+. If you don't use it, Microsoft is not
going to give you
any of your money back. EJB must be purchased as an add-on to Windows
2000. And while some versions of it will be available inexpensively,
these are not the
versions you are going to trust for your mission critical application.
Mission critical applications will require very sophisticated high end
EJB implementation, the kind
you will get from companies that have strong backgrounds in Transaction
Processing Monitors. Those versions are not going to be available
inexpensively."
Granted, purchasing a good EJB server is expensive. But then again, if
you need that kind of power it is likely that money is not the problem:
you need 24/7 availability. Can COM+ offer that? We'll see, but the
public server crashing competition that Microsoft recently held was
somewhat interesting.. it crashed by itself without any interference..
And from what I have heard the more inexpensive EJB servers, such as
Ejipt, offers very good stability for that price.
On OS integration:
"The problem is that these versions will be layered on top of Windows
2000, not integrated tightly into the operating system, as is COM+.
Therefore
Windows 2000 EJB projects are unlikely to run as well as COM+."
If COM+ is so integrated with the operating system, when (not if..) it
crashes is it not likely to take the system down with it? Furthermore,
EJB gets its performane edge not by its integration with the OS, and
because it is running Java (obviously, although that is rapidly becoming
a non-issue), but because its design allows a server to make some pretty
remarkable optimizations. In enterprise systems it has been argued that
about 10% of the time is spent in the middleware server and 90% in the
database. Hence, it is not in the middleware server that optimizations
are crucial but in the database and the use of it. And this is where
EJB, and its implementations, excel.
On bean portability:
"Code generation, especially the database mapping code for container
managed entity beans, is likely to be a significant task, requiring
expertise with the tools from a
particular vendor. The newly generated code, once it has finally been
generated, is going to have to be compiled before it can be used. So to
imply that beans can be
downloaded from anyplace and used without requiring recompilation, as
described by the EJB specification, is inaccurate."
Yes and no: significant work may be required by the Deployer if the
database mappings are non-trivial. But one of the improvements in EJB1.1
(and he explicitly critiques 1.1, not 1.0) is that there is now a
baseline requirement for the CMP server implementations. This should
provide a good base for bean portability. It is also expected that many
beans will be written as CMP beans and then layered with BMP so that the
beans can be tested against the most popular databases (around 5) and
perhaps even distributed with several BMP layers, hence making
deployment a matter of choosing the right BMP layer.
On proprietary services:
"Since these value-added
services will not be standardized, beans using them will not even be
portable to other vendors that have equivalent services. The
specification should say, "An
enterprise Bean that depends on such a [value added] service can only be
deployed in the container for which it was developed."
Strictly speaking this is correct. However, this is exactly why there is
now work being done on a Connector API which will allow custom services
to be plugged into any EJB compliant server, so in reality this will not
be a problem.
RMI detail:
"Historically, Java has ignored IIOP and developed its own wire protocol
for RMI."
Java has not developed its own wire protocol: RMI is an interface
specification, and the JDK is shipped with a default implementation.
There are well-known improved implementations such as WebLogic RMI and
NinjaRMI. RMI/IIOP is just another implementation. The RMI people has
however not been as exact as the EJB team in defining what is RMI (the
design) and what is JRMP (the wire protocol implementation) which is why
there is confusion on this subject among developers.
New RMI?:
"That compromise was that RMI would be rewritten to use the IIOP wire
format."
Again, RMI/IIOP is just another implementation of RMI. RMI/JRMP will
still be available, in fact it will be greatly enhanced in the next
version of Java, codenamed Kestrel.
The rest of his article is dedicated to conclusions based on the above
assessments. Read them if you want, but have my comments in mind. He has
some points, but overall they are extremely biased.
Thus endeth the lesson.
/Rickard
===========================================================================
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".
