In 1998 Sun introduced their distributed server-side component architecture under the name of Enterprise JavaBeans (EJB). Since then, the EJB technology has seen a widespread acceptance throughout the industry. The "write once, run anywhere" philosophy embraced by the EJB specification is undoubtedly a major factor in its success. An EJB component can be built once and then deployed on different platforms without recompiling or altering the source code.
The concept behind the EJB API is simple: let the application programmer concentrate on writing business logic and shield him or her from complex system-level services. To achieve this the EJB components must operate within a controlled runtime environment called the container. This container is responsible for all the system-level services, such as instance pooling, transaction handling, security, exception handling, and data caching. To provide the EJB component with these low-level services, it's mandatory that the EJB interact only with the container and the resources provided by it.
Programming Restrictions
Not having to write system-level services comes at a cost. To ensure portability across containers from multiple vendors, the EJB developer is expected to operate within the framework provided by the EJB specification. This means there are restrictions on certain features that are normally available to the Java developer. The specifications of the runtime environment (EJB 1.1 ch18, EJB 2.0 ch24) list these restrictions.
Some restricted features such as changing the socket factory of ServerSocket are rarely used, and this article won't elaborate on these types of restrictions due to the fact that few developers will be exposed to this level of programming. However, there are restrictions that can have a significant impact on your usual coding techniques.
In this article I'll state some of the programming restrictions as defined in the EJB specifications 2.0 (almost the same as the 1.1 spec) and try to explain the reason for the restriction. Where possible I'll also include an alternative approach to reaching your goal without violating the restriction.
Before diving into the details of the restrictions, it's important to clear up one of the greatest misconceptions in EJB programming. Many believe that these restrictions apply only to the code they write within the EJB's classes and not the helper classes used by the EJB component. This is wrong. The EJB components run within the container, hence all classes that run within the container are subject to the same restrictions.
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 restriction is simple but it has the greatest impact on a programmer's normal coding routines. When using a static field (class variable) you expect all your instances to access the same field. If you're operating within one JVM, this is a correct assumption; however, the EJB server can run multiple JVMs for performance or load-balancing reasons. Now each JVM contains one or more instances of the EJB and these instances no longer reference the same field. In addition, there's the problem of concurrent access to the static field, because in the EJB specification the use of the threading API is also restricted, so no synchronization mechanisms are available (more on this later).
