Java EE Component Model and Development Steps: Roberto Jesus Aguilar Bernabe this Student Guideฺ

BS Grupo SฺAฺCฺ
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2014, Oracle and/or its affiliatesฺ
Java EE Component Model and Development

Steps
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
Copyright © 2011,E S U itssaffiliates. All
Oracle and/ora i d eฺ
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a
Objectives
After completing this lesson, you should be able to:

• Describe the principles of a component-based

development model
• Describe the asynchronous communication model
• Describe the process used and roles involved when
developing and executing a Java EE application
• Compare the different methods and tools available for
developing a Java EE application and related components
• Describe how to configure and package Java EE u se
to
applications BE nse A lice
N
B ER rable
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a
Developing Applications for the Java EE 6 Platform 2 - 2

Principles of Component-Based Development
• The EJB specification was designed from the outset to

support integration of components from different vendors.

• EJB components can be authored without knowing the
environment in which they will be used.
• Applications based on EJB components are loosely
coupled:
– Loosely coupled systems are easier to test and maintain.
– Components of a loosely coupled system are easier to
reuse. u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Java EE Components
EJB Container
Entity
Components
Web Container
EJB
Components Database
JSP
Pages Servlets
Application
Client
Container
u se
to
B E ense
R NA le lic
B E rab
App Client
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Java EE Components
RO hotm this S
A component in the@ Java EE platform is not necessarily a class, but is more commonly a
e
ab and interfaces that implement a self-contained unit of functionality.
grouping of classes
The Java r n
eEE model defines a number of different component types, each of which is
a r b
g u il
customized to fulfill a specific need. The figure in the slide illustrates the primary Java EE
(ra component types in their respective containers.
The Java EE component types include:
• Session beans
• Entity classes
• Message-driven beans
• Servlets
• Components that are based on JSP technology

Java EE Component Characteristics
• State and properties

• Encapsulation by a container
• Support for local and distributable component interactions
• Location transparency
• Component references obtained using a naming system
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Java EE Component
o t ma is St
RO Characteristics
The following three @ h describe
slides ththe component-based application framework that is
supported by the a e EE specification.
bJava
er n
la r b
g u i
(ra

Component State and Properties
• State is associated data that has to be maintained across

a series of method calls.

– A component may or may not be stateful.
– Stateless components may have performance advantages
over stateful components.
• A property is a component feature that can be either read
and written or read or written by its clients
– A property might be represented internally by an instance
variable. se
– Properties are modeled as accessor and mutator method to u
pairs. B E ense
A N le lic
R
E rab
B
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E t
Component StateO
tma his S
R andhProperties
o
The manner in which @a component t manages state or defines properties can have implications
e
ab or on how it can be used within the Java EE framework.
on its performance
Component r n
e State: Components may have state. However, there are certain performance
a r b
g u il
advantages that follow from the assumption that some components have no state.
(r a Specifically, the component infrastructure can cycle a client’s method calls to different
instances of the component on different hosts. This cycling is advantageous for load
balancing and fault tolerance. Components may be designed to be intrinsically stateless or
stateful. Other component types may have both stateless and stateful forms.
Component Properties: A property may be represented internally by an instance variable,
but this is irrelevant to a component’s clients. In the Java programming language, properties
are typically modeled as accessor and mutator method pairs. For example, the getName and
setName methods represent the name property.

Encapsulated Components
• Encapsulation is an important concept in object-oriented

programming.
• Java EE encapsulates components in containers that:
– Provide lifecycle management
– Isolate components from other components
– Isolate components from the runtime environment
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Component Proxies
Some Java EE components, such as EJB, are utilized through

proxies.
• There is no direct reference to the component.
• The new() operator should not be called on the
component.
• The Java EE container provides the proxy.
• A proxy allows the container to intercept method calls and
provide container-based functionality such as security
checks and transaction management. u se
to
• Some components require the developer to writeBan E ense
interface for the proxy. Java EE 6 eliminates N A licfor
the need
R
E rable
the interface in some cases. R B
ILA trans fe
U
S AG non-
Copyright © 2011,E S Uand/or itssaffiliates.
a eฺ reserved.
a Allidrights
O J om) h nt Gu
Oracle
T
R ilฺc ude
B E a t
Component Proxies
RO hotm this S
One component can@ only interact with another component through that component’s proxy.
e
ab to directly
Even if the components are located in the same Java Virtual Machine (JVM™), it is an error
r n
for one component
e instantiate another component with the new() operator or to
make r b
la direct method calls on another component’s implementation. Interfaces are frequently
u i
gused to define the functionality that will be made available by a component’s proxy.
(ra Provided that the proxy implements the same interface as the real component, the client is
unaffected by this imposition. Java EE 6 allows this proxy-based access approach to be
implemented for some components without requiring an interface. The use of proxies allows
the component to be managed by its container, which has important advantages for you.

Interaction of Java EE Application Components

Through Interfaces
Interface 1 Interface 2
Implementation 2
Implementation 1
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
RO hotmThrough
Interaction of Components
i s SInterfaces
The figure in the slide
@ th Java EE application components interact through
illustrates how
interfaces. abe
e rn implementations are programmed against the other’s public interface instead
Two component
b
of
u i lar the concrete implementation.
against
g
(ra

Distributable and Local Component Interactions
The developer specifies whether an interaction is to be local or

distributable.
• Local: The application server makes components available
to each other in the same JVM.
• Distributable: The application server provides an RMI
infrastructure by which components communicate.
Both strategies have associated costs and benefits.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Distributed Components and RMI

Interface2 Interface2
Stub Skeleton u se
to
B E ense
Component 1
R NA Component
l e lic 2
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
RO hotand
Distributed Components ma RMI i s St
To support distributable
@ component th interaction, the application server must provide an RMI
infrastructure atob e communication. Because the Java EE component model allows a
support
n
er of interface from implementation, it is straightforward to provide an RMI
strict separation
la r b
infrastructure in a way that is mostly transparent to you.
g u i
(ra The figure in the slide shows the following:
• Component1 interacts with Component2 through its interface, Interface2.
• For distributed components, Interface2 is implemented by a stub.
• The stub contains the communication logic that allows it to make remote method calls.
• Component2 is unaware that its methods are not being called directly by Component 1.
In fact, the methods for Component2 are called on behalf of Component1 by a skeleton.
• The stub and the skeleton jointly implement the communications infrastructure.

Distributed Components and RMI
The RMI infrastructure must be able to manage the following

design issues:
• Marshalling and unmarshalling of arguments and return
values
• Passing distributed exceptions
• Passing security context and transaction context
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
RMI InfrastructureO BE m
Design a
Issues St
R o t i s
h
Marshalling and unmarshalling
@ thof arguments and return values: Java programming
n a be forms part of this process. However, serialization alone is not sufficient
language serialization
passed r b er distributed
if the RMI infrastructure
between
must be language-independent. Nevertheless, objects that are to be
components must normally be serializable
u i la
g
(ra Passing distributed exceptions: When the components are distributed, error conditions
might arise that are independent of the application logic itself, such as a network
disconnection. Normally, the caller can expect to catch a java.rmi.RemoteException in
such circumstances.
Passing security context and transaction context between the caller and the target:
There is information to supply, along with the method call, that is distinct from arguments and
return types. For example, the target component may need to ensure that the caller has the
access rights to invoke the method.
An application server must support IIOP (RMI Protocol), which is part of the CORBA
specification set. IIOP ensures that applications based on EJB components are interoperable
with CORBA services. However, there is nothing to prevent a server vendor from supporting
protocols in addition to IIOP. For example, some vendors support RMI with Java Remote
Method Protocol (JRMP) as well.

Calling Semantics for Local and Distributable

Components
Local and distributable component interactions follow different
calling conventions.
Local Distributable
Components Components
Passing arguments Arguments are Arguments are
passed in shared passed by value.
memory.
Modifying the The target The target
caller’s instance component can component cannot
u se
modify the caller’s modify the caller’s to
instance. E ense
instance.
B
R NA le lic
Arguments that are themselves distributableBcomponents E rab are
an exception to these rules. These arguments I L AR nare s fepassed by
reference. A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E t
tma his SInteraction
RO hoComponent
Local and Distributable
There is one exception @ to the rulest shown in the table in the slide. Arguments that are
ab e
themselves distributable components are always passed by passing a stub, regardless of
whether the e r n
components are local to one another. Because a stub is passed, the object to
which r b
la it is passed can call methods over the wire onto the caller’s instance of the object.
g u i
(ra

Advantages and Disadvantages of a Distributed

Component Model
The following advantages derive from location transparency:
• Increased fault tolerance

• Improved load sharing between hosts
The following disadvantages derive from RMI overhead:
• Data marshalling overhead
• Network latency
• More complex exception handling
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ERloadasharing
i lฺc between
t u de servers may be achieved with local
O otm is S
Note: Fault tolerance and
components by R h advanced
using the thapplication
features of an application server such as Glassfish. Load
balancing, session
b e @
replication, and server clustering do not require remote
components. r a
nCheck the advanced features of your application server, because these features
b e
u i lar required by the Java EE specification.
are not
( rag

Location Transparency
Location transparency is a design goal of the distributed

component model in the Java EE platform:

• The calling component is not concerned with the physical
location of the target component.
• A component can be deployed in more than one host,
thereby enabling it to take advantage of these benefits:
– Load balancing
– Fault tolerance
• The application server vendor is responsible for realizing u se
to
these benefits.
B E ense
• NA le lic
The developer is responsible for developingRspecification-
compliant components. B E rab
R fe
U ILA trans
S AG non-
a eฺ reserved.
a Allidrights
O J om) h nt Gu
Oracle
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Naming Services in the Component Model
Interface 2
2
Lookup
1
Component 1 Naming Publish
Service
Interface 1
3
Component 2
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E t
Naming Services O
R in the o ma is SModel
Component
t
In the Java EE component
@ h model,tha component requires a way to get a reference to another
n a be without making use of the actual implementation. The facility to get a
component’s interface
r another component’s interface is provided by a naming service. An application
referenceeto
b
server
i r
la provides its components with a central repository of components that are accessible by
u
gname.
(ra The figure in the slide shows the process of using the naming service to look up reference
information. The three steps can be described as follows:
1. When the application is deployed, all of the components that need to be made
accessible to clients are registered with the naming service. In the example,
Component2 is published. This implements Interface2.
2. Component1 can only make method calls on Component2 through Interface2. To get a
reference to Interface2, Component1 performs a lookup using the central naming
service that has the logical name of Component2.
3. The naming service supplies an instance of a component that implements Interface2.
The object that is supplied is not necessarily an instance of Component2. The object
might be a proxy for Component2. Component1 can then call methods on Component2
using Interface2.

Use of the Java Naming and Directory Interface™

(JNDI) API in the Java EE Component Model
In the Java EE platform environment, the JNDI API:
• Implements a general lookup service for:

– Java EE components
– External resources
– Component environment
• Abstracts the underlying naming protocols and
implementation:
– CORBA naming service
– LDAP u se
to
– Vendor-specific protocols B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Use of JNDI API inOthe Java a
R hotm EEthComponent i s St Model
Only a subset of the@
full API is required when JNDI API is used in the context of a Java EE
application. ab e
e rn the protocol has no effect on the application developer, because the API
In mostbcases,
i lar these details.
conceals
u
g
(ra

The Context Interface and the InitialContext

Object
The Context interface is the basis for all naming operations.
• The InitialContext object is a specific implementation

of the Context interface.
• An InitialContext object represents the entry point to
the naming service.
• The namespace can be hierarchical.
• A lookup operation on a Context object results either in
an object or in a subcontext.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

The Context Interface and the InitialContext

Object
A subcontext also implements the Context interface. The
following two code snippets have the same effect:
Context c = new InitialContext();

Object o = c.lookup("aaa/bbb");
Or
Context subcontext = (Context) c.lookup("aaa");
Object o = subcontext.lookup("bbb");
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Configuring the InitialContext Object
Configuration of the InitialContext object differs within a

Java EE component and in a stand-alone application:

• Within a Java EE component, the container provides
configuration to the InitialContext object:
• In a stand-alone application, the InitialContext object
may require configuration:
Hashtable env = new Hashtable();
env.put ("java.naming.factory.Initial",
u se
"com.sun.jndi.cosnaming.CNCtxFactory"); to
B E ense
env.put("java.naming.provider.url", "iiop://hostname:3700");
Context c = new InitialContext(env);
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc Object
Configuring the InitialContext t u de
RO hotm this S
When you use the JNDI@ API outside of the context of an application server, you may be
required to supply e
b configuration information. This information varies from one naming service
ausually
to another,
e r n
but two pieces of information are required:
r b
•ilaThe name of a class that implements the underlying naming protocol
g u
(ra • A Universal Resource Locator (URL) that specifies the location of the naming service
This information is typically supplied in the form of name-value pairs that are passed in a
Hashtable object to the InitialContext constructor or as a properties file that is read
automatically in the InitialContext constructor.
The code snippet in the slide shows an example of how to configure a naming context for an
application server. Remember that this configuration is only required for access to JNDI when
using a client component located outside the Java EE application server host. A properties file
may be used in place of programmatic configuration.

Using JNDI API as a Resource Locator
In addition to components, JNDI API calls can locate:

• Connections to relational databases

• Connections to messaging services
• Message destinations
• Component environment variables
• Connections to legacy systems that are supported by
resource adapters
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Narrowing and Remote Objects
JNDI lookup results differ for nonremote and remote objects:

• For nonremote objects, the result of a lookup is cast to the

appropriate type:
DataSource ds = (DataSource)c.lookup("jdbc/bank");
• For remote objects, the result of a lookup requires
narrowing to the appropriate type:
Object o = c.lookup("ejb/BankMgr");
u se
BankMgr bankMgr = (BankMgr) to
javax.rmi.PortableRemoteObject.narrow ABE e n se
R N le lic
(o, BankMgr.class); E B erab
• The Java EE specifications requireLA R
narrowing s f for remote
I n
objects; however, some application A GU onservers -tra allow casting.
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E t
Narrowing and Remote
RO hoObjectstma his S
Nonremote objects: @ For example, t connections to relational databases are obtained in the
form of DataSource e
abshows objects (javax.sql.DataSource). The code snippet under the first
bullet in the
e r n
slide the code that is required to look up a database resource named
la r
jdbc/bank.b If the object that is returned by the lookup is not of the expected type, the cast
u i
(r agfails and the caller gets a ClassCastException.
Remote Objects: The result of the lookup requires narrowing to the appropriate type. This
narrowing is to ensure future compatibility with a broad range of RMI infrastructures. Some
application servers allow remote objects that are looked up with JNDI to be cast. The code
snippet in the slide shows narrowing.
Remember that when the client of a Java EE component asks for a local reference instead of
a remote reference, the result of the JNDI API lookup is not a remote object and will never
require narrowing.

Using a Component Context to Locate

Components
Java EE components have their environment represented by a
context object, such as EJBContext. A component’s context:

• Is automatically supplied to a component; no lookups are
needed
• Can be used in place of JNDI for lookups
• Simplifies lookup code:
@Resource private javax.ejb.SessionContext context;
public void myMethod() {
BankMgr bankMgr =
u se
(BankMgr)context.lookup("ejb/BankMgr"); to
} B E ense
• Does not require the use of R NA le lic
B E rab
PortableRemoteObject.narrow for
AR nsfe remote
I L
component
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Using a Component
R O Context
o t mato Locate
i s St Components
Java EE EJB components
@ h typically th have a reference to an EJBContext object that is used to
provide several b
a e pieces of information. The EJBContext object:
critical
n
er already present in an EJB component
• Isbusually
r
•ilaProvides access to environmental data and manipulation, such as security information,
u
g transaction control, and resource lookup
(ra
• Works in a similar way to a JNDI Context
• Performs JNDI lookups within the java:comp/env JNDI Context and can be used to
locate EJB references, DataSources, and any other resource reference that can be
stored in JNDI
• Removes the need to repeatedly call a new InitialContext method and simplifies
exception handling by only causing runtime exceptions
An EJBContext object can be used to look up EJB 2.1 Home references. Even when looking
up EJB 2.1 Remote Home references using the component context, the use of
PortableRemoteObject.narrow is not required.

Using Dependency Injection to Locate

Components
Dependency injection can be used to locate resources.
Containers assign values to annotated variables. Dependency

injection:
• Replaces JNDI lookup code
• Uses Java annotations. For example:
import javax.ejb.*;
@Stateful
public class MySessionBean implements MyInterface {
@EJB private BankMgr bankMgr;
} u se
to
• Uses a container to locate resources B E ense
• Only works in managed components R NA le lic
B E rab
• AR nsfto
Can be used in Java EE 5 or 6 components
I L e locate
J2EE™ 1.4 components GU -tra A non
S
a eฺ reserved.
a Allidrights
O J om) h nt Gu
Oracle
T
R ilฺc ude
B E
Using Dependency
ROInjection
o t mato Locate
i s St Components
Previously, the design
@ h name
pattern th for dependency injection was Inversion of Control. The
n a be
idea behind dependency injection is to remove the need for the developer to repeatedly write
resourcee r
lookup code. Resource lookup in Enterprise Java is typically done with JNDI.
l a rb injection eliminates JNDI coding. Dependency injection was limited to being
Dependency
i
a g u within certain types of components in Java EE 5. Java EE 5 applications sometimes
used
( r required a mixture of dependency injection and JNDI API usage. Java EE 6 enhances
dependency injection support, thus eliminating the need for almost all JNDI use by application
developers.
Annotations provide a way to embed extra data about classes, variables, and methods in
source code and also in compiled class files. This extra data added to class files can be
ignored by the Java Runtime Environment if it is not needed. Software such as a Java EE 6
application server can check for the presence of annotations using the Java reflections
package.

To implement dependency injection, an application server assigns a reference value to a
variable before it can be used. To guarantee that the application server has a chance to
perform the injection, a component must have its life cycle controlled by the server. These
types of components are referred to as managed components and include Servlets, JSPs,
and EJBs. Plain Java classes still require developers to write JNDI lookup code.
In a previous version of Enterprise Java, developers and deployers were required to create
and edit large amounts of XML deployment descriptors. In the Java EE 5 platform,
annotations and dependency injection replaced the need for most deployment descriptor
information.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S US s a n deฺ
J E
) h a Gui
R TO com ent
O BE mailฺ Stud
R hot this
a b e@
er n
a r b
g u il
(r a

Asynchronous as Compared to Synchronous

Communication
Synchronous Asynchronous
Semantics Request-response Request-notification
Blocking Client blocks until Client does not

operation block
completes
Response Client gets a direct Client may get a
response deferred response
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
RO hotm thiModel
Asynchronous Communication a
s St
There are two basic@ ways that a component can interact with other components,
synchronouslyaor e
b asynchronously. Although each style of interaction has its place in the Java
EE programming
e r n model, the asynchronous model, in some cases, provides distinct
la r b
advantages.
g u i
(ra Synchronous interactions might not be suitable for operations that take an extended time to
complete or that require a high guarantee of service.
In asynchronous communication, request-notification semantics allows an application to
support operations that can take a long time to complete, and also reduces coupling between
components.

Asynchronous Component-to-Component
Interaction
1
Legacy Batch
Place Order Ordering System
4 2
Check Order
Status
Notify Order
Status u se
to
B
Update OrderE ense
3 NA le lic
Status
R
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
RO hotm this S
Asynchronous Component-to-Component Interaction
@ shows an example of an application that uses asynchronous
ab e
component-to-component interactions to support a legacy system.
The steps r n
ein the slide can be described as follows:
a r b
g u il A component places an order on a legacy batch processing system on behalf of a client.
1.
(ra The legacy system processes orders in batches of one hundred, so it might take several
hours for the order to be processed.
2. When the batch processing system has completed the order, it notifies another
component.
3. This component updates a database that contains order status information.
4. If the client requests information about the status of the order, a component can check
the order status database. This last step can be performed using a synchronous
interaction, asynchronous messaging, or an email notification.

Asynchronous Messaging
The application server must provide a messaging service to

support asynchronous component interaction.

• The J2EE 1.4 specification required that a server must
provide infrastructure for web services and XML
messaging.
• Components use the JMS API to send messages to other
components or to external resources.
• Message-driven beans act as consumers of messages.
• Java EE 6 adds support for asynchronous processing that u se
to
does not require messaging. E se
N AB licen
B ER rable
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Advantages and Disadvantages of Asynchronous

Interactions
Asynchronous component interaction results in both benefits
and costs, compared to synchronous component interaction.

• Advantages:
– Reduced coupling between components, which results in
reduced long-term costs of management
– Accommodation of operations that take an extended time to
complete
• Disadvantages:
– Requires a more complex infrastructure
u se
– Is usually less efficient in network resource usage to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
RO hotm thiof
Advantages and Disadvantages
s SAsynchronous Interactions
Reduced coupling between@ components is a standard principle of software engineering,
because the fewer e
ab dependencies that exist between components, the easier it is to manage
components e r nindependently. This benefit results in the reduced long-term costs of software
la r b
management. An asynchronous model inherently offers loose coupling.
g u i
(ra

Developing Java EE Applications
• Performed by a group of people

• Involves separate roles and responsibilities
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Developing Java EE
o t ma is St
RO Applications
Roles include system @ h
architects, h
tcomponent developers, and application assemblers.
ab e
e r n
a r b
g u il
(ra

Java EE Roles
Roles related to application development:

• Application component provider

• Application assembler
• Deployer
Other defined roles:
• System administrator
• Tool provider
• Product provider
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Java EE Roles O
R hotm this S
The Java EE specification
@ defines several roles that are involved in the development,
deployment, and e
abmanagement of an enterprise application. Although most organizations have
strategies e r
forndividing up the work between different members of a project team, the Java EE
la r b
specification goes as far as mandating, to a degree, how this is to be done. Java EE roles
u i
ginclude:
(ra Application component provider: The application component provider develops Java EE
components such as EJB components, web components, and possibly resource adapters.
The output of this role is compiled classes and XML deployment descriptors. The descriptors
might be incomplete with respect to the finished system. The output from this process can be
used on any Java EE platform-compliant environment. Application component providers
produce vendor-neutral output.
Application assembler: The application assembler takes completed Java EE components
and assembles them into a deployable application. The components themselves can be from
various sources, including sources from outside of the organization. The application
assembler resolves cross-references between components and configures the components to
suit the application as a whole. Because of simplified packaging rules and support from tools,
this role has become less critical.

Deployer: The deployer is responsible for the deployment of the assembled application in a
specific operational environment. The deployer is responsible for resolving references to
external resources, configuring the runtime environment of the application, and integrating the
application with the security infrastructure.
System administrator: The system administrator maintains and monitors the application
server environment and ensures that optimum performance is achieved. For example, this
role may involve making decisions that are related to load balancing and redundancy.
Tool provider: The tool provider implements development, packaging, assembly, and
deployment tools.
Product provider: Product providers are vendors of application servers and the supporting
hardware and software for those servers.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S US s a n deฺ
J E
) h a Gui
R TO com ent
O BE mailฺ Stud
R hot this
a b e@
er n
a r b
g u il
(r a

Java EE Roles
Important role distinctions:

• Distinction between tool provider and product provider

• Distinction between component provider, application
assembler, and deployer
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
RO hotm this S
Java EE Role Distinctions
For the purposes of@ this course, two role distinctions are important:
e
ab between the tool provider and the product provider: Most vendors
• The distinction
e r n
ofbapplications servers that are based on Java EE technology supply assembly and
a r
il deployment tools with their products. However, the standards-based nature of the Java
g u
(ra EE specification allows a developer to use tools from third-party tool providers if they so
desire. Application components that are developed and assembled according to the
Java EE specification should run on any compliant platform.
• The distinction between the component provider, application assembler, and
deployer: This distinction is operative throughout the Java EE specification, and is
fundamental to this course as well. Remember that although the same person can be a
developer, assembler, and deployer, these are separate roles with defined
responsibilities. For example, the component provider may use an environment variable
within the application code that the deployer sets at deployment time.

Steps for Developing a Java EE Application
• Designing
• Coding
• Creating deployment descriptors
• Packaging
• Assembly
• Deployment
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
RO haoJava
Steps for Developing
s St
tmaEEhiApplication
Developing a Java EE @ application t typically requires performing the following tasks:
Designing: As
e
ainb any project, design is one of the most critical steps. Simply using the Java
r n
e framework resolves many design issues, such as how to apply security or
EE application
a r b
g u il
transaction management in an application. Java EE design typically involves a higher level of
(ra abstraction, such as deciding on what set of components to use to implement the presentation
tier or the business logic.
A system architect designs the application architecture and specifies component interfaces. A
well-defined set of component interfaces at the design step can make all of the following steps
go relatively smoothly. The steps required to design and architect a Java EE application are
covered in the course titled Developing Architectures for Enterprise Java Applications.

Coding: In this step, component developers :
1. Create the underlying implementations of the Java EE components.
2. Code, compile, and debug the components to make sure that the components fulfill their
interface contracts.
3. Perform unit testing, which is an important part of any substantial development process.
Coding can be done in any editor, and compiling and testing can be done either
manually or with a tool.

Java EE application components may be developed for a particular application, or they may
be general-purpose components or part of a software library. Component developers typically:
• Code to an interface specification using logical names of other application components
• Use logical names for external resources, such as databases that the component
accesses at run time. These logical names must be resolved when a component is
deployed as part of a functioning application. This is typically done using a naming
service.
Creating deployment descriptors: A component provider uses an XML deployment
descriptor to list resources and other components that are accessed by a Java EE
component, as well as the names used to reference them. Components that do not have u se
to
preprogrammed connections to outside resources are reusable in many applications.
B E ense
Ultimately, the application server creates resource connections and resolves
R NA descriptor.
l lic You
references
e
between components using the information contained within a deployment
BE erab or vendor-
can create a deployment descriptor by using a text editor orRwith a third-party
supplied tool. I L A nsf
A Ga U n - trauntil it is packaged as a
Packaging: A set of class files is not considered o
component
component. All pertinent files must be S packaged a n idineanฺ appropriate archive file.
US stogether
Packaging can be done either manually
O JE at) the hacommand
G u line or with a tool.
Assembling: In this step,R theTapplicationomcomponentst
en are assembled into a working
E
B process i l ฺ c t u d
application. Part of this
ROcomponent
provided by different o t mainvolvesi s
vendors.
Sresolving references between components that are
@ h th
Deployment: The
a eapplication must be deployed to the application server either manually or
btool.
r
using a vendor’s
e n This step typically involves some vendor-specific configuration of the
b
r components or the runtime environment, such as load-balancing. Most server
application
l a
u i
vendors provide a tool to accomplish deployment.
( rag

Java EE Application Development Process

Assemble
– Client Module
– EJB Component Module
– Web Module
Application
Components – Resource Module
Application Application
Component Assembler
Provider
RAR
ejb
u se
WAR
to
Deployer B
EAR E ense
NA le lic
JAR
R
E rabApplication
Deployment B
Applications
Tool
I L AR nsfe Server
A GU on-tra
S an
Copyright © 2011,E S U
Oracle and/oraitssaffiliates. All
i d eฺ
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Java EE Application
RO Development
o t ma is ProcessSt
@ h
illustrates th application components are assembled into application
how
modules that are a e deployed as an application to an application server.
bthen
er n
la r b
g u i
(ra

Development Tools
Java EE applications are traditionally developed within an

integrated development environment (IDE). IDEs provide:

• An editor
• The ability to manage Java EE components in a graphical
manner
• The ability to compile from within the IDE
• The ability to debug source code
• The ability to edit deployment descriptors using a graphical
tool u se
to
BE ense
• The ability to deploy to one or more applicationAservers
R N le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Development Tools
RO hotm this S
You can create Java @EE technology components using a variety of tools, such as text editors
e
b editing, command-line compilers, deployment and assembly tools, or
for coding andafile
integrated e r n
development environments (IDEs) that manage the entire iterative development
cycle r b
la under the umbrella of a single application.
u i
(r agThe Netbeans and Eclipse IDEs provides all of these features and more. IDEs may provide
other features, such as database exploration, entity class creation from existing database
structure, and advanced refactoring capabilities. Many IDEs are extensible using plug-ins,
which provide potentially unlimited capabilities.

Configuring and Packaging Java EE Applications
• Developers package individual components into archive

files. These archive files contain:

– Relevant class files
– XML deployment descriptors (optional)
• These archive files are packaged into a super archive to
form a complete application.
• The contents and structure of these archive files are
mandated by the Java EE specification.
• Any compliant application server should be able to accept u se
to
any compliant application. E se
N AB licen
B ER rable
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Configuring and Packaging Java EE Applications
There are four basic types of archive files used in a Java EE

development project:
• WAR files
• JAR files
• RAR files
• EAR files
Java EE 6 allows an EJB component to be packaged in a WAR
file.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E t
a EESApplications
RO hotm Java
Configuring and Packaging
i s
th defines the characteristics and operating requirements
Each type of archive @ file declaratively
of the archived
n a be
components by using a deployment descriptor.
Java EE b r
eapplication components are generally created in modules that serve as the basis for
the a r
ilconstruction of an archive file. A Java EE module consists of one or more Java EE
g u
(ra components for the same container type and one component deployment descriptor of that
type. For example, EJB components can be developed as part of an EJB module that is
subsequently used to create an EJB JAR file.

Web Application Elements

Web Container
Web Application
Static Content Deployment Descriptor
Bean Classes
se
Dynamic Content Tag Libraries
to u
B E ense
NA le lic
Servlet
R
E rab
Controllers
B
I L AR nsfeAuxiliary Classes
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Web Archive FilesO
R hotm this S
The figure in the slide@ shows the fundamental elements that constitute a web application.
e
ab in the slide only shows one icon for each element or component type, a
Although the diagram
r n
e may contain hundreds of individual elements.
web application
a r b
g u il
(ra

Web Archive File Creation

Static Content
Dynamic Content myWebApp.war
WEB-INF/
jar cvf myWebApp.war

web.xml
ejb.xml u se
to
classes/
B E ense
R NA le lic
lib/
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Web Archive File O
R Creation
o t ma is St
As illustrated in the @figure th the contents of a web application are stored as a web
h in the slide,
n be
archive file foradistribution and incorporation as part of a deployable Java EE application.
A web b r
e file uses a .war file extension.
archive
l a r
iaddition
a g u
In to allowing EJB components to be placed in the classes directory of a WAR, Java
(r EE 6 allows library JAR files that contain EJB components to be placed in the WEB-INF/lib
folder of a .war file. A library of EJB components is not considered a stand-alone enterprise
module.

Java Archive Files
Java Archive files (JAR):

• Provide a standard mechanism for packaging and

distributing Java class files and related resources
• Are normally given names that end in .jar
• Are defined by the Java EE specification as the packaging
format for EJB components and Java EE clients
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Enterprise Archive Files

EJB Component EJB Component

JAR JAR
WAR
File
Helper u se
Classes to
JAR File
B E ense
Deployment
Descriptor R NA le lic
B E rab
AR nsfe
RAR
File
I L
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E
Enterprise Archive
ROFiles o t ma is St
The super archive is@ called th
h an enterprise archive or EAR file. These files are usually given
names that endb e
a in .ear.
EAR files r n
eare structured in the same way as Java Archive files. The EAR file contains EJB
a r b
g u il
component archive files, web component archive files, resource adapter archive files, and
(ra client archive files.

Deployment Descriptors
Deployment descriptors:
• Are XML-formatted files

• Provide a declarative way to describe the interactions
between components and between a component and its
container
• Have their format, naming convention, and other attributes
defined in the relevant component specification
• Are not always required. In-code annotations can be used
by developers. u se
to
E ense
• Are used to configure vendor-specific features. Application
B
NA le lic
servers may have additional nonportable deployment
R
descriptors to do this job. B E rab
R fe
U ILA trans
S AG non-
a eฺ reserved.
a Allidrights
O J om) h nt Gu
Oracle
T
R ilฺc ude
B E a t
RO hotm this S
Deployment Descriptors
For example, the EJB @specification indicates that an EJB deployment descriptor must be a file
e
b that is located in a META-INF directory in the EJB JAR file or be
called ejb-jar.xml
r
located inethenaWEB-INF directory in a WAR.
r b
la Deployment descriptors are optional beginning with Java EE 5. Developers can use
g u i
Note:
(ra in-code annotations to configure components. If present deployment descriptors override
in-code annotations.
A component or application deployment descriptor may specify:
• The transaction management strategy
• The authorization requirements, or who can do what to the component
• The deploy-time configuration variables
• The mapping to other components
• The external resource access dependencies

The Java EE platform stipulates that when components are assembled into an application, no
changes to source code are allowed. The assembler may not even have the source code.
Therefore, the use of the deployment descriptor is significant.
Vendor-specific deployment information: Java EE component specifications may allow
server vendors to include vendor-specific configuration files in the component archive files.
For example, vendor-specific configuration files might contain information about the mapping
of externally mappable names onto physical resources, load balancing properties, and
session management settings.

Although the container may be able to supply defaults for some of these items, it cannot
usually provide the externally mappable names for resources.
The implication of this is that the application deployer needs to provide the vendor-specific
XML files, as required by the target platform.
The vendor typically supplies a document type definition (DTD) or XML schema that
describes the format and the data elements for the vendor specific configuration file.
An application deployer can construct a valid vendor-specific configuration file using an XML
editor and the DTD or XML scheme.
The effect of vendor-specific configuration on portability is minimal. These deployment u se
activities are a small part of any project, and can easily be done for any server platform. to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S US s a n deฺ
J E
) h a Gui
R TO com ent
O BE mailฺ Stud
R hot this
a b e@
er n
a r b
g u il
(r a

Summary
In this lesson, you should have learned:

• The principles of component-based development

• The characteristics of asynchronous communication
• The roles and development steps involved to create a Java
EE technology application
• How Java EE components are packaged and assembled
• The tools and techniques available for creating a Java EE
technology application
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Summary
RO hotm this S
Component-based development
@ is a key feature of the Java EE platform. The Java EE model
e
nab components have some or all of the following essential characteristics,
defines a number of different component types, each customized to fulfill a specific need.
Java EE e r
technology
l a rb on the component type:
depending
i
a g u• State and properties
(r
• Encapsulation by a container
• Strict separation of interface from implementation
• Support for local and distributable component interactions
• Location transparency
• Component references obtained using a naming system
There are two basic ways that a component can interact with other components,
synchronously or asynchronously. Although each style of interaction has its place in the Java
EE programming model, the asynchronous model, in some cases, provides distinct
advantages.

Java EE application development is typically performed by a group of people, each with
separate roles and responsibilities. The Java EE specification defines several roles that are
involved in the development, deployment, and management of an enterprise application.
Developing a Java EE application typically involves several steps. An application developer
uses a number of tools and techniques to develop a Java EE application.
Java EE application components are packaged into archive files for distribution and assembly
into a Java EE application. Archive files contain a deployment descriptor that describes the
characteristics of the components contained within an archive file.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S US s a n deฺ
J E
) h a Gui
R TO com ent
O BE mailฺ Stud
R hot this
a b e@
er n
a r b
g u il
(r a

Quiz
Which of the following features are provided by component-

based proxies in Java EE 6?

a. Enhanced presentation layer performance
b. Implementation requires an interface.
c. Implementation without requiring an interface
d. Containers are allowed to manage the original component.
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Answer: c, d
RO hotm this S
a b e@
b e rn
u i lar
(r ag

Quiz
Which of the following design issues are managed by RMI

infrastructure?
a. Passing SQL
b. Parsing strings
c. Marshalling and unmarshalling
d. Passing distributed exceptions
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
R ilฺc ude
B E a t
Answer: c, d
RO hotm this S
a b e@
b e rn
u i lar
(r ag

Quiz
Which of the following statements best defines location

transparency?
a. The location is defined by a universally accessible URL.
b. The calling component caches a proxy location to the
target component.
c. In any component to component interaction, the calling
component is not concerned with the physical location of
the target component.
d. In any component to component interaction, the calling u se
to
E ense
component resolves the physical location of the target
B
component using well defined algorithms. RNA lic
B E rable
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: c
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
What is JNDI? Select one of the following.

a. Java Negative Data Initialization

b. Java Naming and Data Interface
c. Java Naming and Directory Interface
d. Java Normalization and Data interface
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: c
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
Which of the following is the correct way to set up a JNDI

context?
a. Context c = new Context();
b. InitialContext c = new Context();
c. Context c = new InitialContext();
d. InitialContext c = new InitialContext();
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: c
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
Which of the following Java feature allows you to accomplish

dependency injection?
a. JDBC
b. EJB
c. Java Interfaces
d. Java Annotations
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: d
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
How is a synchronous communication different from

asynchronous communication? Select one of the following.

a. A synchronous process always performs better than an
asynchronous process.
b. An asynchronous process always performs better than a
synchronous process.
c. A synchronous process blocks communication after
making a request; an asynchronous process continues
working. u se
to
E ense
d. An asynchronous process blocks communication after
B
NA le lic
making a request; a synchronous process continues
R
working. BE rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: c
RO hotm this S
a be@
b e rn
i lar
ag u
(r

Quiz
Which of the following is not a Java EE role?

a. Deployer
b. Application Analyst
c. R System Administrator
d. R Application component provider
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: b
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
Which of the following is the correct task order for Java EE

application development?
a. Code, test, code, test, package, deploy
b. Design, code, configure, package, assemble, deploy
c. Code, test, code, configure, package, assemble, deploy
d. Code, configure, package, assemble, deploy, test, code
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: b
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Quiz
Which of the following is not a Java file package type?

a. tar
b. jar
c. war
d. ear
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
Answer: a
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Practice 2: Overview
This practice covers the following topics:

• Describing the Java EE roles and responsibilities

• Listing the options for packaging applications
u se
to
B E ense
R NA le lic
B E rab
I L AR nsfe
A GU on-tra
S an
O J om) h nt Gu
rights reserved.
T
B ER ailฺc tude
RO hotm this S
a b e@
er n
a r b
g u il
(r a

Java EE Component Model and Development Steps: Roberto Jesus Aguilar Bernabe this Student Guideฺ

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Java EE Component Model and Development Steps: Roberto Jesus Aguilar Bernabe this Student Guideฺ

Загружено:

Авторское право:

Доступные форматы

BS Grupo SฺAฺCฺ

Java EE Component Model and Development

After completing this lesson, you should be able to:

• Describe the principles of a component-based

Developing Applications for the Java EE 6 Platform 2 - 2

Principles of Component-Based Development

• The EJB specification was designed from the outset to

support integration of components from different vendors.

Developing Applications for the Java EE 6 Platform 2 - 3

Developing Applications for the Java EE 6 Platform 2 - 4

Java EE Component Characteristics

• State and properties

Developing Applications for the Java EE 6 Platform 2 - 5

Component State and Properties

• State is associated data that has to be maintained across

a series of method calls.

Developing Applications for the Java EE 6 Platform 2 - 6

• Encapsulation is an important concept in object-oriented

Developing Applications for the Java EE 6 Platform 2 - 7

Some Java EE components, such as EJB, are utilized through

Developing Applications for the Java EE 6 Platform 2 - 8

Interaction of Java EE Application Components

Developing Applications for the Java EE 6 Platform 2 - 9

Distributable and Local Component Interactions

The developer specifies whether an interaction is to be local or

Developing Applications for the Java EE 6 Platform 2 - 10

Distributed Components and RMI

Developing Applications for the Java EE 6 Platform 2 - 11

Distributed Components and RMI

The RMI infrastructure must be able to manage the following

Developing Applications for the Java EE 6 Platform 2 - 12

Calling Semantics for Local and Distributable

Developing Applications for the Java EE 6 Platform 2 - 13

Advantages and Disadvantages of a Distributed

• Increased fault tolerance

Developing Applications for the Java EE 6 Platform 2 - 14

Location transparency is a design goal of the distributed

component model in the Java EE platform:

Developing Applications for the Java EE 6 Platform 2 - 15

Naming Services in the Component Model

Developing Applications for the Java EE 6 Platform 2 - 16

Use of the Java Naming and Directory Interface™

• Implements a general lookup service for:

Developing Applications for the Java EE 6 Platform 2 - 17

The Context Interface and the InitialContext

• The InitialContext object is a specific implementation

Developing Applications for the Java EE 6 Platform 2 - 18

The Context Interface and the InitialContext

following two code snippets have the same effect:

Context c = new InitialContext();

Developing Applications for the Java EE 6 Platform 2 - 19

Configuring the InitialContext Object

Configuration of the InitialContext object differs within a

Java EE component and in a stand-alone application:

Developing Applications for the Java EE 6 Platform 2 - 20

Using JNDI API as a Resource Locator

In addition to components, JNDI API calls can locate:

• Connections to relational databases

Developing Applications for the Java EE 6 Platform 2 - 21

Narrowing and Remote Objects

JNDI lookup results differ for nonremote and remote objects:

• For nonremote objects, the result of a lookup is cast to the

Developing Applications for the Java EE 6 Platform 2 - 22