An Introduction to Enterprise Java Beans

As with the page on Object Transactions Services (OTS), What follows is a brief and link laden introduction to the Enterprise Java Beans and a how Java came to be the new COBOL.

What is Java

Java, and the name is apparently from a brain-storming session and is supposed to suggest Coffee and therefore the computer programmers' favourite psychoactive drug, Caffeine, was originally going to be called Oak (but this name seem to have run into Trade Mark difficulties). It was part of the product of a project within SUN to produce radical new products (that is not another Work Station). Java was originally envisaged as being the programming language of a range of small devices which would accomplish home automation tasks. To this end Java was designed as being a small, object oriented language which would effectively be mobile by being interpretive (at a byte-code level). Each device would contain a Java Virtual Machine (JVM). This mobile agent approach is one used by other folks at General Magic and so forth. It was not to be however, the devices that would have been produced were seen to be prohibitively expensive and it was thought that they would be unmarketable. Recently, with the advent of JINI the mobile agent approach has been resurrected. Such mobile agent Java programs have been termed Aglets.

Java on the Web Browser

Java was next seen as a programming language that would allow programs to be delivered to Web Browsers, should they have JVM embedded in them. Java has been successfully deployed in this context for some time, although it has to be added it hasn't swept the world as the some had hoped. At one point it was thought that the Web Browser, equipped with its JVM would take over the so called desk-top and programs (such as word processors and spread sheets) would be delivered in compiled Java. The hegemony that Microsoft currently enjoys would thus be broken.

That Java enabled Web Browsers have not (or not yet) broken the Microsoft strangle hold is well known. The problems with Java in this context appear to be that of performance and restrictions imposed by the very necessary security features of the Web Server JVM. The Java programs themselves are known as Applets, the diminutive of Application as a Noun, in this context.

Java at the Back End

It has been known for some time that there are limitations to the HTML protocol and in particular the way that HTML pages (such as the one you are looking at now) are marked up. Several people have developed mechanisms whereby content can be added to pages on the fly as they are served. This usually involves a scripting language communicating with a database and the most widespread deployment of such technology can be seen with Active Server Pages from Microsoft.

In the Java version of things the JVM is embedded within the server. Java can be used to communicate with database, do the necessary business logic and provide the content. The result is known as Java Server Pages (JSP) and has Java code embedded within a HTML page within special tags. Another approach is to have separate Java programs which produce HTML themselves. These are called Serverlets, as a follow on derivation of "Applet".

At the same time the limitations of Common Gateway Interface (CGI) scripts (such as Search on this site) were being appreciated. In this system, on screen forms provided by the Browser in response to tags such as <form> are filled in by the user. The data is then transmitted in bulk to the server where a CGI program is run. This is traditionally written in a scripting language (usually, but not always Perl) and run as a separate operating system process, specially spawned for the purpose. That program does whatever it has to do and builds a valid HTML page with the results embedded in it.

This is fine to a certain extent but it is very, very, inefficient. Spawning discrete operating system process is expensive, as is making and braking database connections on a per use basis. It is much better to have the program that does this kind of work part of the HTML server and permanently connected to any database.

This goal can be easily achieved by using Java in a JVM with Java's Database connection Application Programming Interface (API).

Beans

The final part of this introduction to Java from an OLTP stand point is the concept of Componentization. Java components are termed Beans. To be a Bean, a Java program should use standard names for its API. Within a Class these API should be have names which are orthogonal with other and conform to certain rules, for example a Class Account could have public methods getBalance and setBalance to manipulate some internal value Balance. This naming convention is set down in the definition of a Bean and is often referred to as Patterns by the object oriented fraternity. To be a Bean the Java Program should allow Introspection. Introspection is the ability of a Java Program to look inside itself and return information to a program that might be manipulating it. A Bean should also be customisable to an extent and packaged in a particular way. In all a Bean should be a re-usable Java Program which can be manipulated by a Tool, the Java Program is said to be Toolable.

This Bean concept was originally thought of as a front-end thing. A complexed form for doing a particular job could be embedded in yet another form easily using a Graphical User Interface (GUI) Builder tool when the Java program that provided the first form was a Java Bean.

Enterprise Beans

The final part of this is defining a Java Bean that can interoperate with an Object Transaction Manager, thus deriving the benefits of both Transactions and scaling. The EJB Specification is now widely supported and this set of APIs, definitions and tool interfaces is now considered by many to be the new, open, forward looking way of programming business logic. It is in the process of being refined and extended with the Java 2 Platform, Enterprise Edition (J2EE) Specification.

In this model an Enterprise Java Bean (EJB) instance is created (ie the Java program is run, in slightly older terminology) by something called the Container. The Container is responsible for Client access to the EJB. The interaction between the Client and the EJB is known as a Contract, as is the relationship between the EJB and the Container. The EJB has to provide Interfaces and Methods to allow all these interactions to happen. As with regular Beans the EJB must be packaged in a special way together with an fragment of Extensible Markup Language (XML) which contains information about the deployment of the Bean. EJB's split into a number of categories and sub-categories.

• Session Beans
  • Stateful Session Beans
  • Stateless Session Beans
• Entity Beans
  • Database Interaction Bean
  • Persistence Data Model Bean

Enterprise Java Beans interact with each other and with their Clients through Remote Method Invocation (RMI), which is mapped to CORBA's the Internet Inter-ORB Protocol (IIOP). IIOP propagates the necessary Transactional and Security interface and provides a Naming service which the Bean accesses using the Java Naming and Directory Interface (JNDI). By using IIOP the Client is not restricted to being another Java program, but can be any valid CORBA client.

Session Enterprise Java Bean

There is a taxonomy to Enterprise Java Beans and the largest division is between Session and Entity Beans. Session Beans do not have a direct analogy in traditional TP systems, but can be considered a halfway house between the fully Transactional Entity Bean (see below) and the Client. They come in two flavours, those that are essentially stateless and do not hold information over Client invocations and those who are stateful and do. Their use is generally defined in terms of "Shopping Carts" holding information about a Client's pseudo-conversational session. As such they can be a bit more lightweight than an Entity Bean, and are not designed to be recoverable over a system crash.

Entity Enterprise Java Beans

Entity Beans in many ways resemble traditional Services in Tuxedo or Encina and Transaction Programs if your background is CICS. They are the main repositories of the business logic; where the interaction with the database is and are designated as being recoverable in a Transactional sense, in that they are robust over crashes of system. They have two mechanisms of managing data, the persistence model or the direct connection model.

In the persistence model Java programs have the database mapped to Objects which they manipulate. The data is thus held in the database but appears like a local variable to the parts of the program using them, the data is just there when the program is run.

The other mechanism is somewhat more traditional, it makes use of a specialised non-procedural database access language, which is either embedded in a standard programming language or invoked by a callable interface. That specialised language these days, of course, is SQL, and in the Java methodology it is embedded in a communication/call interface known as JDBC. There are moves being made to introduce the other mechanism, of embedded SQL statements fully in Java too (just ha they have been in other languages such as C and COBOL), SQLJ. Of the two JDBC is by far the most prevalent.

The Benefits of EJBs

The goals of EJB are pretty much the goals that Object oriented programming aspire to, that of creating components which are easily reused. The Enterprise part of the name shows that these Java Bean components will exploit Transactions and scalability afforded by Transaction Managers. The EJB is hoped to be the preferred programming model for the new generation of Enterprise computing driven by the Web, where rapid deployment in a fast moving market place is seen as the key to success. With EJB there will be an explosion in the development and deployment of Rapid Application Development (RAD) tools specifically aimed at the Enterprise market. It is expected that Independent Software Vendors will also wade in with EJB versions of their particular speciality. Finally because all this is Java there will an independence from the vendors of the Enterprise computing environment which will allow competition based on price and performance.

Programming EJBs

The Enterprise Java Bean specification tightly defines what an Enterprise Java Bean is. It also provides for the `tool-able' nature of the EJB. It is thus expected that there will be a variety of RAD tools available to manipulate EJBs. At this point it is worth mentioning UML. Unified Modelling Language (UML) [Rumbaugh, Jacobson & Booch] is the Open Management Group preferred design methodology. It is rapidly gaining ground over rival methodologies the ideas from which it incorporates (such as Grady Booch's). It is expected that the development of a EJB, together with the front end; the design of the database that will serve the data and the Extensible Markup Language (XML) which will define deployment will be derived from a UML driven design and Rapid Application Development (RAD) tools.

In later releases of this page it is hoped to have a short review of some of the major contenders in this UML to EJB RAD arena (goodness! what a lot of TLA).

More Information

The best source of information, a good deal more comprehensive than here, are books specially written on the subject [Orfali & Harkey], [Vogel & Rangarao].

$Date: 2008/07/03 12:36:10 $