<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 

    2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

 <servlet>

  <servlet-name>AllItemsServlet</servlet-name>

  <servlet-class>AllItemsServlet</servlet-class>

 </servlet>

 <servlet>

  <servlet-name>DetailServlet</servlet-name>

  <servlet-class>DetailServlet</servlet-class>

 </servlet>

 <servlet-mapping>

  <servlet-name>AllItemsServlet</servlet-name>

  <url-pattern>/servlet/AllItemsServlet</url-pattern>

 </servlet-mapping>

 <servlet-mapping>

  <servlet-name>DetailServlet</servlet-name>

  <url-pattern>/servlet/DetailServlet</url-pattern>

 </servlet-mapping>

 <session-config>

  <session-timeout>

   30

  </session-timeout>

 </session-config>

 <welcome-file-list>

  <welcome-file>

   index.jsp

   </welcome-file>

   <welcome-file>

    index.html

   </welcome-file>

   <welcome-file>

    index.htm

   </welcome-file>

  </welcome-file-list>

  <ejb-ref>

   <ejb-ref-name>ejb/CatalogManagerBean</ejb-ref-name>

   <ejb-ref-type>Session</ejb-ref-type>

   <home>CatalogBeans.CatalogManagerBeanHome</home>

   <remote>CatalogBeans.CatalogManagerBean</remote>

   <ejb-link>CatalogManagerBean</ejb-link>

  </ejb-ref>

</web-app>

When you work in the Sun ONE Studio 5 IDE, you do not code the deployment descriptors for your modules and applications. You work with the IDE's visual representations of components, modules, and applications, and the IDE prepares the deployment descriptors for you.

---

Visual Representations of Modules and Applications

Most explanations of J2EE assembly focus on the contents of deployment descriptor files, such as the files shown in CODE EXAMPLE 1-1, CODE EXAMPLE 1-2, and CODE EXAMPLE 1-3. These explanations tell you how to code the XML. The Sun ONE Studio 5 IDE provides visual representations of components, modules, and applications. Instead of coding deployment descriptor files, you work with Explorer window nodes that represent components, modules, and applications.

When you assemble in the IDE, the Explorer creates a visual representation of the module or application you are creating. The nodes that represent applications have subnodes for their modules, and the nodes that represent modules have subnodes for their components. While you work with the visual representation, the IDE creates a matching deployment descriptor.

Each node has a property sheet that allows you to configure the component, module, or application that the node represents. Most of the properties map to deployment descriptor tags. (There are more properties than deployment descriptor tags.) You configure a component, module, or application for deployment by setting its properties, and the IDE adds tags to its deployment descriptor. These tags identify the services that are needed from the application server.

The sections that follow introduce the IDE's visual representations of modules and applications.

Web Modules

Web modules have a standard directory structure (for more information see Building Web Components), and this structure is represented in the Explorer window. FIGURE 1-2 shows a web module in the Explorer. The nodes and subnodes of a web module represent the individual directories and files in the module.

The top-level node for a web module represents the web module's top-level directory. For the IDE to recognize a directory as a web module you must mount the directory as an Explorer window filesystem. If you mount a web module directory in the Explorer as a subdirectory of another filesystem, the IDE will not recognize the web module directory as a web module.

The top-level node has a subnode for a WEB-INF directory. The WEB-INF directory has subnodes for a lib subdirectory, which is used for web components in JAR file format, and a classes subdirectory, which is used for any web components in .java file format. The WEB-INF node also has a web subnode that represents the module's deployment descriptor file. This is the standard directory structure for a web module.

Web modules also have nodes for components and resources that are added by developers. FIGURE 1-2 shows a node for an HTML page named index.html. The classes directory contains nodes for two servlet classes, which are named AllItemsServlet and ItemDetailServlet.

 FIGURE 1-2 Web Module Node and Subnodes

Notice that this representation of a web module corresponds to a specific directory and its contents. The deployment descriptor is a file named web.xml, which is represented in the Explorer by the web node. The web.xml file is part of the web module's source code.

EJB Modules

EJB modules are represented differently from web modules. The top-level node for an EJB module does not represent a particular directory and its contents. Instead, the EJB module node represents the module's deployment descriptor. The EJB module node functions as a list of enterprise beans. These enterprise beans can be in one directory or in a number of directories in different filesystems. The top-level node, which represents the deployment descriptor, tracks where the source code for the components is located.

Representing EJB modules with logical nodes allows you to combine enterprise beans from different directories in one EJB module. It also keeps the configuration information in the deployment descriptor separate from the source code. When you deploy an EJB module, a deployment descriptor XML file is generated and the source files for the components that are identified in the deployment descriptor are compiled into an EJB JAR file.

FIGURE 1-3 shows an EJB module in the Explorer window. This module has subnodes for three enterprise beans that have been included in the module. Each of these enterprise beans can be in a different directory. It is even possible for a single enterprise bean to be in several different directories. For example, the source code for the enterprise bean's interfaces could be in one directory and the classes that implement those interfaces could be in a different directory.

 FIGURE 1-3 EJB Module Node and Subnodes

J2EE Applications

J2EE applications are also represented by logical nodes. Like an EJB module node, the top-level J2EE application node does not represent a single directory or filesystem. Instead, the application node represents a deployment descriptor for the application and functions as a list of the modules that make up the application. The source code for these modules can be in more than one directory or filesystem.

The IDE maintains the application-level deployment descriptor separately from the source code. You can include the same source code in more than one J2EE application. The deployment process compiles all the source files and associates the compiled versions with the deployment descriptor in an EAR file.

FIGURE 1-4 shows a J2EE application in the Explorer. The modules shown FIGURE 1-2 and FIGURE 1-3 have been added to the application. The modules are represented by subnodes of the application node.

 FIGURE 1-4 J2EE Application Node and Its Subnodes

Property Sheets

Every node that represents a J2EE module or application has a property sheet. The property sheet has properties that let you specify what services the module or application needs from the application server. These properties correspond to the tags that appear in the module or application deployment descriptor. When you set the values of properties, you supply the information that will be used in the deployment descriptor. You work with the property sheet instead of editing and formatting the XML deployment descriptor with a text editor.

• In the case of a web module, the deployment descriptor exists as a file, and the file appears in the Explorer window. You can see this in FIGURE 1-2. The values that you specify in the web module deployment descriptor are associated with the source files.
• In the case of an EJB module or a J2EE application the deployment descriptor file is not generated until you deploy the module or application. Deployment compiles the source files and generates an archive file, a EJB Jar or an EAR file. deployment descriptor file is included in the archive. The deployment descriptor is associated with a specific archived copy of the source files.

The properties have property editors that help you select the correct values. When you have the property sheet open, you open the editors for individual properties by clicking a property and clicking the ellipsis (...) button. Procedures for using the property editors vary widely--some let you browse for IDE nodes, some let you open another level of dialog, and so on. For the more complex property editors, online help is available.

The property sheets have a number of tabs. The tab labeled Properties lists the standard properties defined by the J2EE specifications. Other tabs have the names of application server products. These tabs collect additional information that is not defined in the J2EE specifications but is required by a specific application server product. These tabs are the property sheet's server-specific tabs. When you assemble a module or application you need to work with the standard properties and with the server-specific properties for the server product that you are using.

---

Deployment Basics

Deployment is the process of compiling the source files that make up a J2EE application and installing the compiled files into directories that are managed by a J2EE application server. Deployment is carried out by the application server or by software distributed with the server, such as a deployment tool or an administration tool.

The IDE communicates with application servers. It provides commands that deploy modules or applications to an application server and execute the modules or applications. You can deploy and execute without leaving the IDE. Deployment is performed by the plugin or the application server software, and execution happens in the application server's environment, but you manage deployment and execution in the IDE.

After you execute an application and test it, you can modify the source code, redeploy the application, and execute the new version. You can continue this process as long as necessary.

The actual procedure for deploying an application that you have assembled is very simple. You right-click the application node and choose the Deploy command. Before you deploy, however, the IDE must be set up to work with an application server. The steps for setting up an application server are summarized in the following list:

1. Install the application server.

2. Install the server plugin that enables communication between the IDE and the application server. The plugin for Sun ONE Application Server 7, Standard Edition is installed with the IDE. Plugins are available for other widely used application server products. Installing a plugin creates application server nodes in the Explorer's Runtime tab. (To learn more about the plugin, see Appendix A.)

3. Use the menu commands of the application server nodes to establish communications between the IDE and the application server.

4. Use the application's property sheet to specify the application server to which your application will be deployed.

5. Right-click the application node and choose the Deploy command. The deployment software reads the deployment descriptor represented by the application node and deploys the source files that are listed in the deployment descriptor.

Most installations of the IDE include Sun ONE Application Server 7, and the installer automatically configures the IDE to work with the application server. The Sun ONE Studio 5, Standard Edition Getting Started Guide explains this in detail.

---

Execution Basics

After you deploy an application you can execute the application. The IDE associates the Explorer node that represents the application with the deployed copy of the application. You can right-click the node and choose the Execute command, and the IDE instructs the application server to execute the deployed copy of the application.

A number of IDE nodes, including the J2EE application nodes, have Execute commands. When you right-click a node and choose Execute, the IDE, if necessary, deploys the application and then executes it. The results of the Execute command depend on the type of application. For example, if the application includes a web module, the Execute command will start a web browser and open the application's URL.

You can also execute deployed applications entirely in the application server's environment, without using the IDE. For example, to execute a deployed application that includes a web module, start a web browser and open one of the application's web pages.

---

Using This Book

The Java Community Process, supported by Sun Microsystems, Inc., has evolved standards for designing distributed, enterprise applications with J2EE components. The J2EE platform documentation listed in Before You Read This Book covers these standards for application design and architecture.

This book is about how you implement these architectures with the Sun ONE Studio 5 IDE. It is about using the IDE to combine components and create J2EE modules, making sure that all of the components interact in the way that the application design specifies. It is also about combining J2EE modules to create J2EE applications, making sure that the distributed interactions between the modules function in the way that the application design calls for.

This book covers assembly by presenting a number of examples, or scenarios. Each scenario presents a realistic combination of components or modules and shows you how to assemble them into a module or an application. The business problems described in the scenarios are realistic, but this book is not really meant to be an exhaustive guide to designing J2EE applications.

The real purpose of these scenarios is to show you how to program specific kinds of interactions between components and modules. Once you have decided on your application design, you can use the scenarios in this book to help you program the interactions between the components and modules in your application.

You probably will not find everything you need in a single scenario, because each scenario focuses on one or two kinds of J2EE interaction, and your real-world J2EE application can include dozens or hundreds of components and interactions. For each kind of interaction, however, you should find an example in this book.

For example, to program one common type of J2EE application, with a web module and an EJB module, you can look at Chapter 2, which covers assembling a web module, Chapter 3, which covers assembling an EJB module, and Chapter 4, which covers assembling a web module and an EJB module into a J2EE application. Then, to see how you set up transactions, look at Chapter 6, and, for security, look at Chapter 7.

This book is your guide to developing distributed enterprise applications with the Sun ONE Studio 5 development environment. It shows you how to develop J2EE modules, how to program your modules for different kinds of interactions, and how to request enterprise services, such as security checking and transaction management, from the J2EE platform.