The J2EE specification attempts to fill the gaps between the web components and Enterprise JavaBeans by defining how these technologies come together to form a complete platform. One of the ways in which J2EE adds value is by creating a consistent programming model across web components and enterprise beans through the use of the JNDI ENC and XML deployment descriptors. A servlet in J2EE can access JDBC DataSource objects, environment entries, and references to enterprise beans through a JNDI ENC in exactly the same way that enterprise beans use the JNDI ENC. To support the JNDI ENC, web components have their own XML deployment descriptor that declares elements for the JNDI ENC (<ejb-ref>, <resource-ref>, <env-entry>) as well as security roles and other elements specific to web components. In J2EE, web components are packaged along with their XML deployment descriptors and deployed in JAR files with the extension .war, which stands for web archive. A .war file can contain several servlets and JSP documents that share an XML deployment descriptor. The use of the JNDI ENC, deployment descriptors, and JAR files in web components makes them consistent with the EJB programming model and unifies the entire J2EE platform.

Use of the JNDI ENC makes it much simpler for web components to access Enterprise JavaBeans. The web component developer does not need to be concerned with the network location of enterprise beans; the server will map the <ejb-ref> elements listed in the deployment descriptor to the enterprise beans at deployment time.

Optionally, J2EE vendors can allow web components to access the EJB local component interfaces of enterprise beans. This strategy makes a lot of sense if the web component and the bean are located in the same Java Virtual Machine, because the Java RMI-IIOP semantics can improve performance. It’s expected that most J2EE vendors will support this option.

The JNDI ENC also supports access to a javax.jta.UserTransaction object, as is the case in EJB. The UserTransaction object allows the web component to manage transactions explicitly. The transaction context must be propagated to any enterprise beans accessed within the scope of the transaction (according to the transaction attribute of the enterprise bean method). J2EE also defines an .ear file (enterprise archive), which is a JAR file for packaging EJB JAR files and web component JAR files (.war files) together into one complete deployment, called a J2EE application. A J2EE application has its own XML deployment descriptor that points to the EJB and web component JAR files (called modules) as well as other elements such as icons, descriptions, and the like. When a J2EE application is created, interdependencies such as <ejb-ref> and <ejb-local-ref> elements can be resolved and security roles can be edited to provide a unified view of the entire web application. Figure 17-3 illustrates the file structure of a J2EE archive file.

Figure 17-3. Contents of a J2EE .ear file

J2EE Application Client Components

In addition to integrating web and enterprise bean components, J2EE introduces a new component model: the application client component. An application client component is a Java application that resides on a client machine and accesses enterprise bean components on the J2EE server. Client components also have access to a JNDI ENC that operates the same way as the JNDI ENC for web and enterprise bean components. The client component includes an XML deployment descriptor that declares the <env-entry>, <ejb-ref>, and <resource-ref> elements of the JNDI ENC in addition to a <description>, <display-name>, and <icon> that can be used to represent the component in a deployment tool.

A client component is simply a Java program that uses the JNDI ENC to access environment properties, enterprise beans, and resources (JDBC, JavaMail, and so on) made available by the J2EE server. Client components reside on the client machine, not the J2EE server. Here is an extremely simple component:

public class MyJ2eeClient {
    
    public static void main(String [] args) {
        
        InitialContext jndiCntx = new InitialContext( );
        
        Object ref = jndiCntx.lookup("java:comp/env/ejb/ShipBean");
        ShipHome home = (ShipHome)
            PortableRemoteObject.narrow(ref,ShipHome.class);
        
        Ship ship = home.findByPrimaryKey(new ShipPK(1));
        String name = ship.getName( );
        System.out.println(name);

    }
}

MyJ2eeClient illustrates how a client component is written. Notice that the client component did not need to use a network-specific JNDI InitialContext. In other words, we did not have to specify the service provider in order to connect to the J2EE server. This is the real power of the J2EE application client component: location transparency. The client component does not need to know the exact location of the Ship EJB or choose a specific JNDI service provider; the JNDI ENC takes care of locating the enterprise bean.

When application components are developed, an XML deployment descriptor is created that specifies the JNDI ENC entries. At deployment time, a vendor-specific J2EE tool generates the class files needed to deploy the component on client machines. A client component is packaged into a JAR file with its XML deployment descriptor and can be included in a J2EE application. Once a client component is included in the J2EE application deployment descriptor, it can be packaged in the .ear file with the other components, as Figure 17-4 illustrates.

Figure 17-4. Contents of a J2EE .ear file with application component