A walking tour of J2EE

Advertisement: Support JavaWorld, click here!

FEATURED NEWS & JW ABOUT

July 2001 HOME COLUMNS FORUM
TUTORIALS REVIEWS RESOURCES JW

Enterprise Java

A walking tour of J2EE

What makes the J2EE platform?

Summary
Java's success in the enterprise can be attributed to the collaboration of Java
Community Process members. Based on the J2EE specification, vendors are now
bringing scalable, available, high-performance products to market, competing
(at least in theory) on J2EE platform implementations. New technologies, such
as EJB 2.0 and the Java Messaging System (JMS), are being developed in
innovative, collaborative ways. This inaugural Enterprise Java column describes
the J2EE platform's place in enterprise Java, and outlines the platform's basic
motivations and strategies. (4,000 words)

By Mark Johnson

elcome to JavaWorld's newest technology column, Enterprise Java. I'm Mark

Johnson, former JavaBeans columnist and regular contributor to JavaWorld. In this
column, I intend to bring you instruction, guidelines, discussion, speculation, and maybe
some controversy about Java technology in the enterprise world. But first, I need your help.

My previous column, JavaBeans, focused primarily on technology tutorials with sample

code; it was very well received. Yet Java in the enterprise is a broader topic, with a wide
range of skill levels, and several categories of interest.

Since you're already reading, you clearly have an interest in this expansive topic. What I
need to know is: Why are you reading? I'm asking -- no, begging -- for you to let me know
what sort of material would be most useful and interesting to you.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (1 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

This initial column flies high over the enterprise Java landscape, explaining how Java 2
Platform, Enterprise Edition (J2EE) meets the fundamental requirements of a multivendor
platform. You'll read about the platform's design goals, its markets, branding, and
competition. Finally, you'll get a rundown on the types of developers the J2EE platform
defines.

Future installments of this column will be more technical, with hands-on coding examples
and diagrams. This month, though, I'll focus on the "big picture."

What makes a platform?

J2EE is a platform for delivering enterprise applications. But what does it mean to say that
J2EE is a platform? J2EE isn't hardware, although it can run on any hardware with an
appropriate JVM. And J2EE isn't software exactly, since many vendors provide J2EE-
compatible systems, and even provide their own JVMs. So what sort of a platform is J2EE,
since it's neither a hardware platform, nor a specific software product?

In the world of software, a platform is a combination of hardware and software necessary to

run applications. In this article, the word platform also implies that third-party developers
can provide applications for that platform. (A platform upon which only the platform owner
can create applications might more accurately be called a proprietary framework.)
Applications have traditionally been developed, and therefore have been available, for some
platforms and not for others. The economics and politics of hardware and software platforms
have shaped the markets of the computer hardware and software industries.

The J2EE platform is a collection of related technology specifications that describe required
APIs and policies. The content of the specifications is controlled by the Java Community
Process (JCP). Interested vendors come to consensus on the specifications' contents, and
then compete on implementations of those specifications. Sun Microsystems retains
ownership of the J2EE trademark and brand, and licensees pay Sun for the use of the brand
name and for the tests that verify adherence to the specifications. But the JCP, not Sun,
controls the contents of the specifications.

The J2EE platform represents the consensus of involved enterprise software vendors on
what facilities an enterprise platform should provide, and how to access them. Vendors
compete on implementation of a common specification, providing customers with freedom
to choose the technology most suited to their needs and budgets, and to switch vendors as
those needs and budgets change.

This situation is analogous to railroad cars and tracks. In the US, companies that produce
train engines and cars sell products based on an identical track spacing (4' 8½", or 1.435
m), and differentiate on other features. If each railroad car vendor used a different track
spacing (as was the case at various times in railroad history), the railcar and engine market
would be fragmented, customers would be locked into their vendors' track width, and
vendors would have little reason (or opportunity) to compete. The common track width lets
vendors compete for market share and empowers customers. Everyone -- except inferior
vendors -- wins.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (2 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

And J2EE seems to be winning. The industry has adopted the J2EE platform so
enthusiastically that the term "application server" now, as often as not, implies "J2EE."
Competition for market share in the J2EE space is fierce. How did Sun manage to convince a
large number of its competitors to agree on a common platform, instead of locking
customers into proprietary platforms?

The answer seems to be in the design of the collaborative process for creating and
controlling the platform technologies. The next section explores some of the requirements
that any open platform must meet to succeed, and then explains how J2EE meets those
requirements in an open, yet competitive, environment.

Platform requirements
Any platform requires at least four crucial, interacting characteristics to succeed in the
marketplace: consistency, adoption, openness (to some degree), and a specification. Let's
look at what each of these requirements implies about the nature of a platform.

Consistency
Consistency across installations is a basic platform requirement. Applications depend on
platforms to provide a specific set of well-known services. At the very least, a platform
should let its applications execute in any environment where the platform is available. This
may be as simple as a PC application that runs on any PC with a particular processor and
installed operating system, to an enterprise application that runs across a broad range of
hardware and software configurations. Without consistency across installations, the idea of a
platform means little.

The Unix operating system is an example of why consistency is crucial for an open platform.
One of the great strengths of Unix is the reliability of the platform API. Programs written to
the "Unix platform," using standard Unix system calls, can run on any Unix system that has
a compiler for program's source language. The most popular languages by far for developing
programs on Unix have been C and C++, which are highly source-code portable across Unix
systems.

However, as Unix matured, the Unix system call API (among other things) fractured into
dozens of almost-but-not-quite-compatible versions. (See "Unix family tree" in Resources
below for a link to an astonishing map of Unix releases.) Quite a large number of toolsets
were created to bridge these incompatibilities. Programs like Imake, configure, and autoconf
customized the build process for a program before compilation. Yet each vendor trying to
"improve" Unix muddied the water for everyone else, and it became progressively more
difficult to write a nontrivial program that would run on every Unix installation. (Though
programmers still managed to create some extremely portable applications using the tools
mentioned above.) In 1986, the IEEE published the Posix standard (IEEE Std.
1003.1/1003.2 and related standards), a collaboratively produced consensus on what Unix
APIs should be. Today, most Unix systems provide a Posix-compliant API. Posix was created
as recognition of the need for consistency in Unix platforms. The same is true of any open
platform.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (3 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

Adoption
Adoption provides established platforms with enormous momentum and market clout. It
also serves as a barrier to entry for new prospective platforms. Software developers
maximize the return on their development investment by targeting their applications at the
most widely adopted platforms. Software vendors often can't justify deploying products on
platforms with minimal adoption.

As with adopting a child, platform adoption is a high-cost, long-term investment for the
adopter. Traditionally, customers seldom change platforms because of high switching costs.
Applications have tended to be intricately enmeshed with the platforms on which they run.
Platform vendors recognize this dependency, and have competed by trying to lock their
customers into their platform. Customers purchase a platform as a combination of hardware
and software, and then make additional hardware and software investments specific to that
platform. To gain adoption, a new platform must provide a net value after subtracting the
cost of switching to that new platform.

Some platform vendors hold their customer base captive by keeping switching costs high,
instead of maintaining customers by serving them well with high-value technology products.
In the business of platforms, adoption is everything.

Openness
A totally closed system is not, for the purposes of this article, a platform. Some degree of
openness is necessary for software vendors to develop products for a platform. Platforms
vary in openness and in how that openness is achieved. For example, a single-vendor
platform, such as Macromedia Flash, may require developers to purchase a system
development kit; the Linux platform, on the other hand, is available for free, including
source code. (The point here is not to compare Flash and Linux as deployment platforms,
but just as development environments.) Openness interacts with adoption and consistency
in complex ways. It's much easier to retain consistency across implementations if you own
all the implementations, but the result of that ownership -- a closed environment -- may
limit adoption. (Contrast the PC with the Macintosh as examples of this principle. The
introduction of Mac OS X with Java 2, though, is an interesting recent development.)

Specification
A platform specification is a document that defines the platform, usually in terms of required
APIs, policies, and interfaces. A platform specification may be controlled by a single vendor
(as with Microsoft Windows), by a group (as with the Java platform under the JCP), or even
by an individual (as with the inventors of various scripting languages that form a "platform"
of sorts).

Control of a platform's specification is perhaps the most important of these four

characteristics. A tight specification helps ensure that a platform operates consistently
across implementations, and correctly across test suites. To the extent that a platform's
specifications are openly available, software vendors can create products for the platform
(even if they can't modify it to suit their needs). For this reason, platform openness tends to
encourage adoption.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (4 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

These four basic characteristics make it easier to understand why the the Java platform and
J2EE are succeeding. The next section will explore this topic.

The creation of a new platform

The Java platform (of which J2EE is a part) continues to succeed in the marketplace because
it was designed with the previous characteristics in mind. The Java platform behaves
consistently across underlying operating systems and hardware. The fact that many licensed
and unlicensed (yet legal) implementations of the Java platform also exist attest to its
openness. Control of the Java platform specification is also openly available for review and is
actively maintained (and updated) by a voting expert group, not by Sun. (The Java name
remains a trademark of Sun Microsystems, however.)

Remember the discussion earlier about the high switching costs associated with a new
platform? The Java platform deals with the problem of incompatible hardware architectures
by defining the Java Virtual Machine (JVM), which implements the Java platform on any
hardware (with sufficient resources). The resulting operational consistency results in much
lower switching costs, since you can implement Java solutions with existing processor,
peripheral, and network hardware. The isolation that the Java platform provides between
applications and the machines on which they run also make it much easier to switch
hardware and operating systems as needed, and to use existing heterogeneous resources.
Essentially, the Java platform turns everything underneath it into a commodity.

For these reasons, the Java platform has gained wide adoption in an incredibly short time,
overcoming the natural obstacles that new platforms face. (Just four years after Java's
introduction, 79 percent of Fortune 1000 companies were deploying Java technology-based
applications, according to a study by Forrester Research, see Resources.) J2EE has
experienced the same sort of explosive adoption, going from announcement to domination
in two years. How did J2EE become the de facto standard for application servers in such a
short time? Find out in the next section.

Creating a market
J2EE is one of the three "editions" of the Java platform. It also includes the Java 2 Platform,
Standard Edition, plus an assortment of interoperating technologies that support the
security, scalability, availability, and reliability needed for large-scale enterprise operations.
(The third edition is the Java 2 Platform, Micro Edition, used for small, resource-constrained
devices.)

J2EE is successful because the JCP and the specifications work together to create a market.
As I pointed out earlier, J2EE vendors cooperate on creating a common specification, and
then compete on implementations of that specification. Applications written to the platform
will run correctly on any implementation that conforms to the specification.

The portability required by the specification gives customers the freedom to choose
technologies both at system construction time and through the application lifecycle. Let's
say you're a small start-up with a good idea and not much money. You can create your
application using free, nonbranded implementations of J2EE platform technologies, and get

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (5 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

your business off the ground at a minimum cost. A year or so later, your revenues and
server traffic have both grown, and your servers are struggling to serve your customers.
Since your application components are portable, you can identify which pieces of the
platform are under-performing, and purchase higher-performance versions of those pieces.
Or, you might buy the entire platform from a vendor that offers the performance you need
at a reasonable price. Either way, the platform's portability ensures that your application
ports to the new platform with minimum hassle.

The point is that you, as a customer, retain ownership of your information assets. It's not
enough to keep your data on a disk, or to have access to your application's source code, if
someone else owns the technology necessary to run the application or access those data.

Let me tell you a story. A music professor friend of mine spent years writing an application
to teach counterpoint. Unfortunately, his application was written for the once-mighty and
now-obsolete Apollo platform. When the Apollo platform died, so did my friend's application
and his data. (Realizing the importance of owning his information assets, my friend went on
to become one of the SGML community's guiding lights.) Having the source code and the
data weren't enough for him; he didn't own his information assets.

Database customers today demand SQL access to their data, in part, because SQL helps
them minimize their commitment to a particular vendor. In the days before SQL, each
database had its own proprietary API, and databases didn't interoperate. In a sense,
database vendors "owned" their customers' mission-critical data, because of the extremely
high cost of switching vendors (and therefore, access methods). SQL changed that by
offering a uniform way to access data regardless of how those data are stored. Customers of
SQL-enabled databases "own" their data because the cost of switching from one vendor to
another is low.

J2EE does for application functionality what SQL did for data access. If your J2EE server
vendor goes under, performs inadequately, or overprices its products, or if you outgrow
your current vendor's product line, you can move your application to another vendor with
minimum switching cost. You will only need to rewrite the parts of your application written
using a vendor's nonportable extensions.

The J2EE platform addresses the four characteristics of a successful open platform by way of
the market. The specification spells out clearly what the customer can expect, and what the
platform implementer must deliver. The specification is developed in a multi-vendor
collaborative process, and is universally available for use, so the platform has some degree
of openness. (The contents of the platform are tightly controlled by the platform
technologies' expert groups, so the platform is not entirely open.) Competitive pressure,
branding (see below), and compatibility tests ensure consistency across vendor products.
And the result has been the widespread adoption of J2EE, providing more product options
for all J2EE customers.

None of this can work, though, if J2EE implementations aren't consistent. How can J2EE
customers know that a J2EE implementation will work as advertised, across vendor product
lines? Sun Microsystems offers three answers to this question: a Compatibility Test Suite

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (6 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

(CTS) and a Reference Implementation (RI) of each J2EE technology, and J2EE branding.

Compatibility test suite

Every J2EE technology must have an associated compatibility test suite (CTS), which
verifies that a product correctly implements the standard. Across technologies, the J2EE 1.2
CTS comprises more than 5,000 programs that test the specific details spelled out by the
specifications. For example, a servlet container must make any HTTP posted form variables
available in the HttpServletRequest object passed to the servlet. The test for this
condition would be to post variables to a servlet, and check that the servlet receives all the
variables, with the correct values. Sun Microsystems requires that every technology offering
that bears the J2EE brand name passes the corresponding test suite. The tests also verify
correct interoperation of the J2EE technologies as specified by the J2EE specification.

The reference implementation

A specification is not considered complete until the technology has a corresponding
reference implementation (RI), which must pass the CTS. For example, Jakarta Tomcat (see
Resources below for a link) is an Apache project that evolves with and slightly ahead of the
official RI for the JavaServer Pages (JSP) and Java servlet technologies. The corresponding
specifications are developed under the JCP.

The RI demonstrates that you can implement the specification, shakes out specification
problems, and verifies test suite correctness. The J2EE RI is not commercial-grade software,
and in fact, may not be deployed commercially or redistributed. Yet Tomcat is free for
commercial and noncommercial use under the Apache 1.1 license, so Tomcat is not itself the
RI. (For more on the relationship between Tomcat and J2EE, see Sun's J2EE FAQ in
Resources below.)

J2EE branding
The combination of specification, reference implementation, and compatibility tests provides
the consistency necessary for a portable, open application platform. Vendors who wish to
put the J2EE brand on their products license the J2EE name. Their products must pass the
CTS, which is available from Sun to licensees only. Licensing the J2EE brand is a nontrivial
income stream for Sun. As of this writing, 29 companies have licensed J2EE, meaning that
they have paid for and passed the CTS, and now may brand their products as J2EE.
Customers know that the J2EE brand ensures that the technology is highly tested and meets
the J2EE platform requirements. Portability and correct operation is more likely with
branded products, since the tests constrain the products to behave correctly.

You might argue that the platform isn't "open" since Sun benefits financially from licensing
the brand name. This is an understandable objection, and I'll just offer a few responses.

● Sun's control extends to branding, but Sun plays no unique or owning role in the JCP.
In other words, Sun controls what can be called J2EE, since it owns the J2EE brand,
but it doesn't entirely control what goes into J2EE technology. That's controlled by JCP
members.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (7 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

● Anyone can implement the J2EE specifications and sell or give away a J2EE-compliant
server -- they just can't call it J2EE. Several fully functional suites implementing J2EE
technology are freely available. These suites don't have access to the compatibility
tests, though, so they can't call themselves J2EE.

● It was perhaps no accident that the application server from iPlanet, a Sun/Netscape
joint venture, was the first J2EE-compatible licensee. Sun claims that, while it does
everything it can to support potential licensees, it did nothing special for iPlanet. But
even with a head start, iPlanet is not currently the market leader, as might be
expected if iPlanet had an unfair advantage.

Opinions vary about Sun's position with branding and test suite control. But there's no
denying that J2EE licensees and partners feel confident enough in the platform's openness
to create competitive J2EE platform implementations -- and betting their businesses on
them.

Platform roles in J2EE

So far, I've discussed the characteristics of an open enterprise platform, the ways that J2EE
embodies those characteristics, and how J2EE creates a market. Now, let's move into some
of the specification's content.

J2EE creates markets and partitions developer responsibility with its concepts of platform
roles. The J2EE specification layers responsibilities into roles that various types of
developers, integrators, and deployers might play. Each role produces a particular product,
such as a server, a component, or an installed application.

The roles defined by the J2EE 1.2 specification are as follows (this section is essentially a
quick paraphrase of the corresponding section of the J2EE 1.2 specification, section 2.4.):

● J2EE Product Provider: Implements and provides either J2EE component containers
or APIs defined by the J2EE specification. Product providers also supply tools that
work with their products. For example, a J2EE Product Provider might provide an EJB
container, plus the tools necessary to deploy the enterprise beans into the container.

● Application Component Provider: Creates application components such as HTML or

JSP pages, servlets, EJBs, or other components that run within a J2EE container. For
example, a developer who creates an EJB suite for enterprise scheduling would be an
Application Component Provider.

● Application Assembler: Combines existing J2EE components into an enterprise

application, packaging them into an "ear" (Enterprise ARchive) file for later
deployment. The Application Assembler identifies and documents dependencies
between the application and the environment in which it runs. These dependencies
are resolved during the deployment process to the target platform. For example,
someone who assembles components into an online shopping application would be an
application assembler.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (8 of 11)3/15/2006 4:50:01 PM

 A walking tour of J2EE

● Deployer: Installs and configures a J2EE application in a particular environment. This

role requires both knowledge of the particular J2EE application and the installation
environment. For example, a deployer might know how to install a particular J2EE-
compliant Web server and servlet container on any of several operating systems.

● System Administrator: Maintains the hardware and software infrastructure

underlying the J2EE system. System Administrators perform resource management
and runtime monitoring tasks, usually with tools provided by the Product Provider. For
example, a database administrator is one type of System Administrator.

The big picture

I hope that this first Enterprise Java column has given you a clearer understanding of the
"big picture" in J2EE. I discussed some of the necessary characteristics for an open
platform, and showed how J2EE meets those characteristics. I also paid special attention to
the issue of consistency, which is critical for adoption. The section on developer roles serves
as an introduction to the J2EE specification.

Next month's article will include a rundown of J2EE technologies and the roles they play in
enterprise applications. Please write and tell me what you'd like to see in future columns.

About the author

Mark Johnson is president of elucify technical communications, a Colorado-based company
dedicated to communicating novel or complex concepts by clear explanation and example.
Mark also works as a contract technical writer with the J2EE Blueprints group at Sun
Microsystems.

Resources
● The Jakarta Tomcat reference implementation for JavaServer Pages and Java servlet
technologies; it's free from Apache:
http://jakarta.apache.org/tomcat/
● Sun's J2EE FAQ:
http://java.sun.com/j2ee/faq.html
● "A Beginner's Guide to Enterprise JavaBeans," Mark Johnson (JavaWorld, October
1998) covers EJB 1.0, but is still useful conceptually:
http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html
● "CRN Interview: Bill Roth, Sun," Colin Browne (ITP.net, 2001) discusses licensing,
compatibility tests, and open source:
http://www.itp.net/features/97524614097034.htm
● "Develop N-tier Applications Using J2EE," Steven Gould (JavaWorld, December 2000)
is a primer on J2EE technologies:
http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-weblogic.html
● Details about the JSR that defines J2EE 1.3:
http://jcp.org/jsr/detail/058.jsp

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (9 of 11)3/15/2006 4:50:01 PM

A walking tour of J2EE

● Links and summaries of Java server products, both commercial and open source, plus
links:
http://www.javaskyline.com/serv.html
● "Java Technology Meets the Enterprise," Todd Sundsted (JavaOne Today/JavaWorld,
1999):
http://www.javaworld.com/javaworld/javaone99/j1-99-j2ee.html
● "Java Technology Comes of Age" quotes Forrester Research documenting Java's rise:
http://java.sun.com/features/1999/05/birthday.html
● "The State of the J2EE Application Server Market," Floyd Marinescu (TheServerSide.
com, March 2001) discusses developments in the J2EE server space in 2000:
http://www.theserverside.com/resources/articles/State-Of-The-Server-Side/article.
html
● "Sun Outlines J2EE Strategy" Tom Sullivan (JavaWorld, January 2001):
http://www.javaworld.com/javaworld/jw-01-2001/jw-0119-iw-sunee.html
● Home of the Java Community Process program:
http://jcp.org/
● "The State of Java Application Middleware, Part 1," Cliff Berg (JavaWorld, March
1999):
http://www.javaworld.com/jw-03-1999/jw-03-middleware.html
● "The State of Java Middleware, Part 2: Enterprise JavaBeans," Anil Hemrajani
(JavaWorld, April 1999) focuses on middleware and Enterprise JavaBeans:
http://www.javaworld.com/javaworld/jw-04-1999/jw-04-middleware.html
● Check out the Unix family tree:
http://perso.wanadoo.fr/levenez/unix/history.html
● Browse JavaWorld's index of Enterprise JavaBean articles:
http://www.javaworld.com/javaworld/topicalindex/jw-ti-ejb.html
● Check out JavaWorld's Server-Side Java index:
http://www.javaworld.com/javaworld/topicalindex/jw-ti-ssj.html
● Check out Mark Johnson's past JavaBeans column:
http://www.javaworld.com/columns/jw-javabeans-index.shtml
● Subscribe to the JavaWorld This Week weekly email newsletter to find out what's new
on JavaWorld:
http://www.idg.net/jw-subscribe

Advertisement: Support JavaWorld, click here!

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (10 of 11)3/15/2006 4:50:01 PM

A walking tour of J2EE

HOME | FEATURED TUTORIALS | COLUMNS | NEWS & REVIEWS | FORUM | JW RESOURCES | ABOUT
JW | FEEDBACK

Copyright © 2005 JavaWorld.com, an IDG company

http://www.javaworld.com/javaworld/jw-07-2001/jw-0727-enterprisejava_p.html (11 of 11)3/15/2006 4:50:01 PM