What restrictions are imposed on enterprise beans? Why are these restrictions in place?
The EJB container is responsible for managing system-related functionality such as security, threading, resource pooling, and so on. In order to control these facets of component operation, the container places certain restrictions on the components it manages.
java.lang.reflectJava Reflection API to access information unavailable by way of the security rules of the Java runtime environment
thisto refer to the instance in a method parameter or result
java.awtpackage to create a user interface
java.net.ServerSocket, or change the stream handler factory of
Are the restrictions mandatory? How are they enforced?
The restrictions are mandatory, since they are laid out in the specification as not optional. There are three basic types of enforcement of these restrictions.
Framewill fail, since the default security setting for the container denies
Most EJB Container implementations will allow changes to the default security settings, so enterprise bean programming restrictions can usually be relaxed in specific cases. It's important to understand, though, the implications of violating the restrictions, by understanding why the restrictions are in place.
Do the restrictions that apply to EJBs also apply to helper and dependent classes ?
Yes. From the point of view of the container, the enterprise bean and its helper classes form a single functional unit. If an enterprise bean were not allowed to, say, open a file in the filesystem, and yet had access to a helper class that was allowed to do so, the restriction on the bean would be meaningless. Therefore, EJB component programming restrictions also apply to any helper or dependent classes the bean may use.
Nonfinal static class fields are disallowed in EJBs because such fields make an enterprise bean difficult or impossible to distribute. Static class fields are shared among all instances of a particular class, but only within a single Java Virtual Machine (JVM ). Updating a static class field implies an intent to share the field's value among all instances of the class. But if a class is running in several JVMs simultaneously, only those instances running in the same JVM as the updating instance will have access to the new value. In other words, a nonfinal static class field will behave differently if running in a single JVM, than it will running in multiple JVMs. The EJB container reserves the option of distributing enterprise beans across multiple JVMs (running on the same server, or on any of a cluster of servers). Nonfinal static class fields are disallowed because enterprise bean instances will behave differently depending on whether or not they are distributed.
The EJB specification assigns to the EJB container the responsibility for managing threads. Allowing enterprise bean instances to create and manage threads would interfere with the container's ability to control its components' lifecycle. Thread management is not a business function, it is an implementation detail, and is typically complicated and platform-specific. Letting the container manage threads relieves the enterprise bean developer of dealing with threading issues. Multithreaded applications are still possible, but control of multithreading is located in the container, not in the enterprise bean.
Because if an enterprise bean is listening on a socket, it can't be passivated -- it must always be available. Enterprise beans can be network socket clients, and so they can use other network resources (including other enterprise bean servers) to do their jobs. Just as with a database connection, don't hang on to open client sockets across method calls; instead, open them, communicate through the socket, and close it before returning from the method.
Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard.
Why isn't AWT available from within an enterprise bean?
Because EJBs are intended to be business-functionality-specific server extensions, not clients with user interfaces. The purpose of an enterprise bean is to perform some service on the server in response to a service request. This is a separate function from managing user interaction. Note that AWT and JFC/Swing may still be used to create user interfaces that access enterprise beans through a remote enterprise bean reference.
Why is there a restriction against using the Java Reflection APIs to obtain declared member information that the Java language security rules would not allow? Doesn't Java automatically enforce those rules?
Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example,
invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden.
Why all the restrictions on creating class loaders and redirection of input, output, and error streams?
Class loading is allowed, but creating custom loaders is not, for security reasons. These restrictions exist because the EJB container has responsibility for class loading and I/O control. Allowing the EJB to perform these functions would interfere with proper operation of the Container, and are a security hazard.
Why can't I load native code?
Native code, if allowed in enterprise beans, could cause a host of problems, including but not limited to:
"Some Containers may allow the Deployer to grant more, or fewer, permissions to the enterprise bean instances than specified in Table 10. 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."