EJB.18.1 Bean Provider's ResponsibilitiesThis section describes the view and responsibilities of the bean provider. EJB.18.1.1 APIs Provided by ContainerThe EJB provider can rely on the EJB container provider to provide the following APIs:
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 previously listed standard extensions. EJB.18.1.2 Programming RestrictionsThis 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 EJB.18.2, which describes the container's view of these restrictions, defines the programming environment that all EJB containers must provide.
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.
Same reason as above. Synchronization would not work if the EJB container distributed to enterprise bean's instances across multiple JVMs.
Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server 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.
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 .
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.
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.
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.
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.
Allowing the enterprise bean to read and write file descriptors directly could compromise security.
Allowing the enterprise bean to access the security policy information would create a security hole.
This function is reserved for the EJB container. Allowing the enterprise bean to load native code would create a security hole.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function would create a security hole.
This function is reserved for the EJB container. Allowing the enterprise bean to perform this function would create a security hole.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security.
Allowing the enterprise bean to use these functions could compromise security.
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 EJB.18-1 and EJB.18-2. The tables define the minimal functionality that a compliant EJB container must provide to the enterprise bean instances at runtime. |