Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc.

Runtime environment

Enterprise JavaBeans 2.0, Public Draft

Container Provider’s responsibility

This function is reserved for the EJB Container. Allowing the enterprise bean to perform this function would create a security hole.

The enterprise bean must not attempt to define a class in a package.

This function is reserved for the EJB Container. Allowing the enterprise bean to perform this function would create a security hole.

The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).

These functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions could compromise security.

The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.

Allowing the enterprise bean to use these functions could compromise security.

The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext.getEJBObject() instead.

To guarantee portability of the enterprise bean’s implementation across all compliant EJB 2.0 Containers, the Bean Provider should test the enterprise bean using a Container with the security settings defined in Table 16. The tables define the minimal functionality that a compliant EJB Container must provide to the enterprise bean instances at runtime.

23.2 Container Provider’s responsibility

This section defines the Container’s responsibilities for providing the runtime environment to the enterprise bean instances. The requirements described here are considered to be the minimal requirements; a Container may choose to provide additional functionality that is not required by the EJB specification.

An EJB 2.0 Container must make the following APIs available to the enterprise bean instances at runtime:

Java 2 Platform, Standard Edition v1.3 (J2SE) APIs

EJB 2.0 APIs

JNDI 1.2

JTA 1.0.1, the UserTransaction interface only

5/31/00

464

Sun Microsystems Inc

Container Provider’s responsibility

Enterprise JavaBeans 2.0, Public Draft

Runtime environment

JDBC™ 2.0 extension

JMS 1.0.2

JavaMail 1.1, sending mail only

JAXP 1.0

The following subsections describes the requirements in more detail.

23.2.1 Java 2 APIs requirements

The Container must provide the full set of Java 2 Platform, Standard Edition, v1.3 (J2SE) APIs. The Container is not allowed to subset the Java 2 platform APIs.

The EJB Container is allowed to make certain Java 2 platform functionality unavailable to the enterprise bean instances by using the Java 2 platform security policy mechanism. The primary reason for the Container to make certain functions unavailable to enterprise bean instances is to protect the security and integrity of the EJB Container environment, and to prevent the enterprise bean instances from interfering with the Container’s functions.

465

5/31/00

Sun Microsystems Inc.

Runtime environment

Enterprise JavaBeans 2.0, Public Draft

Container Provider’s responsibility

The following table defines the Java 2 platform security permissions that the EJB Container must be able to grant to the enterprise bean instances at runtime. The term “grant” means that the Container must be able to grant the permission, the term “deny” means that the Container should deny the permission.

Table 16

Java 2 Platform Security policy for a standard EJB Container

 

 

 

 

 

 

Permission name

EJB Container policy

 

 

 

 

 

 

 

 

 

 

java.security.AllPermission

deny

 

 

 

 

 

 

java.awt.AWTPermission

deny

 

 

 

 

 

 

java.io.FilePermission

deny

 

 

 

 

 

 

java.net.NetPermission

deny

 

 

 

 

 

 

java.util.PropertyPermission

grant “read”, “*”

 

 

 

deny all other

 

 

 

 

 

 

java.lang.reflect.ReflectPermission

deny

 

 

 

 

 

 

java.lang.RuntimePermission

grant “queuePrintJob”,

 

 

 

deny all other

 

 

 

 

 

 

java.lang.SecurityPermission

deny

 

 

 

 

 

 

java.io.SerializablePermission

deny

 

 

 

 

 

 

java.net.SocketPermission

grant “ connect”, “*” [Note A],

 

 

 

deny all other

 

 

 

 

 

Notes:

 

[A]This permission is necessary, for example, to allow enterprise beans to use the client functionality of the Java IDL and RMI-IIOP packages that are part of the Java 2 platform.

Some Containers may allow the Deployer to grant more, or fewer, permissions to the enterprise bean instances than specified in Table 16. Support for this is not required by the EJB specification. Enterprise beans that rely on more or fewer permissions will not be portable across all EJB Containers.

23.2.2 EJB 2.0 requirements

The container must implement the EJB 2.0 interfaces as defined in this documentation.

23.2.3 JNDI 1.2 requirements

At the minimum, the EJB Container must provide a JNDI API name space to the enterprise bean instances. The EJB Container must make the name space available to an instance when the instance invokes the javax.naming.InitialContext default (no-arg) constructor.

The EJB Container must make available at least the following objects in the name space:

5/31/00

466

Sun Microsystems Inc

Container Provider’s responsibility

Enterprise JavaBeans 2.0, Public Draft

Runtime environment

The home interfaces of other enterprise beans.

The resource factories used by the enterprise beans.

The EJB specification does not require that all the enterprise beans deployed in a Container be presented with the same JNDI API name space. However, all the instances of the same enterprise bean must be presented with the same JNDI API name space.

23.2.4 JTA 1.0.1 requirements

The EJB Container must include the JTA 1.0.1 extension, and it must provide the javax.transaction.UserTransaction interface to enterprise beans with bean-managed transaction demarcation through the javax.ejb.EJBContext interface, and also in JNDI under the name java:comp/UserTransaction, in the cases required by the EJB specification.

The other JTA interfaces are low-level transaction manager and resource manager integration interfaces, and are not intended for direct use by enterprise beans.

23.2.5 JDBC™ 2.0 extension r equirements

The EJB Container must include the JDBC 2.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.

23.2.6 JMS 1.0.2 requirements

The EJB Container must include the JMS 1.0.2 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level interfaces that are intended for integration of a JMS provider with an application server, not for direct use by enterprise beans. These interfaces include: javax.jms.ServerSession, javax.jms.ServerSessionPool, javax.jms.ConnectionConsumer, and all the javax.jms XA interfaces.

In addition, the following methods are for use by the Container only. Enterprise beans must not call these methods: javax.jms.Session.setMessageListener, javax.jms.Session.getMessageListener, javax.jms.Session.run, javax.jms.QueueConnection.createConnectionConsumer, javax.jms.TopicConnection.createConnectionConsumer, javax.jms.TopicConnection.createDurableConnectionConsumer.

The following methods must not be called by enterprise beans because they may interfere with the connection management by the Container: javax.jms.Connection.setExceptionListener, javax.jms.Connection.stop, javax.jms.Connection.setClientID.

This specification recommends, but does not require, that the Container throw the javax.jms.JMSException if enterprise beans call any of the methods listed in this section.

467

5/31/00