A walking tour of J2EE

What makes the J2EE platform?

Welcome 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.

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.

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 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.


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.


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.)


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.

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.

1 2 Page 1
Page 1 of 2