Jakarta Enterprise Beans, Core Features

Transaction Interoperability

Specification: Jakarta Enterprise Beans, Core Features

Version: {revnumber}

Status: {revremark}

Release: {revdate}
 _EJB 2.1 and earlier Entity Bean Component
Contract for Container-Managed Persistence_
 _EJB 2.1 and earlier Entity Bean Component
Contract for Bean-Managed Persistence_
 _Client View of an EJB 2.1 and earlier
Entity Bean_
 _EJB QL: Query Language for
Container-Managed Persistence Query Methods_
_JAX-RPC Based Web Service Endpoints_
_JAX-RPC Web Service Client View_
 _A simplified local view that provides
session bean access without a separate local business interface._
 _A singleton session bean component that
provides easy access to shared state as well as application startup and
shutdown callbacks._
 _Definition of the Java language metadata
annotations that can be used to annotate EJB applications. These
metadata annotations are targeted at simplifying the developer’s task,
at reducing the number of program classes and interfaces the developer
is required to implement, and at eliminating the need for the developer
to provide an EJB deployment descriptor._
 _Specification of programmatic defaults,
including for metadata, to reduce the need for the developer to specify
common, expected behaviors and requirements on the EJB container. A
“configuration by exception” approach is taken whenever possible._
 _Encapsulation of environmental dependencies
and JNDI access through the use of annotations, dependency injection
mechanisms, and simple lookup mechanisms._
 _Simplification of the enterprise bean
types._
 _Elimination of the requirement for home
interfaces for session beans._
 _Simplification of entity persistence
through the Java Persistence API_ link:Ejb.html#a9851[See Java™
Persistence API, version 2.1. http://jcp.org/en/jsr/detail?id=338.] _._
Support for light-weight domain modeling, including inheritance and
polymorphism.
 _A query language for Java Persistence that
is an extension to EJB QL, with addition of projection, explicit inner
and outer join operations, bulk update and delete, subqueries, and
group-by. Addition of a dynamic query capability and support for native
SQL queries._
 _An interceptor facility for session beans
and message-driven beans._
 _Reduction of the requirements for usage of
checked exceptions._
 _Elimination of the requirement for the
implementation of callback interfaces._
_Terminology note_ _:_
 _The term_ _remote business interface_ _is
used to refer to the business interface of an EJB 3.x session bean that
supports remote access._
 _The term_ _remote component interface_ _is
used to refer to the remote component interface of the EJB 2.1 client
view. This interface is an EJBObject interface._
 _The term_ _local business interface_
_refers to the local business interface of an EJB 3.x session bean that
supports local access._
 _The term_ _local component interface_ _is
used to refer to the local component interface of the EJB 2.1 client
view. This interface is an EJBLocalObject interface._
...
...
...
...
...
...
 (CartHome)ctx.lookup("
_com.acme.example.MySessionBean/_ cartHome");
CartHome.class);
 Cart create(String customerName, String
account)
throws RemoteException, BadAccountException,
CreateException;
 Cart createLargeCart(String customerName,
String account)
throws RemoteException, BadAccountException,
CreateException;
 Cart create(String customerName, String
account)
throws BadAccountException, CreateException;
 Cart createLargeCart(String customerName,
String account)
throws BadAccountException, CreateException;
initialContext.lookup(...), CartHome.class);
 _//_ _serialize cartHandle, store in a
file..._
cartHandle.getEJBObject(), Cart.class);
...
...
...
...
 _stateless_ —the session bean instances
contain no conversational state between methods; any instance can be
used for any client.
 _stateful_ —the session bean instances
contain conversational state which must be retained across methods and
transactions.
 If a subsequent invocation is made on the
result of _getBusinessObject_ , then:
_AroundConstruct_
_PostConstruct_
_PreDestroy_
_PostActivate_
_PrePassivate_
 _The SessionBean interface was required to
be implemented by the session bean class in earlier versions of the
Enterprise JavaBeans specification. Under the EJB 3.x API, the
functionality previously provided by the SessionBean interface is
available to the bean class through selective use of dependency
injection (of the SessionContext) and optional lifecycle callback
interceptor methods._
// ... do calculation
Integer result = ...;
return new AsyncResult<Integer>(result);
 _NOTE: When a stateful session bean is
looked up or otherwise obtained through the explicit JNDI lookup
mechanisms, the container must provide a new stateful session bean
instance, as required by the Java EE specification (Section “Java Naming
and Directory Interface (JNDI) Naming Context”
link:Ejb.html#a9854[See Java™ Naming and Directory Interface 1.2
Specification (JNDI).
http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/index.html.])._
private SharedData state;
@PostConstruct
void init() \{
// initialize shared data
...
}
...
 _Note that the container must start a new
transaction if the_ _REQUIRED_ _(_ _Required_ _)_ _transaction attribute
is used. This guarantees, for example, that the transactional behavior
of the_ _PostConstruct_ _method is the same regardless of whether the
singleton session bean instance is initialized eagerly at container
startup time or as a side effect of a first client invocation on the
singleton session bean._ The REQUIRED transaction attribute value is
allowed so that specification of a transaction attribute for the
_singleton session bean’s_ _PostConstruct_ _and_ _PreDestroy_ _methods_
can be defaulted.
public void aMethod () \{ ... }
public void bMethod () \{ ... }
...
public void aMethod () \{ ... }
@Lock(WRITE)
public void cMethod () \{ ... }
...
 _java.io.Serializable_ ,
_java.io.Externalizable_ and the interfaces defined by the _javax.ejb_
package are excluded when determining whether the bean class has
business interfaces.
_AroundConstruct_
_PostConstruct_
_PreDestroy_
 _The MessageDrivenBean interface was
required by earlier versions of the Enterprise JavaBeans specification.
Under the EJB 3.x API, the functionality previously provided by the
MessageDrivenBean interface is available to the bean class through the
use of dependency injection (of the MessageDrivenContext) and optional
lifecycle callback methods._
 _AroundInvoke_ interceptor methods are
supported for message-driven beans. These interceptor methods may be
defined on the bean class or on a interceptor class and apply to the
handling of the invocation of the bean’s message listener method(s).
@ActivationConfigProperty(
propertyName="messageSelector",
 propertyValue="JMSType = ‘car’ AND color =
‘blue’
AND weight > 2500")
messageSelector
 JMSType = ‘car’ AND color = ‘blue’ AND
weight &gt; 2500
 _AroundInvoke_ interceptor methods may be
defined for business methods of sessions beans and for the message
listener methods of message-driven beans.
 _AroundTimeout_ methods may throw system
exceptions, but not application exceptions. See section
link:Ejb.html#a2031[See Exception Handling] for further details.
 _PostActivate_ , and _PrePassivate_ methods
follow requirements for the lifecycle callback interceptor methods
defined in the Interceptors specification document
link:Ejb.html#a9887[See Interceptors, version 1.2.
http://jcp.org/en/jsr/detail?id=318.].
 _Interceptor_ methods are allowed to throw
runtime exceptions or any checked exceptions that the method they
interpose on allows within its _throws_ clause. _Interceptor_ methods
are allowed to catch and suppress exceptions and recover by calling
_proceed()._
 _Interceptor_ method invoked in a
transaction context, can mark the transaction for rollback by throwing a
runtime exception or by calling the _EJBContext_ method
_setRollbackOnly()_ . This may be done before or after
_InvocationContext.proceed()_ is called.
_Style 1_ :
<interceptor-binding>
<target-name>*</target-name>
</interceptor-binding>
_Style 2_ :
<interceptor-binding>
<target-name>TARGETNAME</target-name>
</interceptor-binding>
_Style 3_ :
<interceptor-binding>
<target-name>TARGETNAME</target-name>
<method-name>METHOD</method-name>
</interceptor-binding>
_Style 4_ :
<interceptor-binding>
<target-name>TARGETNAME</target-name>
<method-name>METHOD</method-name>
<method-params>
<method-param>PARAM-1</method-param>
<method-param>PARAM-2</method-param>
...
<method-param>PARAM-n</method-param>
</method-params>
<interceptor-binding>
 _Style 1_ : The following interceptors are
default interceptors. They will be invoked in the order specified.
<interceptor-binding>
<target-name>*</target-name>
</interceptor-binding>
 _Style 2:_ The following interceptors are
the class-level interceptors of the _EmployeeService_ class. They will
be invoked in the order specified after any default interceptors.
<interceptor-binding>
<target-name>EmployeeService</target-name>
</interceptor-binding>
 _Style 3_ : The following interceptors apply
to all the _myMethod_ methods of the _EmployeeService_ class. They will
be invoked in the order specified after any default interceptors and
class-level interceptors.
<interceptor-binding>
<target-name>EmployeeService</target-name>
<method-name>myMethod</method-name>
</interceptor-binding>
<interceptor-binding>
<target-name>EmployeeService</target-name>
<method-name>myMethod</method-name>
<method-params>
<method-param>char</method-param>
<method-param>int</method-param>
<method-param>int[]</method-param>
</method-params>
</interceptor-binding>
<interceptor-binding>
<target-name>EmployeeService</target-name>
<method-name>EmployeeService</method-name>
</interceptor-binding>
 _Style 4_ : The following interceptor
element refers to the _myMethod(String_ _firstName, String_ _LastName)_
method of the _EmployeeService_ class.
<interceptor-binding>
<target-name>EmployeeService</target-name>
<method-name>myMethod</method-name>
<method-params>
</method-params>
</interceptor-binding>
<interceptor-binding>
<target-name>EmployeeService</target-name>
<method-name>EmployeeService</method-name>
<method-params>
</method-params>
</interceptor-binding>
<interceptor-binding>
<target-name>EmployeeService</target-name>
<interceptor-order>
<interceptor-class>org.acme.MyIC
</interceptor-class>
<interceptor-class>org.acme.MyDefaultIC
</interceptor-class>
<interceptor-class>org.acme.MyDefaultIC2
</interceptor-class>
<interceptor-class>org.acme.MyIC2
</interceptor-class>
</interceptor-order>
</interceptor-binding>
 _Many applications will consist of one or
several enterprise beans that all use a single resource manager
(typically a relational database management system). The EJB container
can make use of resource manager local transactions as an optimization
technique for enterprise beans for which distributed transactions are
not needed. A resource manager local transaction does not involve
control or coordination by an external transaction manager. The
container’s use of local transactions as an optimization technique for
enterprise beans with either container-managed transaction demarcation
or bean-managed transaction demarcation is not visible to the enterprise
beans. For a discussion of the use of resource manager local
transactions as a container optimization strategy, refer to
link:Ejb.html#a9861[See Java™ Platform, Enterprise Edition
Specification Version 7 (Java EE). http://jcp.org/en/jsr/detail?id=342.]
and link:Ejb.html#a9863[See Java EE™ Connector Architecture,
version 1.7 (Connector). http://jcp.org/en/jsr/detail?id=322.]._
 @Resource javax.transaction.UserTransaction
ut;
@Resource javax.sql.DataSource database1;
@Resource javax.sql.DataSource database2;
public void someMethod(...) \{
java.sql.Connection con1;
java.sql.Connection con2;
java.sql.Statement stmt1;
java.sql.Statement stmt2;
try \{
 // obtain con1 object and set it up for
transactions
con1 = database1.getConnection();
stmt1 = con1.createStatement();
 // obtain con2 object and set it up for
transactions
con2 = database2.getConnection();
stmt2 = con2.createStatement();
 // Now do a transaction that involves con1
and con2.
// start the transaction
ut.begin();
 // Do some updates to both con1 and con2.
The container
 // automatically enlists con1 and con2 with
the
// transaction.
stmt1.executeQuery(...);
stmt1.executeUpdate(...);
stmt2.executeQuery(...);
stmt2.executeUpdate(...);
stmt1.executeUpdate(...);
stmt2.executeUpdate(...);
// commit the transaction
ut.commit();
} catch (...) \{
// handle exception s
...
} finally \{
// release connections
con1.close();
con2.close();
...
}
}
...
 @Resource javax.Transaction.UserTransaction
ut;
@Resource javax.sql.DataSource database1;
 @Resource javax.jms.QueueConnectionFactory
qcf1;
@Resource javax.jms.Queue queue1;
public void someMethod(...) \{
java.sql.Connection dcon;
java.sql.Statement stmt;
javax.jms.QueueConnection qcon;
javax.jms.QueueSession qsession;
javax.jms.QueueSender qsender;
javax.jms.Message message;
try \{
 // obtain db conn object and set it up for
transactions
dcon = database1.getConnection();
stmt = dcon.createStatement();
 // obtain jms conn object and set up session
for
// transactions
qcon = qcf1.createQueueConnection();
qsession = qcon.createQueueSession(true,0);
qsender = qsession.createSender(queue1);
message = qsession.createTextMessage();
message.setText(“some message”);
 // Now do a transaction that involves both
connections
// start the transaction
ut.begin();
 // Do database updates and send message. The
container
 // automatically enlists dcon and qsession
with the
// transaction.
stmt.executeQuery(...);
stmt.executeUpdate(...);
stmt.executeUpdate(...);
qsender.send(message);
// commit the transaction
ut.commit();
} catch (...) \{
// handle exception s
...
} finally \{
// release connections
dcon.close();
qcon.close();
...
}
}
...
 @Resource javax.Transaction.UserTransaction
ut;
@Resource javax.sql.DataSource database1;
@Resource javax.sql.DataSource database2;
java.sql.Connection con1;
java.sql.Connection con2;
public void method1(...) \{
java.sql.Statement stmt;
// start a transaction
ut.begin();
// make some updates on con1
con1 = database1.getConnection();
stmt = con1.createStatement();
stmt.executeUpdate(...);
stmt.executeUpdate(...);
//
 // The container retains the transaction
associated with the
 // instance to the next client call (which
is method2(...)).
}
public void method2(...) \{
java.sql.Statement stmt;
con2 = database2.getConnection();
stmt = con2.createStatement();
stmt.executeUpdate(...);
stmt.executeUpdate(...);
 // The container retains the transaction
associated with the
 // instance to the next client call (which
is method3(...)).
}
public void method3(...) \{
java.sql.Statement stmt;
// make some more updates on con1 and con2
stmt = con1.createStatement();
stmt.executeUpdate(...);
stmt = con2.createStatement();
stmt.executeUpdate(...);
try \{
// commit the transaction
ut.commit();
} finally \{
// release connections
con1.close();
con2.close();
...
}
}
...
 @Resource javax.Transaction.UserTransaction
ut;
@Resource javax.sql.DataSource database1;
public void method1(...) \{
// start a transaction
ut.begin();
}
public void method2(...) \{
java.sql.Connection con;
java.sql.Statement stmt;
try \{
// open connection
con = database1.getConnection();
// make some updates on con
stmt = con.createStatement();
stmt.executeUpdate(...);
stmt.executeUpdate(...);
} finally \{
// close the connection
con.close();
...
}
}
public void method3(...) \{
// commit the transaction
ut.commit();
}
...
...
@TransactionAttribute(REQUIRED)
public void someMethod(...) \{
java.sql.Connection con1;
java.sql.Connection con2;
java.sql.Statement stmt1;
java.sql.Statement stmt2;
try \{
// obtain con1 and con2 connection objects
con1 = ...;
con2 = ...;
stmt1 = con1.createStatement();
stmt2 = con2.createStatement();
//
 // Perform some updates on con1 and con2.
The container
 // automatically enlists con1 and con2 with
the
// container-managed transaction.
//
stmt1.executeQuery(...);
stmt1.executeUpdate(...);
stmt2.executeQuery(...);
stmt2.executeUpdate(...);
stmt1.executeUpdate(...);
stmt2.executeUpdate(...);
} finally \{
// release connections
con1.close();
con2.close();
...
}
}
...
_Mandatory_
_Required_
_RequiresNew_
_Supports_
_NotSupported_
_Never_
 _In this chapter, we use the
TransactionAttribute annotation values to refer to transaction
attributes. As noted, however, the deployment descriptor may be used._
MANDATORY,
REQUIRED,
REQUIRES_NEW,
SUPPORTS,
NOT_SUPPORTED,
NEVER
public void aMethod () \{...}
public void bMethod () \{...}
...
public void aMethod () \{...}
@TransactionAttribute(REQUIRES_NEW)
public void cMethod () \{...}
...
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>*</method-name> +
</method> +
 +
This style is used to specify a default value of the transaction
attribute for the following methods, if any, of the specified enterprise
bean for which there is no Style 2 or Style 3 element specified:
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>METHOD</method-name> +
</method> +
 +
This style is used for referring to a specified method of a business,
home, or component interface method; no-interface view method; message
listener method; web service endpoint method; singleton PostConstruct
and PreDestroy methods; or timeout callback method of the specified
enterprise bean. If there are multiple methods with the same overloaded
name, this style refers to all the methods with the same name.
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>METHOD</method-name> +
<method-params> +
<method-param>PARAMETER_1</method-param> +
... +
<method-param>PARAMETER_N</method-param> +
</method-params> +
</method> +
 +
This style is used to refer to a single method within a set of methods
with an overloaded name. If there is also a container-transaction
element that uses the Style 2 element for the method name, or the Style
1 element for the bean, the value specified by the Style 3 element takes
precedence.
...
<assembly-descriptor>
...
<container-transaction>
<method>
<ejb-name>EmployeeRecord</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>EmployeeRecord</ejb-name>
<method-name>updatePhoneNumber</method-name>
</method>
<trans-attribute>Mandatory</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>*</method-name>
</method>
</container-transaction>
</assembly-descriptor>
 _ExceptionA_ is an application exception
that causes the transaction to be marked for rollback.
 _ExceptionB_ is an application exception
that causes the transaction to be marked for rollback.
 _ExceptionC_ is an application exception
that does _not_ cause the transaction to be marked for rollback.
 _ExceptionD_ is not an application
exception.
Method condition
Method condition
Method condition
Method condition
Method condition
 _The goals of the_
interoperability _requirements specified in
this chapter are as follows:_
 _Scenario 1: A customer wants to buy a book
from an Internet bookstore. The bookstore’s web site consists of a Java
EE application containing JSPs that form the presentation layer, and
another Java EE application containing enterprise beans that have the
business logic and database access code. The JSPs and enterprise beans
are deployed in containers from different vendors._
 _At deployment time: The enterprise beans
are deployed, and their EJBHome objects are published in the EJB
server’s name service. The Deployer links the EJB reference in the JSP’s
deployment descriptor to the URL of the enterprise bean’s EJBHome
object, which can be looked up from the name service. The transaction
attribute specified in the enterprise bean’s deployment descriptor is
RequiresNew for all business methods. Because the “checkout” JSP
requires secure access to set up payments for purchases, the bookstore’s
administrator configures the “checkout” JSP to require access over HTTPS
with only server authentication. Customer authentication is done using
form-based login. The “book search” JSP is accessed over normal HTTP.
Both JSPs talk with enterprise beans that access the book database. The
web and EJB containers use the same customer realm and have a trust
relationship with each other. The network between the web and EJB
servers is not guaranteed to be secure from attacks._
 _At runtime: The customer accesses the book
search JSP using a browser. The JSP looks up the enterprise bean’s
EJBHome object in a name service, and calls findBooks(...) with the
search criteria as parameters. The web container establishes a secure
session with the EJB container with mutual authentication between the
containers, and invokes the enterprise bean. The customer then decides
to buy a book, and accesses the “checkout” JSP. The customer enters the
necessary information in the login form, which is used by the web server
to authenticate the customer. The JSP invokes the enterprise bean to
update the book and customer databases. The customer’s principal is
propagated to the EJB container and used for authorization checks. The
enterprise bean completes the updates and commits the transaction. The
JSP sends back a confirmation page to the customer._
 _Scenario 2.1: An enterprise has an expense
accounting application used by employees from their desktops. The
server-side consists of a Java EE application containing enterprise
beans that are deployed on one vendor's Java EE product, which is hosted
in a datacenter. The client side consists of another Java EE application
containing an application client deployed using another vendor's Java EE
infrastructure. The network between the application client and the EJB
container is insecure and needs to be protected against spoofing and
other attacks._
 _At deployment time: The enterprise beans
are deployed and their EJBHome objects are published in the enterprise’s
name service. The application clients are configured with the names of
the EJBHome objects. The Deployer maps employees to roles that are
allowed access to the enterprise beans. The System Administrator
configures the security settings of the application client and EJB
container to use client and server authentication and message
protection. The System Administrator also does the necessary client-side
configuration to allow client authentication._
 _At runtime: The employee logs on using
username and password. The application client container may interact
with the enterprise’s authentication service infrastructure to set up
the employee’s credentials. The client application does a remote
invocation to the name server to look up the enterprise bean’s EJBHome
object, and creates the enterprise beans. The application client
container uses a secure transport protocol to interact with the name
server and EJB server, which does mutual authentication and also
guarantees the confidentiality and integrity of messages. The employee
then enters the expense information and submits it. This causes remote
business methods of the enterprise beans to be invoked. The EJB
container performs authorization checks and, if they succeed, executes
the business methods._
 _Scenario 2.2: This is the same as Scenario
2.1, except that there is no client-side authentication infrastructure
set up by the System Administrator which can authenticate at the
transport protocol layer. At runtime the client container needs to send
the user’s password to the server during the method invocation to
authenticate the employee._
 _Scenario 3: An enterprise has an expense
accounting application which needs to communicate with a payroll
application. The applications use enterprise beans and are deployed on
Java EE servers from different vendors. The Java EE servers and
naming/authentication services may be in the enterprise's datacenter
with a physically secure private network between them, or they may need
to communicate across the intranet, which may be less secure. The
applications need to update accounts and payroll databases. The employee
(client) accesses the expense accounting application as described in
Scenario 2._
 _At deployment time: The Deployer configures
both applications with the appropriate database resources. The accounts
application is configured with the name of the EJBHome object of the
payroll application. The payroll bean’s deployment descriptor specifies
the RequiresNew transaction attribute for all methods. The applications
use the same principal-to-role mappings (e.g. the roles may be Employee,
PayrollDept, AccountsDept). The Deployer of these two applications has
administratively set up a trust relationship between the two EJB
containers, so that the containers do not need to authenticate
principals propagated on calls to enterprise beans from the other
container. The System Administrator also sets up the message protection
parameters of the two containers if the network is not physically
secure._
 _At runtime: An employee makes a request to
the accounts application which requires it to access the payroll
application. The accounts application does a lookup of the payroll
application’s EJBHome object in the naming/directory service and creates
enterprise beans. It updates the accounts database and invokes a remote
method of the payroll bean. The accounts bean’s container propagates the
employee’s principal on the method call. The payroll bean’s container
maps the propagated employee principal to a role, does authorization
checks, and sets up the payroll bean’s transaction context. The
container starts a new transaction, then the payroll bean updates the
payroll database, and the container commits the transaction. The
accounts bean receives a status reply from the payroll bean. If an error
occurs in the payroll bean, the accounts bean executes code to recover
from the error and restore the databases to a consistent state._
 _Scenario 4: This is the same as scenario
2.1, except that instead of using a “fat-client” desktop application to
access the enterprise’s expense accounting application, employees use a
web browser and connect to a web server in the intranet that hosts JSPs.
The JSPs gather input from the user (e.g., through an HTML form), invoke
enterprise beans that contain the actual business logic, and format the
results returned by the enterprise beans (using HTML)._
 _At deployment time: The enterprise Deployer
configures its expense accounting JSPs to require access over HTTPS with
mutual authentication. The web and EJB containers use the same customer
realm and have a trust relationship with each other._
 _At run-time:
The employee logs in to the client desktop, starts the browser, and
accesses the expense accounting JSP. The browser establishes an HTTPS
session with the web server. Client authentication is performed (for
example) using the employee’s credentials which have been established by
the operating system at login time (the browser interacts with the
operating system to obtain the employee’s credentials). The JSP looks up
the enterprise bean’s EJBHome object in a name service. The web
container establishes a secure session with the EJB container with
mutual authentication and integrity/confidentiality protection between
the containers, and invokes methods on the enterprise beans._
 Remote method invocation on an enterprise
bean’s EJBObject and EJBHome object references (scenarios 1,2,3,4),
described in section link:Ejb.html#a3376[See Remote Invocation
Interoperability].
 Name service lookup of the enterprise bean’s
EJBHome object (scenarios 1,2,3,4), described in section
link:Ejb.html#a3504[See Naming Interoperability].
 Mutual authentication between two EJB
containers or between a web and EJB container to establish trust before
principals are propagated (scenarios 1,3,4), described in section
link:Ejb.html#a3517[See Security Interoperability].
 Propagation of the Internet or intranet
user’s principal name for invocations on enterprise beans from web or
EJB containers when the client and server containers have a trust
relationship (scenarios 1,3,4), described in section
link:Ejb.html#a3517[See Security Interoperability].
 _Transaction interoperability between
containers provided by different vendors is an optional feature in this
version of the EJB specification. Vendors may choose to not implement
transaction interoperability. However, vendors who choose to implement
transaction interoperability must follow the requirements in sections
link:Ejb.html#a3429[See Transaction Interoperability
Requirements] and link:Ejb.html#a3452[See Interoperating with
Containers that do not Implement Transaction Interoperability], and
vendors who choose not to_ implement
transaction interoperability _must follow the requirements in section
link:Ejb.html#a3452[See Interoperating with Containers that do
not Implement Transaction Interoperability]._
 _A distributed transaction started by a web
or EJB container must be able to propagate in a remote invocation to an
enterprise bean in an EJB container provided by a different vendor, and
the containers must participate in the distributed two-phase commit
protocol._
 _Transaction context propagation from client
to EJB container uses the implicit propagation mechanism described in
the_ CORBA Object Transaction Service (OTS)
v1.2 specification link:Ejb.html#a9860[See Transaction Service
Specification (OTS). http://www.omg.org/cgi-bin/doc?ptc/2001-11-03.].
 _The transaction context format in IIOP
messages is specified in the_ _CosTransactions::PropagationContext_
_structure described in the OTS specification. EJB containers that
support transaction interoperability are required to be capable of
producing and consuming transaction contexts in IIOP messages in the
format described in the OTS specification. Web containers_ that support
transaction interoperability _are required to include client-side
libraries which can produce the OTS transaction context for sending over
IIOP._
 _The_ _CosTransactions::PropagationContext_
_structure must be included in IIOP messages sent by web or EJB
containers when required by the rules described in the OTS 1.2
specification. The target EJB container must process IIOP invocations
based on the transaction policies of EJBObject or EJBHome references
using the rules described in the_ OTS 1.2 specification
link:Ejb.html#a9860[See Transaction Service Specification (OTS).
http://www.omg.org/cgi-bin/doc?ptc/2001-11-03.].
 _Containers that perform transactional work
within the scope of a transaction must register an OTS Resource object
with the transaction coordinator whose object reference is included in
the propagated transaction context (step 3), and may also register an
OTS Synchronization object (step 2). If the server container does not
register an OTS Synchronization object, it must still ensure that the
beforeCompletion method of session beans and ejbStore method of entity
beanslink:#a10316[96] are called with the proper transaction
context. Containers must participate in the two-phase commit and
recovery procedures performed by the transaction coordinator /
terminator (steps 6,7), as described by the OTS specification._
 _The exception handling behavior described
in the OTS1.2 specification must be followed. In particular, if an
application exception (an exception which is not a CORBA system
exception and does not extend_
_java.rmi.RemoteException_ _) is returned by the server, the request is
defined as being successful; hence the client-side OTS library must not
roll back the transaction. This allows application exceptions to be
propagated back to the client without rolling back the transaction, as
required by the exception handling rules in
link:Ejb.html#a2940[See Exception Handling]._
 _This section describes the requirements for
supporting interoperable access to naming services for looking up
EJBHome object references_ (interoperability
requirement two in section link:Ejb.html#a3364[See Overview of
Interoperability Requirements]) _._
 _EJB containers are required to be able to
publish EJBHome object references in a CORBA CosNaming service
link:Ejb.html#a9866[See CORBA Naming Service.
http://www.omg.org/spec/NAM/.]. The CosNaming service must implement the
IDL interfaces in the CosNaming module defined in
link:Ejb.html#a9866[See CORBA Naming Service.
http://www.omg.org/spec/NAM/.] and allow clients to invoke the_
 _resolve_ _and_ _list_ _operations over
IIOP._
 _The CosNaming service must follow the
requirements in the CORBA Interoperable Name Service specification
link:Ejb.html#a9867[See Interoperable Name Service FTF document.
http://www.omg.org/cgi-bin/doc?ptc/00-08-07.] for providing the host,
port, and object key for its root_ _NamingContext_ _object. The
CosNaming service must be able to service IIOP invocations on the root_
_NamingContext_ _at the advertised host, port, and object key._
 _Client containers_ (i.e., EJB, web, or
application client containers) _are required to include a JNDI CosNaming
service provider that uses the mechanisms defined in the_ Interoperable
Name Service specification _to contact the server’s CosNaming service,
and to resolve the EJBHome object using standard CosNaming APIs. The
JNDI CosNaming service provider may or may not use the JNDI SPI
architecture. The JNDI CosNaming service provider must access the_ root
NamingContext _of the server’s CosNaming service by creating an object
reference from the URL_ _corbaloc:iiop:1.2@<host>:<port>/<objectkey>_
_(where_ _<host>_ _,_ _<port>_ , and _<objectkey>_ _are the values
corresponding to the root NamingContext advertised by the server’s
CosNaming service), or by using an equivalent mechanism._
 _The advantage of using CosNaming is better
integration with the IIOP infrastructure that is already required for
interoperability, as well as interoperability with non-Java-EE CORBA
clients and servers. Since CosNaming stores only CORBA objects it is
likely that vendors will use other enterprise directory services for
storing other resources._
 _Security of CosNaming service access is
achieved using the security interoperability protocol described in
link:Ejb.html#a3517[See Security Interoperability]. The
CosNaming service must support this protocol. Clients which construct
the root NamingContext object reference from a URL should send an IIOP_
 _LocateRequest_ _message to the CosNaming
service to obtain the complete IOR (with SSL information) of the root
NamingContext, and then initiate an SSL session with the CosNaming
service, as determined by the client policy._
 _EJB containers are required to follow the
protocol rules prescribed by the CSIv2 specification_ Conformance Level
0 _._
 _Support for Kerberos ciphersuites is not
specified._
 _When using IIOP over SSL, a secure channel
between client and server containers is established at the SSL layer.
The SSL handshake layer handles authentication (either mutual or
server-only) between containers, negotiation of cipher suite for bulk
data encryption, and optionally provides a compression method. The SSL
record layer performs confidentiality and integrity protection_
on application data. Since compliant Java EE
products are already required to support SSL (HTTPS for Internet
communication), the use of SSL/TLS provides a relatively easy route to
interoperable security at the transport layer.
 _EJB containers must also be capable of
creating IORs that allow access to enterprise beans over unprotected
IIOP, based on the security policies set by the Deployer or System
Administrator._
 _Since the interoperability scenarios
involve IIOP/SSL usage in intranets, it is assumed that client and
server container administrators cooperatively configure a consistent set
of security policies for the enterprise._
 _At product installation or application
deployment time, client and server container administrators may
optionally configure the container and SSL infrastructure as described
below._ These preferences may be specified at any level of granularity
(e.g. per host or per container process or per enterprise bean).
 _Configure the list of supported SSL cipher
suites in preference order._
 _Configure authentication preferences and
requirements (e.g. if the server prefers authenticated clients to
anonymous clients). In particular, if a trust relationship has been
configured between two servers, then mutual authentication should be
required unless there is physical network security._
 _If the client and server are using
certificates for authentication, configure a trusted common certificate
authority for both client and server. If using Kerberos, configure the
client and server with the same KDC or cooperating KDCs._
 _Configure a restricted list of trusted
server principals that a client container is allowed to interact with,
to prevent the client’s private credentials such as password from being
sent to untrusted servers._
 _Client containers determine whether to use
SSL for an enterprise bean invocation by using the security policies
configured by the client administrator for interactions with the target
host or enterprise bean, and the_
_target_requires_ _information in the CSIv2 tagged component in the
target enterprise bean’s IOR. If either the client configuration
requires secure interactions with the enterprise bean, or the enterprise
bean requires a secure transport, the client should initiate an SSL
connection to the server._ The client must follow the rules described in
the CSIv2 specification Conformance Level 0 for interpreting security
information in IORs and including security context information in IIOP
messages.
 _When an EJB container receives an IIOP
message, its behavior depends on deployment time configuration, run-time
information exchanged with the client at the SSL layer, and
principal/authentication data contained in the IIOP message service
context. EJB containers are required to follow the protocol rules
prescribed by the CSIv2 specification_ Conformance Level 0 _._
@Stateless
public class EmployeeServiceBean implements EmployeeService {
 ...
 // The maximum number of tax exemptions, configured by Deployer
 @Resource
 int maxExemptions;

 // The minimum number of tax exemptions, configured by Deployer
 @Resource
 int minExemptions;

 public void setTaxInfo(int numberOfExemptions,...)
          throws InvalidNumberOfExemptionsException {
 ...
 // Use the environment entries to customize business logic.
 if (numberOfExemptions > maxExemptions
        || numberOfExemptions < minExemptions)
    throw new InvalidNumberOfExemptionsException();
 }
}
// an entry that gets its value from an application-wide entry
@Resource(lookup="java:app/env/timeout")
int timeout;
@Stateless
public class EmployeeServiceBean implements EmployeeService {
 ...
 public void setTaxInfo(int numberOfExemptions, ...)
          throws InvalidNumberOfExemptionsException {
 ...
 // Obtain the enterprise bean’s environment naming context.
 Context initCtx = new InitialContext();
 Context myEnv = (Context)initCtx.lookup("java:comp/env");

 // Obtain the maximum number of tax exemptions
 // configured by the Deployer.
 Integer maxExemptions = (Integer)myEnv.lookup("maxExemptions");

 // Obtain the minimum number of tax exemptions
 // configured by the Deployer.
 Integer minExemptions = (Integer)myEnv.lookup("minExemptions");

 // Use the environment entries to customize business logic.
 if (numberOfExeptions > maxExemptions
        || numberOfExemptions < minExemptions)
    throw new InvalidNumberOfExemptionsException();

 // Get some more environment entries. These environment
 // entries are stored in subcontexts.
 String val1 = (String)myEnv.lookup("foo/name1");
 Boolean val2 = (Boolean)myEnv.lookup("foo/bar/name2");

 // The enterprise bean can also lookup using full pathnames.
 Integer val3 = (Integer)initCtx.lookup("java:comp/env/name3");
 Integer val4 = (Integer)initCtx.lookup("java:comp/env/foo/name4");
 ...
 }
}
<enterprise-beans>
  <session>
  ...
  <ejb-name>EmployeeService</ejb-name>
  <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
  ...
  <env-entry>
    <description>
      The maximum number of tax exemptions
      allowed to be set.
    </description>
    <env-entry-name>maxExemptions</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value>15</env-entry-value>
  </env-entry>
  <env-entry>
    <description>
      The minimum number of tax exemptions
      allowed to be set.
    </description>
    <env-entry-name>minExemptions</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value>1</env-entry-value>
  </env-entry>
  <env-entry>
    <env-entry-name>foo/name1</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>value1</env-entry-value>
  </env-entry>
  <env-entry>
    <env-entry-name>foo/bar/name2</env-entry-name>
    <env-entry-type>java.lang.Boolean</env-entry-type>
    <env-entry-value>true</env-entry-value>
  </env-entry>
  <env-entry>
    <description>Some description.</description>
    <env-entry-name>name3</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
  </env-entry>
  <env-entry>
    <env-entry-name>foo/name4</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value>10</env-entry-value>
  </env-entry>
  ...
  </session>
</enterprise-beans>
<enterprise-beans>
  <session>
    ...
    <ejb-name>EmployeeService</ejb-name>
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
    ...
    <env-entry>
      <description>
       The maximum number of tax exemptions
       allowed to be set.
      </description>
      <env-entry-name>
        com.wombat.empl.EmployeeService/maxExemptions
      </env-entry-name>
      <env-entry-type>java.lang.Integer</env-entry-type>
      <env-entry-value>15</env-entry-value>
      <injection-target>
        <injection-target-class>
          com.wombat.empl.EmployeeServiceBean
        </injection-target-class>
        <injection-target-name>maxExemptions</injection-target-name>
      </injection-target>
    </env-entry>
    <env-entry>
      <description>
        The minimum number of tax exemptions
        allowed to be set.
      </description>
      <env-entry-name>
        com.wombat.empl.EmployeeService/minExemptions
      </env-entry-name>
      <env-entry-type>java.lang.Integer</env-entry-type>
      <env-entry-value>1</env-entry-value>
      <injection-target>
        <injection-target-class>
          com.wombat.empl.EmployeeServiceBean
        </injection-target-class>
        <injection-target-name>minExemptions</injection-target-name>
      </injection-target>
    </env-entry>
    ...
  </session>
</enterprise-beans>
// The maximum number of tax exemptions, configured by the Deployer.
@Resource
int maxExemptions = 4; // defaults to 4
<env-entry>
  <env-entry-name>
    com.wombat.empl.EmployeeServiceBean/timeout
  </env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <injection-target>
    <injection-target-class>
      com.wombat.empl.EmployeeServiceBean
    </injection-target-class>
    <injection-target-name>timeout</injection-target-name>
  </injection-target>
  <lookup-name>java:app/env/timeout</lookup-name>
</env-entry>
package com.acme.example;
@Stateless
public class ExampleBean implements Example {
 ...
 @EJB
 private ShoppingCart myCart;
 ...
}
@EJB(
 name="ejb/shopping-cart",
 beanInterface=ShoppingCart.class,
 beanName="cart1",
 description="The shopping cart for this application"
)
private ShoppingCart myCart;
@EJB(
 lookup="java:app/cartModule/ShoppingCart",
 description="The shopping cart for this application"
)
private ShoppingCart myOtherCart;
@EJB(
 name="ejb/shopping-cart",
 beanInterface=ShoppingCartHome.class,
 beanName="cart1",
 description="The shopping cart for this application"
)
private ShoppingCartHome myCartHome;
@EJB(
 name="ejb/shopping-cart",
 beanInterface=ShoppingCartBean.class,
 beanName="cart1",
 description="The shopping cart for this application"
)
private ShoppingCartBean myCart;
@EJB(name="ejb/EmplRecord", beanInterface=EmployeeRecordHome.class)
@Stateless
public class EmployeeServiceBean
        implements EmployeeService {

 public void changePhoneNumber(...) {
 ...
 // Obtain the default initial JNDI context.
 Context initCtx = new InitialContext();

 // Look up the home interface of the EmployeeRecord
 // enterprise bean in the environment.
 Object result = initCtx.lookup(
      "java:comp/env/ejb/EmplRecord");

 // Convert the result to the proper type.
 EmployeeRecordHome emplRecordHome = (EmployeeRecordHome)
       javax.rmi.PortableRemoteObject.narrow(result,
                EmployeeRecordHome.class);
 ...
 }
}
...
 <enterprise-beans>
  <session>
  ...
  <ejb-name>EmployeeService</ejb-name>
  <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
  ...
  <ejb-ref>
    <description>
        This is a reference to an EJB 2.1 session
        bean that encapsulates access to employee records.
    </description>
    <ejb-ref-name>ejb/EmplRecord</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>com.wombat.empl.EmployeeRecordHome</home>
    <remote>com.wombat.empl.EmployeeRecord</remote>
  </ejb-ref>
  <ejb-local-ref>
    <description>
        This is a reference to the local business interface
        of an EJB 3.0 session bean that provides a payroll
        service.
    </description>
    <ejb-ref-name>ejb/Payroll</ejb-ref-name>
    <local>com.aardvark.payroll.Payroll</local>
  </ejb-local-ref>
  <ejb-local-ref>
    <description>
        This is a reference to the local business interface
        of an EJB 3.0 session bean that provides a pension
        plan service.
    </description>
    <ejb-ref-name>ejb/PensionPlan</ejb-ref-name>
    <local>com.wombat.empl.PensionPlan</local>
  </ejb-local-ref>
  ...
  </session>
  ...
 </enterprise-beans>
...
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>EmployeeService</ejb-name>
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
    ...
    <ejb-ref>
      <ejb-ref-name>ejb/EmplRecord</ejb-ref-name>
      <ejb-ref-type>Session</ejb-ref-type>
      <home>com.wombat.empl.EmployeeRecordHome</home>
      <remote>com.wombat.empl.EmployeeRecord</remote>
      <ejb-link>EmployeeRecord</ejb-link>
    </ejb-ref>
    ...
  </session>
  ...
  <session>
    <ejb-name>EmployeeRecord</ejb-name>
    <home>com.wombat.empl.EmployeeRecordHome</home>
    <remote>com.wombat.empl.EmployeeRecord</remote>
    ...
  </session>
  ...
</enterprise-beans>
...
 <session>
  ...
  <ejb-name>OrderEJB</ejb-name>
  <ejb-class>com.wombat.orders.OrderBean</ejb-class>
  ...
  <ejb-ref>
    <ejb-ref-name>ejb/Product</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>com.acme.orders.ProductHome</home>
    <remote>com.acme.orders.Product</remote>
    <ejb-link>../products/product.jar#ProductEJB</ejb-link>
  </ejb-ref>
  ...
</session>
...
<ejb-ref>
  <ejb-ref-name>ShoppingService/myCart</ejb-ref-name>
  <ejb-link>product/ShoppingCart</ejb-link>
</ejb-ref>
...
...
<ejb-ref>
  <ejb-ref-name>ShoppingService/myCart</ejb-ref-name>
  <lookup-name>java:app/products/ShoppingCart</lookup-name>
</ejb-ref>
...
...
<ejb-ref>
  <ejb-ref-name>ShoppingService/myCart</ejb-ref-name>
  <lookup-name>java:global/products/ShoppingCart</lookup-name>
</ejb-ref>
//The employee database.
@Resource
javax.sql.DataSource employeeAppDB;
...
public void changePhoneNumber(...) {
  ...
  // Invoke factory to obtain a resource. The security
  // principal for the resource is not given, and
  // therefore it will be configured by the Deployer.
  java.sql.Connection con = employeeAppDB.getConnection();
  ...
}
// The customer database, looked up in the application environment.
@Resource(lookup="java:app/env/employeeAppDB")
javax.sql.DataSource employeeAppDB;
@Resource(name="jdbc/EmployeeAppDB", type=javax.sql.DataSource)
@Stateless
public class EmployeeServiceBean implements EmployeeService {
 @Resource
 SessionContext ctx;
 public void changePhoneNumber(...) {
 ...
 // use context lookup to obtain resource manager
 // connection factory
 javax.sql.DataSource ds = (javax.sql.DataSource)
      ctx.lookup("jdbc/EmployeeAppDB");

 // Invoke factory to obtain a connection. The security
 // principal is not given, and therefore
 // it will be configured by the Deployer.
 java.sql.Connection con = ds.getConnection();
 ...
 }
}
@Resource(name="jdbc/EmployeeAppDB", type=javax.sql.DataSource)
@Stateless
public class EmployeeServiceBean implements EmployeeService {

 EJBContext ejbContext;

 public void changePhoneNumber(...) {
 ...
 // obtain the initial JNDI context
 Context initCtx = new InitialContext();

 // perform JNDI lookup to obtain resource manager
 // connection factory
 javax.sql.DataSource ds = (javax.sql.DataSource)
      initCtx.lookup("java:comp/env/jdbc/EmployeeAppDB");

 // Invoke factory to obtain a connection. The security
 // principal is not given, and therefore
 // it will be configured by the Deployer.
 java.sql.Connection con = ds.getConnection();
 ...
 }
}
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>EmployeeService</ejb-name>
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
    ...
    <resource-ref>
      <description>
        A data source for the database in which
        the EmployeeService enterprise bean will
        record a log of all transactions.
      </description>
      <res-ref-name>jdbc/EmployeeAppDB</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
    ...
  </session>
</enterprise-beans>
...
...
<enterprise-beans>
  <session>
    ...
    <resource-ref>
      <description>
        A queue connection factory used by the
        MySession enterprise bean to send
        notifications.
      </description>
      <res-ref-name>jms/qConnFactory</res-ref-name>
      <res-type>javax.jms.QueueConnectionFactory</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Unshareable</res-sharing-scope>
    </resource-ref>
    ...
  </session>
</enterprise-beans>
...
@Resource
javax.jms.Queue stockQueue;
@Resource(name="jms/StockQueue", type=javax.jms.Queue)
@Stateless
public class StockServiceBean implements StockService {

 @Resource
 SessionContext ctx;

 public void processStockInfo(...) {
 ...
 // Look up the JMS StockQueue in the environment.
 Object result = ctx.lookup("jms/StockQueue");

 // Convert the result to the proper type.
 javax.jms.Queue queue = (javax.jms.Queue)result;
 }
}
@Resource(name="jms/StockQueue", type=javax.jms.Queue)
@Stateless
public class StockServiceBean implements StockService {

 public void processStockInfo(...) {
 ...
 // Obtain the default initial JNDI context.
 Context initCtx = new InitialContext();

 // Look up the JMS StockQueue in the environment.
 Object result = initCtx.lookup(
      "java:comp/env/jms/StockQueue");

 // Convert the result to the proper type.
 javax.jms.Queue queue = (javax.jms.Queue)result;
 ...
 }
}
...
<message-destination-ref>
  <description>
    This is a reference to a JMS queue used in processing Stock info
  </description>
  <message-destination-ref-name>
    jms/StockInfo
  </message-destination-ref-name>
  <message-destination-type>
    javax.jms.Queue
  </message-destination-type>
  <message-destination-usage>
    Produces
  </message-destination-usage>
</message-destination-ref>
...
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>EmployeeService</ejb-name>
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
    ...
    <message-destination-ref>
      <message-destination-ref-name>
        jms/EmployeeReimbursements
      </message-destination-ref-name>
      <message-destination-type>
        javax.jms.Queue
      </message-destination-type>
      <message-destination-usage>
        Produces
      </message-destination-usage>
      <message-destination-link>
        ExpenseProcessingQueue
      </message-destination-link>
    </message-destination-ref>
  </session>
  ...
  <message-driven>
    <ejb-name>ExpenseProcessing</ejb-name>
    <ejb-class>com.wombat.empl.ExpenseProcessingBean</ejb-class>
    <messaging-type>javax.jms.MessageListener</messaging-type>
    ...
    <message-destination-type>
      javax.jms.Queue
    </message-destination-type>
    <message-destination-link>
      ExpenseProcessingQueue
    </message-destination-link>
    ...
  </message-driven>
  ...
</enterprise-beans>
...
<assembly-descriptor>
  ...
  <message-destination>
    <message-destination-name>
      ExpenseProcessingQueue
    </message-destination-name>
  </message-destination>
  ...
</assembly-descriptor>
<session>
  ...
  <ejb-name>EmployeeService</ejb-name>
  <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
  ...
  <message-destination-ref>
    <message-destination-ref-name>
      jms/EmployeeReimbursements
    </message-destination-ref-name>
    <message-destination-type>
      javax.jms.Queue
    </message-destination-type>
    <message-destination-usage>
      Produces
    </message-destination-usage>
    <message-destination-link>
      finance.jar#ExpenseProcessingQueue
    </message-destination-link>
  </message-destination-ref>
</session>
@PersistenceUnit
EntityManagerFactory emf;

@PersistenceUnit(unitName="InventoryManagement")
EntityManagerFactory inventoryEMF;
@PersistenceUnit(name="persistence/InventoryAppDB")
@Stateless
public class InventoryManagerBean implements InventoryManager {

 @Resource
 SessionContext ctx;

 public void updateInventory(...) {
 ...
 // use context lookup to obtain entity manager factory
 EntityManagerFactory emf = (EntityManagerFactory)
     ctx.lookup("persistence/InventoryAppDB");

 // use factory to obtain application-managed entity manager
 EntityManager em = emf.createEntityManager();
 ...
 }
}
@PersistenceUnit(name="persistence/InventoryAppDB")
@Stateless
public class InventoryManagerBean implements InventoryManager {

 EJBContext ejbContext;
 ...
 public void updateInventory(...) {
 ...
 // obtain the initial JNDI context
 Context initCtx = new InitialContext();

 // perform JNDI lookup to obtain entity manager factory
 EntityManagerFactory emf = (EntityManagerFactory)
     initCtx.lookup("java:comp/env/persistence/InventoryAppDB");

 // use factory to obtain application-managed entity manager
 EntityManager em = emf.createEntityManager();
 ...
 }
}
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>InventoryManagerBean</ejb-name>
    <ejb-class>
      com.wombat.empl.InventoryManagerBean
    </ejb-class>
    ...
    <persistence-unit-ref>
      <description>
        Persistence unit for the inventory management
        application.
      </description>
      <persistence-unit-ref-name>
        persistence/InventoryAppDB
      </persistence-unit-ref-name>
      <persistence-unit-name>
        InventoryManagement
      </persistence-unit-name>
    </persistence-unit-ref>
    ...
  </session>
</enterprise-beans>
...
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>InventoryManagerBean</ejb-name>
    <ejb-class>
      com.wombat.empl.InventoryManagerBean
    </ejb-class>
    ...
    <persistence-unit-ref>
      <description>
        Persistence unit for the inventory management
        application.
      </description>
      <persistence-unit-ref-name>
        persistence/InventoryAppDB
      </persistence-unit-ref-name>
      <persistence-unit-name>
        ../lib/inventory.jar#InventoryManagement
      </persistence-unit-name>
    </persistence-unit-ref>
    ...
  </session>
</enterprise-beans>
...
@PersistenceContext(type=EXTENDED)
EntityManager em;
@PersistenceContext(name="persistence/InventoryAppMgr")
@Stateless
public class InventoryManagerBean implements InventoryManager {

 @Resource
 SessionContext ctx;

 public void updateInventory(...) {
 ...
 // use context lookup to obtain container-managed entity manager
 EntityManager em = (EntityManager)
     ctx.lookup("persistence/InventoryAppMgr");
 ...
 }
}
@PersistenceContext(name="persistence/InventoryAppMgr")
@Stateless
public class InventoryManagerBean implements InventoryManager {

 EJBContext ejbContext;

 public void updateInventory(...) {
 ...
 // obtain the initial JNDI context
 Context initCtx = new InitialContext();

 // perform JNDI lookup to obtain container-managed entity manager
 EntityManager em = (EntityManager)
     initCtx.lookup("java:comp/env/persistence/InventoryAppMgr");
 ...
 }
}
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>InventoryManagerBean</ejb-name>
    <ejb-class>
      com.wombat.empl.InventoryManagerBean
    </ejb-class>
    ...
    <persistence-context-ref>
      <description>
        Persistence context for the inventory management
        application.
      </description>
      <persistence-context-ref-name>
        persistence/InventoryAppMgr
      </persistence-context-ref-name>
      <persistence-unit-name>
        InventoryManagement
      </persistence-unit-name>
    </persistence-context-ref>
    ...
  </session>
</enterprise-beans>
...
...
<enterprise-beans>
  <session>
    ...
    <ejb-name>InventoryManagerBean</ejb-name>
    <ejb-class>
      com.wombat.empl.InventoryManagerBean
    </ejb-class>
    ...
    <persistence-context-ref>
      <description>
        Persistence context for the inventory management
        application.
      </description>
      <persistence-context-ref-name>
        persistence/InventoryAppMgr
      </persistence-context-ref-name>
      <persistence-unit-name>
        ../lib/inventory.jar#InventoryManagement
      </persistence-unit-name>
    </persistence-context-ref>
    ...
  </session>
</enterprise-beans>
...
@Resource
UserTransaction tx;
...
public void updateData(...) {
 ...
 // Start a transaction.
 tx.begin();
 ...
 // Perform transactional operations on data.
 ...
 // Commit the transaction.
 tx.commit();
 ...
}
public MySessionBean implements SessionBean {
 ...
 public someMethod() {
 ...
 Context initCtx = new InitialContext();
 UserTransaction utx = (UserTransaction)initCtx.lookup(
    "java:comp/UserTransaction");
 utx.begin();
 ...
 utx.commit();
 }
 ...
}
public MySessionBean implements SessionBean {
 ...
 SessionContext ctx;
 ...
 public someMethod() {
 UserTransaction utx = ctx.getUserTransaction();
 utx.begin();
 ...
 utx.commit();
 }
 ...
}
@Resource
ORB orb;

public void method(...) {
 ...
 // Get the POA to use when creating object references.
 POA rootPOA = (POA)orb.resolve_initial_references("RootPOA");
 ...
}
public void method(...) {
 ...
 // Obtain the default initial JNDI context.
 Context initCtx = new InitialContext();

 // Look up the ORB object.
 ORB orb = (ORB)initCtx.lookup("java:comp/ORB");

 // Get the POA to use when creating object references.
 POA rootPOA = (POA)orb.resolve_initial_references("RootPOA");
 ...
}
 ...
<env-entry>
  <env-entry-name>ejb10-properties/foo</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
</env-entry>
<env-entry>
  <description>bar’s description</description>
  <env-entry-name>ejb10-properties/bar</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>bar value</env-entry-value>
</env-entry>
 ...
public class SomeBean implements SessionBean {
 SessionContext ctx;
 java.util.Properties env;

 public void setSessionContext(SessionContext sc) {
  ctx = sc;
  env = ctx.getEnvironment();
 }

 public someBusinessMethod(...) ... {
  String fooValue = env.getProperty("foo");
  String barValue = env.getProperty("bar");
 }
 ...
}
...
//
 // The following two methods allow the EJB
class
// to access security information.
//
 java.security.Principal
getCallerPrincipal();
boolean isCallerInRole(String roleName);
//
 // The following two EJB 1.0 methods are
deprecated.
//
java.security.Identity getCallerIdentity();
 boolean
isCallerInRole(java.security.Identity role);
...
 public boolean isCallerInRole(Identity
identity) \{
return isCallerInRole(identity.getName());
}
implements EmployeeService\{
@Resource SessionContext ctx;
@PersistenceContext EntityManager em;
public void changePhoneNumber(...) \{
...
// obtain the caller principal.
callerPrincipal = ctx.getCallerPrincipal();
// obtain the caller principal’s name.
callerKey = callerPrincipal.getName();
 // use callerKey as primary key to find
EmployeeRecord
EmployeeRecord myEmployeeRecord =
em.find(EmployeeRecord.class, callerKey);
// update phone number
myEmployeeRecord.setPhoneNumber(...);
...
}
@Resource SessionContext ctx;
 public void updateEmployeeInfo(EmplInfo
info) \{
oldInfo = ... read from database;
 // The salary field can be changed only by
callers
// who have the security role "payroll"
if (info.salary != oldInfo.salary &&
!ctx.isCallerInRole("payroll")) \{
throw new SecurityException(...);
}
...
}
...
@Resource SessionContext ctx;
 public void updateEmployeeInfo(EmplInfo
info) \{
oldInfo = ... read from database;
 // The salary field can be changed only by
callers
// who have the security role "payroll"
if (info.salary != oldInfo.salary &&
!ctx.isCallerInRole("payroll")) \{
throw new SecurityException(...);
}
...
}
...
...
<enterprise-beans>
...
<session>
<ejb-name>AardvarkPayroll</ejb-name>
...
<security-role-ref>
<description>
This security role should be assigned to the
employees of the payroll department who are
allowed to update employees’ salaries.
</description>
<role-name>payroll</role-name>
</security-role-ref>
...
</session>
...
</enterprise-beans>
...
...
<security-role>
<description>
This role includes the employees of the
enterprise who are allowed to access the
employee self-service application. This role
is allowed only to access his/her own
information.
</description>
<role-name>employee</role-name>
</security-role>
<security-role>
<description>
 This role includes the employees of the
human
resources department. The role is allowed to
view and update all employee records.
</description>
<role-name>hr-department</role-name>
</security-role>
<security-role>
<description>
 This role includes the employees of the
payroll
department. The role is allowed to view and
update the payroll entry for any employee.
</description>
<role-name>payroll-department</role-name>
</security-role>
<security-role>
<description>
 This role should be assigned to the
personnel
 authorized to perform administrative
functions
for the employee self-service application.
This role does not have direct access to
sensitive employee and payroll information.
</description>
<role-name>admin</role-name>
</security-role>
...
public void aMethod () \{...}
public void bMethod () \{...}
...
@RolesAllowed("HR")
public void aMethod () \{...}
public void cMethod () \{...}
...
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>*</method-name> +
</method> +
 +
This style is used for referring to all of the methods of the business,
home, and component interfaces, no-interface view, and web service
endpoint of a specified enterprise bean.
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>METHOD</method-name> +
</method> +
 +
This style is used for referring to a specified method of the business,
home, or component interface, no-interface view, or web service endpoint
of the specified enterprise bean. If there are multiple methods with the
same overloaded name, this style refers to all of the overloaded
methods.
 +
<method> +
<ejb-name>EJBNAME</ejb-name> +
<method-name>METHOD</method-name> +
<method-params> +
<method-param>PARAMETER_1</method-param> +
... +
<method-param>PARAMETER_N</method-param> +
</method-params> +
</method> +
 +
This style is used to refer to a specified method within a set of
methods with an overloaded name. The method must be defined in the
specified enterprise bean’s business, home, or component interface,
no-interface view, or web service endpoint. If there are multiple
methods with the same overloaded name, however, this style refers to all
of the overloaded methods.
...
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>findByPrimaryKey</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>getEmployeeInfo</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
</method>
</method-permission>
<method-permission>
<role-name>payroll-department</role-name>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>findByPrimaryKey</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>getEmployeeInfo</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>updateSalary</method-name>
</method>
</method-permission>
<method-permission>
<role-name>admin</role-name>
<method>
<ejb-name>EmployeeServiceAdmin</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
...
...
<enterprise-beans>
...
<session>
<ejb-name>AardvarkPayroll</ejb-name>
...
<security-role-ref>
<description>
This role should be assigned to the
employees of the payroll department.
Members of this role have access to
anyone’s payroll record.
The role has been linked to the
payroll-department role.
</description>
<role-name>payroll</role-name>
<role-link>payroll-department</role-link>
</security-role-ref>
...
</session>
...
</enterprise-beans>
...
 _Establishing a run-as identity for an
enterprise bean does not affect the identities of its callers, which are
the identities tested for permission to access the methods of the
enterprise bean. The run-as identity establishes the identity the
enterprise bean will use when it makes calls._
implements EmployeeService\{
...
...
<enterprise-beans>
...
<session>
<ejb-name>EmployeeService</ejb-name>
...
<security-identity>
<run-as>
<role-name>admin</role-name>
</run-as>
</security-identity>
...
</session>
...
</enterprise-beans>
...
Allowable values:
[1,31] or
[-7, -1] or
“Last” or
 \{“1st”, “2nd”, “3rd”, “4th”, “5th”, “Last”}
\{“Sun”, “Mon”, “Tue”, “Wed”, “Thu”, “Fri”, “Sat”}
“Last” means the last day of the month
 -x (where x is in the range [-7, -1]) means
x day(s) before the last day of the month
 “1st”,”2nd”, etc. applied to a day of the
week identifies a single occurrence of that day within the month.
Allowable values:
or
 \{“Jan”, “Feb”, “Mar”, ‘’Apr”, “May”, “Jun”,
“Jul”, “Aug”, “Sep”, “Oct”, “Nov”, Dec”}
Allowable values:
[0,7] or
 \{“Sun”, “Mon”, “Tue”, “Wed”, “Thu”, “Fri”,
“Sat”}
“0” and “7” both refer to Sunday
Allowable values: a four-digit calendar year
_Examples:_
second = "10"
month= "Sep"
_Examples:_
_second = "*"_
_dayOfWeek = "*"_
_Examples:_
_second = "10,20,30"_
__
_dayOfWeek = "Mon,Wed,Fri"_
_minute = "0-10,30,40"_
_Examples:_
second= "1-10"
dayOfWeek = "Fri-Mon"
 dayOfMonth = "27-3" (Equivalent to "27-Last,
1-3")
 _Example:_ _Every five minutes within the
hour_
minute = "*/5"
minute = "0,5,10,15,20,25,30,35,40,45,50,55"
 _Example:_ Every 10 seconds within the
minute, starting at second 30
second = "30/10"
second = "30,40,50"
 _Example:_ _Every 14 minutes within the
hour, for the hours of 1 and 2 a.m._
(minute = "*/14", hour="1,2")
( minute = "0,14,28,42,56", hour = "1,2")
@Schedule(dayOfWeek="Mon")
 @Schedule(second="0", minute="0", hour="0",
dayOfMonth="*", month="*", dayOfWeek="Mon", year="*")
 @Schedule(minute="15", hour="3",
dayOfWeek="Mon-Fri")
 @Schedule(minute="15", hour="3",
timezone="America/New_York")
@Schedule(minute="*", hour="*")
 @Schedule(second="30", hour="12",
dayOfWeek="Mon,Wed,Fri"
@Schedule(minute="*/5", hour="*")
 @Schedule(hour="14", dayOfMonth="Last Thu",
month="Nov"}
@Schedule(hour="1", dayOfMonth="-1")
__
 _@Schedule(hour=_ " _12/2_ " _, dayOfMonth=_
" _2nd Tue_ ")
_Example:_
_Example:_
@Schedule(hour="11", dayOfWeek="Fri")
_Example:_
String timerInfo = t.getInfo();
...
_Example:_
Cache cache;
// Setup an automatic timer to refresh
 // the Singleton instance cache every 10
minutes
 @Schedule(minute="*/10", hour="*",
persistent=false)
public void refresh() \{
// ...
}
public Timer createTimer(long duration,
java.io.Serializable info);
 public Timer createTimer(java.util.Date
expiration,
java.io.Serializable info);
 public Timer createSingleActionTimer(long
duration,
TimerConfig timerConfig);
 public Timer
createSingleActionTimer(java.util.Date expiration,
TimerConfig timerConfig);
 public Timer createTimer(long
initialDuration,
 long intervalDuration, java.io.Serializable
info);
 public Timer createTimer(java.util.Date
initialExpiration,
 long intervalDuration, java.io.Serializable
info);
 public Timer createIntervalTimer(long
initialDuration,
 long intervalDuration, TimerConfig
timerConfig);
public Timer createIntervalTimer(
java.util.Date initialExpiration,
 long intervalDuration, TimerConfig
timerConfig);
 public Timer
createCalendarTimer(ScheduleExpression schedule);
 public Timer
createCalendarTimer(ScheduleExpression schedule,
TimerConfig timerConfig);
public Collection<Timer> getTimers();
public Collection<Timer> getAllTimers();
}
 new
ScheduleExpression().dayOfWeek("Sat").hour(1);
public void ejbTimeout(Timer timer);
_public interface javax.ejb.Timer \{_
_public void cancel();_
_public long getTimeRemaining();_
public java.util.Date getNextTimeout();
 public javax.ejb.ScheduleExpression
getSchedule();
_public javax.ejb.TimerHandle getHandle();_
public java.io.Serializable getInfo();
public boolean isPersistent();
public boolean isCalendarTimer();
_}_
public javax.ejb.Timer getTimer();
_Stateless_
_Stateful_
_MessageDriven_
 _Enterprise bean’s web service endpoint
interface._ If the bean class has a web service endpoint interface, and
the interface has not been specified using metadata annotations on the
bean class, the Bean Provider must specify the fully-qualified name of
the enterprise bean’s web service endpoint interface in the
_service-endpoint_ element. This element may only be used for stateless
session beans.
 _Re-entrancy indication_
. Session beans and message-driven beans are
never re-entrant.
 _Resource environment references_
. The Bean Provider must declare any
enterprise bean’s references to administered objects that are associated
with resources and that have not been defined by means of metadata
annotations, as specified in Subsection link:Ejb.html#a4344[See
Bean Provider’s Responsibilities].
 _Web service references_ . The Bean Provider
must declare any enterprise bean’s references to web service interfaces
that have not been defined by means of metadata annotations, as
specified in Subsection link:Ejb.html#a4154[See Web Service
References].
 _Persistence unit references_ . The Bean
Provider must declare any enterprise bean’s references to an entity
manager factory for a persistence unit that have not been defined by
means of metadata annotations, as specified in Subsection
link:Ejb.html#a4533[See Persistence Unit References].
 _Persistence context references_ . The Bean
Provider must declare any enterprise bean’s references to an entity
manager for a persistence context that have not been defined by means of
metadata annotations, as specified in Subsection
link:Ejb.html#a4671[See Persistence Context References].
 _Message destination references_ . The Bean
Provider must declare any enterprise bean’s references to message
destinations that have not been defined by means of metadata
annotations, as specified in Subsection link:Ejb.html#a4373[See
Bean Provider’s Responsibilities].
 _Message-driven bean’s configuration
properties. The Bean Provider may provide input to the Deployer as to
how a message-driven bean should be configured upon activation in its
operational environment. Activation configuration properties for a JMS
message-driven bean include information about a bean’s intended
destination type, its message selector, and its acknowledgement mode.
Other bean types may make use of different properties. See
link:Ejb.html#a9863[See Java EE™ Connector Architecture, version
1.7 (Connector). http://jcp.org/en/jsr/detail?id=322.]._
 _Message-driven bean’s destination._ The
Bean Provider may provide advice to the Application Assembler as to the
destination type to which a message-driven
bean should be assigned when linking message destinations
 _Interceptors._ The Bean Provider must
declare any interceptor classes and methods that have not been declared
by means of metadata annotations.
 _Singleton session bean initialization
ordering dependencies._ The Bean Provider may provide advice to the
Application Assembler as to the initialization ordering dependencies
among singleton session beans.
 _Message-driven bean message selector_ . The
Application Assembler may further restrict, but not replace, the value
of the _messageSelector_
_activation-config-property_ element of a JMS message-driven
bean—whether this was defined in metadata annotations or the deployment
descriptor.
 _Security identity_ . The Application
Assembler may specify whether the caller’s
security identity should be used for the
execution of the methods of an enterprise bean or whether a specific
run-as security identity should be used. The Application Assembler may
override a security identity defined by the Bean Provider—whether in
metadata annotations or in the deployment descriptor
 _Interceptors_ . The Application Assembler
may override, augment, and/or reorder the interceptor methods defined by
the Bean Provider—whether in metadata annotations or in the deployment
descriptor.
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
elementFormDefault=”qualified”
attributeFormDefault=”unqualified”
version=”3.2”>
<xsd:annotation>
<xsd:documentation>
 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR
THIS HEADER.
 Copyright (c) 2009-2013 Oracle and/or its
affiliates. All rights reserved.
 The contents of this file are subject to the
terms of either the GNU
 General Public License Version 2 only
(“GPL”) or the Common Development
 and Distribution License(“CDDL”)
(collectively, the “License”). You
 may not use this file except in compliance
with the License. You can
obtain a copy of the License at
 or packager/legal/LICENSE.txt. See the
License for the specific
 language governing permissions and
limitations under the License.
 When distributing the software, include this
License Header Notice in each file and include the License file at
packager/legal/LICENSE.txt.
GPL Classpath Exception:
 Oracle designates this particular file as
subject to the “Classpath”
 exception as provided by Oracle in the GPL
Version 2 section of the License file that accompanied this code.
Modifications:
 If applicable, add the following below the
License Header, with the fields
 enclosed by brackets [] replaced by your own
identifying information:
 “Portions Copyright [year] [name of
copyright owner]”
Contributor(s):
 If you wish your version of this file to be
governed by only the CDDL or
 elects to include this software in this
distribution under the [CDDL or GPL
 Version 2] license.” If you don’t indicate a
single choice of license, a recipient has the option to distribute your
version of this file under
 either the CDDL, the GPL Version 2 or to
extend the choice of license to
 its licensees as provided above. However, if
you add GPL Version 2 code
 and therefore, elected the GPL Version 2
license, then the option applies only if the new code is made subject to
such option by the copyright holder.
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 This is the XML Schema for the EJB 3.2
deployment descriptor.
All EJB deployment descriptors must indicate
the schema by using the Java EE namespace:
http://xmlns.jcp.org/xml/ns/javaee
 and by indicating the version of the schema
by
using the version element as shown below:
 <ejb-jar
xmlns=”http://xmlns.jcp.org/xml/ns/javaee”
version=”3.2”>
...
</ejb-jar>
 The instance documents may indicate the
published version of
 the schema using the xsi:schemaLocation
attribute for the
 Java EE namespace with the following
location:
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
 The following conventions apply to all Java
EE
 deployment descriptor elements unless
indicated otherwise.
 same JAR file, relative filenames (i.e.,
those not
 starting with “/”) are considered relative
to the root of
 the JAR file’s namespace. Absolute filenames
(i.e., those
 starting with “/”) also specify names in the
root of the
 JAR file’s namespace. In general, relative
names are
 preferred. The exception is .war files where
absolute
 names are preferred for consistency with the
Servlet API.
</xsd:documentation>
</xsd:annotation>
<xsd:include schemaLocation=”javaee_7.xsd”/>
<xsd:element name=”ejb-jar”
type=”javaee:ejb-jarType”>
<xsd:annotation>
<xsd:documentation>
 This is the root of the ejb-jar deployment
descriptor.
</xsd:documentation>
</xsd:annotation>
<xsd:key name=”ejb-name-key”>
<xsd:annotation>
<xsd:documentation>
 The ejb-name element contains the name of an
enterprise
 bean. The name must be unique within the
ejb-jar file or
.war file.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:enterprise-beans/*”/>
<xsd:field xpath=”javaee:ejb-name”/>
</xsd:key>
<xsd:keyref name=”ejb-name-references”
refer=”javaee:ejb-name-key”>
<xsd:annotation>
<xsd:documentation>
The keyref indicates the references from
 relationship-role-source must be to a
specific ejb-name
 defined within the scope of enterprise-beans
element.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=
<xsd:field xpath=”javaee:ejb-name”/>
</xsd:keyref>
<xsd:key name=”role-name-key”>
<xsd:annotation>
<xsd:documentation>
 A role-name-key is specified to allow the
references
from the security-role-refs.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:assembly-descriptor/javaee:security-role”/>
<xsd:field xpath=”javaee:role-name”/>
</xsd:key>
<xsd:keyref name=”role-name-references”
refer=”javaee:role-name-key”>
<xsd:annotation>
<xsd:documentation>
The keyref indicates the references from
security-role-ref to a specified role-name.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=
<xsd:field xpath=”javaee:role-link”/>
</xsd:keyref>
</xsd:element>
<xsd:complexType name=”access-timeoutType”>
<xsd:annotation>
<xsd:documentation>
 The access-timeoutType represents the
maximum amount of
 time (in a given time unit) that the
container should wait for
 a concurrency lock before throwing a timeout
exception to the
client.
 A timeout value of 0 means concurrent access
is not permitted.
 A timeout value of -1 means wait
indefinitely to acquire a lock.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”timeout”
type=”javaee:xsdIntegerType”/>
<xsd:element name=”unit”
type=”javaee:time-unit-typeType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”async-methodType”>
<xsd:annotation>
<xsd:documentation>
 The async-methodType element specifies that
a session
 bean method has asynchronous invocation
semantics.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”method-name”
type=”javaee:string”/>
<xsd:element name=”method-params”
type=”javaee:method-paramsType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”activation-configType”>
<xsd:annotation>
<xsd:documentation>
 The activation-configType defines
information about the
 expected configuration properties of the
message-driven bean
 in its operational environment. This may
include information
 about message acknowledgement, message
selector, expected
 destination type, destination or connection
factory lookup
string, subscription name, etc.
 The configuration information is expressed
in terms of
name/value configuration properties.
 The properties that are recognized for a
particular
 message-driven bean are determined by the
messaging type.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
 <xsd:element
name=”activation-config-property”
type=”javaee:activation-config-propertyType”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”activation-config-propertyType”>
<xsd:annotation>
<xsd:documentation>
 The activation-config-propertyType contains
a name/value
 configuration property pair for a
message-driven bean.
 The properties that are recognized for a
particular
 message-driven bean are determined by the
messaging type.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
 <xsd:element
name=”activation-config-property-name”
type=”javaee:xsdStringType”>
<xsd:annotation>
<xsd:documentation>
 The activation-config-property-name element
contains
 the name for an activation configuration
property of
a message-driven bean.
 For JMS message-driven beans, the following
property
names are recognized: acknowledgeMode,
 messageSelector, destinationType,
subscriptionDurability,
 destinationLookup, connectionFactoryLookup,
subscriptionName,
and clientId.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
 <xsd:element
name=”activation-config-property-value”
type=”javaee:xsdStringType”>
<xsd:annotation>
<xsd:documentation>
The activation-config-property-value element
 contains the value for an activation
configuration
property of a message-driven bean.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”around-invokeType”>
<xsd:annotation>
<xsd:documentation>
 The around-invoke type specifies a method on
a
 class to be called during the around invoke
portion of an
 ejb invocation. Note that each class may
have only one
 around invoke method and that the method may
not be
overloaded.
If the class element is missing then
 the class defining the callback is assumed
to be the
 interceptor class or component class in
scope at the
 location in the descriptor in which the
around invoke
definition appears.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”class”
type=”javaee:fully-qualified-classType”
minOccurs=”0”/>
<xsd:element name=”method-name”
type=”javaee:java-identifierType”/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=”around-timeoutType”>
<xsd:annotation>
<xsd:documentation>
 The around-timeout type specifies a method
on a
 class to be called during the around-timeout
portion of
 a timer timeout callback. Note that each
class may have
 only one around-timeout method and that the
method may not
be overloaded.
If the class element is missing then
 the class defining the callback is assumed
to be the
 interceptor class or component class in
scope at the
 location in the descriptor in which the
around-timeout
definition appears.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”class”
type=”javaee:fully-qualified-classType”
minOccurs=”0”/>
<xsd:element name=”method-name”
type=”javaee:java-identifierType”/>
</xsd:sequence>
</xsd:complexType>
 <xsd:complexType
name=”assembly-descriptorType”>
<xsd:annotation>
<xsd:documentation>
The assembly-descriptorType defines
application-assembly information.
 The application-assembly information
consists of the
 following parts: the definition of security
roles, the
 definition of method permissions, the
definition of
 transaction attributes for enterprise beans
with
 container-managed transaction demarcation,
the definition
of interceptor bindings, a list of
 methods to be excluded from being invoked,
and a list of
 exception types that should be treated as
application exceptions.
 All the parts are optional in the sense that
they are
 omitted if the lists represented by them are
empty.
 Providing an assembly-descriptor in the
deployment
 descriptor is optional for the ejb-jar file
or .war file producer.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”security-role”
type=”javaee:security-roleType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”method-permission”
type=”javaee:method-permissionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”container-transaction”
type=”javaee:container-transactionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”interceptor-binding”
type=”javaee:interceptor-bindingType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”message-destination”
type=”javaee:message-destinationType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”exclude-list”
type=”javaee:exclude-listType”
minOccurs=”0”/>
<xsd:element name=”application-exception”
type=”javaee:application-exceptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”cmp-fieldType”>
<xsd:annotation>
<xsd:documentation>
 The cmp-fieldType describes a
container-managed field. The
 cmp-fieldType contains an optional
description of the field,
and the name of the field.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”field-name”
type=”javaee:java-identifierType”>
<xsd:annotation>
<xsd:documentation>
 The field-name element specifies the name of
a
container managed field.
 The name of the cmp-field of an entity bean
with
cmp-version 2.x must begin with a lowercase
 letter. This field is accessed by methods
whose
 names consists of the name of the field
specified by
 field-name in which the first letter is
uppercased,
prefixed by “get” or “set”.
 The name of the cmp-field of an entity bean
with
 cmp-version 1.x must denote a public field
of the
 enterprise bean class or one of its
superclasses.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”cmp-versionType”>
<xsd:annotation>
<xsd:documentation>
 The cmp-versionType specifies the version of
an entity bean
 with container-managed persistence. It is
used by
cmp-version elements.
The value must be one of the two following:
1.x
2.x
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”1.x”/>
<xsd:enumeration value=”2.x”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”cmr-fieldType”>
<xsd:annotation>
<xsd:documentation>
 The cmr-fieldType describes the Bean
Provider’s view of
 a relationship. It consists of an optional
description, and
 the name and the class type of a field in
the source of a
 role of a relationship. The cmr-field-name
element
 corresponds to the name used for the get and
set accessor
 methods for the relationship. The
cmr-field-type element is
 used only for collection-valued cmr-fields.
It specifies the
type of the collection that is used.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”cmr-field-name”
type=”javaee:string”>
<xsd:annotation>
<xsd:documentation>
 The cmr-field-name element specifies the
name of a
 logical relationship field in the entity
bean
 class. The name of the cmr-field must begin
with a
 lowercase letter. This field is accessed by
methods
whose names consist of the name of the field
 specified by cmr-field-name in which the
first
 letter is uppercased, prefixed by “get” or
“set”.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”cmr-field-type”
type=”javaee:cmr-field-typeType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”cmr-field-typeType”>
<xsd:annotation>
<xsd:documentation>
 The cmr-field-type element specifies the
class of a
 collection-valued logical relationship field
in the entity
 bean class. The value of an element using
cmr-field-typeType
 must be either: java.util.Collection or
java.util.Set.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
 <xsd:enumeration
value=”java.util.Collection”/>
<xsd:enumeration value=”java.util.Set”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”concurrency-management-typeType”>
<xsd:annotation>
<xsd:documentation>
 The concurrency-management-typeType
specifies the way concurrency
 is managed for a singleton or stateful
session bean.
 The concurrency management type must be one
of the following:
Bean
Container
 Bean managed concurrency can only be
specified for a singleton bean.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Bean”/>
<xsd:enumeration value=”Container”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”concurrent-lock-typeType”>
<xsd:annotation>
<xsd:documentation>
 The concurrent-lock-typeType specifies how
the container must
 manage concurrent access to a method of a
Singleton bean
with container-managed concurrency.
 The container managed concurrency lock type
must be one
of the following :
Read
Write
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Read”/>
<xsd:enumeration value=”Write”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”concurrent-methodType”>
<xsd:annotation>
<xsd:documentation>
 The concurrent-methodType specifies
information about a method
 of a bean with container managed
concurrency.
 The optional lock element specifies the kind
of concurrency
lock asssociated with the method.
 The optional access-timeout element
specifies the amount of
 time (in a given time unit) the container
should wait for a
 concurrency lock before throwing an
exception to the client.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”method”
type=”javaee:named-methodType”/>
<xsd:element name=”lock”
type=”javaee:concurrent-lock-typeType”
minOccurs=”0”/>
<xsd:element name=”access-timeout”
type=”javaee:access-timeoutType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”container-transactionType”>
<xsd:annotation>
<xsd:documentation>
 The container-transactionType specifies how
the container
 must manage transaction scopes for the
enterprise bean’s
 method invocations. It defines an optional
description, a
 list of method elements, and a transaction
attribute. The
 transaction attribute is to be applied to
all the specified
methods.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”method”
type=”javaee:methodType”
maxOccurs=”unbounded”/>
<xsd:element name=”trans-attribute”
type=”javaee:trans-attributeType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”depends-onType”>
<xsd:annotation>
<xsd:documentation>
 The depends-onType is used to express
initialization
 ordering dependencies between Singleton
components.
 The depends-onType specifies the names of
one or more
 Singleton beans in the same application as
the referring
 Singleton, each of which must be initialized
before
the referring bean.
 Each dependent bean is expressed using
ejb-link syntax.
 The order in which dependent beans are
initialized at
 runtime is not guaranteed to match the order
in which
they are listed.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”ejb-name”
type=”javaee:ejb-linkType”
minOccurs=”1”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”ejb-classType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The ejb-classType contains the
fully-qualified name of the
 enterprise bean’s class. It is used by
ejb-class elements.
Example:
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
 <xsd:restriction
base=”javaee:fully-qualified-classType”/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”ejb-jarType”>
<xsd:annotation>
<xsd:documentation>
 The ejb-jarType defines the root element of
the EJB
deployment descriptor. It contains
icon file name
 stand-alone ejb-jars or ejb-jars packaged in
an ear.
 Ignored if specified for an ejb-jar.xml
within a .war file.
 In that case, standard .war file module-name
rules apply.
 enterprise beans that is not specified
through
annotations
if any.
ejb-jar.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”module-name”
type=”javaee:string”
minOccurs=”0”/>
<xsd:group ref=”javaee:descriptionGroup”/>
<xsd:element name=”enterprise-beans”
type=”javaee:enterprise-beansType”
minOccurs=”0”/>
<xsd:element name=”interceptors”
type=”javaee:interceptorsType”
minOccurs=”0”/>
<xsd:element name=”relationships”
type=”javaee:relationshipsType”
minOccurs=”0”>
 <xsd:unique
name=”relationship-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
The ejb-relation-name contains the name of a
relation. The name must be unique within
relationships.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-relation”/>
 <xsd:field
xpath=”javaee:ejb-relation-name”/>
</xsd:unique>
</xsd:element>
<xsd:element name=”assembly-descriptor”
type=”javaee:assembly-descriptorType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 Providing an assembly-descriptor in the
deployment
 descriptor is optional for the ejb-jar file
or .war file
producer.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”ejb-client-jar”
type=”javaee:pathType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The optional ejb-client-jar element
specifies a JAR
 file that contains the class files necessary
for a
client program to access the
enterprise beans in the ejb-jar file.
Example:
<ejb-client-jar>employee_service_client.jar
</ejb-client-jar>
]]>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”version”
type=”javaee:dewey-versionType”
fixed=”3.2”
use=”required”>
<xsd:annotation>
<xsd:documentation>
The version specifies the version of the
 EJB specification that the instance document
must
 comply with. This information enables
deployment tools
to validate a particular EJB Deployment
 Descriptor with respect to a specific
version of the EJB
schema.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name=”metadata-complete”
type=”xsd:boolean”>
<xsd:annotation>
<xsd:documentation>
 The metadata-complete attribute defines
whether this
 deployment descriptor and other related
deployment
 descriptors for this module (e.g., web
service
 descriptors) are complete, or whether the
class
 files available to this module and packaged
with
 this application should be examined for
annotations
that specify deployment information.
 If metadata-complete is set to “true”, the
deployment
 tool must ignore any annotations that
specify deployment
 information, which might be present in the
class files
of the application.
 If metadata-complete is not specified or is
set to
 “false”, the deployment tool must examine
the class
files of the application for annotations, as
specified by the specifications.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”ejb-nameType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The ejb-nameType specifies an enterprise
bean’s name. It is
 used by ejb-name elements. This name is
assigned by the
 file producer to name the enterprise bean in
the
 ejb-jar file or .war file’s deployment
descriptor. The name must be
 unique among the names of the enterprise
beans in the same
ejb-jar file or .war file.
 There is no architected relationship between
the used
 ejb-name in the deployment descriptor and
the JNDI name that
 the Deployer will assign to the enterprise
bean’s home.
 The name for an entity bean must conform to
the lexical
rules for an NMTOKEN.
Example:
<ejb-name>EmployeeService</ejb-name>
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
 <xsd:restriction
base=”javaee:xsdNMTOKENType”/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”ejb-relationType”>
<xsd:annotation>
<xsd:documentation>
 The ejb-relationType describes a
relationship between two
 entity beans with container-managed
persistence. It is used
 by ejb-relation elements. It contains a
description; an
 optional ejb-relation-name element; and
exactly two
 relationship role declarations, defined by
the
 ejb-relationship-role elements. The name of
the
 relationship, if specified, is unique within
the ejb-jar
file.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”ejb-relation-name”
type=”javaee:string”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The ejb-relation-name element provides a
unique name
within the ejb-jar file for a relationship.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”ejb-relationship-role”
type=”javaee:ejb-relationship-roleType”
minOccurs=”2”
maxOccurs=”2”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”ejb-relationship-roleType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The ejb-relationship-roleType describes a
role within a
 relationship. There are two roles in each
relationship.
 The ejb-relationship-roleType contains an
optional
 description; an optional name for the
relationship role; a
 specification of the multiplicity of the
role; an optional
 specification of cascade-delete
functionality for the role;
 the role source; and a declaration of the
cmr-field, if any,
 by means of which the other side of the
relationship is
 accessed from the perspective of the role
source.
 The multiplicity and role-source element are
mandatory.
 The relationship-role-source element
designates an entity
 bean by means of an ejb-name element. For
bidirectional
 relationships, both roles of a relationship
must declare a
 relationship-role-source element that
specifies a cmr-field
 in terms of which the relationship is
accessed. The lack of
 a cmr-field element in an
ejb-relationship-role specifies
 that the relationship is unidirectional in
navigability and
 the entity bean that participates in the
relationship is
“not aware” of the relationship.
Example:
<ejb-relation>
<ejb-relationship-role>
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>ProductEJB</ejb-name>
</relationship-role-source>
</ejb-relationship-role>
</ejb-relation>
 Support for entity beans is optional as of
EJB 3.2.
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
 <xsd:element
name=”ejb-relationship-role-name”
type=”javaee:string”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The ejb-relationship-role-name element
defines a
name for a role that is unique within an
 ejb-relation. Different relationships can
use the
same name for a role.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”multiplicity”
type=”javaee:multiplicityType”/>
<xsd:element name=”cascade-delete”
type=”javaee:emptyType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The cascade-delete element specifies that,
within a
 particular relationship, the lifetime of one
or more
 entity beans is dependent upon the lifetime
of
 another entity bean. The cascade-delete
element can
 only be specified for an
ejb-relationship-role
 element contained in an ejb-relation element
in
which the other ejb-relationship-role
element specifies a multiplicity of One.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”relationship-role-source”
type=”javaee:relationship-role-sourceType”/>
<xsd:element name=”cmr-field”
type=”javaee:cmr-fieldType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”enterprise-beansType”>
<xsd:annotation>
<xsd:documentation>
 The enterprise-beansType declares one or
more enterprise
 beans. Each bean can be a session, entity or
message-driven
bean.
</xsd:documentation>
</xsd:annotation>
<xsd:choice maxOccurs=”unbounded”>
<xsd:element name=”session”
type=”javaee:session-beanType”>
 <xsd:unique
name=”session-ejb-local-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of
 an EJB reference. The EJB reference is an
entry in
 the component’s environment and is relative
to the
 java:comp/env context. The name must be
unique within
the component.
 It is recommended that name be prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-local-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”session-ejb-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of an EJB
 reference. The EJB reference is an entry in
the
 component’s environment and is relative to
the
 java:comp/env context. The name must be
unique
within the component.
 It is recommended that name is prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”session-resource-env-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The resource-env-ref-name element specifies
the name
 of a resource environment reference; its
value is
 the environment entry name used in the
component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:resource-env-ref”/>
 <xsd:field
xpath=”javaee:resource-env-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”session-message-destination-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The message-destination-ref-name element
specifies the name
 of a message destination reference; its
value is
 the message destination reference name used
in the component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:message-destination-ref”/>
 <xsd:field
xpath=”javaee:message-destination-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”session-res-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The res-ref-name element specifies the name
of a
 resource manager connection factory
reference. The name
 is a JNDI name relative to the java:comp/env
context.
The name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:resource-ref”/>
<xsd:field xpath=”javaee:res-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”session-env-entry-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The env-entry-name element contains the name
of a
 component’s environment entry. The name is a
JNDI
 name relative to the java:comp/env context.
The
name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:env-entry”/>
<xsd:field xpath=”javaee:env-entry-name”/>
</xsd:unique>
</xsd:element>
<xsd:element name=”entity”
type=”javaee:entity-beanType”>
 <xsd:unique
name=”entity-ejb-local-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of
 an EJB reference. The EJB reference is an
entry in
 the component’s environment and is relative
to the
 java:comp/env context. The name must be
unique within
the component.
 It is recommended that name be prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-local-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”entity-ejb-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of an EJB
 reference. The EJB reference is an entry in
the
 component’s environment and is relative to
the
 java:comp/env context. The name must be
unique
within the component.
 It is recommended that name is prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”entity-resource-env-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The resource-env-ref-name element specifies
the name
 of a resource environment reference; its
value is
 the environment entry name used in the
component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:resource-env-ref”/>
 <xsd:field
xpath=”javaee:resource-env-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”entity-message-destination-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The message-destination-ref-name element
specifies the name
 of a message destination reference; its
value is
 the message destination reference name used
in the component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:message-destination-ref”/>
 <xsd:field
xpath=”javaee:message-destination-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”entity-res-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The res-ref-name element specifies the name
of a
 resource manager connection factory
reference. The name
 is a JNDI name relative to the java:comp/env
context.
The name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:resource-ref”/>
<xsd:field xpath=”javaee:res-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”entity-env-entry-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The env-entry-name element contains the name
of a
 component’s environment entry. The name is a
JNDI
 name relative to the java:comp/env context.
The
name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:env-entry”/>
<xsd:field xpath=”javaee:env-entry-name”/>
</xsd:unique>
</xsd:element>
<xsd:element name=”message-driven”
type=”javaee:message-driven-beanType”>
 <xsd:unique
name=”messaged-ejb-local-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of
 an EJB reference. The EJB reference is an
entry in
 the component’s environment and is relative
to the
 java:comp/env context. The name must be
unique within
the component.
 It is recommended that name be prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-local-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”messaged-ejb-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-ref-name element contains the name
of an EJB
 reference. The EJB reference is an entry in
the
 component’s environment and is relative to
the
 java:comp/env context. The name must be
unique
within the component.
 It is recommended that name is prefixed with
“ejb/”.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:ejb-ref”/>
<xsd:field xpath=”javaee:ejb-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”messaged-resource-env-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The resource-env-ref-name element specifies
the name
 of a resource environment reference; its
value is
 the environment entry name used in the
component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:resource-env-ref”/>
 <xsd:field
xpath=”javaee:resource-env-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”messaged-message-destination-ref-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The message-destination-ref-name element
specifies the name
 of a message destination reference; its
value is
 the message destination reference name used
in the component
 code. The name is a JNDI name relative to
the
 java:comp/env context and must be unique
within an
component.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”javaee:message-destination-ref”/>
 <xsd:field
xpath=”javaee:message-destination-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”messaged-res-ref-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The res-ref-name element specifies the name
of a
 resource manager connection factory
reference. The name
 is a JNDI name relative to the java:comp/env
context.
The name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:resource-ref”/>
<xsd:field xpath=”javaee:res-ref-name”/>
</xsd:unique>
 <xsd:unique
name=”messaged-env-entry-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The env-entry-name element contains the name
of a
 component’s environment entry. The name is a
JNDI
 name relative to the java:comp/env context.
The
name must be unique within an component.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath=”javaee:env-entry”/>
<xsd:field xpath=”javaee:env-entry-name”/>
</xsd:unique>
</xsd:element>
</xsd:choice>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”entity-beanType”>
<xsd:annotation>
<xsd:documentation>
 Support for entity beans is optional as of
EJB 3.2.
 The entity-beanType declares an entity bean.
The declaration
consists of:
icon file name
in the deployment descriptor
 vendor-specific deployment information such
as the physical
 jndi-name of the entity bean’s remote home
interface. This
 element is not required to be supported by
all implementations.
Any use of this element is non-portable.
and remote interfaces, if any
interfaces, if any
 this element is not specified it is
defaulted to Container.
entity bean’s cmp-version
abstract schema name
field
entries
references
EJB references
service references
references
 to be used for the execution of the bean’s
methods
 resource manager connection factory
references
resource environment references
destination references
for finder and select methods for an entity
bean with cmp-version 2.x.
 The optional abstract-schema-name element
must be specified
 for an entity bean with container-managed
persistence and
cmp-version 2.x.
 The optional primkey-field may be present in
the descriptor
 if the entity’s persistence-type is
Container.
 The optional cmp-version element may be
present in the
 descriptor if the entity’s persistence-type
is Container. If
 the persistence-type is Container and the
cmp-version
 element is not specified, its value defaults
to 2.x.
 The optional home and remote elements must
be specified if
the entity bean cmp-version is 1.x.
 The optional home and remote elements must
be specified if
 the entity bean has a remote home and remote
interface.
 The optional local-home and local elements
must be specified
 if the entity bean has a local home and
local interface.
 Either both the local-home and the local
elements or both
 the home and the remote elements must be
specified.
 The optional query elements must be present
if the
 persistence-type is Container and the
cmp-version is 2.x and
 query methods other than findByPrimaryKey
have been defined
for the entity bean.
 The other elements that are optional are
“optional” in the
 sense that they are omitted if the lists
represented by them
are empty.
 At least one cmp-field element must be
present in the
 descriptor if the entity’s persistence-type
is Container and
 the cmp-version is 1.x, and none must not be
present if the
entity’s persistence-type is Bean.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:group ref=”javaee:descriptionGroup”/>
<xsd:element name=”ejb-name”
type=”javaee:ejb-nameType”/>
<xsd:element name=”mapped-name”
type=”javaee:xsdStringType”
minOccurs=”0”/>
<xsd:element name=”home”
type=”javaee:homeType”
minOccurs=”0”/>
<xsd:element name=”remote”
type=”javaee:remoteType”
minOccurs=”0”/>
<xsd:element name=”local-home”
type=”javaee:local-homeType”
minOccurs=”0”/>
<xsd:element name=”local”
type=”javaee:localType”
minOccurs=”0”/>
<xsd:element name=”ejb-class”
type=”javaee:ejb-classType”/>
<xsd:element name=”persistence-type”
type=”javaee:persistence-typeType”/>
<xsd:element name=”prim-key-class”
type=”javaee:fully-qualified-classType”>
<xsd:annotation>
<xsd:documentation>
The prim-key-class element contains the
fully-qualified name of an
entity bean’s primary key class.
 If the definition of the primary key class
is
 deferred to deployment time, the
prim-key-class
element should specify java.lang.Object.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”reentrant”
type=”javaee:true-falseType”>
<xsd:annotation>
<xsd:documentation>
 The reentrant element specifies whether an
entity
bean is reentrant or not.
The reentrant element must be one of the two
following: true or false
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”cmp-version”
type=”javaee:cmp-versionType”
minOccurs=”0”/>
<xsd:element name=”abstract-schema-name”
type=”javaee:java-identifierType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The abstract-schema-name element specifies
the name
 of the abstract schema type of an entity
bean with
 cmp-version 2.x. It is used in EJB QL
queries.
 For example, the abstract-schema-name for an
entity
bean whose local interface is
com.acme.commerce.Order might be Order.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”cmp-field”
type=”javaee:cmp-fieldType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”primkey-field”
type=”javaee:string”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The primkey-field element is used to specify
the
 name of the primary key field for an entity
with
container-managed persistence.
 The primkey-field must be one of the fields
declared
 in the cmp-field element, and the type of
the field
must be the same as the primary key type.
 The primkey-field element is not used if the
primary
 key maps to multiple container-managed
fields
 (i.e. the key is a compound key). In this
case, the
 fields of the primary key class must be
public, and
 their names must correspond to the field
names of
the entity bean class that comprise the key.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
 <xsd:group
ref=”javaee:jndiEnvironmentRefsGroup”/>
<xsd:element name=”security-role-ref”
type=”javaee:security-role-refType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”security-identity”
type=”javaee:security-identityType”
minOccurs=”0”/>
<xsd:element name=”query”
type=”javaee:queryType”
minOccurs=”0”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”exclude-listType”>
<xsd:annotation>
<xsd:documentation>
 The exclude-listType specifies one or more
methods which
the Assembler marks to be uncallable.
 If the method permission relation contains
methods that are
 in the exclude list, the Deployer should
consider those
methods to be uncallable.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”method”
type=”javaee:methodType”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”application-exceptionType”>
<xsd:annotation>
<xsd:documentation>
 The application-exceptionType declares an
application
exception. The declaration consists of:
an exception of this type, it is required to
 forward this exception as an applcation
exception
 to the client regardless of whether it is a
checked
or unchecked exception.
 set to true, the container must rollback the
current
 transaction before forwarding the exception
to the
 client. If not specified, it defaults to
false.
 set to true, subclasses of the exception
class type
 are also automatically considered
application
 exceptions (unless overriden at a lower
level).
 If set to false, only the exception class
type is
considered an application-exception, not its
exception subclasses. If not specified, this
value defaults to true.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”exception-class”
type=”javaee:fully-qualified-classType”/>
<xsd:element name=”rollback”
type=”javaee:true-falseType”
minOccurs=”0”/>
<xsd:element name=”inherited”
type=”javaee:true-falseType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”interceptorsType”>
<xsd:annotation>
<xsd:documentation>
 The interceptorsType element declares one or
more interceptor
 classes used by components within this
ejb-jar file or .war file.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”interceptor”
type=”javaee:interceptorType”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”interceptorType”>
<xsd:annotation>
<xsd:documentation>
 The interceptorType element declares
information about a single
interceptor class. It consists of :
interceptor class and/or its super-classes.
interceptor class and/or its super-classes.
class and/or its super-classes.
interceptor class and/or its super-classes.
interceptor class and/or its super-classes.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”interceptor-class”
type=”javaee:fully-qualified-classType”/>
<xsd:element name=”around-invoke”
type=”javaee:around-invokeType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”around-timeout”
type=”javaee:around-timeoutType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”around-construct”
type=”javaee:lifecycle-callbackType”
minOccurs=”0”
maxOccurs=”unbounded”/>
 <xsd:group
ref=”javaee:jndiEnvironmentRefsGroup”/>
<xsd:element name=”post-activate”
type=”javaee:lifecycle-callbackType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”pre-passivate”
type=”javaee:lifecycle-callbackType”
minOccurs=”0”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”interceptor-bindingType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The interceptor-bindingType element
describes the binding of
 interceptor classes to beans within the
ejb-jar file or .war file.
It consists of :
 which is used to define interceptors that
are bound to all
beans in the ejb-jar file or .war file.
 the ejb-name element or a specification of
the total ordering
 over the interceptors defined for the given
level and above.
 specifies that default interceptors are not
to be applied to
a bean-class and/or business method.
 specifies that class interceptors are not to
be applied to
a business method.
of a method-level interceptor.
 Interceptors bound to all classes using the
wildcard syntax
 “*” are default interceptors for the
components in the ejb-jar file or
.war file.
 In addition, interceptors may be bound at
the level of the bean
 class (class-level interceptors) or business
methods (method-level
interceptors ).
 The binding of interceptors to classes is
additive. If interceptors
 are bound at the class-level and/or
default-level as well as the
 method-level, both class-level and/or
default-level as well as
method-level will apply.
 The method-name element may be used to bind
a constructor-level
 interceptor using the unqualified name of
the bean class as the value;
 the optional method-params elements identify
the constructor if a bean
 class has a constructor annotated with the
Inject annotation in
addition to a no-arg constructor.
 There are four possible styles of the
interceptor element syntax :
1.
<interceptor-binding>
<ejb-name>*</ejb-name>
</interceptor-binding>
 Specifying the ejb-name as the wildcard
value “*” designates
 default interceptors (interceptors that
apply to all session and
 message-driven beans contained in the
ejb-jar file or .war file).
2.
<interceptor-binding>
<ejb-name>EJBNAME</ejb-name>
</interceptor-binding>
 This style is used to refer to interceptors
associated with the
 specified enterprise bean(class-level
interceptors).
3.
<interceptor-binding>
<ejb-name>EJBNAME</ejb-name>
<method>
<method-name>METHOD</method-name>
</method>
</interceptor-binding>
 This style is used to associate a
method-level interceptor with
 the specified enterprise bean. If there are
multiple methods
 with the same overloaded name, the element
of this style refers
 to all the methods with the overloaded name.
Method-level
 interceptors can only be associated with
business methods of the
 bean class. Note that the wildcard value “*”
cannot be used
to specify method-level interceptors.
4.
<interceptor-binding>
<ejb-name>EJBNAME</ejb-name>
<method>
<method-name>METHOD</method-name>
<method-params>
<method-param>PARAM-1</method-param>
<method-param>PARAM-2</method-param>
...
<method-param>PARAM-N</method-param>
</method-params>
</method>
</interceptor-binding>
 This style is used to associate a
method-level interceptor with
 the specified method of the specified
enterprise bean. This
 style is used to refer to a single method
within a set of methods
 with an overloaded name. The values PARAM-1
through PARAM-N
 are the fully-qualified Java types of the
method’s input parameters
 (if the method has no input arguments, the
method-params element
 contains no method-param elements). Arrays
are specified by the
 array element’s type, followed by one or
more pair of square
brackets (e.g. int[][]).
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”ejb-name”
type=”javaee:string”/>
<xsd:choice>
<xsd:element name=”interceptor-class”
type=”javaee:fully-qualified-classType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”interceptor-order”
type=”javaee:interceptor-orderType”
minOccurs=”1”/>
</xsd:choice>
 <xsd:element
name=”exclude-default-interceptors”
type=”javaee:true-falseType”
minOccurs=”0”/>
 <xsd:element
name=”exclude-class-interceptors”
type=”javaee:true-falseType”
minOccurs=”0”/>
<xsd:element name=”method”
type=”javaee:named-methodType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”interceptor-orderType”>
<xsd:annotation>
<xsd:documentation>
 The interceptor-orderType element describes
a total ordering
of interceptor classes.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”interceptor-class”
type=”javaee:fully-qualified-classType”
minOccurs=”1”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”named-methodType”>
<xsd:sequence>
<xsd:element name=”method-name”
type=”javaee:string”/>
<xsd:element name=”method-params”
type=”javaee:method-paramsType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”init-methodType”>
<xsd:sequence>
<xsd:element name=”create-method”
type=”javaee:named-methodType”/>
<xsd:element name=”bean-method”
type=”javaee:named-methodType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”remove-methodType”>
<xsd:sequence>
<xsd:element name=”bean-method”
type=”javaee:named-methodType”/>
<xsd:element name=”retain-if-exception”
type=”javaee:true-falseType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”message-driven-beanType”>
<xsd:annotation>
<xsd:documentation>
 The message-driven element declares a
message-driven
bean. The declaration consists of:
icon file name.
the deployment descriptor
 vendor-specific deployment information such
as the physical
 jndi-name of destination from which this
message-driven bean
 should consume. This element is not required
to be supported
 by all implementations. Any use of this
element is non-portable.
type
handling programmatically created timers
deployment time
 type. If it is not defined, it is defaulted
to Container.
message-destination-type
message-destination-link
activation configuration properties
superclass around-invoke methods.
superclass around-timeout methods.
entries
references
references
references
 identity to be used for the execution of the
bean’s
methods
resource manager connection factory
references
environment references.
destination references
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:group ref=”javaee:descriptionGroup”/>
<xsd:element name=”ejb-name”
type=”javaee:ejb-nameType”/>
<xsd:element name=”mapped-name”
type=”javaee:xsdStringType”
minOccurs=”0”/>
<xsd:element name=”ejb-class”
type=”javaee:ejb-classType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The ejb-class element specifies the fully
qualified name
 of the bean class for this ejb. It is
required unless
 there is a component-defining annotation for
the same
ejb-name.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”messaging-type”
type=”javaee:fully-qualified-classType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The messaging-type element specifies the
message
 listener interface of the message-driven
bean.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”timeout-method”
type=”javaee:named-methodType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The timeout-method element specifies the
method that
will receive callbacks for programmatically
created timers.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”timer”
type=”javaee:timerType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”transaction-type”
type=”javaee:transaction-typeType”
minOccurs=”0”/>
<xsd:element name=”message-destination-type”
type=”javaee:message-destination-typeType”
minOccurs=”0”/>
<xsd:element name=”message-destination-link”
type=”javaee:message-destination-linkType”
minOccurs=”0”/>
<xsd:element name=”activation-config”
type=”javaee:activation-configType”
minOccurs=”0”/>
<xsd:element name=”around-invoke”
type=”javaee:around-invokeType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”around-timeout”
type=”javaee:around-timeoutType”
minOccurs=”0”
maxOccurs=”unbounded”/>
 <xsd:group
ref=”javaee:jndiEnvironmentRefsGroup”/>
<xsd:element name=”security-role-ref”
type=”javaee:security-role-refType”
minOccurs=”0”
maxOccurs=”unbounded”>
</xsd:element>
<xsd:element name=”security-identity”
type=”javaee:security-identityType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”methodType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The methodType is used to denote a method of
an enterprise
 bean. The method may be any of the following
or a set of
 any of the following methods may be
designated:
business interface method
home interface method
component interface method
web service endpoint interface method
no-interface view method
 singleton session bean lifecycle callback
method
 stateful session bean lifecycle callback
method (see
limitations)
timeout callback method
message-driven bean message listener method
 The ejb-name element must be the name of one
of the enterprise
beans declared in the deployment descriptor.
 The optional method-intf element allows
distinguishing between a
 method with the same signature that is
multiply defined
across any of the above.
 The method-name element specifies the method
name.
 The optional method-params elements identify
a single method
 among multiple methods with an overloaded
method name.
 There are three possible styles of using
methodType element
within a method element:
1.
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>*</method-name>
</method>
 This style is used to refer to all of the
following methods
of the specified enterprise bean:
business interface methods
home interface methods
component interface methods
web service endpoint interface methods
no-interface view methods
 singleton session bean lifecycle callback
methods
timeout callback methods
message-driven bean message listener method
 This style may also be used in combination
with the
 method-intf element that contains
LifecycleCallback as
 the value to specify transaction attributes
of a stateful
 session bean PostConstruct, PreDestroy,
PrePassivate,
 and PostActivate lifecycle callback methods
or to override
 transaction attributes of a singleton
session bean
 PostConstruct and PreDestroy lifecycle
callback methods.
2.
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>METHOD</method-name>
</method>
 This style is used to refer to the specified
method of
 the specified enterprise bean. If there are
multiple
 methods with the same overloaded name, the
element of
 this style refers to all the methods with
the overloaded
name.
 This style may be used to refer to stateful
session bean
 PostConstruct, PreDestroy, PrePassivate, and
PostActivate
 lifecycle callback methods to specify their
transaction
attributes if any of the following is true:
 there is only one method with this name in
the specified
enterprise bean
 all overloaded methods with this name in the
specified
 enterprise bean are lifecycle callback
methods
 method-intf element is specified and it
contains
LifecycleCallback as the value
3.
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>METHOD</method-name>
<method-params>
<method-param>PARAM-1</method-param>
<method-param>PARAM-2</method-param>
...
<method-param>PARAM-n</method-param>
</method-params>
</method>
 This style is used to refer to a single
method within a
 set of methods with an overloaded name.
PARAM-1 through
 PARAM-n are the fully-qualified Java types
of the
 method’s input parameters (if the method has
no input
 arguments, the method-params element
contains no
 method-param elements). Arrays are specified
by the
 array element’s type, followed by one or
more pair of
square brackets (e.g. int[][]).
 If a method with the same name and signature
is defined
 on more than one interface of an enterprise
bean, this
style refers to all those methods.
Examples:
 Style 1: The following method element refers
to all of the
 following methods of the EmployeeService
bean:
no interface view methods
business interface methods
home interface methods
component business interface methods
 singleton session bean lifecycle callback
methods, if any
timeout callback methods
web service endpoint interface methods
 message-driven bean message listener methods
(if the bean
a message-driven bean)
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
 Style 2: The following method element refers
to all the
 create methods of the EmployeeService bean’s
home
interface(s).
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>create</method-name>
</method>
 Style 3: The following method element refers
to the
 create(String firstName, String LastName)
method of the
EmployeeService bean’s home interface(s).
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
 The following example illustrates a Style 3
element with
more complex parameter types. The method
 foobar(char s, int i, int[] iar,
mypackage.MyClass mycl,
 mypackage.MyClass[][] myclaar) would be
specified as:
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>foobar</method-name>
<method-params>
<method-param>char</method-param>
<method-param>int</method-param>
<method-param>int[]</method-param>
</method-params>
</method>
 The optional method-intf element can be used
when it becomes
 necessary to differentiate between a method
that is defined
 multiple times with the same name and
signature across any
 of the following methods of an enterprise
bean:
business interface methods
home interface methods
component interface methods
web service endpoint methods
no-interface view methods
 singleton or stateful session bean lifecycle
callback methods
timeout callback methods
message-driven bean message listener methods
 However, if the same method is a method of
both the local
 business interface, and the local component
interface,
 the same attribute applies to the method for
both interfaces.
 Likewise, if the same method is a method of
both the remote
 business interface and the remote component
interface, the same
 attribute applies to the method for both
interfaces.
For example, the method element
<method>
<ejb-name>EmployeeService</ejb-name>
<method-intf>Remote</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
 can be used to differentiate the
create(String, String)
 method defined in the remote interface from
the
 create(String, String) method defined in the
remote home
interface, which would be defined as
<method>
<ejb-name>EmployeeService</ejb-name>
<method-intf>Home</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
 and the create method that is defined in the
local home
interface which would be defined as
<method>
<ejb-name>EmployeeService</ejb-name>
<method-intf>LocalHome</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
 The method-intf element can be used with all
three Styles
 of the method element usage. For example,
the following
 method element example could be used to
refer to all the
 methods of the EmployeeService bean’s remote
home interface
and the remote business interface.
<method>
<ejb-name>EmployeeService</ejb-name>
<method-intf>Home</method-intf>
<method-name>*</method-name>
</method>
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”ejb-name”
type=”javaee:ejb-nameType”/>
<xsd:element name=”method-intf”
type=”javaee:method-intfType”
minOccurs=”0”>
</xsd:element>
<xsd:element name=”method-name”
type=”javaee:method-nameType”/>
<xsd:element name=”method-params”
type=”javaee:method-paramsType”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”method-intfType”>
<xsd:annotation>
<xsd:documentation>
 The method-intf element allows a method
element to
 differentiate between the methods with the
same name and
 signature that are multiply defined across
the home and
 component interfaces (e.g, in both an
enterprise bean’s
 remote and local interfaces or in both an
enterprise bean’s
 home and remote interfaces, etc.); the
component and web
service endpoint interfaces, and so on.
 Local applies to the local component
interface, local business
interfaces, and the no-interface view.
 Remote applies to both remote component
interface and the remote
business interfaces.
 ServiceEndpoint refers to methods exposed
through a web service
endpoint.
 Timer refers to the bean’s timeout callback
methods.
 MessageEndpoint refers to the methods of a
message-driven bean’s
message-listener interface.
 LifecycleCallback refers to the
PostConstruct and PreDestroy
 lifecycle callback methods of a singleton
session bean and
 to the PostConstruct, PreDestroy,
PrePassivate, and PostActivate
 lifecycle callback methods of a stateful
session bean.
 The method-intf element must be one of the
following:
Home
Remote
LocalHome
Local
ServiceEndpoint
Timer
MessageEndpoint
LifecycleCallback
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Home”/>
<xsd:enumeration value=”Remote”/>
<xsd:enumeration value=”LocalHome”/>
<xsd:enumeration value=”Local”/>
<xsd:enumeration value=”ServiceEndpoint”/>
<xsd:enumeration value=”Timer”/>
<xsd:enumeration value=”MessageEndpoint”/>
<xsd:enumeration value=”LifecycleCallback”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”method-nameType”>
<xsd:annotation>
<xsd:documentation>
 The method-nameType contains a name of an
enterprise
 bean method or the asterisk (*) character.
The asterisk is
 used when the element denotes all the
methods of an
enterprise bean’s client view interfaces.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”method-paramsType”>
<xsd:annotation>
<xsd:documentation>
The method-paramsType defines a list of the
 fully-qualified Java type names of the
method parameters.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”method-param”
type=”javaee:java-typeType”
minOccurs=”0”
maxOccurs=”unbounded”>
<xsd:annotation>
<xsd:documentation>
 The method-param element contains a
primitive
 or a fully-qualified Java type name of a
method
parameter.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”method-permissionType”>
<xsd:annotation>
<xsd:documentation>
 The method-permissionType specifies that one
or more
 security roles are allowed to invoke one or
more enterprise
 bean methods. The method-permissionType
consists of an
 optional description, a list of security
role names or an
 indicator to state that the method is
unchecked for
 authorization, and a list of method
elements.
 Except as noted below the security roles
used in the
 method-permissionType must be defined in the
security-role
 elements of the deployment descriptor, and
the methods
 must be methods defined in the enterprise
bean’s no-interface
 view, business, home, component and/or web
service endpoint
interfaces.
 If the role name ”**” is included in the
list of allowed
 roles, and the application has not defined
in its deployment
 descriptor an application security role with
this name,
 then the list of allowed roles includes
every and any
authenticated user.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:choice>
<xsd:element name=”role-name”
type=”javaee:role-nameType”
maxOccurs=”unbounded”/>
<xsd:element name=”unchecked”
type=”javaee:emptyType”>
<xsd:annotation>
<xsd:documentation>
 The unchecked element specifies that a
method is
 not checked for authorization by the
container
prior to invocation of the method.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:element name=”method”
type=”javaee:methodType”
maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”multiplicityType”>
<xsd:annotation>
<xsd:documentation>
 The multiplicityType describes the
multiplicity of the
role that participates in a relation.
The value must be one of the two following:
One
Many
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”One”/>
<xsd:enumeration value=”Many”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”persistence-typeType”>
<xsd:annotation>
<xsd:documentation>
 The persistence-typeType specifies an entity
bean’s persistence
management type.
 The persistence-type element must be one of
the two following:
Bean
Container
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Bean”/>
<xsd:enumeration value=”Container”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”queryType”>
<xsd:annotation>
<xsd:documentation>
The queryType defines a finder or select
query. It contains
method it is used by
mapping, if the query is for a select method
and entity objects are returned.
 Queries that are expressible in EJB QL must
use the ejb-ql
 element to specify the query. If a query is
not expressible
 in EJB QL, the description element should be
used to
 describe the semantics of the query and the
ejb-ql element
should be empty.
 The result-type-mapping is an optional
element. It can only
 be present if the query-method specifies a
select method
 that returns entity objects. The default
value for the
result-type-mapping element is “Local”.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”/>
<xsd:element name=”query-method”
type=”javaee:query-methodType”/>
<xsd:element name=”result-type-mapping”
type=”javaee:result-type-mappingType”
minOccurs=”0”/>
<xsd:element name=”ejb-ql”
type=”javaee:xsdStringType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”query-methodType”>
<xsd:annotation>
<xsd:documentation>
<![CDATA[[
 The query-method specifies the method for a
finder or select
query.
 The method-name element specifies the name
of a finder or select
 method in the entity bean’s implementation
class.
 Each method-param must be defined for a
query-method using the
method-params element.
It is used by the query-method element.
Example:
<query>
 <description>Method finds large
orders</description>
<query-method>
<method-name>findLargeOrders</method-name>
<method-params></method-params>
</query-method>
<ejb-ql>
SELECT OBJECT(o) FROM Order o
WHERE o.amount &gt; 1000
</ejb-ql>
</query>
 Support for entity beans is optional as of
EJB 3.2.
]]>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”method-name”
type=”javaee:method-nameType”/>
<xsd:element name=”method-params”
type=”javaee:method-paramsType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”relationship-role-sourceType”>
<xsd:annotation>
<xsd:documentation>
 The relationship-role-sourceType designates
the source of a
role that participates in a relationship. A
relationship-role-sourceType is used by
 relationship-role-source elements to
uniquely identify an
entity bean.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”ejb-name”
type=”javaee:ejb-nameType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”relationshipsType”>
<xsd:annotation>
<xsd:documentation>
 The relationshipsType describes the
relationships in
 which entity beans with container-managed
persistence
 participate. The relationshipsType contains
an optional
 description; and a list of ejb-relation
elements, which
specify the container managed relationships.
 Support for entity beans is optional as of
EJB 3.2.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”ejb-relation”
type=”javaee:ejb-relationType”
maxOccurs=”unbounded”>
<xsd:unique name=”role-name-uniqueness”>
<xsd:annotation>
<xsd:documentation>
 The ejb-relationship-role-name contains the
name of a
 relationship role. The name must be unique
within
 a relationship, but can be reused in
different
relationships.
</xsd:documentation>
</xsd:annotation>
 <xsd:selector
xpath=”.//javaee:ejb-relationship-role-name”/>
<xsd:field xpath=”.”/>
</xsd:unique>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
 <xsd:complexType
name=”result-type-mappingType”>
<xsd:annotation>
<xsd:documentation>
 The result-type-mappingType is used in the
query element to
 specify whether an abstract schema type
returned by a query
 for a select method is to be mapped to an
EJBLocalObject or
EJBObject type.
The value must be one of the following:
Local
Remote
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Local”/>
<xsd:enumeration value=”Remote”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”security-identityType”>
<xsd:annotation>
<xsd:documentation>
 The security-identityType specifies whether
the caller’s
 security identity is to be used for the
execution of the
 methods of the enterprise bean or whether a
specific run-as
 identity is to be used. It contains an
optional description
 and a specification of the security identity
to be used.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:choice>
<xsd:element name=”use-caller-identity”
type=”javaee:emptyType”>
<xsd:annotation>
<xsd:documentation>
 The use-caller-identity element specifies
that
 the caller’s security identity be used as
the
security identity for the execution of the
enterprise bean’s methods.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”run-as”
type=”javaee:run-asType”/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”session-beanType”>
<xsd:annotation>
<xsd:documentation>
 The session-beanType declares an session
bean. The
declaration consists of:
icon file name
in the deployment description
 vendor-specific deployment information such
as the physical
 jndi-name of the session bean’s remote
home/business interface.
 This element is not required to be supported
by all
 implementations. Any use of this element is
non-portable.
if any
remote interfaces, if any
local interfaces, if any
no-interface view
interface, if any
handling programmatically created timers
deployment time
initialization
management type
 for a Singleton with container managed
concurrency
 application that must be initialized before
this bean
methods
 If it is not present, it is defaulted to
Container.
 afterBegin, beforeCompletion, and/or
afterCompletion methods
superclass around-invoke methods.
superclass around-timeout methods.
environment entries
EJB references
service references
references
 to be used for the execution of the bean’s
methods
manager connection factory references
environment references.
destination references
 session bean is passivation capable or not.
If not
 specified, the bean is assumed to be
passivation capable
 The elements that are optional are
“optional” in the sense
 that they are omitted when if lists
represented by them are
empty.
 The service-endpoint element may only be
specified if the
bean is a stateless session bean.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:group ref=”javaee:descriptionGroup”/>
<xsd:element name=”ejb-name”
type=”javaee:ejb-nameType”/>
<xsd:element name=”mapped-name”
type=”javaee:xsdStringType”
minOccurs=”0”/>
<xsd:element name=”home”
type=”javaee:homeType”
minOccurs=”0”/>
<xsd:element name=”remote”
type=”javaee:remoteType”
minOccurs=”0”/>
<xsd:element name=”local-home”
type=”javaee:local-homeType”
minOccurs=”0”/>
<xsd:element name=”local”
type=”javaee:localType”
minOccurs=”0”/>
<xsd:element name=”business-local”
type=”javaee:fully-qualified-classType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”business-remote”
type=”javaee:fully-qualified-classType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”local-bean”
type=”javaee:emptyType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
The local-bean element declares that this
 session bean exposes a no-interface Local
client view.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”service-endpoint”
type=”javaee:fully-qualified-classType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
The service-endpoint element contains the
 fully-qualified name of the enterprise
bean’s web
 service endpoint interface. The
service-endpoint
 element may only be specified for a
stateless
 session bean. The specified interface must
be a
valid JAX-RPC service endpoint interface.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”ejb-class”
type=”javaee:ejb-classType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The ejb-class element specifies the fully
qualified name
 of the bean class for this ejb. It is
required unless
 there is a component-defining annotation for
the same
ejb-name.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”session-type”
type=”javaee:session-typeType”
minOccurs=”0”/>
<xsd:element name=”stateful-timeout”
type=”javaee:stateful-timeoutType”
minOccurs=”0”/>
<xsd:element name=”timeout-method”
type=”javaee:named-methodType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The timeout-method element specifies the
method that
will receive callbacks for programmatically
created timers.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”timer”
type=”javaee:timerType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”init-on-startup”
type=”javaee:true-falseType”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The init-on-startup element specifies that a
Singleton
bean has eager initialization.
 This element can only be specified for
singleton session
beans.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
 <xsd:element
name=”concurrency-management-type”
minOccurs=”0”/>
<xsd:element name=”concurrent-method”
type=”javaee:concurrent-methodType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”depends-on”
type=”javaee:depends-onType”
minOccurs=”0”/>
<xsd:element name=”init-method”
type=”javaee:init-methodType”
minOccurs=”0”
maxOccurs=”unbounded”>
<xsd:annotation>
<xsd:documentation>
 The init-method element specifies the
mappings for
 EJB 2.x style create methods for an EJB 3.x
bean.
 This element can only be specified for
stateful
session beans.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”remove-method”
type=”javaee:remove-methodType”
minOccurs=”0”
maxOccurs=”unbounded”>
<xsd:annotation>
<xsd:documentation>
 The remove-method element specifies the
mappings for
 EJB 2.x style remove methods for an EJB 3.x
bean.
 This element can only be specified for
stateful
session beans.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”async-method”
type=”javaee:async-methodType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”transaction-type”
type=”javaee:transaction-typeType”
minOccurs=”0”/>
<xsd:element name=”after-begin-method”
type=”javaee:named-methodType”
minOccurs=”0”/>
<xsd:element name=”before-completion-method”
type=”javaee:named-methodType”
minOccurs=”0”/>
<xsd:element name=”after-completion-method”
type=”javaee:named-methodType”
minOccurs=”0”/>
<xsd:element name=”around-invoke”
type=”javaee:around-invokeType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”around-timeout”
type=”javaee:around-timeoutType”
minOccurs=”0”
maxOccurs=”unbounded”/>
 <xsd:group
ref=”javaee:jndiEnvironmentRefsGroup”/>
<xsd:element name=”post-activate”
type=”javaee:lifecycle-callbackType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”pre-passivate”
type=”javaee:lifecycle-callbackType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”security-role-ref”
type=”javaee:security-role-refType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”security-identity”
type=”javaee:security-identityType”
minOccurs=”0”/>
<xsd:element name=”passivation-capable”
type=”xsd:boolean”
default=”true”
minOccurs=”0”>
<xsd:annotation>
<xsd:documentation>
 The passivation-capable element specifies
whether the
 stateful session bean is passivation capable
or not.
 If not specified, the bean is assumed to be
passivation
capable.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”session-typeType”>
<xsd:annotation>
<xsd:documentation>
 The session-typeType describes whether the
session bean is a
 singleton, stateful or stateless session. It
is used by
session-type elements.
 The value must be one of the three
following:
Singleton
Stateful
Stateless
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Singleton”/>
<xsd:enumeration value=”Stateful”/>
<xsd:enumeration value=”Stateless”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”stateful-timeoutType”>
<xsd:annotation>
<xsd:documentation>
 The stateful-timeoutType represents the
amount of time
 a stateful session bean can be idle(not
receive any client
 invocations) before it is eligible for
removal by the container.
 A timeout value of 0 means the bean is
immediately eligible for
removal.
 A timeout value of -1 means the bean will
never be removed due to
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”timeout”
type=”javaee:xsdIntegerType”/>
<xsd:element name=”unit”
type=”javaee:time-unit-typeType”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”time-unit-typeType”>
<xsd:annotation>
<xsd:documentation>
 The time-unit-typeType represents a time
duration at a given
unit of granularity.
 The time unit type must be one of the
following :
Days
Hours
Minutes
Seconds
Milliseconds
Microseconds
Nanoseconds
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Days”/>
<xsd:enumeration value=”Hours”/>
<xsd:enumeration value=”Minutes”/>
<xsd:enumeration value=”Seconds”/>
<xsd:enumeration value=”Milliseconds”/>
<xsd:enumeration value=”Microseconds”/>
<xsd:enumeration value=”Nanoseconds”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name=”timer-scheduleType”>
<xsd:sequence>
<xsd:element name=”second”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”minute”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”hour”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”day-of-month”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”month”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”day-of-week”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”year”
type=”javaee:string”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”timerType”>
<xsd:annotation>
<xsd:documentation>
 The timerType specifies an enterprise bean
timer. Each
 timer is automatically created by the
container upon
 deployment. Timer callbacks occur based on
the
 schedule attributes. All callbacks are made
to the
timeout-method associated with the timer.
 A timer can have an optional start and/or
end date. If
 a start date is specified, it takes
precedence over the
 associated timer schedule such that any
matching
 expirations prior to the start time will not
occur.
 Likewise, no matching expirations will occur
after any
 end date. Start/End dates are specified
using the
 XML Schema dateTime type, which follows the
ISO-8601
 standard for date(and optional
time-within-the-day)
representation.
 An optional flag can be used to control
whether
 this timer has persistent(true) delivery
semantics or
 non-persistent(false) delivery semantics. If
not specified,
the value defaults to persistent(true).
 A time zone can optionally be associated
with a timer.
 If specified, the timer’s schedule is
evaluated in the context
 of that time zone, regardless of the default
time zone in which
 the container is executing. Time zones are
specified as an
 ID string. The set of required time zone IDs
is defined by
 the Zone Name(TZ) column of the public
domain zoneinfo database.
 An optional info string can be assigned to
the timer and
 retrieved at runtime through the
Timer.getInfo() method.
 The timerType can only be specified on
stateless session
 beans, singleton session beans, and
message-driven beans.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name=”description”
type=”javaee:descriptionType”
minOccurs=”0”
maxOccurs=”unbounded”/>
<xsd:element name=”schedule”
type=”javaee:timer-scheduleType”/>
<xsd:element name=”start”
type=”xsd:dateTime”
minOccurs=”0”/>
<xsd:element name=”end”
type=”xsd:dateTime”
minOccurs=”0”/>
<xsd:element name=”timeout-method”
type=”javaee:named-methodType”/>
<xsd:element name=”persistent”
type=”javaee:true-falseType”
minOccurs=”0”/>
<xsd:element name=”timezone”
type=”javaee:string”
minOccurs=”0”/>
<xsd:element name=”info”
type=”javaee:string”
minOccurs=”0”/>
</xsd:sequence>
<xsd:attribute name=”id”
type=”xsd:ID”/>
</xsd:complexType>
<xsd:complexType name=”trans-attributeType”>
<xsd:annotation>
<xsd:documentation>
 The trans-attributeType specifies how the
container must
 manage the transaction boundaries when
delegating a method
 invocation to an enterprise bean’s business
method.
The value must be one of the following:
NotSupported
Supports
Required
RequiresNew
Mandatory
Never
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”NotSupported”/>
<xsd:enumeration value=”Supports”/>
<xsd:enumeration value=”Required”/>
<xsd:enumeration value=”RequiresNew”/>
<xsd:enumeration value=”Mandatory”/>
<xsd:enumeration value=”Never”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 <xsd:complexType
name=”transaction-typeType”>
<xsd:annotation>
<xsd:documentation>
 The transaction-typeType specifies an
enterprise bean’s
transaction management type.
 The transaction-type must be one of the two
following:
Bean
Container
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base=”javaee:string”>
<xsd:enumeration value=”Bean”/>
<xsd:enumeration value=”Container”/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
 _A “ejb-jar” file in the WEB-INF/lib
directory that contains enterprise beans is not considered an
independent Java EE “module” in the way that a .war file, stand-alone
ejb-jar file, or an .ear-level ejb-jar file is considered a module. Such
an “ejb-jar file” does not define its own module name or its own
namespace for ejb-names, environment dependencies, persistence units,
etc. All such namespaces are scoped to the enclosing .war file. In that
sense, the packaging of enterprise bean classes in an “ejb-jar” file in
the WEB-INF/lib directory is merely a convenience. It is semantically
equivalent to packaging the classes within WEB-INF/classes_ directory
_._
public void foo() \{ ... }
WEB-INF/classes/com/acme/FooServlet.class
WEB-INF/classes/com/acme/FooBean.class
web-app_2_5
or later
web-app_2_5
or later
web-app_2_4
or earlier
META-INF/application.xml
ejb1.jar Class-Path: ejb1_client.jar
_deployment descriptor contains:_
ejb1_client.jar
ejb2.jar Class-Path: ejb1_client.jar
META-INF/application.xml
ejb1_client.jar
ejb3.jar Class-Path: ejb1_client.jar
_javax.jms.Session.setMessageListener_
_javax.jms.Session.getMessageListener_
_javax.jms.Session.run_
_javax.jms.Connection.setExceptionListener_
_javax.jms.Connection.stop_
_javax.jms.Connection.setClientID_
CompletionListener completionListener)
int priority, long timeToLive,
CompletionListener completionListener)
CompletionListener completionListener)
 int deliveryMode, int priority, long
timeToLive,
CompletionListener completionListener)
com.acme.Client
_Example:_
com/acme/EJBContainerProvider.class
...
 _Java™ API for XML-based Web Service,
version 2.2 (JAX-WS). http://jcp.org/en/jsr/detail?id=224._

Jakarta Enterprise Beans, Core Features

Copyright

Eclipse Foundation Specification License

Disclaimers

1. Introduction

1.1. Target Audience

1.2. What is New in This Release

1.3. What was New in EJB 3.1

1.3.1. What was New in EJB 3.0

1.4. Acknowledgements

1.5. Organization of the Specification Documents

1.6. Document Conventions

2. Overview

2.1. Overall Goals

2.2. EJB Roles

2.2.1. Enterprise Bean Provider

2.2.2. Application Assembler

2.2.3. Deployer

2.2.4. EJB Server Provider

2.2.5. EJB Container Provider

2.2.6. System Administrator

2.3. Enterprise Beans

2.3.1. Characteristics of Enterprise Beans

2.3.2. Flexible Model

2.4. Enterprise Bean Object Types

2.4.1. Session Objects

2.4.2. Message-Driven Objects

2.4.3. Entity Objects (Optional)

2.5. Standard Mapping to CORBA Protocols

2.6. Mapping to Web Service Protocols

2.7. Pruning the EJB API

2.8. Relationship to Managed Bean Specification

2.9. Relationship to Contexts and Dependency Injection (CDI) Specification

2.10. Relationship to the Java API for RESTful Web Services (JAX-RS) Specification

3. Client View of a Session Bean

3.1. Overview

3.2. Local, Remote, and Web Service Client Views

3.2.1. Remote Clients

3.2.2. Local Clients

3.2.3. Choosing Between a Local or Remote Client View

3.2.4. Web Service Clients

3.3. EJB Container

3.4. Client View of Session Beans Written to the EJB 3.x Simplified API

3.4.1. Obtaining a Session Bean’s Business Interface

3.4.2. Obtaining a Reference to the No-interface View

3.4.3. Session Bean’s Business Interface

3.4.4. Session Bean’s No-Interface View

3.4.5. Client View of Session Object’s Life Cycle

3.4.6. Example of Obtaining and Using a Session Object

3.4.7. Session Object Identity

3.4.7.1. Stateful Session Beans

3.4.7.2. Stateless Session Beans

3.4.7.3. Singleton Session Beans

3.4.8. Asynchronous Invocations

3.4.8.1. Return Values

Future.cancel(boolean mayInterruptIfRunning)

Future.get

3.4.9. Concurrent Access to Session Bean References

3.5. The Web Service Client View of a Stateless or Singleton Session Bean

3.5.1. JAX-WS Web Service Clients

3.6. Remote and Local Client View of Session Beans Written to the EJB 2.1 Client View API

3.6.1. Locating a Session Bean’s Home Interface

3.6.2. Session Bean’s Remote Home Interface

3.6.2.1. Creating a Session Object

3.6.2.2. Removing a Session Object

3.6.3. Session Bean’s Local Home Interface

3.6.3.1. Creating a Session Object

3.6.3.2. Removing a Session Object

3.6.4. EJBObject and EJBLocalObject

3.6.5. Client view of Session Object’s Life Cycle

3.6.5.1. References to Session Object Remote Component Interfaces

3.6.5.2. References to Session Object Local Component Interfaces

3.6.6. Creating and Using a Session Object

3.6.7. Object Identity

3.6.7.1. Stateful Session Beans

3.6.7.2. Stateless Session Beans

3.6.7.3. getPrimaryKey()

3.6.8. Type Narrowing

4. Session Bean Component Contract

4.1. Overview

4.6.4. Missed `PreDestroy` Calls