J2EE Fills in the Gaps (Enterprise JavaBeans)

11.4. J2EE Fills in the Gaps

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 security roles and other elements specific to web components. In J2EE, web components (Servlets and JSP pages) along with their XML deployment descriptors, are packaged and deployed in JAR files with the extension .war, which stands for web ar chive. 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. Here is a simple deployment descriptor for a web component:

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_1_2.dtd">
<web-app>
  <servlet>
    <servlet-name> HelloWorld </servlet-name>
    <servlet-class> HelloWorld.class </servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name> HelloWorld </servlet-name>
    <url-pattern> /HelloWorld.jsp </url-pattern>
  </servlet-mapping>
  <session-config>
    <session-timeout>1</session-timeout>
  </session-config>
  <ejb-ref>
      <ejb-ref-name>ejb/ShipBean</ejb-ref-name>
      <ejb-ref-type>Entity</ejb-ref-type>
      <home>com.titan.ship.ShipBean</home>
      <remote>com.titan.ship.Ship</remote>
  </ejb-ref>
</web-app>

Use of the JNDI ENC makes it much simpler for web components to access Enterprise JavaBeans. The web component developer doesn't need to be concerned with the network location of beans; the server will map the ejb-ref elements listed in the deployment descriptor to the beans at deployment time. 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 bean method). A .war file can contain several servlets and JSP documents, which share an XML deployment descriptor.

J2EE also defines an .ear(Enterprise archive) file, which is a JAR file for packaging Enterprise JavaBean 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 like icons, descriptions, and the like. When a J2EE Application is created, interdependencies like ejb-ref elements can be resolved and security roles can be edited to provide a unified view of the entire web application. Here is a simple application deployment descriptor:

<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTDJ2EE Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">

<application>
   <display-name>MyApplication</display-name>
   <module>
     <ejb> 
        shipbean.jar
     </ejb>
   </module>
   <module>
     <web>
        <web-uri>
          helloworld.war
        </web-uri>
     </web>
   </module>
   <security-role>
      <role-name>Admistrator</role-name>
   </security-role>
</application>

The J2EE Enterprise Archive (.ear) file would contain the EJB JAR files and the web component .war files. Figure 11-3 illustrates the file structure inside a J2EE archive file.

Figure 11-3. Contents of a J2EE EAR file

11.4.1. J2EE Application Client Components

In addition to integrating web and enterprise bean components, J2EE introduces a completely 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 also 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 client 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, etc.) 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 bean or choose a specific JNDI service provider; the JNDI ENC takes this care of locating the 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. The following code shows the deployment descriptor used by the MyJ2eeClient client component:

<!DOCTYPE application-client PUBLIC "-//Sun Microsystems,
Inc.//DTD J2EE Application Client 1.2//EN" "http://
java.sun.com/j2ee/dtds/application-client_1_2.dtd">

<application-client>
  <display-name>MyClient</display-name>
  <ejb-ref>
      <ejb-ref-name>ejb/ShipBean</ejb-ref-name>
      <ejb-ref-type>Entity</ejb-ref-type>
      <home>com.titan.ship.ShipHome</home>
      <remote>com.titan.ship.Ship</remote>
  </ejb-ref>
</application-client>

A client component is packaged into a JAR file with its XML deployment descriptor and can be included in a J2EE Application. The following application deployment descriptor shows how the client component is declared:

<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTDJ2EE
Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">

<application>
   <display-name>MyApplication</display-name>
   <module>
     <ejb> 
        shipbean.jar
     </ejb>
   </module>
   <module>
     <web>
        <web-uri>
          helloworld.war
        </web-uri>
     </web>
   </module>
   <module>
     <java>
        myclient.jar
     </java>
   </module>
   <security-role>
      <role-name>Admistrator</role-name>
   </security-role>
</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 11-4 illustrates.

Figure 11-4. Contents of a J2EE EAR file with Application component

J2EE's application client component specification doesn't cover authentication, but it does require that client components authenticate (log in) before accessing any beans. This omission makes it difficult to develop truly portable client components because different vendors will require different authentication mechanisms. In a future version of the J2EE specification, client components may be required to use the Java Authentication and Authorization Service ( JAAS), which would provide a consistent authorization mechanism across different implementations.

11.4.2. Guaranteed Services

The J2EE specification requires application servers to support a specific set of protocols and Java enterprise extensions. This ensures a consistent platform for deploying J2EE applications. J2EE application servers must provide the following "standard" services:

Enterprise JavaBeans 1.1: J2EE products must support the complete specification.
Servlets 2.2: J2EE products must support the complete specification.
Java Sever Pages 1.1: J2EE products must support the complete specification.
HTTP and HTTPS: Web components in a J2EE server service both HTTP and HTTPS requests. The Servlets specification itself only requires support for HTTP. The J2EE product must be capable of advertising HTTP 1.0 and HTTPS (HTTP 1.0 over SSL 3.0) on ports 80 and 443 respectively.
Java RMI-IIOP 1.0: As was the case with EJB 1.1, only the semantics of Java RMI-IIOP are required; the underlying protocol need not be IIOP. Therefore, components must use return and parameter types that are compatible with IIOP, and must use the PortableRemoteObject.narrow( ) method.
JavaIDL: Web components and enterprise beans must be able to access CORBA services hosted outside the J2EE environment using JavaIDL, a standard part of the Java 2 platform.
JDBC 2.0: J2EE requires support for the JDBC 2.0 Standard Extension, but not the JDBC 2.0 Optional Package.
JNDI 1.2: Web and enterprise bean components must have access to the JNDI ENC, which make available EJBHome objects, JTA UserTransaction objects, JDBC DataSource objects, and optionally Java Messaging Service connection factory objects.
JavaMail 1.1 and JAF 1.0: A J2EE products must provide access to the JavaMail API for sending basic Internet mail messages (the protocol is not specified) from web and enterprise bean components. J2EE products are not required to support message store protocols, which means you must be able to send mail but not necessarily to read mail. JAF is the Java Activation Framework, which is need to support different MIME types and is required for support of JavaMail functionality.
Java Transaction API 1.0: Web and enterprise bean components must have access to JTA UserTransaction objects via the JNDI ENC under the "java:comp/UserTransaction" context. The UserTransaction interface is used for explicit transaction control.
Java Messaging Service 1.0: J2EE products must support the JMS API definitions (base classes and interfaces), but are not required to provide a JMS implementation. This means that JMS is an optional service in J2EE. If a JMS implementation is supported, the connection factories can be made available through the JNDI ENC.

11.4.3. Connectivity and Interoperability

The J2EE specification currently specifies two mechanisms that can be used to connect non-J2EE systems with a J2EE system: client access to web component services and connectivity with external CORBA services via JavaIDL. Client connectivity with web components is via HTTP/HTTPS. In other words, any client that can make HTTP requests can access J2EE servlets and JSP pages, regardless of how the client is implemented. The requirement that web and enterprise bean components support JavaIDL ensures access to external CORBA services, CORBA objects hosted on ORBs outside the J2EE application server.

While these mechanisms support connectivity (the ability to connect things together), interoperability (the ability for services to collaborate) between J2EE servers or other kinds of servers is not yet supported. In fact, J2EE doesn't even require that J2EE servers of the same brand be interoperable. Security and transactional propagation between web components and enterprise beans are loosely specified in the J2EE specification; this area of the specification needs to be improved.

To have real interoperability, web and enterprise bean components must be able to exchange information about the context in which they operate when they request services for other J2EE processes. Just as EJB propagates security and transaction context from one bean to the next, interoperable services must share the same kind of contextual information. Although HTTP and JavaIDL provide for connectivity with external clients and services, they do not provide interoperability. HTTP, for example, doesn't support interoperability for security and transactions. CORBA interoperability is really nonexistent, since mechanisms for propagating security and transactional context between a J2EE server and CORBA services are not specified.