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.
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.
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.
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:
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 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.
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.
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 2.0 Standard Extension, but not the JDBC 2.0 Optional Package.
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.
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.
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.
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.
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.