An Introduction to Enterprise Java Beans
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)
(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
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 of a different sort|
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
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.
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.
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).
Somewhat belatedly, about ten years after it was actually written, a guide on coversion for CICS to EJB has now been published.