A walking tour of J2EE

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

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

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.

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