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
are packaged along with their XML deployment descriptors and deployed
in JAR files with the extension
.war
, which
stands for web archive. 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 2.0 local component interfaces of enterprise beans. This makes a lot of sense if the web component and the bean are co-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). 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 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 inside a J2EE archive file.
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 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 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 1.3 specification requires application servers to support a specific set of protocols and Java enterprise extensions. This requirement ensures a consistent platform for deploying J2EE applications. J2EE application servers must provide the following “standard” services:
J2EE products must support the complete specification.
J2EE products must support the complete specification.
J2EE products must support the complete specification.
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.
Support for Java RMI-IIOP is required. However, other protocols may also be used by the vendor, as long as they are compatible with Java RMI-IIOP semantics.
J2EE components can be 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 requires support for the JDBC Core ( JDK 1.3) and some parts of the JDBC 2.0 Extension, including connection naming and pooling and distributed transaction support.
Web and enterprise bean components must have access to the JNDI ENC,
which make available EJBHome
objects, JTA
UserTransaction
objects, JDBC
DataSource
objects, and Java Message Service
connection factory objects.
J2EE products must support sending basic Internet mail messages (the protocol is not specified) using the JavaMail API from web and enterprise bean components. The JavaMail implementation must support MIME message types. JAF is the Java Activation Framework, which is needed to support different MIME types and is required for support of JavaMail functionality.
J2EE products must provide support for both point-to-point (p2p) and publish-and-subscribe (pub/sub) messaging models.
J2EE products must support JAXP and provide at least one SAX 2 parser, at least one DOM 2 parser, and at least one XSLT transform engine.
J2EE must support the JCA API from all components and provide full support for resource adapters and transaction capabilities as defined by the JCA.
J2EE products must support the use of JAAS as described in the JCA specification. In addition, application client containers must support the authentication facilities defined in the JAAS specification.
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.