EJB programming restrictions

An enterprise bean works best when it follows the EJB programming restrictions. A bean provider must follow these to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 container. If a bean class does not follow these restrictions, it will still work. However, the performance will have to be compromised. For example, it may lose its benefit of being portable across networks. The restrictions that apply to EJB 2.0 fall in one of these categories:

• Restrictions on distribution: Enterprise bean instances may be distributed across separate Java Virtual Machines. These restrictions help in maintaining portability of the applications across JVMs.
• Security restriction: Security restrictions are imposed in the EJB model to maintain the integrity of the enterprise bean.
• Restriction on container control: The container is responsible for maintaining a bean’s life. Other than this, it also creates and maintains thread, maintains security, and performs other system services. The EJB restrictions prevent enterprise bean classes from interfering with proper container operations.
• Restriction on roles of server: The EJB server, EJB container, and EJB component have clearly specified roles in the enterprise bean programming model. These restrictions enable the server and container to carry on their responsibilities efficiently.

The programming restrictions that apply on EJB 2.0 are as follows:

• Restriction on using static field: It must not use read/write static fields. Writing a static field is not allowed because doing so will not allow an enterprise to be used in a distributed environment. Static fields are shared among all instances of a particular class but only within a single Java Virtual Machine. Changing the value of a field will not reflect the changed value in the field in another JVM. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
• Restriction on thread synchronization: It must not use thread synchronization primitives to synchronize execution of multiple instances.
• Restriction on I/O:
  1. It must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard. However, AWT can be used to create user interfaces that access enterprise beans through a bean’s remote reference.
  2. It must not use the java.io package to attempt to access files and directories in the file system.
  3. It must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast. An enterprise bean listening to a socket cannot be passivated. A socket connection should be closed before returning from a method.
• Restriction on querying a class: It 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.
• Restriction on class loader: It 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.
• Restriction on managing thread: It 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 EJB container is responsible for creating and managing threads. Allowing the container to create and manage thread life cycle allows the bean developer to handle the business issues.
• Restriction on writing a file descriptor: It must not attempt to directly read or write a file descriptor. Reading or writing a file descriptor from EJB will compromise its portability. Also, EJBs are not secure for accessing file systems as they can broadcast the contents of sensitive files or overwrite the JVM runtime, which may violate the whole purpose of writing the file.
• Restriction on security policy: It must not attempt to obtain the security policy information for a particular code source.
• Restriction on using native library: It must not attempt to load a native library. Attempting to load a native library using the load() or loadLibrary() method results in a SecurityException.
• Restriction on using packages:
  1. It 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.
  2. It must not attempt to define a class in a package.
• Restriction on accessing security: It must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
• Restriction on serialization: It must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
• Restriction on passing this: It must not attempt to use this to refer to the instance in a method parameter or result. It must pass the result of SessionContext.getEJBObject(), SessionContext.getEJBLocalObject(), EntityContext.getEJBObject(), or EntityContext.getEJBLocalObject() instead.

• Previous Entry: What are the restrictions that apply to a bean-managed transaction?
• Next Entry: What is the SessionSynchronization interface?