- The client’s view
- Fundamentals of the EJB architecture
- Types of EJB
- Distributed and local EJB semantics
- Anatomy of an EJB
- Principle of operation: session and entity EJBs
- Principle of operation: message-driven EJBs
- The EJB container and its proxies
- Overview of the EJB API
- EJB rules, standards and limitations
- Assembly and deployment
Most applications will need to be configured after development to suit the needs of a particular customer. Even if the application is custom-written for a particular client, it is inconvenient if small changes in settings require recompilation of the application.
Outside of the EJB domain, a number of approaches are used to supply configuration information to applications: configuration files (various formats), environment variables, command-line arguments, database tables, etc. The EJB Specification defines exactly one way to supply configuration information to EJB applications [EJB2.0 20]. The configuration information is placed into the deployment descriptor, in the form of ‘environment variables’ (not to be confused with operating system environment variables, although their purpose is similar). Each variable has a name, a type, and a value. EJBs read these values by making JNDI name lookups, as will be described in Chapter 7.
The EJB Specification calls for this information to be processed only at deployment time [EJB2.0 20.2.4]. After deployment, changes in the environment variables require a redeployment. However, most EJB products do have mechanisms to change the environment variables after deployment. Such mechanisms are invariably vendor specific, and usually undocumented.