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-12(Specifying the JNDI Names)

Although the J2EE application client and the Web client access the same enterprise bean, their code refers to the bean's home by different names. The J2EE application client refers to the bean's home asejb/SimpleConverter, but the Web client refers to it as ejb/TheConverter. These references are in the parameters of the lookup calls. In order for the lookup method to retrieve the home object, you must map the references in the code to the enterprise bean's JNDI name. Although this mapping adds a level of indirection, it decouples the clients from the beans, making it easier to assemble applications from J2EE components.

To map the enterprise bean references in the clients to the JNDI name of the bean, follow these steps.

1. In the tree, select ConverterApp.


2. Select the JNDI Names tab.


3. To specify a JNDI name for the bean, in the Application table locate the ConverterEJB component and enter MyConverter in the JNDI Name column.


4. To map the references, in the References table enter MyConverter in the JNDI Name for each row.

Figure 2-1 shows what the JNDI Names tab should look like after you've performed the preceding steps.

 

Figure 2-1 ConverterApp JNDI Names

J2EE Tutorial-10(Creating the J2EE Application Client)

A J2EE application client is a program written in the Java programming language. At runtime, the client program executes in a different virtual machine than the J2EE server.

The J2EE application client in this example requires two different JAR files. The first JAR file is for the J2EE component of the client. This JAR file contains the client's deployment descriptor and its class files. When you run the New Application Client wizard, the deploytool utility automatically creates the JAR file and stores it in the application's EAR file. Defined by the J2EE Specification, the JAR file is portable across all compliant J2EE servers.

The second JAR file contains stub classes that are required by the client program at runtime. These stub classes enable the client to access the enterprise beans that are running in the J2EE server. Because this second JAR file is not covered by the J2EE Specification, it is implementation specific, intended only for the J2EE SDK.

The J2EE application client source code is in j2eetutorial/examples/src/ejb/converter/ConverterClient.java. You already compiled this code along with the enterprise bean code in the section Compiling the Source Files.

Coding the J2EE Application Client

The ConverterClient.java source code illustrates the basic tasks performed by the client of an enterprise bean:

• Locating the home interface


• Creating an enterprise bean instance


• Invoking a business method

Locating the Home Interface

The ConverterHome interface defines life-cycle methods such as create. Before the ConverterClient can invoke the create method, it must locate and instantiate an object whose type is ConverterHome. This is a four-step process.

1. Create an initial naming context.
   

   
   

       Context initial = new InitialContext();
   

   
   

   
   

   The Context interface is part of the Java Naming and Directory Interface (JNDI). A naming context is a set of name-to-object bindings. A name that is bound within a context is the JNDI name of the object.

   An InitialContext object, which implements the Context interface, provides the starting point for the resolution of names. All naming operations are relative to a context.



2. Obtain the environment naming context of the application client.
   

   
   

      Context myEnv = (Context)initial.lookup("java:comp/env");
   

   
   

   
   

   The java:comp/env name is bound to the environment naming context of the ConverterClient component.



3. Retrieve the object bound to the name ejb/SimpleConverter.
   

   
   

      Object objref = myEnv.lookup("ejb/SimpleConverter");
   

   
   

   
   

   The ejb/SimpleConverter name is bound to an enterprise bean reference, a logical name for the home of an enterprise bean. In this case, the ejb/SimpleConverter name refers to the ConverterHomeobject. The names of enterprise beans should reside in the java:com/env/ejb subcontext.



4. Narrow the reference to a ConverterHome object.
   

   
   

      ConverterHome home =
         (ConverterHome) PortableRemoteObject.narrow(objref,
            ConverterHome.class);
   

   
   

   
   

Creating an Enterprise Bean Instance

To create the bean instance, the client invokes the create method on the ConverterHome object. The create method returns an object whose type is Converter. The remote Converter interface defines the business methods of the bean that the client may call. When the client invokes the create method, the EJB container instantiates the bean and then invokes the ConverterBean.ejbCreate method. The client invokes the createmethod as follows:

Converter currencyConverter = home.create();

Invoking a Business Method

Calling a business method is easy--you simply invoke the method on the Converter object. The EJB container will invoke the corresponding method on the ConverterEJB instance that is running on the server. The client invokes the dollarToYen business method in the following lines of code.

BigDecimal param = new BigDecimal ("100.00");
BigDecimal amount = currencyConverter.dollarToYen(param);

ConverterClient Source Code

The full source code for the ConverterClient program follows.

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import java.math.BigDecimal;

public class ConverterClient {

   public static void main(String[] args) {

      try {
         Context initial = new InitialContext();
         Object objref = initial.lookup
            ("java:comp/env/ejb/SimpleConverter");

         ConverterHome home = 
            (ConverterHome)PortableRemoteObject.narrow(objref, 
                                          ConverterHome.class);

         Converter currencyConverter = home.create();

         BigDecimal param = new BigDecimal ("100.00");
         BigDecimal amount =
            currencyConverter.dollarToYen(param);
         System.out.println(amount);
         amount = currencyConverter.yenToEuro(param);
         System.out.println(amount);

         System.exit(0);      } catch (Exception ex) {
         System.err.println("Caught an unexpected exception!");
         ex.printStackTrace();
      }
   } 
}

Compiling the Application Client

The application client files are compiled at the same time as the enterprise bean files, as described in Compiling the Source Files.

Packaging the J2EE Application Client

To package an application client component, you run the New Application Client wizard of the deploytool. During this process the wizard performs the following tasks.

• Creates the application client's deployment descriptor


• Puts the deployment descriptor and client files into a JAR file


• Adds the JAR file to the application's ConverterApp.ear file

After the packaging process you can view the deployment descriptor by selecting ToolsDescriptor Viewer.

To start the New Application Client wizard, select FileNewApplication Client. The wizard displays the following dialog boxes.

1. Introduction dialog box
   
   
   
   1. Read the explanatory text for an overview of the wizard's features.
   
   
   2. Click Next.
   
   
   
   


2. JAR File Contents dialog box
   
   
   
   1. In the combo box, select ConverterApp.
   
   
   2. Click Edit.
   
   
   3. In the tree under Available Files, locate the j2eetutorial/examples/build/ejb/converter directory.
   
   
   4. Select the ConverterClient.class file and click Add.
   
   
   5. Click OK.
   
   
   6. Click Next.
   
   
   
   


3. General dialog box
   
   
   
   1. In the Main Class combo box, select ConverterClient.
   
   
   2. Verify that the entry in the Display Name field is ConverterClient.
   
   
   3. In the Callback Handler Class combo box, select container-managed authentication.
   
   
   4. Click Next.
   
   
   5. Click Finish.
   
   
   
   

Specifying the Application Client's Enterprise Bean Reference

When it invokes the lookup method, the ConverterClient refers to the home of an enterprise bean:

Object objref = myEnv.lookup("ejb/SimpleConverter");

You specify this reference as follows.

1. In the tree, select ConverterClient.


2. Select the EJB Refs tab.


3. Click Add.


4. In the Coded Name column, enter ejb/SimpleConverter.


5. In the Type column, select Session.


6. In the Interfaces column, select Remote.


7. In the Home Interface column, enter ConverterHome.


8. In the Local/Remote Interface column, enter Converter.

iZoom

iZoom is a simple application designed to allow you to easily resize and crop your photos for optimized display on your iPod photo, on the web, or in email messages to friends. Built using Java, iZoom is available for Mac OS X, Linux, and Windows. Currently, JPEG is the only supported image format.

J2EE Tutorial-9(Creating the Enterprise Bean)

An enterprise bean is a server-side component that contains the business logic of an application. At runtime, the application clients execute the business logic by invoking the enterprise bean's methods. The enterprise bean in our example is a stateless session bean called ConverterEJB. The source code for ConverterEJB is in thej2eetutorial/examples/src/ejb/converter directory.

Coding the Enterprise Bean

The enterprise bean in this example requires the following code:

• Remote interface


• Home interface


• Enterprise bean class

Coding the Remote Interface

A remote interface defines the business methods that a client may call. The business methods are implemented in the enterprise bean code. The source code for the Converter remote interface follows.

import javax.ejb.EJBObject;
import java.rmi.RemoteException;
import java.math.*;

public interface Converter extends EJBObject {
   public BigDecimal dollarToYen(BigDecimal dollars) 
      throws RemoteException;
   public BigDecimal yenToEuro(BigDecimal yen) 
      throws RemoteException;
}

Coding the Home Interface

A home interface defines the methods that allow a client to create, find, or remove an enterprise bean. The ConverterHome interface contains a single create method, which returns an object of the remote interface type. Here is the source code for the ConverterHome interface:

import java.io.Serializable;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;

public interface ConverterHome extends EJBHome {
   Converter create() throws RemoteException, CreateException;
}

Coding the Enterprise Bean Class

The enterprise bean class for this example is called ConverterBean. This class implements the two business methods, dollarToYen and yenToEuro, that the Converter remote interface defines. The source code for the ConverterBean class follows.

import java.rmi.RemoteException; 
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import java.math.*;

public class ConverterBean implements SessionBean {

   BigDecimal yenRate = new BigDecimal("121.6000");
   BigDecimal euroRate = new BigDecimal("0.0077");

   public BigDecimal dollarToYen(BigDecimal dollars) {
      BigDecimal result = dollars.multiply(yenRate);
      return result.setScale(2,BigDecimal.ROUND_UP);
   }   public BigDecimal yenToEuro(BigDecimal yen) {
      BigDecimal result = yen.multiply(euroRate);
      return result.setScale(2,BigDecimal.ROUND_UP);
   }   public ConverterBean() {}
   public void ejbCreate() {}
   public void ejbRemove() {}
   public void ejbActivate() {}
   public void ejbPassivate() {}
   public void setSessionContext(SessionContext sc) {}
}

Compiling the Source Files

Now you are ready to compile the remote interface (Converter.java), home interface (ConverterHome.java), and the enterprise bean class (ConverterBean.java).

1. In a terminal window, go to the j2eetutorial/examples directory.


2. Type the following command:
   

   
   

      ant converter
   

   
   

   
   

This command compiles the source files for the enterprise bean and the J2EE application client. It places the resulting class files in thej2eetutorial/examples/build/ejb/converter directory (not the src directory). For more information about ant, see How to Build and Run the Examples.

---

Note: When compiling the code, the preceding ant task includes the j2ee.jar file in the classpath. This file resides in the lib directory of your J2EE SDK installation. If you plan on using other tools to compile the source code for J2EE components, make sure that the classpath includes the j2ee.jar file.

---

Packaging the Enterprise Bean

To package an enterprise bean, you run the New Enterprise Bean wizard of the deploytool utility. During this process, the wizard performs the following tasks:

• Creates the bean's deployment descriptor


• Packages the deployment descriptor and the bean's classes in an EJB JAR file


• Inserts the EJB JAR file into the application's ConverterApp.ear file

After the packaging process, you can view the deployment descriptor by selecting ToolsDescriptor Viewer.

To start the New Enterprise Bean wizard, select FileNewEnterprise Bean. The wizard displays the following dialog boxes.

1. Introduction dialog box
   
   
   
   1. Read the explanatory text for an overview of the wizard's features.
   
   
   2. Click Next.
   
   
   
   


2. EJB JAR dialog box
   
   
   
   1. Select the Create New JAR File In Application button.
   
   
   2. In the combo box, select ConverterApp.
   
   
   3. In the JAR Display Name field, enter ConverterJAR.
   
   
   4. Click Edit.
   
   
   5. In the tree under Available Files, locate the j2eetutorial/examples/build/ejb/converter directory. (If the converter directory is many levels down in the tree, you can simplify the tree view by entering all or part of the converter directory's path name in the Starting Directory field.)
   
   
   6. Select the following classes from the Available Files tree and click Add: Converter.class, ConverterBean.class, and ConverterHome.class. (You may also drag and drop these class files to the Contents text area.)
   
   
   7. Click OK.
   
   
   8. Click Next.
   
   
   
   


3. General dialog box
   
   
   
   1. Under Bean Type, select the Session radio button.
   
   
   2. Select the Stateless radio button.
   
   
   3. In the Enterprise Bean Class combo box, select ConverterBean.
   
   
   4. In the Enterprise Bean Name field, enter ConverterEJB.
   
   
   5. In the Remote Home Interface combo box, select ConverterHome.
   
   
   6. In the Remote Interface combo box, select Converter.
   
   
   7. Click Next.
   
   
   
   


4. Transaction Management dialog box
   
   
   
   1. Because you may skip the remaining dialog boxes, click Finish.
   
   
   
   

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-7 (Setting up Environment)

Before you start developing the example application, you should follow the instructions in this section.

Getting the Example Code

The source code for the components is in j2eetutorial/examples/src/ejb/converter, a directory that is created when you unzip the tutorial bundle. If you are viewing this tutorial online, you need to download the tutorial bundle from

http://java.sun.com/j2ee/download.html#tutorial 

Getting the Build Tool (ant)

To build the example code, you'll need installations of the J2EE SDK and ant, a portable make tool. For more information, see the section How to Build and Run the Examples.

Checking the Environment Variables

The installation instructions for the J2EE SDK and ant explain how to set the required environment variables. Verify that the environment variables have been set to the values noted inTable 2-1.

 

Table 2-1 Required Environment Variables

Environment Variable	Value
JAVA_HOME	The location of the J2SE SDK installation
J2EE_HOME	The location of the J2EE SDK installation
ANT_HOME	The location of the ant installation
PATH	Should include the bin directories of the J2EE SDK, J2SE, and ant installations

 

Starting the J2EE Server

To launch the J2EE server, open a terminal window and type this command:

j2ee -verbose

Although not required, the verbose option is useful for debugging.

To stop the server, type the following command:

j2ee -stop

Starting the deploytool

The deploytool utility has two modes: command line and GUI. The instructions in this chapter refer to the GUI version. To start the deploytool GUI, open a terminal window and type this command:

deploytool

J2EE Tutorial-6 (Reference Implementation Software)

The J2EE SDK is a noncommercial operational definition of the J2EE platform and specification made freely available by Sun Microsystems for demonstrations, prototyping, and educational use. It comes with the J2EE application server, Web server, relational database, J2EE APIs, and complete set of development and deployment tools. You can download the J2EE SDK from

http://java.sun.com/j2ee/download.html#sdk 

The purpose of the J2EE SDK is to allow product providers to determine what their implementations must do under a given set of application conditions, and to run the J2EE Compatibility Test Suite to test that their J2EE products fully comply with the specification. It also allows application component developers to run their J2EE applications on the J2EE SDK to verify that applications are fully portable across all J2EE products and tools.

Database Access

The relational database provides persistent storage for application data. A J2EE implementation is not required to support a particular type of database, which means that the database supported by different J2EE products can vary. See the Release Notes included with the J2EE SDK download for a list of the databases currently supported by the reference implementation.

J2EE APIs

The Java 2 Platform, Standard Edition (J2SE) SDK is required to run the J2EE SDK and provides core APIs for writing J2EE components, core development tools, and the Java virtual machine. The J2EE SDK provides the following APIs to be used in J2EE applications.

Enterprise JavaBeans Technology 2.0

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 J2EE server.

There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. Enterprise beans often interact with databases. One of the benefits of entity beans is that you do not have to write any SQL code or use the JDBC API directly to perform database access operations; 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.

JDBC API 2.0

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 J2EE platform.

Java Servlet Technology 2.3

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.

JavaServer Pages Technology 1.2

JavaServer Pages technology lets you put snippets of servlet code directly into 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, which determine how the page constructs dynamic content.

Java Message Service 1.0

The JMS is a messaging standard that allows J2EE 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 online Java Message Service Tutorial:

http://java.sun.com/products/jms/tutorial/index.html 

Java Naming and Directory Interface 1.2

The JNDI provides naming and directory functionality. It provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Using JNDI, a J2EE application can store and retrieve any type of named Java object.

Because JNDI is independent of any specific implementations, applications can use JNDI to access multiple naming and directory services, including existing naming and directory services such as LDAP, NDS, DNS, and NIS. This allows J2EE applications to coexist with legacy applications and systems. For more information on JNDI, see the online JNDI Tutorial:

http://java.sun.com/products/jndi/tutorial/index.html 

Java Transaction API 1.0

The Java Transaction API ("JTA") provides a standard interface for demarcating transactions. The J2EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that 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.

JavaMail API 1.2

J2EE applications can use the JavaMail API to send e-mail notifications. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface. The J2EE platform includes JavaMail with a service provider that allows application components to send Internet mail.

JavaBeans Activation Framework 1.0

The JavaBeans Activation Framework ("JAF") 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 JavaBeans component to perform those operations.

Java API for XML Processing 1.1

XML is a language for representing text-based data so the data can be read and handled by any program or tool. Programs and tools can generate XML documents that other programs and tools can read and handle. The Java API for XML Processing ("JAXP") supports processing of XML documents using DOM, SAX, and XSLT. JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation.

For example, a J2EE 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 J2EE application for processing.

J2EE Connector Architecture 1.0

The J2EE Connector architecture is used by J2EE tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any J2EE product. A resource adapter is a software component that allows J2EE 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 enterprise information system.

Java Authentication and Authorization Service 1.0

The Java Authentication and Authorization Service ("JAAS") provides a way for a J2EE 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.

Simplified Systems Integration

The J2EE platform is a platform-independent, full systems integration solution that creates an open marketplace in which every vendor can sell to every customer. Such a marketplace encourages vendors to compete, not by trying to lock customers into their technologies but by trying to outdo each other by providing products and services that benefit customers, such as better performance, better tools, or better customer support.

The J2EE APIs enable systems and applications integration through the following:

• Unified application model across tiers with enterprise beans


• Simplified response and request mechanism with JSP pages and servlets


• Reliable security model with JAAS


• XML-based data interchange integration with JAXP


• Simplified interoperability with the J2EE Connector Architecture


• Easy database connectivity with the JDBC API


• Enterprise application integration with message-driven beans and JMS, JTA, and JNDI

You can learn more about using the J2EE platform to build integrated business systems by reading J2EE Technology in Practice.

Tools

The J2EE reference implementation provides an application deployment tool and an array of scripts for assembling, verifying, and deploying J2EE applications and managing your development and production environments. See Appendix B for a discussion of the tools.

Application Deployment Tool

The J2EE reference implementation provides an application deployment tool (deploytool) for assembling, verifying, and deploying J2EE applications. There are two versions: command line and GUI.

The GUI tool includes wizards for:

• Packaging, configuring, and deploying J2EE applications


• Packaging and configuring enterprise beans


• Packaging and configuring Web components


• Packaging and configuring application clients


• Packaging and configuring resource adaptors

In addition, configuration information can be set for each component and module type in the tabbed inspector panes.

Scripts

Table 1-1 lists the scripts included with the J2EE reference implementation that let you perform operations from the command line.



 

Table 1-1 J2EE Scripts 

Script	Description
j2ee	Start and stop the J2EE server
cloudscape	Start and stop the default database
j2eeadmin	Add JDBC drivers, JMS destinations, and connection factories for various resources
keytool	Create public and private keys and generate X509 self-signed certificate
realmtool	Import certificate files, add J2EE users to and remove J2EE users from the authentication and authorization list for a J2EE application
packager	Package J2EE 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 J2EE specification
runclient	Run a J2EE application client
cleanup	Remove all deployed applications from 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.

J2EE Tutorial-3 (J2EE Components)

J2EE Components

J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components:

• Application clients and applets are components that run on the client.


• Java Servlet and JavaServer Pages (JSP) technology components are Web components that run on the server.


• Enterprise JavaBeans (EJB) components (enterprise beans) are business components that run on the server.

J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and "standard" Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server.

J2EE Clients

A J2EE client can be a Web client or an application client.

Web Clients

A Web client consists of two parts: dynamic Web pages containing various types of markup language (HTML, XML, and so on), which are generated by Web components running in the Web tier, and a Web browser, which renders the pages received from the server.

A Web client is sometimes called a thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, heavyweight operations like these are off-loaded to enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.

Applets

A Web page received 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 virtual machine installed in the Web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file in order for the applet to successfully execute in the Web browser.

Web components are the preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Also, Web components enable cleaner and more modular application design because they provide a way to separate applications programming from Web page design. Personnel involved in Web page design thus do not need to understand Java programming language syntax to do their jobs.

Application Clients

A J2EE application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from 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 application requirements warrant it, a J2EE application client can open an HTTP connection to establish communication with a servlet running in the Web tier.

JavaBeans Component Architecture

The server and client tiers might also include components based on the JavaBeans component architecture (JavaBeans component) to manage the data flow between an application client or applet and components running on the J2EE server or between server components and a database. JavaBeans components are not considered J2EE components by the J2EE specification.

JavaBeans components 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.

J2EE Server Communications

Figure 1-2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the J2EE 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.

Your J2EE application uses a thin browser-based client or thick application client. In deciding which one to use, you should be aware of the trade-offs between keeping functionality on the client and close to the user (thick client) and off-loading as much functionality as possible to the server (thin client). The more functionality you off-load to the server, the easier it is to distribute, deploy, and manage the application; however, keeping more functionality on the client can make for a better perceived user experience.

 

Figure 1-2 Server Communications

Web Components

J2EE Web components can be either servlets or JSP pages. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content.

Static HTML pages and applets are bundled with Web components during application assembly, but are not considered Web components by the J2EE 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 1-3, the Web tier might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.

Business Components

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 1-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.

 

Figure 1-3 Web Tier and J2EE Application

 

Figure 1-4 Business and EIS Tiers

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 that 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 tutorial describes entity beans and session beans. For information on message-driven beans, see The Java Message Service Tutorial, available at

http://java.sun.com/products/jms/tutorial/index.html 

Enterprise Information System Tier

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. J2EE application components might need access to enterprise information systems for database connectivity, for example.

J2EE Tutorial -1 (overview)

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, with greater speed, and with fewer resources than ever before.

To reduce costs and fast-track enterprise application design and development, the Java 2 Platform, Enterprise Edition (J2EE) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multitiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, 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 J2EE component-based solutions are not tied to the products and application programming interfaces (APIs) of any one vendor. Vendors and customers enjoy the freedom to choose the products and components that best meet their business and technological requirements.

This tutorial takes an examples-based approach to describing the features and functionalities available in J2EE Software Development Kit (SDK) version 1.3. Whether you are a new or an experienced enterprise developer, you should find the examples and accompanying text a valuable and accessible knowledge base for creating your own enterprise solutions.

If you are new to J2EE applications development, this chapter is a good place to start. Here you will learn the J2EE architecture, become acquainted with important terms and concepts, and find out how to approach J2EE application programming, assembly, and deployment.

Secrets Of The Masters: Core Java Job Interview Questions

30 Java Interview Questions

* Q1. How could Java classes direct program messages to the system console, but error messages, say to a file?

A. The class System has a variable out that represents the standard output, and the variable errthat represents the standard error device. By default, they both point at the system console. This how the standard output could be re-directed:

Stream st = new Stream(new FileOutputStream("output.txt")); System.setErr(st); System.setOut(st);

* Q2. What's the difference between an interface and an abstract class?

A. An abstract class may contain code in method bodies, which is not allowed in an interface. With abstract classes, you have to inherit your class from it and Java does not allow multiple inheritance. On the other hand, you can implement multiple interfaces in your class.

* Q3. Why would you use a synchronized block vs. synchronized method?

A. Synchronized blocks place locks for shorter periods than synchronized methods.

* Q4. Explain the usage of the keyword transient?

A. This keyword indicates that the value of this member variable does not have to be serialized with the object. When the class will be de-serialized, this variable will be initialized with a default value of its data type (i.e. zero for integers).

* Q5. How can you force garbage collection?

A. You can't force GC, but could request it by calling System.gc(). JVM does not guarantee that GC will be started immediately.

* Q6. How do you know if an explicit object casting is needed?

A. If you assign a superclass object to a variable of a subclass's data type, you need to do explicit casting. For example:

Object a; Customer b; b = (Customer) a;

When you assign a subclass to a variable having a supeclass type, the casting is performed automatically.

* Q7. What's the difference between the methods sleep() and wait()

A. The code sleep(1000); puts thread aside for exactly one second. The codewait(1000), causes a wait of up to one second. A thread could stop waiting earlier if it receives the notify() or notifyAll() call. The method wait() is defined in the class Object and the method sleep() is defined in the class Thread.

* Q8. Can you write a Java class that could be used both as an applet as well as an application?

A. Yes. Add a main() method to the applet.

* Q9. What's the difference between constructors and other methods?

A. Constructors must have the same name as the class and can not return a value. They are only called once while regular methods could be called many times.

* Q10. Can you call one constructor from another if a class has multiple constructors

A. Yes. Use this() syntax.

* Q11. Explain the usage of Java packages.

A. This is a way to organize files when a project consists of multiple modules. It also helps resolve naming conflicts when different packages have classes with the same names. Packages access level also allows you to protect data from being used by the non-authorized classes.

* Q12. If a class is located in a package, what do you need to change in the OS environment to be able to use it?

A. You need to add a directory or a jar file that contains the package directories to the CLASSPATH environment variable. Let's say a class Employee belongs to a package com.xyz.hr; and is located in the file c:\dev\com\xyz\hr\Employee.java. In this case, you'd need to add c:\dev to the variable CLASSPATH. If this class contains the method main(), you could test it from a command prompt window as follows:

c:\>java com.xyz.hr.Employee

* Q13. What's the difference between J2SDK 1.5 and J2SDK 5.0?

A.There's no difference, Sun Microsystems just re-branded this version.

* Q14. What would you use to compare two String variables - the operator == or the method equals()?

A. I'd use the method equals() to compare the values of the Strings and the == to check if two variables point at the same instance of a String object.

* Q15. Does it matter in what order catch statements for FileNotFoundException and IOExceptipon are written?

A. Yes, it does. The FileNoFoundException is inherited from the IOException. Exception's subclasses have to be caught first.

* Q16. Can an inner class declared inside of a method access local variables of this method?

A. It's possible if these variables are final.

* Q17. What can go wrong if you replace && with & in the following code:

String a=null; if (a!=null && a.length()>10) {...}

A. A single ampersand here would lead to a NullPointerException.

* Q18. What's the main difference between a Vector and an ArrayList

A. Java Vector class is internally synchronized and ArrayList is not.

* Q19. When should the method invokeLater()be used?

A. This method is used to ensure that Swing components are updated through the event-dispatching thread.

* Q20. How can a subclass call a method or a constructor defined in a superclass?

A. Use the following syntax: super.myMethod(); To call a constructor of the superclass, just write super(); in the first line of the subclass's constructor.

For senior-level developers:

** Q21. What's the difference between a queue and a stack?

A. Stacks works by last-in-first-out rule (LIFO), while queues use the FIFO rule

** Q22. You can create an abstract class that contains only abstract methods. On the other hand, you can create an interface that declares the same methods. So can you use abstract classes instead of interfaces?

A. Sometimes. But your class may be a descendent of another class and in this case the interface is your only option.

** Q23. What comes to mind when you hear about a young generation in Java?

A. Garbage collection.

** Q24. What comes to mind when someone mentions a shallow copy in Java?

A. Object cloning.

** Q25. If you're overriding the method equals() of an object, which other method you might also consider?

A. hashCode()

** Q26. You are planning to do an indexed search in a list of objects. Which of the two Java collections should you use:
ArrayList or LinkedList?

A. ArrayList

** Q27. How would you make a copy of an entire Java object with its state?

A. Have this class implement Cloneable interface and call its method clone().

** Q28. How can you minimize the need of garbage collection and make the memory use more effective?

A. Use object pooling and weak object references.

** Q29. There are two classes: A and B. The class B need to inform a class A when some important event has happened. What Java technique would you use to implement it?

A. If these classes are threads I'd consider notify() or notifyAll(). For regular classes you can use the Observer interface.

** Q30. What access level do you need to specify in the class declaration to ensure that only classes from the same directory can access it?

A. You do not need to specify any access level, and Java will use a default package access level.

Receiving mail with attachment using javamail API

import java.util.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.activation.*;
import java.io.*;

class ReadAttachment{
public static void main(String [] args)throws Exception{

String host="mail.javatpoint.com";
final String user="sonoojaiswal@javatpoint.com";
final String password="xxxxx";//change accordingly

Properties properties = System.getProperties();
properties.setProperty("mail.smtp.host",host );
properties.put("mail.smtp.auth", "true");

Session session = Session.getDefaultInstance(properties,
new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user,password);
}
});

Store store = session.getStore("pop3");
store.connect(host,user,password);

Folder folder = store.getFolder("inbox");
folder.open(Folder.READ_WRITE);

Message[] message = folder.getMessages();
for (int a = 0; a < message.length; a++) {
System.out.println("-------------" + (a + 1) + "-----------");
System.out.println(message[a].getSentDate());

Multipart multipart = (Multipart) message[a].getContent();

for (int i = 0; i < multipart.getCount(); i++) {
BodyPart bodyPart = multipart.getBodyPart(i);
InputStream stream = bodyPart.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(stream));

while (br.ready()) {
System.out.println(br.readLine());
}
System.out.println();
}
System.out.println();
}

folder.close(true);
store.close();
}
}

LOAD THE JAR FILE :  C:\> set classpath=mail.jar;activation.jar;

COMPILE THE SOURCE FILE: C:\> javac ReadAttachment.java

RUN BY :C:\> java ReadAttachment

what is difference between JDK and JRE and JVM ???

JDK (Java Development Kit)

Java Developer Kit contains tools needed to develop the Java programs, and JRE to run the programs. The tools include compiler (javac.exe), Java application launcher (java.exe), Appletviewer, etc…

Compiler converts java code into byte code. Java application launcher opens a JRE, loads the class, and invokes its main method.

You need JDK, if at all you want to write your own programs, and to compile the m. For running java programs, JRE is sufficient.

JRE is targeted for execution of Java files

i.e. JRE = JVM + Java Packages Classes(like util, math, lang, awt,swing etc)+runtime libraries.

JDK is mainly targeted for java development. I.e. You can create a Java file (with the help of Java packages), compile a Java file and run a java file

JRE (Java Runtime Environment)

Java Runtime Environment contains JVM, class libraries, and other supporting files. It does not contain any development tools such as compiler, debugger, etc. Actually JVM runs the program, and it uses the class libraries, and other supporting files provided in JRE. If you want to run any java program, you need to have JRE installed in the system

The Java Virtual Machine provides a platform-independent way of executing code; programmers can concentrate on writing software, without having to be concerned with how or where it will run.

If u just want to run applets (ex: Online Yahoo games or puzzles), JRE needs to be installed on the machine.

JVM (Java Virtual Machine)

As we all aware when we compile a Java file, output is not an 'exe' but it's a '.class' file. '.class' file consists of Java byte codes which are understandable by JVM. Java Virtual Machine interprets the byte code into the machine code depending upon the underlying operating system and hardware combination. It is responsible for all the things like garbage collection, array bounds checking, etc… JVM is platform dependent.

The JVM is called "virtual" because it provides a machine interface that does not depend on the underlying operating system and machine hardware architecture. This independence from hardware and operating system is a cornerstone of the write-once run-anywhere value of Java programs.

There are different JVM implementations are there. These may differ in things like performance, reliability, speed, etc. These implementations will differ in those areas where Java specification doesn’t mention how to implement the features, like how the garbage collection process works is JVM dependent, Java spec doesn’t define any specific way to do this.

Apple's Tim Cook wins where Steve Jobs failed: On Java

Tim Cook has pulled a startling coup, getting Larry Ellison to start cooking -- if not eating -- his own dog food.

The headlines make it sound like Oracle, the inherited owner of Java, has generously stepped in to help protect Mac owners from infections like Flashback. There's an important backstory, though, that hasn't hit the headlines.

Although Steve Jobs tried for years to get out from under the Java ball and chain, last week Tim Cook finally coerced Oracle into supplying updates for its own software. It only took 700,000 infected systems to convince Oracle to handle Java on OS X itself.

Steve Jobs dropped Java for the Mac in October 2010, removing it as part of the standard OS X install. The Mac OS X Developer Library post for Oct. 20, says, "The Java runtime ported by Apple and that ships with Mac OS X is deprecated. Developers should not rely on the Apple-supplied Java runtime being present in future versions of Mac OS X." At the same time, Apple stopped accepting apps for the Mac App Store that relied on the Java Runtime Environment. Apple had never supported Java clients in its iOS.

On Oct. 21, 2010, the MacRumors forum said that Jobs replied to a concerned Java developer, claiming, "Sun (now Oracle) supplies Java for all other platforms. They have their own release schedules, which are almost always different than ours, so the Java we ship is always a version behind. This may not be the best way to do it."

Of course, Jobs knew at the time he was blowing smoke -- or perhaps a reality distortion field set in. With a few notable exceptions, Java's owner has never supplied versions "for all other platforms." Back when Java started, Sun supplied a version of the runtime for Linux because, as the "father of Java" James Gosling says, "there was no one else to do it." Every other distributor -- Microsoft, IBM, Hewlett-Packard, and Apple -- rolled its own version, based on Sun's reference code.

Java 1.0 for Mac OS 9 was released in 1996, the year Apple bought NeXT and Jobs returned to the Apple fold. Jobs knew full well that Apple was developing its own version of Java, just like all the other platform providers.

Microsoft started taking its version of Java far afield, adding its own extensions to the language, and Sun sued in 1997 to get its trademark back. A bitter, extended, and very public court battle ended in January 2001, with Microsoft paying Sun $20 million for its transgressions and Sun taking control of Java updates. Until this last week, Sun had released Java versions only for Linux and Windows. All the other platforms made their own.

The fact is that Jobs had been trying for years to get Sun, then Oracle, to take over Java releases for OS X. Back in 2007, Jobs is quoted as saying, "Java's not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain." In 2010, when Jobs dropped Java like a hot cup of coffee, he tried to shame Oracle into supporting it. Since then, Java's been a neglected stepchild in the Mac world, completely shunned in iOS.

As Gosling says, "In the early days, they [Apple] were insistent on doing the port themselves. They put terrific energy into it. They did a good job. But then, as OS X took hold and Apple was able to convince developers to target their nonportable/proprietary environment, Apple's fundamental control-freak tendency took over and they put less and less energy into Java."

Oracle is now distributing Java SE 7 Update 4 for Mac OS X, and that will become the default version on Java.com starting May 1. Henrik Stahl, senior director of Java product management at Oracle, says, "Oracle's JDK and JavaFX release supports OS X Lion on any 64-bit capable Intel-based Mac. ... There are community efforts based on OpenJDK to build JDK 7 [and JVM on 32-bit machines] for other configurations, easily found using your favorite search engine. We applaud these efforts! :-)"

Oracle has announced full plans to embrace OS X Lion and later with new updates to the Java Standard Edition and Java Development Kit. (The JDK includes the Java Runtime Environment, JRE, which in turn includes the Java Virtual Machine, JVM. And you thought Microsoft's terminology was confusing!)

It's not clear if Oracle will be updating the Java runtime for earlier versions of OS X. That's particularly troubling because Dr. Web, the site that originally broke the story on the Flashback infections, now says that 25 percent of all Flashback infections come from Macs running OS X 10.5 Leopard, and 63 percent more are from OS X 10.6 Snow Leopard. Only 12 percent of all infections are in OS X 10.7 Lion, and those are the only machines that will be patched with Oracle's Java SE 7 Update 4. Leopard and Snow Leopard users are left to the "community efforts." If either Apple or Oracle is concerned about the hundreds of thousands of customers left swinging in the wind, there's no indication I can find.

In contrast, Apple's two recent Java patches covered Lion and Snow Leopard. They didn't cover Leopard.

It seems that Jobs' desires have finally been fulfilled, with the Java monkey now on Oracle's back. Cook was at the helm -- perhaps actively involved? -- when it happened. Apple's now able to wash its hands of all Java's faults going forward. Oracle has responsibility for its own product. All it took was 700,000 infections.

This story, "Apple's Tim Cook wins where Steve Jobs failed: On Java," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.