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.
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.
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.
Mr. Chappell glosses over what are, in my opinion, the most important distinctions between EJB and MTS:
- "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.
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.
- Single-source v. multiple-source. Implementations of MTS are only available from Microsoft. Period. There is no published standard for enterprising individuals or companies to create a compatible competitor. EJB, on the other hand, has a published specification and many vendors creating implementations of that standard (including at least one open-source initiative).
- (currently) only Java v. multiple languages. Clearly, since MTS is based on COM, and COM defines interoperability at the binary level, MTS can use whatever languages can generate COM objects. EJB is binary at the Java Virtual Machine level, but the only industrial-strength language implemented atop the JVM is currently Java. There's no *technical* reason that VB couldn't compile to JVM bytecodes, or C or C++, either.