J2EE Earns JAVA a Station in the Enterprise
- By Peter Fischer
- January 1, 2001
While java has gained significant acceptance as the object-oriented language
of choice for e-commerce and Internet-based applications, its acceptance as
a platform for enterprise computing has been lagging. Concerns about other capabilities
of the Java platform as a prime-time player in the enterprise computing game
have historically had many IS managers and CTOs cautious about betting the ranch
on Java as the platform on which to build and deploy the new generation of n-tier
Building complex, distributed application systems is more than just having
a solid set of functional APIs readily available. Despite its solid set of APIs,
Java before J2EE was not "ready for prime time" when it came to enterprise computing.
Issues such as a consistent security model, transaction support, administration,
configuration and deployment raised doubts in the minds of potential adopters
about the applicability and usability of Java to solve real-world problems.
However, J2EE has quickly dispelled most of those concerns and has many of
those skeptics seriously considering and evaluating J2EE as "the platform."
Integrated services, combined with dynamic configuration and deployment capabilities,
have clearly entrenched Java in the high-stakes enterprise computing game. In
this article, I will take you on a grand tour of the total J2EE offering with
stops at various key points that will illustrate the power and applicability
J2EE enables solutions for developing, deploying and managing n-tier server-centric
enterprise apps. It provides numerous capabilities, such as:
- A consistent and integrated API set;
- A consistent component model that extends to all processing tiers;
- Reusable components that can be customized to the runtime environment;
- A consistent and integrated set of enterprise services, including the ability
to configure them in the runtime environment dynamically without requiring
changes to processing logic;
- An architectural framework that allows for the creation of complex applications;
- Best practices and guidance in applying the framework to real-world problems.
Despite the obvious advantages, J2EE is more than just a "packaging" of Java-enabling
APIs. J2EE provides a framework for "allocating" component functionality and
code to the appropriate platform using the appropriate technology. It provides
developers and architects alike with a roadmap for how to appropriately apply
the range of Java technologies to real-world programming and architecture challenges.
J2EE consists of the J2EE platform, the J2EE Programming Model, J2EE Compatibility
Test Suite (CTS) and the J2EE Reference Implementation (RI). Before I go into
detail on the first two items, which are the core of J2EE from an application
development and architecture perspective, I will touch on CTS and RI. These
two elements provide the foundation for J2EE in terms of acceptance by the industry
The J2EE Compatibility Test Suite (CTS) is a suite of compatibility tests that
is used by vendors to validate and certify that their products are completely
J2EE-compliant. Vendors run this test suite on their platform implementations
to ensure that all APIs are supported correctly and that all constituent technologies
work together properly for a completely functional J2EE environment. Products
that carry the J2EE "stamp of approval" are therefore guaranteed to support
the complete set of J2EE technologies and functionality.
The J2EE Reference Implementation (RI) provides a minimal J2EE runtime environment
for J2EE applications and is used by both product vendors and developers. For
vendors, it defines the minimal operational environment or "gold standard,"
allowing vendors to determine what their platform implementations must do under
a particular set of application conditions. For developers, it is used to verify
the portability of their J2EE code base and to provide the standard platform
for running the CTS.
The J2EE platform
The J2EE platform is a consolidated set of Java technologies and APIs that
provide a standard platform for hosting J2EE applications. To connect the components
running across all the tiers of the J2EE model, the platform contains a standard
set of enabling and connectivity APIs. Table 1 lists the constituent APIs for
Historically, Java APIs have been delivered in dribs and drabs with no real
coordination between them. This was fine when the APIs were evolving in isolation.
With J2EE, however, the constituent APIs have "grown up" to become integrated
and dependent on each other for key functionality. For instance, early on there
was no requirement for Java Database Connectivity (JDBC) to support the Java
Naming and Directory Interface (JNDI) or transactions. The 2.0 release of JDBC
provides support for transactions and utilizes JNDI to store target datasource
The key to creating a solid and foundational platform for enterprise computing,
as well as e-commerce-based computing, is a solid set of core services. More
importantly, these services have to be integrated across the platform. With
J2EE, services like security, transaction support, and naming and directory
are not "add-ons" — they are integrated across all tiers of the architecture.
Even though support for the Java Message Service (JMS) is not currently mandatory
for J2EE, I anticipate that most, if not all, J2EE application server vendors
will provide a JMS engine, if only to provide product discrimination and a key
purchase point. JMS supports connectivity and information exchange between Java
components in both point-to-point and many-to-many fashion, providing key messaging
service capabilities for complex and interactive Java apps. In that vein, JMS
is a key and vital element of e-commerce-based solutions, enabling information
exchange between partners on the supply chain.
J2EE security services are designed to ensure that only authorized users access
resources and components. The J2EE security model supports both authentication
and authorization facilities. For authorization, access control is provided
and controlled using an application's security domain, which is configured and
administered independently of application code.
Unlike other enterprise application models, which require platform-specific
security features in each app, J2EE's security environment provides declarative
access to security configuration and attributes. This allows security settings
to be configured outside of program code at deployment time and not at development
time. These rules are interpreted when the application components are deployed
in the runtime environment. In addition, J2EE requires that all app server and
platform vendors provide standard login mechanisms, eliminating the need for
developers to supply this logic.
The J2EE transaction model is a flat model, which means that a transaction
cannot have any child or nested transactions. J2EE takes the complexity out
of the transaction management process by implicitly handling many transaction
details, such as propagating transaction context and coordinating transactions
across multiple transaction managers. This is done by leveraging the methods
on the interfaces of the JTA.
However, it is important to note that the transactional capabilities of J2EE
are clearly tipped toward the business logic or Enterprise JavaBean (EJB) tier
— Web components (Java Server Pages [JSPs] and servlets) are not designed to
be transactional in nature. Transactional behavior should always be delegated
to an EJB, which can use one of two styles of transactional behavior: bean-managed
transaction demarcation or container-managed transaction demarcation. In the
former case, the EJB programmer takes responsibility for managing all aspects
of the transaction in program code such as transaction start, rollback and commit.
With bean-managed demarcation, the EJB container handles all transaction details
and operations, driven by instructions in the EJB's deployment descriptor. Session
beans can support both types, but they cannot be used at the same time.
J2EE naming services provide application clients, EJBs and Web components with
access to a JNDI naming and directory environment. J2EE components locate other
components by looking them up in a naming context, a hierarchically organized
collection of logical names that map to the physical location of the component.
This provides a structured and disciplined approach to managing and locating
objects in complex distributed environments, overcoming the chaotic and free-for-all
approach that typically occurs.
A J2EE component can access both system-provided and user-defined objects.
The names of system objects, such as JTA transaction objects, are stored in
a special naming context. In addition, J2EE allows a component to name user-defined
objects such as EJBs, environment entries, JDBC datasource objects and JMS message
connections. For JDBC datasource objects, this allows application code to locate
and open a database source based upon an easy-to-read logical name instead of
the often clumsy and usually long database URLs that were prevalent with JDBC
1: J2EE API thumbnail
2 Standard Edition
Naming and Directory Interface
| JDBC 2.0
of the constituent application programming interfaces (APIs) for J2EE.
The J2EE Programming Model
The J2EE Programming Model provides a standard and extensible model for architecting,
building and deploying multi-tier, distributed, thin-client apps. J2EE is positioned
to be the platform for distributed computing supporting the architecting, development
and deployment of e-commerce systems as well as Internet-, intranet- and extranet-based
J2EE applications consist of three fundamental elements — components, containers
and connectors. Figure 1 illustrates the relationship between components and
containers. Containers provide all J2EE application components with the J2SE
platform APIs, which include both the Java Interface Definition Language (IDL)
and JDBC core enterprise APIs. In addition, support is provided for the APIs
listed in Table 1. Containers provide the execution environment for components
that run on all three processing tiers of J2EE — client, Web and server. These
containers are really a formalization of what we have seen in the various Enterprise
Java initiatives — browsers on the client side, servlet and JSP engines in the
Web middle tier, and EJB containers in the business logic middle tier.
Connectors sit under the J2EE platform and define a portable service-level
API to connect heterogeneous information systems and sources into a J2EE app.
These connectors provide the EAI functionality for the J2EE platform by allowing
processing assets stored in diverse EIS-tier systems — host-based systems, pre-packaged
apps and ERP systems such as Baan, PeopleSoft and SAP — to be accessed in a
consistent manner from middle-tier components.
The J2EE Programming Model partitions application components and models into
three logical tiers: client, middle and EIS, as shown in Figure 2. At the top
of the model is the client tier, which is composed of a combination of HTML
page-based clients and HTTP content-based clients. These clients interact with
components in the middle tier. These middle-tier components are either servlets
and/or JSPs in the Web tier, or EJBs in the business-logic tier. Middle-tier
components provide the underlying server-side processing capabilities of J2EE
apps. In the business-logic tier, business code packaged as EJBs executes in
an application server-based environment. At the bottom of the J2EE "stack" lies
the ultimate pot of gold, the EIS tier, which contains the key processing systems
J2EE apps can be Web- or non-Web-based, allowing the user interface to be presented
as HTML pages, Java applets, Java-Beans or a combination of the three. For example,
HTML-based apps can be generated via dynamically generated HTML pages and forms.
More sophisticated application services will interact with first-tier clients
by exchanging business data directly. In this scenario, JSPs and servlets are
used to format and present this data in a way that is easy for J2EE clients
to consume and use. These clients can be both Java applets running in a Web
browser and Java technology-based programs (such as wireless or hand-held devices,
With HTTP content-based clients, advanced functionality is attained through
the use of client-side logic execution. In this case, raw information such as
eXtensible Markup Language (XML) is exchanged between the middle and client
tiers, while execution on the client is typically in the form of Java apps,
applets or JavaBeans. To support the plethora of browsers and their various
versions dynamically, J2EE provides the ability to load the runtime environment
dynamically using the Java plug-in.
Servlets and JSP components comprise the Web tier of a J2EE application. Servlets
are a portable way to deliver dynamic content, while JSPs provide a text-based,
presentation-centric approach to developing servlets. In the runtime environment,
JSPs are compiled into servlets that are then run in a Web container. Combining
JSPs with JavaBeans offers all the advantages of servlets with the added benefit
of separating content and display logic cleanly.
One key advantage to this approach is that content developers do not have to
be concerned with app logic, eliminating the need for presentation developers
to understand Java app code and the need for EJB developers to understand HTML
or presentation logic. This fits in with the roles associated with J2EE, which
I will discuss later. In addition, with this approach, Web templates can be
created easily, allowing a Web-based J2EE app with a consistent look and feel
to be created with minimal effort.
From my experience, I have noticed that a typical dilemma is determining how
to leverage JSPs and servlets, as well as deciding among the various approaches
and technologies to developing and packaging Web components. The advice and
guidance that I typically offer is that servlets provide a programmatic approach
to capturing functionality on the Web server. Servlets are used to capture code
that changes infrequently or that provides access to low-level functionality.
JSPs are used as a presentation-centric, declarative approach to binding dynamic
content with processing logic.
As we have seen, J2EE is more than just a collection of APIs that provide the
ability to create distributed Java systems. J2EE is positioned to be the foundation
of a complete application and architectural framework, providing the services
required to build e-commerce-based applications. A key component of this "architectural
blueprint" is the inclusion of a guide for architecting and building these applications.
This integrated set of documentation provides guidance and best practices for
architecting, designing and building n-tier distributed application systems.
The J2EE Blueprints component provides the "cookbook" for building well-architected
applications that leverage the J2EE product and technology set.
Assembling and deploying J2EE applications
As an integral element of J2EE's discipline, a set of six roles has been defined
to cover the range of activities that are performed in creating and deploying
a J2EE application system. These roles are product provider, application component
provider, application assembler, deployer, system administrator and tool provider.
The roles reflect the distinct and clear separation of product purchase from
development, deployment and administration. Most of these are derived from typical
industry usage and should be familiar to application development organizations.
The identification of such roles is not novel, but their formalization into
a platform such as J2EE is. An application component provider creates J2EE components
— such as Web components or EJBs — and packages them in archive files, while
an application assembler takes these packaged components and assembles them
into a complete J2EE app.
The deployer role entails deploying the complete J2EE application into the
runtime environment. This role is key because of the declarative nature of a
significant portion of J2EE functionality. For example, a deployer would be
responsible for setting all the attributes of an EJB deployment descriptor targeted
for a specific environment, including transaction and security attributes. The
system administrator is responsible for the day-to-day health of the J2EE system.
This person will typically utilize the administrative capabilities of the application
server environment to tune and optimize the J2EE runtime environment.
J2EE extends the deployment model we are familiar with from Java and EJBs,
with a few new acronyms thrown in. A J2EE application is packaged as an Enterprise
Archive (EAR) file, which is a standard Java JAR file. These EARs comprise one
or more J2EE modules and a J2EE deployment descriptor, as illustrated in Figure
The creation of an EAR is a two-step process. In the first step, application
component providers create the constituent tier deployment modules — EJB, Web
and client modules. One key point to keep in mind is that each of the constituent
deployment modules is an independent deployable unit. The client components
are packaged as .jar files, while the EJBs are packaged in EJB-JAR files. A
new archive construct, the Web Archive (WAR file), contains all the elements
of the Web tier, including JSPs, servlets, HTML files and supporting Web files
(images, sound files and so on).
In the second step, the application assembler packages these modules into an
EAR file that contains the complete, deployable J2EE application. During this
step the application assembler edits deployment descriptors for each of the
constituent J2EE modules to link dependencies between components that are contained
within each archive as well as components in different archives. For example,
the JSP and servlets in the WAR file need to refer to the correct EJBs in the
Once the assembly step is complete, the EAR should be run through a J2EE verifier
tool (one is included in the J2EE SDK) to ensure that the contents are well
formed. While this verification is not a solid guarantee that the application
will behave correctly at runtime, the verifiers provide a significant number
of static checks to ensure that the deployment descriptor and the archive file
contents are consistent with the EJB, servlet, JSP and J2EE specifications.
Unlike earlier deployment descriptors, the J2EE deployment descriptor is XML-based
and consists of a series of name-value pairs that are organized in a hierarchical
manner. Deployment descriptors contain a variety of information, such as structural
information that describes the components that comprise the archive and assembly
information. Most important, a deployment descriptor contains attributes and
values that control the runtime behavior of the components stored in the archive.
For example, an EJB-JAR file contains entries and attributes that control the
security and transactional behavior of contained EJB components.
To be continued ...
As we have seen, the J2EE platform is a significant step in the evolution of
Java as a platform for enterprise computing. However, this is not the end of
the story. During the next year, improvements will be made in the platform to
tighten up some loose ends and to solidify J2EE as the platform for enterprise
computing. This includes the addition of JMS as a first-class API in the platform
and its integration with EJB as a core service.
Of more importance is the evolution of the EJB container with new enterprise-class
features that will enable it to become the standard execution environment for
components. The addition of key and core services to the container framework,
including inheritance, persistence and the ability to support dynamic relationships,
provides the foundation of an extensible and reliable execution environment
for J2EE applications.