| Building J2EE Applications |    
|
| Building J2EE Applications |
|
| C H A P T E R 1 |
|
Assembly, Deployment, and Execution Basics |
The modular nature of the J2EE platform means that you combine smaller units to make larger ones. You combine components to create modules and then combine the modules to create applications. This combining of smaller units to create larger ones is known as assembly.
The J2EE modules and applications you assemble will need runtime services provided by the platform, services such as container-managed persistence, container-managed transactions, and container-managed security validation. So, as you assemble components into modules and modules into applications, you must determine which runtime services they need and specify those services in a J2EE deployment descriptor. This is also part of the assembly process.
This chapter reviews the basic characteristics of J2EE modules and applications that you must consider when you assemble. It also introduces the basics of assembling with the Sun ONE Studio 4 IDE.
Assembly is a J2EE concept that covers a number of separate development tasks. If you perform the assembly tasks correctly, you end up with modules and applications that you can deploy to a J2EE application server and execute in the server's environment.
The greatest obstacle to successful assembly is the variability of the process. Every module or application you assemble requires a different combination of runtime services. Since there is no standard set of steps for assembling modules and applications, you need to approach the process with some understanding of what a correctly assembled module or application is. This section provides some background information on J2EE modules and applications that should help you understand the assembly process.
A J2EE application is a collection of components, combined into modules, which are themselves combined into an application. The J2EE mechanism for combining components into modules and modules into applications is the deployment descriptor, which is basically a list. The deployment descriptor for a module lists the components in the module and the deployment descriptor for an application lists the modules in the application.
To understand why the J2EE platform uses the deployment descriptor, consider how the source code for an application is used. At edit time, components exist as a number of source files in your development environment, and they cannot be executed until you deploy them, or install them in a J2EE runtime environment.
Deploying an application compiles the source files identified by the deployment descriptor and installs the compiled files in directories managed by the application server. After the application is deployed you can execute it in the application server's environment. In other words, an application is created when you deploy it.
So the deployment descriptor is an edit time mechanism for specifying a set of files that will be deployed together as a module or an application. When you assemble a module or an application at edit time you are not actually modifying the source files. You are simply preparing a deployment descriptor that identifies the contents of your module or application, which will be used as input to the deployment process.
Deployment descriptors are XML files. They use specific XML tags to identify an application and the modules that make up the application (or the module and the components that make up the module). CODE EXAMPLE 1-1 is an example of a deployment descriptor for an application.
This example is the deployment descriptor for a J2EE application named CatalogApp. It contains two modules, CatalogData and CatalogWebModule. Each module is identified by a <module> tag.
Each of the modules in the application has its own module-level deployment descriptor that lists the components in the module. (For examples of module-level deployment descriptors, see CODE EXAMPLE 1-2 and CODE EXAMPLE 1-3.) When you deploy this application the application server will read this deployment descriptor, and then read the two module-level deployment descriptors, which identify the source files for the individual J2EE components.
At runtime, J2EE applications make extensive use of services provided by the J2EE application server to which they have been deployed. Among the most significant of these services are container-managed persistence, container-managed transactions and container-managed security validation, but there are others.
To make use of these services, applications, and the modules that make up applications, must tell the application server which services they need. The mechanism for this is the deployment descriptor. For an example, consider J2EE container-managed transactions. To use this service you define the appropriate transaction boundaries when you program Enterprise JavaBeans components, by setting each enterprise bean's transaction attribute property. To convey this information to the runtime environment, this value is included in the deployment descriptor for the EJB module that contains the enterprise bean. CODE EXAMPLE 1-2 is the deployment descriptor for the EJB module named CatalogData (which was listed in CODE EXAMPLE 1-1). The tags with the transaction attribute values appear at the end of the deployment descriptor.
When the application that contains this EJB module is deployed and executed, the J2EE application server will recognize the transaction boundaries specified in the deployment descriptor and open and commit transactions (or roll them back) at the appropriate points.
In addition to being modular and making use of runtime services, J2EE applications are distributed. Each module in a J2EE application can be deployed to a different machine and run in its own process to create a distributed application. FIGURE 1-1 shows a J2EE application, composed of two modules, implementing a typical multi-tiered application architecture.
[ D ]
The web module is deployed on a machine that is dedicated to HTTP interactions with users. The application server uses HTTP connections to send the web pages defined in the web module to browsers running on user desktop machines. The EJB module is deployed on another machine, dedicated to database operations. The HTTP connections between web browser and web module and the distributed interaction between the two modules are supported by the J2EE application server.
The J2EE platform provides a number of technologies that support different modes of communication between modules, including:
J2EE supports these different types of interaction with different kinds of components. For example, the message-driven Enterprise JavaBean supports asynchronous messaging between modules.
Selecting a mode for interactions between the modules in an application, and choosing a component type to implement the interaction, are part of application design. But when the time comes to assemble the application, you need to know what kind of interaction was designed and how to implement it. This means that when you assemble you perform such tasks as setting up EJB references (to implement Java RMI interactions), or setting up queues (to implement JMS messaging interactions).
The J2EE platform also supports interactions between J2EE modules and the external resources used by applications, such as data sources. The technologies that support these interactions include:
When you assemble an application, you also need to make sure that any external resources the deployed application uses are identified correctly. Once again, the deployment descriptor is the edit tine mechanism for identifying external resources.
CODE EXAMPLE 1-3 shows the deployment descriptor for a web module named CatalogWebModule. This module is assembled, with an EJB module (the EJB module whose deployment descriptor is shown in CODE EXAMPLE 1-2), into a J2EE application. The technology used for the interaction between these two modules is Java RMI. Java RMI depends on a remote EJB reference, which is declared at the end of this deployment descriptor with the <ejb-ref> tag.
Most explanations of the J2EE assembly process look at the contents of deployment descriptor files, such as those shown in the preceding code examples, and explain how to code the XML for a deployment descriptor. The Sun ONE Studio 4 development environment provides visual representations of components, modules, and applications, and instead of working with deployment descriptor files, you work with Explorer window nodes that represent components, modules, and applications.
Nodes that represent applications have subnodes for their modules, and module nodes have subnodes for their components. As you assemble, the Explorer creates a visual representation of the module or application you are creating. While you work with the visual representation, the IDE creates a matching deployment descriptor.
Each node you work with has a property sheet that allows you to configure the component, module, or application. Many of the properties correspond to deployment descriptor tags. (There are more properties than deployment descriptor tags.) This means that as you configure your component, module, or application by setting its properties, the IDE is adding tags to its deployment descriptor, which identify the services needed from the application server, including those that enable distributed interactions between modules.
The sections that follow introduce the IDE's visual representations of modules and applications.
The nodes and subnodes of a web module represent the individual files in the module. 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 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 it as an Explorer window filesystem. If a web module directory appears as a subdirectory of another filesystem the IDE will not recognize it as a web module. This is also covered in more detail in Building Web Components.
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, for any web components in .java file format. The WEB-INF node also has a web.xml subnode that represents the module's deployment descriptor file. This is the standard directory structure for a web module.
This particular web module also has nodes for a JSP page named myNewJSP, an HTML page named index.html, and a taglib named myTagLib. These nodes represent components and resources added by a web component provider. In addition to these nodes, the classes directory contains a node for a servlet class named myNewServlet, which is another resource added by the component provider.
Notice that this representation of a web module corresponds to a specific directory and its contents. The deployment descriptor (the web.xml file) is included with the source code.
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. It functions as a list of enterprise beans, which can be in one directory or in a number of directories in different filesystems. The deployment descriptor specifies 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 file is generated and the source files for the components identified in the deployment descriptor are compiled, from wherever they happen to be in your filesystem, 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 could be in a different directory. It is even possible for a single enterprise bean to be in several different places in the file system. For example, the source code for the enterprise bean's interfaces could be in one directory while the classes that implement those interfaces could be in a different directory.
[ D ]J2EE applications are also represented by logical nodes. Like an EJB module node, the top-level node for a J2EE application does not represent a single directory or filesystem. Instead, it represents the application-level deployment descriptor, and it functions as a list of 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, making it possible to use the same source code in more than one J2EE application.Only when you deploy the application (or generate an EAR file for the application) does the IDE take a copy of all the source files and associate them with the deployment descriptor in an EAR file.
FIGURE 1-4 shows a J2EE application in the Explorer. The modules in FIGURE 1-2 and FIGURE 1-3 have been added to the application, and are represented by subnodes of the application node.
[ D ]Every node that represents a J2EE module or application has a property sheet. The property sheet has properties that let you describe the services the module or application needs from the application server. These properties correspond to the tags that appear in the module's or application's deployment descriptor, so that as you set the values of properties you are supplying information that will be used in the deployment descriptor. This means that you can work with the property sheet instead of trying to edit and format the XML deployment descriptor with a text editor. (Some of the properties do not correspond to deployment descriptor tags.)
Many of the properties have property editors that help you select the correct values. When you have the property sheet open, you open editors for individual properties by clicking a property and then 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. The other tabs have the names of applications server products. These tabs collect additional information, not defined in the J2EE specifications, but required by a specific application server product. These tabs are referred to as the property sheet's server-specific tabs. When you assemble a module or application you need to work with both standard properties and the server-specific properties for the server product you are using.
As mentioned, deployment is the process of compiling the source files that make up a J2EE application and installing the compiled files into directories managed by a J2EE application server. The process is carried out by the application server or software distributed with the server, such as a deployment tool or an administration tool.
In order to support iterative development--in which you code source files, run them to test them, modify them, and run them again--the Sun ONE Studio 4 IDE makes it possible for you to deploy and execute from within the IDE. Deployment is performed by the application server software, and execution is in the application server's environment, but you can manage deployment and execution from within the IDE. You can write J2EE source code, assemble a J2EE application, and using IDE commands, you can deploy and execute your application. After executing and testing 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 simply right-click the application node and choose the Deploy command. For this to work, however, the IDE must be set up to work with a particular application server. This setup is summarized below. (Complete instructions for this are included in the Sun ONE Studio 4, Enterprise Edition for Java Getting Started Guide.)
1. Install the application server.
2. Install a module that enables communication between the IDE and the application server. These modules are known as server plugins, and each plugin module supports one application server product. A number of plugins are available for widely used application server products. (If you are interested in a description of the plugin's functionality, see Appendix A.)
3. Using the plugin, open communications between the IDE and the application server.This creates an Explorer window node that represents a server instance.
4. Specify the application server to which your application will be deployed, by referring to one of the server instance nodes.
5. Right-click the application node and issue the deploy command. This instructs the deployment software to read the deployment descriptor represented by the application node and process the source files listed in the deployment descriptor.
After an application has been deployed it can be executed. The IDE associates the application node with the deployed copy of the application, which means that you can issue an execute command in the IDE, and the IDE will instruct the application server to execute the deployed copy of the application.
A number of IDE nodes, including 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 contents of the 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 an application that includes a web mode, start a web browser and open a URL for the application.
The Java Community Process, supported by Sun Microsystems, Inc., has evolved standards for designing distributed, enterprise applications with J2EE components. The J2EE documentation listed in covers these standards for application design and architecture.
This book is about how you implement these architectures with the Sun ONE Studio 4 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 this material by presenting a number of examples, or scenarios. Each scenario presents a realistic combinations of components or modules, and shows you how to combine them into a module or an application. The business problems described in the scenarios are realistic, but the book is not really meant to be a guide to designing J2EE applications. There are hints about the appropriate use of J2EE technologies, but not exhaustive discussions.
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 connections that are needed between the components and modules in your application.
You probably won't 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 relationships. For each kind of connection, 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 see Chapter 7, and, for security, see Chapter 8.
This book is your guide to developing distributed enterprise applications with the Sun ONE Studio 4 development environment. It shows you now 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.
| Building J2EE Applications | 816-7863-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.