Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. If you are already working in this area, you know that in today's fast-moving and demanding world of e-commerce and information technology, enterprise applications have to be designed, built, and produced for less money, faster, and with fewer resources than ever before.
To reduce costs and fast-track enterprise application design and development, the Java 2 Platform, Enterprise Edition (Java EE) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The Java EE platform gives you a multitiered distributed application model, the ability to reuse components, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent Java EE component-based solutions are not tied to the products and APIs of any one vendor.
This article introduces the Java EE platform and doubles as the overview chapter for the Java EE tutorial. The Java EE Tutorial takes an examples-based approach to describing the features and functionalities available in Java EE SDK version 1.3. Whether you are a or an experienced enterprise developer, you should find the examples and accompanying text in the Java EE tutorial a valuable and accessible knowledge base for creating your own enterprise solutions.
If you are new to Java EE applications development, this introduction is a good place to start. Here you will learn the Java EE architecture, become acquainted with important terms and concepts, and find out how to approach Java EE applications programming, assembly, and deployment.
The Java EE platform uses a multitiered distributed application model. This means application logic is divided into components according to function, and the various application components that make up a Java EE application are installed on different machines depending on which tier in the multitiered Java EE environment the application component belongs. Figure 1 shows two multitiered Java EE applications divided into the tiers described in the bullet list below. The Java EE application parts shown in Figure 1 are presented in Java EE Application Components.
While a Java EE application can consist of the three or four tiers shown in Figure 1, Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three different locations: client machines, Java EE server machine, and the database or legacy machines at the back-end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage.
Figure 1: Multitiered Applications
Java EE applications are made up of components. A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and files and communicates with other components. The Java EE specification defines the following Java EE components:
Java EE components are written in the Java programming language and compiled in the same way as any Java programming language program. The difference when you work with the Java EE platform, is Java EE components are assembled into a Java EE application, verified that they are well-formed and in compliance with the Java EE specification, and deployed to production where they are run and managed by the Java EE server.
A Java EE application can be web-based or non-web-based. An application client executes on the client machine for a non-web-based Java EE application, and a web browser downloads web pages and applets to the client machine for a web-based Java EE application.
An application client runs on a client machine and provides a way for users to handle tasks such as Java EE system or application administration. It typically has a graphical user interface created from Project Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible.
Application clients directly access enterprise beans running in the business tier. However, if the Java EE application client requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier.
The user's web browser downloads static or dynamic Hypertext Markup Language (HTML), Wireless Markup Language (WML), or Extensible Markup Language (XML) web pages from the web tier. Dynamic web pages are generated by servlets or JSP pages running in the web tier.
A web page downloaded from the web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java VM installed in the web browser. However, client systems will likely need Java Plug-in and possibly a security policy file so the applet can successfully execute in the web browser.
JSP pages are the preferred API for creating a web-based client program because no plug-ins or security policy files are needed on the client systems. Also, JSP pages enable cleaner and more modular application design because they provide a way to separate applications programming from web page design. This means personnel involved in web page design do not need to understand Java programming language syntax to do their jobs.
Applets that run in other network-based systems such as handheld devices or car phones can render Wireless Markup Language (WML) pages generated by a JSP page or servlet running on the Java EE server. The WML page is delivered over Wireless Application Protocol (WAP) and the network configuration requires a gateway to translate WAP to HTTP and back again. The gateway translates the WAP request coming from the handheld device to an HTTP request for the Java EE server, and then translates the HTTP server response and WML page to a WAP server response and WML page for display on the handheld device.
The client tier might also include a component based on the JavaBeans component architecture (JavaBeans component) to manage the data flow between an application client or applet and components running on the Java EE server. JavaBeans components are not considered components by the Java EE specification.
JavaBeans components written for the Java EE platform have instance variables and get and set methods for accessing the data in the instance variables. JavaBeans components used in this way are typically simple in design and implementation, but should conform to the naming and design conventions outlined in the JavaBeans component architecture.
Figure 2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the Java EE server either directly, or as in the case of a client running in a browser, by going through JSP pages or servlets running in the web tier.
Figure 2: Server Communications
Java EE applications use a thin client. A thin client is a lightweight interface to the application that does not do things like query databases, execute complex business rules, or connect to legacy applications. Heavyweight operations like these are off-loaded to web or enterprise beans executing on the Java EE server where they can leverage the security, speed, services, and reliability of Java EE server-side technologies.
Java EE web components can be either JSP pages or servlets. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that contain static content and snippets of Java programming language code to generate dynamic content. When a JSP page loads, a background servlet executes the code snippets and returns a response.
Static HTML pages and applets are bundled with web components during application assembly, but are not considered web components by the Java EE specification. Server-side utility classes can also be bundled with web components, and like HTML pages, are not considered web components.
Like the client tier and as shown in Figure 3, the web tier might include a JavaBeans object to manage the user input and send that input to enterprise beans running in the business tier for processing.
Figure 3: Web Tier and Java EE Application
Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure 4 shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.
There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database table. If the client terminates or if the server shuts down, the underlying services ensure the entity bean data is saved.
A message-driven bean combines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS messages asynchronously. This introduction describes entity beans and session beans. For information on message-driven beans, see the Java Message Service Tutorial.
Figure 4: Business and EIS Tiers
The enterprise information system tier handles enterprise information system software, and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. Java EE application components might need access to enterprise information systems for database connectivity, for example.
Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. The component-based and platform-independent Java EE architecture makes Java EE applications easy to write because business logic is organized into reusable components and the Java EE server provides underlying services in the form of a container for every component type. Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.
Component are installed in their containers during deployment and are the interface between a component and the low-level platform-specific functionality that supports the component. Before a web, enterprise bean, or application client component can be executed, it must be assembled into a Java EE application and deployed into its container.
The assembly process involves specifying container settings for each component in the Java EE application and for the Java EE application itself. Container settings customize the underlying support provided by the Java EE Server, which include services such as security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. Here are some of the highlights:
The fact that the Java EE architecture provides configurable services means that application components within the same Java EE application can behave differently based on where they are deployed. For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.
The container also manages non-configurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistence, and access to the Java EE platform APIs described in Java EE APIs. Although data persistence is a non-configurable service, the Java EE architecture lets you override container-managed persistence by including the appropriate code in your enterprise bean implementation when you want more control than the default container-managed persistence provides. For example, you might use bean-managed persistence to implement your own finder (search) methods or to create a customized database cache.
The deployment process installs Java EE application components in the following types of Java EE containers. The Java EE components and container addressed in this tutorial are shown in Figure 5.
Figure 5: Java EE Server and Containers
Java EE components are packaged separately and bundled into a Java EE application for deployment. Each component, its related files such as GIF and HTML files or server-side utility classes, and a deployment descriptor (DD), are assembled into a module and added to the Java EE application. A Java EE application is composed of one or more enterprise bean, web, or application client component modules. The final enterprise solution can use one Java EE application or be made up of two or more Java EE applications depending on design requirements
A Java EE application and each of its modules has its own deployment
descriptor. A deployment descriptor is an Extensible Markup Language
(XML) text-based file with an .xml
extension that describes a component's deployment settings. An
enterprise bean module deployment descriptor, for example, declares
transaction attributes and security authorizations for an enterprise
bean. Because deployment descriptor information is declarative, it can
be changed without modifying the bean source code. At run time, the
Java EE server reads the deployment descriptor and acts upon the component
accordingly.
A Java EE application with all of its modules is delivered in an
Enterprise ARchive (EAR) file. An EAR file is a standard JAR file with
an .ear
extension. In the GUI version of the Java EE SDK application deployment
tool, you create an EAR file first and add JAR and WAR files to the
EAR. If you use the command line packager tools, however, you create
the Java ARchive (JARs) and Web ARchive (WAR) files first and create
the EAR. The Java EE SDK tools are described in Tools.
.class files for the enterprise bean..class files for the application client..class files for the servlet or .jsp files for
a JSP page.Using modules and EAR files makes it possible to assemble a number of different Java EE applications using some of the same components. No extra coding is needed; it is just a matter of assembling various Java EE modules into Java EE EAR files.
Reusable modules make it possible to divide the application development and deployment process into distinct roles so different people or companies can perform different parts of the process.
The first two roles involve purchasing and installing the Java EE product and tools. Once software is purchased and installed, Java EE components can be developed by application component providers, assembled by application assemblers, and deployed by application deployers. In a large organization, each of these roles might be executed by different individuals or teams. This division of labor works because each of the earlier roles outputs a portable file that is the input for a subsequent role. For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a Java EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the Java EE application into a Java EE server.
The different roles are not always executed by different people. If you work for a small company, for example, or if you are prototyping a sample application, you might perform the tasks in every phase.
The Java EE product provider is the company that designs and makes available for purchase the Java EE platform, APIs, and other features defined in the Java EE specification. Product providers are typically operating system, database system, application server, or web server vendors who implement the Java EE platform according to the Java 2 Platform, Enterprise Edition Specification.
The tool provider is the person or company who makes development, assembly, and packaging tools used by component providers, assemblers, and deployers. See Tools for information on the tools available with Java EE SDK version 1.3.
The application component provider is the company or person who creates web components, enterprise beans, applets, or application clients for use in Java EE applications.
A software developer performs the following tasks to deliver an EJB JAR file that contains the enterprise bean:
.class files and deployment descriptor into an EJB JAR fileA web designer (JSP pages) or software developer (servlets) performs the following tasks to deliver a WAR file containing the web component.
.class, .jsp, .html,
and deployment descriptor files in the WAR fileA software developer performs the following tasks to deliver a JAR file containing the Java EE application client.
.class files and deployment descriptor into the JAR fileThe application assembler is the company or person who gets application component JAR files from component providers and assembles them into a Java EE application EAR file. The assembler or deployer can edit the deployment descriptor directly or use tools that correctly add XML tags according to interactive selections. A software developer performs the following tasks to deliver an EAR file containing the Java EE application.
The deployer and administrator is the company or person who configures and deploys the Java EE application, administers the computing and networking infrastructure where Java EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls, security attributes, and specifying connections to databases.
During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server, and generates the container-specific classes and interfaces.
A deployer/system administrator performs the following tasks to install and configure a Java EE application.
The Java EE SDK is a noncommercial operational definition of the Java EE platform and specification made freely available by Sun Microsystems for demonstrations, prototyping, and educational uses. It comes with the Java EE application server, web server, relational database, Java EE APIs, and complete set of development and deployment tools. You can download the Java EE SDK from the web.
The web server provides services to one or more web containers. For example, a web container typically relies on a web server to provide HTTP message handling. A Java EE implementation is not required to support a particular type of web server, which means the web server supported by different Java EE products can vary.
The relational database provides persistent storage for application data. A Java EE implementation is not required to support a particular type of database which means the database supported by different Java EE products can vary. See the Release Notes included with the Java EE SDK download for a list of the databases currently supported by the reference implementation.
The Java 2 Platform, Standard Edition (J2SE) SDK is required to run the Java EE SDK and provides core APIs for writing Java EE components, core development tools, and the Java virtual machine1. The Java EE SDK provides the following APIs to be used in Java EE applications.
An enterprise bean is a body of code with fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Java EE server.
There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans as described in Business Components. You do not have to write any SQL code or use the JDBC API directly to perform database access operations with an entity bean. The EJB container handles this for you. However, if you override the default container-managed persistence for any reason, you will need to use the JDBC API. Also, if you choose to have a session bean access the database, you have to use the JDBC API.
The JDBC API lets you invoke SQL commands from Java programing language methods. You use the JDBC API in an enterprise bean when you override the default container-managed persistence or have a session bean access the database. With container-managed persistence, database access operations are handled by the container and your enterprise bean implementation contains no JDBC code or SQL commands. You can also use the JDBC API from a servlet or JSP page to access the database directly without going through an enterprise bean.
The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the Java EE platform.
Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.
JSP pages technology lets you put combine snippets of Java programming language code with static markup in a text-based document. A JSP page is a text-based document that contains two types of text: static template data which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements that determine how the page constructs dynamic content.
The JMS API is a messaging standard that allows Java EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. For more information on JMS see the Java Message Service Tutorial.
The JTA API provides a standard demarcation interface for demarcating transactions. The Java EE architecture provides a default auto commit to handle transaction commits and roll backs. An auto commit means any other applications viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction including both operations begins, rolls back, and commits.
Many Internet applications need to send email notifications so the Java EE platform includes the JavaMail API with a JavaMail service provider that application components can use to send Internet mail. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface.
The JavaBeans Activation Framework is included because JavaMail uses it. It provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBean component to perform those operations.
XML is a language for representing and describing text-based data so the data can be read and handled by any program or tool that uses XML APIs. Programs and tools can generate XML files that other programs and tools can read and handle.
For example, a Java EE application can use XML to produce reports, and different companies that receive the reports can handle the data in a way that best suits their needs. One company might put the XML data through a program to translate the XML to HTML so it can post the reports to the web, another company might put the XML data through a tool to create a marketing presentation, and yet another company might read the XML data into its Java EE application for processing.
The Connector API is used by Java EE tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any Java EE product. A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager. Because a resource adapter is specific to its resource manager, there is typically a different resource adapter for each type of database or EIS.
The Java Authentication and Authorization Service (JAAS) provides a way for a Java EE application to authenticate and authorize a specific user or group of users to run it. JAAS is a Java programing language version of the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 platform security architecture to support user-based authorization.
The Java EE reference implementation provides an application deployment tool and an array of scripts for assembling, verifying, and deploying Java EE applications and managing your development and production environments. See The Java EE Tutorial for a complete discussion of the tools.
The Java EE reference implementation provides an application deployment tool for assembling, verifying, and deploying Java EE applications. It comes in two versions: command-line and GUI.
The GUI tool includes wizards for
In addition, configuration information can be set for each component and module type in the tabbed inspector panels.
Table 1 lists the scripts included with the Java EE reference implementation that let you perform operations from the command line.
| Script | Description |
|---|---|
j2ee |
Start and stop the Java EE server. |
cloudscape |
Start and stop the default database. |
cloudIJ |
Run the interactive SQL tool. This is an unsupported tool. |
j2eeadmin |
Add JDBC drivers, JMS destinations, and connection factories for various resources. |
keytool |
Create public and private keys and generate X509 self-signed certificates. |
realmtool |
Import certificate files. Add Java EE users to and remove Java EE users from the authentication and authorization list for a Java EE application. |
packager |
Package Java EE application components into EAR, EJB JAR, application client JAR, and WAR files. |
verifier |
Verify that EAR, EJB JAR, application client JAR, and WAR files are well-formed and comply with the Java EE specification. |
runclient |
Run a Java EE application client. |
cleanup |
Remove all deployed applications from the Java EE server. |
The Java EE platform provides everything you need to design, build, test, and deploy distributed multi-tiered applications. The Java EE tutorial provides in-depth coverage on the platform features, APIs, and tools. If you want help with Java EE application design, Java EE Blueprints Digest presents a high-level introduction to the standard programming model for developing multitiered, thin-client applications on the Java EE platform.
The application programming model consists of a body of technologies and principles to guide the Java EE applications developer in doing such things as deciding on the most appropriate implementation options, making the best use of Java ServerPages and servlets, choosing a good design when implementing business logic, and effectively mapping the Java EE security model to enterprise computing environments and infrastructures.
1 As used on this web site, the terms Java virtual machine or Java VM mean a virtual machine for the Java platform.
© 1994-2005 Sun Microsystems, Inc.