J2EE Tutorial-15(Running the Web Client)

To run the Web client, point your browser at the following URL. Replace <host> with the name of the host running the J2EE server. If your browser is running on the same host as the J2EE server, you may replace <host>with localhost.

http://<host>:8000/converter

You should see the screen shown in Figure 2-2 after entering 100 in the input field and clicking Submit.

Figure 2-2 Converter Web Client

J2EE Tutorial-8 (Creating the J2EE Application)

The sample application contains three J2EE components: an enterprise bean, a J2EE application client, and a Web component. Before building these components, you will create a new J2EE application called ConverterApp and will store it in an EAR file named ConverterApp.ear.

1. In deploytool, select FileNewApplication.


2. Click Browse.


3. In the file chooser, navigate to j2eetutorial/examples/src/ejb/converter.


4. In the File Name field, enter ConverterApp.ear.


5. Click New Application.


6. Click OK.

J2EE Tutorial-5 (Development Roles)

Reusable modules make it possible to divide the application development and deployment process into distinct roles so that different people or companies can perform different parts of the process.

The first two roles involve purchasing and installing the J2EE product and tools. Once software is purchased and installed, J2EE 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 J2EE 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 J2EE application into a J2EE 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.

J2EE Product Provider

The J2EE product provider is the company that designs and makes available for purchase the J2EE platform, APIs, and other features defined in the J2EE specification. Product providers are typically operating system, database system, application server, or Web server vendors who implement the J2EE platform according to the Java 2 Platform, Enterprise Edition Specification.

Tool Provider

The tool provider is the company or person who creates development, assembly, and packaging tools used by component providers, assemblers, and deployers. See the section Tools for information on the tools available with J2EE SDK version 1.3.

Application Component Provider

The application component provider is the company or person who creates Web components, enterprise beans, applets, or application clients for use in J2EE applications.

Enterprise Bean Developer

An enterprise bean developer performs the following tasks to deliver an EJB JAR file that contains the enterprise bean:

• Writes and compiles the source code


• Specifies the deployment descriptor


• Bundles the .class files and deployment descriptor into an EJB JAR file

Web Component Developer

A Web component developer performs the following tasks to deliver a WAR file containing the Web component:

• Writes and compiles servlet source code


• Writes JSP and HTML files


• Specifies the deployment descriptor for the Web component


• Bundles the .class, .jsp, .html, and deployment descriptor files in the WAR file

J2EE Application Client Developer

An application client developer performs the following tasks to deliver a JAR file containing the J2EE application client:

• Writes and compiles the source code


• Specifies the deployment descriptor for the client


• Bundles the .class files and deployment descriptor into the JAR file

Application Assembler

The application assembler is the company or person who receives application component JAR files from component providers and assembles them into a J2EE 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 J2EE application:

• Assembles EJB JAR and WAR files created in the previous phases into a J2EE application (EAR) file


• Specifies the deployment descriptor for the J2EE application


• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification

Application Deployer and Administrator

The application deployer and administrator is the company or person who configures and deploys the J2EE application, administers the computing and networking infrastructure where J2EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls and 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 J2EE application:

• Adds the J2EE application (EAR) file created in the preceding phase to the J2EE server


• Configures the J2EE application for the operational environment by modifying the deployment descriptor of the J2EE application


• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification


• Deploys (installs) the J2EE application EAR file into the J2EE server

J2EE Tutorial-4 (Packaging)

J2EE components are packaged separately and bundled into a J2EE application for deployment. Each component, its related files such as GIF and HTML files or server-side utility classes, and a deployment descriptor are assembled into a module and added to the J2EE application. A J2EE application is composed of one or more enterprise bean, Web, or application client component modules. The final enterprise solution can use one J2EE application or be made up of two or more J2EE applications, depending on design requirements.

A J2EE application and each of its modules has its own deployment descriptor. A deployment descriptor is an XML document 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 J2EE server reads the deployment descriptor and acts upon the component accordingly.

A J2EE application with all of its modules is delivered in an Enterprise Archive (EAR) file. An EAR file is a standard Java Archive (JAR) file with an .ear extension. In the GUI version of the J2EE SDK application deployment tool, you create an EAR file first and add JAR and Web Archive (WAR) files to the EAR. If you use the command line packager tools, however, you create the JAR and WAR files first and then create the EAR. The J2EE SDK tools are described in the section Tools.

• Each EJB JAR file contains a deployment descriptor, the enterprise bean files, and related files.


• Each application client JAR file contains a deployment descriptor, the class files for the application client, and related files.


• Each WAR file contains a deployment descriptor, the Web component files, and related resources.

Using modules and EAR files makes it possible to assemble a number of different J2EE applications using some of the same components. No extra coding is needed; it is just a matter of assembling various J2EE modules into J2EE EAR files.

J2EE Tutorial-3 (J2EE Containers)

J2EE Containers

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 J2EE architecture makes J2EE applications easy to write because business logic is organized into reusable components. In addition, the J2EE 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.

Container Services

Containers 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 J2EE application and deployed into its container.

The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. Container settings customize the underlying support provided by the J2EE server, which includes services such as security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. Here are some of the highlights:

• The J2EE security model lets you configure a Web component or enterprise bean so that system resources are accessed only by authorized users.


• The J2EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit.


• JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access naming and directory services.


• The J2EE remote connectivity model manages low-level communications between clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.

The fact that the J2EE architecture provides configurable services means that application components within the same J2EE 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 nonconfigurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistence, and access to the J2EE platform APIs described in the section J2EE APIs. Although data persistence is a nonconfigurable service, the J2EE 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.

Container Types

The deployment process installs J2EE application components in the J2EE containers illustrated in Figure 1-5.

 

Figure 1-5 J2EE Server and Containers

J2EE server

 

The runtime portion of a J2EE product. A J2EE server provides EJB and Web containers. 

Enterprise JavaBeans (EJB) container

 

Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server. 

Web container

 

Manages the execution of JSP page and servlet components for J2EE applications. Web components and their container run on the J2EE server. 

Application client container

 

Manages the execution of application client components. Application clients and their container run on the client. 

Applet container

 

Manages the execution of applets. Consists of a Web browser and Java Plug-in running on the client together.