Ejb Inconsistencies

EJB is inconsistent: Like any design by commmitee spec, it offers too many choices -- too many choices for transactions for instance. The way these options are combined or interact together is not defined -- just left up to the vendor. So, as with CORBA, we get fully "standards compliant" implementations that are incompatible; your programs break when you move them.

for example...

The Enterprise JavaBeans specification defines three approaches to demarcating transaction boundaries:

Client-managed transactions -- where a client makes explicit calls to begin and end each transaction.
Container-managed transactions -- allowing a client to rely on the EJB container to begin and end transactions automatically.
Bean-managed transactions -- where an enterprise bean makes explicit calls to begin and end transactions.

Given that its creators are trying to ensure that Enterprise JavaBeans can be retrofitted onto existing legacy products, they have chosen to support the traditional client-managed approach to transaction demarcation.

EJB's container-managed transactions are nearly an exact clone of MTS’s automatic transaction. Enterprise bean TX_REQUIRES_NEW, TX_REQUIRED, TX_SUPPORTS or TX_NOT_SUPPORTED -- with same meaning as in MTS. And like MTS, Enterprise JavaBeans assumes that a bean wishes to commit the transaction unless it explicitly invokes the setRollbackOnly method. (However, EJB does not provide the MTS SetComplete? call.)

Sure EJB is flexible, but it's also complex. What happens if you mix different transaction styles within one business unit of work?

If developers can't easily understand the outcome of their transactions, how can they write correct applications?

MTS provides all three transaction options found in EJB, but clearly defines their interactions.

EJB was produced by a committee of competing vendors, and nearly every one of its faults stems from this fact. Defining full, complete standards leaves no room for competitive advantage, and so vendors tend not to do it. Not surprisingly, then, the biggest problem with EJB is its lack of true standardization.

EJB's support only a single programming language -- Java.

-- AnonymousDonor

These are some good arguments. Here are some rebuttal points:

Correct me if I'm wrong, but haven't application servers like GemStone or PersistencePowerTier supported automatic transactions for quite a while now? Many of the vendors involved in the EJB spec wanted to come up with a "common denominator" of features between servers. I don't think this concept was a rip-off of MTS. Perhaps the way deployment descriptors mark transaction attributes was a more blatant copy, but it's a rather minor detail.

I feel that the design-by-committee horse has been beaten to death by now. EJB is a valiant attempt at unifying such an important industry, and more credit to them for trying. Furthermore, most of the options EJB gives you seem to be more of just design oversights (i.e. instead of doing it right, pass the buck) instead of political wranglings.

[One might rightfully consider "beaten to DEATH" an overstatement, since obviously design-by-committee continues. Let the beating continue!]

Regarding conflict between client and automatic transactions: my understanding is that both rest upon the bedrock of the JavaTransactionService (JTS), which is effictively a Java implementation of the CORBA Object Transaction Service (OTS). Client-based transactions use the Java Transaction API (JTA), which is a simple high-level demarcation API that connects to JTS. Invoking an automatic transaction while simultaneously using a client-managed transaction should have the same effect. Whether this works in practice depends on the competence of the implementor.. and I trust that at least one will get it right. :)

As for getting CORBA & IIOP to work with multiple vendor's implementations: this is also a tired argument, and a disproved one at that. The OMG had a website up pointing to an application that had ORBS from 11 different vendors connected together, running 24/7 for many months. Regarding holes in the spec: distributed security services have been well specified in the security service spec, though not widely implemented. There is little/no need for a directory services spec as LDAP is already the de jure & de facto standard in that arena, and it is rather easy to integrate an LDAP database with the CORBA Naming service through JNDI... or just using LDAP directly. Load balancing is often a low-level chore that is vendor-dependent, so it's quite arguable that this topic doesn't even need to be specified. EJB uses JTS which defines compatibility with a number of legacy wire protocols, as well as IIOP for context transfer between transactional managers.

Could you elaborate by what you mean with EJB's "three different ways to demarcate transaction boundaries" vs. COM's one way? Are you referring to the allowance of client-managed vs. bean managed vs. container managed transactions? If COM allows client-managed transaction, how is this not a "different way" from automatic?

I have a number of qualms with both EJB and MTS, which I'll probably elaborate on soon in WhatsWrongWithEjb. I think that both specifications have a near-equal amount of tradeoffs and disadavantages: with EJB you're limited to one language, with COM+ you're limited to one platform. With EJB you're at the mercy of design-by-committee vendor squabbling, with COM+ you're limited to Microsoft's legendary software quality (ahem). The primary thing that I think Microsoft has going for it with COM+ is its IMDB - which is something only a handful of EJB vendors have (PersistencePowerTier & GemStone ... anyone else?). [note: IMDB was pulled from Windows2000 and ComPlus --DinoChiesa, 12 April 2000]

Anyway, the only real criticism I agree with here is that there is real fuzziness about when to use Session Beans vs. Entity Bean (the EJB-INTEREST mailing list is full of discussions of what to do). There is also a lot of fuzziness about how to integrate servlets properly (though I think this exists with MTS right now as well). Furthermore, there is a LOT of room for incompetent vendors to put out mediocre products, leading to a "burn the spec" mentality, unfortunately.

In all, I don't think that EJB or COM+ are great steps forward in enterprise systems design... I'd much rather use the proprietary GemStone/J API, or WebObjects EOF as they are both much more powerful & elegent. Both COM+ and EJB are, however, great steps forward in making object-oriented systems design politically acceptable. Tons of vendors scrambling over a half-baked specification and the big-momma of vendors coming out with their own makes people-with-money take notice. I like that.

--StuCharlton

I agree completely with the point about Java - which is exactly why we should all support the OMG and vendors in the production of a standard that provides language-neutral EJB interoperability: we want EB, not EJB! --JohnDaniels

Indeed, basing your enterprise component model on a particular language seems shortsighted. The problem with OMG's CorbaComponentModel is of course, OMG. Sure, we want Enterprise Components, but is OMG the right vehicle? Is it capable of delivering anything with enough velocity to maintain the interest of the market? History says no. It seems many vendors have pulled focus from CORBA and are now investing in Java/EJB, all the while delicately pitching the "EJB is the best of Java and CORBA" story. Hooey. -DinoChiesa, 12 April 2000

What about WebServices as loosely coupled components? Does this cut it for an enterprise component model . Certainly WebServices falls short of being a rich component model - but assuming you have EJB or CORBA or COM+ or Gemstone or.... - and that environment supports WebServices, then you can connect to other WebServices fairly easily.

[Ralph's comments moved to EjbVsComPlus]

CategoryEjb