A Response to David Chappell's "MTS versus EJB"

by Chris Cleeland

Update!

The original author, David Chappell, and I have exchanged several emails discussing how our opinions are formed. Based on these conversations, there are some aspects of my response which I would change.

I assured him that I would make those changes and make a rebuttal from him available, but I have simply been overcome by recent events and not had time to do it justice.

Therefore, please take the words written herein in the light that some of my original opinions may have softened. You can be assured, however, that the core of my opinion, i.e., that bias lead to inaccuracies and omissions in the column, remains.

Background

A colleague just asked me to read the Nov. '98 column "MTS vs. EJB" in Component Strategies. Considering that the column title is "On COM", I expected bias to lean towards MTS. However, I was awestruck at the inaccuracies regarding EJB and CORBA, and wonder how such things could ever get through peer reviews? So, I decided to write a response.

However, rather than simply sending it off without peer review (what I've accused SIGS of doing, or not doing well, in this case), I'm making it available on my web site for many to review.

The Response

A colleague just asked me to read the Nov. '98 column "MTS vs. EJB" in Component Strategies. Considering that the column title is "On COM", I expected bias to lean towards MTS. However, I was awestruck at the inaccuracies regarding EJB and CORBA, and wonder how such things could ever get through peer reviews?

We find the first incorrect statement in the first paragraph: "[EJB] was created by a group of vendors headed by Sun." Certainly Sun enlisted the participation of other domain experts, but this is far less a design-by-committee (ala the OMG) than it is an enlightened dictatorship. Sun, in the form of JavaSoft, is solely responsible and has final say on what goes into an EJB specification, as in all other JavaSoft specifications.

Then, we find an error which is most likely a typo: "Unlike Entity Beans, Session Beans allow the..." Typos normally don't motivate me to write the editor, but this one is SO glaring that its very existence is a strong indicator that this column was not proofread by anyone with more than a marketing knowledge of EJB. Never mind the fact that the rest of the sentence ("...the TP monitor [loads] and [stores] the Bean's state.") is technically incorrect since a TP monitor's responsibilities are completely orthogonal to those of a persistence mechanism (yes, many persistence mechanisms DO possess some transactional abiities as a convenience, but the two exist on independent planes).

None of the errors mentioned thus far even come close to the magnitude of the errors presented in EJB Cons. Were I enlisted as a pre-publication reviewer for this column, I would have needed a second sheet of paper in order to contain the commentary because the almost every sentence contains something wrong.

For example:

"EJB was produced by a committee of competing vendors..."
We've already covered this one above, but the fact that it's re-stated and wasn't caught *AGAIN* is another strong indicator of the lack of adequate peer review.

"...the biggest problem...is its lack of true standardization."
I guess this depends on the level at which you looking, but EJB, as a 1.0 specification, has done very well to NOT overspecify. Certainly there are underspecified topics as is expected in anything in its first revision.

"EJB all but assumes the use of...CORBA."
Really? What evidence supports this? I can say that in my evaluation of implementations of EJB over the past 4 months I have not found a single implementation which even *utilized* CORBA, much less anything in the spec (which I have read rather painstakingly) which indicates CORBA as a requirement.

"...cross-vendor interoperation essentially requires...IIOP."
Actually, this could not be further from the truth. EJB requires passing of objects by value, and the vast majority of current IIOP implementations do not yet support object-by-value, though it is in the latest release of the spec. There are currently two ways in which EJB might use IIOP or CORBA: accidentally, such as when RMI's wire protocol is changed to be IIOP; or explicitly, such as implementing the EJB/CORBA interoperability specification.

"...there's been little success in building truly effective distributed environments from multiple vendors' CORBA-based products."
While this bare statement is correct, there appears to be confusion regarding causality. Mr. Chappell's writing implies that IIOP is the cause of this problem, when, in fact, IIOP is the only level below IDL at which different vendors' CORBA implementations *can* interoperate. The Portable Object Adapter which debuted in the CORBA 2.2 specification seeks to mitigate the majority of problems associated with creating portable implementations of interfaces, but that was released only in early calendar year 1998.

"Complete standards for directory services...are lacking."
EJB specifies the Java Naming and Directory Interface (JNDI) as its means to get and store naming information; it expressly DOESN'T specify the details of the naming service, and defers the mapping of the interface to the naming service *implementation* to others. This is commonly known as "separation of concerns".

"EJB...doesn't even indicate which wire protocol should be used for controlling transactions"
I'm very confused by this statement as a "con", because in "EJB Pros", Mr. Chappell discusses how EJB can utilize existing TP monitors. If EJB specified the wire protocol, wouldn't it then exclude the use of existing TP monitors, or at minimum force the use of a single TP monitor? Rather, and just like EJB's stance naming and directory information, EJB can use anything that has a JTS-compliant interface. EJB doesn't specify a wire protocol *because it doesn't care!*

"...[a] side-effect of creation by committee is complexity."
Sigh...I will avoid beating the dead horse of the erroneous "creation by committee" and instead focus on the "complexity" assertion. The purported complexities stem from (a) permitting simultaneous operation of defining 3 different transaction boundaries (none cited, however) and (b) the multiple flavors of managing state (which MTS doesn't offer). I posit that this is *flexibility* being confused as *complexity*. Thankfully, the designers of the EJB specification DID NOT make all decisions for me!

There are simple ways to manage the accidental complexities created by such flexibility, such as guidelines, choosing wise defaults, etc. Thus, a user of the technology is free to *choose* what is best and move from there.

Mr. Chappell glosses over what are, in my opinion, the most important distinctions between EJB and MTS: While bias towards MTS is excusable in a column dedicated to COM, gross errors are not. Moreover, SIGS performs a disservice to its readership by not presenting accurate information, whether in an unbiased article or a column. In doing this, Component Strategies is not living up to the standard of excellence established by other SIGS publications such as C++ Report. I look forward to the Editorial Board improving the caliber of this fledgling publication.

Chris Cleeland
Last modified: Thu Jan 7 12:51:13 CST 1999