J2EE: An enterprise Java blueprint

by Tim Fielden

December 14, 2000 —

IN TODAY'S competitive marketplace, organizations are facing the difficult
challenge of providing a broad range of electronic-business services while keeping
costs down in the face of ever-compressed development cycles. To address this problem,
many companies are investigating the implementation of business logic on the midtier
using Java. Those who use Java components often find that development is simplified and
that rapid deployment is achievable. What's more, distributed Java applications can be
implemented in such a manner as to boost scalability and reliability.

In the past, companies choosing Java have struggled with security-and performance-
related issues. For many sites, these problems have detracted from Java's overall value
within the enterprise. Sun Microsystems has thoroughly invested itself in addressing
these challenges. The result, released this month, is Sun's Java 2 Enterprise Edition
(J2EE) software developer's kit (SDK).

J2EE is a standard architecture definition using the Java language, which companies
can now more readily leverage on the midtier to speed up distributed deployments. The
use of this architecture in enterprise development efforts allows developers to quit
worrying about the "plumbing" required to run mission-critical business applications
and instead focus on designing the business logic and presentation of applications.

There are several components that make up Sun's J2EE, including an application
programming model, a standard platform for implementation, a compatibility suite to
test compliance, and a reference implementation. Building on the features that Sun
included in its Java 2 Standard Edition, this latest release of J2EE boosts scalability
while adeptly tackling the performance and security issues that have plagued Java. Sun
has added full support for Enterprise JavaBeans (EJB), the Java servlets API, and Java
Server Pages (JSP). The net of this is an architecture that can significantly reduce
time to market for enterprise developers.

The J2EE Model

Anyone tasked with creating highly available and reliable buusiness applications
knows how complex the job can be. The bulk of the development time and expense often
comes from having to build the midtier plumbing required for accessing and managing
data and applications from a variety of enterprise resources.

J2EE's Application Programming Model, also called the J2EE BluePrints, alleviates
some of that complexity by providing an architectural model comprising an integrated
set of documentation and examples for implementing J2EE-based multitier applications.
It is meant to be used as a guideline for developers to design and optimize components,
to strategically divide development labor, and to allocate technology resources.
Following the model will ensure that one J2EE application will function just like
another.

The J2EE Application Programming Model instructs developers to partition their work
into two distinct categories: business logic and presentation logic. The rest is
handled automatically by the system resources. Without the requirement to code midtier
plumbing, developers have more time to spend on business and presentation logic, which
will be a welcome change for companies that are concerned about shortening the project
cycle.

The J2EE platform

The J2EE platform is the standard environment for running J2EE applications. It is
made up of the J2EE deployment specification (a set of standards that all J2EE platform
products must support), a set of Internet Engineering Task Force standards, and a set
of CORBA standards. The updated J2EE platform adds, among other things, the JavaBean
component model. Developers can use the JavaBean component model to customize Java-
class instances and to make Java classes accessible via defined events.

As mentioned earlier, J2EE supports EJB, thereby enabling developers to implement
multiuser and transactional functionality. When run on a J2EE server, Enterprise
JavaBeans breaks up application logic into reusable and extensible pieces of code.
Enterprise JavaBeans components are not new in this release, but J2EE extends their
power and portability by defining the standard clients and service APIs for their
use.

EJB runs within a container on the server, which provides all the typical midtier
services such as transaction management, security, remote-client connectivity, life-
cycle management, and database-connection pooling.

To make a transactional system operational with an EJB container in place, a
developer would need only declare the beans' transactional properties in the deployment
descriptor file. This eliminates the need to develop the code to manage the often error-
prone transactional boundaries.

Enterprise JavaBeans consist of two types: session beans and entity beans. Session
beans can be thought of as a client process running on the J2EE server. They allow
applications to converse and invoke methods belonging to another EJB. Being non-
persistent or transient, a session bean can have only one client associated with it and
it terminates when the corresponding client does.

An entity bean, on the other hand, is a representation of a business object in a
persistent storage mechanism, such as a database. Management of this type of bean can
be performed by the server via container-managed persistence or via bean-managed
persistence, in which the developer writes and controls data access within the bean
itself. A common misconception is that an EJB is the same as a JavaBean component.
While they are both written in Java, the JavaBean component defines a convention from
which tomake a Java class instance customizable and accessible via events, whereas the
EJB implements multi-user, transactional services.

The J2EE server

Sun's J2EE server provides naming and directory services via the Java Naming and
Directory Interface (JNDI), authentication, HTTTP, as well as the capability to work
with Enterprise JavaBeans. The JNDI, which is a standard extension to the Java
platform, provides Java-enabled applications with a unified interface to naming and
directory services in the enterprise, including Lightweight Directory Access
Protocol.

The J2EE server also takes advantage of Java servlet technology. A servlet (think
of it as an applet that runs on the server) provides the developer with a component-
based, platform-independent method for building Web-based applications without the
performance limitations of some other approaches, such as using CGI programs. Servlets
are a simple, consistent mechanism for extending the functionality of a Web server,
and, because they are written in Java, they have access to the entire library of Java
APIs, including the Java Database Connectivity API for accessing enterprise databases.

The JSP is an extension to the Java servlet. While servlets provide the ability to
develop and present interactive Web pages from the server, JSPs go one step further,
making it easier to create and support HTML and Extensible Markup Language pages that
combine static templates with dynamic content.

Peace of mind

While we've talked at some length about the technologies that compose the platform,
we haven't yet discussed the new features of the SDK. One essential feature is the
Compatibility Test Suite. Used primarily as a vehicle to verify the conformity of a
Java application to the J2EE platform specification, the tool comes packaged as three
testing components. The first, a test for basic API-level compatibility, uses method
signature testing to ensure that all the implemented APIs are neither a superset nor a
subset of the required API set.

The second test is really nothing more than a superset of tests to make sure that
all individual components work and behave properly. The third test checks for end-to-
end compatibility. The Compatibility Test Suite lets users rest assured that their J2EE
applications will interoperate properly with others.

J2EE also includes a reference implementation, which, aside from being the
operational definition of the J2EE platform used by vendors and companies, is a
guideline used by developers to verify the portability of an application.

Enterprise worthy

Wanting to check it out for myself, I created a test application using Enterprise
JavaBeans. I started up the J2EE enironment via the command line after setting all
necessary Java environment variables. Once the server services were started, I chose to
fire up the application deployment tool by executing the "deploytool" command as inst
ructed in the documetation, and was pleasantly surprised to see a graphical set of
tools presented.

I was provided with a relatively straighforward path from which to work. I chose to
create a new application and was prompted for the name of my application as well as the
location of my Enterprise Archive (.EAR) file, a J2EE application deployment file,
containing my Java archive (.JAR), and Web archieve (.WAR) files. I then went to work
creating my first Enmterprise JavaBEan. With a bit of help from the documentation, I
was able to create all the necessary elements of my EJB including the remote interface,
the home interface, and the bean itself. Beionga stateless session bean and
implementing only two methods, little hand coding was required.

With this task behind me, I began the compilation of my source using a handy batch
file that was provided during the installation. I then launched another Sun-provided
tool, the Enterprise Bean Wizard. The wizard prompted me for information on the
directory where my code resided; a definition for the class name, the home interface,
and the remote interface; and whether my bean would be an entity or session bean. With
these quesstions answered, my EJB creation was completed.

I was amazed at all the choices the EJB wizard provided. If I chose to have
transactions handled by the EJB versus the server, a click was all it took. Just 12
wizard steps were required to create my Java archive file.

I found it very useful to have the XML tags of the deployment descriptor displayed
so I could inspect them. Choosing the "Deploy Application" option from the Tools menu
found within the application deployment tool, I was prompted to verify my JNDI name
before the application was completed. With the server side finished, all that was left
was to create the client, which was also done in quick fashion. Testing my application
proved that development via a command line could be fun.

If you want to ensure that your applications are created in a consistent fashion --
that is, scalable, reliable, and compatible with other enterprise applications -- then
I would strongly advise you look at J2EE. Its deployment and development wizards,
increased execution speeds, and security improvements make it a worthy technology on
which to base your enterprise-application framework. With its ability to remove some of
the burden of the midtier plumbing, developers will actually have fun coding again.

InfoWorld