Conclusion

24 February 2002

<< Knock-On Effects

EJB makes Java look bad. Its gives the enemies of Java a stick to beat us with. Can it be fixed though?

Much of this article reads like an EJB "wish list". If only certain key issues could be resolved, J2EE would become unstoppable.

We don't seriously believe that Sun would hold up their hands and say "it's a fair cop, let's scrap EJB - let's hit the reset button and start again, having learned from our mistakes."

It is far more likely that they will produce "point releases" that gradually fix EJB, one minute problem at a time. Local objects are a good example. The problem is that rather than being fixed from the ground up, the EJB spec will grow, and become ever more complex as the server vendors must support the legacy specs as well as the jazzy new "fixed" specs.

As it is, here are a few more recommendations to "fix" EJB:

	That bridges be built between EJB and the Beans spec. To come up with client side stubs like JBeans Session that fit into the beans spec.
	That development is simplified so that 1-tier, 2-tier and 3-tier are seamlessly catered for.
	That deployment is simplified so that we programmers can have back our concept of a separate design time and run time (i.e. not having to jump through hoops to package everything up, just to test-run/debug the slightest change). The simple addition of a deployment interface that IDEs can use would help immensely.
	That the container side specs are revised so that persistence is decoupled from the business aspects, as this doesn't add any value for the developer.

EJB is not as type safe as it could have been, so servers need to 'simulate' type safety by going through a verification phase. Verification is not done at design or build time - the APIs could have been designed so that more type checking was made between the Remote Interfaces and the Server side beans.

Alternatively, some kind of XML meta-constraints could have been implemented to introspect the Java and match it to the XML.

More importantly, there is no specification for passing or failing the verification phase - but there is a test for passing J2EE. It would have been nice if they were one and the same thing, so applications would pass or fail verification consistently for different vendors.

Back when Java was released, James Gosling said that Java was C++ without the knives and the daggers (with reference to how bad references in C/C++ caused programs to fail).

Now J2EE introduces bad references to a new generation of developers, causing programs to fail. The knives and daggers are back. Or is it just the sign of an over-ripe language?

EJB is not the final word in distributed systems. After RPC and CORBA, it is the third major release of possibly six or more architectures.

Almost every EJB tool vendor offers a "value-added" framework, showing that it can't stand up on its own as an architecture. EJB was designed by server enthusiasts for server enthusiasts.

Marc Fleury, who is the founder and lead of the JBoss project, said recently (regarding the future of J2EE):

"We see J2EE becoming embedded in applications. The 'object poets' want to see distributed systems with objects talking everywhere, but it just doesn't work that way. We don't take the paternalistic view of big servers small clients, we take the view of small servers, with the J2EE stack embedded in everything. "

Looking at the problems with EJB, the next major distributed system will be based around the client side requirements, and not the server side implementation. The interfaces will be between business and presentation logic, for example a more advanced version of the Beans APIs to include the concepts of Home and Session. The interfaces will be between organisations, for example a more advanced version of SOAP that will include interfaces.

It is worth reinforcing the fact that J2EE is not EJB. A point made recently by Rick Ross of JavaLobby.org:

"J2EE is not spelled 'EJB', any more than rectangle is spelled 'square'. ... 90% or more of current J2EE solutions don't use EJB."

The next distributed architecture must also conceal the persistence mechanism. The current Java product offering includes many persistence mechanisms (EJB, JDBC, JNDI, MIDP, Java Spaces, Java Blend, JDO, Serialization, XML etc.)

The next generation of distributed systems will give application programmers a choice of architectures. Give them the freedom to choose between the costs and benefits of each architecture on offer. EJB's choice is Hobson's Choice: either put up with our design, or handcraft it yourself.

EJB is just a fashion. It mostly doesn't suit requirements, and we're given Hobson's Choice. To quote from Moby Dick:

"Oh! Ahab," cried Starbuck, "not too late is it, even now, the third day, to desist. See! Moby Dick seeks thee not. It is thou, thou, that madly seekest him!"

Do you agree/disagree with any of the issues raised here? People are already voicing their opinion in our message forum. Join in here...

<< Back to EJB Central

<< Back to Software Reality