Subjects Freshman Year Reading African American Studies African Studies American Studies Anthropology Art, Film, Music and Architecture Asian Studies Business and Economics Criminology Education Environmental Studies Foreign Language Instructional Materials Gender Studies History Irish Studies Jewish Studies Latin American & Caribbean Studies Law and Legal Studies Literature and Drama Literature in Spanish Media Issues, Journalism and Communication Middle East Studies Native American Studies Philosophy Political Science Psychology Reference Religion Russian and Eastern European Studies Science and Mathematics Sociology Study Aids


E-Newsletters: Click here to be notified of new titles in your field
Click here to request Desk/Exam copies
Freshman Year Reading
View Our Award Winners
Click here to view our Catalogs
CodeNotes for J2EE

CodeNotes for J2EE

Upgrade to the Flash 9 viewer for enhanced content, including the ability to browse & search through your favorite titles.
Click here to learn more!

Order Exam Copy
E-Mail this Page Print this Page
Add This - CodeNotes for J2EE

Written by Gregory BrillAuthor Alerts:  Random House will alert you to new works by Gregory Brill

  • Format: Trade Paperback, 240 pages
  • Publisher: Random House Trade Paperbacks
  • On Sale: January 2, 2002
  • Price: $19.95
  • ISBN: 978-0-8129-9190-1 (0-8129-9190-7)
Also available as an eBook.
EXCERPT

Chapter 1: Introduction
Orientation, History, Background

What Is the Java 2 Enterprise Edition (J2EE)?

Depending upon whom you ask, Java 2 Enterprise Edition (J2EE) is one of many things. A systems architect might tell you that J2EE is a platform and design philosophy for large enterprise systems. Your local server administrator might tell you that J2EE is a combination of vendor products, WAR, JAR, and EAR files. A developer might tell you that J2EE is marketing spin wrapping up a suite of toolkits. In fact, J2EE comprises three major components.

1. A conceptual definition for enterprise systems architecture. This definition provides a rigorous design philosophy for building large, scalable, web-enabled systems.

2. A collection of API extensions that relate to enterprise systems. These APIs range from e-mail access to database connectivity, bridging concepts as different as distributed computing and web-based applications.

3. A new deployment specification for packaging Java components into a single enterprise solution. Basic Java uses a simple “Java Archive” standard for packaging a set of common class objects into a single deployable file. J2EE extends this concept to Web Archive (WAR) and Enterprise Archive (EAR) formats for deploying larger enterprise systems. This deployment specification includes support for role-based security.

History

In 1999, Sun announced a fundamental redefinition of the Java platform. Java had originally been designed as an all-encompassing “Write Once, Run Anywhere™” system; but Java applications rapidly exploded across a tremendous range of platforms, from smart cards to air conditioners (e.g., www.myappliance.com) to distributed, mission-critical enterprise systems. Obviously, the requirements for an offline payment system on a smart card are vastly different from those of an enterprisewide, web-enabled stock trading platform.

Sun initially supported the different platforms by providing a core SDK and an assortment of extension APIs. This approach rapidly became unwieldy, and Sun redefined the Java platform into three distinct versions: Java 2 Micro Edition (for embedded applications such as smart cards), Java 2 Standard Edition (for normal Java applications), and Java 2 Enterprise Edition (for large-scale, distributed, web-enabled applications).

The J2EE APIs

When the initial J2EE specification was announced, many of the enterprise APIs already existed as independent packages. Thus it is often difficult to tell whether an API is part of Java 2 Enterprise Edition or Java 2 Standard Edition, or is a stand-alone package, or is included in more than one edition. As the various Java editions mature and the literature catches up with the changes in the Java platform, these distinctions should become clearer.

The most important J2EE 1.2.1 components are:

-JDBC 2.0—JDBC is the primary mechanism for using Java to communicate with SQL-compliant databases. J2EE requires the JDBC 2.0 Optional Package, an extension to the core JDBC API included with the Java 2 Standard Edition. Chapter 3 explains the core concepts of JDBC and working with relational databases.

-Java Servlets 2.2—Servlets are server-side web programs that are primarily gateways between web interfaces and middle-tier components. Servlet technology is an essential component to building secure, scalable web-enabled systems. Chapter 5 covers fundamental Servlet concepts and provides the framework for JavaServer Pages.

-JavaServer Pages (JSP) 1.1—JavaServer Pages (Chapter 6) extend the power of Servlets by providing a simple mechanism for decoupling web content generation from application and business logic.

-Java Naming and Directory Interface (JNDI) 1.2—JNDI provides a transparent Java interface to various naming and directory services, including LDAP, NDS, DNS, and NIS(YP). JNDI is briefly covered (along with RMI and JavaMail, below) in Chapter 4, and extensively covered on the CodeNotes website.

-Remote Method Invocation (RMI)—J2EE supports distributed computing by providing interfaces for both CORBA and a proprietary Remote Method Invocation system. RMI can crosscommunicate with CORBA using the Internet Inter-ORB Operating Protocol (IIOP).

-JavaMail 1.1—The JavaMail API provides an interface for sending and receiving e-mail through standard systems such as SMTP and POP3. This CodeNote describes sending e-mail, and several examples for reading e-mail are available on the website aJ2010004.

-Enterprise JavaBeans (EJB) 1.1—A JavaBean is a small Java class that follows design rules for exposing member variables. Enterprise JavaBeans (Chapter 6) extend the JavaBean concept into the world of distributed computing. EJBs are used for encapsulating business logic in small, reusable packages that are easily configured into complex applications.

-Java Transaction API (JTA) 1.0—This component provides support for distributed transaction systems. The JTA provides a user-level interface for creating and managing transactions. The use of JTA is beyond the scope of this CodeNote, but several examples are available on the WebSite aJ2010001.

-Java Messaging Service (JMS) 1.0—Many enterprise systems rely on secure, reliable messaging systems for publish-subscribe and broadcast services. JMS provides an interface to these technologies. J2EE 1.2.1 requires that the API definitions be included with any J2EE-compliant server product, but does not require an actual implementation. Although JMS is not covered in this book, several articles on JMS can be found on the website aJ2010002.

Several additional components, such as the Java Authentication and Authorization Service (JAAS), are in draft form and will be included in the next J2EE release, version 1.3, which was in its final draft phase at the time of writing. Chapter 9 (Darkside) includes a brief discussion of several of these technologies.

Deployment Specification

A common belief is that J2EE is nothing more than a wrapper for a set of toolkits. However, J2EE does contain some new tools that are inherently part of the specification. These tools provide packaging for systems components. By extending the traditional Java Archive, or JAR file, into Web Archive (WAR) and Enterprise Archive (EAR) files, the J2EE deployment specification provides much greater flexibility for distributed enterprise systems.

In addition to packaging, the deployment specification also includes definitions for role-based security. Role-based security can define access to individual methods on EJBs and access to individual web pages in a WAR. These security settings can also be accessed programmatically inside EJBs, Servlets, and JSPs for finer-grained control.

Finally, the deployment specification includes support for environment variables maintained by the J2EE container. These variables can range from database access to e-mail connectivity to default parame- ters. Environment settings are accessible through a naming service and JNDI.

The deployment specification is detailed in Chapter 8 (Deployment).

About the Vendor
Sun Microsystems

Sun (www.sun.com) originally developed Java as a language for television “set top boxes,” which were an instrumental component of the anticipated interactive TV explosion. Instead, the Internet and World Wide Web exploded and Java was quickly drawn into the realm of platform independent computing.

Sun’s philosophy for Java consists of two key statements: “The Network is the Computer”™ and “Write Once, Run Anywhere”™. These two concepts are built into every aspect of Java and J2EE.

Vendors

JDBC, JSP, Servlets, and EJB all require components that are built by third-party vendors. These components must conform to the basic J2EE specification but can have dramatically different support for the extended features of J2EE. The following lists of vendors include many of the market leaders but are by no means exhaustive.

JDBC Drivers

Most database vendors provide a JDBC driver for their database. For example, if you are using an Oracle database, you should strongly consider using the Oracle JDBC driver. However, several companies provide cross-database-compliant drivers that are very feature-rich.

-Merant (www.merant.com) is a major player in JDBC driver development and has offerings for all of the major databases.

-Inet Software (www.inetsoftware.de) provides crossplatform JDBC drivers, including an SQL Server driver.

If you are in doubt when selecting a JDBC driver vendor, the best starting point is always Sun’s JDBC driver database (industry.java.sun.com/ products/jdbc/drivers).

Excerpted from CodeNotes for J2EE by Edited by Gregory Brill Copyright © 2002 by Edited by Gregory Brill. Excerpted by permission of Random House Trade Paperbacks, a division of Random House LLC. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.