A Critique of Enterprise Java Beans

The Web is currently full of papers extolling the virtues of Enterprise Java Beans (EJB), but few cast a sceptical eye over this architecture and wonder how it would all work in a big real world application. Well there's nobody with a more sceptical and jaundiced eye than Mr. OLTP. Here's some nuggets from his spleen. As is fashionable and in keeping with the rest of this site this is a multi-tiered effort. There are some Object oriented terms in here, like `Method', have a look at Object terminology for beginners if you don't understand them.

The Front End

As envisaged by the Open Management Group, there will be a smooth development process based in Unified Modelling Language (UML) [Rumbaugh, Jacobson & Booch] and moving through to the production and assembly of Java Beans some of which will be of the Enterprise variety and others will be Beans for the front end. The deployment of these components will be guided by files of instructions written in Extensible Markup Language (XML). All this will be accomplished by Graphical Interface based Rapid Application Development Tools. The front end therefore needs to be able to run Java in its latest incarnation and have an Orb to allow the Java's native Remote Method Invocation (RMI) to be mapped to the Internet Inter-ORB Protocol (IIOP), the preferred communication protocol in this architecture.

Hands up how many of you reading this are running such a browser. Well, currently only the absolute latest Netscape Navigator has these capabilities. Microsoft, who with Internet Explorer (IE) currently have over 50% of this market, have effectively queered the pitch on this. Department of Justice rulings notwithstanding, IE will never support the level of Java nor will it ever have the necessary Orb. In addition to these, the big two, there are other Browsers further down the market segment list such as Lynx, Mr OLTP's favoured text only Browser, and relative newcomers such as Opera. Again, it is unlikely that the appropriate levels of Java and Orb will be seen in these Browsers any time soon (if at all).

SUN's response to this is to supply all the necessary components (and in particular the latest Java 2 JVM) as a down-loadable plug-in. Bizzarly, because the the HTML for both Microsoft's Internet Explorer and Netscape will have to be the same (the Java 2 JVM will have to be invoked with something other than the <APPLET> tag); Netscape has to have a plug-in too. This plug-in and additional Java code can only be considered as huge (about 5 Mbytes) and rather an imposition to download if all you wanted was to order a Pizza on-line.

What's left therefore is that unless the front end is tightly controlled (such as in a dedicated Netscape deployment Inta-company) then using Java on the front end in this architecture could only be accomplished if a lowest common denominator fall back is available. This lowest common denominator consists of the familiar HTML Form, possibly augmented with a little scripting in the de-facto scripting language (confusingly called JavaScript, for it has nothing to do with Java). When you've provided for the fall back and dealt with all its scaling issues, one has to wonder, why bother with Java?

The Middle Bit

The Middle bit is based on the Common Object Request Broker Architecture (CORBA) and the the Internet Inter-ORB Protocol (IIOP) protocols which for new protocols come with their own set of baggage. These protocols have an object oriented element, so therefore it can be expected that they will have a higher overhead than more traditional RPC type protocols. Further, because IIOP is layered over TCP/IP it will suffer the same scaling problems as other TCP/IP based Transaction Processing (TP) solutions (and almost certainly require the same sort of fixes). TCP/IP was never designed to be a TP protocol and as such it scales poorly in very large applications. Each TCP/IP connection consumes a small but finite resource even if no messages are being transmitted. It also has a fairly large overhead in establishing and dismantling of connections. Traditional Transaction Processing Monitor (TPM) Tuxedo and Top End, which use TCP/IP, use the approach taken by IBM's Systems Network Architecture (SNA) earlier, that of funnelling the messages and their replies over increasingly concentrated permanently made connections in a hierarchical architecture. This will necessarily require intermediary computers, but will relieve the central machine of this TCP/IP overhead and leave it to do the actual Transaction Processing.

The Back End

The Back End, in this architecture as with traditional TP is all about the Data Base and making it perform at its most optimal. In the Enterprise Java Bean model the Entity Bean is responsible for the system's interaction with the database. The Entity Bean comes in two flavours one with a Persistence model and another with a more standard SQL interaction.

Although progress has been made on databases with an Object model, and there are still many Hiarchical databases around too, the most likely database model adopted for this work will be a Relational one with SQL as an access language to the database.

The Persistence model will therefore necessarily have to generate SQL dynamically under the covers to be successful. Such dynamic SQL is likely to be poor, even by dynamic SQL terms, and pure performance poison. It is expected therefore that, although this technique will have its day, most Entity Beans will be coded to use the database directly using SQL.

There are two competing ways that SQL may be embedded in Java. It can be interpolated into a hybrid language, as is traditional with COBOL and C (SQLJ) or it can use the ODBC like JDBC. In its most naïve form JDBC, like ODBC uses dynamic SQL. This will again involve a performance overhead that would normally be considered unacceptable. More capable Java/JDBC programmers will use the prepare Method but the best way of insuring static SQL performance (or better) is to use Database Procedures. In coding Database Procedures the same rules apply as to any database or TP project, keep your business logic out of the Database Procedure as these instructions are interpreted by the database, which are poorer at such things than a conventional programming language. This leads, necessarily, to complexity and code control issues. Consider static SQL in SQLJ as an alternative choice.

Having made your very necessary efforts to get the database performance up, you will of course have created something that is as portable as the Empire State Building. Vendor independence was one of the reasons for choosing an EJB system and that benefit has now been negated.

If business logic in a Database Procedure is a poor choice because the Database Procedure is interpreted is not programming it in Java a poor choice too? No it is not. It turns out that Java, although it is a byte code interpreted language is not such a bad language to code business logic in.

Java is compiled into an architecture neutral object format for a hypothetical Java machine. This object code is then interpreted by a Java Virtual Machine (JVM). This object can be compiled by the interpreter into the native architectures object code on the fly and the resultant code stored for further later execution. This approach, known as Just In Time (JIT) compilation (confusingly as it is in the Interpreter) means that if a Java program is used frequently it will be cached in a form that would allow it to be executed as fast as, or approaching a program written in a traditional high-level compiled language such as COBOL, C and C++. Just such environments exist within a TP architecture.

This has lead some to the conclusion, based on dubious extrapolations, that Java will be quicker than such traditional languages [Jones]. Other more scientific papers note that Java will be slower, but the performance impact between different programmers' efforts will be more marked [Prechelt]. Herein lies the rub, Java is an easy to learn language, but its learning curve is steeper than it might be for you don't simply have to learn the language but also all the Classes that interface with the outside world. You have to effectively learn a new operating system interface too. It is therefore possible that novices in Java would write a consummately worse performing program than, say novices in C++ (provided of course that the said C++ novices were coming from a familiar Operating System and TP environment).

There are features in Java which are considered good and wholesome by the Java community, which were in other languages too. These features latterly evolved out of these languages as a performance issue (such as bounds checking on arrays in Pascal). One can argue therefore that over time Java will evolve into a family of programming languages, and that porting between these different Javas will present its own set of challenges. What price a Java compiling into native code with pointers as a language extension? SUN have been successful in resisting these evolutionary pressures by being draconian in what can be called "Java" and being quick to the law, as Microsoft have found out. Java itself however, as defined by SUN, can be a moving target too. If this is not considered so, we have a demonstration Clock Applet that might or might not work on your browser and we invite feedback on this.

Architecture

All this architecture has of course been specified by SUN, a company who until now had not been noted for being in the fore front of distributed OLTP. SUN, until now, had rather regarded TP Monitors as being a bunch of `user' programs. They viewed Database Manager stuff in much the same light. So superficially one has to ask "who made them the experts?"

As with everything there is more to this once one delves a little deeper. SUN's ideas about OLTP seem to have a rather blue hue. IBM, who have both most to gain and most to lose with EJBs are enthusiastic adopters of these SUN promulgated standards. It could be argued that it is IBM who make and break standards in these areas as can be seen with the ACSE/Presentation Transaction Processing API (XAP), an earlier ISO effort at interlinking disparate TP monitors. IBM didn't support XAP and it effectively died shortly after. Suffice to say that there is much too-ing and fro-ing between IBM and SUN. IBM have had a run in with the Department of Justice and is probably happy that SUN are seen to be in charge of all this. That IBM have adopted Enterprise Java Beans (EJB) so strongly is a good portent for their future success. Presently CICS and shortly IMS will be EJB-ized, and since these two TPM represent the plumbing to 90% of the world's e-commerce, well enough said.

The two main things that are driving all this, of course, are the opportunities of new business afforded by the paradigm shift to e-commerce leveraged by the Web (now there's some management speak for you) and the Spector at the feast that is Microsoft. Microsoft wield enormous power with their total domination of the present desk top. Everybody fears what they can do with it, especially if they come to own the interface to the Internet with their Web Browser, Internet Explorer. They would be in a position to dictate the way that the middleware and commerce over the Internet would work and thence much of the rest of the system. It is fair to say that fear of Microsoft is keeping everybody on board with EJBs, and that it is quite possible that without Microsoft the whole EJB thing would fragment.

So what would a realistic EJB system look like. This is of course a matter of much speculation and argument between practitioners. It is more than likely that the somewhat idealised pure EJB systems seen in some publications will not be realised. For one thing nobody is going to completely rewrite the software that currently supports their business simply to have it in the Language du jour, Java. What is more likely is that the EBJ component will be a significant new addition which will interface to the Web, perhaps bring self-service Web based financial transactions, which have until now been provided by agents in branches using rather more traditional interfaces.

$Date: 2009/10/18 10:30:30 $