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.
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.
The J2EE specifications require application servers to support a specific set of protocols and Java enterprise extensions, ensuring a consistent platform for deploying J2EE applications. J2EE application servers must provide the following “standard” services:
J2EE 1.4 products must support Java 2, SDK 1.4. J2EE 1.3 products must support Java 2, SDK 1.3.
J2EE 1.4 products must support EJB 2.1. J2EE 1.3 products must support EJB 2.0.
J2EE 1.4 products must support Servlets 2.4. J2EE 1.3 products must support Servlets 2.3.
J2EE 1.4 products must support JSP 2.0. J2EE 1.3 products must support JSP 1.2.
Web components in a J2EE server service both HTTP and HTTPS requests. 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. Components must have full access to HTTP/HTTPS client APIs.
Support for Java RMI-IIOP is required. However, the vendor may also use other protocols, as long as they are compatible with Java RMI-IIOP semantics.
J2EE components can be native Java RMI (JRMP) clients.
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.
J2EE 1.4 requires support for JDBC 3.0. J2EE 1.3 requires support for the JDBC 2.0 and some parts of the JDBC 2.0 Extension.
Web and enterprise bean components must have access to the JNDI ENC,
to access things like the EJBHome
objects, JTA
UserTransaction
objects, JDBC
DataSource
objects, Java Message Service
ConnectionFactory
objects, and JAX-RPC
ConnectionFactory
objects.
J2EE 1.4 products must support JavaMail 1.3, including access to a message store. J2EE 1.3 products must support JavaMail 1.2. Both platforms must support JAF (Java Activation Framework) 1.0; it’s needed to support different MIME types and required for support of JavaMail.
J2EE 1.4 products must support JMS 1.1. J2EE 1.3 products must support JMS 1.0.2. J2EE products must provide support for both point-to-point (p2p) and publish-and-subscribe (pub/sub) messaging models. J2EE 1.4 must also support the Unified messaging model.
J2EE 1.4 products must support JAXP 1.2, which includes XML Schema validation, while J2EE 1.3 products must support JAXP 1.1.
J2EE 1.4 products must support J2CA 1.5, which includes asynchronous messaging. J2EE 1.3 products must support J2CA 1.0.
J2EE 1.4 and 1.3 products must support the use of JAAS 1.0, as described in the J2CA specifications.
J2EE 1.4 and 1.3 products must support JTA 1.0 and must have access
to the UserTransaction
objects via the JNDI ENC.
J2EE 1.4 must support Web Services for J2EE 1.1 The specification includes JAX-RPC 1.1, JAXR 1.0, and SAAJ 1.2.
J2EE 1.4 products must support the logging of
events using
the java.util.logging
package, which is part of
the J2SDK 1.4 core.
J2EE 1.4 products must support the J2EE Management API 1.0, including support for some features of JMX 1.2.
J2EE 1.4 products must support the J2EE Deployment API 1.1. Vendors must support the plug-in component for tool vendors.
J2EE 1.4 must support the JACC 1.0, which defines a contract between a J2EE application server and an authorization policy provider.