Sun Microsystem Inc

Chapter 18 Runtime environment

This chapter defines the application programming interfaces (APIs) that a compliant EJB Container must make available to the enterprise bean instances at runtime. These APIs can be used by portable enterprise beans because the APIs are guaranteed to be available in all EJB Containers.

The chapter also defines the restrictions that the EJB Container Provider can impose on the functionality that it provides to the enterprise beans. These restrictions are necessary to enforce security and to allow the Container to properly manage the runtime environment.

18.1 Bean Provider’s responsibilities

This section describes the view and responsibilities of the Bean Provider.

Sun Microsystems Inc.

18.1.1 APIs provided by Container

The EJB Provider can rely on the EJB Container Provider to provide the following APIs:

•JDK 1.1.x or Java 2

•EJB 1.1 Standard Extension

•JDBC 2.0 Standard Extension (support for row sets only)

•JNDI 1.2 Standard Extension

•JTA 1.0.1 Standard Extension (the UserTransaction interface only)

•JavaMail 1.1 Standard Extension (for sending mail only)

The Bean Provider must take into consideration that while some Containers will provide JDK 1.1.x APIs, other Containers may provide the Java 2 (i.e. JDK 1.2) APIs. This means that the Bean Providers that want to deploy their enterprise beans in all Containers must restrict the APIs used by the enterprise beans to those that are available in JDK 1.1 and the above listed standard extensions.

18.1.2 Programming restrictions

This section describes the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB Container. The restrictions apply to the implementation of the business methods. Section 18.2, which describes the Container’s view of these restrictions, defines the programming environment that all EJB Containers must provide.

•An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.

This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean’s instances, others may distribute the instances across multiple JVMs.

•An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.

Same reason as above. Synchronization would not work if the EJB Container distributed enterprise bean’s instances across multiple JVMs.

•An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.

Sun Microsystem Inc

Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system.

•An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC API, to store data.

•An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.

The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients.

•The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.

Allowing the enterprise bean to access information about other classes and to access the classes in a manner that is normally disallowed by the Java programming language could compromise security.

•The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.

These functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions could compromise security and decrease the Container’s ability to properly manage the runtime environment.

•The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.

These networking functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions could compromise security and decrease the Container’s ability to properly manage the runtime environment.

•The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads would decrease the Container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to directly read or write a file descriptor.

Sun Microsystems Inc.

Allowing the enterprise bean to read and write file descriptors directly could compromise security.

•The enterprise bean must not attempt to obtain the security policy information for a particular code source.

Allowing the enterprise bean to access the security policy information would create a security hole.

• The enterprise bean must not attempt to load a native library.

This function is reserved for the EJB Container. Allowing the enterprise bean to load native code would create a security hole.

•The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.

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 Containers, the Bean Provider should test the enterprise bean using a Container with the security settings defined in Tables 10 and 11. The tables define the minimal functionality that a compliant EJB Container must provide to the enterprise bean instances at runtime.