Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Programming restrictions on EJB

Learn to write reliable and portable EJB 1.1 components

By Sanjay Mahapatra, JavaWorld.com, 08/25/00

Enterprise JavaBeans (EJB) is a specification and architecture for the development and deployment of distributed server-side, transactional, and secure business application components. The EJB architecture is the basis and core of the Java 2 Enterprise Edition (J2EE), which defines an entire standardized application development architecture as well as a deployment environment. In this architecture, application developers focus on encapsulating the business logic and business rules and leave the infrastructural service-related issues or plumbing to the application container and server.

Further, the runtime properties of the application components pertaining to transactions, persistence, security, and so on are customizable in the deployment environment, using the highly flexible declarative approach. The architecture defines a container and server model -- the container is the environment in which application component instances live and execute, while containers are in turn housed within a server. The J2EE platform thus provides a simplified development model, industrial-strength scalability, support for legacy integration, flexible deployment, application server and vendor independence, and generally tends to make proprietary application servers and proprietary distributed object frameworks almost archaic.

EJB roles and responsibilities

The EJB specification defines several standard roles and responsibilities as listed below:

  1. EJB Server provider provides the EJB application server, and it is an expert in distributed transaction management, system services, and so on.
  2. EJB Container provider provides the runtime environment for the EJB components' instances as well as the deployment tools. EJB Server/Container providers are typically OS vendors, database vendors, and application server vendors. The EJB server and EJB container are assumed to be provided by the same vendor because no interfaces between them have been defined in the specification -- both in the current EJB 1.1 (final version) as well as the EJB 2.0 public-draft version, which is currently under review.
  3. Bean provider, or EJB developer, develops EJB components that contain business logic and business functionality. The EJB developer provides for each EJB component: the EJB implementation containing all obligatory component-container contract methods, such as ejbCreate(), ejbRemove(), and so on, as well as the business methods; the Home interface; the Remote interface; and helper classes if necessary. The Home interface provides the signature for the methods that create, remove, and find EJB instances. The Remote interface defines the signatures for the business methods.
  4. Application Assembler takes a set of EJB components developed by the Bean provider and assembles them into a complete J2EE application.
  5. Deployer is an expert in the target production environment in which the application is to be deployed. The deployer installs the application components on the application server and configures their transactional, data persistence, and security aspects. Thus, you can declaratively address and manage complex issues such as transactions, concurrency, persistence, and security.
  6. Systems Administrator is responsible for the server's configuration and administration, runtime monitoring, and load balancing.
  7. Application Client/User Interface developer is responsible for the user interface and presentation logic.


The focus of this article is on the Bean provider/EJB developer and the programming restrictions that apply to the EJB components' implementation code.

Restrictions on EJB components

The EJB developer must not program any systems-level services into the EJB component implementation code. EJB component providers/developers should be aware of and strictly follow certain restrictions in the interest of developing reliable and portable EJB components.

The following is a list of Java features that you should avoid, hence restricting their use in your EJB components' implementation code:

  1. Using static, nonfinal fields. Declaring all static fields in the EJB component as final is recommended. That ensures consistent runtime semantics so that EJB containers have the flexibility to distribute instances across multiple JVMs.
  2. Using thread synchronization primitives to synchronize multiple instance execution. By avoiding that feature, you allow the EJB container flexibility to distribute instances across multiple JVMs.
  3. Using AWT functionality for keyboard input/display output. That restriction exists because server-side business components are meant to provide business functionality that excludes user interface and keyboard I/O functionality.
  4. Using file access/java.io operations. EJB business components are meant to use resource managers such as JDBC to store and retrieve application data rather than the file system APIs. Also, deployment tools provide the facility for storing environment entry elements (env-entry) into the deployment descriptor, so that EJB components can perform environment entry lookups in a standardized manner via the environment-naming context. Thus, the need to use file system-based property files is mostly eliminated.
  5. Listening to or accepting socket connections, or using a socket for multicast. EJB components are not meant to provide network socket server functionality; however, the architecture lets EJB components act as a socket client or RMI clients and thus communicate with code outside the container's managed environment.
  6. Using the Reflection API to query classes that are not otherwise accessible to the EJB component due to Java's security rules. That restriction enforces Java platform security.
  7. Attempting to create or obtain a class loader, set or create a new security manager, stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.
  8. Setting the socket factory used by the URL's ServerSocket, Socket, or stream handler. By avoiding that feature, you also enforce security and maintain the EJB container's ability to manage the runtime environment.
  9. Starting, stopping, or managing threads in any way. That restriction eliminates the possibility of conflicts with the EJB container's responsibilities of managing locking, threading, and concurrency issues.

  10. By restricting your use of features 10-16, you aim to plug potential security holes:

  11. Reading or writing a file descriptor directly.
  12. Obtaining security policy information for a particular code source.
  13. Loading native libraries.
  14. Accessing packages and classes that the usual rules of Java make unavailable.
  15. Defining a class in a package.
  16. Accessing or modifying security configuration objects (Policy, Security, Provider, Signer, and Identity).
  17. Using the subclass and object substitution features of the Java Serialization protocol.
  18. Passing the this reference as an argument or returning the this reference as a result. Instead, you must use the result of the getEJBObject() available in SessionContext or EntityContext.


Java 2 Platform Security policy

The restricted features listed above are, in fact, standard and powerful features of the Java programming language and the Java 2 Standard Edition (J2SE). The EJB container is allowed to make some or all of the restricted features from the J2SE unavailable to the EJB components -- by using the J2SE security mechanism rather than by subsetting the J2SE API set.

The Java 2 Platform Security policy for the standard EJB container of the EJB 1.1 specification defines the security permission sets that concur with the programming restrictions on EJB components. According to the policy, several permissions such as java.io.FilePermission, java.net.NetPermission, java.io.reflect.ReflectPermission, and java.lang.security.SecurityPermission are denied in order to enforce the programming restrictions listed earlier.

Some EJB containers may not enforce the restrictions with the expectation that the EJB developer will either adhere to the programming restrictions or violate them at his or her own risk. EJB components that violate those restrictions, by relying on fewer or more permissions than the standard set, will at the very least not be portable across EJB containers. In addition, indeterminate and unpredictable runtime problems could lie hidden in the code. That's all the more reason for EJB component developers to be aware of those programming restrictions and take special care to adhere to them.

Any violations of those programming restrictions within the EJB implementation code will not be detected at the time of compilation since those features are, after all, an integral part of the Java language and J2SE.

Those restrictions apply to EJB components as well as helper/access classes used by the EJB components. J2EE applications are packaged using the Java Archive (jar) file format into a file with an .ear extension (ear stands for Enterprise Archive). The ear file is the standard file format for delivering an application to the deployer. The ear file consists of EJB components in one or more ejb-jar files, and possibly library jar files on which the ejb-jars may depend. All code in that ear file is considered application code and is subject to the programming restrictions and permission sets.

1 | 2 | 3 |  Next >
Resources